Pattern: Decide Closest to the Action

Those nearest to a change action get the first chance to make any decisions related to it

Decide Closest to the Action

Cloud native transformation is underway, and there is a lot of uncertainty. People are still learning about the tech, which itself is continually evolving, and the market is changing frequently and erratically. Each team is responsible for delivering its own microservice, and there are many moving pieces. Managers and lead architects have only a broad, high-level understanding of the product and little grasp of the technical details that underlie the actual development process.

In This Context

Decision making via chain of command is not sustainable in cloud native. Using hierarchy to resolve conflicts and agree on decisions takes too long, and solutions are limited to the capabilities of the managers making that level of decision. Engineers might find a superior solution that never gets implemented because it takes too much time and effort to navigate the bureaucracy to get permission. So they will give up and just move on with whatever they have.


Push the decision power as close as possible to any change as it is happening. It is typically best if the dev team itself makes the decisions.Because your team works as part of a bigger tribe of teams, sometimes your decision must involve others. For example, if you want to change APIs, you must inform those who use them—and they may object to the change. So whatever happens inside of a microservice is fully the domain of its development team, but anything going in/outis also the domain of the teams that consume them.


Executives delegate the power to create the vision and objectives to middle management,and middle managers delegate power over technical decisions to the execution teams.