Kung Fu .NET

Cool stuff found out on a dev journey

6 lessons I've learned from The Phoenix Project

1. Taking risks must be a part of the company culture

Failing fast with new ideas, taking lessons, and improving is way more effective than just following the standard way of work. Every time you take a task, think about how you can do it more effectively next time - and if you know how to improve it, try very hard to find the time to make that improvement, because delaying it for some "unknown later" will lead to technical debt (both on a project scope and a personal scope). Try to allocate some Dev & IT time towards nonfunctional requirements. John is a security guy who goes through a change of work approach over the course of the book. At first, he's excluded from the meetings, but after he starts to take the initiative and the risks, he transforms from a progress blocker to an important asset.

2. Documenting key project knowledge is required

The perfect solution would be to document every detail, so when a big project is rolled out (as the project Phoenix himself), we know every detail of the step that was taken. In real-life projects, there's not enough time to document everything perfectly, so focus on the frequently repeated and complex processes (employee onboarding, VPN configuration, custom integrations with vendors, etc.).

3. Slack time is important

In the book, there's a guy called Brent, who is the "know-it-all" type of guy. Brent is resolving different issues in many systems and knows undocumented processes, so only he's able to solve them. Why is that? Brent is always busy, firefighting and working on some projects, which means until he's done with it, he can't take on any new work. As in the theory of constraints, having some slack time/a time window is important, so it can be filled with new improvements or documentation work or taking some priority work items.

4. High trust and engineering spirit

Transparency, mutual trust, and vulnerability are not easy to have in a team but are required to function properly. Mutual trust - saying that you can't finish the task on time due to not having the required knowledge is way better than lying that something unexpected occurred. Next time this type of task is done, the team will know that it requires some nonstandard competency. Vulnerability - in the book, the CEO Steve encourages others to share personal info about themselves. By opening up we see each other more as a human, with stronger relationships, improved self-acceptance, and less ego. Transparency - Brent didn't share the details of his work with his colleagues on a constant basis, so they couldn't help in many ways. Documenting the configuration steps, architecture, having visible CI&CD processes, and plans will help the organization of work.

5. Priorities

Brent wasn't always doing the highest priority work, due to a lack of organization he tried to pack in less important work projects or work that could be automated or passed to somebody else.

6. Every company is an IT company

At first Steve, the company CEO says "IT is like keeping the toilets running. I should never have to think about it". After seeing that IT is an integral part of the business and as technology use becomes more pervasive, the companies must keep up and advance, his view on the IT employees transforms from toilet janitors to essential workers. It's still common to find companies that are fighting their IT departments and not embracing the long overdue change, but they find themselves at a competitive disadvantage. Lately, I've been trying to plan my kitchen, so before going full-on Blender and modeling I've decided to see what tools different companies have to offer. For example, IKEA has a great and intuitive tool to design your kitchen that opens up in the browser, but other companies were lacking in their tools or just didn't have them. I think that it can be a deciding factor for customers who are interested in getting a new kitchen.