The first time I stepped from senior engineer into running a technology org, the title I got was director. They didn’t want to hand out VP, and nobody was getting CTO. The developers ran the place by whoever had the loudest opinion that month. That was the job: walk into a moving car and find the steering wheel.

Most of my experience is at smaller companies with deep technical and product problems. In two of the five, the founders were pharmacists who happened to start a technology company. It goes about how you’d expect. People who love going to restaurants open a restaurant, find out they’re bad at running one, and they’re two years deep before anyone says it out loud. Same story in pharmacy.

So this is biased toward the messy end of the spectrum. If you just took a leadership role at a calm, well-run company, congratulations, and most of this still applies, you’ll just have more time to do it.

Here’s how I run the first 90 days.

Put the hammers away

The hardest part of the first 30 days is doing almost nothing.

You’re an engineer. You want to fix things. As an executive you should rarely be fixing anything, and you should probably never commit code. If you are committing code, you’re covering a staffing gap, and leadership needs to hear about it.

Your actual job in month one is to observe and take notes. Sit in the meetings, follow whatever process they have, and resist offering solutions until someone asks. The fastest way to lose the room is to have someone say “you don’t even understand how we do things here,” and they’ll be right, because you don’t yet. Some fix that looks obvious on day three turns out to be impossible once you’re in the weeds on day twenty.

You’ll also meet the people who are very bought into their own process. “It only broke this sprint”. “We’d fix it if we had time”. Then you talk to everyone else and learn it breaks every sprint and always has. Your edge as the new person is the outside perspective, and it has a shelf life. Use it before you become a native.

The one rock you do flip over

There are exceptions, and you’ll know them when you see them.

One morning I was reading a pull request and watched someone write SQL injection straight into it. I put my foot down on the spot. I don’t care if it costs us a million dollars, you cannot knowingly ship the single most exploited attack vector on the internet. Anything that’s a live security hole or a regulatory fire gets handled now, not in your 30-day readout.

And then it quietly becomes one of your bullet points anyway, because “the team shipped SQL injection and didn’t flinch” tells you something real about where you actually are.

Symptom, cause, then the 80/20

At the 30-day mark you owe the CEO a readout. Mine is always the same shape: my top five problems, the symptom everyone already feels, the cause underneath it, and the smallest fix that buys the most.

Never walk in with “number one is a seven-month rebuild.” That’s how you get tuned out. Walk in with the one-week thing and the one-month thing that make everyone’s life better, and save the ugly structural work for after you’ve earned some trust.

The quick win I reach for over and over is observability. My most recent company had no application performance monitoring at all. When something broke, people opened the log files and started reading. They were never the first to know, and everything took forever to fix. I asked the obvious question, wouldn’t it be great to know exactly what’s failing and why, and then I told them it’s a one-day proof of concept. We had OpenTelemetry running by the end of the week.

Nobody ever celebrates a week of work that delivers that much. That’s the point. Quick wins are how you buy the political capital you’ll spend later on the boring, important work. Because eventually the easy wins run out and all that’s left is the unsexy stuff: a real software development lifecycle, dependency monitoring, the things no customer ever praises. A security team will ask you for your SDLC and file it away. Not one of them will tell you that you knocked it out of the park. You have to be the champion of that work yourself.

There’s a line I think about a lot, and I forget who coined it: every three years everything in technology gets twice as easy. A riff on Moore’s law, but true. APM was basically unapproachable ten years ago. OpenTelemetry didn’t exist, you were looking at Datadog or New Relic and a real budget. Today you’re insane not to have it. A lot of your “secret” advantages are just knowing what got cheap while nobody was looking.

Learn how your CEO reads

Half of this job is translation, so learn the format before you write the report.

I’ve had visual CEOs who want an application map: here’s how the pieces fit, here’s the choke points, here’s where it’s on fire. I’ve had CEOs who want exactly six bullet points, and if you write a seventh, the email doesn’t get read at all. It sounds pedantic. It isn’t. These are busy people who do not want a pile of problems dumped on them, and figuring out their format early is most of getting heard.

One more thing executives do not care about: problems you can’t name yet. Telling a CEO “there’s tech debt somewhere we haven’t found” just hands them a worry to carry. There are always enough known problems that nobody has the patience for hypothetical ones. Keep digging until the worry becomes a specific, actionable thing.

Day 60: ship the cheap wins

Month two is for actually implementing. By now you’ve handed the CEO your solutions and your quick wins, and the 80/20 rule takes over. If a fix is 20% of the effort and solves 80% of the pain, that’s what’s getting done. Trying to force the more rigorous solution first is fighting gravity.

Keep your changes to technical fixes and light process. No incident response plan? Write one. No alarms or monitoring? Add them. What you don’t do in month two is march in and announce you’re converting the whole company from waterfall to agile. If you’re going to touch process, tie it directly to the pain it’s causing, never to your preferences.

This is also where you start banking capital for later. Warn the CEO in advance: we’re doing it your way, and because we’re using waterfall with no observability, this is going to take two months instead of one, and here’s exactly why. Say it factually, not whiny. Then follow their process in public. When the thing takes the two months you predicted, you point at the record. That’s how you earn the right to push for the bigger call later.

You don’t need a particular methodology. You need a cadence. Kanban, scrum, sticky notes on a whiteboard, I don’t care, as long as things ship on a tight and predictable schedule, weekly or biweekly at the latest. Pick one and keep it.

And the release calendar is rarely fully yours. In pharmacy you cannot deploy in December, because everyone’s insurance flips over on January 1st and January 10th. Ship a breaking change that first week of January and you’ve created chaos inside claims and dispensing. That’s why healthcare code freezes start in December. You want a full month of nothing changing and nothing breaking.

Day 90: everyone has a plan until they get punched

By month three you should have a few wins implemented and a real grip on the problem list. You’ll also have a pile of net-new problems, because half your tidy 30/60/90 plan didn’t survive contact.

Mike Tyson had it right. Everybody’s got a plan until they get punched in the mouth. I’ve drafted 30/60/90 plans and mostly held them. I’ve also drafted them and never mentioned them again, because the company had so many outages that the only real plan was to put out fires and slowly get ahead of them. If your company can’t honestly promise what it’s doing a month from now, your 30/60/90 plan is decoration. A company that can hand you a three-month roadmap and actually hit even 80% of it is a stable company, and getting one there usually takes about two years and a lot of buy-in.

Here’s the part nobody tells you on the way in. Most of what looks like a technology problem is a product problem, a prioritization problem, and a leadership problem wearing a technology costume. Technology sits at the bottom of the company. Every bad decision made upstream rolls downhill and lands on your team, and there’s no escaping it, it’s gravity. A previous leadership team of mine clearly got schmoozed into a bad data-redaction vendor, signed it in November with a year-end deadline, and the bill landed on engineering. I didn’t get any of the kickback, and the product was bad too. Thanks for that. (I’ve written more about ideas rolling downhill here.)

So when something that should take two weeks takes three months, the cause is almost always process or prioritization, and that’s the fight you actually have to win. You play ball with their process publicly and you tell the CEO the truth privately. When you’re proven right, and you will be, sometimes it forces a hard call, and sometimes that call ends someone’s tenure. That’s the genuinely uncomfortable part of the job.

But the technology team gets crushed by everything else in the company by default, because everything rolls downhill. Somebody misses a deadline, somebody books a sale, somebody signs a vendor, and it all lands on you, and you’re the one who looks bad even when everyone else behaved badly. If you don’t fight for your team, it gets flattened.

That’s the whole job in the first 90 days. Watch more than you fix, ship the cheap wins, learn how your CEO reads, and start building the case for the things that actually matter before anyone’s ready to hear it.