The priority gap: Why engineering teams have to stop delivering to themselves in early project milestones

The majority of modern technology teams following a Lean-Agile path are familiar with the “deliver early and often” approach. Even though continuous milestone delivery is a common focus, directing efforts to put something in the client’s hands as early as possible to build trust, is not.

Too often development teams get stuck in delivering to “themselves” and prioritising technology. This alienates the product owner, analysts, sponsor and any non-developers who really need to see progress and problems being solved in a way they can understand – especially in the beginning of the project. Odds are, the business spent months, if not years, trying to sell the project internally before being able to bring on a development team. When the project finally kicks off, it’s only natural that the business feels some excitement and nervousness.

What normally goes wrong
Development teams are technically-inclined, so they will naturally focus on the foundational technology in the beginning. This is important, but doesn’t have intrinsic business value. The time spent on algorithms and the back-end is difficult to showcase to non-technical stakeholders, and will often be seen as invisible work.

Business loses interest if there is too much focus on engineering preferences in early milestones. This will cause stakeholders to feel overwhelmed and isolated from the project. At the other end, if an effort is made to include the business at the start of the project and the focus is on business priorities, stakeholders’ sentiments will increase and trust will grow. The difference between these two scenarios create a priority gap between business and the development team.

Delivering something that keeps stakeholders engaged
It’s important to gain the business’ trust while relationships are still new by involving everybody in initial phases instead of diving into deep tech work. Technology teams should show that they are keeping the stakeholders’ priorities and concerns top of mind – even if the technologists don’t share those particular concerns. The priority gap causes the business to feel disillusioned and no longer in control of their project, which leads to mistrust early on in the project, before the relationships are there to lean on.

Engineering teams need to be empathetic and reciprocate their concerns of what the business feels the key risks are in the project. It’s important to demonstrate these concerns early on in the project and in a language that the business and stakeholders will understand. This can often be done with visual outputs, or workshops, findings and models which speak directly to those top priorities, instead of new ones which the business doesn't understand or worry about.

The third principle from the Agile manifesto tells us to deliver early and often. However, it’s not always clear what needs to be delivered early and often during the early phases of a project: business value. Business value is often just about reciprocating priorities and sharing empathy with stakeholders. When development teams prove that they’re focused on providing business value, the priority gap closes.