The two work types that I see are odds more often than not are the business projects and the internal projects. Why can’t we easily integrate these two types of projects into a single roadmap? What I think is the problem is product and engineering see two very different views of the code. Most people think code is a stable, structured thing, like steel in a skyscraper. But that’s where everyone is wrong.

It feels kind of strange to write this one, and the following post, because it seems like it should be self explanatory. Today’s topic is on trust, and why its foundational to a team. More importantly, how teams may not recover if trust is broken. Effective teams need to be able to trust each other. We’ve all heard that multiple times, but why? That’s what I want to explore in this topic, not as some BS productivity coach, but as a guy trying to keep his team together.

Recently, I had the opportunity to read The Five Dysfunctions of a Team: A Leadership Fable (on O’Reilly ) and wanted to provide my thoughts on it. The book follows the story of Kathryn, who took the position of CEO at a dying startup tech company. The company can’t ship software effectively and is having internal problems with its C-Suite leadership team. The team itself is highly dysfunctional and cannot come to a single decision in multiple hours of meetings.