A couple of years ago I worked on a strategic project that was outside my remit. It was an incredible learning experience for me and here is some of what I learned.
The problem for my team was that our tech estate was in contention. I was leading one of a number of engineering groups within a larger organisation; each group had its own priorities, but most of them required delivery through my team or tech estate; and we had our own priorities. So we ended up slowing each other down.
It seemed to me that we needed an overarching strategy to enable us to resolve these conflicts and all pull together towards the same ultimate goal, but it didn’t feel like my place to work out what that would be: it would impact my peers’ teams as well as my own so it felt like the solution had to come from the level above.
However, two things changed for me. I started working with an excellent coach, who helped me unblock my thinking. Then, I was talking to someone about how it wasn’t for me to solve this problem and they said: why not you?
And I thought, yes, why not me? So I pitched to my boss that I step aside from my role for three months to propose a solution.
This post is not about the answers I came up with, but about what I learned through the process. And it was a lot.
I had planned to work out our strategic direction, including any changes we’d need to make to our technical architecture or organisation.
My proposed end goal of the three months included:
I had also hoped that we would reach these goals by clarifying the overarching strategy.
This sounds laughably ambitious now, but when I proposed this piece of work, I genuinely thought I would be able to get all or most of that done in the agreed time.
I adddressed the main issue in a little longer than intended: after five months we had a clear technical direction for how to address some of the contention on the codebase and a team starting work on it.
However, I hadn’t addressed funding models, I hadn’t brought everyone along on the journey, and I definitely had not resolved the underlying contention between groups about the strategy.
This was an incredible learning experience. Here are some of the things I learned.
At every level of my career I’ve learned that you don’t have to wait for someone else to solve a problem you have, or to create the opportunity you believe exists. However, each time it looks a bit different. This time it looked like I would be treading on toes and/or would not be in a position to be able to achieve results.
If I had just gone off and done it on my own, it would have been difficult. However, this work solved a problem for my boss. Pitching how I could get us to a solution meant that he backed me to do it, which conferred the authority to get the work done.
In my enthusiasm for the opportunity, I didn’t clarify exactly what I hoped to achieve.
This led to two main problems:
I didn’t clarify, because I didn’t know all the possible outcomes. But this is a problem that has been solved in engineering. In this situation, either be really precise about the outcome you plan to achieve and then work towards that, updating on progress as you go, or timebox the efforts and report on how far through that timebox you are.
It’s quite easy to sell a poorly defined piece of work that will solve everyone’s problems, and is much harder to sell a piece of work that is more clearly defined but smaller in scope. However, it’s worth putting that work in at the beginning to make sure all stakeholders understand what the goal is.
This is good advice in general, but with a piece of work like this it’s crucial, as your results depend on buy-in. In this case, a peer of my boss was a key stakeholder. She already had a solution in mind, and saw my work as part of that, which led to crossed wires when I took a different direction than the one she had anticipated.
The learning for me was that it’s not always obvious who the key stakeholders are and it’s important to understand that and manage them closely.
This was not just an engineering problem, so I asked two of my colleagues in product to work with me on this. This was great, as their understanding and challenge helped the work be much better.
We also talked to a wide range of people to get their input. We conducted about 50 internal interviews and I also had about 10 conversations with external companies to understand how they did it. Working as a team with other people made it possible to have that many conversations, and bought a lot of learning and diverse thinking.
The most important thing I learned from this piece of work is: it’s not enough to find the right answer. In fact, finding the right answer is really not that valuable. What is valuable is creating change; and in order to create change, you need to bring people along with you.
We did bring people along on the journey with defining the problem. When we’d completed internal interviews we did a very well attended talk outlining the challenges we wanted to address and people were clearly engaged. However, this got harder when we got into the solution space. It’s really important to continue to engage people as you start to work towards solutions.
It’s harder to communicate when the work might involve change. It’s also difficult to communicate work in progress without people thinking it’s a done deal.
I initially planned to do weeknotes for this piece of work and share them openly, but quite quickly I found that in order to not share anything that might make people worry about their jobs, I had to make them quite banal, and therefore quite boring.
In retrospect, one thing that held me back is my commitment to keeping things open. I prefer to be as transparent as possible, and so I was aiming to do one set of weeknotes that would serve both the exec team and also everyone else.
Unable to produce one size fits all, I did neither, and in fact, I should have done both.
I had a fortnightly meeting with the CPO, CTO and CPTO to update on progress, which was initially a great medium for sharing progress and checking alignment.
This worked great when all three of those execs could show up, but fell apart when one of them was off sick. She missed a step that the other two were apparently on board with, so I continued working on that angle; when she returned she did not agree with the direction. It then took time to both bring her partly up to speed and also to account for what she wanted. Because the meeting was fortnightly, that one missed person in one meeting set the project back six weeks.
I’ve talked above about the importance of clarifying what execs/sponsors are expecting from the work, but you also need multiple ways to communicate.
If you want to communicate something it should be verbal, visual and written, because people take in information in different ways. I had been preparing slides for the updates and then sharing them after the meeting, which I thought was verbal and written. However, since this experience I’ve worked a lot harder on visual representations, on communicating outside meetings as well as inside and on repeating the message in different ways.
When we’d completed the internal and external interviews, our prioritisation process was the clear frontrunner among the potential issues to address.
I got very excited about tackling the biggest problem we had and effecting a change that would have a huge impact on our productivity. I also was following the Drucker principle of “First things first, second things not at all” so I threw my energy into addressing that issue.
The mistake I made here was starting with the biggest problem. This issue was one that was stopping all other pieces of work being as successful as they could be, so it seemed to be the highest leverage: but actually, it was not. It was a big problem and would take a lot of energy to solve; a high leverage opportunity is one that has a big impact for a relatively small amount of work.
Meanwhile, because I was focusing on this problem and it was slow going, there was no demonstrable progress on any other part of the work. Part of strategic work is demonstrating that your strategy is sound. You can’t just jump to an ideal end state. So take tangible small steps that you can deliver quickly. This will demonstrate the value of the wider piece of work and earn you the trust to execute the larger pieces of work that may need a leap of faith.
One thing that was new to me was people pushing back on change they don’t want by asking for more data.
Two examples were “What would that look like, can you show some options to help me make a decision?” and “Can you give me some examples of where this has been the root cause of the problem so I can understand the issues better?”
Both of these seemed like reasonable requests, so I went away and diligently pulled together more information. Both times, when I returned with it, they didn’t want the information I’d put together. Asking for more data was a way of resisting the change.
How to address that is a whole other post, but my main learning is, if you’ve got to the point where these questions are being asked, you’ve missed out a step or two on the way of bringing people on the journey, and you need to find a new way to get where you are going.
As I mentioned above, I genuinely thought I would achieve my strategic goals, have communicated them, and be ready to start the work in three months. Since then, speaking to people, I’ve understood that just the first part of this work can take many months, and the execution of the strategy can take many years, and this isn’t because people are not focusing: it’s that some of this work takes a long time.
This was an incredibly valuable learning for me and helps make sense of some previous situations where I had felt leadership were dragging their feet.
This was one of my biggest personal learnings that year. Because of how I’m motivated, I am always looking for the next challenge and opportunity. Sometimes that means I don’t pause to celebrate what I have achieved to date.
That doesn’t help me, because it can mean that I feel like I’ve not achieved much, as I’m always looking forwards at what is left to do. But more importantly, if I don’t celebrate the amazing successes of my team, it doesn’t help them feel their efforts and hard work have been worthwhile; and it doesn’t help executive sponsors see the value of the work.
This is something I’m still working on. You can even see that in this post, where I’ve spent a lot more time talking about how I would improve, than I have talking about the big changes we managed to drive, the engagement of multiple people in making this project successful, and the tangible change of direction of the tech strategy that demonstrably helped teams deliver faster.
If I had to pull out the three lessons that were most valuable to me:
This was an incredible learning experience and has really changed the way I approach things.
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list: