From: Moore, Danny
To: All Staff
Date: 17 September 2022 at 3:27 pm
All,
A quick follow up note here as a few aspects of Buffet’s“avoid at all costs list” concept has popped up a few times this week.
In particular, one very key aspect of prioritisation is how to manage people, events, and contexts that act to knock you “off the ball”. In our business we have to deal with a lot of market or other event driven challenges, the rapidly shifting sands of client internal politics and the like. We also have to deal with the actions of people across the company.
Back in the software business we developed a mental model recognising two types of highly “net negative” (but nice) people: the “noise generators” and the “bug factories”. Net negative in that their contribution reduces (often significantly) the output of the team as a whole. They knock everyone else off the ball.
A “bug factory” is often a coder who is bright, engaging, enthusiastic and jumps in to help with every project, but never tests their code, builds unit tests, etc. The net effect is bedlam as their software blows up in production every time it’s deployed. See last week’s MEMO on “a stitch in time”. This profile of engineer can do a lot of damage in a world where it takes 10x or 100x the effort to manage a bug when it manifests in production vs the effort required to build an obvious unit test in the first place.
A “noise generator” is a person who generates a lot of noise and enthusiasm around their projects (or pet projects) and sucks in (a.k.a. distracts) lots of other people in the process. The worst type tends to be drawn to the most overloaded teams or engineer(s) in a company, distract them, and in doing so derail all the high priority work the team needs to be focused on. My comment below is that these people are just plain dangerous and can be hugely net negative for the whole firm while marching forwards apparently successfully themselves.
In my experience some mean well and read a self help book on the “power of persistence” but missed the chapters on listening to feedback and understanding which battles to pick. Some are just narcissists.
I borrowed the term “noise generator” from Taguchi’s “signal to noise” ratio. Some people are all noise and no substance. The concept is well documented in organisational theory and central to narratives in “The Goal” and “The Phoenix Project”. AFAIK the “bug factory” terminology is original, maybe the topic for the next great business novel?.
In Options’ history we’d terrible issues with erroneous network changes in the first half of 2013. In June we hired Aaron White to lead the networks team, then John Bryant, Aaron and I did an audit of the change accuracy of all the changes prepped by each network engineer in the previous month. We fired the 3 engineers with the highest rework percentages (the “bug factories”). The worst scoring engineer only got the config right once in every five attempts, which means outages, frustrated customers, project managers tearing their hair out, escalation calls and the like four times out of five. Firing what was then 3/7 of the team seemed crazy but was immediately transformational, eliminated the constant fire fighting and let us focus on the real work.
Jason Williams scored 100% for change accuracy in the analysis. We moved him to cross-check and push changes out of hours, doubling down on our most “accurate” engineer. I’d recommend everyone have a chat with Jason at some point if you get the chance. He has captained an Americas Cup yacht and represented New Zeland in shooting,.. self reliant, one shot, one kill. Accuracy is key if you push 30 network changes a night.
Quite a few senior exits over the years have been high profile noise generators. Generally we saw immediate transformational benefits after they left. Persisting after feedback that the project you’re sucking resource into is a dangerous distraction and needs to be mothballed isn’t a good career move. Per Buffet’s “avoid at all cost list”.. part of running a business is asking people to refrain from drawing organisational focus to projects on that list, and acting if they persist. There have to be boundaries.
The final component of the system we used back in the day was designed to facilitate organic free flow innovation from the ranks without excessive noise and distraction.
The research on innovation is very clear. Companies that rely on a brilliant tech founder or a brilliant CTO tend to fail in the long term. Companies that figure out how to facilitate broad based innovation, or what’s termed an “innovation culture” tend to prevail. Innovative spark doesn’t respect org chart boundaries and very often the person most likely to block an internal entrepreneur is their own manager. Managers can be an insecure bunch, or sometimes built the current status quo so have a hard time seeing past it to a more efficient alternative.
The approach we implemented is laid out in this 2012 blog:
Stevie and I had a chat this morning around how the five step process could be applied more formally in Options.
Please don’t hesitate to contact me directly if you’ve any questions, thoughts or comments.
Cheers,
Danny