Engineering the How - Part 1: Bringing technical priorities into the roadmap
Thoughts for first-time engineering managers series
In a previous post, I wrote about why an Engineering manager must partner with the Product counterpart. It is our responsibility as managers to define and share the engineering behind the business goal including other technical priorities.
Wait a minute, which technical priorities exactly?
Let's go deeper in this question. The way I see it is: there is no tech separate from Business in a company. Tech must serve the business.
By technical priorities we are talking about those that will always enable the business goals to be achieved: Platform improvements that accelerate the delivery, security work that keeps us in the market, quality actions that increase customer trust and satisfaction and many more.
It seems obvious, but easy to forget when we dive into what could happen in the future. We may lose sight of what needs to be shipped now.
Remember:
If there is no product or service to sell today, there will be nothing to scale tomorrow
Defining the how behind the What
- Start from the existing business roadmap - Understanding
Sit with your Product partner and walk through the roadmap and its priorities. (If there isn't one, I will try to cover that in a different post). For simplicity let’s assume your product manager knows what is doing, has worked on a roadmap and has validated it with upper management.
Depending on your context (company, business or product manager experience) you may have goals defined only for a month, a quarter or even a year. You will have to deal with those different scenarios. The more clarity you have the better you can plan and guide your team focus.
Make sure you understand the What and the Why behind each goal.
- Define goal by goal - Organize
For each business objective:
- Write a brief summary on the expected outcome and confirm your understanding
- Collect the main information your team may need
- Brainstorm with the team and define the solution
Disclaimer: Of course you do not need to do this for every work your team will do. This is only useful for new EPICs and piece of work that needs deep understanding.
The one-pager I use for each goal
Use this as a living document per goal/epic. Keep it short, high-level and updated. This page will become your bible and while your team is focus on individual Jira tickets, this will help you to keep the overview of what needs to be done, when and how. You will be filling the gaps while defining the solution with your team.
Title (business-friendly): a name both product and engineering recognize
Problem to solve and why it matters: brief sentence, brings clarity and purpose for your team members
Success metrics: how we will know we have achieve success
Stakeholders: who will use it
Deadline: when is the work expected to be shipped
Strategy: Main building blocks like prerequisites and actions (Including drawings)
Concerns: anything the may be a risk in short/medium or long term
Tickets: Epic and list of tickets that describe the work in detail (For example, if using Confluence, I always add the component that shows automatically Jira tickets under an EPIC)
Tips - Balance is the Key
- Every ticket in a Sprint/Kanban should create business value direct or indirect (revenue, speed, quality, safety, cost ... you name it).
- Every technical investment should be framed in terms of the business impact that enables.
- The key question to use: "How does this help the company to grow, move faster or server customers better?" If there is not answer then it is not ready for the roadmap.
- Communicate with your Product partner using your one-pager.
What to avoid
Next on this series: Brainstorming and designing the solution
