Stop Being Just a Cost Center: Learn the Business to Make Your Engineering Matter

After that all-hands meeting ended, I overheard the engineer next to me whisper, "More pie in the sky. I don't get it. Anyway, we can't influence these things."

I didn't respond, but my heart skipped a beat—three years ago, I thought the same way.

Writing good code, managing tasks well, making performance optimizations... isn't that "professional" enough?

But slowly, I began to realize: our problem isn't a lack of professionalism, but that we always see ourselves from the perspective of a "cost center."

We always assume: if the technology is good, it will naturally be valued. But the reality is, the less you understand the business, the more your technology looks like an "expense."

"Not understanding strategy" is okay, but "not understanding the business" is truly dangerous

Not every technical person needs to read the board's PowerPoint or recite the company vision's OKRs.

But a fundamental fact is: your work supports a business goal. If you don't know what that goal is, no matter how advanced what you build is, it might be completely off target.

I've seen too many smart engineers build technically perfect systems, only to have them cut two months after launch because nobody used them. It's not that the technology was bad, but that the feature wasn't aligned with "business priorities" at all.

So, if technology doesn't want to be treated as a cost, the first step isn't to explain the technical solution clearly, but to see the business direction clearly.

Real business sense isn't memorizing KPIs, but understanding decision logic

Many people say "I want to understand the business," so they go memorize sales figures, registered users, GMV... But these "business metrics" are effects, not causes.

What's more valuable is figuring out:

Why did this feature suddenly get prioritized?
The boss says "improve customer retention," but what specific behavioral problem are we trying to solve?
The product team wants a redesign—is it because traffic changed, or is there a conversion gap?

We don't need to become product managers, but at least we should be able to see the logic of a business chain, from goal → action → technical landing point.

One practice that has benefited me greatly:

Subscribe to and read at least one internal weekly report written by the PM or BD team every week. Mark the parts you don't understand and try to draw a cause-and-effect diagram.

Do this for three months, and when you're in meetings again, you'll already be able to hear "what the underlying motivation of this requirement is," and you'll know where to "invest" the technical solution.

Technical people look at the business not to switch roles, but to give technology leverage

The more you understand the business, the more you can use "technical means" to make moves that the business can feel.

For example:

For the same "system performance optimization," once you understand the business, you'll know to prioritize optimizing the settlement process rather than the backend query interface, because the latter only affects operational experience, while the former directly impacts GMV settlement delays.
When running A/B experiments, you're no longer just "helping with instrumentation," but can suggest variable settings, because you know which metric is the core goal and which is a relay metric.
You can even, early in a project, push back on the business side to change direction or reduce scope, because you've discovered that the goal and the execution method don't match.

These aren't "understanding strategy" or "managing the business"—rather, it's using technology to build business acumen, so that every line of code "lands on a leverage point."

How do I train my own "business acumen"? A few small methods to share

These methods are simple, but after repeated practice, they've really increased my influence as an IC.

1) When making a decision, ask yourself: "What's the business benefit of this action?" If you can't say, go ask product, BD, or operations. Sometimes it's not that you're clueless, but that the requirement itself wasn't thought through.

2) Subscribe to two external information sources: one industry blog and one competitor product update. For example, if you work in fintech, you can subscribe to Finextra, TechCrunch, and the PayPal product blog. You'll be surprised how outsiders view your industry.

3) Develop a "once a quarter" review habit: which features actually brought business results? Was it enabled by the technical implementation?

Often our understanding of "business contribution" stays in Jira—but what's truly valuable is matching technical results with business results.

4) I wrote a small tool myself: it collects every product iteration description and related data changes from our BU.

It automatically scrapes keywords from daily reports, monthly reports, and financial reports, and then I manually annotate "which metrics changed before and after this feature went live." This tool started out of curiosity, but now new team members use it during onboarding.

Technology isn't a cost, but it depends on what you bring to the company

We often say, "Technology shouldn't be treated as a cost center." But at the end of the day, if no one knows what business problems you've solved, then indeed all they can look at is the cost.

You don't need to fight for KPIs, and you don't need to become a business analyst. You just need to learn to ask one more question:

"What business scenario problem are we trying to solve with this?"

Then use technical means to make that problem "solved beautifully."

Business isn't some distant strategy; it's the "landing coordinates" of every technical action you take.

The sooner you see this, the sooner you go from "capable" to "valuable."