This winter holiday season, I spend some time listening to a new book by the author of the famous “The Phoenix Project.” As I really liked that book, a new novel about the DevOps movement was on my reading list long before the release.

“The Unicorn Project” is a fiction and not a technical guide for DevOps practices. So, keep that in mind when looking for your next reading. The events of the story happen during the same period as the events in “The Phoenix Project” and complement each other. However, you don’t have to read “The Phoenix Project” first to understand the setting of the new book.

The book elaborates about “Five Ideals,” or I would rather say five ideas that are all crucial parts of creating high-performance organizations. So, let’s talk about them in more detail.

Locality and Simplicity

Despite their benefits, segregation of duties and functional organizational structure create complex processes and introduce lots of delays. Taking to the extreme such as “Phoenix Project” in “Parts Unlimited,” even simple IT tasks sometimes might require weeks and months to complete.

Modern applications and computer systems usually consist of multiple components: servers, databases, network connections, mobile apps, etc. If each component is managed by a separate team and you have to create request tickets to ask them for assistance, it becomes like a quest game where you need to gather 50+ items in a specific order to complete the task. It might sound fun for quest lovers from the game perspective, but if you need to submit dozens of requests and got other tens of approval each time to complete simple tasks, it becomes a real nightmare: instead of doing your job, you constantly fight some dumb bureaucracy.

Don’t get me wrong. I’m not advocating against processes. They are necessary to bring order and ensure predictable outcomes of your work. However, when they become Godzillas that require A1 sheet to draw, it is probably high time to review and simplify them.

In contrast, if you have most of the required skills in your team to complete 80% of your daily tasks without creating 10+ process diagrams, you might be really impressed by how fast and how much value you can produce in a single day. Also, from the operational point of view, the simpler and smaller a solution, the faster it works and less maintenance effort it requires.

Focus, Flow and Joy

I believe that almost all engineers and developers during their carrier have these hard times when you try to concentrate on an important task without success. A phone rings, an instant message pops up, a colleague stops by your desk and asks you something – you probably know that feeling when just a moment ago you were close to solving “a puzzle,” and suddenly you get distracted and completely lost your focus. On the contrary, sometimes you can accomplish more in just a few quite hours than in a whole busy week. So, what’s the trick?

People are bad at multitasking. That's the truth of life. No magic. Context switching consumes lots of mental energy and it requires 10 to 20 minutes to get back to “The flow.” Just imagine, 10 distractions per day can cost you more than 3 hours of productive work. Plus, your energy level is not the same high during the day. So, if you waste your most productive hours on some useless meetings or administrative tasks, don’t wonder why you feel exhausted and cannot perform any creative work despite having a couple of “free” hours in the afternoon.

I already wrote a few articles about personal productivity, so check them out if you want to know more about organizing your time.

Improvement of Daily Work

"Beware the man who says he has 10 years of experience, who actually has 1 year of experience 10 times." If you just do the same job every day and don’t invest a portion of your efforts into improving it daily, you will either become obsolete due to automation of your tasks or lose to competitors who seek better ways to do the same job more efficiently.

A few years ago, I was impressed by the idea of keeping operational work below 50% of your time described in “Site Reliability Engineering: How Google Runs Production Systems.” It seems evident that the less toil you have, the more time you can dedicate to improvement. It can be learning new skills, making your system more reliable and responsive, replacing ineffective parts with more productive solutions, decommissioning obsolete systems to free up more productive time, etc. However, it is not so easy to implement that idea in practice because, naturally, people are resistant to changes.

Apart from that, the widely discussed phenomena of technical debt and the natural tendency of complex systems to entropy both contribute to the process deviation from an ideal (most effective at some point in time) state. Regarding the IT industry, constant changes in hardware, software, processes, organizations impede our progress to “the better future.” On the contrary, changes are an unavoidable part of organizational evolution. Something that worked perfectly just yesterday, today might become a restrainer due to the changed conditions in a company, on the market, or somewhere else. The truth is simple: you either improve or degrade — no middle ground.

Psychological Safety

This ideal I would personally put into the first place because fear is one of the strongest natural feelings. It is really unwise to underestimate its devastating impact on individual and team performance. On rare occasions, fear might help to mobilize your resources and achieve extraordinary results, but if this state becomes constant, it will just suck up all your life energy and put you into bed in better case.

I had experience working in the team where the former manager punished the subordinates on every occasion. Even the smallest mistakes weren’t forgiven. If you were performing as required you lived, if you were falling behind, you got your porting of lashes. The people were unwilling to express any kind of initiative because the best they could expect was “business as usual” with no benefits for them. If something went wrong, you got a fine or pay cut. Sounds motivating? I doubt that. Eventually, that behavior cased the team’s stagnation and full inability to perform its duties according to the business requirements.

It took me almost two years to change the perception of mistakes in that team and to create an environment of trust. Only when these people believed that they could safely make and correct their errors, the team gained the level of self-sufficiency enough to face the upcoming work issues with confidence. Creating a blameless work environment, to my mind, is the most important work that any manager can do for his or her team. Entrusting your subordinates or teammates to do their best is the required prerequisite to long-lasting high organizational performance.

Customer Focus

Understanding your customers, even if they are just other teams in your organization, is the map to your success. Your performance might suck, you might have huge technical debt, but if you understand what business value you should deliver, it's like having the map of pirate’s treasure in hand. You might lack the information about the exact steps required to get to the point, but at least you know where the gold is.

Many average engineers and developers tend just to perform their technical work and do what they have been told to do. On the one hand, focusing on your primary job duties is essential for successful employment. On the other hand, the ability to see a little bit further and go the extra mile can significantly differentiate you among hundreds and thousands of other tech folks.

The difference between good and exceptional professional is that the latter can map the flow of business value and understands who exactly contributes to his or her paycheck. According to some researches, that difference can be as much as 10x in business impact comparing to some John or Jane who just toils from 9 to 5.

Final notes

Despite a high interest of mine to the subject of this book, I wouldn’t call it a masterpiece. This novel has lots of logical and literary weaknesses, so some book parts should be perceived with a bit of irony. To my mind, too much attention is devoted to the feeling of the main character, Maxine, but the connection between her emotional state and the story is mostly unclear.

Moreover, the motivation of “the rebellion” to change the way “Parts Unlimited” works is also somewhat idealistic and unrealistic at the same time. Judging from the plot, all the rebels just wanted “to do a great job,” “have great feelings about the work they do,” “make the company better,” “feel good about solving complex engineering problems,” and other “blah-blah-blah” mottoes. It looks like there are no other companies or job opportunities in the area to look for, and “the good guys (and gals)” just work “to make the company great again.” If I were one of the book’s characters, the first thing I would do is to question whether the cost of such efforts worth the possible benefits. By benefits, I mean personal goals such as promotion, pay rise, relevant work experience, data for your studies or any other what is appropriate in your case.

The last piece of criticism is about the level of synergy when almost all company employees are good people with only a few “villains.” In real life, the bigger the organization, the more forces and parties are involved in the daily politics game. So, in more realistic scenarios, I would expect such drastic transformations ether to be more local (see the first ideal) or to involve much stronger leadership intervention to align key political groups, which are natural parts of every large organization. "Life is not always black and white; it's a million shades of grey."

Nevertheless, I enjoyed listening to this book and highly recommend her to everyone interested in DevOps culture, organization performance and self-development. So, go, grab your copy and have a good reading!

P.S. If you are looking for other books like that, check out my review of “The Phoenix Project.” Also, you can find more practical advice on the principles and ideas of DevOps in non-fiction “The DevOps Handbook” and “Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale.”