From Senior Engineer to Manager: The First Ninety Days

Nobody warns you that the promotion is a career change. One day your output is code, the next it is decisions, context and other people's momentum — none of which show up in a commit history. The first ninety days are mostly grief about that.

Weeks one to three: resist fixing things

You will see problems immediately, because you were in the trenches last month. Almost all of them can wait. Spend the time understanding why things are the way they are — most odd decisions had a good reason at the time, and the team will tell you if you ask instead of announcing.

Weeks four to eight: stop writing critical-path code

This is the hardest one. Keeping a ticket on the sprint feels like staying credible; in practice you become the blocker whenever a hiring panel or an incident eats your week. Pick up the unglamorous work instead — the flaky test, the deployment script, the documentation nobody owns.

Your throughput is no longer measured in what you ship. It is measured in what the team ships without waiting on you.

Weeks nine to twelve: build the feedback habit

• One-to-ones are for them, not for status — status has a board
• Say the uncomfortable thing early and small, while it is still a nudge
• Ask what you are getting wrong, then actually change one of them visibly

If at ninety days you miss the code enough to be unhappy, that is useful data rather than failure. Staff and principal tracks exist precisely because the industry finally admitted management is a different job, not a higher one.