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?