From Tech Debt to Top Priority: The Engineer's Guide to Getting Buy-In

How to get leadership buy-in for tech debt and other large projects across multiple teams, tight timelines, security concerns and more.

How many times have you felt defeated or frustrated after they’ve repeatedly failed to get buy-in for important work or ideas you have to improve the product/systems?

Yeah, me too.

At times it can feel like all your leadership team does is shoot down ideas, or say they’ll try to get to them next quarter.

In today’s article, you’ll learn how to break though the roadblocks the “we’ll do it next quarter”s and endless back and forth with decision makers. Including:

• Why great ideas often fail to get buy-in

• The language barrier between tech and business

• Building compelling technical proposals

• How to get buy-in from decision makers

I’ll end with a real-life story from my experience of how I got buy-in for a new library/vendor in the midst of our startup being acquired that helped us successfully land a new multi-million dollar client under an insane deadline.

Let’s dive in 👇🏼

Why great ideas fail to get buy-in

The top reasons I’ve seen good ideas or projects fail to get prioritized are:

• Lack of buy-in from decision makers

• Failure to connect the ask to a business need

The first two are related. Often you can’t get buy-in from decision makers because you are failing to connect your ask to a business need.

I’ve heard so many engineers have a similar conversation:

Engineer: There is some tech debt in x/y/z area, we really need to address it, the code is super messy and the cyclomatic complexity is very high.

PM/EM/Director: Ok, thanks for bringing it up. We’ve got this important project or set of tickets we’ve got to land right now, but let’s try to carve out some cleanup time in Q4 for that.

6-18 months later a big incident happens…

Director: This is insane, how did we not know about this land mine in our system?

Engineer: I told everyone several times, but no one listened.

Director: oh wait… is this related to that tech debt issue you mentioned last year? You didn’t tell me things had gotten worse since then. I would have prioritized this if I had known the impact this could have had on our systems / customers.

Engineer: No one ever listens to me until its too late.

This type of thing or similar happens all too often, and its a lose, lose for everyone involved. The engineer is constantly frustrated that no one listens to them, and then things blow up, and the director feels like they can’t trust the engineer to watch out for their business and systems.

The language barrier between tech and business

The above exchange is a clear example of a language breakdown between tech and business. The more senior you want to be as an IC or engineering leader, the more important it is to your success and your team’s success to bridge gaps between business, product, and engineering.

Without it, you’ll never earn the trust, buy-in, or opportunities from decision makers you need to take on large projects, new ideas, or complex re-architectures that are key to your future career, and your team’s success.

Business leaders care about their products, their customers, and their bottom line. Most engineers care about their code, their systems, and likely their products and customers, but in a less direct way.

The best engineers I’ve worked with learn how to bridge the gap between their goals and perspectives and the businesses goals in order to be successful.

But Caleb, that’s not my job!! I shouldn’t have to tell my leaders why technical debt is important to tackle. They should know that. I told them, why don’t they believe me?

Gosh, I feel you, and I’ve been there so many times myself. Now that I’ve been a technical lead for a couple yrs, and more recently an engineering manager, my perspective has changed a bit.

Connect your ideas and needs to business needs

Here’s what I’ve come to realize:

Those who work hard to understand the business, the product, customers needs and pain points, and even financial incentives of the business and learn how to connect that to their work are leaders.

These engineers are the ones who get promoted into leadership roles whether they ask for it or not. They are the ones that get the big projects and opportunities that end up giving them even more in the future.

Taking that extra time to bridge the gap, pays off for you and your team – even if it’s not technically your job.

Find out what your leadership cares about, and meet them there with compelling ideas that will crush their goals, and help you and your team in the process.

Building compelling technical proposals

Alright, let’s look at our earlier example, but with our new perspective:

Engineer: There is some tech debt in X and Y areas. I’ve talked with few team members, and even though Y has a lot of messy code, it’s annoying but manageable, it’s not a great investment to spend time there.

Where I think we really need to focus is this scaling issue I’ve started to piece together after we’ve gotten several new alerts popping off over the last couple weeks. They were dismissed as unrelated, but I pulled together this dashboard showing they are not anomolies, and our two biggest customers are affected weekly. What’s worse, with our three new customers landing the problem will get 2-3x worse likely leading to a large production issue.

EM: Wow, thanks for bringing that up – we’ve gotta have someone start looking into that. What would it take to fix this issue?

Engineer: I’ve talked to a couple other staff engineers and drafted a rough plan. I’d estimate with 2 engineers spending 3-4 weeks, we’d be in good shape. I’d recommend we land this high priority feature we’ve been working on, and then pivot into this new priority issue. Here’s my draft tech spec – I’d need another couple days to finish up and break out tickets, but I can have it ready for our next sprint if you agree we need to jump on this.

EM to Director: We’ve got to switch priorities in our next sprint. We’ve identified a large production bottleneck affecting our two largest customers, that would also block successful onboarding for new our customers if we didn’t tackle it. The team has a plan and will be ready before they land, but we’ll need to delay launching that other feature we had planned for a few weeks.

Director: Wow, thanks for highlighting before we had a huge outage. Done and done, please get to work! I’ll communicate with our brands and support team, and reshuffle our next quarter a bit. Who did you say found this again?

6-18 months later… new brands successfully land, new scaling records are hit

EM: I want to chat about you pursuing a staff role. The way you consistently looked out for our future needs and anticipated the needs of our systems and business is so valuable. Leadership is constantly raving about you…

That example is not too far off from reality for many engineers who now find themselves as staff, principal, or even engineering directors.

It’s not necessarily the best coders who have the most impact. It’s engineers who can drive important cross-team efforts connected to large business or product impact, and say no to the endless other things vying for their attention.

This is only going to be more true as ai continues to take on more of the raw day to day coding work.

How I learned this with 3 months to prove it works

We'd just been acquired when a multi-million dollar client needed enterprise RBAC features in 3 months. Features that would normally take 12-18 months to build.

We had basic user roles. They needed enterprise-grade permissions, user groups, and document sharing.

The client was about to sign, but needed all the features in 3 months. So like all good startups, we jumped in headfirst and said yes 😅.

I was the lead on the project, and quickly realized building all of those features in-house would take at least 12-18 months.

I found an amazing paid library that could get us there in time, but it had red flags: newer startup, no SOC 2 certification, and new tech to our org. Meanwhile, our new parent company's security team was pushing their own internal tool that wouldn't actually work for our needs.

I built a stakeholder proposal covering everything our leadership team would need to make the decision: why internal tools wouldn't work, vendor pricing and scaling, SOC 2 timeline, customer references, and exactly how much revenue this would unlock.

I walked into the meeting, presented the high level overview – plus handed in a 35 page doc of all my research if they wanted more details.

I patiently worked through all their questions and objections, and 20 mins later walked out with a signed contract and a new vendor/library in our hands!

Later my EM reached out and said I really impressed our VP. The VP said I made it so easy for them to make a decision they could be confident in. I had done all the hard work, it was just up to them to make a call either way.

Hitting the 3 month timeline was still insane, and we didn’t launch without any hiccups – but we did succeed in the end. Shoutout to some amazing all star engineers on my team who did most of the engineering work to pull it off.

It was a massive win for me, for our team, our business, and our products.

I really believe that project was a key part of the puzzle that led to my promotion from engineer to manager, and really unlocked a new level of thinking, cross-team collaboration and execution that continues to be a big part of my success in this field.

The Compelling Technical Proposal Checklist

Use this checklist to ensure your success as you prepare for stakeholder meetings when pitching large efforts you want to get prioritized: