Complected
I just finished reading a book that was recommended to me by a coworker. The book, titled the Unicorn Project by Gene Kim, outlines…
Complected
I just finished reading a book that was recommended to me by a coworker. The book, titled the Unicorn Project by Gene Kim, outlines several organizational issues that have compounded over the years at a fictional auto parts company that is making the leap from brick and mortar stores to a hybrid online / retail store approach. If you have worked as an engineer in any capacity you’ll find yourself going through the full range of emotions as you read this book, laughter, fear, anger, and self realization — it’s all there.
The book focuses on what the author calls the five main ideals which I’ll annotate below then give you a fictional example of how things can go horribly off track just on the basis of a seemingly minor decision.
Locality and Simplicity — Let’s talk about locality — in both architecture and organizationally. Locality in the sense of the book is a loosely coupled system where teams can make changes, test, and deploy to customers without the overhead of having to get approvals and coordinate actions across multiple teams.
Simplicity is straightforward, most projects start simple and turn into complex complected systems over time. This means that if you find yourself working on a monolithic application, afraid that changing a line of code in the logging module for example might just cascade into an unforeseen production issue that takes your system down you’ve got to get back to the whiteboard. Organizationally, if you have put processes in place where the time from a commit to realizing that code in production is measured in weeks or days and not hours you certainly haven’t optimized your teams to achieve locality. Really ask yourself why?
Aristotle wrote that nature operates in the shortest way possible, your solutions should do the same and maybe even more important — your organizational processes should reward simplicity and remove complexity.
The key metrics that you’ll need to keep an eye on to serve as an indicator that you have achieved locality and simplicity are really, lead time for changes, which is the time it takes to go from code committed to production; deployment frequency, which is how often is code deployed to production; change failure rate, or the rolling ratio of successful deployments to unsuccessful deployments; and lastly, time to restore service, which is the average time it takes to restore service.
A world class deployment frequency is multiple times per day, lead time for changes and time to restore service are both**< an hour** and, change failure rate is between 0 and 15%. As with all measurements they really don’t mean anything unless you intend to improve them!
Gene Kim sums this up in the book stating that, “Simplicity is important because it enables locality. Locality in our code is what keeps systems loosely coupled, enabling us to deliver features faster. Teams can quickly and independently develop, test, and deploy value to customers. Locality in our organizations allows teams to make decisions without having to communicate and coordinate with people outside the team, potentially having to get approvals from distant authorities or committees so far removed from the work that they have no relevant basis to make good decisions,”
Focus, Flow and Joy is the second ideal and is really affected by simplicity and locality. Do you work on a team where you spend hours (days:months) waiting for others to complete something before your work can start. In a cruel world like this the countdown to code freeze keeps ticking while you wait. Worse yet — have you been told to slow down, stay in your lane, or just look over tickets instead of starting something new because process dictates it? Finally, the pièce de résistance, do you have merge parties that last hours (days) because instead of working on small focused tasks that can be delivered in less than an hour you save all your commits and have at it monthly.
Improvement of Daily Work is the idea of elevating improvement of the work over the work itself. I love that book ties in Jidoka which is one of the pillars of the Toyota production system, a system which builds quality into the manufacturing process versus only an inspection at the end — if you are working on a QA team I really, really recommend you take a look into this it will make your final inspection that much easier. Jikoda basically states that when you discover an abnormality stop and fix the immediate problem then investigate the root cause to ensure that the issue will not happen again. On the Toyota assembly line a series of physical ropes named Andon cords followed the assembly line and when pulled would stop manufacturing — it wasn’t a warning light or an alarm — it made the assembly line stand still. Everyone building the product had the responsibility to stop building and solve any problems then and there. When something stopped the line, the supervisor came down to thank the person who pulled the cord and start solving the problem. You can see how over time this culture where the improvement of daily work over the work itself leads to world class quality.
The book rightfully points out that “The opposite of the Third Ideal is someone who values process compliance and TWWADI, ‘The Way We’ve Always Done It.’ It’s the huge library of rules and regulations, processes and procedures, approvals and stage gates, with new rules being added all the time to prevent the latest disaster from happening again.”
Psychological Safety — do you feel that you can take risks and speak up in your team without feeling embarrassed or insecure? If you are on a team, or especially if you are in a team lead position; fostering an atmosphere of psychological safety is absolutely the most important thing you can do. In fact, it is so important to Google’s five keys to a successful team that they call it the underpinning of the other four dynamics, dependability, structure and clarity, meaning of work, and impact of work which they have found makes up a high performing team.
If you are in a leadership position be fiercely transparent! Realize that everyone is doing their best! It’s easier when dealing with a data science team (which I am blessed to do) to frame tasks as scientific experiments — you are just testing a hypothesis, most of them will fail. Admit that you are not perfect and actions do speak louder than words so lead by example, own your mistakes — don’t hide them - let everyone know so that they may not be repeated.
Harvard professor Amy Edmondson stated, “ Even small acts that seem inconsequential at the time can pave the way for larger contributions that carry more weight. By creating a team climate that encourages people to embrace potentially risky contributions, the team will be rewarded with better decisions, motivated members, and improved performance.”
Unfortunately, all it takes is one person to undermine an entire team or even organization by building silos and fostering a climate of fear and secrecy if you find yourself in this situation act swiftly to correct the problem. Just in this article you can already start to see how you will never implement Jidoka if your team lacks psychological safely, and without the ability to take risks you stifle innovation; as you continue think about the role psychological safety plays in the last ideal.
Customer Focus which according to the book is the act of ruthlessly questioning whether something actually matters to the customer. This one is really a problem because of something that a whole other post could be written on. The false consensus effect, basically says that you think everyone has the same beliefs as you do, and everyone also thinks the same way. This is one of the reasons why diversity on your team is so important but that’s yet another post. Remember when you are ruthlessly questioning what matters — if everyone is agreeing with you something is wrong at best you are now witnessing pluralistic ignorance. Pluralistic ignorance is when people approve publicly but disapprove privately. If this happens and you really have built a team that thinks in the same way you have created blind spots. As a leader you really — really — need to both surround yourself with a good amount of people who are not afraid to disagree and additionally, but that’s not all you also need to be the type of person that fosters an environment where people feel comfortable to disagree if you want to have any chance at success.
Ready to violate every rule above and pay the piper? I’m going to illustrate a rather trivial example where seemingly minor decisions turned out to be pivotal. Pivotal like a path diverged in the woods. Even Frost notes the paths themselves were worn equally the same, it’s just a matter of how much we believe that our choice — or lack of — made all the difference, and more importantly; what are we going to do about it now that we have been made aware of the ideals above?
A butterfly flaps it’s wings in Brazil and sets off a tornado in Texas….
The butterfly theory states that a small change in a dynamic, nonlinear systems can lead to large changes. Dynamic systems are those where the behavior of the system at a point in time influences it’s behavior in the future, and nonlinear systems abide by exponential rather than additive relationships. Weather predictions are a good example of this in practice; the complexity of the task is something we take for granted. The takeaway here is that where you are now is related to several small seemingly unimportant decisions that have converged and reacted in ways that you could never have imagined — so be ready to change course, understand that everything you do has an impact (you just don’t know how much yet), and finally, there is an order behind random events.
Imagine that you have a system that ingests data from a series of sensors at an extremely fast rate, and you would like to allow for really quick queries over this data; you would need to choose a database that scales so you have a couple of forks in the road here — do you want to scale vertically, meaning adding power and memory on an existing box until you max it out, or horizontally — where you add more machines and pool them together in a cluster. Let’s assume the amount of data you were required to store made the vertical choice not only cost prohibitive, you would reach the physical limits of your hardware in the future.
Everything is going well then you get a new feature request :
“As an end user I would like to view a summary of key data points like size of data from each sensor in bytes grouped by day“
How you handle this request will make all the difference, you know that doing a distinct() or group_by() across all the data to get an exact sum will be extremely costly so your first question should be — does an exact number make a difference with this data set or could you use an approximation? You start to dig deeper and realize that due to up time, communication issues, even lack of full visibility you even question whether the data you are querying really is an approximation of a more holistic data set — in complex systems and especially systems used in predictions the answer will likely be no for various reasons hence the need for data imputation which itself is an estimate- ugh. You open Jira and start adding a comment on the ticket:
“Could the result be an approximation? Is there a time constraint on the duration of the query?“
You think that adding the second question will guide the discussion and hit submit then start researching the various ways to run the queries needed to satisfy the ask. You are well into the TopN extension when you get an email:
Sigh — No, the customer needs exact numbers and we aim for sub-second response time as always.
This is literally a million dollar mistake, remember chaos theory — implementing the task above will require extra hardware, a new (expensive) database that can handle this type of ask within that timeframe and will violate the first ideal, locality and simplicity — let’s walk it back. Not only are you making a major change thus lead time for changes increases, and you find out that the only way to ensure you stay in the performance bounds is to sacrifice stability so you start seeing more downtime and your time to restore service metric starts taking a hit.
You want to pull the Andon cord but quickly realize that it’s gone, you are now at an inflection point — knowing that the concept of improvement of daily work has managed to fade and you remember the pillar that supports all the ideals: you scan the book and find it.
“Psychological Safety, where we make it safe to talk about problems, because solving problems requires prevention, which requires honesty, and honesty requires the absence of fear.”
You realize that it’s the people that make all the difference …., if you want to know how the author overcomes situations such as the one above pick up the book and give it a read — with a highlighter if possible!
By Joshua McDonald on January 6, 2020.
Exported from Medium on August 26, 2026.
Reader discussion