本文深入探讨了从工程师转型为管理者后，时间管理面临的挑战与应对策略。文章指出，管理者的时间管理与工程师有显著差异，需要学会优先处理多重任务、关注团队产出而非个人效率。文章提出了管理者应调整预期、高效优先排序、授权团队成员等关键策略，并提供了应对工作过载的实用方法。此外，文章还强调了创造专注时间的重要性，帮助管理者在碎片化的工作中保持高效。

⏰ 转变时间管理模式：作为团队负责人，需要适应由外部日程驱动的工作模式，而非专注于单一任务。

🎯 调整工作重心：管理者的首要责任是团队产出，个人工程工作应退居其次，并合理分配时间。

✅ 准确评估个人能力：管理者应认识到个人产出的减少是正常现象，并学会通过时间追踪来提高效率。

💡 优先级排序：学会区分任务的紧急程度和重要性，优先处理截止日期前的重要任务，并关注能提升团队未来效率的工作。

🤝 授权与团队成长：通过合理的授权，帮助团队成员成长，同时减轻自身工作压力，并为团队预留发展空间。

📋 应对工作过载：制定应对清单，包括与上级沟通、梳理任务、授权和确定放弃事项，从而有效管理工作量。

🗓️ 创造专注时间：通过集中处理干扰性工作，例如批量处理会议，为深度工作留出时间。

Published on April 2, 2025 4:00 AM GMT

This post was adapted from an internal doc I wrote at Wave.

Welcome to being a manager! Your time-management problem just got a lot harder.

As an IC, you can often get away with a very simple time-management strategy:

Decide what your one most important thing is.Work on it until it’s done.GOTO 1

As a team lead, this isn’t going to work, because much more of your work is interrupt-driven or gets blocked for long periods of time. One-on-ones! Code reviews! Design reviews! Prioritization meetings! Project check-ins! All of these are subject to an external schedule rather than being the type of thing that you can push on in a single focused block until it’s done.

Being a team lead means three big changes for your time management:

You no longer have a single most important thing. You’ll have to learn how to juggle competing priorities.

Your most important responsibility is for your team’s output, not your personal output. That means that individual engineering work goes last in your list of potential most important things.

You’ll need to start spending some of your time on a manager’s schedule:

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

Here’s some advice on how to cope with those changes.

Have accurate expectations of yourself

Your responsibilities to your team will take time, and even more importantly, attention. That means you’ll be a lot less productive on IC work than you have been in the past—especially at first while you’re finding your legs. Additionally, your time will be less predictable week-to-week as you might have to spend an unknown amount of time responding to “inbound” work.

For the first few months, you should treat any individual engineering work that you get done as a bonus. Even after that, you should expect to have something like 10-20% less individual output per engineer you manage, depending on how experienced you are, they are, etc., and with substantial week-to-week variance.

To mitigate this, my rule for myself has been to make sure that my IC work is important but not urgent—i.e. that nobody will be sad and no plans will be derailed if I end up having to spend the next week firefighting instead of pushing it forward.

For honing my intuitions about how much I can actually expect to accomplish, I’ve found time tracking very useful (see How time tracking helped me be a better manager and I apparently got 50% better at my job last month).

Prioritize ruthlessly

A corollary of the above is that it becomes very important for you to prioritize what to work on, both on an hour-to-hour cadence and on a larger timescale.

It’s not possible to write down a full algorithm for prioritizing in a blog post—that’s why they pay us the big bucks—but here are some heuristics for which things are most worth prioritizing:

Deadlines where something bad happens if you miss them. (e.g. performance improvements in advance of a holiday rush.) Note that the badness of missing deadlines varies wildly. Make a habit of asking “what is the reason for this deadline?” for any deadline-driven project.Work that increases your or your team’s future bandwidth. This can include hiring, addressing tech / process debt, automating toil, mentoring people, reducing pager burden, etc. A useful way of thinking about it is to rank this kind of work based on the “payback period,” or how long it takes before the time saved by the improvement exceeds the time invested in making it.One-on-ones. Try very hard not to cancel these, unless you’re on vacation—the other 39.5 hours a week they’re focused on what you need from them, so please don’t disdain the 0.5 hours you spend focused on what they need from you. If you cancel too many, expect your reports to feel less safe bringing up tricky things, and to have more issues “blow up” because they didn’t get addressed early.

Unemploy your future self

One of the most important types of “work that increases your or your team’s future bandwidth” is delegating things. This is something entire books have been written about, but here’s how to avoid a few common delegation pitfalls for new team leads:

Negotiate how hands-on to be. Effective delegation means finding the right balance between micromanaging, and throwing your report to the wolves. The stereotype is that new managers often micromanage, but at Wave, I’ve noticed that new managers often err on the side of undermanaging, or being too hands-off, perhaps out of a desire to signal that they trust their reports.

If you’re unsure, it’s good to have an explicit conversation with the person you’re delegating to about how much support they want. E.g. “do you want to do the design for this feature yourself, have me do the high-level and fill in the details, or have me write the entire design doc?”

Calibrate to your team members’ task-relevant maturity, or how capable they are of independently doing a particular type of task. A senior engineer should be able to design most features independently (with review), but give the same design task to a junior engineer and they’ll probably flail around and make no progress. You should be maintaining a mental map of each of your team members’ strengths and weaknesses—and updating it over time as you help them improve.

Delegate ahead of future growth. Your team’s workload is going to increase over time, so even if you don’t feel like you have too much work to do right now, you probably will in the future, unless you currently feel underutilized. You should aim for a workload where in the steady state, you feel like you have some slack capacity.

Delegate “stretch projects” to help your team level up. Getting enough slack might require you to delegate work that no one else on your team can currently do. Take your mental strengths-and-weaknesses map, ask yourself what the most important growth directions for each of those team members are, and figure out how to give them work that stretches them in that direction. Note that these delegations will probably require more frequent monitoring, since your reports will have less task-relevant maturity on their stretch projects!

A five-step “help, I’m overwhelmed” checklist

Despite your best efforts to follow the above advice, there will probably come a time when you feel very stressed about the amount of work on your plate. When that time comes, here’s what to do:

Schedule time with your manager, for the soonest slot you can, to triage your todo list. (If the primary stakeholder for your scariest todos is your PM, schedule with them instead.)Make a list of everything that’s on your plate currently. Yes, everything, even that code review that’s been sitting in your backlog for the last 3 months.At the meeting you scheduled in step 1, figure out how to delegate everything in that list you can delegate, then stack-rank the remainder.Realistically (see Have accurate expectations of yourself) decide how far down the list you’re going to get. Remember to leave yourself some slack for whatever comes up!For things below the cutoff, decide that you’re not going to do them, and notify everyone who cares that you probably won’t get to it.

Carve out focused time

If you’re not careful, it’s easy to fill your entire calendar with meetings, Slack, etc. and have no time for deep work. With careful planning, you can avoid this by “batching” all your distractions to particular times of day.

There are lots of tactical tips for doing this; I catalogued some that work for me in Tools for keeping focused.

One tech-lead-specific one that I’ll add is batching meetings: I schedule all my meetings back-to-back on Tuesdays and Thursdays to leave the rest of the week as free as possible for deep work.

Appendix: further reading

Rest in MotionHow time tracking helped me be a better managerTime management: the leadership meta-problem.Tools for keeping focusedAttention is your scarcest resourceI apparently got 50% better at my job last monthThe Top Idea in Your MindMaker’s Schedule, Manager’s ScheduleMy weekly review habit

Discuss