strategy Technical Debt

How to drive your initiative forward as an engineer

This post will show you how to move your tech idea from idea to execution.

As an engineer, you will surface work that is needed but difficult to explain to non technical stakeholders.

Without authority, you will learn how to influence others and surface the importance of your initiative so that you can move forward with its execution.

Unfortunately, doing so requires changing how you communicate and stepping out of the technology realm and into the business realm.

A change not many engineers are comfortable making.

The business realm is full of ambiguity

Unlike engineering, where we can model uncertainty and default to established patterns to solve problems, business is full of ambiguity and uncertainty.

Making the switch a daunting task for a lot of engineers

Here are other reasons engineers find difficulties driving their initiates forward

  • Finding advocates to support your idea
  • Tech-centric messaging that caters to engineers
  • Unable to articulate how it solves a business problem
  • Lack of alignment with the current strategy

Fear not, you are here to learn, and I am about to show you how to drive your initiative forward successfully

Here’s how step by step:

Step 1: start with a user problem

No initiative survives the smell test unless it can solve a customer pain point.

Time and time again engineers come to me with enhancement ideas to solve scalability concerns such as the need to increase the DB size, or maintainability and quality issues solved by increasing test coverage.

From an engineering perspective, these ideas always make sense.

But the major concern we run into when trying to move forward is priority.

Your idea needs to stack up against current initiatives, your peers’ projects, bugs, the latest exec idea, incidents, and a vast range of other work competing for your team’s time and attention.

However, adding value to our users is always a winning proposition and something anyone in the company can understand.

To introduce a scaling initiative, you could start with a user problem such as “our users lost trust in our system”

followed by some backing data like “our incidents have increased twofold compared to last quarter”

Next, tie the data to the engineering problem you want to solve “a large percentage of these incidents showed that scaling our infrastructure could have prevented them”

Step 2: Gain advocates early!

Many engineers jump straight to presenting their ideas to a decision maker.

The failure is the lack of peer validation.

Decision makers will often rely on validation from others that the idea is sound and adds value to our users.

This is because they have to place many ideas into perspective, compare them against each other, decide, and defend their decision by demonstrating they went through a good decision-making process.

To increase the chances your initiative goes through, present your idea to your team mates, and others in the organization willing to listen.

This is an excellent opportunity to get early feedback by asking if the problem statement resonates, if the message is clear, or if the pitch triggers any defensiveness.

Dig deep and change your messaging as you gain more feedback.

The excellent benefit of involving others early is that they usually tend to become your backers.

They have been involved early in your process and, through the back and forth with you, now have a lot of context on the problem you are solving and how your proposal will achieve the goal.

Step 3: Find alignment to the current strategy

By now, you are talking about solving a user problem and have advocates with the knowledge and willingness to vouch for your idea.

Typically, this is enough to get buy-in from your team, but there might be cases where your pitch doesn’t neatly align with a larger company initiative.

This is where you talk about how helping our users also increases revenue, reduces churn, helps with expansion, or increases our ability to introduce new products.

Reach out to marketing, product, design, engineering leadership, and other areas with high visibility into planning with questions about the current direction, stated goals, and the strategy to get there.

With this new set of information, you are now ready to turn your tech initiative into solving a user problem, with backing from your peers and alignment with the company’s strategy.

Alignment icons created by Eucalyp – Flaticon

Technical Debt

Managing technical debt

What is technical debt?

In simple terms, technical debt can be described as time borrowed when writing software.

In other words, we incur technical debt to save time now that we will be paying back in the future.

There are many reasons why we might incur technical debt, and when you are deciding, it will feel like the right choice, and it often is.

Just remember that incurring technical debt is usually a business decision, not a technical one.

Here a few examples of what I am talking about

  • We decide to use an open-source library instead of writing our own code… because we can get to market faster this way.
  • When building an MVP, we don’t spend a lot of time making our code scalable…. because we might not get the traction we expect.
  • you build a non-ADA compliant application… because your clients are not asking for it, yet.
  • You see an improvement, but your boss is pushing hard to meet the deadline, so you open a ticket and hope to get to it later… because, well, deadlines!

Types of technical debt

Technical debt has many shapes, the most common ones to engineers are probably new bugs, code smells, and other code metrics.

The reality, however, is that technical debt is much more complex than that.

Would you consider a lack of documentation as technical debt? (hint: you should).

What about no unit test coverage? is that technical debt? yes, yes it is.

For your purposes, you will need to come up with a good definition of what you consider to be technical debt.

If you are coming up with only a few things on your list, I recommend that you take a look at the presentation titled “Towards an Ontology of Terms on Technical Debt” by the Software Engineering Institute at Carnegie Mellon University.

Their list should work as a good starting point to identify technical debt within your organization.

Should you pay it off?

Now that you know what it is, and you can categorize it, what is the next step?

Well, now you figure out how much of it you pay down. Remember how I mentioned that incurring technical debt is usually a business decision and not a technical one? guess what, paying it down is a business decision as well.

In our case, as engineers dealing with technical debt, we can make a very good business case for spending engineering time paying down technical debt.

Take for example the MVP app we mentioned above. Since we had an aggressive time to market, we pushed hard and got the application out on time.

In the process, lots of things could have been better, but we knowingly incurred technical debt just to get the application out.

Now your user base is growing and your metrics are showing slowdowns in some areas of the application, nothing major yet, but since you are a responsible engineer, you mention it to your product manager, your manager, and your fellow engineers.

You are asked to look at how much work it would be to make the experience better, and you come up with about 6 weeks of work. (did you use our estimation guide, go ahead, take a look, we’ll wait)

While doing the work makes a lot of sense from the technical perspective, after all, we know our application can be better and we know exactly how to get there.

From a business perspective, the story is a different one. Those 6 weeks could mean a lot of positive or negative things such as

  • Missed deadlines for other projects
  • Going over budget
  • Broken promises


  • Increased application engagement
  • Renewing the unhappy client complaining about performance
  • Gaining new clients

It all depends on the business, their vision, and the return on investment perceived from paying down the technical debt.

Strive to identify technical debt early, be honest, and open about what it is and why you think it is important to pay it off.

Remember that your business counterparts will not always understand the nuances of the technical details for your proposed solution, so be nice and explain it in simple terms from a business perspective and together with your business partners decide if you will pay it down now or later.

Further reading

Technical debt is a complex topic, if you are interested in knowing more, I recommend following up by reading these great books on the topic

Great books to follow up on technical debt
Icons made by Flat Icons from www.flaticon.com