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?
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.
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.
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.
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.
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.
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 :)
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.
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.
Perfect April fool joke
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.
@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.
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.
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!
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.
So a manager should really be a leader.
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.
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.
Sorry about the rather long comment.
I
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.
Interesting article Scott :) and some very interesting comments too.
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.
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.
Great article! I went the management route and have never been happier. I wrote a blog post on my top reasons for choosing management vs coding here: http://softwaremanagementblog.net/2016/02/24/top-5-reasons-to-choose-managing-over-coding/
Thanks for checking it out!
Managers of programmers don’t have to be able to program at all.
As long as they stay out of the programming and manage. This means things like making sure programmers know what the objectives and expectations are. Ensuring things are kept track of. Ensuring programmers aren’t blocked and that there is sufficient coordination.
I’ve seen a lot of good managers like this and they trust their programmers. They tend to be humble and it works well. Some managers with programming experience can make it worse if it’s only as a bad or average developer and if it’s only moderate experience. Well studied but non-practicing managers tend to be even worse because they revel in the theory but only know things rather than understand things and the practice. The result is being asked to do things in unnecessarily complex ways (such as a client needs a dead simple RPC API but then your manager sells them on the notion that it also needs to be a SOAP + REST API and suddenly one days work is a months work even though the client isn’t paying for it but it makes the manager look good to say those buzzwords or they looked up how to make APIs and got that) or sometimes overly simplistic (braindead rules are easy to enforce but it doesn’t make them good). Some programming experience unfortunately has a tendency to make them more bold and confident in imposing things such as standards that might be naive or solutions that are suboptimal. As in you don’t need to do any of this fancy escaping for input on SQL queries I used to be a programmer and we never had to do it. Or you have to sole every conceivable problem with DDD because that what I had to do when I was a programmer, even though it’s a months of additional work with no benefit and we don’t have months. It’s usually presented as I was also a programmer therefore your perspective doesn’t matter. It just gets used to blindly assert authority. That might not be the case if the manager has a good attitude or was a really good developer. Lets be serious, not that many people go from a programming role to a non-programming role because they’re such good developers. A problem in programming and management is that it can be very hard to fatally fail but very easy to let all of the non-immediately fatal errors mount up. If a company has a million in cash floating around and a manager is given something new to do, whether it is done within ten thousand, a hundred thousand or half a million then it’s not a failure. In fact being seen as to have managed a half million dollar project will bring more prestige. In reality no one will know that it should have cost ten thousand dollars.
Those are all typical problems but if managers do stick to managing those who do the actual work that needs to be done and allowing them to do that with reasonable autonomy then the biggest problem of all though is that it’s very hard for such managers to know if their developers are very good. I’ve often seen this play out poorly.
* One developer was considered very good but did things like sanitising all input into an application naively and in an extreme fashion. Down the line this led to corrupt data and a broken content system since data a party submitted wouldn’t match the data stored. To be fair this developer at least didn’t over complicate things but they weren’t entirely aware of what they were doing either or the consequences such as creating a denormalised table that now makes it impossible to upgrade the DB because the columns and keys are too long to switch to a better engine.
* One developer hired as senior despite only a year and a half experience thought that all branches should be versioned immediately. The same programmer thought that because monoliths were a thing from the 70s that simple ten line functions that were really just different endpoints of the same application should be broken up into entirely separate applications just because they’re called by CLI rather than HTTP. The result was what should have been ten lines becoming thousands and thousands. The same developer thought that it was fine to also have different versions of the application on production servers that only existed to spread load which included different versions that people had edited directly in production to fix random things.
* Another senior developer tried to cram a 16 bit variable into an 8 bit variable by taking the top and the bottom then adding them. Generally a lot of their code was bad but hidden among layers and layers of excessive objects and classes. You would have to jump through dozens of classes and thousands of lines of code to determine the actual one hundred lines of operative code that had been scattered throughout a convoluted object graph that served no real purpose.
* Another developer that had been left alone for years had turned what could have been a ten thousand line application into a million line application. This included a fifty thousand line God class, objects wrapping objects wrapping objects across layers with every function throwing exceptions then immediately catching them and turning them into error details on the objects. An object using one of these objects in a method would throw an exception only to be immediately caught and converted into an error number. This was a company in the center of the city with over 50000 employees.
I could make a much bigger list but this is some insight. Sometimes these mistakes are annoyances that someone like me has to come along and fix. Sometimes they result in complete disaster or years and years of work that’s unnecessary. It’s very common to see money effectively being poured down the drain with bad development. I’ve seen companies that when you do the analysis have wasted millions on salaries alone from the extra work created. A lot of these companies just about manage to stay afloat but are always on the edge of cataclysm. It’s like the Malthusian Trap of incompetence.
Teams that aren’t structured as to represent competence and that don’t self structure accordingly really don’t do well. A very common problem is that those who have stayed the longest are automatically the most senior. Bad programmers without oversight for a long time also tends to work out poorly. Relatively something as simple as visiting a bad developer once after a half years effort, pointing out the top ten worst things and then leaving them to fix those can make an almost miraculous difference.
In my experience which is fairly expansive I can safely say at least 9 in 10 programmers basically suck. Most struggle at things I was excelling in after a year or two self taught programming despite years of experience, qualifications, etc (YOE and degrees don’t always reflect very well on programming ability). It’s not as bad a problem as it sounds. They can still be very productive and they can learn. The problem is when you have a jumble and put the bad ones over the good ones. You need your best developers to be the tip of the spear and to help suck developers do the best that they can especially when it comes down to things that need to be done, things that don’t need to be done and things that’ll come back and bite you in the ass down the line.
A good team gets the best potential out of each of its members where-ever possible. The exception to that is when one member is ten times more capable. That is the last member you want to significantly handicap especially as such members when uninhibited also improve maximising the potential or productivity of other members. What tends to end up with jumbled teams is that good developers are suppressed by their peers, especially if it’s driven by consensus or with an idiot in charge. When you have an idiot in charge it often becomes the case that no one else is allowed to be anything other than an idiot. Anything they don’t understand even if it’s basic programming is your mistake and you’re a problem. In such a case you might as well deliberately only hire idiots. The problem with that is that in a group of ten programmers taken at random there’s a good chance of one being ten times better or more than all of the rest.
Programming groups and dynamics don’t really work entirely according to how people would expect based on instinct. A good programmer will be able to do things no number of bad programmers can do (unless there’s a good programmer in their waiting to get out). It’s a bit like in physics. In realistic terms you can’t simply get ten mediocre physicists and then get the work of Einstein out of them by somehow combining their efforts.
Programming is problematic because it skirts both lanes. There are a lot of basics that bad programmers can do and those scale. There’s an awful lot that doesn’t scale though. I can give an example of how that looks when it actually comes to scaling.
I visit one company consulting. They collect and analysis data in a process driven by five developers. They have a problem analysing their data. It is presented as a lot of complex data that requires a lot of resources to process. They have a number of plans including virtualisation and using large clusters of virtual nodes to process the data. This includes all of the latest trends and fads such a microservices, NOSQL, memory caching, etc. This would bring in large costs and additional complexity for handling the data. They’re expecting to have to bring up hundreds of servers to process this stuff. Down the line perhaps thousands.
On investigating it I find that the data is not that complex. Their core data is only a few GB. It does however have a series of integrity issues that were made significantly worse where queries were run in the background and then the results saved to attempt to speed things up. Over 90% of the data was derivative and the results of things like joins or group by.
After a couple days of analysis and a week of implementation:
* Removed thousands and thousands of lines of code completely unnecessary.
* Removed most of the redundant data in the database.
* Fixed a few queries.
* Left them with a system that would happily run on a single server for years and years.
* Left them with a system where they wouldn’t have to hire ten people every half a year to keep up with it.
This is actually representative of most shops and it’s not the first time I have done that. The difference one good programmer can make isn’t comparable to that of bad programmers no matter how many bad programmers you group together. You’ll probably just make things worse as they spew out more and more bad code that then needs to be maintained.