After reading The Unicorn Project by Gene Kim, I wanted to write down the part that I want to keep with me: the five ideals.
Reading something and agreeing with it is relatively easy. Remembering it when you have a busy day, several things competing for your attention, and a problem that needs fixing is a different story.
That is why I am writing this post. I want these ideas somewhere I can return to, think about, and gradually apply to the way I work.
My background is in infrastructure and virtualization, so that is naturally where my mind goes when thinking about them. Dependencies between systems, manual tasks, troubleshooting, documentation, and the way teams work together. There is plenty to apply here.
1. Locality and Simplicity
The first ideal made me think about how much coordination a seemingly small change can require.
If changing one thing means understanding several unrelated systems and involving multiple teams, that is complexity we have to carry every time we do the work.
For me, applying this ideal starts with making things easier to understand and giving people enough ownership to complete a useful piece of work.
In infrastructure, that could mean a script with a clear purpose, a documented dependency, or a standard configuration that removes unnecessary differences between environments.
I also want to apply it to what I build myself. If I come back to a script six months later, will I understand it? Could someone else use it without needing me to explain every step?
The question I want to remember is:
Can I make this easier to understand, maintain, or change?
2. Focus, Flow, and Joy
This one is easy to relate to.
You start working on something, begin to understand the problem, and then a message arrives. You switch to another task, answer a question, check something else, and eventually return to the original problem.
Now you need to rebuild the context before you can continue.
What I take from this ideal is that being able to focus depends partly on the conditions around the work. Clear priorities, useful tools, and fewer unnecessary interruptions all matter.
I like that joy is included as well. There is satisfaction in understanding a difficult issue, getting an automation working, or finishing something you can see is useful. I want to pay more attention to what makes those moments possible.
What is making it difficult for me or the team to finish useful work?
3. Improvement of Daily Work
This is probably the ideal I most want to keep visible.
It is easy to keep repeating a manual task because doing it again feels quicker than stopping to improve it. The same can happen with an unclear procedure or an alert that produces more noise than useful information.
There is always something more urgent.
My takeaway is that improving how we work needs a place in the work itself. Otherwise, the same frustrations keep coming back.
That improvement can be small. Document a step that causes confusion. Fix a recurring script failure. Remove an unnecessary handoff. Automate a task once the process is understood.
I want to get better at noticing those opportunities and doing something about them while the problem is still fresh.
What did I struggle with today that I could make easier next time?
4. Psychological Safety
People need to be able to say that something is wrong, that they made a mistake, or that they do not understand a decision.
That sounds straightforward. The difficult part is how we respond when it actually happens.
In infrastructure work, uncertainty matters. Someone saying “I am not comfortable with this change yet” might be pointing to a dependency, a missing test, or a recovery assumption that needs attention.
I want to remember that my response helps determine whether they will raise the next concern.
For me, this means asking questions before making judgments, being honest about what I do not know, and making room for people to challenge an approach, including mine.
There still needs to be accountability. There also needs to be enough trust to discuss what happened and learn from it.
Am I making it easier for people to raise a problem early?
5. Customer Focus
Working with infrastructure, it is easy to spend most of our attention on the platform: the hosts, storage, networks, versions, and configuration.
Those details matter. I also want to be able to explain how the work helps the people who depend on it.
For an infrastructure team, that connection might run through an application team or an internal service before reaching the end customer. It is still worth following.
A disaster recovery improvement should help restore a useful service. Automation should reduce waiting, errors, or manual effort. A platform change should solve a problem we can describe.
This gives me a useful check when deciding where to spend time, especially when an interesting technology comes along.
Who benefits from this work, and what gets better for them?
How I Want to Put This into Practice
I do not expect to finish the book and suddenly apply all five ideals consistently.
I want to start with something manageable: a short reflection at the end of the week.
- Where did unnecessary complexity get in the way?
- What helped or interrupted focused work?
- What recurring problem did I improve?
- How did I respond to questions, mistakes, or disagreement?
- Can I explain who benefited from the work I completed?
Some weeks, the useful outcome might be identifying one thing to change the following week.
That feels like a practical place to start.
The five ideals give me a way to look at everyday decisions more deliberately. Writing them down is my first step toward remembering them when I need them.
The next step is to use them.
Further reading: Gene Kim on the Five Ideals.