This is episode 2 of my series on life as an Engineering Manager (check out episode 1). In this ep we dive in to how you should spend your time: what you should be doing, thinking about, worrying about, on any given day.
One of the questions my managers and I spend time on is “What should I be doing [today/now/next]?” When they were an engineer, this wasn’t a concern: they were working on a feature or a technical initiative, and the current phase was clear: exploration, technical design, estimating and planning, execution, testing, integration. All of the various software development processes (agile, waterfall, kanban, scrumban, kangile, scrumgilefall, etc) are there to help identify, track, and metricize the cycle of technical work. You always know what you should be doing, because your Jira tickets / whiteboard stickies / Pivotal Tracker make it very clear. Many dollars are spent on agile software, scrummaster hours, and 75" TVs showing metrics on every wall to ensure engineers’ very valuable time is well-spent.
But, jumping into management, there is no process for the work. There are no management stickie tracking systems, no project managers to help organize your work. There’s no Big Board telling you what to do next. This can initially seem chaotic or scary or underspecified. And, in a way, it is — the work generally is much more randomized than software development.
So, you roll into work in the morning, fire up the Nespresso, and then land at your desk. What do you do now?
The tools of the trade
Before we get into what should be on your TODO list, let’s spend a moment talking about where that list lives. Get yourself some sort of tracking system. Find your favorite task tracking app — like Trello, Remember the Milk, Things, or perhaps paper and pens? Make sure you can access your list from anywhere — your laptop, your phone, your refrigerator’s touch screen. Moving to management generally means the number of items you are tracking grows dramatically — there will be plenty of little things that you need to remember, and if you drop the ball on any of them, it is bad.
Responding to things
Get good at responsiveness—since your outcomes generally will rely on other people (“Indirect engineering” from ep1), velocity and accuracy of communication is imperative. Make sure your Slack channels notify you at all hours; make sure your email filters are finely tuned; make sure your team knows you will respond right away if they need something.
If something arrives that you can’t respond to right away — either because you need more time to consider it, or you are on a higher priority task — make sure you have a way to get reminded about it later. Add it to your TODO list, or use Slack’s “remind me” feature, or put the email in a “due by EOD” folder. Don’t drop things. Your organizational skills are emblematic of your skills as a manager, and so communication and follow-through are mission critical.
You can’t do everything at once — humans can’t multitask. And as a manager you will be bombarded with inputs, requests, questions, distractions, fires to fight, etc. And part of your job is to field all this, so it doesn’t hit your team and distract them.
But you can’t do it all— so you need to prioritize. Whether it is “Sally, your team needs to build Feature X right now or the company will implode!” or “Jensen, respond to this lengthy email right away!”, you need to weigh this time against all the other demands: Features Y and Z that are also mission critical, or all the other emails and communications waiting for you. In other words, you need to be relentlessly vigilant with your team’s time, and with your own.
And this means saying No sometimes. But how you say No is also important: “Let’s work together to figure out where this stands amidst the other ongoing projects” is better than “Sorry, we’re not building Feature X”. A quick email of “Let me get those results to you by Friday” is better than letting the thread drop.
So make sure you are ruthlessly prioritizing your and your team’s workload. Your prioritization always has to be against business goals and needs, so you need to evolve a good eye for maximizing business impact. Talk to your boss, other Engineering leaders, and your peers in Product Management, to make sure everyone is aligned. More on business goals in episode 4.
Now, let’s explore some ways of determining what you should do today. Some of the major areas to consider are:
- What should I do that no one else can do?
- How should I support my team?
- How should my team support the business?
- Everything else!
Let’s dive in:
What should I do that no one else can do?
And by that, I mean — what is the engineering manager role for? What function does it serve in a company, that no other role covers? You need to have a clear understanding of this — talk with your boss and your peers to align. Here are some of the key areas:
Driving your technical initiatives
In episode 3, we will get into the whats, whys, and hows of technical initiatives. For now, let’s consider technical initiatives to be all engineering work that is motivated and defined by Engineering — and it is important. As an engineering leader, this is one of the most critical roles you fill. Spend time on this, make sure it is moving forward, make sure you are achieving your technical goals.
Today’s tasks: Depending on the status of each technical initiative, take steps to move it forward! Go be a cheerleader, a driver, and a technical problem solver!
Always be hiring. Generally, if you are working for an exciting, growing business, there is plenty of hiring to do. But even if not, you need to figure out how to find excellent people and get them on board.
Larger companies have recruiting teams who handle much of the logistics of hiring. But, that doesn’t excuse you from spending time on this — it just shifts where you spend your time. You still need to be talking to candidates, attending events where they might be, and evaluating your process.
Today’s tasks: Review new resumes that have come in. For high-pri candidates, make sure they are moving forward in the pipeline — ping the recruiting team and lean on them to make sure your candidates are at the top of their list.
How should I support my team?
As we discussed in episode 1, your success is only through the success of your engineers. So, you need to do everything you can to enable that — this is the people management side of the role. Here are some things you should do to support that.
Spend time with your people. I recommend you schedule weekly 1:1s with your team. Some weeks you can skip them, or some weeks you’ll need more than a half hour. But you need them on the calendar, since it is so easy for this time to vaporize.
The 1:1 is a time to talk about anything other than the day-to-day work. There are enough forums to talk about that (scrum planning meetings, standups, etc). The 1:1 is for all the other stuff: discussing obstacles, evaluating performance, fostering career growth, tackling strategic goals, pair-brainstorming. Make sure you discuss any topics your team member has, before your agenda. You should take the time to provoke deeper conversations — ask them questions about these heavier topics, since it is so easy for these to go overlooked across multiple months.
For any given week, pick a topic that you will dive into with each of your team members in their 1:1s. One week ask them “How are you feeling about the company’s direction?” or “What do you want to accomplish by this time next year?” or “What new technology do you want to work with?” or “How is working with the other members of the team?”, etc. This makes sure you get a broad view of the thoughts and opinions of your team.
Today’s tasks: At the beginning of the week, determine what you are covering in this week’s 1:1s. Prep for each 1:1 by reviewing where people stand, and what questions you might have for them.
Success and failure
By what means do you represent success on your team, and identify areas for improvement? How will you show your boss that your team is doing well?
You need to establish the yardsticks for your team’s success. Perhaps your larger Eng org already has some of these — scrum team velocity, or high-level goals, etc. That’s great. But you need to specifically identify the goals or metrics that are unique to your team. What will the impact be if your team is successful? Is there a way to differentiate between wild success and mild success? If not, you need to create this. You need to set aggressive goals for your team, and then push them to accomplish this.
You need to do the same thing for each individual. Everyone should have a clear articulation of success. You should write down what you expect from each person in 1 week, 1 month, 1 year, and then align with each person on this. Then, you need to track where each person stands against those goals. This can feel pedantic or nitpicking, but is important.
So, on a daily or weekly basis, you need to think through how each person is doing. Better to give little feedback every week, than to hit someone with a huge bomb when the problem has gotten out of control. Sit down, think about things, ping people on Slack if you are wondering where their projects are, and formulate an opinion. Use your standups and your 1:1s to hone that opinion, and based on your point of view, provide support for your team members.
Today’s tasks: If you don’t have your metrics and goals set up yet, do that. Once they are operational, watch them daily: are tickets getting completed, are delivery targets achieved, is each team member on track.
Help with blockers
Note — I didn’t say “remove blockers”. A manager’s job isn’t to take care of problems that their team members face. That doesn’t scale, nor do you want to be on the critical path to removing blockers — if you are the only one on the team that can remove them, then your team will be doubly blocked if you have a dentist appointment or you get hit by a bus.
Your job as a manager is to help with blockers: if your team member needs guidance on how to remove blockers, provide this. If the blockers are external to your team, help solve that problem, but also then figure out how to adjust processes and procedures to avoid inter-team blockers. If the blockers are technical, you should draw on the resources in your team or beyond to figure out how to resolve them.
You do need to ensure that blockers don’t last more than a working day — ongoing blockers are deadly to overall productivity.
Today’s tasks: based on the status from today’s and yesterday’s standups, ensure all blockers are on a path to resolution. Ping all the relevant people or channels to make sure things are back underway. Get people together in person if you are not satisfied.
How should my team support the business?
A big part of being an engineering leader is providing a bridge between technical needs, activities, and strategies, and business needs, activities, and strategies. You need to deeply understand both worlds so that you can ensure both aspects are being serviced, and you need to ruthlessly prioritize so that you and your team are maximizing your business impact.
Work closely with Product Management
From Engineering’s perspective, Product Management represents the business. The Product team’s principal role at a company is to assimilate data from across the business, customer base, and industry, and formulate a product plan that optimizes the business outcomes. Therefore, you need to have an extremely tight relationship with your counterparts in Product. You should have a weekly 1:1 with any relevant Product folks, and you should have a recurring planning meeting to which you and Product bring ideas, concerns, and problems to work on together.
Typically, the Product team is also the arbiter of whether your team’s work has hit its mark. This needs to be an ongoing, lightweight interaction: they need to be able to review work while it is in progress, versus waiting til it is all done before they discover it isn’t what they were expecting. Make sure you build out a way for them to have eyes on your team’s work: a staging environment, or daily builds, or whatnot.
Software engineering is more art than science, and that is why estimating it is hard. When projects start to go off the rails, it is up to you and your peers in Product to figure out how to right the ship. You need to partner with them to prioritize, adjust scope, or move team members around, to optimize the overall delivery. The most important thing is that you defend quality — cutting corners is not an option — so you must pull other levers to solve the problem.
Today’s tasks: Collect any topics for the upcoming planning meeting with Product. Ensure that the Product team has an updated view of the work your team is doing. If anything is looking at risk, plan to discuss it at standup or the planning meeting or in a special session.
Understand your industry, customer, and user
For any engineering team to be successful, they need to understand the user of the software they are building. For some software this is easy: if you are building software that is to be used by other software engineers, you are already the target user. In other cases, this can be very challenging, if your target user is very different from who your team is. It is critical to bridge this gap and gain context about your user: what are their challenges, what do they want out of your software, how do they use your software.
You need to find any available means to collect this intel: join customer calls, track incoming support tickets, observe user testing, etc. If your customers are companies, and you can shadow an implementation, you should do so. If you can instrument your product with user analytics, you should do so. Create whatever dashboards you can to synthesize all these inputs into actionable information. You should then digest all of this, and share it with your team.
Meanwhile, you also need to understand the industry your company plays in. You should find a source for relevant industry news, and keep on top of that. You should spend time chatting with leaders across your business to glean their insights, concerns, and ideas.
Today’s tasks: Scan industry news headlines and read relevant articles. Review user or customer intel: usage data, support tickets, etc. Get involved in any of your company’s relevant user or customer activity.
After you have spent time on the activities unique to your role, supporting your team’s work, and furthering your team’s impact on the business, you can spend your time on all the other things you need to do:
- Thinking time: Make sure you take time to think about stuff — to brainstorm, strategize, evaluate. Your schedule will become full of meetings and 1:1s and other tactical things, so you need to make sure you carve out time for your own thought time. This is critical. Block time on your calendar, if that is what it takes. More on this in a later episode.
- Individual contributorship: Depending on the situation, you may need to be doing actual work: coding, etc. If this is part of your role, make sure you get it done — but not at the expense of everything listed above.
- Training: Every person in every role at every company should take time to improve themselves — including you. Figure out what resources you can utilize to do so, to improve at your job.