Of all organizations defects and challenges I’ve witnessed, a disconnect between planning and execution is among the most common.

A disconnect between planning and execution happens when separate groups are responsible for defining what must be done and for getting it done. It takes many different forms depending on the company, but produces the same detrimental effects.

Organizational patterns

This disconnect is the norm in top-down structures where leadership tends to concentrate decision power. Objectives are task lists (e.g., delivering features and projects) rather than outcomes. Teams are at the service of a cascading roadmap.

More surprisingly, this disconnect remains a common problem in modern product organizations, where durable pluridisciplinary teams are designed to have complete ownership over one aspect of the company’s value chain. It can appear in different places:

• Between leadership and product managers, when the latter are not responsible for outcomes and empowered on solutions. The structure may resemble that of a product organization, but remains top-down in practice with leadership calling all the shots. Product managers responsibility is narrowed down to the the animation of the backlog and the agile ceremonies.

  

  
  

• Between product managers and engineering teams, when this relationship is too distant or lacks trust. Product acts as a thin interop layer between strategy and execution, therefore closer in responsibility to the traditional Business Analyst or Project Manager.

  

  
  

Regardless of its particular incarnation, the disconnect between planning and execution will inevitably poison the ability for an organization to operate at its full potential.

Recognizing the symptoms

Lack of focus

This is the most common symptom. You hear complains that “teams are spread to thin”, or that “we start a lot but finish too little”.

Indeed, the most immediate consequence of divorced planning and execution is that planners do not experience the consequences of their decisions. This is not a case of bad intent, but a side effect of the organizational design.

When the number of opened topics is too high, their relative priorities become indiscernable (i.e., “when everything is urgent, nothing is”). Context switching is high, further eroding the teams ability to succeed. Worst, it creates tension among interdependent teams as they juggle with conflicting priorities.

Lack of alignment behind the mission

Organizations where planning is disconnected from execution tend to have an unfair assessment of engineers engagement. Indeed, as teams are struggling with the dozens of priorities emerging from a disconnected planning process, their efforts in navigating the resulting chaos should demonstrate nothing but strong engagement.

It can however appear like engineering does not share the same sense of urgency than leadership on the business problems. This should not come as a surprise: they were never trusted with these problems in the first place! You cannot both deprive engineers from the strategic aspect of their work, yet blame them for not being sufficiently product or business-minded. That is not to say that all engineers should feel strongly about the product’s direction, but I have yet to see an organization where none of the engineers would participate in the decisions if offered the chance.

As @VaughnVernon elegantly puts: “if your engineers aren’t challenged with a business problem, then they’ll challenge themselves with technology problems.”

Process efficiency as a measure of success

How success is measured is the most accurate marker of expectations. Organizations where planning is disconnected from execution tend to measure engineering success on process efficiency alone. Indeed, why would an engineering department expected to ship features and nothing more be evaluated on anything but its efficiency at shipping features?

This is where you may see reports about velocity, numbers of pull requests merged, or numbers of bug resolved. As we discussed in communicating engineering activity: while those metrics may be useful for continuous improvement, it is rarely a good sign to see them used as measure of success.

Escaping the build trap

Closing the feedback loop

Planners do not get to experience the consequences of their decisions in situations where the responsibilities of planning and execution are split across different groups. Addressing the issue must therefore start by closing this feedback loop.

In the best of worlds, an organizational change would put both responsibilities in the hand of empowered groups, incentivized on outcomes alone. This is the ideal rightfully defended by the advocates of product-led organizations such as Marty Cagan, but often hits two practical obstacles. A first obstacle is that unless the organization was product-led from its inception a significant culture shift must happen. A second is that no organizations is ever truly 100% outcomes driven (Intercom published an amazing blog post on that topic) and that some planning decisions inevitably remain exogenous to the teams in charge of execution.

Can we expect this team to successfully deliver on both these initiatives? Is our current load compatible with the starting of a new project? These questions are difficult to answer without a strong sense of the reality of execution. Worse, it is impossible without this visibility to visualize the ripple effect of our planning decisions. When the knowledge of execution doesn’t feed into the planning process, or only does so artificially through point-in-time estimations, the performance of the organization as a whole degrades. The only way out is to constantly feed our knowledge of execution as inputs to the planning process.

Shining a light on the reality of the teams activities will surface the challenges in executing on a multitude of potentially-conflicting goals. For this purpose, anecdotal evidence and gut feelings are an insufficient feedback loop: data is mandatory. Measuring the reality of engineering teams activities is a notoriously hard problem: organizations traditionally rely on tedious hour-based time declaration, or heavyweight processes based on leveraging issue trackers.

Outcome-focused communication

Many books describe the ideal that companies should aspire to reach, but few cover how to get there: Melissa Peri’s Escaping the Build Trap is one of them. In this book she writes:

If there is one main reason I have seen companies fail to make a transition, it’s the lack of leadership buy-in to move to an outcome-oriented company. Leaders will say that they want to achieve results, but, at the end of the day, they still measure success by features shipped.

[…]

Visibility in organizations is absolutely key. The more leaders can understand where teams are, the more they will step back and let the teams execute.

[…]

Many companies fall back into bad habits because they have not figured out how to consistently communicate progress across the company in the form of outcomes. When leaders do not see progress toward goals, they quickly resort to their old ways.

As we’ve discussed on the topic of managing technical debt, expressing our activities in terms of desirable business outcomes is crucial. It gives engineers a sense of purpose that goes way beyond closing tickets and checking boxes off a task list. It also makes engineering activity understandable to anyone, using business outcomes as the universal language of the company.

How Echoes helps escape the build trap

If Echoes alone cannot change your company’s culture, we’ve designed it in no small part to help companies escape the build trap and create the best context for teams to succeed.

• Echoes surfaces the reality of engineering teams’ activities without tedious time-tracking or heavyweight process. It acts as your field-level sensor and closes the feedback loop between planning and execution. Perhaps you have agreed to dedicate 25% of your bandwidth to paying off technical debt: Echoes will show you whether this target allocation is happening in practice. Perhaps you’ve started a new initiative with the assumption it would only impact a limited area of the organization: Echoes will show whether it unexpectedly hurts the focus of other teams.

• Echoes reports activity on outcomes over vanity metrics of outputs. For engineers, Echoes makes the link between their day-to-day work and purpose visible. For leadership, Echoes shines a light on investments in the most understandable way.

Echoes creates the shared context necessary to elevate conversations from the efficiency of the development process to the product-engineering contribution to the business strategy. Let us help you escape the build trap!