Force the others to do less and less. I’ve seen this a million times, you have one dev going absolutely buck wild building a cathedral of abstractions that only they can understand. The rest of the devs struggle to implement basic features because, and I can’t overstate this enough because it’s true every time the code is a horribly written tightly coupled shoddily architected ball of chewing gum of twine spooky action at a distance with no isolation between components (usually because “DRY”) which is impossible to reason about unless you wrote it.
That dev becomes insanely productive in that codebase, the hero of to all managers, and everyone grinds to a halt gets demotivated because they can’t tackle anything ambitious.
I've been that person in a couple of projects, and it wasn't just because I went off and did my own thing. In at least one case the other people on the team were simply not very capable. As in... I've been building web applications for 25 years, and some of the other folks on the team came out of a bootcamp. And... they don't talk.
"Please, joe, let's connect and you can follow along with what I'm doing". Silence.
"Hey, dave, I see the PR is only a few days late. We still have some time left, can you write a test for it?"
I can get stuff done or I can 'corral and build up' the others, but I can't do both. If you want stuff done by a deadline, and you will not discipline the non-contributors (discipline doesn't mean fire, but it might mean "you have to come to these meetings and pair and follow along and document and write tests")... what's left?
FWIW, I know the difference between decent teams and non-decent teams. The non-decent ones were poorly managed, largely because management could not determine who was skilled and who wasn't. The decent teams I've been on were situations where I still generally had more overall experience (function of age) but the other less-experienced people will still good, engaged, and already contributing, and were measurably improving month to month.
It is one thing if they don't talk. It is even worse if they have no experience but thousands of suggestions that don't work. And you have to debunk every of these suggestions to management while keeping the progress going.
Often, if the work horse leaves, no one is able to keep the project going or rewrite the project from scratch. They should be able to do the latter if their suggestions are so great and they have been kept back. But they cannot.
I've got a colleague with similar history - 24+ years of tech experience - software, hardware, networking, etc. He's built systems that processed tens of millions of dollars, has single-handedly reworked legacy crap spaghetti in to testable, documented, well-functioning stuff. He came in to a company, then covid hit, and no one else on the team has anywhere near his level of experience. One guy graduated high school 18 months ago and loves kotlin. Every meeting is him trashing everything saying how cool kotlin in. He's rewritten existing working image processing libraries from C (which my colleague wrote and were working in production) in to Kotlin because "kotlin is faster". Guess what's broken now?
They have multiple meetings per week where people argue about what encryption library they should use for JWT token signing. Like... 5 people - none of whom have ever written encryption, nor written a JWT, arguing based on all the blog posts they've collectively read. That's just one example. This happens constantly. And the manager is of the view that "everyone's opinion matters, everyone should be heard". So the person with decades of experience who's already written (and written docs and tests) for the system they're trying to migrate to has to sit and listen to people who can not spell SQL talk about how 'bad' his system is because it's not in Kotlin.
That feels like an extreme example, but the more I talk with other folks, it doesn't seem to be that uncommon. Probably 15% or so of folks I connect with seem to have wildly imbalanced skill levels in their teams which are not acknowledged as such. It's fine for someone to have less experience. It's not fine to pretend that your 6 months of CS-101 homework is equivalent to someone else's decades of experience and working/documented/tested code.
in my experience the team needs critical mass of decent developers. And by 'decent' I don't mean all-knowing experienced beasts. I mean adequate devs with ability to listen and to be wrong. If team has it, better devs naturally get listened more and everyone gets chance to improve from it.
It doesn't mean that you just don't let juniors express their opinions (everyone should be able to talk), but the 'weight' of dev's opinion determines by his track of previous cases. And obviously every opinion comes with responsibility for the result. If you forced your approach you need to be able to deal with the results.
ah yeah, the mythical 10x dev. He, who has the permission and authority of management, to completely eviscerate any and all process to get whatever management wants done. I know a guy like that. He recently commit a massive code change without so much as a code review or a Jira ticket. 100s of new files. No one knows what the fuck they do. Wonder of wonders.
People still believe in 10x. People also believe in agile. It's amazing. If you're doing code reviews, proper unit tests, Jira micromanagement bullshit, it's an impossibility to get a 10x dev. We have WIP limits for fucks sake! WIP!! You literally cannot merge enough code to be a 10x without management favoritism.
> People still believe in 10x. People also believe in agile. It's amazing.
I'm not sure it's the same people who 'believe' in both, or... there's more nuance.
I 'believe' in the '10x' thing, because... at times, I've been the 10x person, by many metrics (bugs closed, docs written, tests written, lines of code, tickets addressed, etc). And yes, I'm aware that metrics like that can be gamed in some fashion. I never did, mostly because it's not really apparent at the time there's an output imbalance, but looking back at some numbers like those, I was the '10x' person on a team. It said as much or more about the rest of the team than it did me personally. I've been on other teams where I was decidedly not a 10x, and do have memories of being the -2x person a few times.
I 'believe' in agile, but only to the extent that it supports and enhances an already functioning team. I've seen it played out in a team from a few years ago, and it was as much of a 'well-oiled machine' as you could get while being a growing startup expanding and hiring a lot. That said, the skills and people together would have worked decently and productively together absent any formal process. Obviously just 'imo', but after decades in software, you sort of get a sense of skill levels and ability. We/they were a decent team, and would have been without 'agile' - that was some extra layers of process and ceremony which no doubt helped some people with visibility. That benefit was largely ancillary to the delivery of working software. One could argue the 'repeatability' and 'onboarding' benefits of 'agile', but I've not seen it be a huge boon in most teams I've seen adopt 'agile'.
I did such thing at least twice (unintentionally). Usually there is a quite simple way to overcome this - cultivate review process and some some of tech meetings, where your '10x dev' can talk about their approach and others have chance to criticise it. If other devs don't care enough to challenge 10x and just roll with it, well then they have it coming.
Force the others to do less and less. I’ve seen this a million times, you have one dev going absolutely buck wild building a cathedral of abstractions that only they can understand. The rest of the devs struggle to implement basic features because, and I can’t overstate this enough because it’s true every time the code is a horribly written tightly coupled shoddily architected ball of chewing gum of twine spooky action at a distance with no isolation between components (usually because “DRY”) which is impossible to reason about unless you wrote it.
That dev becomes insanely productive in that codebase, the hero of to all managers, and everyone grinds to a halt gets demotivated because they can’t tackle anything ambitious.