I learned c++ after c++20 and after several attempts to enjoy rust, c#, go, and C, I always come back to c++ as the most enjoyable language to develop.
I worked at a company that emulated Valve’s hyper-flat structure on their engineering team, with 1 manager having 50 direct reports. That’s as close to a management-less structure as I can think of, since your manager can’t attend meetings or do 1:1s anymore.
It’s great at the beginning. We started with a team of mostly self-motivated people and the lack of upward review made technical decision-making easy.
Eventually, you hire someone who is not self motivated. Also, some existing people get wise to the fact that no one will check up on them, and read Reddit for half the day.
About 4 months in, every team had 1 person like that. They had to work around them - one team can’t ever get designs cause the designer is checked out, one team’s backend work takes 1.5x as long as everyone else.
People say things to the underperformers, but there’s no teeth to anything, no one is anyone’s manager, so it’s just suggestions. They get ignored. Resentment builds into each individual team’s culture. Deadlines start slipping.
1 year in, non technical leadership is fed up. They don’t see benefits from the flat structure, and hire a new CTO and new middle management layer.
The new managers come in briefed with “the team is lazy.” The underperformers get pushed out, and have trouble finding work because their skills have absolutely atrophied. Any remaining high performers are permanently tarred with the reputation of the org from the flat structure days, and get micromanaged. To the new managers, they are kids who will misbehave the second they aren’t watched (which, in fairness, is kinda what happened at the organizational level when they weren’t watched.)
Sone good middle management providing timely oversight and feedback could’ve avoided the whole situation.
I have an opposite experience in one of my last gigs where hired management batted 50% mishire rate where people just didn’t do anything at all or worse shipped something that needn't to even exist of quality so bad that the project had to be scrapped. This was allowed to drag on for years.
Last I heard he eventually got rid of most of them when the company fell on hard times and had to do a bunch of layoffs. By that point the damage was already done and most good people have left or quite quit.
Imo it’s a common misconception that management doesn’t know who low performers are. In most cases they know even if the team is large, they just choose to ignore it for whatever political reasons
Out of curiosity, the OP’s language is “quality issues”, not “quality issue.” Why did you assume there wasn’t already a pattern of behavior implied there?
I'm not OP, but just by the way it was worded. It feels vague and grandstand-y. "I have noticed" is such a silly way to word what's happening here and it's hard not to imbue underlying meanings to it.
And then "can we talk about how we can address that." More vague, leading statements.
Speak to the facts. "The team / org had to roll back this release, the team does not think there is a process improvement that would have alleviated this problem, and the team relied on you to properly make this feature. Our exceptions of all team members is [...]"
Make it clear:
1. This is affecting the whole team (equally)
2. The team as a whole shares this perspective (it's not just the manager nitpicking)
3. There are consistent and vibrant standards that the entire team must adhere to
4. You are not meeting those standard(s) or necessary actions for success.
5. Offer what you think will fix the problem (if anything)
6. Make it clear this is their chance to agree/disagree
7. Continue to talk it out.
Honestly OP seems like a person who has struggled in his position as manager to properly speak to people, and instead of understanding why there was a struggle simply switched to more coded language.
Most people will see through it and react negatively.
I’m surprised by this and curious at the “team thinks” framing. What advantages do you see here?
I think I would much rather own the critique myself than say “the team thinks x.”
For context, I’d probably start with “what happened with that deployment that was rolled back?” and let them self-diagnose and share their perspective. By listening, I might learn there were extenuating issues, or I may see they are already aware of the issue.
If they’re able to critique their own work, I can agree and reinforce the whys. There’s no hostility and we can talk about what ideas we have for what we can do going forward.
If not, and I think we must do better, I can talk about my concerns, my expectations, and the consequences that I am worried about or frustrated by, and propose more prescriptive remedies.
>I’m surprised by this and curious at the “team thinks” framing. What advantages do you see here?
>I think I would much rather own the critique myself than say “the team thinks x.”
"the team thinks" means, well I went around and talked to everyone else about you before talking to you and they all say you suck! In short I don't think there would be an advantage to that.
> “I’ve noticed quality issues in your code recently that’s resulted in some rollbacks. Can we talk about how we can address that?”
That’s the first step in fixing the quality issues, not an end state. Reports don’t know what they don’t know, so step 1 is to get their ideas on how to fix quality issues.
reply