I recently read through The Phoenix Project and it had tons and tons of good nuggets of knowledge.

“A great team doesn’t mean that they had the smartest people. What made those teams great is that everyone trusted one another. It can be a powerful thing when that magic dynamic exists.”

I think a lot of people lose sight of the fact that a team is more than just the sum of its parts. You could have five amazing developers working on a project but if they spend half their time fighting over useless crap it won’t get you anywhere. Trust is important. So is respect. Developers are a fickle bunch and if they decide they don’t like you, good luck trying to wrangle them into doing anything, much less on time.

“We need to create a culture that reinforces the value of taking risks and learning from failure and the need for repetition and practice to create mastery.”

Taking risks is definitely one way to spur growth. If you never take risks you’re going to be doing the same thing (and making the same mistakes) over and over again. My company just decided to switch from svn to git. There was the risk that some people wouldn’t understand the workflow as well, or that there’d be some mess ups along the way, but we made the leap anyway. And now just a few months later everyone is following a workflow that works for us.

“Improving daily work is even more important than doing daily work.”

I think this aspect of our work gets ignored too often. Improving the way we work is going to help us more than just putting blinders on and cranking out work as fast as we can. I know from experience that doesn’t work and even makes things worse. It wasn’t until we implemented release cycles and a (automation-friendly!) workflow that work started flowing smoothly, instead of a project constantly being in chaos. Take this example: everyone on a project pushes their code changes to the same branch (like in svn most of the time). The client only approves 3/5 of the finished tasks. Another half of the tasks are sitting on Dev and haven’t even been reviewed yet. So you have 3 tasks that can go live but let’s say, 12 tasks worth of commits piled up. So you log into production and check which files need to be updated. Sometimes, the files touched by tasks 1, 2 and 3 are separate from the files touched by tasks 4-12. But sometimes, they’re not. So what do you do? Put off the next release until they’re all finished. Or update the file anyway and then edit it on the server to remove something until the other task gets approved.

Eff that. Now that I am enforcing feature branches and making sure everyone works off master (so they branch off a stable base of the code), I can merge branches into a release branch any day of the week I want and push them to production with one command. No more sweating bullets as you carefully pore through lists of files and hope you didn’t forget a file or aren’t accidentally updating a file that contains changes that haven’t been approved. Talk about wasting time.

“Something seems wrong in a world where half the e-mail messages sent are urgent. Can everything really be that important?”

I think anyone who works with client projects knows this feeling very well. Everything is always on fire. Everything needs to be fixed ASAP. Why are things this way? I think most of what causes this is poor planning and prioritization. Realistic goals and development cycles have helped immensely in getting rid of the constant panic.

Another point: Reducing Work In Progress. People seem to think that if they just keep assigning you tasks that you will hopefully just hunker down and get them all done. Then unexpected work comes up and they keep adding more tasks — “these are for THIS week!” they say. Even though there’s still open tasks from last week. So then you blink and suddenly, you have 50 things on your plate that were all due yesterday. This is not the way things should be done. I think things work much better when a set number of tasks is decided to be worked on, and nothing else gets added to the list until those are done. DONE, as in on production and tested and working. Not done as in “I pushed code to the repo, now give me more work.”

Everyone who has a career anywhere in technology needs to read this book. Go on!