Two years ago, I wrote about how as a technical leadership team we can figure out what to work on. We made some changes to the way we worked and found them really beneficial. However, last year we realised there were flaws in how we were working, which made it hard for us to prioritise the bigger, more impactful pieces of tech work.
Here are the changes we made to address that. We still have some way to go and would love your thoughts.
One reason we had less time for larger pieces of tech work was that over the course of 2020, team health work became more important. We all found ourselves doing (and needing!) more of that, both due to the external stresses of the pandemic, and internal pressures around changes that had to be made because of it.
In addition, when the pandemic hit and we all moved to working from home, a few of our processes also dropped out. For example, we no longer had a physical wall, and in the rush and emotional turmoil of those first few working from home weeks, we dropped having a stand-up meeting and did not restart it.
By the end of summer 2020, all of the principal engineers and I felt that we had been struggling to make time for the larger pieces of technical work.
However, it wasn’t just about making time. It emerged that none of the principal engineers felt empowered to push forward on any individual piece of tech work, because all felt uncertain about what the priorities were or the direction of travel.
They all felt confident in making decisions about team health, recruitment etc, often without discussion with each other, but with technical decisions there was uncertainty about the overall direction and what the priorities were, which meant that only small technical issues got worked on, and mostly in a very reactive way.
We all felt that we were avoiding the bigger technical issues, and spending too much time on lower value work, but didn’t understand why or how to fix it.
I’ve written before about how we initially prioritised work on our tech strategy. One of the most useful exercises we did for prioritisation was a card exercise where we laid cards out on the floor in the order we felt work needed to be done and then walked the room discussing dependencies and things we hadn’t considered. The participants were senior engineers, principal engineers, the product director and myself.
This exercise was extremely useful for:
We left that meeting with an idea of the top three priorities to work on. We then had shorter, quarterly meetings, where we clarified where we were with the top three priorities, and when work was finished, identified the next priority or priorities.
The initial card-laying session, supplemented with the quarterly discussions, despite changes in personnel of a lot of people in the roles, saw us through 18 months of understanding what our technical direction was and clarity on what the next steps were to get there.
By the beginning of 2020, it was clear that we were getting to the end of the roadmap we’d defined, and we did not have alignment among ourselves, either within the principal engineers or more widely within engineering, as to what the next priorities were.
So we planned another away day to go through the card-laying exercise again. This was booked in for March 26th, 2020. However, on March 16th the FT moved to working from home, and by March 23rd the UK was in lockdown.
We cancelled the meeting.
In the first, very stressful, few months of the pandemic, it didn’t feel possible to think about how to plan ahead. Once we were able to do so, we managed to find good ways to prioritise and vote remotely, but what we were missing was the bigger picture view we had hoped to get with the full day discussion and we could not work out how to do achieve the same outcomes remotely or asynchronously.
As I described in my previous blog post about how we worked, we felt we ought to be splitting our time 1/3 team health, 1/3 tech strategy, 1/3 tech oversight. But we were not keeping track of the time. This hadn’t turned out to be a good suggestion as the overhead for implementation was too great, so we decided to think about it another way than splitting time.
An analogy I’m fond of is the one about how if you put sand in a jar first you do not have room for rocks, where rocks represent life’s big priorities and sand the little things, whereas if you put the rocks in first you’ll still have room for some sand. (Here is a link to a version which includes beer).
It felt very much to me that we had some pebbles and a lot of sand, but we were avoiding picking any rocks, where rocks were big, meaty, technical issues that needed focus and time to solve.
So our suggestion was we crowd out the sand with rocks; i.e. be clear about what the rocks are and make sure we are always working on those.
When the team was feeling a bit lost at the end of the summer, I felt it was clear what the priorities should be.
However, just telling people what to do next is not part of how I lead. While it is my job to set and implement tech strategy, I don’t have all the answers and I don’t see everything. Successfully selling priorities, taking on board feedback, and considering other options, rather than just dictating what we do, leads to a better strategy, as well as more ownership from those who are actually going to be implementing it.
A blocker from me was that I didn’t want us to go off and define the tech strategy ourselves without involving the senior engineers.
However, it was clear that we were stalled and needed to move forward, so I put that aside and arranged a meeting with just the principal engineers to discuss the top priorities. Because there were fewer of us, we were able to have a shorter meeting that was manageable remotely.
We came out of that meeting with a shared understanding of the top three priorities, which solved the immediate problem of not knowing what we should be working on, though didn’t address the wider of issue of not getting into this mess again.
As well as crowding out the sand with rocks, we felt it was important to review what the sand represented, to be clear about what we shouldn’t be doing. Sand in this case represented work that seems urgent, and it’s easier for each of us independently to make a decision about what the right action is, so ends up taking too much of our time, but actually was not contributing to our priorities.
We have a list of the kind of activity a principal engineer does, split into three categories: tech strategy, tech oversight and team health. This is useful for job specs, letting people who are interested in joining the team know what we do, as well as clarifying for ourselves what’s in and what’s out. It’s also useful for making sure that we fairly share out the essential glue work that otherwise may not be fairly distributed. However, we realised that some of the things on that list were not actually things that should be priorities for us.
We reviewed the list and questioned whether each one was actually something we should be doing. This was a really useful exercise as it identified some places we were spending our time wrong. For example we identified a number of tasks that were actually a delivery responsibility and were able to hand those over, and some further tasks that on reflection were not adding sufficient value to be worth our time.
Technical work is where we can really add value as senior technical leaders - and it is work that needs doing, that no-one else can do. We were not fulfilling our potential, or even doing our jobs properly by allowing sand to crowd that work out.
We agreed that this should be the overriding principle of what we should be doing – prioritise the work that only we can do, as senior technical leaders. This helps us be clear about when we should say no to things.
While our one-off conversation had made sure we were all aware of what the next priorities were and were making progress towards them, I still wanted a process that supported that happening in an ongoing way.
My goal is still, and always has been, looking for ways to make myself redundant in a role, and in this case, for the Customer Products principal engineers to be able to run the team without me – so anything that relies on me having to state what the priorities are is a bad sign.
We have a weekly principals’ meeting that anyone can add items to and we go through in priority order. There’s always a lot on the agenda, and what we found was that we often didn’t have time for in-depth discussions.
So we made some changes:
We set up two planning meetings
One every six weeks, called ‘future planning’, and one every other week instead of the principals’ meeting, called ‘incremental planning’.
In future planning, we spend two hours discussing the bigger picture and making sure our priorities are in the right order. We use a Miro board to support this discussion, and in between times we add context. This is really useful because over time the picture builds up.
In incremental planning, we check in, just to make sure the work we are currently doing reflects the highest priorities as agreed in future planning.
This is also where we look at work that people have asked us to do and see where it fits in and how it should be prioritised; make sure we don’t each have too much WIP; hand things off to each other if appropriate and drop things if they are not a priority. It is a useful context sharing meeting to check we remain aligned.
We reinstated stand-up for six weeks but found it duplicated incremental planning so dropped it again.
We set up two weekly discussion slots of an hour each. These are for the ‘pebbles’ that need more discussion than we can cover in our weekly meeting, or for making progress together on ‘rocks’.
These slots are booked and available so that if we do need to have a more in depth discussion about something, we don’t need to then worry about finding the time; and if there’s nothing that we need to talk about: great, we’ve got a bit of time back to do other focused work.
These changes have worked really well. Future planning means we are spending time discussing the bigger picture and making sure we are still agree on the top priorities. Incremental planning makes sure we are keeping on track. And the discussion slots are really useful – sometimes we use up both the slots in a week, either ad hoc or booked in advance, and about half the time we don’t have anything on the agenda so we get some time back.
We have worked out what the next big things are, and a process to share context between principal engineers and ensure we are focused on the rocks.
However, the forward planning meeting and other changes we’ve made are about context sharing and thinking together. While this is very useful, what is missing is clarity around what kind of thing should be next. What should person X, as an engineer on Customer Products, do next, in order to get us to our goal?
Strategy should be diagnosis, vision and a plan of coherent action. The “rocks” are steps on the way, but they do not form a full plan of action, and they do not tell us how to prioritise the next thing to work on.
One of the principal engineers pointed me at Turn the Ship Around! (which I wrote up here). This book was great, but what I struggled to apply to a technical leadership situation was how to make sure that an engineer on the team could identify what work is next.
When I asked for advice on this, I got some really helpful thoughts from Chris Swan. “The concept I’ve found most useful to deal with this is ‘command intent’. Once you know which hill you’re going to bombard, the team know the desired outcome, which is to take the hill, and they can get on with doing that even if you’re shot by a sniper moments later.
Amazon’s practice of working backwards is also useful in this mix to get outcome orientation and involve practitioners in describing outcomes (bounded by their view of what’s achievable).”
It’s possible that this next step is around clarifying what outcomes are most important to us (e.g. is it speed of releasing? In which case is the next priority is the slowest part of the stack to release. Or is it about cost? Or user experience? etc). Or it could be about principles. Or it could be finding a way to have the group exercise again, where we either figuratively or literally, lay cards out on the floor to identify what needs to be done to get us to our long-term goal.
Working this out is my next thing to do.
However:
I would love to hear from anyone who has useful contributions on this; particularly any thoughts about how to do a card exercise or similar context-sharing/prioritising activity with a large group of people either remotely or asynchronously.
And I would also love to hear from others who are in charge of a large stack and successfully share the work of prioritising with the team.
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list: