Yousuf Sohail

My first 30 days as an engineering manager

March 10, 2026

I became an Engineering Manager on February 1, 2026. Thirty days later, here’s what actually changed — and what I didn’t expect.

What I Expected to Change

More meetings. True. Where I had two-hour focus blocks every morning, I now have 1:1s, sprint planning, stakeholder syncs, and cross-squad conversations. I protect afternoons for deeper work.

Less coding. True, mostly. I still review PRs and do architecture deep dives when I need to understand a problem before delegating it. But the line-by-line, feature-shipping coding is done. I miss it sometimes. Not enough to think I’ve made the wrong choice.

More ambiguity. True, and harder to prepare for. As an IC, “done” was legible — the test passed, the feature shipped, the PR merged. As an EM, “done” is harder to see. Is the team healthy? Is the architecture pointed in the right direction? Are the right people growing? These are slow variables with long feedback loops.

What I Didn’t Expect

The context-switching tax is different.

As an engineer, context-switching meant switching between tasks — feature to PR review to bug fix. Expensive but recoverable.

As an EM, it means switching between people and between problems that live entirely in different heads. One minute I’m helping an engineer think through a data model. Next I’m in a conversation with a product manager about scope. Next I’m in a 1:1 about someone’s growth trajectory.

Each requires a different mode of thinking. The cost isn’t in the transition — it’s in arriving at each conversation fully present. Some days I’m good at this. Some days I’m not.

The leverage is real but invisible.

The most important thing I’ve done in my first 30 days probably doesn’t appear in any metric yet.

I had a conversation with one of my engineers about what they wanted their career to look like in three years. They hadn’t been asked that question directly before. By the end, they had a direction. Their work since then has had a different quality — more intentional, more engaged.

Did that conversation show up in sprint velocity? No. Will it compound into better work over the next year? Probably.

That’s the EM leverage model. Invisible inputs, slow outputs. You have to trust the model before you can measure the results.

People problems are architecture problems.

I knew engineering teams had “people problems.” I thought they were separate from “technical problems.” They’re not.

In my first 30 days:

The codebase is a reflection of the communication patterns of the team that built it — Conway’s Law, which every engineer has heard and most have underestimated. My job now is to shape both.

What I’m Still Figuring Out

When to direct vs. when to coach.

I have opinions. Thirteen years of engineering experience give you opinions. The reflex when someone presents an approach I disagree with is to say: “I’d do it this way.”

That’s not always right. Sometimes the engineer’s approach is fine — different from mine but fine — and what they need is confidence to ship, not a redirect. Sometimes the approach has a real problem that needs to surface through questions, not instructions.

I’m still calibrating this. I’ll be calibrating it for years.

How to measure team health before it surfaces in metrics.

Sprint velocity is a lagging indicator. By the time velocity drops, something has been wrong for weeks. I’m looking for leading indicators — the texture of standups, whether engineers ask for help or stay stuck, whether PRs move smoothly or accumulate review comments.

I don’t have a good system for this yet. It’s on the list.

The Honest Take After 30 Days

The best thing: the potential impact. Helping five engineers do better work over the next year is higher leverage than the code I would have written as an IC.

The hardest thing: the patience required. As an IC, you build something in a sprint and can point to it. As an EM, you build something in a quarter that you can only point to obliquely.

I chose this. I’d choose it again.

Ask me in a year.