Learning from a strategy project
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 I wanted to solve
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.
What I planned to achieve
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:
- a plan for what technical work would be required and roughly how complex it was
- how might the desired end state fit with current funding models
- what the cost impact would be
- a team for initial changes ready to start work
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.
What I actually achieved
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.
What I learned
This was an incredible learning experience. Here are some of the things I learned.
Don’t wait to be asked: you can put yourself forward
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.
Put the work in to clarify expectations
In my enthusiasm for the opportunity, I didn’t clarify exactly what I hoped to achieve.
This led to two main problems:
- People started to think this piece of work was going to solve all things for all people
- The exec team didn’t understand where we were in terms of progress
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.
It’s very important to know who your stakeholders are
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.
If you want to go far, go together
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.
You need to bring everyone else on the journey with you
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.
Tailor communication, even if it means you have to duplicate
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.
Repeat the same information in different ways
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.
Don’t start with the biggest problem; start by showing progress
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.
People resist by asking for more data
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.
This work takes a long time
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.
Celebrate what has been done before moving on
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.
This continues to be very useful for me
If I had to pull out the three lessons that were most valuable to me:
- Even if you think you know the desired end state, take a smaller chunk and make some tangible steps.
- Overcommunicate the goal and your progress towards it.
- Focus more on bringing people with you than on getting a perfect answer.
This was an incredible learning experience and has really changed the way I approach things.
Scaling People
I recently read Scaling People by Claire Hughes Johnson, former COO of Stripe. I was first interested in it because it was reviewed in the Economist (paywall) and then an excellent colleague of mine recommended it. Here are my notes.
This is an enormous book
It’s about 500 pages, hardcover and structured like a textbook. My colleague Aaron Lawlor suggested the format may be because it is aimed at the business school market.
Having read it, I can imagine there are some bits I might want to refer back to, but overall, it didn’t completely work for me. However there were quite a few interesting parts.
Her central thesis is that you need core principles and processes that support them
“No matter how brilliant a company is, it will not get far, let alone have an impact at scale, without strong management and sound operating systems”. She then she gives guidance on what these might look like.
They start with what she calls “Essential operating principles”, which are the guidelines you use to make decisions and get things done.
Her four are:
- Build self-awareness to build mutual awareness.
- Say the thing you think you cannot say.
- Distinguish between management and leadership.
- Come back to the operating system.
The rest of the book is based on these principles and the “operating system:, i.e. the core processes that she has built around them.
Your core principles will be different to hers
She acknowledges that your core principles will likely be different. Her position is that you need to work out what yours are in order to drive the operating principles of a company.
Your core principles may not be immediately apparent to you. A good way to start is by working out your most important values. She includes an extract in the book from a values exercise you can do online (PDF).
There is an extra step which I could have used a bit more detail on: getting from your core principles to the values of a company where others’ core principles will be different.
Say the thing you think you cannot say
This is one of her core principles. There was an interesting thought that has stayed with me:
- The "it": the task being discussed
- The "we": the relationship between the people having the discussion
- The "I": your personal stance in the conversation
Throughout the book she comes back to this principle, for example around feedback, building trust etc.
When was the last time you leaned into the company’s values to make a decision?
The books is really focused on the tools and examples that she built up at Stripe and there is a lot of documentation included.
One really interesting one is the Stripe values document. It’s long, a lot longer than a usual values document, and really paints a picture of what it’s like to work at Stripe.
For me, it made it very clear that it isn’t somewhere I’d want to work, which in itself is useful and does more than a usual values statement does.
Things should be uncomfortable
One of her takes on the difference between leadership and management is: “Once you become a great manager, you can get very comfortable. But once you become a true leader, almost every day is uncomfortable.”
“A strategy should hurt”. It should be painful and disappointing, either internally or to your customers. There’s no such thing as a strong strategy that prioritises everything at once.
A key role of leadership is to invest in critical work that no one else will naturally step up to prioritise.
Useful steps for setting goals
The book includes a large extract from this blog post on good goals by a former product leader at Stripe. The post is worth reading in full.
She also makes some concrete suggestions around the cadence of reviews, for example quarterly business reviews.
I also recently read an interesting post on LinkedIn extolling the virtues of shortening the planning process. For me, the really compelling point there was “because it was so short, it actually also ALLOWED everyone to focus 100% on planning and delay their other work” which is something I and my engineering leadership team have experienced a bit of recently.
This all together has some good, well-thought out ideas on how to run a planning process that works well.
Recruitment doen’t end with a successful hire
She has some great insight into how to improve recruitment. The process doesn’t end with the hire, but with a successful onboarding and a strong connection between the new hire and their company overall.
She talks about getting recognised in a tough market. There are usual ways, like writing blog posts, but Stripe went a lot further than that. They held several capture the flag competitions which created a strong talent brand and drove leads to the hiring process.
She includes a write-up of the work involved to set that up, and it was a lot. Several weeks, many engineers, a residential week for the core team of engineers in North Dakota for the crunch period. It was a major piece of work, and she doesn’t really dwell on that point. It’s an interesting thought experiment about just how important you think it is to hire the best.
Attracting the right candidates
Be really clear about the work environment and watch out for language that subtly transmits bias – use tools like Textio to check that.
Make your job ads genuine, not a rosy ad. Be self aware as a company. Knowing who you are helps you hire well.
Think about who is successful at the company. What qualities do they share and what questions can you ask to suss out whether candidates have those qualities?
She also has some great background on how Stripe makes it clear that hiring is everyone’s job. They have some clear principles for all involved: hiring managers, interviews and recruitment, about how to make hiring successful. For example, keep calendar accurate, reply to any candidate question within 48 hours or send on to hiring manager; and on recruitment’s side, be respectful of calendars, shepherd candidates through offsites, etc.
Her advice is that the founder should meet each hire until the the company is about 100 people, because they are the people critical to the company’s trajectory.
She advocates really spending a lot of time on hiring. Talent is everything. Hiring is expensive but it is a critical foundation.
Some useful interview questions
- Works with other people
- Gets quality work done
- Motivates and develops themselves
- Has or can develop the expertise needed for the role
- Demonstrates leadership and resilience”
It’s good to ask then how their colleagues would describe them and about constructive feedback they’ve received. (I’ve also been asked: how would your reports describe you).
Always make reference calls; at least one reference call should be made by the hiring manager themselves. One question she likes to ask: “Is this person in the top 50 per cent of people you’ve worked with?” Then “top 20? 10, 5?” She says people can be positive, but will usually be honest when asked for data. “If someone only says the candidate is in the top 20 percent of folks they’ve worked with, that’s not a ringing reference.”
She also has some other questions like, where do you see them in three years, when was the last time you didn’t see eye to eye, and what advice do you have for me as a manager as to how I can best support them, which gives insight into their weakness/development areas. This is useful for the hire decision, but is also useful for starting to work with them.
Additional thinking around leadership hires
Screen the candidate so that at least two important people are excited by them. Bring in the main stakeholders, even those you think will be negative. Make sure hiring deliberation is a feedback forum not a decision-making forum.
She also stresses the importance of the announcement, which should remind people of the process, celebrate the person you’ve hired and explain why they are right for the company and the role.
It’s key when hiring senior people that you dig into their answers, to make sure they are not just giving you a pre-prepared answer that won’t suit your context. Senior people will be good at interviewing.
Detailed processes around onboarding
This was a section I felt I may refer back to, or pass on to others. A lot of detail on how to onboard, including the “why” of the company and the “how” of company behaviours.
She says company leadership should take part in onboarding, possibly a monthly session where leaders talk about values etc.
If a hiring mistake is made, do a retrospective on your process.
Interesting ideas about processes to track things like internal mobility. Are people moving for career growth, or does it say something about a certain manager or team?
Think beyond individual to team development
Performance tools are focused on the individual, but it’s teams that get the work done. Investment in teams is not something you can finish; “team development is more like a set of habits you cultivate over time, some performed by the manager and some by team members.”
We should all be learning how to teach and facilitate change management.
At first your work is about building a common team understanding of the type of team you want to be and of the results you want to achieve.
If you are thinking about restructuring a team, she recommends mapping out the structure best suited to accomplish your team’s goals and then write out how you’d communicate it – the narrative about why this is the best structure to support your strategy. Similar to writing a press release before you’ve finished a product, writing a comms plan at this point can expose gaps in your thinking and surface potential objections.
Under-delegating and over-delegating
She has some good examples of where you might be under-delegating or over-delegating to your team.
Under-delegating: you are involved in all the team’s work, you ask to review it all before seen externally. Some clues you may be under-delegating:
- people come to you with problems but rarely with solutions
- decisions can’t be made without you
- if you’re on holiday things start falling apart
- you feel overwhelmed by your workload and can’t spend time on strategic work
Over-delegating: you are good at making employees feel empowered and trusted but you are too far away from the work and may also give people work they are not ready for. Some clues you may be over-delegating:
- you become aware of projects going off the rails too late
- your reports often tell you they feel overwhelmed by their jobs
- you can’t say off the top of your head what critical work your team has recently completed, what work is underway and what comes next on the priority list
I definitely recognised one or two of the over-delegating examples she gave – sorry previous teams!
When delegating, explain why the work is right for the person, e.g. with reference to their development goals.
I agree with her ideas about meetings
Structure, agendas, prep, etc. She has given a talk about it.
One new idea to me was checking out. I’ve written before about meeting check-ins. We recently did some team training where they said “you haven’t joined a meeting until you’ve spoken” and suggested check-ins for every meeting.
Hughes Johnson’s suggestion is start with maybe just one word on how you are feeling, and then also end the meeting with a checkout, for example, are you happy with the decision we took?
Very useful suggestions on how to calibrate end of year reviews
In a larger company, do data analysis, for example average designations for a given group, or promotion percentages between employees of different genders, or remote and non-remote employees.
In a smaller company, a more manual calibation: submit scores ahead of time and look for anomalies. Over time, these meetings become less about reviewing each person in detail and more about gut-checking what each designation means, and finding examples so that every manager can calibrate to what, for example, “meets expectations” means for a certain role and level.
It is important to remind people of the kind of cognitive biases that might surface: beyond unconscious bias, she mentions availability, recency and confirmation biases as examples. Understand and coach the group on how to avoid each one.
Her suggestion of how to actually do the calibration is similar to the process we used when I was at the Government Digital Service. Start at the more junior levels with everyone in the room, and once you start reviewing people who are at the same level as the managers in the room, start excusing the more junior managers.
Do a final review of the data afterwards to check for broad parity. Then roll up to senior leadership to review and check for an expected distribution. It shouldn’t be a forced distribution, but high n counts should have a roughly normal distribution. Senior management should also review that the percentage of employees being promoted feels equitable and in line with compensation budgets.
Managing high performers
She divides high performers into ‘pushers’, who are highly ambitious, can be very critical, set high standards for themselves and others, and are internally motivated, and ‘pullers’, who take on much more work than they should and deliver high-quality output, but they get burned out; they are more externally motivated and have trouble saying no.
She then suggests some ways you can motivate and develop these two kinds of performers.
Pushers: encourage and reward them for the high standards they set; ask them to lead projects to address areas that need attention; frame work as development opportunities; coach them on how to exert influence indirectly.
Pullers: help them prioritise and set boundaries; encourage and reward them in private and publically; before they take work on encourage them to ask themseves: am I the most qualified person to do this? Is this the most important thing I could be doing? What would I have to let go in order to do this? Coach them on how to say no.
Do the best for your reports
Aniticipate when the work will become boring and work with your reports to think about where they might want to focus in six months. Include them in your succession planning. Think laterally about opportunities that might give them a chance to grow in the ways they want to, even if they aren’t their logical next step.
Finally, let go. If you can’t find interesting opportunites for a high performer on your team, don’t hold onto them for too long – land them a job in another part of the organisation, or open up your network and help them get another job; play the long game, you’ll have earned their loyalty and trust.
She also suggests pre-exit interviews – ask people: if you were going to leave, what would be the reason? Ask 3-5 people, or maybe the top 10% of talent.
Managing good performers
Don’t just spend time with your high performers, also think about people who are not currently high performers but have a lot of potential. She says she obsessess over how to unlock the upside.
For example, someone who always has a completely different perspective on a problem can sometimes feel very disruptive, but they can also engineer the breakthrough the team are seeking. She gives an example of when she was at Google. Someone kept suggesting peer-to-peer support as a solution to their customer support backlog. Eventually she told them “find an external example and write up a way for us to test the concept”. The test was very successful, users were getting help immediately, and it led to a building a new support approach that is still in use.
Finally, she notes medium performers are sources of stability and are often culture carriers. This ties into something we talked about on my IoD leadership course (yet to be written up!) that the ‘medium’ performers, who are competent, consistent, and productive, but aren’t your highest performers, are actually the pillars of the company.
Managing poor performers
She also goes into a lot of detail about managing poor performers.
One of the things she does in this book is suggest different ways to say things:
I found this a bit grating, and there was a lot of it in the section on managing poor performance. This could be useful for people who don’t have experience here or want advice on exactly what words to use, but it didn’t work for me.
One thing to note is that the content on managing out is definitely not useful if you are not based in the US.
Who is this book for?
This book contained a lot of great ideas and pulled together a lot of useful resources, but as a whole, I found it tiring, rather than inspiring. I am not sure if that was the style, or just that I am not the target audience. It was definitely management rather than leadership.
It’s also very long. Hughes Johnson says it’s not necessarily to be read cover-to-cover but instead pick it up and go to the page of what’s on your mind. However, for that to be the case, the contents pages and index need to be a lot better.
If you are in a company that doesn’t have good processes, particularly around people management, then this definitely has a lot of useful content and good ideas, but it wasn’t a strong recommend from me.
Analysing, Deciding Doing: How to develop and execute an effective strategy
In June 2023, I delivered a talk at Turing Fest on how to create a strategy. This talk is the one I would have liked to have seen when writing my first strategy: how you actually do strategy.
Watch the talk!
The slides are here:
Summary of the talk: models and techniques to help you create your strategy
In the talk, I go through some specific models, with examples.
- Analysing the situation: how to reach a diagnosis, including models like PESTLE, S-curves, Five Forces, VRIN, and value chain analysis.
- Making a strategic decision: how to make a strategic choice, including Three Horizons, Ansoff matrix, Blue Ocean strategies, and weighting and scoring.
- Making it happen: how to implement your strategy, including communication, managing change and showing progress.
These tools, techniques and actionable advice will set you up to be able to create and deliver an effective strategy.
Strategic technology leadership: video
Earlier this year, I keynoted the second day of CTO Craft Con: The Strategic CTO, and the video is now available:
You can also read more about the discussion in my write-up.