00 - Keep It Simple

Like the title says, keep it simple.

Thinking of adding a new governance board, working group, meeting, or other congregation of people? Perhaps it’s better to repurpose an existing one and deprioritize other things that group is working on.

Thinking of building a microservices architecture in order to improve speed of software value delivery? Not so fast! Microservices are usually not the solution! You probably want to improve and simplify the current software development and coordination process you’re using. Also, you should always start with a monolith. After all, if you can’t build a well-organized monolith, what makes you think you can handle microservices?

Focus first on ways you can remove work, whether via process or otherwise, in order to make things simpler. There is a shocking amount of process in large organizations that adds no value whatsoever. Furthermore, the human energy and time required to follow those process actually detracts from doing more valuable work. Seek ways to eliminate process steps or work at every opportunity.

Recognize opportunity costs

There are costs to being slow. If you’re a private-sector organization then the cost might be missed market opportunities and therefore profit. If you’re a national security organization then the opportunity cost might be that your enemies can innovate faster than you and therefore get inside your decision cycle. Regardless of the application, recognize that being slow is very costly! Security efforts are important, but they also reduce speed. What is the balance? Reducing duplication of effort in a large software organization is important, but that requires centralized coordination (and we all know how well centrally-planned economies work), so how much slowness due to centralization are you willing to tolerate.

Sometimes it’s better to let 5 teams work on the same thing, come up with different solutions to the problem, and have the internal market dynamics of an organization determine what the actual solution will be rather than go through a series of product backlogs, change control boards, and steering groups, in order to decide who will build what and when. It’s almost never worth it to try to centrally control and manage development efforts in a large organization. You’ll end up doing everything more slowly, more expensively, and with less user value than you would if you let teams iterate independently towards the same strategic objective.

There are numerous possible examples out there, but they all represent one underlying philosophy: keep it simple.