(https://hbr.org/2013/12/how-google-sold-its-engineers-on-man...)
I am an Engineering Manager/Director and my life is quite hectic and not because of busywork. You work with some very brilliant people, but they often fail in conflict resolution. Even if you don't have EMs, you still have upper management and more often then not they're out of touch, here the EM acts as a translation layer that understands both the business and the tech enough to balance these tensions well to make sure the team works well while delivering value for the company. Sometimes you need to deal with other teams with their own agendas.
In essence - if things go well, there's less need for an EM. I had a well running team last year, so much so that my life was quite calm. Then the leadership forced product domain and technology change on us and we lost our tech lead. Even if 90 % of the team stayed the same the dynamics were completely new and I had to help the team navigate an uncertain environment. Things went to normal and suddenly we became responsible for the core of a cross-team project and I am busy pushing against leadership, getting other teams to commit to take the burden off of our core team and other much needed activites. My tech lead couldn't do that while also designing the tech solution so in a way I am helping them do better work.
The real difficulty, which the author only touches on at the end, is optimizing the number of managers. Not only are there diminishing returns to adding excessive managers, more management creates more workload for everyone past a point. But even though the organization would benefit from scaling back the number of managers, there is an obvious individual disincentive to say "it would be better for you all if I was fired." Thus once you get too much management, it tends to stick around[0], and therefore it is critical to avoid excessive management in the first place. The article articulates clearly why you need more than 0 managers, but it should include strategies for determining whether you need an n+1th manager.
[0] There is one fix. It's tough to get rid of excess management, but an organization can potentially grow into an appropriate size for the amount of management it has. This may be a challenge for a mature company, but for a startup like the one featured in the article hiring too many managers is just hiring an appropriate number of managers early.
The middle managers (the VPs and Directors) are essentially useless as they are passing forward the leadership 10,000 ft view. The managers are stuck implementing in their area and thus no two teams operate the same way. The workers are then in this area of constant upheaval as nothing seems to get accomplished the way leadership expected.
I read these articles as they seem to have come out every year first Google then Zappos then various startups. Leadership communicating to workers never seems to work out well as companies grow. They operate at too high a level and unless there are a solid structure of guidance to go across teams/individuals it makes it difficult to all row in the same direction. It makes sense that a UI team is going to operate at a different cadence to the services team to the data team, but if you don't have managers over each function at least there will be chaos in my experience.
I worked for a year with no engineering manager, no software director, no VP of Engineering. The most productive year of my group at that job. Brought out two new versions of our OS to support multi-processor configurations and use new memory modes.
Prevent other teams from reaching in and randomizing our priorities, work on promotion plans for anyone seeking promotion, manage customer/partner team relationships, ensure everyone has balanced feedback regularly, mediate disputes, collect information to manage upwards so we can still be funded, advise on team process but never mandate it, facilitate accommodations, manage poor performance so the team isn't dragged down, try to consolidate and clear meetings from calendars across the team.
If I'm not around, then all those things either don't get done or fall to the engineers themselves. I personally think it's useful to have someone on the team specialize in those activities for the benefit of the team. But I'll admit my bias.
Managers are like cockroaches, every time you turn on the lights, there are more of them scurrying around.
Yes, we do need project managers, but before you hire them you need a plan and business managers can't come up with sufficiently detailed WBS to drive a project of any significant complexity.
Before you have a project plan you need a business case and a marketing plan.
As a founder and soon to be CEO you need a rock solid business case.
Then a capable technical person comes up with a project plan with sufficient detail (aka WBS) that you can see what needs to be done and a provide a reasonable estimate of time-frames and resources required.
Only then do you need a project manager to make it happen. If the project is sufficient large, then groups of technical personnel might need a more experienced person, aka team leader.
The bane of so many "projects" is that they have a vague description of a deliverable, a hard deadline and a budget created without any comprehension of what is required to create the deliverables and whether the business plan will even sustain the realistic need for resources.
Maybe, in the article's startup with 40 engineers, if they want to structure it as compartmentalized worker drone resources, who mostly only do what they're tasked to do, and someone else has their eye on the bigger picture and what all the teams need.
Depending on the nature of the project, 40 engineers could be a lot, and might have big coordination overhead and risk. Then maybe managers and/or cross-team technical roles can help with that.
Or maybe the bulk of it is something easily parallelizable and straightforward, like systems integrations for many customers around a shared core that they don't much change. Or they're building something that they're sure fits a routine pattern, with little cross-team thinking to do (e.g., "simple CRUD, with Web backend, Web frontend, and iOS and Android apps"). If the work is that simple, but still voluminous, you don't need many people who aren't either typing code or determining&selling product.
With nothing coming up, I'm getting my biases confirmed that orange site remains unable to discuss the conditions of our jobs.
Until we can discuss power and control instead of just how we build things you're gonna have managers same way a prison has guards.
At a minimum, I’d limit it to two or three managers (12-13 reports). Adding EMs for each 3-4 person team is overkill, and a huge morale hit especially if they are outside hires.
All I can see is a massive 25% headcount increase that will result in ten people trying to implement [latest-job-I-had] structures and “show impact”. Seems like a recipe for disaster at a startup.
You will know this because the managers keep creating specs without consulting the IC’s and the amount of useless busy work and fake deadlines go up.
https://www.youtube.com/watch?v=7dcDuVyzb8Y
https://en.wikipedia.org/wiki/Coastline_paradox
Problems are fractal-like. Each section of a problem needs attention and management. Engineers are largely self-managing - we pay attention to the problem in front of us. There is still a need for coordination.
The article's topic is of common interest, and the quoted question's little details sound plausible/familiar. But I'm wondering whether the quote was contrived by the article author, to set up the article in a more engaging way?
Yes, I could just do a search but imo is also worth mention and listing the key points that the author wants to highlight about them. Otherwise everyone is taking away a different interpretation.
I worked on a team half that size with a single manager, our "lead developer" and it was remarkably smooth.
I ask what is keeping the VP of engineering so busy that they can't handle that work themselves?
:D
Yeah.
Instead you should notice the natural hierarchy that forms based on everyone's desire to build things. Some of your engineers are already deferring decisions to other engineers, and you just have to pick up on that as you develop a leveling system. That's where a hierarchy should come from if you insist on it.
It sounds like this is already what's going on given that you have clumps of 3-4 engineers around leads. And the author even says "hierarchy is a property of self organizing systems". So clearly this system is self organizing and working. But the author has no skill for designing organizations, and doesn't know what to do if he can't hire managers and make it look like what he's used to.
It sounds like a bad culture fit. The CEO needs a VP who isn't stamping out the same organization job after job, and can embrace and extend what is already working at this company.