In our last essay we discussed a famous paper titled Nobody Ever Gets Credit For Fixing Problems That Never Happened — which describes how many companies eventually just push its workers to work harder, instead of doing process improvement. We discussed how this happens, and why; we also took a look at a handful of common business experiences to illustrate how this is a phenomenon that you’ve likely already experienced.
This is a great question. A couple of unconnected thoughts and observations:
I think the best way to find folk like that is to ask for stories where they’ve done process improvement in the past. The usual caveats about doing reference checks probably apply.
I’d said that people like Byrum aren’t that rare if you hang around startups long enough, but in terms of absolute numbers (e.g. if you count them and then compare them to the number of candidates/hires you make) they’re actually pretty damned rare.
Some people do tend to have more of a ‘do whatever it takes to improve the process’ orientation than others. I’m not entirely sure why that is. Now that I’ve read the paper and thought about it more, I realise what you want to do is to identify folk like that and give them air cover. I haven’t done this before. (The most I did, apart from the ‘keep an engineer/intern in reserve’ was ‘build process/tooling improvement into the promotion criteria for leveling engineers’).
The tricky thing about evaluating these folk is that they may have been constrained by bad org dynamics in prior roles. A possible way around that is to ask the YCombinator application question “Please tell us about the time you most successfully hacked some (non-computer) system to your advantage”
It strikes me that Byrum (and many other early Amazon employees) may best be described as ‘relentlessly resourceful’. Which is ostensibly what makes for good founders, but then you want folk like that in your company anyway. Of course the next question is how do they (YC/Paul Graham) identify it, and I guess the answer there is ‘ask for stories’.
Here’s a potentially controversial takeaway from this case: I’m guessing that it actually was the best decision for Amazon’s leadership not to direct any of their engineers to this problem. Obviously I’m saying that with low context, but given how fast they were growing and where internet tech was in 1996, I suspect there were probably more pressing product issues that were breaking than customer inbound questions. That’s not to undermine Byrum and Amazon’s Customer Service leadership at all — they sound phenomenal (I’ve worked with one person who fits that mold, and to my eternal discredit, I almost vetoed her hiring because she did such a poor job in the interview process… needless to say I’ve since learned how valuable her skillset is!).
Or maybe to put it in Commoncog-ese, I doubt that Customer Service at Amazon in 1996, as important as CS always is, was the high-order bit, i.e, not where Jeff Bezos should have been spending his cycles. I know that CCM isn’t about taking learnings from these cases, but there’s a broader paradox around process improvements: 1.) it seems like most process improvement needs explicit senior-level support, because the gravity of an organization usually pulls away from process improvement; but 2.) unless you’re running a Danaher- or Koch-style company, and especially if you’re in a tech business, process improvement is not close to the high-order bit.
So how does one set up an organization to succeed with process improvement? In my reading of the instance in this case, the solution was solved b/c a CS leader with a particularly valuable persona was hired into the role AND the CS org was so orphaned by the rest of the company that it could run this skunkworks project unmolested. But that’s obviously hard to set up intentionally.
I struggle with this, but in my little world (and relating to this comment from @cedric about WBRs https://forum.commoncog.com/t/private-thread-the-amazon-wbr/1954/18), I’m thinking that process improvement may just be a situation of: “it’s not the high-order bit, or even close to it, but it’s a hygiene item that requires leadership to spend x hours/week working on”.
Curious how others have seen this reconciled well.