Good work very much doesn't speak for itself, typically software problems represent management problems more than a lack of people trying to do good work. This is such a wild claim vs what I've seen that it makes me quite suspicious of this article and the one before it. It is a nice story that there is a high-productivity engineer who just does great work and everything steams to a happy end out because they are just that hyper-competent. But that is a myth, and probably more a tell that the narrator is misreading something about the situation.
This looks a lot like a manager-once-removed undermining a reporting manager by supporting an engineer to go rogue. I'd believe that the engineer is actually doing good work, but then that suggests there are problems in the management culture here. Either the blog writer doesn't know how to manage managers, or the middle manager has a competence problem. From that assumption I'm not totally surprised that there are problems in the resulting software that one unusually capable engineer can expose with a few weeks of rogue work.
Some people are obviously very intelligent and for people with enough technical abilities this can be spotted (e.g. because they churn out a large volume of high-quality code with almost zero defects). I have definitely seen this.
But I have also seen a colleague getting promoted that took thrice the scheduled time to deliver on a low-impact project, planning 2-3 long meetings a week, with about 8 people, discussing details for hours and hours (of course without writing anything down). When he went on leave for a few weeks, leaving a significant backlog of work and noting to our manager that "it's trivial to release", I actually managed to release it. At the end-of-year review he was praised for "deliviring such a complicated project", while the higher impact project I worked on and delivered in 1/3rd of the scheduled time was seen as a "simple project" because it got delivered without any hiccups.
Often it's also just a matter of "this guy states facts with confidence so it seems he knows what he's talking about" (even when he gets the facts wrong). At some point I just stopped correcting him because if we disagreed people would just assume I was wrong. In other words, being good at talking helps your career a lot.
Now, the wolf may benefit from hands off managment, but they will need leadership support. The author seems to have proposed a style of leadership centered around hands off managment and letting the wolf sink or swim. I would hope thismstyle of leadershio includes him holding a life support by the sidelines. (leadership != management)
There are definitely times when the best thing for upper management to do is stay the hell out the way, but this doesn't sound like it was obviously one of them.
The wolves analogy is simply wrong. Wolves work in packs.
Whether or not the natural world has such wolves, its a fictional archetype.
It is a particularly common theme in Japanese fiction, where the deviation from the social hierarchy requires a stong force of individual will. Interesting it is also common in Japanese technology breakthrough documentaries.
Ogami Itto - Lone wolf and cub is the first thing that comes to mind when the author says wolf.
Hint: think of the widespread expression used in terrorism debates: "Lone wolf". It's a self radicalized/motivated individual acting independently and alone.
I'm pretty sure the author doesn't think managers should create a culture that attracts and promotes terror attackers.
There are plenty of lone wolf developers, but you won’t find them in large teams. Or if you do, they’re dysfunctional. On their own, a lone wolf engineer is not generally able to complete large, important pieces of work. Some do! But they are exceptions.
You assume "lone wolf" types are "one trick ponies" who can't learn. You also assume the only interesting problem space for these people is technical/code.
The lone wolf has a big limitations in transitioning to scale: 1. managers do what the article suggested, and stay out their way. The lone wolf never gets the experience of being managed, so it is difficult to transition to manage others. 2. they don't get why others don't "get it". e,g the solution is clear , the code can be done in a day, the comprehensive system model in their head should be shared by everyone.... it takes time to understand that the average engineer works slow and steady on a small scale understanding.
I will suggest there is a lone wolf type manager too. This is not a productivity skill, but an adaptivity and mobility skill.
We've been taken over by PE and forced into a very strict Jira powered "Agile" with time tracking of how long cards are in progress, and all work needs to be planned pre-sprint.
I cannot even begin to explain the opportunity cost of all this to anyone with any sort of control. The art of building good software is continual improvement. Being able to improve something without planning it.
Whether or not you find this blurb interesting will probably determine whether or not this link is worth clicking to you.
Interesting enough people do jump around to build their skills.
That's the norm across all industries.
It's strange to intentionally try to place or manufacture mavericks within your org for (at least) two reasons:
1. They're emergent phenomena. It's probably more valuable on average to examine WHY someone skipping all of your processes is effective than it is to make the conditions right for someone to become that maverick. Theoretically anyone CAN be that person, but unless something is actively going wrong it probably won't happen.
2. Process exists because it makes your org more efficient. When you start building your teams around the idea of someone explicitly being the maverick(s), ask yourself: "Who exactly is going to reconcile all of this against the framework that the entire rest of the company runs on? Is the rest of that person's team relegated to damage control and cleanup crew, and is that actually more effective than having an equivalent number of mid-level performers all pulling in the same direction?"
In the world of tech, the alleged 10x-er often manifests itself as: Tech Debt, but at High Volume™!
What the original article described is an engineer who could not stand by and let a painful problem with an obvious solution not be solved. the key point of the so called wolf is the obviousness of the solution. it was. ot obvious to anyone else, and to anyone else it would have been a major investment. the 10x does not come from frantic coding, it comes from a comprehensive and unique understanding that translates to code quickly due to motivation and understanding.
Process does not make an org more efficient. it makes it more consistent. if the baseline efficiency is low, the consistency of an improved set of work practices will ofcourse improve efficiency.
What a process often does is overfitting. Overfitting to the most common buiness need, sometimes overfitting to the noisiest patholgies seen.
The problem with process overfitting is that it excludes efficient solutions for problems that don't fit the previous set of business needs, or are not at risk of the previous set of pathologies. sometimes the process has a good pressure valve for this, pull the andon cord. do some kaizen, fire up the CMM level 5 KPAs. but sometimes just applying bespoke judgment is better.
I have been the wolf he describes. I also have been the manager he describes who lets the wolf have space and stand up for themselves. i have also been the manager who creates process and worflows and alignment and blah blah to dampen the noise of individual agency.
tech debt is an orthogonal concern.
That is one hell of an assumption.
Nah. Process mostly exists because management doesn't have visibility into what engineering is doing, so they have to poke vertical holes through the org to know what everyone is up to.
Process is often pitched as improving coordination between teams, but that's more of a fringe benefit than the actual reason for process.
reading this post, i see that the founder (already in his 60s) is in many ways that "Wolf" as described here, and he's not great at managing the team around him.
any suggestions what structure/ team set up is working well in such a scenario?
Which is phrased as "not my job" for some reason.
That’s what I read.
10x people can be like one-shot LLMs, your request is for sure wildly underspecified and what you get is 90% determined by the "smoothing term" applied by not you. This is why the right amount and frequency of interation is needed.
I’ve gotten in the habit of not telling anyone about side efforts I’m working on until they’re done, and even then, I usually only tell the people who it might be of use to. I’ve been burned too many times by people trying to “help” or placing a lot of extra expectations and pressure on something. I don’t know if something will work until it works.
To someone actually running a company this looks like absolute corporate nonsense. Don’t categorize people like this, it’s demeaning and weird. Why can’t we just treat people like adults.
Instead of “Oh yea he’s a total 10xer wolf,” try “Yea Mark, has some good ideas for a test framework we should consider”.
What the hell is the incentive of the guy posting this to encourage and help The Wolf??? He’s just doing it out of good will? What does he get out of doing the right thing? No recognition. No bonus. Nothing. Yet he still does it.
I find this fascinating.
I won’t say it’s necessarily altruistic, as of course there could be a drive from inner machinations that we’d never be privy to.
(Sometimes the exposure of an article can be considered a reward, for those looking for ego inflation)
Even myself, I generally don’t leave comments unless I feel they’re going to be helpful or insightful to someone else. But I am also biased, as I do have a very strong affinity towards sharing information, so I greatly appreciate the effort artisans and those more knowledgeable than I go through to share such knowledge.
I got the recognition in my paycheck, which was the only place I wanted it. I prefer to work quietly behind the scenes. It wasn’t about any one project, but consistently delivering whatever it was I was delivering, without much input or interference.
Building a reputation of being wise?
i think i am an expertise on not getting into other people's business. can someone pay me?
Refreshing writing in a world of AI slop.
People wonder how to find great developers - what even IS a great developer in the world of AI, do they still exist or did AI level them all out with the playing field?
They’re still around - they can talk with you in great depth about software and how it works ……. same as ever.