Matt Johnson

an experienced leader in technology
[email protected]

2nd June 2023

It’s not about engineers, exactly

When building engineering cultures I have previously used the principle of “Engineering First” as a guide for building not just excellent teams, but also excellent products and cross-discipline cultures. Some people might recoil at the name “Engineering First” since it might sound a little too exclusive, or place too much emphasis on engineering as a profession. But I hope to dispel those ideas and describe how an engineering first culture can assist your organization in delivering faster, better products.

Starting at the start

In the process of building software, we can roughly outline the Software Delivery Life Cycle (SDLC) steps as follows:

  1. Idea
  2. Research
  3. Validation
  4. Plan
  5. Design
  6. Build
  7. Test
  8. Deploy
  9. Iterate

While different SDLC methodologies may have slight variations, they share a common characteristic: they revolve around a continuous loop that returns to the initial idea. Notably, the SDLC progresses from left to right, with “deploy” serving as the final step. Consequently, the Engineering First principle emphasizes the importance of providing the final step with comprehensive information gathered from the preceding stages.

Focus on the latter part of the SDLC

Although it may seem counterintuitive, considering the last step as the most crucial is vital. Ultimately, it represents the finish line, and enabling the team to cross it with the least amount of effort should be a priority. If we delve into these final steps, they typically involve contributions from test engineers, DevOps engineers, and software engineers—collectively referred to as “Engineers.”

Fuel to the engine of delivery

To drive successful delivery, the entire team, and indeed the organization as a whole, should provide engineers with as much information and support as possible. Recognizing that the team acts as the engine of delivery, it becomes clear that fueling their efforts should be a collective responsibility. While it is not solely the Product Owner’s duty to support the team, the entire organization must align its efforts to enable and empower the team wherever it makes sense.

Hence, the Engineering First principle emerges as a call to prioritize providing the team with the necessary resources, information, and support, enabling them to deliver at an optimal pace. It’s important to note that this principle is not solely about engineering or placing engineers above others. In essence, it could be referred to as “Delivery First,” as the sentiment remains unchanged.

Benefits of the approach

Implementing an Engineering First culture can be challenging, especially for organizations with non-software-focused backgrounds. It requires aligning the entire organization around the notion of fueling the engine of delivery and embracing a mindset of continuous product delivery. However, the benefits are tangible. Predictable high-velocity delivery becomes attainable, and meetings and objectives outside of engineering gain a clearer focus on their intended outcomes. Meetings can center around actionable content that contributes to product delivery, and associated metrics or key performance indicators (KPIs) become easier to measure. Examples include increased product and feature documentation, clearer tickets, more accurate ticket scoring, and stakeholders feeling heard and seeing their suggestions implemented. Ultimately, the goal is to maximize the impact of the delivery team’s work by focusing on actionable outcomes that the team can implement effectively.

Conversely, a lack of an Engineering First culture manifests when engineering teams receive vague or incomplete tickets, feel excluded from the backlog-grooming or ticket-creation process, or engage in prolonged back-and-forth exchanges with managers over unclear requirements. Such circumstances result in a loss of momentum for the team and diminished impact, which cannot be adequately measured with a burn-down chart. While more maintenance-type tasks might be completed, the overall effect is reduced.

How to get started with it

  1. Review your current backlog - Engage with the business and ensure that the description, intent, and approximate implementation effort of each ticket are clearly understood by everyone involved. Although this process can be time-consuming, it fosters a shared consensus on the value of the work
  2. Change your measurements - Story points, often used for estimation, tend to be one-dimensional and may not capture crucial aspects such as complexity, implementation effort, business value, and ROI. Choose a measurement approach that makes sense to all stakeholders and prioritize tickets based on agreed-upon business value during ticket elaboration and backlog grooming
  3. Bring business-people closer to delivery-people - Embrace flatter organizational structures to encourage direct engagement between delivery teams and business stakeholders. By removing middle managers, communication becomes more direct, facilitating efficient and accurate information exchange
  4. Shift mindsets - Cultivate a culture in which the business at all levels recognizes the value of engaging with delivery teams. This doesn’t require a drastic transformation but necessitates top-level support to foster open and fluid conversations. Over time, the broader business will come to appreciate the benefits of transparent communication and collaboration with delivery teams

By adopting an Engineering First approach, organizations can enhance their ability to deliver products efficiently, achieve meaningful outcomes, and foster a collaborative and results-driven environment.