4 ms·
This article hits the nail on the head. Large teams need coordination, and coordination is a job that both takes up significant time and operates in a very diff
by jjk166 2y ago
This article hits the nail on the head. Large teams need coordination, and coordination is a job that both takes up significant time and operates in a very different manner from engineering work. Without having a few people specialize to do this work, you are forcing everyone else to compromise their engineering capacity to make up the difference.
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.
- jghn 2y agoThere are two separate tasks that need to be filled as a company starts go get beyond a small size. One is the coordination that you mention. The other is the day to day people management: making sure people are happy, understanding their hopes & desires, steering them towards growth, that sort of thing. What I've found over time is the implementation of this is often very inefficient. The coordination aspect is often a blend of the product organization and the engineering leadership, and in both cases I find there's too much authority pushed all the way down into individual scrum teams. There needs to be a cohesive product vision across all of the teams, and some set of people need to make sure they're all working on roughly the same things at roughly the same time. But that's about it. And you don't need a Product Manager, an Engineering Manager, and a Scrum Master for every set of 8-10 developers in order to make that happen. The people management portion is trickier. You *do* want to cap that at a ratio of about 1:8-10. But this role is traditionally associated with authority over things like on what their reports are working. Which exacerbates the point above.
- jacobyoder 2y ago"The other is the day to day people management: making sure people are happy, understanding their hopes & desires, steering them towards growth, that sort of thing." I've not been in many companies over the years - mostly worked independently - but in the companies I've been in, that was never on the cards. Ever. I don't doubt it exists, someplace, but never saw it in person. Bit of a shame, as it sounds nice.
- ChrisMarshallNY 2y agoWhen I was a manager (25 years), I worked that way. I’ve learned not to mention that, here, as it often results in fairly insulting attacks. I get the feeling that people don’t actually want to be managed that way.
- jacobyoder 2y agoThe few places I've worked in (some small, some largish - 2500+ people) - I've never worked anywhere more than 22 months, so ... there's not always a long time to develop relationships. But... coming in, there are already relationships, sometimes going back years, between people, and it's not easy breaking in to those, or fitting in at all. Without even trying (or specifically because they're not trying), well intentioned managers end up playing 'favorites' with some, which has seemed to exacerbate the issue of 'insiders' vs 'outsiders'.
- Supermancho 2y ago>> understanding their hopes & desires, steering them towards growth > people don’t actually want to be managed that way. That is not management, per se. It is a way to try to extract more value from employees outside of the business. More often than not, documentaion (ie quarterly reviews) is weaponized when cuts are being made. This is by desgn. If something is not a reliable tool for making their job better, engineers will choose to avoid wasting work time with it.
- keybored 2y agoI most often tell my manager that everything is fine.
- irrational 2y agoThe one good thing about excess management is when the economy takes a nose dive and the company is looking at doing layoffs, the excess managers are the first ones to go. I see them as shielding us developers from being laid off.
- freeopinion 2y agoIs this meant as some version of the broken window fallacy?
- Clubber 2y ago>the excess managers are the first ones to go Well, second to go, right after they have the task of laying off their team first.
- _uhtu 2y agoI'm my experience it's the exact opposite and they lay off ICs and leave the managers largely in place, making it worse.
- icedchai 2y agoI’ve seen this first hand. You wind up with “managers” that have 1 or 2 reports. What are they going all day? Going to meetings, it seems.
- em-bee 2y agotry seeing it from the other perspective: i am tasked with doing X, but i have to spend all day every day discussing X, and Y and Z with the higher ups and other teams, so that i have to get an assistant to actually do X.
- irrational 2y agoOver the past 24 years, I've been through six major layoffs and it is always the middle managers that go first. Recently my company went through a massive layoff. I don't know a single developer that was let go, but plenty of middle and upper managers were.