alt Hacker News> 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.
Replies
> 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.
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)
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.