Team Driven Technical Strategy
How many times have you been in the situation where the team raised blockers, or concerns about the code base and the tools? Does the team know what is the technical priority? Do the team members share this same priority? Having a proper technical strategy will help the team to have this clear focus.
Frank M.L.
6 min read
Most of the teams I have worked with, share this same characteristic. All the team members have a clear view of what we need to do to improve the team environment, but each one of them has their own point of view. Even if they share actions, they rarely agree on the priority order.
This commonly results in misalignments in the team actions. They may have really good intentions to improve, but the people promoting these actions, find it hard to communicate their importance or impact.
Also we face another big obstacle, the team is already dealing with the product priority or roadmap, which usually fills the backlog. Leaving the technical priorities fighting constantly for being included inside of the team backlog.
In my teams, we build technical strategies which live with the product strategy. This way we can optimise the impact of the technical actions, during the product development.
Building a Technical Strategy.
In order to ensure all the team members are on the same page, we always have a team vision, mission and values. Here you can find the session I like to use with my teams:
Prepare the session
Playground
To start this session I prepare a canvas with 4 different sections:
Introduction: Here I add the team and company vision, mission and values.
Improvements: This is a blank space with enough post-its for the team to add all the improvements, ideas or goals.
Prioritisation: In this area I usually prepare two matrices: an Eisenhower matrix and a cost/impact matrix. There we will prioritise the outcome from the areas and actions.
Summary: Here we will visualise the outcome of the session.
Who has to be in this session?
There is an obvious answer: the technical team. But in my experience, it is very useful to add all the team, even a stakeholder or person in charge of the transversal priority.
It is important that everyone attending the session has a clear idea of the goal of this session.
The goal of the session is: Finding the most important areas, where the team will take actions to improve the technical stack, in line with the other team priorities. This session is not meant to discuss the topics in depth, product priorities, or external topics.
I like to give heads up to non-technical roles, presenting them the focus of the meeting and giving them the opportunity to decide if they want to take part of the session.
Allowing all of the team to take part of the session, has proven to be a great opportunity to build a more realistic strategy. Increasing the cohesion between all the roles and priorities in the team.
Let's create the Strategy!
[Session time: ~1h 30min]
Welcome to the meeting.
[time limit: ~10 min]
Let's start the session! First of all review the goal of the session:
Finding the most important areas where the team will take actions to improve the technical stack in line with the other team priorities.
Then I like to remember the vision, mission and values, so the team has a clear focus on why and what we want to achieve as a team.
If there are product representatives or stakeholders, encourage them to present the product strategy or roadmap. This will help the team to have a better visibility of the upcoming challenges.
Remember! This part is just an introduction, prevent any discussion about the team statements, or the other roadmap/strategies. Gather any comments and promote separated sessions to discuss them.
Visualising what we need to improve.
[time limit: ~30 min]
As a first step, I like to throw this question:
Taking into account the information we just saw: What do we need to improve in the technical stack to pursue our Vision?
Then I give the team 10 min to add all the post-its in the improvement section of the canvas.
Once the team or the time finishes, it is time to check all the topics on the board. During the next 20 minutes we are going to review all the topics on the board, grouping them into areas.
Some advices for the grouping:
Pick the first post-it and encourage the team to explain the topic, usually starting by the person who wrote it.
Then encourage the rest of the people to group the similar topics next to this one.
Prevent in depth debates. We won't refine now the tasks, areas, or discuss if they are really the action we really need to do. This phase is just discovery.
Prioritising the Improvement areas.
[time limit: ~20 min]
After identifying the improvement areas, it is time to know which are the ones we will focus on. Usually the teams raise more than 6 improvement areas, but it is not feasible to focus on all of them. So, we need to find the 2-3 most important areas in order to be able to have a significant impact.
Here I always start with an Eisenhower Matrix (importance - urgency matrix):
We start by picking one improvement area, placing it were the team thinks it is right and use it as a benchmark for the other topics.
All the topics can have their placement in the matrix altered, i.e if we have a topic in the high importance and high urgency area, but the team realises that other topic has more importance. We would move the first topic down in importance.
This is about priority. So a topic in the low-importance & low-urgency area is not meaningless, but we just shouldn't focus on this topic until the other topics are out of the picture.
Once we have the most important and urgent topics, we will select the 2-3 topics with the highest priority.
Summarising the session
[time limit: ~30min]
Now it is time to place the topics with the highest priority on the side. I usually organise the topics from top to bottom.
To have an effective technical strategy, we take all of the actions related to the selected areas from the Visualising what we need to improve and place them alongside to the improvement areas. This will give the team a starting point which reflects the actions we want to prioritise.
For prioritising these actions, I also like to use a cost/impact matrix. This will help identify the quick wins the team can do, helping them to have a clear focus on where we need to put the effort. Here I leave you some tips:
Try to prioritise the task with the greater impact and the least cost. If the team raise a task with a great impact and a high cost, I encourage the team to break it, in order to bring it closer to the quick win section.
Encourage the team to pick the tasks they can commit to, taking into account the priority we just set and the information we got from the start of the session.
In the end, the team will have a prioritised list of:
Improvement area 1:
Action 1
Action 2
Action 3
...
Improvement area 2:
Action 1
Action 2
...
Improvement area 3:
Action 1
...
Once we have this list, my job as a manager is to ensure the team is bringing these actions to the refinement sessions. Either if it is insider of a feature development or as standalone actions, we need to ensure the actions share the priority with the rest of the team's work.
Share it with the rest of the company.
Finally, I share a summary of the session, usually adding it to the team wiki. I also like to send a public message to the rest of the company, with the highlights an a link to the summary of the session.
This will help to:
Create awareness about the focus of the team.
Create synergies with the rest of the technical teams, even promoting possible collaboration between teams or reducing the duplicity of the actions.
Highlight the importance of having technical improvement in their daily work.
Review it!
In order to ensure the technical strategy is always on the same page as the other priorities, I set quarterly technical strategy reviews with the team.
The main advantages of these reviews are:
Review and learn from the previous quarter.
Adjust the priority to the reality of the team.
Raise new improvement areas or actions that can be taken.
With this technical strategy, the team will be able to have a common roadmap. In my teams we also use it as support for our personal OKRs.
I hope this post helps you to have an effective technical strategy in your teams!
If you have any doubts or feedback about this topic, please contact me: