Marc Hedlund on the less immediately tangible but in many ways more rewarding products of being a manager. The difference between good jobs and bad jobs is the manager you report to, a lot of the time. Most people spend more time at work on any other single thing. As a manager, your responsibility is to make that time more fulfilling, enjoyable, and productive. I find it’s a good gig.
Ta-Nehisi Coates writes about his experience of teaching a writing class at MIT this semester. Here he is talking about motivating students:
I didn’t have to work hard to motivate people. What I found was that if I showed up, and I was excited, they fed off of that, and they got excited. I came to feel that teaching was performance. My job was to communicate my own energy and belief in the importance of the work.
As a manager, this is what I try to bring to my work. Hopefully I’m successful.
I’m going to write more about this some other time, but one thing I’ve come to realize is that there’s nothing I appreciate more than a committed performance. Whether it’s from a singer, an actor, a teacher, or a colleague. Commitment makes up for almost any other deficiency.
Last week’s New York Times included a book review of defense reporter Fred Kaplan’s book “The Insurgents,” which covers General David Petraeus, counterinsurgency doctrine, and the wars in Iraq and Afghanistan. It explains well how falling in love with your ideas can get in the way of success.
Kaplan writes about how proponents of counterinsurgency doctrine in the military worked the media, defense scholars, and the defense establishment to replace the existing Cold War doctrine with their own ideas. Here’s how the reviewer, Thanassis Cambanis, describes their better days:
President Bush had promoted the COINdinistas because they were flexible, pragmatic problem solvers and because he had a nagging problem on his hands: how to get out of Iraq without looking defeated. Counterinsurgency was just one part of the fortuitous mix that yielded a just-good-enough resolution for Iraq. Petraeus and the officers and experts had been right about how to fight in Iraq and reached plum positions in the Pentagon.
And here’s the conclusion:
The COIN brigade forced the Army to adapt, to become what one officer called “a learning organization,” but the Pentagon failed to grasp the most important lesson of the decade: that the military does best when it can learn new types of missions quickly, whether delivering aid after a tsunami, stabilizing a failed state or running covert missions against international terrorist rings. Instead, it exchanged an old dogma for a new one. Once persuaded that the military could do counterinsurgency, few in Washington stopped to think about when it should do it.
This story reminded me a lot of the tech industry. Last year, GitHub’s Ryan Tomayko wrote a “here’s what works for me” blog post about his management style, which was fantastic. Here’s the crux of it:
It’s often cited that GitHub doesn’t have managers. In my opinion, a better way to describe the phenomenon would be to say that everyone at GitHub is a manager. Instead of assigning 100% management duties to individuals, the basic role of management is spread between 1.) every single employee, and 2.) a set of custom in-house tools that serve to keep everyone in the know with regards to other projects.
I think this is a pretty brilliant philosophy, and my impression is that it works very well for them. That article changed the way I think about my work as a manager.
This weekend I listened to a presentation from a developer at GitHub about their “no managers” corporate structure. This presentation essentially argued that the GitHub approach is indisputably the best way to run a company, and that all other corporate structures are broken.
This is exactly the trap that the military officers Fred Kaplan wrote about fell into. It’s a form of lazy thinking. Every problem and situation is unique. Nearly all people are naturally inclined to cling to heuristics rather than thinking deeply about problems and adapting to solve them.
This is one of the great penalties of success. People try something, meet with success, and then attempt to apply that formula over and over again, failing to recognize that new problems require new solutions. Often the real reasons for success go completely unexamined, because people are so eager to embrace it as proof of their own brilliance.
To the proponents of counterinsurgency doctrine, every war looks like an opportunity to apply counterinsurgency doctrine. To the GitHubber, every corporation should work like GitHub.
When people propose that all problems look the same, or even worse, that problems look different but that old solutions are still ideal, it’s a strong sign that they’re operating from within their dogma rather than starting with the problem and working their way out. There’s nothing that invites disaster more than falling in love with your own good ideas.
You should read John Alspaw’s essay, On Being A Senior Engineer, even if you don’t aspire to be a senior engineer. Maybe you already think of yourself as a senior engineer. Maybe you work in some completely unrelated field. What it’s really about is becoming a mature professional and not only mastering the skills of your field but passing them on to other colleagues in useful ways as well.
I recently read a post about the value provided by managers. I was not surprised to read that managers do add value, but I was a bit surprised at the means by which that value is added. I would have assumed that it was by keeping people happier, removing distractions that sap productivity, or helping to prioritize work. As it turns out, the actual value is in teaching people how to do their jobs better.
So as a manager, the best way to add value is to help people along their path to becoming senior engineers (if the people who report to you are engineers). As an engineer, you should be looking for opportunities to work for a manager who can teach you to be a better engineer. And perhaps most importantly, you don’t have to be a manager to help other people get better at their jobs, so you should helping other people get better as a key aspect of you’re job. This is one of the key points of John’s essay.
Anyway, you should be reading his post and not mine. It’s a road map to making the most of the incredible opportunity we have to work as engineers.
Valve gets a big feature in the New York Times. Unfortunately the article doesn’t really dig into discrepancies between the employee handbook and day-to-day life at the company. Maybe there aren’t very many, but it would be interesting to know.
Larry White argues with the idea that performance reviews are even a good idea. I tend to think that they are useless at best and destructive at worst. Good management involves giving constant feedback all year, not bundling it all up for one incredibly awkward process that takes pace annually.
Interestingly, however, there is one last bastion of economic activity that proved remarkably resistant to the triumph of the market: firms, companies and, later, corporations. Think about it: market-societies, or capitalism, are synonymous with firms, companies, corporations. And yet, quite paradoxically, firms can be thought of as market-free zones. Within their realm, firms (like societies) allocate scarce resources (between different productive activities and processes). Nevertheless they do so by means of some non-price, more often than not hierarchical, mechanism!
An observation by Yanis Varoufakis that has often struck me as well.
Yanis Varoufakis, Valve’s in-house economist, analyzes Valve’s non-management structure. Here’s a link to my earlier post on Valve’s approach to management.
Today I was sort of idly thinking about the difference between a manager and a team leader. I suppose these terms mean different things in different organizations, but I think it makes sense to propose general definitions that clarify a somewhat hazy topic. We’ll assume that in both cases, the members of the team report to the manager or team leader, at least for the duration of the project that they’re working on. (If you work at a place where people have a manager and a team leader and the responsibilities are divided, all bets are off.)
Both are accountable for the overall performance of the team. If the team fails to meet its goals or is dysfunctional, that’s on the person who’s running the team, regardless of their title. I strongly prefer to think about these responsibilities in terms of accountability rather than authority for the reasons I talked about in my post about judgement and influence. I think that teams function most effectively when the members buy into the team goals individually because they see the value in them, rather than because somebody told them to do something.
So the difference is that a team leader should be thought of as the senior practitioner on the team whereas for a manager that may not be the case. If you’re the team leader of a team of developers, you should probably be the best developer on the team, and the other members of the team should respect your technical capabilities. If you’re the manager of a team of programmers, that’s not necessarily the case. A manager may be a fine programmer, but their core responsibility is management and coordination, not necessarily bringing an authoritative voice when it comes to making technical decisions.
The difference matters in terms of setting the expectations of the members of the team. It’s a dangerous thing when the members of a team think of the person running the team as a manager but they think of themselves as a team leader. Or if the team members have a manager they expect to be a team leader but who isn’t equipped to function in that role.
I’d be curious to know what other people think about these definitions. I haven’t heard of the two titles being defined this way before, but they match with my expectations based on my experience. I think that as an industry, it might pay off to formalize them.
I’m just going to keep posting stuff about Valve until I get tired of it.
Did you read the Valve employee handbook? If not, you should. To catch you up, at Valve, the corporate structure is completely flat. They have no managers, and everyone decides what to work on for themselves. The handbook explains what is expected of Valve employees and how people should adapt to that corporate structure.I’m sure some people find it intriguing and others terrifying.
Succeeding at Valve depends on two things, the application of one’s judgement and influence. Employees use their judgement to decide where they can add the most value for Valve. They use their influence to recruit other people to help them build the things that they have decided are valuable. Find a problem to work on, convince other people to help you solve it. Nobody is empowered to order anybody to do anything.
What occurred to me after reading the Valve handbook is that you or I can work in the Valve style regardless of where we work. If you work anywhere but Valve, you probably have a manager and you may have people who you manage as well. Within the constraints of your job, though, you should be relying on judgement and influence rather than hierarchy in your work, just like a Valve employee does.
If, in your judgement, there’s something more valuable you could be working on, you should be convincing people (like your boss) that your time could be better spent working on that other thing. Just be sure that you’re open-minded enough to accept that your judgement could be mistaken. If you’re right, though, it ought to be easy to convince people that your time could be better spent on a more valuable project.
At the same time, rely on influence rather than authority to get the help you need to get your work done. People generally do better work if they believe in the project they’re working on, and the ability to recruit volunteers is a good sign that whatever you’re working on is worth doing. People sometimes mistake interesting for valuable, but it’s always better to work with enthusiastic volunteers than with people who are doing something just because someone told them to do it.
Obviously if you work on an oil rig or at Burger King, this approach may not work. However, the field I understand best is software development, and if you’re working on software, you should the Valve philosophy to heart. Use your judgement and influence to make sure you’re adding as much value as possible at your job. If that gets you into trouble, maybe it’s time to use your judgement and influence to land a job more suited to your talents.