Time Management for the Newly Promoted

The day you become a team lead, your calendar stops being yours. The work doesn't get harder. It gets louder. And loud is not the same as important, which turns out to be the entire problem.

A confession, to set the tone. I wrote my last real production code around 2015. What I shipped back then was held together with commented-out lines and // PLEASE WORK. So I am not here to lecture you about discipline. I'm here because I was bad at this and found exactly one thing that helped.

Eisenhower, 1954: "I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent."

Urgent screams. Important waits politely, then turns urgent the moment you've ignored it long enough. Two axes, four boxes:

                URGENT                 NOT URGENT
            +--------------------+--------------------+
 IMPORTANT  | do it now          | the box that       |
            | (the actual fire)  | actually pays you  |
            |                    | back: refactors,   |
            |                    | mentoring, the     |
            |                    | rewrite            |
            +--------------------+--------------------+
 NOT        | delegate or say no | don't. just don't. |
 IMPORTANT  | (someone's loud    | (the meeting that  |
            |  ticket)           |  was a Slack msg)  |
            +--------------------+--------------------+

It worked on me for a specific reason. I have an ADHD brain. My son and I share the wiring, and explaining recursion to him is still the hardest thing I do all week. Left alone, that brain chases whatever is shiny and loud. The matrix is dumb enough to survive my attention span. When I first saw it I assumed it was the kind of thing HR makes you do at a retreat. I was desperate, so I tried it anyway.

We were rewriting our alerting platform at the time: monolith to stateless streaming, single region to multi-cloud. Mid-rewrite, the feature requests poured in - sliding windows, relative thresholds, ML-based thresholds, the full menu. Plus support tickets at every level of fake urgency. I started to drown.

So we put everything into the four boxes, as a team, out loud. Critical bugs and the core rewrite: now. Refactoring, letting the data scientists test new models: scheduled, protected, not skipped. Half the "urgent" tickets: delegated. The endless debate about the font size on graph metadata: we nearly lost a good engineer to that meeting, so we killed it.

We shipped on schedule. Bug resolution time dropped about 36%. Three feature launches landed on time. I would love to credit my brilliance. It was mostly a 2x2 grid and the nerve to say "that's a box-four conversation, take it offline."

The real unlock is doing it as a team, not in your head. When everyone can see the grid, "we don't have time for this" stops being your opinion and becomes a shared decision. The loudest project manager in the room is much easier to push back on when the priorities are on the wall instead of in your gut.

You will not out-discipline a noisy calendar. You'll lose. What you can do is decide, on purpose and ideally in public, what is actually important, and then defend that box like it's production. Do I still chase the shiny thing? Constantly. The grid just helps me find my way back before it costs anyone a sprint.