Tom Barber (00:00)
Here's the truth nobody tells you about modernization. The first 90 days will make or break your entire initiative. Not the technology choices, not the architecture diagrams, the politics, the quick wins you choose and the enemies you accidentally make in week three. I'm Tom Barber and on today's Engineering Evolved, we're walking through exactly what to do in those critical first 90 days. And more importantly, what not to do. Because I've seen too many directors crash and burn by day 60.
And it's almost never for the reasons they think.
Welcome to Engineering Evolved, the podcast for engineering directors at mid-sized companies who refuse to accept this is how we've always done it. I'm your host, Tom Barber, and this is episode number nine. If you're leading a team at a company with 200 to a thousand employees, you know you're stuck in the awkward middle ground. You can't move as fast as startups and you don't have enterprise budgets. But here's what you do have.
the ability to make real change without drowning in bureaucracy. This show is about modernization, product thinking applied to engineering, and building cross-functional teams that actually function. No fluff, no theoretical frameworks that fall apart the moment they meet reality, just practical approaches that work when you're stuck between the move, fast, and break things, and submit your change request in triplicate. This is Engineering Evolved. Let's get into it.
Ahem.
So, day one of your modernization initiative. You walk into your in-wheel roadmap, your vision, document, maybe even executive buy-in. You're ready to transform this place. By day 30, you're wondering why half your organization seems actively opposed to you. By day 60, you're in damage control. And by day 90, well, we've all seen what happens by day 90.
I've seen both sides of this. I've been the director who thought they had it all figured out and watched other leaders make choices in those first weeks that haunted them for years. And here's what I've learned. Those first 90 days aren't about the technology at all. They're about trust, momentum, and not accidentally declaring war on people who could be your allies. Let me tell you what prompted this episode. Recently, through my consultancy, Concept to Cloud, we worked with a director of engineering.
at a 600 person company. And this person had been brought in specifically to modernize their platform. They had all the credentials, all the experience and the board that was behind it. And she lasted 73 days. Not because the technical vision was wrong, not because they couldn't lead, but because they spent the first month mapping out a perfect two-year transformation roadmap while production was literally catching fire.
They didn't realize that the VP of sales had spent three years promising customers features that required the exact systems they wanted to sunset. They didn't know that the resistant senior engineer that they kept butting heads with was actually the person who'd been begging for modernization for years. He was just skeptical because he'd seen previous two directors fail. So today we're going to walk through those first 90 days the right way.
not theoretically, not ideally, but the way that you have to do it when you're surrounded by legacy code, competing priorities, and people who've been burnt alive. And here's my promise, by the end of the episode, you'll have a week by week action plan that you can actually execute. No management consulting nonsense, just practical steps that work.
So before we get into the timeline, we need to talk about the biggest mistake that directors make in their first 90 days. And it's often not what you think. The mistake is assuming that you are hired to modernize the technology. You weren't. You were hired because someone, probably the CTO or the CEO, is feeling pain. Maybe it's customer complaints. Maybe it's competitors moving faster. Maybe it's an upcoming compliance deadline that's terrifying everyone.
Whatever it is, there's a burning platform somewhere. And until you find it and address it, nobody cares about your vision for microservices or your containerization strategy. Here's the harsh truth. Your job in the first 90 days isn't to fix everything. It's to prove you understand the business, can be trusted, and won't make things worse. That's it.
Master those three things and you'll learn the political capital you need for real transformation. Fail at any of them and it doesn't matter how good your technical roadmap is. So let me ask you, do you actually know what pain caused your organization to bring you in? I mean, specifically not technical debt or legacy systems, but what...
the business outcome is being blocked right now. If you can't answer that one sentence, stop. Do not pass go. Do not start architecting solutions. Go and find out.
And this is where my Concept to Cloud framework comes in. Before you can plan 90 days, you need clarity. And I mean like real clarity, not the clarity you get from reading your documentation and sitting in meetings where everybody nods politely. At Concept to Cloud, for example, we run a 10-day discovery sprint specifically designed to de-risk modernization initiatives. So here's what we do. Days one to three.
Problem framing and user stories. We're not looking at systems yet, we're looking at people. Who's hurting, what's actually broken from their perspective, and critically, what's the difference between must haves and nice to haves? I've worked with companies where the critical modernization turned out to be someone's pet project, while the real business need was being ignored because nobody wanted to admit it existed. Days four to seven, target architecture and risk mapping. Only now,
do we look at technical solutions, target stack, data models, integration points. But here's the key, we're not designing the perfect system, we're designing the boring proven system that solves the actual problem with minimum risk. Days eight to nine, delivery planning, timeline, budget bands, roles, and this is critical,
A three sprint roadmap that shows immediate value. Day 10, the readout. Deliverables include a 10 to 15 page MVP plan, a three sprint roadmap with story level estimates, architecture diagrams, risk registers and acceptance criteria. Everything you need for a major go no go decision. What does this give you? It forces trade-offs early. It's vendor agnostic, which use boring proven tools and not shiny objects. And it produces artifacts that both investors and engineers trust.
Now, I'm not saying you need to hire us to do this, though if you want help, we're here, but whether you do it yourself or bring in outside help, you must do some version of this discovery in your first two weeks because without it, you're building your 90 day plan on assumptions and assumptions kill modernization initiatives.
All right, let's break it down week by week. I'm gonna be opinionated here because I've seen what works and what fails. So weeks one and two is listen and map. Your only job is to understand the current state and identify the burning platform. So do this, schedule a 30 minute one-on-one with every person who will be affected by your modernization. Every person, engineering, product, sales, customer support, the CTO,
even finance if they're involved in procurement. Ask them the same three questions in every conversation. What's currently causing you pain? What would make your job easier? And what past modernization efforts have failed here and why?
Map your stakeholders into a grid, influence high and low versus support for change high and low. You need to know who your champions are, who your blockers are, and who's neutral. And then identify the shadow CTO. Every organization has one. It's a senior engineer or architect who might not have the title, but everyone listens to. And you must get them on your side. Don't do this. Don't propose solutions yet. I know it's tempting, but resist.
Don't criticize existing systems even if they're terrible. The person who built them is probably in the room. And don't spend all your time with just the engineering team. The biggest risks to your modernization aren't technical, they're organizational. Think about it. When was the last time you saw a modernization project fail because the technology didn't work? It's almost never. They fail because sales don't want to lose their custom features. They fail because customer success is terrified of change.
They fail because finance won't release the budget. You need to see these landmines before you step on them.
So weeks three to four is defining the quick win. So your job here is to identify and commit to one quick win that builds credibility. Here's the strategy. You need a project that's small enough to complete in 60 to 75 days, visible enough that people notice and valuable enough that it matters. And it needs to solve real pain points that you heard about in weeks one and two.
require minimal dependencies on other teams, be achievable if half the things that could go wrong do go wrong, and demonstrate your approach to modernization, product thinking, user-focused, cross-functional. Some examples from MidSight companies might be automating a manual deployment process it takes for hours down to 20 minutes, fixing a performance issue in a customer-facing feature that's generating support tickets.
or creating an API for an internal tool that three departments are all working around.
What makes a bad quick win would be anything requiring major database migrations, anything that blocks other teams work, anything foundational that doesn't deliver value, or anything that requires consensus from more than three stakeholders. I'm serious about this. Your quick win needs to be almost boring in its straightforwardness. Save your ambitious stuff for month four.
By the end of week four, should have a one page brief on your quick win project, problem solution, success criteria and timeline, for example, buy in from your direct leadership, the small team identified two to four people and your first communication to the broader organization about what you're doing and why.
Then we get on to weeks five to eight where we execute the quick win and build the roadmap. So this is where a lot of directors make their second big mistake. They think, great, my team's executing the quick win. I can go back to strategic planning.
But you need to be in the work, not micromanaging, but visible, unblocking, problem solving, communicating progress. So here's your weekly rhythm. Monday, team kickoff, review progress, identify blockers. Wednesday, stakeholder update. Could be a quick email or a Slack update. Only has to be three to five sentences. Friday should be demo or showcase of what was shipped this week, even if it's small.
This serves two purposes. You're building trust by staying engaged and you're establishing a communication cadence that will carry through the entire modernization. In parallel, you're building the full 90 day plus roadmap. With weeks five to six, you're drafting the roadmap based on your discovery work and stakeholder input. Week seven, socialize the roadmap with key stakeholders. This isn't a presentation. This is just saying, here's what I'm thinking. What am I missing?
We can revise this based on the feedback and prepare for leadership review. So your roadmap should include the vision, the quick win, the next three priorities, what we're not doing, how we measure success and what could derail us and how we'll mitigate those risks.
So weeks nine and 10 is now about delivering the quick win. So hopefully the quick win is wrapping up and here's how to maximize the impact. Ship it, even if it's not perfect. Done is better than perfect when you're building credibility. Create artifacts, before and after metrics, customer or internal user testimonials, a quick what we learned document, photos or recordings if relevant.
and then celebrate it publicly. Give credit to your team, thank the stakeholders who helped and share the impact widely. And this matters because you're not just delivering a feature, you're proving that you can ship. You're showing what good looks like. You're demonstrating the modernization doesn't mean endless planning. It means delivering value.
Then you get to weeks 11 and 12. This is about communicate the vision and setting expectations. So now that you've earned the right to talk strategy, present your full roadmap to the leadership and your presentation should cover like what you learned in the last 70 days, the quick win and its impact, modernization, vision and roadmap, resource needs, risks and mitigation strategies and what success looks like in 6, 12 and 24 months.
But crucially, you also might need to reset expectations. Be honest about what won't change because some legacy systems might stay for years. How long will the transformation really take? Because it's probably longer than they would want. What trade-offs you'll have to make because you can't do everything. And so you might get pushback from leadership. Good. It means they're engaged.
Better to have those conversations now than in six months when you're behind schedule and out of political capital.
So week 13, plan the next quarter. Your final task in the first 90 days is setting up the next 90 days. And this isn't just about technical planning, it's about rhythm and momentum. So establish a regular cadence for engineering all hands and updates, clear decision-making processes on who decides what, how you'll handle the urgent requests versus your roadmap work, metrics that you'll track and share.
and how people can give feedback or raise concerns. And most importantly, identify your next quick win. The mistake directors make is treating the quick win as a one-time thing. No, quick wins build momentum. So you should always have something shipping in the next 60 to 90 days that's tangible and valuable.
So let's talk about communication cadence because this is where so many modernization efforts fall apart. And here's my framework. Weekly, you update the direct team and your immediate stakeholders. You have like a list of brief, like bullet points. Here's what we did. Here's what's next. Here's what's blocked. Bi-weekly, you can then update extended stakeholders like the product team, sales, customer success. And that probably needs a little bit more context because they're not as in the weeds.
and that can focus on impact and upcoming changes that might affect them. And then monthly, you've got a broader organization update. The newsletter or all hands segment, celebrate the wins and preview the next month. Invite the feedback. And then quarterly, you've got an executive review, which obviously is a formal presentation with metrics, strategy, and resource requests. The key here though is consistency. Don't update when you feel like it.
Don't only communicate when there's good news and definitely don't go silent when things are hard. I'll tell you what happens when you don't communicate. People fill the vacuum with assumptions and those assumptions are almost always worse than reality.
So we've covered a lot. Let me close this main segment with five pitfalls I see most often in their first 90 days. Pitfall number one is starting with the architecture instead of the problems. And you now know how to avoid this. Problems first, solution second. Pitfall number two, ignoring the human side of technology. Because technology is easy compared to changing how people work. So invest in change management from day one.
Pitfall number three, taking on too much too fast. Your legacy system survive this long. It can survive another 90 days. So focus on one thing at a time. Pitfall number four, not celebrating the small wins. Momentum is everything. If you only celebrate the big transformation at the end, you'll lose people along the way. Pitfall number five, forgetting who you're really working for.
And this one's quite personal for me because I've seen directors get so focused on the technical transformation that they forget they're serving customers, serving the business and serving their teams. The technology is just the tool. Don't fall in love with the tool.
So here's my question for you to sit with. What's the one thing that you're most worried about in your first 90 days? Not the technology, the people, the politics, the organizational dynamics. Name it because once you've named it, you can plan for it.
So if you're sitting here thinking, this all sounds great, Tom, but I need help actually doing it. I get it. And that's why we built Concept to Cloud. So we specialize in helping mid-size companies de-risk their modernization initiatives. Our 10-day discovery sprint gives you the clarity that you need to plan for those crucial first 90 days. We're not going to sell you a year's long engagement or lock into some rigid methodology.
we're gonna help you understand the problem, identify the right solution and give you the roadmap you can execute, whether you work with us or not. So if that sounds useful, visit conceptofcloud.com, where there's no high pressure sales calls, no enterprise solutions that don't fit your reality, just practical help from someone who's been in your shoes. And if you don't need outside help, honestly, that's great. Take what we've talked about today and run with it. That's why this podcast exists.
why all the downloadable material is there for you to get started. I want you to succeed whether or not you work with us. So all right, let's wrap this up. If today's episode resonated with you, here's what I'd love for you to do. First, share this episode with another engineering director who's about to start a modernization initiative. They'll thank you for the heads up. Secondly, let me know what you think. You can find me on LinkedIn, just search for Tom Barber and Concept to Cloud.
I actually do respond to messages. So send me a DM. Tell me about your first 90 days. What worked, what bombed, and what would you add to this framework? And third, subscribe to the Engineering Evolved wherever you get your podcasts. We release new episodes every week, and each one is designed to give you practical strategies you can use immediately. No theory for theory's sake. Next time on Engineering Evolved, we're
tackling a question I get all the time, which is how do I sunset a legacy system without destroying the team morale? Because here's the thing, every time you modernize something, you're implicitly saying the old way was wrong. And the people who built the old way, they're probably still on your team. So how do you navigate that transition without making people feel like their past work was worthless? It's a masterclass in emotional intelligence meets technical leadership, and I'm going to share the framework that worked for me in some pretty tricky situations.
So that's next time on Engineering Evolved. I was your host Tom Barber. I'll see you in the next one.