Why every engineer should know Hans Monderman 👷🏼♂️
I once joined a team that was really struggling to deliver software. We had talented engineers & good working relationships within the team and with other departments, but the work we delivered frequently had bugs or just didn't solve the problems we cared about.
It wasn't for lack of process! Our Jira board had all of the lanes, a sophisticated state diagram determining which statuses were allowed to transition which way, and most importantly, lots of checks along the lifetime of a ticket to ensure that the work was being done the right way.
Something like this list of statuses probably looks familiar to a lot of engineers:
- Todo
- Refined
- Estimated
- Design Doc
- Design Doc Review
- In Progress
- PR Review
- Design Review
- Acceptance Testing
- Deployed
(I think I've simplified this somewhat but you get the idea)
We were frequently finding that tickets failed at step 9, sometimes multiple times for the same ticket.
Coming from a much smaller company—which had far less process and none of these delivery problems—I was both frustrated and confused. After all, I was working with smart people! Who cared about their work! And yet.
Enter the traffic engineer who hates traffic signs
Let's talk about Hans Monderman for a sec.
From Wired's profile on Monderman:
Hans Monderman is a traffic engineer who hates traffic signs. Oh, he can put up with the well-placed speed limit placard or a dangerous curve warning on a major highway, but Monderman considers most signs to be not only annoying but downright dangerous. To him, they are an admission of failure, a sign - literally - that a road designer somewhere hasn't done his job. "The trouble with traffic engineers is that when there's a problem with a road, they always try to add something," Monderman says. "To my mind, it's much better to remove things."
The article is worth a read (I read it as a kid and it lives rent-free in my brain), but the tl;dr is that he increased both safety AND throughput by removing features designed to help cars travel fast & safely (like curbs, painted lanes, wide roads, traffic signs). Drivers on signless, narrow roads had no choice but to slow down and pay close attention.
The trouble with traffic engineers
That “trouble with traffic engineers” sure resonates with modern software development practices: statuses, reviews, sign-offs are all designed with good intentions to make software development safer. From an engineering manager's point of view, it's tempting to see a failure as an opportunity to add a control: “We shipped the wrong design, so we added a design review step”.
These processes evolve into something that robs developers of autonomy and responsibility. They don't know whether they're shipping the right thing because they literally have a step in their process where someone else determines whether they shipped the right thing.
So I took Monderman's advice: I started deleting statuses.
I did it incrementally, and it took some effort to convince folks, but I happened to be in the right place at the right time to make the change (EM left and I was the lead dev/scrum master). The folks who were performing manual “checks” as a part of this process were generally happy to be resources to be consulted instead of owners of someone else's work.
It was unnerving for some team members. At standup, when 'walking the board' I landed on a ticket in progress that appeared to be done. The engineer assigned to it asked reflexively “but how do I know that it is done?” which prompted a funny conversation: “how do you know if it's done?”. Of course, they knew all the steps and criteria, they just weren't accustomed to being asked!
But that interaction gives insight into why we stopped shipping bugs and started shipping faster: engineers became responsible not just for saying when work was done, but also whether they were doing the right work.
We still engaged with the same stakeholders, and still worked cross-functionally, but responsibility for shipping was exclusively the engineer's.
Eventually I whittled the 8 lanes on our board down to 3: To Do, In Progress, Done.
This process change received overwhelmingly positive feedback from within and without the team, because the change was obvious. We were performing at a higher level, devs were happier, designers & PMs had fewer & more productive meetings.
So, next time you've got an organizational problem, remember to channel Hans Monderman and think about what you can remove =).
Inspiration & References
Leadership on a Submarine - very similar concept: don't create a detailed protocol for a complex task. Empower the people doing the task to own it.
Product Engineers - I consider myself a product engineer (I just recently learned about this medium article from a coworker—thanks Lily!), and the engineers I've learned the most from are all product engineers.