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.


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.

One thing I wanted to a better job at as I took on a new role last year is to be more deliberate in giving feedback. As a German, I tend to fall on the side of only focusing on negative, or constructive feedback. I tend to focus on pointing out what I think should be improved, or what isn’t conclusive. This is quite ingrained in the German work culture.

Over the years I’ve come to appreciate positive feedback more and more. Getting affirmation or appreciation shows us that we’re doing something right. That we should keep going down the path we’re on.

Constructive feedback tells us where we should course-correct. Together they give us a compass for our own personal and professional development.

In the daily shuffle of work, feedback used to fall off my radar. It still does from time to time. So I was looking for a means to be more deliberate about feedback. And a means that helps me track and plan the feedback I distribute.

Meet the feedback log. It’s not a complicated thing. It’s a text file. It has two sections:

  • History: a timeline of feedback I’ve given, to whom and when.
  • Future log: a list of feedback I intend to give at the next occasion, indexed by person.

It could like this:

  • 2019-07-25, Virginia: The presentation you gave last week was great I thought. The subject matter was well researched and presented. The conclusion you got to made sense to me. You built consensus with your team on the final decision and gathered input in the presentation, which helps us and you make better decisions.
  • 2019-07-23, Max: Last Tuesday you posted a comment in Slack that could be taken the wrong way by some folks. It used language that could make some folks feel excluded. For the future, I’d suggest that you avoid this particular language.

For the future log, I either leave out the date or include the date of our next conversation.

Why is this useful? It helps me keep track of feedback when I observe a situation worthy of it. I can go back to my future log before every 1:1 and see if there’s something I should bring up.

The timeline helps me be more balanced in my feedback. I can ensure that I give both affirmative and constructive feedback in equal measure.

Lastly, it serves as a record of all feedback I’ve given. This can be useful to go back to in the future to see the progression over time for an individual. Should there be a dispute over what kind of feedback I’ve given in the past, I can go back to the list too to verify.

It’s a little thing but sticking to it with some discipline has helped me build up a better habit of giving feedback.

Inspiration for this log came from the Decision Log in Oren Ellenbogen’s book “Leading Snowflakes.”

A question that I’ve come across frequently is why a team is not doing what their manager expects them to do. The flip side of this question could be phrased as:

“How can I remove myself from all the discussions I’m constantly being pulled in?”

And also:

“How can I get my team to take on more responsibility?”

Leaders who find themselves wondering why their teams aren’t making important decisions on their own tend to be leaders who are constantly pulled into many different discussions. Their calendars are filled to the brim, leaving little time for longer term work.

This can seem like you’re contributing as a manager, like you’re doing important work and keeping yourself busy. It also means that you’ll have less time to focus on strategic work. Which becomes more important as you move into more senior roles.

What is strategic work? For instance:

  • Thinking about where your team should be three months from now.
  • What processes are missing or need to be tinkered with to make your team more effective.
  • Contributing to broader company or engineering initiatives or technical decision making.
  • Determining hiring needs for the next six months.

Not being able to scale yourself tends to go hand in hand with your team not meeting unwritten expectations. The good news is that there’s a way to help you resolve both.

“Expectations” Doesn’t Mean Giving Orders

Inexperienced leaders tend to be hesitant setting expectations. I’ve heard reasons like “servant leadership,” or “I want to give my team enough freedom without setting boundaries,” to “I don’t want to give my team orders on what they should do.”

All these are reasonable things to consider as you’re working out a set of expectations for your team. Setting expectations the wrong way can make your team feel like you’re micro-managing them.

Good expectations focus on context and outcomes

Expectations don’t have be set that way. Good expectations focus on providing:

  • Context
  • Frameworks
  • Outcomes

These three focus on providing structure and being clear on what you want your team to come out with at the end.

Context is everything a team needs to know to meet the expectations. This can include approaches you’re taking when you approach the topic you want your team to work on. It can also be company and business context, like a technical vision or the company strategy. It’s anything that helps the team to achieve the desired outcomes.

Frameworks provide your teams with tools they can use. This could include meeting structures, decision making processes, or question they should ask themselves as they work on a topic.

Outcomes set clear goals for what your team should achieve. This could be as simple as “make a decision on X” or “agree on the priorities for the next development cycle.”

You can set expectations and also ask your team to give you feedback on them, to agree on them, or to develop their own expectations and frameworks. In the last case, your expectation can simply be for them to develop their own approach.

How you go about doing this depends on your leadership style, how your team likes to work, and how experienced they are.

Teams can be blocked without clear expectations

When you’re not seeing your team take the initiative and meet your expectations, it’s possible that they’re just waiting for you or someone to either provide them with the answer, or to give them the opportunity to step in.

They may not have known who can make a certain decision, where they can discuss a certain topic, or that you want them to make a decision in the first place.

They might be blocked without knowing it. The surprising effect of setting clear expectations can be that your team is suddenly unblocked and can move forward.

Expectations help grow new leaders

There’s another benefit from setting clear expectations for your team and then letting them take the lead. It’s an opportunity for folks from your team to step up and lead projects, working groups, or meetings. This allows engineers to improve on skills that aren’t associated with writing code but that may become more relevant as they grow more senior.

Setting expectations helps you scale

Delegating more work to your team has a benefit for you as their manager too. Instead of always bringing them the answers, you step out of a cycle. Your team gets used to coming to you for answers and decisions because you always provide them.

Instead you focus on setting the right context and the outcomes rather than be involved in the discussion and decision making. That gives you more time to focus on other things.

It can be deeply uncomfortable to remove yourself from important discussions. You used to have a clear work mode that seemed to contribute value to your team by unblocking them, by making decisions for them, by patiently answering their questions.

By setting expectations you’re not a part of this loop anymore. You find yourself with more free time and less on your plate.

Filling this gap can be a challenge. For a starting point, you could pick one of the topics from the top to get into a more strategic work mode. Or you could work with your manager to find specific areas where you could contribute and grow.

It takes guts and practice to say “Y’all can do this without me. I trust you with this.” But there’s something incredibly freeing about it too.

Setting clear expectations is a leadership skill

Senior technical leadership requires you to remove yourself from many day-to-day discussions. You’ll be focused more on higher level processes so that your team can focus on the work. You’ll be focused on work where your time is spent with the highest leverage, the highest impact on your team. Setting expectations and letting teams lead areas and make decisions on their own is part of this work.

Note that this isn’t quite the same as “getting out of the way.” It’s getting out of the way by setting a clear focus on what your team should focus on and giving them the tools to achieve a good outcome.

The next time you find yourself in a situation where your team involves you in discussions or decisions, take a step back. Check if there’s an opportunity for your team to step up and for you to step away.

  • Write down a set of outcomes that you’d like them to achieve and communicate those. Note that an outcome isn’t the same as a specific result. Ideally you focus on what you want them to do rather than dictating the exact result they should back to you with.
  • Provide sufficient context for your team to achieve the goal. This could include things that you’re thinking about when you approach the topic at hand.
  • If you’re not certain whether your team has the right skills, write down how you would approach going through the process. This can result in a short process description or framework to guide your team.

It takes practice and patience to get your team to take a more active role in decision making and leading discussions. You’ll need to review and adjust your approach and your team’s output several times over until you’ve found the sweet spot. But it’s work worth doing, for your team’s sake and for you as a leader. In the long run, everyone will benefit from clarity on expectations.

Thanks to Daniel Schauenberg for an early review, corrections and feedback.

One of the greatest challenges for a manager is finding ways to channel the constant pulling into different directions. These days, that pull is likely also true, especially in a distributed team where it’s easy to get pulled into Slack discussions and lose track of priorities. At least that’s been my experience in the past and in the present too, amplified further by now having a management role.

As a manager, trying to balance being there for your team (both for individual team members and the team as a whole) but also finding time to focus on the bigger topics presents a challenge, as the desire is first and foremost to be there for your team to support them, to answer questions, and to get blockers out of the way.

Over the years, I’ve been trying a few ways of handling and channeling the different pulls as well as finding time for focused work, time to ponder and reflect on things and work on the bigger topics that are on my own agenda.

In a couple of recent 1:1s I’ve had, the topic of staying productive came up and I offered to write up a couple of my systems. What I'm outlining below is an overview of the system I'm using (or have used) to structure the time that I don't have directly alloted to meetings or interaction with my team, like 1:1s for example.

Chunks of Focus Time

The core element of all of the systems I have been using is that focused work needs blocks of dedicated time. The best way to manage these that I’ve found is to block them in my calendar. I have a block like that scheduled every morning and about until noon, which means they can’t be booked in any other way unless I choose to.

Those chunks of time I then break down into smaller chunks, e.g. 15 minutes dedicated to a specific task (which can also be scheduled on the calendar to make this approach fully explicit and to force yourself to really think through the work at hand).

I may or may not get the task done in the time allotted but it gives me guidance to think about what needs to happen next to move this particular project or item forward. It also fosters thinking about the smallest possible step, making it as actionable as possible.

During that chunk of time, and in an ideal world, there are no distractions. Either I turn off Slack for a while and try to only focus on the task at hand, removing distractions, but also telling the team that I’m doing so.

Setting these chunks of time for yourself is also about setting expectations for you and your team. If you feel like you need to be available for your team in some capacity, set up an escalation path and communicate that to your team, e.g. that they can text you in case of an emergency.

It doesn’t matter when you schedule these chunks of time, but it does help to be deliberate about putting them in your calendar. And, more importantly, you need to stick to them. Making productive use of these blocks of dedicated time requires discipline and constant adjustment. There are many distractions always at the ready to pull you out of that little bit of time you have. When in doubt, use something like Pomodoro or Hey Focus to focus or remove immediate distractions like chat apps or block social media sites.

You can start each larger block (e.g. when you have two hours) planning out how you’ll make use of the time available, planning out the smaller chunks of time in each block.

Parkinson’s Law

The main driver behind structuring my workday is Parkinson’s Law, and it’s worth mentioning. The law says that

Work expands so as to fill the time available for its completion.

This suggests that unless time is restricted work will expand endlessly. A common feeling and observation is that there’ll always be more work. Unless we limit the time available to it, we’ll spend more than eight hours of work time in a day. It’s too easy to give into that feeling and the desire to get more work done, especially for a manager, where a general feeling is that you don’t have much visible output yet still need to find time to focus on bigger topics.

Setting up chunks of time is one way to make sure that work doesn’t overwhelm. It requires discipline but also the acceptance that not everything that needs to get done will ever get done. There’s always more work to be done.

My favourite corollary to Parkinson’s Law is this, which is more in line with the approach I just detailed.

Work contracts to fit in the time we give it.

The Operating System

This is an idea and approach I’ve gotten from “The Startup CEO”.

The idea is to have a spreadsheet that includes all my current and ongoing projects, giving me an overview of the work I have available for the aforementioned chunks of time or should a window of time suddenly open up (e.g. because a meeting got delayed or cancelled).

Each project includes a list of action items that I could tackle next. These are on-point action items, concrete rather than vague, focused around getting them done in an hour or less than being too vague, which can leave a feeling of never making any progress.

I used to have this operating set up in Wunderlist, like so:

This can also be mapped into a spreadsheet or likely any other task tracking tool. It could also be a simple text file in Markdown.

The key is to keep the list of tasks short and focused only on what needs to happen next. This helps avoid having the task lists grow indefinitely, eventually leaving you feeling like you’re constantly behind.

The focus on projects also provides framing for the work to be done. Some work will always pop up that doesn’t fit into these, but these projects define the work that I should spend my dedicated chunks of focus time on.

Weekly Projects and Daily Tasks

I’ve since abandoned using the operating system and opted for something simpler.

I start every week by writing down 5-6 bigger projects that I’ll focus on. I write these in my notebook, mostly because I like paper and because writing them down forces me to think about the projects more than when I just type them into some task tracking tool. I prefer this kind of magic over tracking things electronically, which ends up just overwhelming me over time.

Every day, I start my day by writing down 5-6 tasks that I want to get done. Some of these tie directly in with the projects for the week (which is the whole point of defining these projects), others are based on work that doesn’t neatly tie into these but that still needs to get done.

The important piece is keeping these tasks actionable. If I need to leave a comment on some GitHub issue, that’s my task. If I need to figure out what my answer should be, that’s the task that needs to come first. If the tasks are too vague or include more than one step, progress on them will stretch over days (or weeks), and it won’t feel like you’re getting anything done.

I also keep a list of tasks that come up out of the blue for each week, or tasks that I need to do at some point, alongside the list of weekly projects, so I can remember to slot them in later.

All this happens in a notebook, so I don’t track these things electronically but rather focus on paper. If you’re looking for a simple methodology to follow, the Bullet Journal is nice. It’s similar to what I’m using but includes a couple of extra features.

Rotating Daily Topics

An approach I’ve recently adopted again is to dedicate certain days of my week to certain areas. Each day has a theme assigned to it that guides my focus further. Here are the themes I’m currently following:

  • Monday: Planning. This is when I go through my own projects, plan out my week, garden the ongoing work in the ELT and determine the projects and work I’m going to focus on during the week. This is also a good day to do expenses for a couple of minutes to make sure they’re up-to-date.
  • Tuesday: Marketing and Partnerships. Here I follow up on conference sponsorships, focus on marketing work, e.g. writing copy, review guest blog posts and follow up on partnerships.
  • Wednesday: Team and Culture. With this team I focus on topics like hiring, following up on or starting new discussions on cultural or company topics (think All Hands, OKRs, and the like).
  • Thursday: Customers. This is usually when I will spend time diving into customer support issues for a while, making sure that I stay in touch with helping customers and continue talking to them. When I have some customers where I’m the main contact for their accounts, this is the day I’ll follow up with them.
  • Friday: Strategy and Writing. Fridays I have scheduled to be out of the office. I’ll try to be mostly offline to spend time pondering larger topics, thinking about strategy and generally leaving slack time that allows me to reflect. I also leave some time on Fridays to write, either internal or external blog posts or to write reflections for myself. I tend to not schedule any company-related meetings on Fridays, too.

The idea for this approach is from Jack Dorsey and how he schedules his week (or how he used to, I can’t be sure). Note that I don’t follow his 80-100 hour work week. My normal work day will have no more than eight hours, with the exception of some of 9-10 hours (usually only one day per week).

The Value of Out of Office Time

Being away from the office and scheduling time to reflect on bigger topics or on yourself (the mark of every leader is to continuously work on themselves, absorb feedback and try to find new ways of approaching problems and questions).

Being away from the office and the usual work environment can help greatly with this, if only it means going to a coffee shop, putting on noise-cancelling headphones and grabbing a notebook to work on an important topic.

The same is true for taking walks, one of my key habits of having time to reflect. The mind wanders when its left on its own, with no immediate task in your head or screen directly in front of you to keep your mind busy.

Once it’s in free-flowing mode it can be nudged into all kinds of directions, by asking myself questions, or by thinking about a random topic. This time is incredibly valuable and is necessary to have dedicated time for reflection and thinking.

Weekly Review

This is something I’ve only recently adopted, inspired by my friend Cate.

In this review, I look at the bigger projects I’d scheduled for the previous week and the progress I’ve made on them. Then I write about the projects I’m focusing on next.

In addition I include a section of loose thoughts on different topics, which gives me an outlet for things that have been on my mind during the previous week or that don’t fit anywhere else. They can be related to company culture, personal observation, customer feedback, anything goes.

I like this approach as it gives visibility to the team (whether it’s my direct team or the whole team is something I’m still pondering) what’s on my agenda. Visibility in work is a general struggle for every manager, and a review that’s visible to your team can help increase this kind of visibility.

Your team will generally have more interest in where you are on your bigger projects rather than on every single small task that you check off. A weekly review is a nice approach on giving them insight into your overall progress.

Listening to the “This American Life” episode on the GM/Toyota NUMMI plant recently, one particular part struck me as interesting when it comes to culture.

Culture is something that everyone would love to be able to easily replicate. Companies like Etsy, Netflix and others are forging ahead with openness, open source and empowering employees when it comes to their production systems.

NUMMI was an attempt to bring Toyota’s principles in building cars to General Motors, the automotive giant that was struggling hard in the eighties and was eventually bailed out by the American tax payers in 2009.

Toyota’s production line is famous for a simple tool, the Andon cord that allowed every worker on the factory floor to stop the assembly line whenever they encountered a problem. This empowered every employee to work towards a single goal: quality.

At NUMMI, this same system was implemented, and very successfully so. Every worker in the factory initially worked for two weeks with a team at Toyota in Japan to fully experience how teamworks looks like. It didn’t exist inside GM before NUMMI was conceived.

The Andon cord is an essential tool in learning and improving quality continuously. Every stop of the production line is an opportunity to learn and to improve the production process.

Before the NUMMI experiment, and in the rest of GM, the one goal is to never stop the production line. Quantity over quality, at all times.

Quality at NUMMI thrived, and GM looked into implementing this in more of their factories.

This experiment failed as there was a lot of resistance in management, amongst the workers and in the unions (all of whom had been fully onboard at NUMMI).

One bit in particular was interesting about the adoption issues.

The Andon cord was installed in other factories too, but when workers used it, they were reprimanded for stopping the production line. Managers were paid by volume of cars leaving the factory. In other factories, the cord was cut down so it was harder to reach.

I found this bit fascinating in so many ways, and it made me think about culture.

We’d love to just take a blueprint from another company and apply that to ours. But culture is something you need to work hard on, something that takes years of learning and improving to bring about, and it requires continuous nurturing to stay healthy.

You can’t just replicate culture.