Hacker News Reader

> 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...)

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.

> 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.

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.