Most start-ups invest significant time and energy in defining their product strategy, and with good reason; after all, it’s the end product you’re hoping prospective customers will buy. However, as your product evolves and starts to achieve product-market fit, it’s essential that an equally important strategy is conceived. To ensure the success of your product now and long into the future, you need to define and execute an engineering strategy! 🚀
In this blog, I’ll walk you through the process we followed at Immersive Labs, starting with how we defined an inspiring vision, to how we leveraged objectives and key results (OKRs) to execute our strategic priorities. Finally, I’ll show you how we evolved our strategy to provide greater clarity on what the next 12-24 months have in store.
My hope is that this will provide inspiration for those looking to elevate the impact of their engineering team and support the long-term success of their product/company.
A vision of the future
When setting out to define a strategy, the first question you might ask is: “Where do I start?” For us, the answer was creating a vision; one we hoped would guide and inspire the work of our engineers over the next three to five years. Our aim was to create a vision that aligned with the overall mission of Immersive Labs, and which would resonate with our engineering team. Clear lineage back to the overarching mission of the company was a critical part of the process. This ensured our engineers understood how the work they do every day contributes to the success of the company.
To define our vision, we set up a session with our engineering leadership team and several engineers that have broad domain knowledge, which gave us input from a wide range of perspectives. As the session was run virtually (during the lockdown in the UK), we used a Miro board to make it as collaborative as possible (you’ve got to love virtual post-it notes!).
The agenda for the session was as follows:
- Ideation – identify on post-it notes all the ways engineering can help the company achieve its mission. For example, we can provide a scalable platform that meets the demands of our growing user base.
- Themes – group the ideas from the ideation session into themes. For example, reliability was a common theme that emerged, as was the ability to deploy changes quickly and safely.
- Vision statements – each person writes a vision statement that encapsulates the themes identified.
- Finalize the Vision – debate each vision statement and modify it based on feedback. Then use dot voting to pick the final vision statement.
The output of this session is the vision statement below, which has played an integral role in guiding all the amazing work our engineering team has undertaken over the past 18 months.
As a world-class engineering team we’re creating:
A highly stable, secure, scalable, and extensible platform 🏆
That enables evolution at pace 🚀
To deliver market-leading cyber experiences 🔐
You may notice an emoji at the end of each line of the vision (we love emojis at Immersive Labs 😍). These emojis have become a simple and effective way to communicate how each piece of work supports our vision. For example, an initiative that improves the performance of our automated test runs as part of CI would have the 🚀 emoji, as this helps us evolve our platform even faster.
Measure what matters
Having shared the vision with the engineering team and the rest of the product organization (remember to over-communicate 📣), our next challenge was working out how we would deliver our top priorities. A popular approach used by many successful companies, including the likes of Google and Intel, is objectives and key results, better known as OKRs.
Given our team had previous experience using OKRs, we decided to use this approach and opted for a cadence of setting OKRs each quarter. We found a quarter provided enough time to deliver bigger pieces of work while allowing enough agility to pivot into new problem spaces.
With an agreed method of execution, we needed to define our first set of OKRs, and again we opted for a highly collaborative approach to do this (yes, this meant another Miro board and more virtual post-its 🤓). Throughout the session we used the vision statement as our guide, ensuring the OKRs took us a step closer to the vision.
The agenda for the session was as follows:
- Themes – with the vision statement in mind, write down key themes/principles and group them.
- Objectives – record two to four big objective statements based on the themes; these should be inspiring, aspirational, and non-measurable. Use dot voting to select the objectives.
- Key results – define one to four indicators for each objective, which are the measures that would prove if the objective is being achieved.
- Targets – set a target for each key result that should feel uncomfortable, but not impossible!
- Tasks/initiatives – list the various tasks/initiatives needed to help deliver the OKR.
- Bring it all together – write a set of draft OKRs! 😎
The screenshot below shows the output of one of our planning sessions, where two draft OKRs were defined:
After some asynchronous tweaks to the OKRs, we were ready to start executing! 🙌 To be successful with OKRs you need to make them visible and ensure they’re tracked regularly. We used a Google Sheet to track our OKRs, which was shared with the engineering team, product management team, and wider business.
We planned the work required to achieve the OKRs in various ways: within individual teams, particular disciplines (e.g., frontend engineers), and guilds (special interest groups, such as our accessibility guild). The goal was to identify key tasks that would move the needle on the key results. The work was then delivered through one of our product teams, with the support of our product managers, or via one of our platform teams, which have a greater capacity for engineering tasks.
The progress of OKRs is either tracked through weekly check-ins with engineering leadership, or monthly check-ins that are open to the whole engineering team. The progress of each OKR is discussed and the value of the key results is recorded. The status of tasks/initiatives and any concerns/blockers to completion are also covered. The owner of each key result provides a confidence score (on a scale of 1-10) in achieving the target by the end of the quarter, which helps with prioritization and course correction. If the confidence score is 10-out-of-10, it’s usually a sign the target was too easy!
We’ve been using OKRs for the past six quarters, and they’ve provided our teams with a greater focus that has enabled us to make great strides towards our vision!
Evolution, not revolution!
After successfully executing OKRs for a couple of quarters, we started to realize that the vision, although inspiring, did not provide the engineering team with enough visibility of the problems that needed solving in the next 12-24 months. For this purpose, we decided the vision was too nebulous and lacked the strategic detail to really bring things to life.
What we needed was evolution! In practice, this meant documenting the midterm (12-24 month) strategy, which we agreed to break down into the following areas:
- Engineering Vision – our starting point that guides and influences all the work we do.
- Cross-Cutting Strategy – problems that cut across all engineering teams, such as security, observability, and CI/CD.
- Front End Strategy – problems specific to our frontend React app, such as the build system, dependency management, and design system.
- Back End Strategy – problems specific to our backend Ruby on Rails monolith, such as domain-driven design and database performance.
- Infrastructure Strategy – problems specific to our AWS infrastructure and K8s implementation, such as global performance, network architecture, and identity management.
- Quality Strategy – quality-related problems that cut across all engineering teams, such as subcutaneous data testing, quality metrics, and exploratory testing.
- Delivery Strategy – although not part of engineering, delivery (agile coaching) plays a critical role in supporting teams with their agile processes, ways of working, tooling, and so on.
An example problem can be seen below, which is tied to the vision by the relevant emoji:
The strategy resides in our internal wiki (powered by Nuclino), and is a living document, meaning everyone in engineering keeps things up-to-date. The prioritization is something we review regularly, especially the urgency, as problems often become more critical over time.
This strategy has become the primary input into our quarterly OKR planning cycle, and has provided some much-needed clarity to our teams about the problems we need to address now and in the future.
Conclusion
The approach we’ve taken at Immersive Labs to define and execute an engineering strategy has proved highly effective, and has enabled our team to deliver significant improvements to our platform and SDLC. If you decide to adopt any of the approaches outlined in this blog post, there are a few things to bear in mind to emulate our success.
Firstly, make the process as inclusive as possible. Seek input from a wide range of perspectives and embrace the concept of co-invention, which will help ensure your teams are fully engaged with the strategy.
Secondly, don’t plan your engineering strategy in a silo. The strategy needs to support and complement the company’s mission and product strategy. You need to bring your product management team on the journey, so involve them early on in the process and consult them often. If product managers understand the engineering strategy and the value of the OKRs, it facilitates productive prioritization discussions during sprint planning.
And finally, adopt the agile mindset of kaizen, which means continuously improving how you work. We’ve learned so much over the past 18 months, and each quarter we strive to keep improving how we plan, track, and deliver our engineering strategy.
