"The work was going to be successful without me; he’s a Wolf."
This is the biggest pile of crap I have ever heard. Projects and ideas being thought up by "wolves" that are incredible so often die because of lack of support from management. If I talked to a senior leader about an idea and they thought it was jaw droppingly good, and their only resulting action was to tell my boss, "oh yeah, that thing x is working is interesting", during a prescheduled meeting, I would never have faith in that person again.
Good work does not speak for itself, it needs a shitload of people to speak for it. The most capable "1000x" engineer in the world can never achieve anything if someone better at talking has the mic.
Have you never seen a good project or idea, that every engineer who saw it thought was awesome, die because it wasn't sold well to authority?
Authority may not have to sell or mandate for that person to get their work done but supporting good ideas and effective people is what authority should be doing.
No I haven’t. I’ve also deliberately avoided the types of places where that happens throughout my entire career.
Those types of ideas and projects have no need for the approval of authority. They are their own authority.
If a person in authority ends such a project or idea then the engineering culture at that organization is so completely broken the best path is to leave.
Respectfully, if that’s your mindset then I think the problem lies with you and not with the manager.
> good work does not speak for itself, it needs a shitload of people to speak for it
The absolute best way to get a shitload of people to speak for it is to get a shitload of people to use it. The best way to get them to use it is to make it _so good_ they use it naturally. Using the test framework from the article as an example - a period of time passed between the meeting and the work actually being recognised. The manager clearly gave the right feedback to keep working on it rather than “I’m not sure - your other thing is quite important too”. The sign of a good wolf is someone who can tell the difference between “this isn’t a good idea” and “there’s a process to be followed to find out if there’s a good idea”. Ignoring the first one is suicide, but ignoring the second one is what makes you succeed.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Someone comes with an idea? Smile and nod, because ideas are worth the paper they’re printed on. If someone comes to me with a prototype of something that I think is jaw droppinly good, depends on what it is. Internal tool? Ask them what their coworkers think of it. Internal facing admin/feature? Same. User facing feature? Ask them what they think the next step is. The goal is, as you put it, to get everyone on the team trying to tell me it’s a good idea not just one person.
>Respectfully, if that’s your mindset then I think the problem lies with you and not with the manager.
Adding "respectfully" to a sentence that says, "you are wrong and the problem is you", does not make it respectful. You could have simply left it out and your comment would have provided the same content. I'm fine being a kettle but don't pretend you are not a pot.
To get back on topic:
So you would:
- talk to team mates
- ask for next steps
And then what? You seem to want to avoid saying you would do anything because that goes against the premise of getting out of the way. But if an idea is brought to you that is jaw droppingly good, are you just going to ask some basic questions and do nothing? Or are you going to support it?
The point of saying respectfully was, just like my reply on how I’d handle the scenario you posed, to be gentle about it.
> and then what
You’re missing the point. My job as a manager isn’t to tell this person “wow, good job, let me go organise a presentation to <pointy haired boss> and we can get you 3 engineers working on it and get it added to your sprint work”.
> you seem to want to avoid saying you would do anything because that goes against the premise of getting out of the way.
Because getting out of the way _is the point_ and the action I’m taking. The “wolf” doesn’t need me to champion them, they need me to not be in the way.
> if an idea is brought to you that is jaw droppingly good are you just
You didn’t ask me what I’d do if they brought me something that I thought was dumb, misguided or not worth doing. And the answer to that is “get in the way”. I would ask them why they think this is a good idea, is it likely to benefit the team/org/product/business, is it a better thing to do than their current project, should we pitch it to the team.
As a manager your job isn’t to make your ICs successes happen, it’s to balance the project/company needs with the opportunities for the individuals. My job isn’t to champion someone’s project. I’m not a PM or an assistant to organise meeting.
If someone does something so good, then I won’t have a choice but to make sure that they have the space to keep doing it, but if they do something that’s as good as the 15 other things that are going on, I’ll get it prioritised with the rest of the stuff that’s going on.
> My job as a manager isn’t to tell this person “wow, good job, let me go organise a presentation to <pointy haired boss> and we can get you 3 engineers working on it and get it added to your sprint work”.
If you see something of extreme value it is not your job to allocate time and resources to it?
> Because getting out of the way _is the point_ and the action I’m taking. The “wolf” doesn’t need me to champion them, they need me to not be in the way.
And my point is in real life leaderships job is not to "get out of the way" of good ideas or people that get things done, it is to champion them.
> You didn’t ask me what I’d do if they brought me something that I thought was dumb, misguided or not worth doing. And the answer to that is “get in the way”. I would ask them why they think this is a good idea, is it likely to benefit the team/org/product/business, is it a better thing to do than their current project, should we pitch it to the team.
First, why would I ask? Is is that unexpected that you would "get in the way" of bad ideas? And let me get this straight, a bad idea comes your way, you do something, a good idea, you do nothing?
> As a manager your job isn’t to make your ICs successes happen, it’s to balance the project/company needs with the opportunities for the individuals. My job isn’t to champion someone’s project. I’m not a PM or an assistant to organise meeting.
That is your job! Their success is your companies success! I do not understand the line you are trying to draw here. Your job is not to champion "someones" project, it is (among other things) to champion amazing projects that you think are jaw droppingly good.
> If someone does something so good, then I won’t have a choice but to make sure that they have the space to keep doing it, but if they do something that’s as good as the 15 other things that are going on, I’ll get it prioritised with the rest of the stuff that’s going on.
So at the end of all of that, what it boils down to is that you would do something? We're going to call it "making space" but I feel like that means it's at the top of a list of things you are making sure happen yes?
If you want to keep cutting hairs you can, I will keep supporting people who do good work, no matter how self propelling they are. So far it's worked well for me and them but ymmv.
> If you see something of extreme value it is not your job to allocate time and resources to it?
Have you ever had the situation where a kid is good at something, and the parent latches onto it and stifles whatever good was coming out of it in the first place? IME with these people, the freedom _is_ the key to the success. The minute you start to bring other people in to help, they lose their baby, and their interest.
Also; The best person is already spending time and resources on it, and they did so without me needing to tell them to do so. They're doing fine without me.
> Is is that unexpected that you would "get in the way" of bad ideas? And let me get this straight, a bad idea comes your way, you do something, a good idea, you do nothing?
I dunno, I guess it depends on how you would expect me to respond to bad ideas. Even a bad idea can have some merit, and I always want my team to talk to me. Flat-out rejecting their misses isn't how I operate, as there's a reason they suggested the thing they did. Maybe they read about a new build tool, and we don't need a new build tool. Next week they might read about a new test approach, or a new game mechanic and we _do_ need one of those. The most important thing is that they talk to me next week, and the next week.
> So at the end of all of that, what it boils down to is that you would do something? We're going to call it "making space" but I feel like that means it's at the top of a list of things you are making sure happen yes?
I'm not really sure what your point is here, sorry. If you're trying to pin down "what exact action would you take in the hypothetical situation that a high performing engineer comes to you with an unspecified item of extreme value" from me, I think I'm destined to miss the mark for what you're looking for. I think I've been clear - my job is to let high/excellent performers do excellent things, and if they're already doing that then my job is to just let them keep doing it. The real hard part is getting everyone else to _not_ go on tangents because they think they're a wolf.
Like I said, you feel free to continue to do nothing to support good work done by good people and just "let it happen", I will continue to support it actively when I see it.
I think you forgot to follow these guidelines in your previous response. You came off very dismissive and went straight to "you're the problem" interpretation.
It's not the biggest pile of crap, I'd say it's... let's see... currently the 27th biggest, but that's subject to change since I have several meetings coming up this week.
lone wolf. maybe he missed the significance of lone in that phase when he heard it first and thought it could be dropped. That is my working assumption, it happens.
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.
I read those stereotypes as people phantasizing about being wild and free and a fierce (coding) biest, without actually knowing the wild. But it does have the effect on me to not being able to take it serious. If they don't even know basic facts about the animal they want to use as their metaphor, I expect way more to be wrong.
> Then there's the weak, pathetic, scrawny dweeb who sits on a bench dressed up in fancy robes, who passes judgment on big strong men in handcuffs daily and sends them to prison for years. He may have some level of power, but he's Beta as they come. He was placed in power by an Alpha.
Whoa that's a lot to unpack. Most pressingly, why do you need to point out that judges are not "at the top"? They perform a duty with a lot of responsibility. And that is that. No, where I live judges don't get appointed by "alphas".
> Not everyone can be at the top of the bell curve.
This is me nitpicking and I understand you mean to say that "the alphas" are special. But "at the top of the bell curve" is where everyone is! The freaks are found down in the tails. Exceptional people will be in the middle with everybody else on most metrics that show a normal distribution.
I'd say you'll have to look at metrics that show a not-normal distribution to cluster "the alphas" together. But then I don't really know how "being alpha" is defined. So maybe there is a metric where humans distribute in a bell curve and "the alphas" crowd out one side of it? Got an example?
Hint: think of the widespread expression used in terrorism debates: "Lone wolf". It's a self radicalized/motivated individual acting independently and alone.
Lone wolves are not happy animals, though. They are less successful in hunts, they can’t take down large prey at all. They don’t generally produce offspring. They’re an unfortunate effect of the social structure of wolves, where young males who cannot find a place in the pack are expelled.
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.
Whether or not the natural world has such wolves, its a well formed fictional archetype.
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.
you need to think in a different plane of isolation. i would say the pure machiavellian manager is a lone wolf in that the relationships hold no weight as interpersonal relationships, only as functional relationships - no different to how you would manage and integrate code.
> process has an unfortunate side effect of crushing innovation unintentionally
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.
> Being able to improve something without planning it.
There are very few professions we’d consider this acceptable. Implicit in this statement is the assumption that your time-value is only known by you (or free).
You certainly wouldn’t let your contractor improve things on your dime, unplanned, and unexplained. You might even fire them if you discovered they spent the day “refactoring” conduit instead of installing the pot lights you asked them for.
> You certainly wouldn’t let your contractor improve things on your dime
Where you have a contractor hired on a full-time basis with the intent to built the best house, or at least the most moated house, on the market so that all the people of the world come to live in your house, not someone else's, of course you would.
Your example worsens your position. I do not want my home builder going over budget and over time without telling me, only finding out after their “continual improvement” that I won’t be moving into my house. Worse, because they believe only they’re able to know what’s best.
In your fictional scenario of unlimited budget and time, sure I grant that an expert should work unguided.
> Worse, because they believe only they’re able to know what’s best.
Well, you certainly wouldn't hire a contractor if you knew better, would you? That would be pointless. The whole reason for hiring a contractor, instead of hiring the same laborers the contractor will go on to hire on you behalf anyway, is because the contractor brings the expertise you lack. If you can't trust them to know better than you, why bother? It just becomes an unnecessary expense and a waste of another person's time.
In practice what you’re suggesting is that you’ll let your home builder run over time and over budget. Intervention on your behalf would be an unnecessary expense and a waste of the builders time. They know better and that would be pointless.
Your position is employers are building the best house with the biggest moat to attract the entire world, with an assumed endless time and budget, and there are no bounds to be set with employees.
> you’re suggesting is that you’ll let your home builder run over time and over budget.
If you thought your home builder was going to run over time and budget, you wouldn't hire him in the first place. Those who can't find the necessary trust don't build homes. There are plenty of used homes out there to buy.
There will always be this back-and-forth discussion of planning vs not-planning. The agile idea in itself is quite simple: Inspect and Adapt. My firm belief is that everything else needs to be build around that.
> The agile idea in itself is quite simple: Inspect and Adapt.
Ish. Agile is, ultimately, about removing managers.
- Individuals over processes
- Working software over documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Developers on a team coming together to inspect and adapt, as you say, is a necessary function when you don't have a manager to do it for you. Hence why it is included in the Twelve Principles. Each of the twelve principles present a function that needs to be considered when you don't have a manager to do the work for you.
Of course, this point from the Twelve Principles is always Agile's sticking point: "Build projects around motivated individuals." In the real world, businesses don't want to hire motivated individuals that will drive projects, they want to hire many cheap, replaceable commodities along with just one motivated manager to whip them into shape. That is what that Jira stuff mentioned in the earlier comment is all about.
I think this quote snipe without the context doesn't really do the article justice. The post is interesting both intellectually and in that it's already clearly controversial. This quote standing by itself is mostly just confusing and imo takes away from the discussion.
A thing can become controversial exactly by appearing intellectually interesting on a superficial level but being dumb on a deep read. This splits the audience in the superficial readers and those with the time or expertise to read the piece with a deeper view. Both teams see the other as missing the point.
Google AI overview returned: “A ‘lone wolf’ is a wolf that has left its pack to find a new territory or mate, a natural dispersal behaviour crucial for genetic diversity.”
Interesting enough people do jump around to build their skills.
> All of these activities did occur because good work speaks for itself ...
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.
In my career I never received any recognition for well designed and executed projects. Even the ones that were high impact and widely praised by customers. I had much more luck with shitty/buggy stuff that should not have been released. Yes, I’m not perfect and suffer from brain farts sometimes. In such cases I could play a hero that worked whole nights/weekends to put down fires. And I got rewarded for that.
The point is the wolf does not need managment. He has built up a model in his head of the problem and solution space better that a team of 1x specialists. T expose it to "managment" , "oversight" and "accountability" is to destroy it, especially for the article that shows an innnovative solution to an organizational pain point. They may be poorly managed, but they may be well managed, either way the managment style likey does not match the particular problem and/or solution the wolf is adressing. One of the key premises of The Innnovators Dillema is that well managed companies are well managed in sweet spots of operation and struggle outside of that sweet spot.
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)
> One of the key premises of The Innnovators Dillema is that well managed companies are well managed in sweet spots of operation and struggle outside of that sweet spot.
This become apparently quickly to anyone thats worked in a rapidly scaling company, switched from megacorp to startup, or vice versa.
There are processes and controls that make a lot of sense when you have 100k employees that will literally strangle your company to death when you have only 20 employees. What process & controls you add over time, as you grow from 20->200->2000->20k is another question.
If you hire too many megacorp thinkers into your smallcorp too early, you will observe this friction. Likewise if you do grow to 2000 people and still have Bob the Wolf ordering servers on his personal Amex, you're probably gonna have some problems.
I’ve only done 20-200-2k, but I agree with you fully. At 2k, there’s a weird middle ground (IMO) where you actually need a handful of wolves to keep things nimble. They cause an awful lot of strife particularly to the people who are trying to grow from 2k -20k, but they are the thing that keeps the other people moving in the right direction until you’re big enough that it’s just not tolerable anymore.
At that point you get an office of the CTO to be formal wolves!
you need flexible organziational glue logic at this scale, and the so called wolve can help, so this office of wolves can be the ones patch wires and to reprogram the organzational FPGA's or rewrite the organizational routing table (or what ever it is distributed software people use as glue logic...)
If some dev rolls up to work and claimed that "I don't need to do anything to be a high value programmer" because he has mastered the zen of not getting in the way of good code, is anyone going to buy that? It is a lie for those who were born yesterday by someone justifying not being very good at their job. Ditto when a manager says it, even if they are important enough nobody is going to call them out directly. Under no circumstances is what the narrator describes a good response. All managers have limitations so sure maybe it is the best response he can muster and he's still a great manager otherwise, fair enough, but the story then isn't that wolves are amazing, but that the writer has a massive blind spot, it hasn't caused a big enough problem that they had to fix it and they've settled on tonic immobility as a strategy because they haven't figured out the productive action.
The situation is an employee is doing great things. Employees manager-once-removed agrees. The middle manager is trying to stop the employee. That isn't a story where the key is an amazing employee. It is a story where manager-once-removed doesn't know how to manage the middle manager, and the middle manager is either being undermined, is incompetent or both.
That is reading a lot into 2 blog posts, so I wouldn't go down on that ship. Maybe there are a lot of extenuating circumstances that aren't being written down. But the most likely fit of the facts in a software business is that management are flailing. Which is cool, management sometimes flails. But the focus should be on improving managers so they can do their job properly, not pushing the stress of dealing with their flailing down to the employees. It is unfair and stressful for the lower tiers of the org tree, and flailing management can get a lot of people fired.
Interesting. I read the article and situation completely differently.
I suspect the author has failed to explain enough to get readers outside of their preconceptions based on their experience.
In particular I think management and leadership have been conflated in most interpretations - his inaction is a form of leadership to promote personal growth for line manager and IC. The absence of management is the application of this leadership.
> This looks a lot like a manager-once-removed undermining a reporting manager by supporting an engineer to go rogue.
Yes, and this is unfortunately the best move in many situations given how hard it is to fire people.
The ideal thing to do is fire the incompetent manager who is a tax on their team rather than a multiplier.
That unburdens the highly competent engineers on their team to do good work.
However, that might not be possible or even a good idea.
A failed hire might reflect badly on the upper manager, or prevent them from hiring a replacement.
It might require a lengthy performance improvement plan, which means you have a burdened team for that whole duration.
It's often easier to de-claw the bad manager, and take back on their responsibilities yourself.
Not ideal, but the best of a bad situation.
> This looks a lot like a manager-once-removed undermining a reporting manager by supporting an engineer to go rogue.
The second red flag in all of this is that an engineer doing good work on their own is labeled "rogue".
Management's job is to make people productive, if they can't realize that the best configuration for their team involves some individuals working largely separate from the managers own mediocre day-to-day ceremonies/projects, then they aren't doing their job.
People that don't need to be managed are the best kind of people, if you can't spot them and leverage them, get out of management.
Yep. Even the details provided suggest that (i) the "wolf" explicitly asked for a level of support from upper management that wasn't offered and (ii) when others eventually became aware of the testing framework, they were able to improve it. Neither of the two details provided vindicate the author's self-congratulation on spotting the wolf and choosing to keep it quiet.
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.
100% agree. You don’t have to let an engineer go rogue to get stuff built that isn’t a new feature.
I don’t manage managers, but do manage a team of 15. I try to be clear that part of my job is giving them time to improve their jobs. When one has a complaint or suggestion, I ask them to put it on paper so I can get it into our backlog. I will gladly prioritize something that will have a positive impact across multiple engineers.
Test and build are things that fall through the cracks and working on them can get outright hostility from management and other team members in some places, indifference in others.
At one place I worked nobody could give me a reliable build procedure, I settled in on one that was 40 min and worked reliably. I complained at every team meeting about the slow build and nobody cared. I put in a ticket for the slow build and was asked “how does this help the end user?” and my answer was “if my build was faster the end user would have had the product six months ago”
Where I am now I have a “maintenance droid” that automates a mildly polyglot build and when it runs into trouble it applies various levels of cleaning and every few months I run into some problem where it gets different results from my supervisor and/or the CI system and these days it always turns out to be right.
I really enjoyed reading this story. I personally believe in subscribing to self concordant goals and working altruistically to cultivate the good Society.
I also agree with the statement above. But what the author leaves out is that good work that speaks for itself can also create insecurity for those that are in an intense competition for recognition.
People’s reality is entirely subjective, where even well intentioned people may reject ideas that don’t contribute to their interpretation of reality.
In my personal experience, when I came up with and executed ideas that made substantial impact and outperformed others, I wasn’t given proper recognition, mostly due to others insecurity and politics to support a subjective reality that everyone can agree to. Particularly leadership who were non-technical sycophants that cared more to please their master than to do the right thing for the company or even themselves.
Humans are complicated social creatures where ethics and altruism often lose to filling personal voids.
I do believe in the concept of the wolf, someone who has reached self transcendence that doesn’t need to subscribe to a subjective shared reality and can achieve personal satisfaction through mastery by exercising their will to do something they believe is intrinsically meaningful.
I disagree. Ideas don’t speak, and work doesn’t speak. People do. Being a 10x engineer isn’t just about having great ideas, it’s about having great impact.
Sometimes I hear ICs say with some pride that “I’m not interested in playing office politics”. I promise you they will lose out to the engineers who are able to self advocate, and coalition-build.
You look at gaining recognition for good ideas as a zero sum game that requires self promotion.
If you develop a good original idea that solves a problem and it gets implemented, you have created positive impact without self promotion. If you're not concerned with public perception, then the discussion stops right here.
Someone can take credit for your idea to gain perception that it was their original idea. But in the end, someone who self promotes that can't come up with original ideas will eventually lose their believability factor and will be unable to promote themselves much further.
The crux is in the “and it gets implemented” part. Teams have a limited bandwidth, so what gets implemented absolutely is a zero sum game, that’s why backlog prioritization exists. In order for your idea to get implemented, you have to advocate for it, and convince others to do the same.
Writing great code and delivering useful side-projects can make you a 2-5x engineer. If you want to be a 10x engineer, you have to scale your impact beyond what you can do alone
Edit: maybe your great idea is actually something that you can implement on your own, such as a test suite or a tool. You still need to change other peoples behavior. You need to convince people to try it.
I'm speaking specifically to the example given by the author.
He was approached by an engineer that saw a critical flaw in the software that goes beyond simple "backlog prioritization".
The engineer "quietly" escalated his concerns by showing a thoughtful approach to fixing a global problem that goes beyond his assignment, that if left unsolved can cause problems for everyone.
Given the managers experience, he understood the engineers intrinsic motivation to do good (not biased in self promotion) and believed that the idea would speak for itself and gain the confidence of other engineers, which it did.
This approach is antithetical to what you described. The engineer did not advocate for himself or his idea, he identified a bigger problem that was far more important than his assignment. He brought the idea to leadership out of concern, to deal with conflicting priorities above him. He was not caught up in politics or transactional thinking.
The message the author is trying to convey, people with significant talent that have higher order values, are not concerned with labels such as "wanting to be a 10x engineer". They just focus on what they believe are the most important problems that they can solve that benefits everyone, not just themselves.
These people are truly rare and your argument that playing politics is necessary to promote ideas, proves how rare it is to come across these people.
This is an incredibly cringe article. From using “wolf” in a completely forced way, to full quoting a conversation that seemingly only misses “and that testing framework’s name? Albert Einstein”.
Man I'm glad someone said this. Incredibly cringe and unnecessary using the whole wolf analogy for, essentially, "someone who's good at their job". Gives off vibes of the whole "alpha/high value male" thing going on in social media.
I have to admit reading heroic stories like these is a guilty pleasure of mine. It's ridiculous, but strangely inspiring in a completely unrealistic way.
The interesting thing about the "test and build" kind of work that this "wolf" was working on is that this is team-oriented behavior that people in teams usually think the team won't let them do. It takes a kind of rugged individualism for somebody to buck the team to do this teamwork!
On the other hand, my belief is that the main responsibility of engineering management is to be sure that stupid little details like build and test are taken care of. When they hear that "my build takes too long" or "I can't figure out how to write tests for X" they should take it as seriously as "I have cancer". If your "team" can't give a new programmer a checklist (or coaching) that gets them up and running quickly, it isn't really a team!
Instead of this, most engineering managers are doing something else which might seem to have to value their managers but from my viewpoint of a developer is a complete waste of time. If instead of telling developers to suck it up about little annoyances they took responsibility for clearing them away they could 2x or 3x the whole team and not waste time chasing hypothetical 10x developers.
This. And the reason this is relevant today is because an excellent build and test system multiplies the effectiveness of coding agents which multiply again the effectiveness of next level engineers.
There aren’t many other things I can think of that have such a huge positive impact on the productivity of an engineering team.
I have experienced some companies trying to tame wolves with agile type systems with poor results. I have seen wolves getting sick in cages, i have been seen wolves accomplishing amazing feats and being sidelined for not being team players by mediocre leadership because the leadership did not get recognition.
Early in my career I would build something I thought was useful, deploy it, meet with people within the company to get people to start using it. A lot of effort for something that would have a positive impact. My manager would schedule a meeting with me, and with a look of panic open with, “why didn’t you tell me about this or why did you do this?”. I understand now that before you start something, you need to decide who you are going to give credit to, and that person needs to be made aware that they will get credit for the project. Ideally your boss’s boss’s boss. Corporate caché only exist insofar as leadership allows it to exist, you gotta play the game. Pawns don’t get to take the glory for themselves.
Were you doing it on your own time? From your described “a lot of effort,” I assume it was not but please correct me if I’m wrong.
If you’re being paid for your time by someone else, it’s fair to notify them how you plan to use a significant chunk of that money before you do it. Unless of course you were employed to _not_ do that.
I am not suggesting explaining a day or two of work. But it sounds like you’re talking weeks.
It would be like if I was expected to deliver A by the end of the quarter and instead I delivered A + B. The value gain from B was more than A. Your manager (and hopefully higher up the org) better know about B, or they will attack it as a threat.
Also, I’m not being paid for my time, I’m being paid to do a job. “Trading your time for money” is one of the most self defeating views on work you can have. It reduces you from a worker with agency to a detached prostitue, and is harmful to both the employer and employee.
> i have been seen wolves accomplishing amazing feats and being sidelined for not being team players by mediocre leadership because the leadership did not get recognition.
The argument seems to be: don't promote/support good ideas or projects because if they're good they'll likely succeed without you, and then the initiator will be slightly more confident.
The message is that process is there to extract value from people with average skills and motivation. When you find someone very skilled and self motivated doing the right thing, don't let process hamper their way.
I wish the article actually said that in plain words instead of trying to foist it into that peculiar "wolf" analogy (or whatever it's trying to do). I found the article kind of confusing. Thanks for spelling it out.
I thought the message is “you might really want to find and encourage and promote and support your best programming talent though overt action, but such overt action might in fact have the inverse unintended outcome, often best to ensure you know such people are in the team and ensure traditional management does not get in their way or piss them off with traditional corporate thinking, which has zero idea what great programming talent looks like or is motivated by.”
Same. New ideas are like starting a fire. Piling too much on top or blowing too hard will stop it. You (together, however distributed across roles) do have to assess if you can handle one more fire, if it comes on top, replaces an old one etc. Getting to this decision in your specific setup is the tough and important part.
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.
This is how I took it, and what I lived through. Both the supportive boss that let me do my thing without getting in the way, and those who tried to manage everything and make me shut down.
But did OP actually suggest their job is to “ensure traditional management does not get in their way”? I’m almost certain their point was not to interfere even at that level, which is why they didn’t hype it up the chain and let it land on its own.
Part of not hyping it up the chain is also that a lot of these projects are experiments. They may work, they may not, and some pivots may be required along the way. As soon as something is hyped to leadership, now there are feature lists, timelines, and expectations. All room for creativity and experimentation are gone.
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.
I don't know that I care much for the mythologization of effective developers as "Wolves" and "10x-ers" which are this decade's equivalent of Ninja / Rockstar / Guru, but a similar less tech-centric version of that is just the concept of the "Maverick" within any organization and the parallels aren't too far regardless of the industry you're talking about. Outsized impact in undersold roles with a lot of heavy swinging soft power earned through merit.
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.
I don't think the concepts are as unrelated as you're suggesting, they both tend to operate on the premise that they can be more effective than others because they're able to bypass the lanes that everyone else is taking.
And you are highlighting exactly what I'm pointing out, which is that if your process is so rigid and overfit that your org is regularly missing out on obvious solutions then the thing you should be solving is the process rather than trying to create "wolves". The concept of a team needing someone that consistently "breaks the rules" so that you can do the right thing is a glaring red flag that you have a bigger picture problem.
my point was the efficiency from bypassing/cutting corners is different to the efficiency from understanding and synthesizing problems and solutions differently.
the "obviousness" in the first is seen by everyone, the "obviousness" in the second is seen only by people able to break out of a collective mindset and unground their thought processes.
in the first the "wolf" is missing some obvious things, in particular the negative externality of their action. in the second the "wolf" is generally working on maximising the positive externality by generalizing problem space and solution space outside of the conventional fitting.
> Process exists because it makes your org more efficient
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.
People like this can be a huge help, but they can also cause real damage. I've seen it go both ways: someone can deliver a ton of value one year and create serious problems the next.
This article's description gives me pause because it reads as non-collaborative and needlessly abrasive. In my experience, people who bulldoze process and relationships are almost always a long-term net negative, even if they can ship something short-term at 10x speed.
If you are 10x, there's still a ceiling on what you can do. If you're leading a team of 50 and you can help each person get to 1.2x, you've created the same effective lift, while strengthening the team instead of burning it down.
And that's a durable change which doesn't go away if the "Wolf" leaves or has a down year.
Most wolves I know of are impossible to work with and a barrier to company scaling. Which eventually leads to à net lots of growth opportunity.
Worse I’ve experienced as dev around wolves is the typical tendency of being marginalised only to be later proven true about things. To me this is super toxic so duck them wolves really, they be lone very often.
i'm supporting a small org with their decision making and feedback systems.
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?
Well... As one of those supposed 10x engineers, that's not quite true
It's true that the intellectual satisfaction is my main driver, but I'm also quite vain. Appreciation and respect (especially from peers, who cares about an All Hands) add juice to the battery.
A feel good article where you can choose to self insert as the wolf or the wise manager who knew to be “hands off”.
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”.
Hard agree. Nothing more offputting than being labeled and categorized like the corporate overlords are playing AeO II and I’m a "resource" to be acquired, harvested, used and/or discarded.
> “How do I become a Wolf?” Wolves don’t know they are wolves. They don’t care about the label or the unique conditions that surround them. Wolves are the result of the work, not asking the question. Wolves don’t ask to be wolves; they are.
Answering the question a bit more directly, you do it by stopping thinking about being a Wolf, and by putting what seems like an unreasonable amount of effort into getting shit done well. There's some natural talent involved here, but most of it is just caring enough to learn and do whatever is needed to be great. And then, the more you run, the faster you get.
This is goddamn terrible advice. You’re rolling a dice to see if the great work ends up making it.
Have we not learned the lesson of bell labs? 90% of the time the great work doesn’t make it by itself. It takes leadership to carve a path for it to emerge and actually flourish.
I swear, there are like two influential things on the internet that have completely wrecked the practice of engineering management:
While I'm all for empowering your best contributors, I'll repeat what I say every time I hear someone mythologize about "10x engineers": if you want a 10x engineer, you need to pay a 10x salary.
When companies say they want a 10x engineer, what they really mean is that they want an engineer who will work for 10x less than they're worth.
I generally don’t take these articles too seriously but a question has been popping up in my mind.
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.
Some people genuinely want to help others, without any immediately visible reward.
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 had a boss like this. He didn’t stand me up in front of everyone to show stuff off, but each year when it came time for raises and bonuses, he always took care of me. But those raises were never conditional or tied to whatever project I was working on.
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.
I find it fascinating that people find it fascinating that people just want to do right by others. I get that this is in the context of a workplace, and there is always some level of competition between people, but personally, I never gave that more weight than being happy and feeling good about how I treat others.
I've got to admit to being somewhat disappointed that the "wolf" in question wasn't the character from the film 'Pulp Fiction', because - at least in my mind - it's an apt example for Rand's original article.
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.
He posts his articles to his socials,⁽¹⁾ along with the occasional quip like “Your life is going to be full of people sounding like they know what they’re talking about.” and “Your three-day response time to critical communications tells me exactly what I need to know.” and “You're either getting stuff done or talking about getting stuff done.”
Just in from 2014, when the original article referenced in the first line of this one was written, opening 'You've heard of the 10x engineer, I'm here to tell you about the Wolf'?
It's more completing book length works that are published by a publishing house. Therefore subjected to content editing, copy editing and finding an audience. Quite a complex multi-stage process.
What criteria are you using to evaluate writing? Can you point to an example that you think is good writing?
(I say all this as someone who is still working on stringing words into sentences)
His logic for staying "out of the way" is:
"The work was going to be successful without me; he’s a Wolf."
This is the biggest pile of crap I have ever heard. Projects and ideas being thought up by "wolves" that are incredible so often die because of lack of support from management. If I talked to a senior leader about an idea and they thought it was jaw droppingly good, and their only resulting action was to tell my boss, "oh yeah, that thing x is working is interesting", during a prescheduled meeting, I would never have faith in that person again.
Good work does not speak for itself, it needs a shitload of people to speak for it. The most capable "1000x" engineer in the world can never achieve anything if someone better at talking has the mic.
edit: spelling
The wolf and Rands are next level.
> Good work does not speak for itself, it needs a shitload of people to speak for it.
Good work does speak for itself. The work speaks directly to other like minded engineers who "get it" and spread the word.
Nobody in authority needs to do any selling or mandating for the kind of work and the kind of person Rands is talking about here.
Have you never seen a good project or idea, that every engineer who saw it thought was awesome, die because it wasn't sold well to authority?
Authority may not have to sell or mandate for that person to get their work done but supporting good ideas and effective people is what authority should be doing.
No I haven’t. I’ve also deliberately avoided the types of places where that happens throughout my entire career.
Those types of ideas and projects have no need for the approval of authority. They are their own authority.
If a person in authority ends such a project or idea then the engineering culture at that organization is so completely broken the best path is to leave.
Understood, I think we are coming from different environments.
Edit: I wish I had access to ones more like yours.
I’ve had the pleasure of managing a wolf.
Respectfully, if that’s your mindset then I think the problem lies with you and not with the manager.
> good work does not speak for itself, it needs a shitload of people to speak for it
The absolute best way to get a shitload of people to speak for it is to get a shitload of people to use it. The best way to get them to use it is to make it _so good_ they use it naturally. Using the test framework from the article as an example - a period of time passed between the meeting and the work actually being recognised. The manager clearly gave the right feedback to keep working on it rather than “I’m not sure - your other thing is quite important too”. The sign of a good wolf is someone who can tell the difference between “this isn’t a good idea” and “there’s a process to be followed to find out if there’s a good idea”. Ignoring the first one is suicide, but ignoring the second one is what makes you succeed.
The best wolves I know define their own process to find out if the idea is good and ignore all externally imposed processes that get in their way.
[flagged]
No need to be like that. https://news.ycombinator.com/newsguidelines.html
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Someone comes with an idea? Smile and nod, because ideas are worth the paper they’re printed on. If someone comes to me with a prototype of something that I think is jaw droppinly good, depends on what it is. Internal tool? Ask them what their coworkers think of it. Internal facing admin/feature? Same. User facing feature? Ask them what they think the next step is. The goal is, as you put it, to get everyone on the team trying to tell me it’s a good idea not just one person.
Your initial response included this:
>Respectfully, if that’s your mindset then I think the problem lies with you and not with the manager.
Adding "respectfully" to a sentence that says, "you are wrong and the problem is you", does not make it respectful. You could have simply left it out and your comment would have provided the same content. I'm fine being a kettle but don't pretend you are not a pot.
To get back on topic:
So you would:
- talk to team mates
- ask for next steps
And then what? You seem to want to avoid saying you would do anything because that goes against the premise of getting out of the way. But if an idea is brought to you that is jaw droppingly good, are you just going to ask some basic questions and do nothing? Or are you going to support it?
edit: for formatting
The point of saying respectfully was, just like my reply on how I’d handle the scenario you posed, to be gentle about it.
> and then what
You’re missing the point. My job as a manager isn’t to tell this person “wow, good job, let me go organise a presentation to <pointy haired boss> and we can get you 3 engineers working on it and get it added to your sprint work”.
> you seem to want to avoid saying you would do anything because that goes against the premise of getting out of the way.
Because getting out of the way _is the point_ and the action I’m taking. The “wolf” doesn’t need me to champion them, they need me to not be in the way.
> if an idea is brought to you that is jaw droppingly good are you just
You didn’t ask me what I’d do if they brought me something that I thought was dumb, misguided or not worth doing. And the answer to that is “get in the way”. I would ask them why they think this is a good idea, is it likely to benefit the team/org/product/business, is it a better thing to do than their current project, should we pitch it to the team.
As a manager your job isn’t to make your ICs successes happen, it’s to balance the project/company needs with the opportunities for the individuals. My job isn’t to champion someone’s project. I’m not a PM or an assistant to organise meeting.
If someone does something so good, then I won’t have a choice but to make sure that they have the space to keep doing it, but if they do something that’s as good as the 15 other things that are going on, I’ll get it prioritised with the rest of the stuff that’s going on.
> You’re missing the point.
One of us is
> My job as a manager isn’t to tell this person “wow, good job, let me go organise a presentation to <pointy haired boss> and we can get you 3 engineers working on it and get it added to your sprint work”.
If you see something of extreme value it is not your job to allocate time and resources to it?
> Because getting out of the way _is the point_ and the action I’m taking. The “wolf” doesn’t need me to champion them, they need me to not be in the way.
And my point is in real life leaderships job is not to "get out of the way" of good ideas or people that get things done, it is to champion them.
> You didn’t ask me what I’d do if they brought me something that I thought was dumb, misguided or not worth doing. And the answer to that is “get in the way”. I would ask them why they think this is a good idea, is it likely to benefit the team/org/product/business, is it a better thing to do than their current project, should we pitch it to the team.
First, why would I ask? Is is that unexpected that you would "get in the way" of bad ideas? And let me get this straight, a bad idea comes your way, you do something, a good idea, you do nothing?
> As a manager your job isn’t to make your ICs successes happen, it’s to balance the project/company needs with the opportunities for the individuals. My job isn’t to champion someone’s project. I’m not a PM or an assistant to organise meeting.
That is your job! Their success is your companies success! I do not understand the line you are trying to draw here. Your job is not to champion "someones" project, it is (among other things) to champion amazing projects that you think are jaw droppingly good.
> If someone does something so good, then I won’t have a choice but to make sure that they have the space to keep doing it, but if they do something that’s as good as the 15 other things that are going on, I’ll get it prioritised with the rest of the stuff that’s going on.
So at the end of all of that, what it boils down to is that you would do something? We're going to call it "making space" but I feel like that means it's at the top of a list of things you are making sure happen yes?
If you want to keep cutting hairs you can, I will keep supporting people who do good work, no matter how self propelling they are. So far it's worked well for me and them but ymmv.
> If you see something of extreme value it is not your job to allocate time and resources to it?
Have you ever had the situation where a kid is good at something, and the parent latches onto it and stifles whatever good was coming out of it in the first place? IME with these people, the freedom _is_ the key to the success. The minute you start to bring other people in to help, they lose their baby, and their interest.
Also; The best person is already spending time and resources on it, and they did so without me needing to tell them to do so. They're doing fine without me.
> Is is that unexpected that you would "get in the way" of bad ideas? And let me get this straight, a bad idea comes your way, you do something, a good idea, you do nothing?
I dunno, I guess it depends on how you would expect me to respond to bad ideas. Even a bad idea can have some merit, and I always want my team to talk to me. Flat-out rejecting their misses isn't how I operate, as there's a reason they suggested the thing they did. Maybe they read about a new build tool, and we don't need a new build tool. Next week they might read about a new test approach, or a new game mechanic and we _do_ need one of those. The most important thing is that they talk to me next week, and the next week.
> So at the end of all of that, what it boils down to is that you would do something? We're going to call it "making space" but I feel like that means it's at the top of a list of things you are making sure happen yes?
I'm not really sure what your point is here, sorry. If you're trying to pin down "what exact action would you take in the hypothetical situation that a high performing engineer comes to you with an unspecified item of extreme value" from me, I think I'm destined to miss the mark for what you're looking for. I think I've been clear - my job is to let high/excellent performers do excellent things, and if they're already doing that then my job is to just let them keep doing it. The real hard part is getting everyone else to _not_ go on tangents because they think they're a wolf.
Like I said, you feel free to continue to do nothing to support good work done by good people and just "let it happen", I will continue to support it actively when I see it.
I think you forgot to follow these guidelines in your previous response. You came off very dismissive and went straight to "you're the problem" interpretation.
Re-reading, you're right. I meant to suggest that the comment I replied to should look inwards.
It's not the biggest pile of crap, I'd say it's... let's see... currently the 27th biggest, but that's subject to change since I have several meetings coming up this week.
> Wolves don’t care if they are seen or not. Wolves are entirely focused on the self-selected essential project in front of them
The wolves analogy is simply wrong. Wolves work in packs.
lone wolf. maybe he missed the significance of lone in that phase when he heard it first and thought it could be dropped. That is my working assumption, it happens.
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.
I read those stereotypes as people phantasizing about being wild and free and a fierce (coding) biest, without actually knowing the wild. But it does have the effect on me to not being able to take it serious. If they don't even know basic facts about the animal they want to use as their metaphor, I expect way more to be wrong.
I think we can simply replace "wolf" with "alpha" and the analogy makes much more sense.
I mean that in the worst possible way.
Especially since the whole "alpha" thing has been debunked, mostly.
Interestingly, it came out from putting random individuals in anhigh-stress prison environment.
"Alpha" in the wild is really dad and mom...
[dead]
> Then there's the weak, pathetic, scrawny dweeb who sits on a bench dressed up in fancy robes, who passes judgment on big strong men in handcuffs daily and sends them to prison for years. He may have some level of power, but he's Beta as they come. He was placed in power by an Alpha.
Whoa that's a lot to unpack. Most pressingly, why do you need to point out that judges are not "at the top"? They perform a duty with a lot of responsibility. And that is that. No, where I live judges don't get appointed by "alphas".
> Not everyone can be at the top of the bell curve.
This is me nitpicking and I understand you mean to say that "the alphas" are special. But "at the top of the bell curve" is where everyone is! The freaks are found down in the tails. Exceptional people will be in the middle with everybody else on most metrics that show a normal distribution.
I'd say you'll have to look at metrics that show a not-normal distribution to cluster "the alphas" together. But then I don't really know how "being alpha" is defined. So maybe there is a metric where humans distribute in a bell curve and "the alphas" crowd out one side of it? Got an example?
[dead]
Who is the "establishment"? All power is granted and can be withdrawn. But the brick will not know.
Not all wolves work in packs.
Hint: think of the widespread expression used in terrorism debates: "Lone wolf". It's a self radicalized/motivated individual acting independently and alone.
Lone wolves are not happy animals, though. They are less successful in hunts, they can’t take down large prey at all. They don’t generally produce offspring. They’re an unfortunate effect of the social structure of wolves, where young males who cannot find a place in the pack are expelled.
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.
Whether or not the natural world has such wolves, its a well formed fictional archetype.
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.
A ”lone wolf” with a manager is a contradiction in terms.
you need to think in a different plane of isolation. i would say the pure machiavellian manager is a lone wolf in that the relationships hold no weight as interpersonal relationships, only as functional relationships - no different to how you would manage and integrate code.
It’s clear that the discussion has stretched the metaphor of wolves far beyond its breaking point.
The point was that developers (or indeed people in general) do not work the way wolves do, and I’m not reading great arguments to the contrary.
> Hint: think of the widespread expression used in terrorism debates: "Lone wolf"
I'm pretty sure the author doesn't think managers should create a culture that attracts and promotes terror attackers.
[dead]
> process has an unfortunate side effect of crushing innovation unintentionally
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.
> Being able to improve something without planning it.
There are very few professions we’d consider this acceptable. Implicit in this statement is the assumption that your time-value is only known by you (or free).
You certainly wouldn’t let your contractor improve things on your dime, unplanned, and unexplained. You might even fire them if you discovered they spent the day “refactoring” conduit instead of installing the pot lights you asked them for.
> You certainly wouldn’t let your contractor improve things on your dime
Where you have a contractor hired on a full-time basis with the intent to built the best house, or at least the most moated house, on the market so that all the people of the world come to live in your house, not someone else's, of course you would.
Your example worsens your position. I do not want my home builder going over budget and over time without telling me, only finding out after their “continual improvement” that I won’t be moving into my house. Worse, because they believe only they’re able to know what’s best.
In your fictional scenario of unlimited budget and time, sure I grant that an expert should work unguided.
> Your example worsens your position.
Worsens what position?
> Worse, because they believe only they’re able to know what’s best.
Well, you certainly wouldn't hire a contractor if you knew better, would you? That would be pointless. The whole reason for hiring a contractor, instead of hiring the same laborers the contractor will go on to hire on you behalf anyway, is because the contractor brings the expertise you lack. If you can't trust them to know better than you, why bother? It just becomes an unnecessary expense and a waste of another person's time.
In practice what you’re suggesting is that you’ll let your home builder run over time and over budget. Intervention on your behalf would be an unnecessary expense and a waste of the builders time. They know better and that would be pointless.
Your position is employers are building the best house with the biggest moat to attract the entire world, with an assumed endless time and budget, and there are no bounds to be set with employees.
> you’re suggesting is that you’ll let your home builder run over time and over budget.
If you thought your home builder was going to run over time and budget, you wouldn't hire him in the first place. Those who can't find the necessary trust don't build homes. There are plenty of used homes out there to buy.
There will always be this back-and-forth discussion of planning vs not-planning. The agile idea in itself is quite simple: Inspect and Adapt. My firm belief is that everything else needs to be build around that.
> The agile idea in itself is quite simple: Inspect and Adapt.
Ish. Agile is, ultimately, about removing managers.
Developers on a team coming together to inspect and adapt, as you say, is a necessary function when you don't have a manager to do it for you. Hence why it is included in the Twelve Principles. Each of the twelve principles present a function that needs to be considered when you don't have a manager to do the work for you.Of course, this point from the Twelve Principles is always Agile's sticking point: "Build projects around motivated individuals." In the real world, businesses don't want to hire motivated individuals that will drive projects, they want to hire many cheap, replaceable commodities along with just one motivated manager to whip them into shape. That is what that Jira stuff mentioned in the earlier comment is all about.
> Wolves are the result of the work, not asking the question. Wolves don’t ask to be wolves; they are.
Whether or not you find this blurb interesting will probably determine whether or not this link is worth clicking to you.
I think this quote snipe without the context doesn't really do the article justice. The post is interesting both intellectually and in that it's already clearly controversial. This quote standing by itself is mostly just confusing and imo takes away from the discussion.
A thing can become controversial exactly by appearing intellectually interesting on a superficial level but being dumb on a deep read. This splits the audience in the superficial readers and those with the time or expertise to read the piece with a deeper view. Both teams see the other as missing the point.
Google AI overview returned: “A ‘lone wolf’ is a wolf that has left its pack to find a new territory or mate, a natural dispersal behaviour crucial for genetic diversity.”
Interesting enough people do jump around to build their skills.
It helped me to think of it more as does-my-house-say-dead-engineer-storage-Wolf than awoo-Wolf.
This article has to be satire…
I lived through some of the events described therein. It's not satire.
That’s cool it just reads like an onion piece.
I know Michael Lopp. It’s not satire.
Shark or sheep?
"A lion doesn’t concern himself with the opinions of the sheep!"
On National Geographic channel, I have seen cannibalism in lions and spotted hyneas.
“Jugglers and singers require a pay raise. You’re a Lannister”
"Any man who must say 'I am the CEO' is no true CEO at all."
“Are you enjoying your new position?”
“Am I enjoying it?”
You could easily fit many GoT quotes in a series about office politics.
> All of these activities did occur because good work speaks for itself ...
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.
> Good work very much doesn't speak for itself
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.
In my career I never received any recognition for well designed and executed projects. Even the ones that were high impact and widely praised by customers. I had much more luck with shitty/buggy stuff that should not have been released. Yes, I’m not perfect and suffer from brain farts sometimes. In such cases I could play a hero that worked whole nights/weekends to put down fires. And I got rewarded for that.
The point is the wolf does not need managment. He has built up a model in his head of the problem and solution space better that a team of 1x specialists. T expose it to "managment" , "oversight" and "accountability" is to destroy it, especially for the article that shows an innnovative solution to an organizational pain point. They may be poorly managed, but they may be well managed, either way the managment style likey does not match the particular problem and/or solution the wolf is adressing. One of the key premises of The Innnovators Dillema is that well managed companies are well managed in sweet spots of operation and struggle outside of that sweet spot.
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)
> One of the key premises of The Innnovators Dillema is that well managed companies are well managed in sweet spots of operation and struggle outside of that sweet spot.
This become apparently quickly to anyone thats worked in a rapidly scaling company, switched from megacorp to startup, or vice versa.
There are processes and controls that make a lot of sense when you have 100k employees that will literally strangle your company to death when you have only 20 employees. What process & controls you add over time, as you grow from 20->200->2000->20k is another question.
If you hire too many megacorp thinkers into your smallcorp too early, you will observe this friction. Likewise if you do grow to 2000 people and still have Bob the Wolf ordering servers on his personal Amex, you're probably gonna have some problems.
I’ve only done 20-200-2k, but I agree with you fully. At 2k, there’s a weird middle ground (IMO) where you actually need a handful of wolves to keep things nimble. They cause an awful lot of strife particularly to the people who are trying to grow from 2k -20k, but they are the thing that keeps the other people moving in the right direction until you’re big enough that it’s just not tolerable anymore.
At that point you get an office of the CTO to be formal wolves!
you need flexible organziational glue logic at this scale, and the so called wolve can help, so this office of wolves can be the ones patch wires and to reprogram the organzational FPGA's or rewrite the organizational routing table (or what ever it is distributed software people use as glue logic...)
> This become apparently quickly to anyone thats worked in a rapidly scaling company, switched from megacorp to startup, or vice versa.
exactly! my frame of reference...
> The point is the wolf does not need managment.
If some dev rolls up to work and claimed that "I don't need to do anything to be a high value programmer" because he has mastered the zen of not getting in the way of good code, is anyone going to buy that? It is a lie for those who were born yesterday by someone justifying not being very good at their job. Ditto when a manager says it, even if they are important enough nobody is going to call them out directly. Under no circumstances is what the narrator describes a good response. All managers have limitations so sure maybe it is the best response he can muster and he's still a great manager otherwise, fair enough, but the story then isn't that wolves are amazing, but that the writer has a massive blind spot, it hasn't caused a big enough problem that they had to fix it and they've settled on tonic immobility as a strategy because they haven't figured out the productive action.
The situation is an employee is doing great things. Employees manager-once-removed agrees. The middle manager is trying to stop the employee. That isn't a story where the key is an amazing employee. It is a story where manager-once-removed doesn't know how to manage the middle manager, and the middle manager is either being undermined, is incompetent or both.
That is reading a lot into 2 blog posts, so I wouldn't go down on that ship. Maybe there are a lot of extenuating circumstances that aren't being written down. But the most likely fit of the facts in a software business is that management are flailing. Which is cool, management sometimes flails. But the focus should be on improving managers so they can do their job properly, not pushing the stress of dealing with their flailing down to the employees. It is unfair and stressful for the lower tiers of the org tree, and flailing management can get a lot of people fired.
Interesting. I read the article and situation completely differently.
I suspect the author has failed to explain enough to get readers outside of their preconceptions based on their experience.
In particular I think management and leadership have been conflated in most interpretations - his inaction is a form of leadership to promote personal growth for line manager and IC. The absence of management is the application of this leadership.
(But who really knows...)
> This looks a lot like a manager-once-removed undermining a reporting manager by supporting an engineer to go rogue.
Yes, and this is unfortunately the best move in many situations given how hard it is to fire people. The ideal thing to do is fire the incompetent manager who is a tax on their team rather than a multiplier. That unburdens the highly competent engineers on their team to do good work.
However, that might not be possible or even a good idea. A failed hire might reflect badly on the upper manager, or prevent them from hiring a replacement. It might require a lengthy performance improvement plan, which means you have a burdened team for that whole duration. It's often easier to de-claw the bad manager, and take back on their responsibilities yourself. Not ideal, but the best of a bad situation.
> This looks a lot like a manager-once-removed undermining a reporting manager by supporting an engineer to go rogue.
The second red flag in all of this is that an engineer doing good work on their own is labeled "rogue". Management's job is to make people productive, if they can't realize that the best configuration for their team involves some individuals working largely separate from the managers own mediocre day-to-day ceremonies/projects, then they aren't doing their job. People that don't need to be managed are the best kind of people, if you can't spot them and leverage them, get out of management.
Yep. Even the details provided suggest that (i) the "wolf" explicitly asked for a level of support from upper management that wasn't offered and (ii) when others eventually became aware of the testing framework, they were able to improve it. Neither of the two details provided vindicate the author's self-congratulation on spotting the wolf and choosing to keep it quiet.
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.
100% agree. You don’t have to let an engineer go rogue to get stuff built that isn’t a new feature.
I don’t manage managers, but do manage a team of 15. I try to be clear that part of my job is giving them time to improve their jobs. When one has a complaint or suggestion, I ask them to put it on paper so I can get it into our backlog. I will gladly prioritize something that will have a positive impact across multiple engineers.
Test and build are things that fall through the cracks and working on them can get outright hostility from management and other team members in some places, indifference in others.
At one place I worked nobody could give me a reliable build procedure, I settled in on one that was 40 min and worked reliably. I complained at every team meeting about the slow build and nobody cared. I put in a ticket for the slow build and was asked “how does this help the end user?” and my answer was “if my build was faster the end user would have had the product six months ago”
Where I am now I have a “maintenance droid” that automates a mildly polyglot build and when it runs into trouble it applies various levels of cleaning and every few months I run into some problem where it gets different results from my supervisor and/or the CI system and these days it always turns out to be right.
> Good work speaks for itself.
I really enjoyed reading this story. I personally believe in subscribing to self concordant goals and working altruistically to cultivate the good Society.
I also agree with the statement above. But what the author leaves out is that good work that speaks for itself can also create insecurity for those that are in an intense competition for recognition.
People’s reality is entirely subjective, where even well intentioned people may reject ideas that don’t contribute to their interpretation of reality.
In my personal experience, when I came up with and executed ideas that made substantial impact and outperformed others, I wasn’t given proper recognition, mostly due to others insecurity and politics to support a subjective reality that everyone can agree to. Particularly leadership who were non-technical sycophants that cared more to please their master than to do the right thing for the company or even themselves.
Humans are complicated social creatures where ethics and altruism often lose to filling personal voids.
I do believe in the concept of the wolf, someone who has reached self transcendence that doesn’t need to subscribe to a subjective shared reality and can achieve personal satisfaction through mastery by exercising their will to do something they believe is intrinsically meaningful.
> good work speaks for itself
I disagree. Ideas don’t speak, and work doesn’t speak. People do. Being a 10x engineer isn’t just about having great ideas, it’s about having great impact.
Sometimes I hear ICs say with some pride that “I’m not interested in playing office politics”. I promise you they will lose out to the engineers who are able to self advocate, and coalition-build.
I don't see things the way you do.
You look at gaining recognition for good ideas as a zero sum game that requires self promotion.
If you develop a good original idea that solves a problem and it gets implemented, you have created positive impact without self promotion. If you're not concerned with public perception, then the discussion stops right here.
Someone can take credit for your idea to gain perception that it was their original idea. But in the end, someone who self promotes that can't come up with original ideas will eventually lose their believability factor and will be unable to promote themselves much further.
The crux is in the “and it gets implemented” part. Teams have a limited bandwidth, so what gets implemented absolutely is a zero sum game, that’s why backlog prioritization exists. In order for your idea to get implemented, you have to advocate for it, and convince others to do the same. Writing great code and delivering useful side-projects can make you a 2-5x engineer. If you want to be a 10x engineer, you have to scale your impact beyond what you can do alone
Edit: maybe your great idea is actually something that you can implement on your own, such as a test suite or a tool. You still need to change other peoples behavior. You need to convince people to try it.
You completely missed the crux of the story.
I'm speaking specifically to the example given by the author.
He was approached by an engineer that saw a critical flaw in the software that goes beyond simple "backlog prioritization".
The engineer "quietly" escalated his concerns by showing a thoughtful approach to fixing a global problem that goes beyond his assignment, that if left unsolved can cause problems for everyone.
Given the managers experience, he understood the engineers intrinsic motivation to do good (not biased in self promotion) and believed that the idea would speak for itself and gain the confidence of other engineers, which it did.
This approach is antithetical to what you described. The engineer did not advocate for himself or his idea, he identified a bigger problem that was far more important than his assignment. He brought the idea to leadership out of concern, to deal with conflicting priorities above him. He was not caught up in politics or transactional thinking.
The message the author is trying to convey, people with significant talent that have higher order values, are not concerned with labels such as "wanting to be a 10x engineer". They just focus on what they believe are the most important problems that they can solve that benefits everyone, not just themselves.
These people are truly rare and your argument that playing politics is necessary to promote ideas, proves how rare it is to come across these people.
This is an incredibly cringe article. From using “wolf” in a completely forced way, to full quoting a conversation that seemingly only misses “and that testing framework’s name? Albert Einstein”.
Man I'm glad someone said this. Incredibly cringe and unnecessary using the whole wolf analogy for, essentially, "someone who's good at their job". Gives off vibes of the whole "alpha/high value male" thing going on in social media.
Exactly! I hate these stupid archetypes.
It's like a linkedin article that has escaped from its cage.
I have to admit reading heroic stories like these is a guilty pleasure of mine. It's ridiculous, but strangely inspiring in a completely unrealistic way.
[dead]
The interesting thing about the "test and build" kind of work that this "wolf" was working on is that this is team-oriented behavior that people in teams usually think the team won't let them do. It takes a kind of rugged individualism for somebody to buck the team to do this teamwork!
On the other hand, my belief is that the main responsibility of engineering management is to be sure that stupid little details like build and test are taken care of. When they hear that "my build takes too long" or "I can't figure out how to write tests for X" they should take it as seriously as "I have cancer". If your "team" can't give a new programmer a checklist (or coaching) that gets them up and running quickly, it isn't really a team!
Instead of this, most engineering managers are doing something else which might seem to have to value their managers but from my viewpoint of a developer is a complete waste of time. If instead of telling developers to suck it up about little annoyances they took responsibility for clearing them away they could 2x or 3x the whole team and not waste time chasing hypothetical 10x developers.
This. And the reason this is relevant today is because an excellent build and test system multiplies the effectiveness of coding agents which multiply again the effectiveness of next level engineers.
There aren’t many other things I can think of that have such a huge positive impact on the productivity of an engineering team.
You need to tell your countrymen that rugged individualism belongs to the omnivorous foxes, not lonewolves
I have experienced some companies trying to tame wolves with agile type systems with poor results. I have seen wolves getting sick in cages, i have been seen wolves accomplishing amazing feats and being sidelined for not being team players by mediocre leadership because the leadership did not get recognition.
Early in my career I would build something I thought was useful, deploy it, meet with people within the company to get people to start using it. A lot of effort for something that would have a positive impact. My manager would schedule a meeting with me, and with a look of panic open with, “why didn’t you tell me about this or why did you do this?”. I understand now that before you start something, you need to decide who you are going to give credit to, and that person needs to be made aware that they will get credit for the project. Ideally your boss’s boss’s boss. Corporate caché only exist insofar as leadership allows it to exist, you gotta play the game. Pawns don’t get to take the glory for themselves.
Were you doing it on your own time? From your described “a lot of effort,” I assume it was not but please correct me if I’m wrong.
If you’re being paid for your time by someone else, it’s fair to notify them how you plan to use a significant chunk of that money before you do it. Unless of course you were employed to _not_ do that.
I am not suggesting explaining a day or two of work. But it sounds like you’re talking weeks.
It would be like if I was expected to deliver A by the end of the quarter and instead I delivered A + B. The value gain from B was more than A. Your manager (and hopefully higher up the org) better know about B, or they will attack it as a threat.
Also, I’m not being paid for my time, I’m being paid to do a job. “Trading your time for money” is one of the most self defeating views on work you can have. It reduces you from a worker with agency to a detached prostitue, and is harmful to both the employer and employee.
Not sure i understand what your are trying to say, good communication is definitely important, if only to serve oneself
> i have been seen wolves accomplishing amazing feats and being sidelined for not being team players by mediocre leadership because the leadership did not get recognition.
That's the norm across all industries.
The argument seems to be: don't promote/support good ideas or projects because if they're good they'll likely succeed without you, and then the initiator will be slightly more confident.
Which is phrased as "not my job" for some reason.
The message is that process is there to extract value from people with average skills and motivation. When you find someone very skilled and self motivated doing the right thing, don't let process hamper their way.
I wish the article actually said that in plain words instead of trying to foist it into that peculiar "wolf" analogy (or whatever it's trying to do). I found the article kind of confusing. Thanks for spelling it out.
I thought the message is “you might really want to find and encourage and promote and support your best programming talent though overt action, but such overt action might in fact have the inverse unintended outcome, often best to ensure you know such people are in the team and ensure traditional management does not get in their way or piss them off with traditional corporate thinking, which has zero idea what great programming talent looks like or is motivated by.”
That’s what I read.
Same. New ideas are like starting a fire. Piling too much on top or blowing too hard will stop it. You (together, however distributed across roles) do have to assess if you can handle one more fire, if it comes on top, replaces an old one etc. Getting to this decision in your specific setup is the tough and important part.
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 remember when we used interns as an analogy to explain LLMs, now we've come full circle and are using LLMs as an analogy to explain people.
This is how I took it, and what I lived through. Both the supportive boss that let me do my thing without getting in the way, and those who tried to manage everything and make me shut down.
But did OP actually suggest their job is to “ensure traditional management does not get in their way”? I’m almost certain their point was not to interfere even at that level, which is why they didn’t hype it up the chain and let it land on its own.
Part of not hyping it up the chain is also that a lot of these projects are experiments. They may work, they may not, and some pivots may be required along the way. As soon as something is hyped to leadership, now there are feature lists, timelines, and expectations. All room for creativity and experimentation are gone.
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.
I don't know that I care much for the mythologization of effective developers as "Wolves" and "10x-ers" which are this decade's equivalent of Ninja / Rockstar / Guru, but a similar less tech-centric version of that is just the concept of the "Maverick" within any organization and the parallels aren't too far regardless of the industry you're talking about. Outsized impact in undersold roles with a lot of heavy swinging soft power earned through merit.
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™!
You are confusing concepts.
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.
I don't think the concepts are as unrelated as you're suggesting, they both tend to operate on the premise that they can be more effective than others because they're able to bypass the lanes that everyone else is taking.
And you are highlighting exactly what I'm pointing out, which is that if your process is so rigid and overfit that your org is regularly missing out on obvious solutions then the thing you should be solving is the process rather than trying to create "wolves". The concept of a team needing someone that consistently "breaks the rules" so that you can do the right thing is a glaring red flag that you have a bigger picture problem.
my point was the efficiency from bypassing/cutting corners is different to the efficiency from understanding and synthesizing problems and solutions differently.
the "obviousness" in the first is seen by everyone, the "obviousness" in the second is seen only by people able to break out of a collective mindset and unground their thought processes.
in the first the "wolf" is missing some obvious things, in particular the negative externality of their action. in the second the "wolf" is generally working on maximising the positive externality by generalizing problem space and solution space outside of the conventional fitting.
> Process exists because it makes your org more efficient
That is one hell of an assumption.
> Process exists because it makes your org more efficient
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.
People like this can be a huge help, but they can also cause real damage. I've seen it go both ways: someone can deliver a ton of value one year and create serious problems the next.
This article's description gives me pause because it reads as non-collaborative and needlessly abrasive. In my experience, people who bulldoze process and relationships are almost always a long-term net negative, even if they can ship something short-term at 10x speed.
If you are 10x, there's still a ceiling on what you can do. If you're leading a team of 50 and you can help each person get to 1.2x, you've created the same effective lift, while strengthening the team instead of burning it down.
And that's a durable change which doesn't go away if the "Wolf" leaves or has a down year.
Most wolves I know of are impossible to work with and a barrier to company scaling. Which eventually leads to à net lots of growth opportunity.
Worse I’ve experienced as dev around wolves is the typical tendency of being marginalised only to be later proven true about things. To me this is super toxic so duck them wolves really, they be lone very often.
i'm supporting a small org with their decision making and feedback systems.
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?
> Wolves don’t care if they are seen or not.
Well... As one of those supposed 10x engineers, that's not quite true
It's true that the intellectual satisfaction is my main driver, but I'm also quite vain. Appreciation and respect (especially from peers, who cares about an All Hands) add juice to the battery.
That's just me though.
A feel good article where you can choose to self insert as the wolf or the wise manager who knew to be “hands off”.
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”.
Hard agree. Nothing more offputting than being labeled and categorized like the corporate overlords are playing AeO II and I’m a "resource" to be acquired, harvested, used and/or discarded.
wolfness is in the eye of the beholder
> “How do I become a Wolf?” Wolves don’t know they are wolves. They don’t care about the label or the unique conditions that surround them. Wolves are the result of the work, not asking the question. Wolves don’t ask to be wolves; they are.
Answering the question a bit more directly, you do it by stopping thinking about being a Wolf, and by putting what seems like an unreasonable amount of effort into getting shit done well. There's some natural talent involved here, but most of it is just caring enough to learn and do whatever is needed to be great. And then, the more you run, the faster you get.
This is goddamn terrible advice. You’re rolling a dice to see if the great work ends up making it.
Have we not learned the lesson of bell labs? 90% of the time the great work doesn’t make it by itself. It takes leadership to carve a path for it to emerge and actually flourish.
I swear, there are like two influential things on the internet that have completely wrecked the practice of engineering management:
The Spotify org chart blog post and Rands.
While I'm all for empowering your best contributors, I'll repeat what I say every time I hear someone mythologize about "10x engineers": if you want a 10x engineer, you need to pay a 10x salary.
When companies say they want a 10x engineer, what they really mean is that they want an engineer who will work for 10x less than they're worth.
Gassing them up so they'll manage that many bodies (outsourced, of course)
I think OP's nickname is a good summary for my thoughts on this article
"omegas don t care what other people think, they simply do their thing", thats hoow you people sound, very dumb.
So basically just cats then?
I generally don’t take these articles too seriously but a question has been popping up in my mind.
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.
Some people genuinely want to help others, without any immediately visible reward.
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 had a boss like this. He didn’t stand me up in front of everyone to show stuff off, but each year when it came time for raises and bonuses, he always took care of me. But those raises were never conditional or tied to whatever project I was working on.
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.
In this case you are helping your boss’s bottom line. The poster here gets nothing.
I find it fascinating that people find it fascinating that people just want to do right by others. I get that this is in the context of a workplace, and there is always some level of competition between people, but personally, I never gave that more weight than being happy and feeling good about how I treat others.
He’s building credibility as an engineering management consultant.
He got attention?
Building a reputation of being wise?
Was this written by the 1980s business guy from Futurama?
I've got to admit to being somewhat disappointed that the "wolf" in question wasn't the character from the film 'Pulp Fiction', because - at least in my mind - it's an apt example for Rand's original article.
Nice to see Rands back.
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.
He posts his articles to his socials,⁽¹⁾ along with the occasional quip like “Your life is going to be full of people sounding like they know what they’re talking about.” and “Your three-day response time to critical communications tells me exactly what I need to know.” and “You're either getting stuff done or talking about getting stuff done.”
⁽¹⁾ https://www.threads.com/@rands
I don’t know, man. Rands was kind of the original slop
"Build a safe, healthy, distraction-light, and drama-free environment where builders focus on building. "
As he says in a footnote, that's hard. Each of those attributes is hard. Getting any of them is good...
"I didn't say anything to the manager - I made a subtle hint and prayed that they took it, because ... reasons. On this occassion, I lucked out"
This just in: Wolves is the new hype word for the mythical 10x employee.
Just in from 2014, when the original article referenced in the first line of this one was written, opening 'You've heard of the 10x engineer, I'm here to tell you about the Wolf'?
What an untalented writer. His prose is clunky and every paragraph drips with sanctimony and reaching generalizations.
Well the writer has had a number of books published which appear to have been successful. So he has found a market and delivered completed work.
So it's okay he's a bad writer? Sales above all?
It's more completing book length works that are published by a publishing house. Therefore subjected to content editing, copy editing and finding an audience. Quite a complex multi-stage process.
What criteria are you using to evaluate writing? Can you point to an example that you think is good writing?
(I say all this as someone who is still working on stringing words into sentences)
sure is nice to be paid for staying out of the way.
i think i am an expertise on not getting into other people's business. can someone pay me?