“Shipping features gets you noticed. Shaping what gets built, and why, makes you a leader.”
In the AI-accelerated era, output is no longer the bottleneck. Routine implementation work is cheap, fast, and increasingly automated. What's scarce, and what's genuinely valuable, is the combination of business acumen and ethical leadership: knowing which trade-offs matter, which outcomes are worth pursuing, and which corners shouldn't be cut.
The previous post in this series explored how communication and empathy shape engineering quality in AI-assisted workflows: prompt engineering as a communication discipline, translating AI output for non-technical stakeholders, and updating team rituals like standups and design reviews for hybrid collaboration. That post focused on how engineers communicate. This one is about what they communicate about, and whether anyone on the team is asking the harder question: should we be building this at all?
The engineers who thrive won't be the ones who build the most. They'll be the ones who influence what gets built in the first place.
“Just Tell Me What to Build” Is a Career Ceiling
It's a mindset many of us were trained into: optimize for delivery, velocity, and clean merges. Over time, that turns you into a high-performing task-taker. The further upstream the conversation happens (before tickets, before specs) the less impact you have.
This is the ceiling: you're fast, you're accurate, but your influence is capped. You become a cog in someone else's roadmap.
The engineers who grow are the ones who refuse to wait for the backlog to be finalized. They start asking:
- Who is this feature for?
- Why now?
- What happens if we don't build this?
Once the ticket is in your queue, the opportunity to shape it has already passed.
Business Acumen Is the Judgment Layer AI Can't Replace
AI can now generate technically accurate solutions in seconds. Some are elegant, some are over-engineered, many solve the wrong problem. That speed doesn't reduce your value. It raises the bar for your decision-making.
Business acumen is the ability to look at a valid solution and ask: does this help the product win?
Here's what that looks like. A PM requests a real-time analytics dashboard with sub-second refresh. You know the data pipeline runs batch jobs every five minutes, and re-architecting for streaming would take two months while stalling planned onboarding improvements. The PM's actual need is spotting campaign performance trends within the same business day, not watching numbers tick in real time. You propose a version with 15-second refresh using the existing pipeline and a lightweight cache layer: it ships in two weeks, covers the core use case, and keeps the roadmap intact. That's business acumen: the PM needed fast-enough data with reliable delivery, not sub-second latency.
It's knowing when to:
- Choose a lean implementation that gets to market faster.
- Push back on a feature that adds churn risk or support load.
- Advocate for a “boring” architecture because it reduces long-term volatility.
These calls require awareness of:
- Customer needs
- Team bandwidth
- Risk tolerance
- Strategic alignment
When execution speed is commoditized, understanding the business becomes the engineer's superpower.
Ethical Leadership Starts Before the Code
Most engineers know software isn't neutral. The question is whether that awareness shows up in your design reviews or only in your conference-talk opinions. AI makes the stakes higher, faster.
Yes, ethical leadership shows up in code reviews:
- “This model is trained on biased data.”
- “This logging call exposes sensitive user behavior.”
- “This feature could be easily misused without rate limits.”
But the deeper shift is upstream.
The real ethical failures don't start in the PR. They start in the design doc nobody questioned. That's where engineers need to show up with uncomfortable questions:
- Who does this exclude?
- What does failure look like for the user, not just the system?
- Are we solving for usability or surveillance?
A lightweight “ethical gut check” in early planning can prevent downstream disaster. If no one else is thinking about it, that's your cue to lead.
This matrix maps business acumen against ethical maturity in modern engineering roles. Engineers in the bottom-right quadrant shape outcomes: they know what the business needs and hold the line on what users deserve.
Seniority Isn't About Tenure. It's About Trajectory.
You don't get senior by writing better code.
You get senior by seeing the system around the code and being trusted to navigate it.
That means:
- Translating business strategy into technical trade-offs. AI tools can generate three architectures for any given problem. The senior skill is mapping each option to its business impact (cost, time-to-market, maintenance burden) and recommending the one that fits the company's current stage, not the one that looks best on a whiteboard.
- Mentoring with clarity, not just syntax. When a junior engineer asks the AI for help and gets a plausible but subtly wrong answer, they need someone who can explain why it's wrong in terms of the system's constraints, not just hand them the correct code. That kind of mentoring builds judgment, not just output.
- Owning ambiguity instead of escalating it. AI tools make it trivially easy to generate three plausible approaches to any problem. The senior skill is choosing which one to commit to, defending that choice with evidence, and accepting accountability if conditions change.
- Saying “no” when it's the right call, and proposing something better. AI-generated solutions always say yes. They will happily produce code for a feature that conflicts with your roadmap, duplicates existing functionality, or creates tech debt that outlives the sprint. Someone has to be the filter, and that someone earns trust by pairing the “no” with a better path forward.
AI doesn't replace any of this. The faster you can ship, the more dangerous it becomes to ship the wrong thing.
You're Not Just the Builder. You're the Backstop.
AI can write code. It can build features. But it can't choose wisely. It can't say no. It can't protect users. It can't recognize when something is technically brilliant but strategically irrelevant or ethically risky.
That's on you.
And that's the kind of growth we focus on at Utterskills: where clean code meets clear thinking, and real impact starts upstream.
Frequently Asked Questions
Do engineers really need business acumen?
Yes, and the need is growing. When AI handles more of the implementation work, the gap between “technically correct” and “strategically valuable” becomes the difference between a feature that moves metrics and one that ships to silence. Business acumen lets you evaluate whether a solution serves the customer, aligns with the company's direction, and justifies the engineering investment. Engineers who can frame technical trade-offs in terms of revenue impact, customer retention, or operational cost become trusted advisors to product and leadership. Engineers who can't are left waiting for someone else to decide what matters.
What does ethical leadership look like in day-to-day engineering?
It rarely looks like a grand stand. It looks like raising a concern in a design review: “This data collection goes beyond what the user consented to.” It looks like adding a rate limit before someone asks for one, or flagging that an AI model's training data underrepresents a user segment your product serves. Ethical leadership means asking “who does this affect, and how?” before code is written, not after an incident report lands. The engineers who do this consistently earn trust precisely because they slow down the parts of the process that deserve scrutiny.
How does business understanding relate to seniority?
At the junior level, strong execution is the expectation. As you move toward senior and staff roles, the expectation shifts: you're assessed on whether your technical decisions serve the business, not just whether they compile. An engineer who can explain why a migration reduces customer churn by 15%, or why a particular architecture choice cuts support costs, demonstrates the judgment that promotion committees and hiring panels look for. Technical skill gets you in the room. Business awareness is what makes your recommendations stick.
Next in this series: The Adaptive Engineer: Adaptability and Learning explores how engineers and teams stay relevant in a world defined by constant change. From learning loops to reinvention strategies, the final post covers what it takes to build a future-proof career and culture.
Author Quote
“AI can write code. It can't choose wisely. It can't say no. It can't protect users.”