During the first weeks in a new role, one of the things I’ve most recently focused on is to assess the direction of the engineering department as a whole. Will Larson has written at length about the first ninety days in a senior engineering leadership role. He also mentions documenting the existing strategy as one of the key milestones to take care of.
At the time I started there was no explicit strategy in place. Which is also not an unusual thing for a young company, just to be clear. So I set out to draft one.
As a remote CTO I considered a documented engineering strategy one of the key tools to provide direction and context. Especially when I’m not around during discussions, a frequent occurrence when you’re to nine time zones away from everyone.
Unfortunately examples of engineering strategies are far and few in between. There’s plenty of examples on the importance of having a vision and strategy in place though.
For instance, Cate Huston wrote about the importance of having a vision, mission and a strategy as the corner stones of communication in a team.
Daniel Schauenberg wrote about learning to have an engineering vision in place.
The missing piece for me was how to put together a strategy and come up with a compelling one for my team. That’s the process I’m documenting here.
This post is based on a Slack thread in the eng-managers Slack where I wrote about my approach. Do note that this is only one approach of many. Approaches vary depending on the organisation, its stage, or where the team is at in its own trajectory.
Prerequisites
When I started out there was no explicit direction place for the engineering department. There also were no OKRs or similar tools that may have provided a foundation for such a strategy.
I had a blank slate in front of me. This was both exciting and also required extra care to get a strategy in place. The only influence I had was the business strategy as well as a product manifesto. These proved to be useful to have in place as it provided context for everything the engineering department would focus on.
My goal was to come up with a strategy that features several elements:
- A mission for the engineering department that outlines the overall direction and focus.
- A number of objectives to steer the technical direction for the next 12 to 18 months.
- A list of process refinements that make explicit changes in approach or structure.
I didn’t want to have this entire document to come from the top. Nor did I want to shift the entire team into a whole new direction as sometimes can be the case. This can be necessary depending on what stage a team is in. But it wasn’t in my case.
So I started talking to key folks from the team.
Gathering Perspectives and Input
I spent quite some time listening to folks. I read slews of documents, meeting notes, roadmaps, to understand what trajectory the team has been on so far.
Listening proved to the most fruitful here. Here are some questions that proved useful to explore:
- Is there a technology currently being removed from the stack?
- Is there a new technology that the team is keen to try out? Or a technology that is worth implementing to support a larger business initiative?
- Is there a process or structure that’s not working or that’s getting in the way?
- Are there any places where the team is understaffed (or overstaffed) or missing key experience?
It was also helpful to understand how these decisions have been made and how folks have arrived at their own conclusions.
The goal here is to assess where the team is at as of the moment that you’ve joined them. You may find gaps in joint understanding of where the team should go, what technologies should be adopted (or cast aside), or what it should focus more (or less) on. These gaps are useful to uncover as you now have a chance to close them!
The process will likely last over multiple conversations. Don’t force this within just two weeks. It’s worth exploring and looking for nuggets in the conversations to dig deeper into subsequently.
These questions help you craft a strategy that documents the current approaches (that are working) and that includes new approaches and goals.
Having the business strategy helps in these conversations. It allows you to ask folks questions like: “How do you think this ties into our business goal of achieving X?”
You may not always come to a compelling answer. In that case it may be up to you to connect the dots or discard the idea.
What if there is no Business Strategy?
Especially earlier stage companies don’t yet have a business strategy in place. In this case it can be a struggle to connect your engineering strategy to the larger business goals.
What can help is talking to the other teams and departments around you. Ideally you focus on those where your team has the largest contact surface.
Ask them about what’s most important to them, what their own measures of success, their OKRs, or their longer term goals are. This doesn’t need to be stuff that’s directly related to your team’s work (depending on what level in the organization you craft the strategy). But it can give you clues on what’s important to the departments around you.
This can be any part of the business that is impacted by your team’s work. For instance, other engineering teams, product management, marketing, customer success, and so on.
Do make sure to make the learnings and assumptions derived from these conversations explicit. This will help everyone understand the context.
Drafting Objectives
An objective is a longer term goal that requires multiple steps and likely a longer stretch of work to get it implemented fully.
“Swap out the WYSIWYG editor for that new thing from Basecamp” is more of a project than it is a strategic initiative. It doesn’t work well as an objective. It’s also more descriptive and doesn’t leave much decision making power with your team. Which in the end, is one of the goals to have a strategy in place.
“Migrate core functionality pieces (including authentication, user data, shopping cart) to a micro services architecture that’s running independently of our main application” works much better. This is a long term commitment and also provides enough freedom for the teams to discover and decide on how they’ll achieve this goal.
It can be helpful to outline for each objective to include a short description on how it supports the business strategy. This is useful context to make this connection clear to everyone. If it’s not the strategy then it could be a case of how it supports the business as a whole.
What’s important to you?
While this whole approach is supposed to gather as much input as possible from the team, there’s also room to add your own improvement ideas. Ideally those are bought in from the team as well of course.
A few examples of what I focused on here is making explicit a new structure for how the engineering teams are working together on specific projects. Or a focus on continuous delivery by doing more regular releases.
These can be process improvements like preferring early prototypes over late feedback. Or maybe you want your team ship every day. Or there needs to be a better way for making decisions in the team. This list can include anything that you think helps the engineering department support the business more effectively.
That per-final step
Before making it official the strategy was open for feedback. The subsequent discussion helped uncover some possible conflicts and misinterpretations. So it was helpful to spend that time to get a crisper strategy.
This process also helps increase buy-in for the document across the team.
Putting it all together
What I had at the end was a strategy document that outlined:
- The engineering team’s mission and how it relates to the business’ overall mission.
- Seven objectives that steer larger technical decisions and direction over the next 12 to 18 months. Seven is not a magic number here, but it helps to keep this list below ten.
- Three process improvements to help the engineering team support the business better.
The exact number of items in each isn’t as important. What’s key is to keep the strategy concise. Each item included an objective and a wee bit of context. The entire document had 500 words.
For deeper inspiration on how to draft crisp and actionable strategies, I recommend the book “Good Strategy, Bad Strategy.”
Good luck on your journey of drafting a strategy for your team.