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?)

(Related – see: Long comment thread about a similiar question on Stack Overflow)

What have your experiences been like?

34 Responses to “Should managers know how to code?”

  1. Drew

    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.

    Reply
  2. Rakesh Malik

    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.

    Reply
  3. Sean

    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.

    Reply
  4. Scott Berkun

    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.

    Reply
  5. ray

    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.

    Reply
  6. Paul

    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 :)

    Reply
  7. Mike Ramm

    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.

    Reply
  8. Jeff

    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.

    Reply
  9. Pawel Brodzinski

    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.

    Reply
  10. Allison

    @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.

    Reply
  11. Dick

    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.

    Reply
  12. Jen

    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!

    Reply
  13. David

    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.

    Reply
  14. Mark

    So a manager should really be a leader.

    Reply
  15. Raj

    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.

    Reply
  16. Mike Nitabach

    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.

    Reply
  17. Rubio

    Sorry about the rather long comment.

    I

    Reply
  18. Berthold

    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.

    Reply
  19. Nrithya

    Interesting article Scott :) and some very interesting comments too.

    Reply
  20. Hussain

    I think the best project managers are ones that are from a technical degree such as computer science but doesn’t necessarily want to program in the real world. They will have the logical understanding to understand how software development works and understand the constrains and empathise.

    Reply
  21. Andy

    Just to chime in here. We are fortunate to have a PM who is an excellent programmer with 15 years experience coding but is also excellent with people and a great manager. You could say he is a unicorn, like designers who know how to code, or programmers who can design.

    Of course it helps when your manager can program. Even better when they are better than you and can help you. I have other managers who are ex designers or marketers and when the other guy goes on holiday they just fall to pieces because they literally don’t understand how things are built.

    It’s like designers of aircraft. Would you get in a plane that was designed and managed by people with no knowledge of aero nautical engineering principles? So why do we build websites with managers and designers who don’t how to websites and software are built.

    Reply

Pingbacks

  1. […] 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.

Leave a Reply

* Required