In Engineering Management circles this is an eternal question. Once you leave your position as an IC, do you stop coding with the risk that the skills that got you to where you are decline over time, or do you keep trying to mix your management work with coding with the possible drawback that you don’t spend enough time on your management tasks?

A couple of weeks ago Cloudflare went down. The day after a post-mortem was posted on Hacker News and in one of threads it was noted that the post-mortem was very honest and open about what had happened. What was also noted was that it was very rapidly shared. In a response to this comment came the following from the user eastdakota:

Well… we have a culture of transparency we take seriously. I spent 3 years in law school that many times over my career have seemed like wastes but days like today prove useful. I was in the triage video bridge call nearly the whole time. Spent some time after we got things under control talking to customers. Then went home. I’m currently in Lisbon at our EUHQ. I texted John Graham-Cumming, our former CTO and current Board member whose clarity of writing I’ve always admired. He came over. Brought his son (“to show that work isn’t always fun”). Our Chief Legal Officer (Doug) happened to be in town. He came over too. The team had put together a technical doc with all the details. A tick-tock of what had happened and when. I locked myself on a balcony and started writing the intro and conclusion in my trusty BBEdit text editor. John started working on the technical middle.

Further down I realized that eastdakota was in fact Cloudflare’s CEO Matthew Prince. I was in awe, although Matthew Prince is not an engineer (he’s a lawyer), it’s an amazing feat of someone so far removed from the engineering organization to be able to write such a piece of clear and detailed overview of the events that lead to the downtime with the help of the (former) CTO. In any of the organizations that I’ve been, to have that level of detailed knowledge and the ability to explain it you would have had to been a very language gifted senior engineer or a senior tech lead or similar. Certainly not the CEO or CTO of a company of Cloudflare’s size.

This made me consider an incident that I experienced years ago where after significant delays and bugs in a project, the customer escalated the problems to the Director of Engineering. The director in this case was very hands-off and without the necessary technical experience, he was brought into the organization as “an agent of change”. The escalation meeting quickly spiralled out of control when it was obvious to the customer that the Director of Engineering could provide no insight into the problem or any direction on how to move ahead. Instead of being able to respond to the customer about what the issues were, their root causes and what the organization was doing to address them concretely, what was delivered was a speech of the organization’s committment to customer value and a deep felt wish to improve communications. The outcome was further escalations and a lot of trust lost with the customer.

For Engineering Managers, one of the most important questions that needs answering almost daily are “how are we doing” with the meaning, is the team performing as it should, do we have the skills we need, is what we’re doing good enough and so on. Surely the answer to these questions can be found in metrics but to understand and action on them, a manager will need to be able to evaluate the work of the team and that inevitably means hands-on experience with the code.

Turning to my own experience, it’s not uncommon that I’ve worked with engineering management who do not have a detailed understanding of the platform that they are managing. The argument has often been that as a manager, you should not be in the weeds of the code, your focus should be on managing the team or teams and making sure that they are performing as well as they can. While not entirely wrong, it misses this important aspect, if you don’t understand the code, how are you then going to judge how well the team performs?

Far too often you end up in discussions where an engineering manager is not able to explain what’s causing a team to be late, or why bugs keep reappearing or what the alternatives are to move faster (except reducing scope of course) or any other topic that includes a view on the engineering challenges that is detailed enough to actionable. Instead the engineering manager is turned into an expensive email router, just distributing information back and forth.

Going back to the case with the Engineering Director, how involved in the technical details should an Engineering Director be? Looking at the example above with Matthew Prince, if not actively coding then an Engineering Director will absolutely have to be very aware of what’s going on in the platforms he or she is managing. To the level of being able to explain why a certain initiative is late or what caused an outage at a detailed level. What’s really the alternative, just relaying information from others without being able to form your own opinion?