You feel overwhelmed, you have more than 100 different tasks, your schedule is stuffed with meetings and you can hardly find time for focused work.
If any of this sounds familiar to you, then this post is exactly for you.
How are you supposed sharpen your time management skill? What is productivity for an engineering manager? Figuring this out is 50% of your job, while the other 50% is enough to bury you under an avalanche of work.
Here you’ll find actionable tips to improve time management for managers. We’ll uncover productivity tricks and myths for you to move ahead on your way to becoming a better engineering manager.
Leadership and work-life balance is never easy, but I’ll use the transitioning from engineering to management as an example. It’s an extremely difficult phase, because these people often try to do two functions at once. It's common in our industry to ask engineers to transition into management while they’re still doing individual contributor work.
Later on, you’ll be spending all your time managing the team, and your roles and responsibilities increase with time. Always consider what phase you're in, because the solutions will be different. People in the transition process are often overwhelmed, even by the advice they get from seasoned leaders.
Engineering management is a difficult job to do well.
Don't be too harsh on yourself. You’ll often feel like you're behind, like you're not doing your job well. You add to your own stress and anxiety by being harsh and continuously evaluating yourself.
There are simple steps you can take to start getting better. Becoming a great engineering manager means doing a couple of things every day. You can’t get there overnight, so cut yourself some slack, and you'll be under less stress.
This is the very foundation for everything you do to manage your time effectively: examine your calendar and take stock of your time.
Your time is the key building block of the work you do in a week and for how much of it you can allocate to different tasks. I advise people to dive into their calendar, and understand what the necessities are. It tells you what you have time for.
Doing a calendar audit only takes a few minutes, but it’ll help you tremendously. I try to do a calendar audit monthly, and some even do it weekly. The point is to make sure your baseline hasn't shifted dramatically.
After you’ve scheduled all the critical meetings, you need to make time to be proactive about your job to get ahead and to lead your team. This is the biggest challenge for engineering managers, so don't be too hard on yourself. Even the best managers have weeks where they're running around, putting out fires, constantly reacting.
In the transitional phase while you're still writing code, you'll likely have a lot of time beyond essential meetings, so balancing them is the trick. Full-time managers may be surprised with how little proactive time they have in a given week. Keep in mind that a lot of white space in your calendar will be used for context switching, conversations, emails, etc.
You're going to use what you’ve learned for figuring out how much time you need to block off, to do the proactive work that you need.
When you hear about a calendar audit, it doesn't sound like fun. It can feel overwhelming, but it’s also simple. My advice is to do it once, and see how it feels.
This is how you do it.
Take a look at your typical week. Look back on the last few weeks to get a sample for a typical week, because if you look forward, you don’t get a realistic view of what your week looks like. People schedule with you during the course of the week, and things pop up that may not be on your calendar yet.
Take a look at your calendar in a standard week, and categorize all your meetings into a level of importance on a scale from 1-5. One means, “I don't know why I need to be there; this is the least important meeting,” Five means, “If I’m not there, I’ll be fired.”
I’ll give you examples on how to rank your meetings.
Ones are easy to handle; get them off your calendar.
Meetings ranking at two don't need to be recurring responsibilities. Maybe you like to do them, but you should critically evaluate whether you need them.
Meetings you rank at three is where it gets interesting. They’re relevant, but they don’t demand your presence, so with some effort, you may enable someone to take them off your plate. You can’t do it overnight, but you can prepare others to do a code review or to handle a recurring team meeting.
Meetings ranked at four are ones that if you don’t show up consistently, or cancel, you can’t function in your job. These may be one-on-ones with your direct reports, recurring team meetings, etc.
It’s a five if you're running the meeting or if it's critical to your job. If you don't show up to it, it's going to reflect on you poorly. This may be a one-on-one with your manager or doing critical reviews, etc.
The point is to figure out the immovable objects on your calendar.
Fives and fours are critical. So, how much of your week do you spend in these meetings? For most managers, it’s in the 10-40% range, depending on career phase.
You have the most to gain with meetings ranking at three and two. You can get rid of them instantly or by handing them down to someone else over time.
Doing a calendar audit is a simple task; it only takes a few minutes. The idea is to get an honest view of how much time you have left in a week for proactive managerial work.
Let's take the transitioning manager’s perspective, because that's the most complicated. You have the baseline, and you found that in a week, you have 15-20 hours of meetings, and 10 hours of this are essential. In a typical 40-hour work week, you have 20-30 hours to play with.
You have 5-10 hours of optional meetings. You can start reducing the optional meeting time or accept this as an area for improvement, and focus on the rest of the week. It’s up to you, depending on what you need to make time for.
As for the remaining time, a transitional manager is going to have a hard time cramming engineering and proactive management work into 20 hours. It’s a tough challenge for anyone. So, you have to be strict about setting aside time both for focused software engineering and for managerial work.
It’s easier for a full-time manager, but let’s stick with the complicated example. If you only have 20 hours to do both these functions, you need to carve out at least four hours a week to manage proactively. Then you only have 16 hours left to do your engineer work, and that’s not even too bad.
Then you can set aside Tuesdays and Thursdays for writing code, and move your meetings off those days. You could do one-on-one meetings on Wednesdays, and dedicate the afternoon to proactive management work. Schedule it in your calendar, and don’t allow anyone to interrupt you at that time.
Dedicate this time to the needs of your team. Think about the careers of your team members, the most important things your team needs to accomplish, and how you can unblock them. New managers often feel this part of the job is awkward.
You sit down for four hours, while there are a million fires to put out. The temptation to focus on these fires and what your team is asking for is almost irresistible. It feels better than sitting around and thinking about the future needs of your team.
But you need to do this. It’s the only way you get yourself out of debt and force yourself into the habit of managing proactively.
Start with at least two-hour blocks of these proactive management thinking sessions each week, if you can afford it. Two one-hour blocks are still better than nothing.
It's going to feel unnecessary at first, and you’ll struggle with filling it. But over time, it’s going to become critical for you to think about strategy, quarterly targets, and career development. It's going to make you a better engineering manager.
You don't need to start with career development and future objectives. The need to ship one aspect of the product is a valid answer. It’s okay to stay tactical; that’s where new managers feel the most comfortable.
The most important aspect is to get into the habit of thinking critically in the long-term, rather than constantly focusing on the daily tasks. Over time, considering long-term strategies, like career development, will come naturally.
Here are tactical questions to ask yourself in these sessions:
Here are some tactical decisions I’ve made in these sessions:
Here are strategic questions you can ask yourself:
Use this time to manage your own career by evaluating your performance as an engineering manager. A useful way to approach figuring out how to evaluate your own work every week is to put yourself in the mindset of your boss.
You can think about it in three dimensions; it’s a common framework. Consider how you’re managing down, managing up, and managing horizontally. If your company does peer reviews, or 360 reviews, you’ll get feedback from all three levels about how you're doing.
You can use this information in your proactive time to improve.
Managing down means managing the people on your team. Managing up means communicating and being responsive to your boss. Managing horizontally is about keeping in sync and coordinating with your peers, like other engineering managers and product managers.
For example, you get feedback from your manager saying he feels out of sync with what your team is doing, and he needs more information. To improve on this, you can set yourself a reminder to write a message to your manager about what’s going on and how your progress is.
When managing horizontally, you want to communicate the right set of information, so the peers your team relies on can spot issues in time.
It’s often key for a product manager or a design leader to understand what your team is working on. A sign to look out for is the feeling that someone consistently blocks you. There may be many reasons for this, but it could be that you aren't doing a good job at communicating where your team is headed and what you need.
When it comes to managing down, you want to make sure that your team understands the roadmap, and where they fit in. You need transparent feedback, so their understanding of how they're performing is similar to yours. If you find a difference there, you want to start working on bringing yourselves to the same page.
It's hard to find hard metrics for engineering managers. It's a subjective role, and it makes the transition from software engineering to management a difficult one.
Engineers are familiar with objective measurements, and the feedback loop for an individual contributor is quick. You write code, see the results, and you ship it.
The feedback loop for managers is longer. It’s weeks at best, but it’s often months or even years before you see the results of good management. The measurements are also subjective.
I can point to one hardcore metric, and it’s how you’re managing your time.
This is the most important contributing factor to how you function in your job. You can monitor how much time you spend weekly on your proactive tasks. That’ll help you understand how much you can get ahead. If you spend a week reacting, you're going to be less effective as a manager.
Subjective measures are easier to find; there are many out there. You can use the feedback from your team, your peers and from your manager.
There’s one definitive subjective metric that summarizes everything: do people want to be on your team? It’s hard to measure, and you often don't know about it directly. But great managers are going to gain a reputation, and people will want to work for them.
This is what you want as an engineering manager expanding your career: a reputation for being effective, supportive to your team, and managing communication well.
An effective way to provide opportunities for your team to grow is to hand down some meetings you ranked 3 for your team members to lead. Those people are good candidates for giving opportunities to expand their careers.
Here’s an example from my own career:
I had a front-end engineering team meeting every Friday over lunch. As my duties expanded, and I started managing managers, I wasn't doing a good job of setting the agenda, collecting topics, and leading the discussion.
I didn’t set aside enough proactive time to do that, and other things consumed my time. It took me too long to realize that it was an opportunity for another team member to step up and lead this meeting.
Engineering managers tend to feel like it's their duty to take on the non-technical work. Never forget that your team members will want to participate in the team-building aspects too.
I found an engineer on my team who wanted to take a more active role. He was eager to help, put together the agenda, and sync with other people. He couldn’t do it alone for the first meeting, but by the third time, he could run it effectively.
With one stroke:
I've struggled with delegating effectively in the past. It's easy for managers at all levels to take on more work than they need to.
New engineering managers are often comfortable with a certain area in the code base, while others are struggling with it. It comes naturally to say, “I know the code. I'll dive in and fix it.” Depending on the context, jumping in and helping out like that might be the right decision.
But when it happens often, recognize it as a sign that you’re not delegating properly. Anytime you're actively taking work back from your team, it’s a red flag. This means you're going in the wrong direction.
It happens with managers of all stripes. I do it too; it's very human. Just make sure to recognize it as a bad sign.
The toughest thing about delegating is that you’re often better at doing a task. Usually, you get promoted for a reason. You know the context, you have the information, and you've probably been a great individual contributor.
You might be the best person for a task, but that doesn't mean you should do it. If there's an opportunity to put a task on a team member, think critically about delegating it to them.
Make sure there's a delineation of roles and responsibilities. This is tricky when you’re transitioning into management but still doing IC work. Once you're an engineering manager that's moved on from IC work, don’t dive back into projects ad hoc.
I think it's important for engineering managers to set aside some time to do software engineering every week, just to stay familiar with the codebase. But this is different from sliding back into doing day-to-day IC work.
Think about roles and responsibilities on a strategic level for your team. Think about areas where you can offload some of the smaller tasks to your team, like research or preparations.
Your team members will often jump at the opportunity to take this work off your hands. They see it as a way to level themselves up.
This is going to take getting used to on your part, and it'll feel less efficient. But you need to master delegating effectively to be a great engineering manager.
I set aside time for emails in my calendar. As you can tell, I’m calendar oriented. If you look at top performers in any field, most of them use their calendar as a record of truth.
Make space for essential tasks you know about in advance. I consider answering emails reactive time, so I schedule it.
I leave a 30-minute block in the morning every day. It doesn't matter if it’s at 8am or at 11:30am, as long as I have it. I've set the expectation that email is for long-form communication that isn’t extremely time-sensitive.
Get rid of the crap in your email, and unsubscribe from useless stuff to get those spam emails out.
As you move up in the organization, you’ll need to see different emails. For example, I don't need to see Datadog Daily Digest reports anymore. Make sure to get rid of the crud.
I have a mentor who's been in the business for 40 years; he's been a CEO at a major company. He set the expectation in his companies by always arriving to meetings on time.
If people weren't there on time, he left. It was a clear message, and others in the organization started following his example.
I’ve never done it this severely. If people are late, and you start the meeting, they're still going to get the message. It's a matter of company culture, and if you let it slide, it's going to bleed into everything.
He also set an expectation for meetings by asking at the start:
If the answer wasn’t clear, or key people were missing, he left to set the expectation. Again, you don’t have to be this hard about it, but it's sound advice. You lead by example, and people will follow.
There are different approaches to run meetings. You need to understand that the same way doesn’t work for everyone.
Many people think that every meeting should start with ten minutes to read the agenda, or that every meeting should have a key decision-maker. In my opinion, that's not true. A stand-up is different from a one-on-one, a staff meeting, or a team sync.
Make sure to use the right tools for the right meeting.
I think that any meeting with more than two people should have one person responsible for the topic. This person needs to be able to articulate why everyone is in the room. This may take the shape of an agenda or starting with a presentation about what needs to be resolved.
You want to avoid going to meetings where everybody is confused about why they're there. It's your job as a manager to ask these questions, and to work out with your team how to conduct your meetings and what tools to use.
Make sure to pick a method, and go from there. Don't allow the answer to be, “We'll just get in the room and figure it out.” It's easy to put the topic in the meeting description or to spin up an agenda.
We use the Amazon model at Clockwise. We set aside 5-10 minutes at the start of the meeting to read the materials critical for making decisions in the meeting.
You should find what's best for you, but it's important to choose a method.
Sometimes, you’re not just in meetings back to back all day, but you’re double-booked. This can be a real environment, especially if you’re resource constraint.
The first step to me is the same every time: take stock of where you are today. Do a calendar audit, and analyze how much time you have.
Go to your manager and have a conversation about it. Say “This is what it’s like on the ground right now. I don't have time to get ahead, so we need to come to terms with that.”
In a worst-case scenario, there's no way to make an impact at the moment, but at least your manager will understand that you can’t be as effective as you'd like to be. If this continues indefinitely, it becomes a limiter on your career. If this happens, you should evaluate whether the organization can give you the necessary support.
When the situation isn’t that bad, you should focus on blocking off time for the work you need to do on your calendar. Get rid of low priority stuff, and move flexible appointments around.
It's okay to move meetings, just make sure not to give yourself a privileged position or put yourself above your teammates. But when your time is the limiter for your team, you can move things around for yourself, as long as it works for your team.
You need to have this time for yourself. Block it off, and protect that time religiously. If you don't have this, you'll be stuck in reactive mode all the time.
It's only human that you’d rather put out the immediate fires or do your emails. But you need to use this time to think about the critical things your team needs to move forward.
The biggest productivity killer in an open office is the ad-hoc conversations. It’s tough to balance, because it’s also the most fun aspect of the office environment. These discussions also spark creativity and ingenuity.
It's about making the space for them in the right way.
Be conscious about when you're open for these talks and when you're not. For example, you really don’t want to be interrupted in your proactive management time. Set rules for yourself and put on headphones to show you're not available for conversations.
Slack is a big one for me. It can enhance productivity, or destroy it. At the time of this interview, many people are working remotely due to COVID-19, so it’s a key communication tool, but you need to manage it right. If you think about it as part of your environment, it can take over and eat all your time.
My advice is to think of Slack as an asynchronous communication mode, like e-mail. It's easy to view it as a synchronous channel.
I’ve seen it happen many times: when team members send you a message in Slack, they stop working until they get a response. They expect an instant answer. They’re used to it, so they’ll wait for it.
This is damaging for both sides.
The one sending the message stops moving forward to wait for you. This puts pressure on you to stop what you're doing and respond. It’s usually not explicit, just a casual expectation that you'll respond.
Sending the expectation that you're not a synchronous responder, breaks this in a productive way.
You don’t have to be rude about it. Set the expectation by closing Slack, or turning on “do not disturb” and replying in batches. Once people see you’re unavailable, they won’t expect an instant response, and they will leave you a message for later.
The key is to stick to this practice, and it’ll make behaviors shift. We’ve done this at our company, and I think it’s effective, so I’d recommend this for everyone.
The same goes for all types of communication, like somebody tapping on your shoulder. Show clear expectations about when you're available and when it has to be an emergency for anyone to interrupt you.
If everything needs an instant response, you can’t function. So, it's your job as an engineering manager to set the expectations around communication. Get everyone on the same page, and make sure people understand the rituals.
Whether it’s a “do not disturb” in Slack, setting the headphones rule, or anything else, you need to set the expectations for your team.
I'm sure everybody's familiar with the mythical man-month.
The basic idea is that more members on the team don't necessarily mean an increase in productivity. There is a time for ramping up manpower. I assume most engineering managers are familiar with the concept, so I won’t go into details.
Another myth is that more hours equals better productivity.
But people burn out, and they have a limit on how productive they can be in a day. The limit is different for each individual, for the stage of their lives they’re in, and for the type of work they’re doing.
But more hours don’t always mean more productivity.
Productivity is heavily influenced by the type of hours you have. There's a real impact to context switching and running from meeting to meeting. A two-hour block facilitates different work from a 30-minute block.
Try to make time for your engineering teams to go heads-down on a specific task for an extended period. It allows them to get into the flow. One two-hour or four-hour block is inherently more valuable than the same time split up through the day.
Another aspect of this is focus. Focusing on one thing at a time, instead of multitasking, reduces the tax of context switching and the overhead of jumping back and forth between projects.
Trying to maximize efficiency and productivity right now is a common mistake. Productivity in the long run looks different than efficiency in the next week.
Here’s an example.
It takes time to figure out how to delegate a specific part of your job to a team member. It’ll likely take increased investment in that team member over the next few weeks. If you did the task yourself, it’d take an hour, while delegating the same task might take you 30 minutes and two hours for your report to complete.
It doesn’t look efficient.
But in the long run, you increase the overall capacity of your team. And your job as a manager is to think about the long-term productivity of your team. Be careful about the trade-offs between short-term efficiency and long-term capacity.
Always make sure you're not trading the team’s long-term interests for a short-term advantage.
When you’re doing well, you should feel like you're less underwater. Being an engineering manager often feels like you can’t catch your breath, so you’ll recognize the moments when you can.
You go home on a Friday feeling like everything’s under control, and you get to have your weekend. Or you go home on a Tuesday night and watch Netflix, without responding to Slack messages before tomorrow morning, and you don’t feel bad about it.
The dedication to having that proactive management time every week allows you to get pressure off yourself.
It’s simple math. You only have so many hours in a week. If you don’t make time for your proactive management work in the week, one of two things is going to happen.
Either you won’t have time for it at all. Then it's going to be stuck in the back of your head, leading to anxiety. You’ll think about it in the shower, at night, and when you wake up.
Or you do it after hours. This leads to burnout, because you won’t have time to relax. You won’t have time to think about critical issues, and you just end up doing it in a rush outside work hours.
Managing your own psychology as an engineering manager goes hand-in-hand with everything we’ve discussed so far.
There are always more hours you could sacrifice. And there’s always more to be done for an engineering manager.
The trick is you've got to set the parameters for yourself for when you're going to work and when you’re not.
Don’t be too hard on yourself. We're all human with only so much capacity, so we can’t get everything done. Be honest with yourself about your limits as a person, a manager, and a contributor in your team.
Manage your own psychology, your thoughts, and anxiety by being honest with yourself. You’re good enough, and you can do this. Budget your time so you can find the time to do everything important in the week.
This is what your team needs, not you running around with your hair on fire working 24/7.
Matt Martin is the co-founder and CEO of Clockwise, offering a product that helps people make time for their essential work by automatically rearranging their schedule. He was in and out of software development throughout the earlier years of his career, and even went into law for a while.
Over the last decade, he’s been at different companies in the Bay Area, honing his software engineering skills as a front-end engineer and transitioning into engineering management. He started Clockwise in 2016, and his team’s been growing ever since, publicly launching the company in 2019. He’s currently running a team of 20 people.
👉 If you are serious about becoming a great engineering leader, you should take a deep dive into the State of Engineering Management 2022 report.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.