“Make sure you tie your work to business impact.”

I heard this every six months at Dropbox during performance reviews. And like most engineers, I’d dutifully scramble to retrofit my technical work to business metrics after the fact.

Sound familiar?

Here’s the thing about being an IC at a big tech company: Business problems go through several translations before they reach you. Sales hears customer needs, Product gathers requirements and builds the business case, Engineering Management breaks it down into technical projects, and finally, you get a JIRA ticket.

This definitely had its benefits for us ICs. Less cognitive overhead, more focus on our technical craft, faster shipping.

But this setup isn’t all roses.

Your incentives drift from the organization’s. You may work on what’s technically interesting, or what your manager wants, or what’s fun. And then every six months, you play the game of justifying it with business metrics.

Now that I run my own consulting practice, everything is different.

I start with the business problem. Sometimes that means writing code. But sometimes it means sitting down with the founder and documenting their sales process in a Google Sheet, or conducting user research to better understand the product.

The technical skills are still important, but they’re just one tool in the toolkit for solving business problems. Instead of retrofitting business impact onto technical work, business impact drives every decision from the start.

This approach creates perfect alignment:

• The client gets measurable business impact
• I know I’m creating real value
• Success is clear and quantifiable

When you’re a consultant, you can’t retrofit business value after the fact. It has to be your starting point.

What about you? Have you ever had to justify your work’s business impact after the fact? How did that feel? Hit reply and let me know.