Imagine you’re a hiker and mountain climber.
You plan on marching through the wilderness to reach one of the many peaks in front of you. Once you decide on a peak, you have to make a detailed analysis of the landscape in front of you.
Doing so reveals canyons, forests, and rivers you have to cross. You only have limited supplies with you, so you have to guess which route you’ll be able to successfully take with what you have.
The same is true for engineering managers (EMs). You have goals you want to achieve, but you need a strategy to do so. Without a clear roadmap, time will pass with no clear progress.
Developing and implementing such a strategy comes down to four steps:
- Setting goals
- Creating steps
- Setting milestones
- Reviewing progress and making changes
This framework, however, is deceptively simple.
Even the best-laid plans will evolve
There isn’t always clear progress when you move through the wilderness. Sometimes, cliffs or thick woods block your path, and you have to backtrack. Other times, you don’t have the necessary gear to cross a difficult obstacle and have to move to another crossing.
The same is true for developing strategy. You may start with a clear vision, but you could soon discover you need to make changes to account for realities on the ground.
The fact you know you have to change your plan doesn’t mean you shouldn’t make one in the first place, though.
To help, you need to develop two skills:
- Making your best estimate
- And preparing for inevitable changes to that estimate
As the EM, you’re the one facilitating this process for your team. If you’re new to the job or are considering a move to the position, you need to be aware of what this entails and what pitfalls may await you.
1 - Setting goals
Before you start a journey ending with a climb, you must decide on a peak. The same goes when deciding what to do with your team as an EM – you need to know where you’re going before you start giving directions.
Goals benefit from being concrete, measurable, and achievable within a certain time frame. Compare these two versions:
- Bad: add more features to our product
- Good: develop ten new features within this year
If you have someone above you who sets long-term strategy, like a CTO, you’ll need to consult with them to find out what the company’s priorities are and where it needs to be in the long run. As the EM, it will be your job to translate that vision into action.
But sometimes, you’ll have to set the goals and vision yourself. This is especially true in smaller companies where EMs take on roles like the VP of Engineering or the CTO.
Our peak: migrating to a new platform
Once, I had to set the goal myself a few years ago when our team became limited by the PaaS we were using.
In the past, we used Heroku to publish applications. But there was an issue.
Our projects quickly outgrew this platform, and we needed to migrate somewhere else. Our long-term strategy was to find a new solution that wouldn’t require us to migrate again over the next few years.
After some deliberation, together, we made the decision to migrate to AWS. Once we settled on this as our “peak,” we started thinking of how exactly we were going to get there and when.
I can’t stress enough how important this initial stage of goal-setting is – you need to know where you want to go. Everything else will be defined by this destination, much like a climber’s path is defined by their mountain of choice.
2 - Creating steps
It’s easy to think of a goal like migrating to AWS and feel overwhelmed. It’s a huge process with dozens of moving pieces – you’ll never keep it all in your head.
So, you need to break your goal down into manageable pieces. For a hiker, this might mean:
- Moving through the forest
- Crossing the river
- Traversing the following canyon
- Reaching and climbing the peak
For you, it will be breaking down the goal into a series of actionable steps that can then be fit into a timeline.
The main thing to avoid at this stage is paralysis. Especially if you’re a perfectionist and feel a need to make a perfect set of steps the first time around.
Here’s a secret: you can’t.
No matter how good your first outline is, it’s always going to be the first in a long series of iterations that will get more optimized as you go on.
To avoid paralysis or perfectionism, I recommend turning off your inner critic when generating your first round of options. This means coming up even with crazy or unrealistic ideas. Write everything down just to get it on paper.
Then, you will need to consult with other core team members, like senior engineers and team leads. They’ll help you narrow down the choice of initial steps to something both appropriate and actionable.
Our path to AWS migration
There are far too many ways to migrate to AWS, so we had to find a concrete path that worked for us and our resources.
First, we decided what experience we wanted to keep from our previous platform and what we wanted to add.
For example, we:
- Were used to having certain metrics in our applications
- Had access to searching at least one month’s worth of logs
- Wanted engineers to have shell access to any machine they needed
- And we wanted it to work as seamlessly as it did on Heroku
We created our priorities from these and other requirements. I consulted with my lead engineer to evaluate different options. Once he gave me a list of pros and cons for each, we made our choice. We decided to use K8s for our architecture and agreed on individual pieces like the EKS stack. We also wrote an easy shell access tool for developers so we’d have the functionality we needed.
From there, we developed the following steps. We needed to:
- Create a container for just one application
- Implement logging and make logs searchable
- Implement monitoring
- Build a shell access tool
- Implement autoscaling
But these steps changed over time. There will always be unforeseen barriers that will require you to rethink your path, and that’s okay.
Think of yourself like a portrait artist, first making broad strokes and then only finishing with the details. The purpose of the first roadmap is to get you started.
3 - Setting deadlines and milestones
Once you know where you want to go and what you have to do to get there, you will have to decide on a timeline.
How long a task will take depends on its complexity and your team’s experience. That said, sometimes, it’s unclear exactly how much time you need until you’re knee-deep in the project.
As the EM, you should know about your engineer’s skills and capacities. If you are new to the position or the team, you will need to rely on other managers and senior ICs to fill you in.
The thing is, you have to do this knowing that an estimate is an estimate, and it’ll be hard to predict the delays and issues that will come over the course of the project. Which means you’ll also have to plan in time for the unexpected.
For instance, there will be some projects whose later phases will only become clear once you reach the first milestone. This is easier if you don’t have a hard deadline, as you’ll be able to take the time you need as you move forward.
But if you find yourself running out of time, you may have to adjust your scope.
Imagine you have a year to finish a project, and you projected ten stages that would take one month each. This would give you time to spare. But if each stage takes two months, you’ll have to limit yourself to six to meet the original deadline.
Our timeline for AWS migration
We were lucky enough not to have a major deadline for our migration. Which was good, because it took us two months before we could choose Kubernetes with confidence. If we only had a year, that would have meant we’d only have ten more months left to complete the migration.
When you have time restraints, you have to take shortcuts. If we were restricted, we would have initially had to use off-the-shelf logging and monitoring tools instead of open-source and installed-on-premise. We would switch to on-prem installations later, but it would take time to do them properly.
This would have been more expensive. We would have had to use their enterprise versions to get all the security knobs we needed.
So, while we would be saving money as our engineers would spend less time on the project, the predicted costs would still have to include the software that helps us take those shortcuts. But this would have let us finish on time – there are always tradeoffs.
Every project is going to be different, but as the EM you have to think about these possibilities, make your best estimate, and go from there.
4 - Review
You will need to build in dedicated review time over the course of the project. This means occasionally re-evaluating strategy with your superiors. This is especially true when new developments, such as AI, radically change the landscape for your company.
But it matters less how often you do these reviews than whether you do them consistently.
Some do large reviews every quarter, some every month. Some teams plan them around milestones.
Think about these reviews like driving through the mountains. If you had done this a generation ago, you would have used a paper map. But imagine there’s a landslide on one of the roads. Even if the map clearly shows all nearby roads, you won’t be able to tell whether the landslide affected any other ones.
You need to develop systems that are more like driving with an app. If there’s a traffic jam or accident, the system analyzes all possible routes, finds the best one, and sends you there.
Protect your time
All the points listed above only happen if you carve out time for planning and reflection.
That’s easier said than done. As the EM, you’re constantly beset on all sides with requests, meetings, calls, one-on-ones, and more.
I cope with this by having two professional personas in my head. The first is the one that does everyday tasks like resolving conflicts, advising my peers, and listening to my team. The second is an internal manager who manages me while keeping an eye on the big picture.
When people demand your attention, they’re unintentionally stealing time from your second persona. The only way you can give the proper attention to your second persona is setting aside time that is sacred – no one is allowed to bother you during it.
This could be half a day every week or an hour or so at the beginning or end of each day. It doesn’t matter which regime you have – it just needs to be protected.
The short version: break it down, take your time, execute, and adjust
If you want to get somewhere with your team, you need to develop a strategy and a roadmap for getting there. Your strategy is going to come down to a few components:
- Setting goals with the help of your superiors and senior ICs
- Creating smaller, actionable steps that get you closer to those goals
- Marking deadlines for those steps and doing a broader timeline
- Reviewing all of the above over time
- Setting aside undisturbed time during the week for reflection and planning
Don’t be afraid if the final result isn’t exactly what you projected at the start – it rarely is. What’s most important is that you learn how to pivot to where you need to go in the least amount of time.
Want more tips on leading effective software engineering teams?
Join my newsletter if you’ve found this content useful
Originally published on Medium.com
Content in this blog post by Alex Ponomarev is licensed under CC BY 4.0.