There is a heated discussion going on in Hacker News, started after an article written by Eliot Horowitz, CTO of MongoDB. He claims that engineering managers should code 30% of their time and then goes on to give good tips on how to go about finding the time. In the usual Hacker News style, this created a very heated debate where the top comment is: “This is ridiculous… And honestly, this is just BS.”. One common thread mentioned in the discussions is the sports analogy (NFL, MLB). In this case, the engineering manager role is compared to the various levels of sports coaches. And the argument goes something like this: Just as it is ridiculous for a coach to play alongside the players or train with them in the field, it is also ridiculous for engineering managers to code alongside the team. They have too many things to do as a manager, and spending time on coding is surely not time well spent!

Even though, there is some merit in the analogy between sports teams and software teams, I think the comparison of the specific duties or elements are not appropriate. Yes, a sports coach does not play in the field. But have you ever seen one who does not show up to the game? A sports coach always stays with their team during the game, running around giving directions, reading their and the opposing teams’ plays. They actively participate in that game, by being there shouting, running, yelling if necessary. Well sports is a very different beast than software development. So I am not going to attempt to partition elements of a sports team or a game, and try to compare those elements one by one to elements of a software development project. The actual comparison need to stay at the level of intent. At a meta level, a successful coach is always committed to the team and the game. Similarly a successful general is always committed to his soldiers in the battlefield, charging the enemy and fighting alongside them. So in that sense, an effective engineering manager needs to be 100% involved with their team and the product. Then the question is: Is coding a must-have activity in order to be 100% involved with your team?

In a software project, the only truth lies in the code. The documentations rot (or not exist in many cases), the diagrams never get redrawn after the code is implemented. The complexity of a software project lies in the way it is implemented. You cannot just say: “Well it makes sense that component A calls component B and not vice-versa” and assume that is the case. So the point is not about knowing how to code or having been a coder before. You could even be an active coder, working on your own pet projects or company research initiatives. The point is to intimately know the codebase you are managing. If you are a startup CTO, the chances are you probably built a good portion of it, so you would know it quite well. You can probably keep yourself up-to-date with relatively lesser effort. However, if you get hired as an engineering manager to a codebase, you have not worked on, then you have your work cut-out for you. Without knowing that codebase, you will not deeply understand whether you need to pay that technical debt or not.

There is only one way to truly understand what is going on, and that is to get your hands dirty. You will need to setup a development machine, checkout the codebase and run your first build. But that is just a starter, in order to learn something you will need to actually do it. You would soon need to poke some parts, yank some other parts, break your (own) build, add a few baby features, fix a few bugs perhaps. The thing is, this is not different than, what a new developer in the team would do to come up to speed with the codebase. So it is not about knowing how to code or having coded before. It is about knowing that particular codebase you are working on. Only then you can know the strengths and weaknesses of that codebase first hand. You will have a better feel for when to pay the technical debt and understand how to go about estimating what it would take to add a new feature. And only then you will be truly part of your team. You will be able to defend your team against unreasonable demands. You will be truly accountable for what you and your team produce. As for analogies go, which one sounds like a more effective leader that you are likely to follow in the battlefield? One that is standing tall on his horse with a drawn out sword or the one that stays in his palace talking to his generals and waiting for the pigeon to arrive with the news?

So does it take 30% of your time to get immersed and keep being immersed in your codebase? Well it depends. It may even take more than that initially, if you are brought into an existing and large codebase. But it is a price that needs to be paid. Otherwise you will be driving in blind. Hey, who said being an engineering manager is simple?