The New Engineering Lead’s Guide to Time Management
A practical guide to protecting your calendar, delegating earlier, making better decisions, and creating space for your team to do good work.
For most of my career, I was an individual contributor. Usefulness was visible: write the code, review the change, fix the problem, publish the document. The output was easier to see.
Moving into management changed that relationship before I had a good way to think about the calendar. A 1:1, a proposal review, a stakeholder question, and an escalation can all be legitimate work. Put enough of them together, though, and the week disappears before the decisions and conversations that require a lead have room.
The transition problem starts when leadership work arrives before old IC work leaves. Implementation, routine review, technical coordination, and familiar context remain attached through habit; people, delivery, feedback, stakeholders, and risk arrive on top. This is not a time-management problem in the narrow sense. It is a responsibility problem expressed through the calendar.
This guide is for new engineering managers and technical leads whose outcomes increasingly depend on other people while they still carry part of their old role. Their authority differs, but the practical question is the same: which work genuinely requires your attention, and which work is still yours because it used to be?
My operating rule is simple: when leadership work enters your week, work from your old job needs to leave. A transition may require temporary overlap, but temporary overlap needs an end date. Otherwise it quietly becomes two permanent jobs.
Audit the week you actually have
For an initial audit, do not start by designing an ideal calendar. Start with the previous ten working days.
Open your calendar, Slack, notes, and whatever you use to track work. Account for visible commitments and the work around them: preparing feedback, reviewing proposals, answering questions, writing follow-ups, recovering context between meetings, handling an incident, or finishing something after hours because it never found space during the day.
You do not need a new time-tracking system. The goal is not minute-by-minute surveillance. You are looking for enough evidence to answer five questions:
What took meaningful time?
What outcome did it create?
Why did it require me?
Who waited for me?
Should I own it, stay close to it, transfer it, or stop it?
A simple audit might look like this:
The “Why me?” column is uncomfortable because familiarity can masquerade as responsibility. You may be the fastest reviewer because you know the codebase. You may be the best person to rewrite a plan because you have stronger opinions about its structure. Neither fact automatically means the work should remain yours.
Look for three forms of calendar pressure:
Hidden leadership work: feedback, tradeoff decisions, stakeholder preparation, and thinking that gets pushed outside working hours.
Habitual IC work: implementation, routine review, or technical coordination you still own because you used to own it.
Recurring demand: meetings, approvals, and repeated questions that keep returning because the underlying ownership or context is unclear.
At the end of the audit, name the three biggest sources of pressure. Do not fix all of them yet. The audit separates what feels busy from what is making the team dependent on you.
Stop carrying your old job
Push each recurring responsibility to the lowest level of involvement that is still safe. Then sort it into four groups.
Own. Work that requires your authority, accountability, or sensitive judgment: a performance conversation, a priority conflict, a cross-team commitment, a high-risk escalation, or a decision where the team needs one accountable owner.
Stay close. Work where you need enough context to exercise judgment without controlling every step: an important launch, a migration with operational risk, architecture with long-term consequences, or a customer problem that could change team priorities.
Transfer. Give another person a complete outcome when the work can develop their judgment and reduce unnecessary dependence on you: routine reviews, project coordination, implementation planning, recurring documentation, or a technical proposal.
Stop. Meetings without an output, duplicate reports, inherited approvals nobody can justify, and processes that cost more attention than the risk they manage.
These categories do not make technical work inappropriate. A technical lead might keep implementation when it reduces important risk, establishes a reusable pattern, or supplies context that would be expensive to gain another way. An engineering manager might stay close by inspecting risk and decision quality without becoming the routine reviewer or implementer. The test is whether lead-level attention changes the outcome, not whether the work is technical.
Treat Own as the uncomfortable “only I” list, then challenge every item in it. Does it truly require your authority? Is the information sensitive? Is the decision hard to reverse? Is the risk high enough that you need to own the call? If the answer is no, the work may need your context or a checkpoint, but it probably does not need your hands.
Do not remove yourself so aggressively that high-risk work loses necessary context. Transferring a security-sensitive change and then disappearing creates an accountability gap. Match your involvement to the person, the risk, and the reversibility of the decision.
For the next week, choose one item to stop, one to transfer, and one to stay close to through a lighter mechanism. If Own still contains half the role, go through it again. You may be protecting a preferred method rather than a necessary responsibility.
Budget your week before it fills
Once you know what should remain yours, build the week around responsibilities rather than incoming requests.
Start with the commitments that are genuinely fixed: 1:1s, team planning, interviews, an operating review, or a launch decision with an external deadline. Add preparation time for the commitments that need it. A one-hour feedback conversation is not a one-hour piece of work if you need thirty minutes beforehand to review examples and decide what you actually want to say.
Then add the work that is important but easy to displace:
decisions and tradeoff preparation;
consequential technical context;
difficult conversations;
written context that will prevent repeated explanation;
delegation checkpoints;
support or escalation requests to your manager.
Some of this work deserves a name: judgment time. It is where you compare weak signals, prepare consequential feedback, inspect technical risk, and decide which tradeoff you are willing to defend. Without a named block, visible tasks and incoming requests can repeatedly displace it.
Create an operating reserve. As a starting experiment, reserve 10–20% of your sustainable week if you can, then adjust it through the weekly audit. A team with frequent on-call interruptions may need more. A lead with little control over the calendar may begin with one open half-day. The point is to treat incidents, escalations, and work that runs long as normal operating conditions rather than planning failures.
The arithmetic has to work. If your plan contains forty-six hours of commitments, a better color scheme will not turn it into a forty-hour week.
Consider a hypothetical new engineering manager with seven reports, a migration in progress, and normal on-call exposure:
The numbers are illustrative. A tech lead may need more technical time; a manager with a larger team may need more people-management time. The important change is what left, not the allocation itself.
Before moving on, make the budget balance:
Subtract fixed commitments, preparation, and the operating reserve from your sustainable weekly capacity.
Allocate what remains across people, decisions, technical context, stakeholders, and administration.
Remove, reduce, or transfer work until the total fits without relying on evenings.
Block your time
Calendar blocks help only when they protect a named outcome. “Focus time” is too vague. It is easy to overwrite because nobody, including you, knows what would be lost.
Use specific names:
Review the migration risk and decide whether to phase the launch.
Prepare feedback for Thursday’s 1:1.
Read the API proposal and write the decision boundary.
A useful block also needs an interruption rule and a response window. For example:
I am using 9–11 to prepare feedback and make the release decision. Interrupt for a production incident, an urgent people issue, or a decision holding up several people. Otherwise, add it to the queue and I will respond by 2.
This keeps protected time from becoming unavailability. The team knows what may interrupt it and when other requests will receive attention.
Block three things in the next week: one decision, one consequential conversation, and one technical risk. That is enough to test the shape without turning the calendar into a fortress.
Do not protect personal output while the team waits for a decision only you can make. If five engineers are blocked on a release call, move the writing block, make the call, and restore the time somewhere visible. Protect important work from accidental displacement, not every calendar event.
If the same “temporary” meeting overwrites a block every week, the block is not protected and the meeting is not temporary. Resolve the conflict instead of maintaining the fiction.
