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)
Which is phrased as "not my job" for some reason.
That’s what I read.
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.
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.
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.
The wolves analogy is simply wrong. 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.
There are plenty of lone wolf developers, but you won’t find them in large teams. Or if you do, they’re dysfunctional. On their own, a lone wolf engineer is not generally able to complete large, important pieces of work. Some do! But they are exceptions.
You assume "lone wolf" types are "one trick ponies" who can't learn. You also assume the only interesting problem space for these people is technical/code.
The lone wolf has a big limitations in transitioning to scale: 1. managers do what the article suggested, and stay out their way. The lone wolf never gets the experience of being managed, so it is difficult to transition to manage others. 2. they don't get why others don't "get it". e,g the solution is clear , the code can be done in a day, the comprehensive system model in their head should be shared by everyone.... it takes time to understand that the average engineer works slow and steady on a small scale understanding.
I will suggest there is a lone wolf type manager too. This is not a productivity skill, but an adaptivity and mobility skill.
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.
I'm pretty sure the author doesn't think managers should create a culture that attracts and promotes terror attackers.
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 mean that in the worst possible way.
Interestingly, it came out from putting random individuals in anhigh-stress prison environment.
"Alpha" in the wild is really dad and mom...
To someone actually running a company this looks like absolute corporate nonsense. Don’t categorize people like this, it’s demeaning and weird. Why can’t we just treat people like adults.
Instead of “Oh yea he’s a total 10xer wolf,” try “Yea Mark, has some good ideas for a test framework we should consider”.
What the hell is the incentive of the guy posting this to encourage and help The Wolf??? He’s just doing it out of good will? What does he get out of doing the right thing? No recognition. No bonus. Nothing. Yet he still does it.
I find this fascinating.
Building a reputation of being wise?
I won’t say it’s necessarily altruistic, as of course there could be a drive from inner machinations that we’d never be privy to.
(Sometimes the exposure of an article can be considered a reward, for those looking for ego inflation)
Even myself, I generally don’t leave comments unless I feel they’re going to be helpful or insightful to someone else. But I am also biased, as I do have a very strong affinity towards sharing information, so I greatly appreciate the effort artisans and those more knowledgeable than I go through to share such knowledge.
I got the recognition in my paycheck, which was the only place I wanted it. I prefer to work quietly behind the scenes. It wasn’t about any one project, but consistently delivering whatever it was I was delivering, without much input or interference.
That's the norm across all industries.
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.
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.
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.
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)
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.
At that point you get an office of the CTO to be formal wolves!
exactly! my frame of reference...
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.
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...)
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.
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.
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.
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.
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.
i think i am an expertise on not getting into other people's business. can someone pay me?
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™!
That is one hell of an assumption.
Nah. Process mostly exists because management doesn't have visibility into what engineering is doing, so they have to poke vertical holes through the org to know what everyone is up to.
Process is often pitched as improving coordination between teams, but that's more of a fringe benefit than the actual reason for process.
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.
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.
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.
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?
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.
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
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.
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.
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.
In your fictional scenario of unlimited budget and time, sure I grant that an expert should work unguided.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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
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.
> 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.
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.
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.
Edit: I wish I had access to ones more like yours.
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.
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.
There aren’t many other things I can think of that have such a huge positive impact on the productivity of an engineering team.
As he says in a footnote, that's hard. Each of those attributes is hard. Getting any of them is good...
silisili•6d ago
Whether or not you find this blurb interesting will probably determine whether or not this link is worth clicking to you.
picardythird•6d ago
seanhunter•6d ago
dbt00•6d ago
picardythird•6d ago
baxtr•6d ago
slfreference•6d ago
arter45•6d ago
baxtr•5d ago
arter45•5d ago
“Am I enjoying it?”
You could easily fit many GoT quotes in a series about office politics.
ai_critic•6d ago
Etheryte•6d ago
nathan_compton•5d ago
lastdong•6d ago
Interesting enough people do jump around to build their skills.
Throaway1982•5d ago