As an engineering student I was impressed by the intricate\u00a0harmony of development processes. It was probably the same part of me that loved the uniformity and\u00a0audacity that is xml.<\/p>\n
These days I use JSON 100\u00a0times more often than xml. I’ve similarly fallen out of love with process. But there’s still a grudging respect there. Like an old lover that done you wrong, but is a sort of evil superhero so you’ve got to respect.<\/p>\n
Now I’m a manager, and many developers dismiss my thoughts on process. But there’s good process and there’s bad process. The trick is telling them apart.<\/p>\n
I’ve been trying to foster one good process: The 5 Whys.<\/p>\n
I’ve dealt with many production incidents — goofs where we went down and failed to serve our users. We have a process for reviewing those incidents. I feel like they often only address a shallow understanding and patching of the problem.<\/span><\/p>\n In my view, if the investigation of a production incident doesn’t eventually lead to management being wrong, then you’re just not digging deeply enough. That is, I should have to change.<\/span><\/p>\n I’ve tried to install a 5-whys process to make these reviews more effective. (Read about them anywhere on the web, or in Eric Ries’\u00a0The Lean Startup<\/a><\/em>.) <\/span>It’s hard to get support. <\/span><\/p>\n Everyone’s busy. Add to that a bias against “process” and it really is an uphill battle.<\/span><\/p>\n I figured that I need to make it palatable by keeping it lightweight and low burden to the team.<\/span><\/p>\n Then I remembered that Eric Ries introduced the 5-Whys with the sentence:<\/span><\/p>\n “Adaptive processes force you to slow down and invest in preventing the kinds of problems that are currently wasting time.”<\/span><\/p>\n<\/blockquote>\n — The Lean Startup, pp. 229. Eric Ries<\/span><\/p>\n The 5 Whys is supposed to slow you down right when you need to. You fix the causes and speed up again. \u00a0When others arise you slow down again.<\/span><\/p>\n Trying to improve without taking any time away from “real work” isn’t possible. I can’t make brakes that work\u00a0and<\/i> don’t slow you down:<\/span><\/p>\n The most innovative and exciting feature of Cheforlet’s new concept car is that the brakes bring you to a stop without slowing down. \u00a0Picture arriving at your destination just as if you sped straight there without a stop \u2013\u00a0even in heavy city traffic. The imagineers have done it again!<\/span><\/p>\n<\/blockquote>\n — Said Noone Ever<\/span><\/p>\n I can’t improve the team’s track record without costing time. That means that developers need to take time to understand why production went down. Then we need to understand why the work was done that way. Then we need to understand how management is going to enable and support a new way of doing work.<\/span><\/p>\n All of that takes data. Sometimes it takes dark and inaccessible data that we need to write custom tools and reports to get at. We must force ourselves to get the data we need and not settle for the data that’s easy (availability bias).<\/p>\n While it is a dev ops\u00a0concern it can’t be done without buy-in from the\u00a0business. We need to carefully manage their expectations around incidents. They should expect that incidents will cause a slow-down beyond the flurry to restore service.<\/p>\n Mr. Ries bills The 5 Whys as a way to grow just the right amount of process. The kind of process that addresses problems so credible that they’ve happened to you before.<\/p>\n Of course, if you just address the surface issues and promise to “be more careful” then you avoid building more process. And\u00a0you also pass\u00a0up helpful guard rails that make your job safer and more fulfilling.<\/p>\n","protected":false},"excerpt":{"rendered":" As an engineering student I was impressed by the intricate\u00a0harmony of development processes. It was probably the same part of me that loved the uniformity and\u00a0audacity that is xml. These days I use JSON 100\u00a0times more often than xml. I’ve similarly fallen out of love with process. But there’s still a grudging respect there. Like… Continue reading Brakes That Don’t Slow You Down<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":281,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[87,88,24],"class_list":["post-280","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-executive","tag-5-whys","tag-lean-startup","tag-process","wow fadeInUp","entry"],"_links":{"self":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts\/280","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/comments?post=280"}],"version-history":[{"count":1,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts\/280\/revisions"}],"predecessor-version":[{"id":282,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts\/280\/revisions\/282"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/media\/281"}],"wp:attachment":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/media?parent=280"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/categories?post=280"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/tags?post=280"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Incident Review SHOULD Slow You Down<\/span><\/h2>\n
\n
Not a Holy Grail: A Contradiction<\/span><\/h2>\n
\n
Improvement Costs Time\u00a0\u2013 Requires Partnering<\/span><\/h2>\n
Custom Grow Your Good Processes<\/h2>\n