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


Project empathy – quick update

Not long ago I began writing code to remember what it was like to build things every day for users with the hope to build some empathy for my direct and indirect reports

After a few months of doing close to 30 minutes in the morning of daily coding I want to share what I have re-learned so far.

The temptation to deliver quickly is high, but maintaining a high quality standard requires patience, persistence and consistency.

I made an effort to write up a service canvas, detailed tickets explaining the work to my future self, used true and tried design patterns to keep the code maintainable, covered the code under test, and used sonar cloud to review my code for known vulnerabilities and other static analysis checks.

These and more are expected outputs of any software my teams write. Going through the steps and making an effort to understand the value provided has done wonders to create empathy for the challenges software engineers face daily.

Releasing code is more complex, there are vast options from multiple providers that can make it overwhelming at first, but new tooling like render.com made it simpler and provided a glimpse into a bright future for hosting options.

In short, we ask a lot of engineers and oftentimes, as leaders, we get too excited about the prospect of shipping fast, but we fail to realize that good engineering practices have tremendous value and take considerable time to go through.