Charity Majors’ Post

*someone* has to handle the admin of the team (self organising or otherwise), has to deal with stakeholders. You either allocate one person to do this for a group of engineers (hopefully one person with aptitude and enthusiasm for these tasks), or every engineer gets to do it, do a worse job of it and be distracted by it. Also, someone needs to be thinking about the recruitment, pastoral care, career development and retention of those engineers. At 1:20 or a little more IME that becomes a full time job if you are going to do it well. And if you are not going to do it well, someone will be spending more time on recruitment shortly. I worry for your company if this is anything more than a passing thought for your CEO.

Great response to that person's question. IIRC from Erick Schmitt and Johnathan Rosenbergs book "How Google Works" they ran an experiment at Google removing lines of management. The experiment failed as they then found out all the socio needs that the management level was fulfilling so reinstated the management layer but ensured that the technical management layer were still close to the actual 'doing' of the work. It's been a very long time since I read that book so you may need to verify that. Brook's law https://en.wikipedia.org/wiki/Brooks%27s_law could potentially be a good addition where you speak to how engineering managers are a useful level of abstraction when it comes to the combinational explosion of lines of communication. I love this diagram for demonstrating just how many lines there are! 🙂

We can build an engineering org without engineering managers; its difficult and requires some 'unusual' culture and management structure(s). It may or may not be worth the cost for a specific org. But "we need everyone writing code, and can't take the hit to our velocity" is trivial to prove wrong - it's a simple "40 engineers have 41 incompatible opinions" problem ... without a management function of some kind you won't run in ANY direction. I think the rest of the article is over-complicating this. I've fielded this question plenty of times from first-time line-managers dropped-in to leadership roles without support or training, but I'm not sure how someone gets to the point of overseeing 40 engineers without knowing how to answer these questions. That seems a bit ... too ... artificial to me (who on earth took a VP-Eng role with 40 engineers but doesn't know the Day-1 basics of engineering management?)

Having EMs is largely to help ensure your teams are working together as a team, that individuals are getting what they need to excel, understanding the context of the team in relation to all the other systems at play in your organization and perhaps most importantly to ensure the team is working on the right things for the business. You can get away with no EMs at a certain size with the right personalities. It's small enough that context and awareness flows easily. As teams get bigger that isn't as easy and having an EM is a benefit. Velocity is worthless if you're working rapidly on the wrong stuff or in opposing directions. Just my .02 cents

A great engineering lead can also be writing code. Great leaders can lead by example. "Managers" in isolation without seeing the challenges sometimes up close, become detached from the reality faced and so lack understanding of them. And you can't get any more up-close, than doing it in person. Besides... Respect is often earned, not given - So having a manager that can't/won't get into the dirt and work with you often lacks the respect of their reports. TLDR; Your CEO is partly right. The trick is not to call them managers. Call them team leaders and focus on making/keeping the "management" piece low-touch, that those leaders can do themselves without stopping them being an engineer.

Managers who code should code sometimes, not for the sake of velocity but to keep in contact with the “temperature of the water” to be able to make appropriate decisions about the future of the environment. Managers who do not code have to be comfortable with making such determinations by other means — and that’s fine, too. Too often, managers are merely knowledge concentrators and (often not the greatest) abstractors of information in enterprises where contact between levels of an organization has been lost. That can result in bad metrics and an obsession with velocity (of what?) and “resource utilization” — losing contact with little things like creating good software and acquiring the knowledge and maturity to create better software. But the manager as hammer idea can go to hell.

Your CEO's idea does not and will not scale. Additionally, he can't measure and will never realize the friction he is inducing upon the team as they struggle to self-regulate issues better handled by someone skilled specifically as a leader/manager. This lack of organizational clarity is one of the most common things wrong in companies and teams, and it is no doubt dragging down the velocity the CEO thinks he is encouraging. It is a pity that Honeycomb’s approach is fundamentally different from other tools; however, its approach to engineering management is so classically flawed.

I think you've likely already got a bunch of great answers, but I'll bite (with the added benefit that it helps some Friday procrastination) The two strongest arguments I'd lean into are. 1. Google has done the work on this -- https://hbr.org/2013/12/how-google-sold-its-engineers-on-management 2. Having managers and people support the success of your engineers long term helps them to be able to get the best results. We can see all sorts of analogies for this, ranging from the coach on sporting teams to the conductor in a musical orchestra. Having someone that's job is to make the team successful is so important.

What do you need an engineering manager to do that the engineers can't do themselves? It's not a rhetorical question. What needs to be done? What skills are needed? Who has those skills? What skills do you need to grow or hire? Don't get hung up on titles.