Should managers know how to code?

In a series of posts, called readers choice, I write on whatever topics people submit and vote for. If you dig this idea, let me know if the comments, and submit your ideas and votes.

This time: Should managers know how to code?

I see people debate this all over the tech sector, and in tech/web groups in other companies. Even back at Microsoft, we used to argue about this all the time, especially whether program managers (e.g. small team level project managers) should know how to code or not. Sadly, no one ever researched whether it had any bearing on their success or not in this role.

In short, it depends on what you are managing.

If you are A) exclusively a manager of software developers, then yes, you should probably still know how to code and have a programming background. But only a small percentage of your working day (5-20%) should be spent writing code. The larger your team, the smaller this number should be. Once you are the boss, your primary job is to do all the things that individual programmers can not do. To fight the political battles no one else on your team can fight. Champion new initiatives or directions. Resolve ugly conflicts. Coach. Arrange for training, budget, skill development and recruiting, so the team continues to grow and get better. Managers who are former programmers are notorious for continuing to be good at programming and entirely sucking and neglecting just about every other task good managers do. The tech sector is filled with these people. It’s sad. In many cases they’d be better off with the kind of people who end up as B.

If you are B) your management role is more general, say a project manager or a team lead, but you do have programmers working with or for you, then knowing how to code is less important. You probably have a background in business, or marketing, or have worn many different hats in your career. What is important are the following:

Do you have their trust? And do you trust them? It matters less how you get it, but put simply, do programmers trust you? This can be true or not regardless of how much you know about coding. If you protect your programmers, help them to be effective, keep them out of boring meetings and other forms of stupidity, then you’ll have their trust. And with trust they will be a partner and an ally, and work with you to get the best out of each other regardless of how much you know or don’t know. Oddly, it’s calling bullshit, or to be less confrontational, asking good, smart, tough questions that demonstrate you not only understand, but you care, that often earns trust. On the other side, leaders have to extend trust first and resist the tendency to micromanage what you don’t understand. Leaving programmers alone with crystal clear goals and deadlines they’ve collaborated on can be a surprisingly effective management style.
Can you call bullshit? Part of the conversation with every employee is sorting out whether what they say is hard is a) actually hard b) they are ignorant of how to make it easier or c) it’s just something they don’t want to do. A good leader has have enough understanding of tradeoffs and how software works to ask tough questions and, now and then, call someones bluff.
Do you understand morale? There is more to morale than morale events. Someone has to understand what motivates the programming team. What gets them excited and what makes them depressed. I can know more about programming then the 100 programmers working for me, but if I ignore their feelings about their work, never inspire them, or help them understand why the work we do matters, what good is that programming knowledge? Its worthless. A leader who can understand, motivate, inspire, convince, or in some cases merely make people laugh, makes a special contribution no one else can likely make.
Do you understand coding concepts? There could easily be a “programming for managers” short course. There are meta concepts that matter: performance, objects, the problems of specifications, APIs, basics of testing, etc. that don’t require hard core programming skills to understand. Even just having some exposure to working in HTML/CSS, Flash, Excel macros, anything, if taught in the right way, can yield a sense of the concepts involved, and those concepts are what matters. You don’t need to be a geek to speak and understand geek.
Can you help programmers make good decisions? Good decision making is good decision making. Any good leader (e.g. a president, executive or parent) is often in situations where they are not the expert, but where they have to work with experts who know much more about something. There is a skill, a communication and thinking skill, for how to maximize the utility of an expert in making a decision. Simply asking a programmer two questions: 1) What are our 3 or 4 alternatives here? 2) What are the tradeoffs between them? frames the conversation so that good decisions are likely to surface just through conversation. Even in listening to the programmer explain the differences forces the programmer to think better about the decision, and simultaneously informs the leader on the context, tradeoffs, and risks that matter without forcing them to become experts themselves. Managers don’t need to be experts – they need to be great at getting functional value out of experts of any kind. Another word for this is facilitation, but people rarely like to admit that the secret of good leadership hinges on a touchy-feely communication word like facilitation.
Can you let programmers help you make good decisions? As is often the case, this is reciprocal. Are you capable of taking ideas on design, marketing, or management from the programming team? Just as you have insight into what programmers should be doing, programmers have insight into what you are doing. Another quick way to build trust is to let them see that if they give you feedback or a suggestion and you make use of it, they’ll know you have their ear and treat you differently for it.
Can you represent their work well to others. The other functional task leaders have is reporting on, or showing work the team has done to people not on the team. This likely involves being asked technical questions, and the leader has to be able to represent some percentage of these questions and challenges well from a technical perspective. Typically if a leader is truly involved in the decisions, and understands the tradeoffs, they’ll be able to answer many of the questions about the work. But if they can’t, and must always be surrounded by a crew of programmers to prevent being embarrassed, then they’re not as useful to the team as they should be.

Conclusion: There are so many different kinds of teams and projects where my advice might be different, but on average I’m convinced someone of type B, who can’t code but meets most of the criteria above, will have better results than someone who can code, but meets less of the criteria I listed above.

Disclaimer: Of course there is nothing mutually exclusive between being a great programmer and being a great manager. These people exist. But they’re rare (How many have you met in your career?)

What have your experiences been like?

If you liked this there's more: please subscribe to this feed or follow me on twitter

Posted Thursday, April 1st, 2010 at 10:10 am

in Management, Microsoft | 30 Comments »

Drew - April 1, 2010 at 11:34 am #

Love the point about helping “facilitate” by asking clarifying questions like “what are our alternatives” and “what are the tradeoffs?”
I feel like this skill is underrated, while self-described certainty is often highly valued. The distinction matters–it’s the difference between making a good, one-way presentation of a solution, and developing a good, collaborative solution.

Rakesh Malik - April 1, 2010 at 12:18 pm #

Most of the dev managers that I’ve had have been former coders… and most of them clearly weren’t very good at coding, either. The best managers I’ve had have been non-coders. They’re the ones who actually put some effort into facilitating the development process. The former coders generally just got in the way and prevented the development team from doing anything right. (That’s not a joke; they generally forced the team into using the most complex approach rather than one that accounted for actual users’ needs.)

So based on experience, I would say no, because in most cases, developers make bad managers.

Sean - April 1, 2010 at 12:37 pm #

Rakesh, most *people* make bad managers. Management is hard. The problem isn’t that developers make bad managers. It’s that very few people have what it takes to be a good manager. This is just as true in textile manufacturing, police work, civil engineering and graphic design as it is in software development. The problem is of course compounded by the fact that many companies promote individual contributors who are good at their job into management roles. There is, of course, little if any correlation between being a good programmer and being a good manager.

The lesson isn’t that managers shouldn’t know how to code. It is that most companies need to do a better job of selecting and training managers.

Scott Berkun - April 1, 2010 at 12:40 pm #

Sean: You reminded me there is an argument (not saying it’s a good one) that if, say, one out every five programmers is good, and one out of every five managers is a good manager, trying to find a good programmer who is also a good manager is waaaay harder.

ray - April 1, 2010 at 2:09 pm #

my father had been a manager for one of the biggest electronic/software/chip companies and he knew everything about programming in every language, all the electronic and physics theories and practical uses and so he knew all the steps the departments he managed did, and far more, had a big picture of everything, he even studied at home program listings with more than 2000 printer-pages so he knew what he was managing.
i think it’s a requirement managers know more and even studied what the other people in the company do every day.. i mean, he is “managing” the company and should know what every one doing in the company is able to, so he could get the corresponding jobs for the company..
today a manager gets a big job and the people working in the company have to make it, else they get thrown out.. this is totally NOT the way to successfully manage a company, or you would have to get different people for different jobs all the time and not keeping a company and its people together to be a productive and team-working elite who know each others personality and can arrange to it, even with their own work..
i can just say, its a natural way to manage things successfully, even if other modern ways to manage (without knowing what people are doing and how to code, and what is possible) would be more efficient, maybe causing an unnatural and cold company environment with many people being unsatisfied and getting thrown out and new people just classified for their jobs by numbers getting into companies for a short period of time..
i think its how you want a company to be like and if you care about a short term financial goal, or a long term humanitarian goal in reaching your company’s goals.

Paul - April 1, 2010 at 2:55 pm #

The problem is that most excoder-managers have become managers because there is nowhere else to promote them to. Companies don’t like to put “architect” in someone’s job title because of the implicit salary, nor do they understand what a “coach” is. But those are the two roles most coders should end up in.

And I say all that as an excoder-manager who was promoted for exactly that reason, and probably shouldn’t have been, though I think I’ve adapted better than most of my colleagues and that I’m getting better as time goes by. You’d have to ask people who’ve worked for me to be sure of that though :)

Mike Ramm - April 1, 2010 at 3:28 pm #

I think it is possible one to be a good coder and a good manager but not at the same time. These jobs require different thinking and this is the reason it is so difficult to find a person who is a good developer and good manager at the same time.

But I would say that I was a good developer at the time and later decided to switch to management and became a good manager. I stopped coding now. I still know how to code and I understand coding issues but I am not so good anymore simply because I haven’t kept up with the news.

Anyway, I believe that coding experience gives me some advantages in managing software developers.

Jeff - April 1, 2010 at 7:16 pm #

There’s always a gray line that defines how much coding and managing someone should be doing as they’re rising through the ranks, especially before they’ve been officially anointed as management of any kind. I’m usually around 50/50, and I believe I do both jobs well.

That said, I can feel myself get better in one aspect or the other as the 50/50 is skewed due to business demands. So greatness as measured by immediate knowledge, yes, that is diminished on the technical side without constant practice. Greatness as measured by the ability to quickly ramp up on concepts and ideas and that immeasurable intuition that is honed through experience? That sticks around longer, and with the proper influence in whatever business setting you’re in, can be maintained with less practice than the technical side.

Pawel Brodzinski - April 2, 2010 at 1:41 am #

I never met a person who is great programmer and great manager at the same time. Actually I would go further than you and say that paths of being great manager and great programmer at the same time are mutually exclusive.

It just constantly takes time to be good at management and at programming. It’s not that you work hard to become good manager and then you’re good at it for life. It doesn’t work that way. You have to spend significant time and effort to maintain your managerial skills, to keep them actual. The same is with programming by the way. An engineer who stops learning becomes obsolete, same as his code.

Unless your twenty-four hours are longer than ours or you’re able to work 12+ hours everyday it’s close to impossible to work on both fronts.

Allison - April 2, 2010 at 6:02 am #

@Pawel – so I actually have seem a manager/coder work a few times. Typically the breakdown is at least 80% manager and 20% coder where the 20% is done after hours and the team is smaller than 10 people. When I did that split, I was more 90% manager and 10% coder. Oh and all the code needs to be non critical. And did I mention almost all coding is done after hours? Hybrid positions are hard and shouldn’t last more than a few months to a year. Max.

The big issue, I think, that holds back a ton of former coders from being good (to great) managers is simply her ability to let go and trust her team. Too many times I’ve seen managers try to still be an architect or try to tell senior devs to “do it this way” instead of the way they want to do it. Or, even worse, withhold critical project information from the team since they think “protecting” means keeping coders in their dark cave, blissfully unaware of the big picture. Micromanaging and withholding information are not good skills to have.

Once a former coder now manager can let go, can trust, the final points of what is good/great (from Mr. Berkun’s points above) can start to happen. But not before.

Dick - April 2, 2010 at 6:27 am #

Excellent post Scott. Been there, done that, got the scars (and a few kudos). My personal experience tends to say that project leads for software projects need to have done the software job and retain the concepts. After that, if I’m the PM then I’m going to need to depend on and trust my technical lead or individual team leads on the coding details–my hands-on experience is decades out of date and I know it. Leadership is “trust and trustworthy” (Mike Mears). Oh, and have you read “Managing Einsteins” by Ivancevich and Duening? I really like it and much of what you’ve said here echoes thoughts there.

Jen - April 2, 2010 at 6:32 am #

I’m a programmer. The differences existing in what you are managing is so important and also brings up another question: To get the best out of programmers, how do we organize / group (there may be a better word here) them?

The best management experience I have had was where I was on a team exclusively consisting of technical people. Our manager was a former coder and stayed current on technology and development tools. He therefore had the ability to coach and provide technical leadership on processes, training, and tools. There was no anxiety about being poorly represented and yes, he could call bullshit. Our development team was then enabled to do our best work and our projects were consistently successful. In general, technical people have a need to intellectually respect those they report to.

If a technical manager has no coding experience, at the very least, they should read “How Coders Work”.

Excellent post!

David - April 2, 2010 at 9:14 am #

One thing to keep in mind is that to discuss this topic, it is important to understand the functions/roles of a manager. Most readers of this blog know what software development is all about (I think this is a safe assumption). But I assure you that unless you’ve been in a management position, you can’t know for sure what your manager has to deal with.

A very good reference for those of you who want a better understanding is the book “Managing” by Henry Mintzberg (or his earlier Harvard Business Review article “The Manager’s Job: Folklore and Fact” (March 1990).

After reading either of these, you quickly understand why the coder/manager skillsets are so different and that being good at one doesn’t have much bearing on being good at the other.

Raj - April 4, 2010 at 6:32 am #

Great post Scott. Based on my personal experience, in todays work environment, its really important to distinguish that managing is a very different job and not about being a better programmer. You need to be very clear exactly what you bring to the table else you can be left feeling like a “middle manager”. A manager needs to spend more initiating and figuring out WHAT needs to be done. While its good for all programmers to think like entrepreneurs, entrepreneurship is one of the prerequisites to being a successful manager.

Mike Nitabach - April 4, 2010 at 12:58 pm #

Dude, if you replace “manager” with “principal investigator”–i.e., head of an academic scientific research laboratory–and “programmer” with “bench scientist”, then every single thing you say applies exactly in the context of effectively managing academic scientific research labs.

However, an important difference in academic science is that the *only* people ever given the opportunity to become PIs are those who have first demonstrated outstanding talent as bench scientists. This means that (1) many PIs never learn to stop thinking like bench scientists and start thinking like managers (and thus suck at being PIs) and (2) many people who are attracted to science as a career and could probably be outstanding PIs, never get the chance because they were never good enough at the bench to get a shot. It is a very good thing about computer engineering that there are alternate routes to project management than via programming, and it is a very bad thing about academic science that there are no routes to PIhood other than via the bench.

Berthold - April 13, 2010 at 2:24 am #

I’m certainly more of a facilitator these days, but I still know how coding works (being a design student, I have to make use of that skill frequently, despite not being especially psyched about that). The #1 thing people tend to neglect as managers (I know I have) is being honest and upfront about what you can and can’t do. If you pretend you can program and are found out to be a hack, bye bye respect. If on the other hand you tell your programmers that you only have a rough idea about what exactly they do *and* you respect their decisions (and learn about programming in the process), everybody wins. Bonus points for actually asking one of those pimply, bespectacled nerds to teach you a few tricks.

Your aim in learning this part of the job is indeed to baffle everybody by calling bullshit one day. Don’t do it too early, though, or you run the risk of shooting yourself in the foot.

Coders who become Managers – Lessons Learned – random relativity - April 2, 2010 at 12:15 pm

[...] First, read this post, I think it’s apt to what I want to talk about. Have you read it? Good. Now the first lesson, and most important, as a coder turned manager that I can impart on you is to trust your employees to get shit done. They can, and will do it better than you (or at least different). You, as their manager, are not their to micro manage their every move, critique their use of memory, or otherwise spoon feed them their work.

Development Managers: To Code or Not to Code â€” cioessentials - April 21, 2010 at 10:25 pm

[...] Berkun has a great post that talks about this in detail. Whether or not managers should know how to code depends on a [...]

Managing people and skill-sets II « Ian Hilt's Blog - May 26, 2010 at 5:41 am

[...] other people are thinking about this and have also reached similar conclusions. Scott Burken has written in a much more detailed manner about this subject. I have to say I agree with [...]