Your 100-Day Plan Dies on Day 12
Write the 100-day plan anyway. The three classic new-EM faceplants, why month one is for mapping the local balagan instead of fixing it, and the quiet Flink timezone bug that erased events during a pre-Black-Friday code freeze.
The written plan did not survive that week. The impression did.
Write the 100-day plan. Expect it dead by day 12. Both halves matter. A direction you adjust beats no direction.
Walking into a new company as an experienced engineering manager is humbling: you know exactly how much you don't know yet.
Don't pretend otherwise. Everyone already knows you're the new one. The only open question is whether you do.
Day one is a reset button
It doesn't matter how much you shipped at the last place. Day one wipes the ledger.
Most of day one is logistics and not screwing up. Sort your access early: email, repos, the wiki nobody has touched since 2019. Take notes. Eat lunch where people actually eat lunch. Then mostly shut up and watch.
The watching is the job. Fight the urge to fix things. You don't yet know why that "obviously broken" process exists. Maybe it's stupid. Maybe it's scar tissue from an outage that nearly killed the company.
Ask "tell me how the team landed on this" instead of "did you consider X". One invites a story. The other announces that you've already reached a verdict.
The three faceplants
Experienced EMs embarrass themselves in three classic ways. I've done at least two.
"Back at my old company..." Every time it leaves your mouth, it translates to "this place is worse and I'd rather be there". Keep the comparisons in a private doc.
The overpromise. New-job adrenaline makes you want to announce a full process overhaul by Thursday. Resist. Declare in week one that you're fixing deploys, the on-call rota, and estimation. By month two you're the office cautionary tale.
Find one small thing that's broken and nobody bothers to escalate. Fix it. Let the win do the talking.
Judging by the desk. The loud one with the strong opinions is not automatically your strongest engineer. The one who hasn't said a word in three meetings is sometimes the reason production is still standing.
First impressions in this job age badly, and your gut is calibrated on your old team, not this one. Give it a few weeks before you decide who's who.
Start with 1:1s, and actually listen
Skip the status-update kind. Ask what's slowing them down, then close your mouth.
One real question beats ten from a skip-level template. Mine: "On a scale from fine to dumpster fire, how's the workload. Straight answer."
You'll learn more from three of those than from a month of dashboards. The craft of a good 1:1 is mostly shutting up. In month one it is entirely shutting up.
Map the balagan, don't fix it
Every company has its own house style of balagan. Balagan is Hebrew for chaos: the local mess everyone has stopped seeing. The chaos has a shape, and the shape tells you which company you're actually standing in.
Your job in month one is to map it, not fix it. Deadlines always slipping? Could be process. Could be one overloaded person. Could be requirements written in crayon. Same symptom, three different fixes, and you don't know yet which one is yours.
The expensive signal is silence. Quiet resentment instead of an argument.
An argument means people still believe saying it changes something. Resentment means they've decided it's no longer worth saying. Don't reach for blame. Reach for "tell me more about that", and pay attention to what nobody says out loud.
The plan dies on day 12
Have the plan: direction, priorities, the two or three things you believe need to change. Then hold it loosely. By day 12 parts of it are already wrong.
What survives contact is the early wins. Find the obvious ones and clear them. The ancient approval step everyone hates. The code reviews that sit for six hours.
People flag these things in the 1:1s and then shrug, because they stopped believing anyone would remove them. Clearing one lands harder than any new initiative. A new process from the new manager asks for trust you haven't earned yet. Removing an old one gives the team hours back this week.
Nothing builds credibility faster than deleting a process everyone assumed was load-bearing and watching the building stay up.
The fire that replaced the plan
Whatever your plan says about weeks three through eight, production has its own roadmap.
One I still think about. The pipeline was the standard shape for event analytics: page tags feeding collectors, collectors feeding Kafka, a Flink job enriching events in the middle, ClickHouse at the end doing the counting.
An "innocent" enrichment tweak landed in the Flink job. Inside it, a quiet timezone conversion. Certain events simply stopped existing.
No crash. No alert. No error spike.
A timestamp is not decoration in an event pipeline: shift it and events start landing where nothing is looking for them.
Nobody noticed until the numbers downstream in ClickHouse went sideways. During the pre-Black-Friday code freeze. Half the team on vacation.
Then came the second surprise: someone had "helpfully" changed replicated_deduplication_window, the setting that governs ClickHouse's silent insert deduplication. When events are vanishing and the dedup knob has fresh fingerprints on it, your debugging tree just doubled.
Unpicking that while talking executives off the ledge was not in my 100-day plan.
That fire was the actual first 100 days. The team learned more about me in one bad week than in a month of 1:1s. They watched whether I hunted the mechanism or the person who merged it. They watched whether the executive panic stopped at me or rolled downhill.
The written plan did not survive that week. The impression did.
Protect yourself. It's not a poster
A fried manager makes worse calls, and your team inherits every single one of them.
The second reason is bigger. The boundaries you actually keep are the boundaries your team is allowed to keep.
Nobody guards a line their manager visibly doesn't. Every late-night reply, every skipped vacation, tells them whether this place is a sprint or somewhere a person can stay. Declining on purpose is a skill, and month one is when you show whether you have it.
The crash test dummy
You were hired for your experience. Experience means sharper questions, and the nerve to say out loud what you haven't figured out yet.
Do that. Kill two stupid processes. Survive the first fire. People start trusting you, and that trust is the only thing that holds when something actually breaks.
The plan gives you direction. The job is to map before you fix, protect the team when production chooses the roadmap, and keep the boundaries you want them to keep.
Most days you are not the hero. You're the crash test dummy.
Show up anyway.