Welcome to the next chapter of my blog series on our journey within Software Engineering. I will continue with the Building the Team theme, focusing this time on the Software Engineering strategy.

Building out our initial Software Engineering Strategy
Our initial focus on the strategy was fairly low-level detail mainly to start to socialise the need to iterate and evolve our Engineering culture within Software Engineering. It was also important to me to build a strategy which the team had the opportunity to shape. More crucially, I wanted a strategy the whole team supported, so we can get some focus and get better at this stuff.

In December 2015, ready for 2016, we ran 3 one-hour workshops to collect ideas and goals from the team. We did it in true Agile style, with post-it notes, dot voting and short timeboxed brainstorming sessions. We collected over 300 goals and grouped them into 32 areas, spread over 9 themes from 100+ Engineers.

In December 2016, ready for 2017, we iterated on the process from the previous year, this time limiting the scope to 12 themes and around 2 to 4 goals per theme because we learnt that we took on too much the year before. To help guide us, we applied some Work in Progress (WIP) Limits to limit how much we did. At a high level, we identified 12 key focus areas organised around People, Systems and Processes:


We also applied some guiding principles to underpin our strategy:

Guiding Principles – Culture

  • We have fun and love what we do
  • We own our stuff and are proactive
  • We help each other and get stuff done
  • We keep it simple
  • We deliver value that’s driven by the needs of our users
  • We use experimentation & A/B

Guiding Principles – Engineering

  • We shift to a Continuous Delivery in DevOps environment
  • We shift to a decoupled domain-based, service-oriented architecture
  • We have a focus on reducing errors
  • We build resilience and adaptability into our systems
  • We ensure our code is secure
  • We focus on automating everything, including tests and our pipeline
  • We consider NFRs from the outset
  • We have good engineering habits & discipline

Guiding Principles – Cross-Functional Collaborative Product Teams
• We are data-driven so we understand our quality & pace
• We continuously push ourselves to be better through iterative and
incremental improvement
• We reduce context-switching through limiting WIP
• We focus on good requirements from the outset
• We break our work down into small manageable chunks
• We have teams who have a well-understood approach to estimating work
• We aim for 3 to 5 days cycle time to reach “Definition of Done” from “Ready for Dev”
• We aim for our defect age to be consistently less than 5 working days
For the 2018 Engineering strategy, we have iterated a few steps further with our approach and broadened it across the whole of Engineering to set out our Engineering 2020 vision. In the coming months, I will post a blog sharing more details of our 2020 vision.

In the next part of this blog, I will share some of our experiences on ways of working and starting to build a Servant Leader culture… thank you.