Technical Expertise Gets Projects Started. People Skills Get Them Across the Finish Line.
- Leadership
- 4 min read
Venkatachalapathi Mavilla – Senior Program Manager at Mercedes-Benz Research and Development India
In complex engineering programs, the hardest problems aren’t always technical.
Imagine an automotive engineering program approaching a critical delivery milestone.
The software team is confident about its implementation. The hardware team has identified an integration concern. Testing needs more time to validate a critical dependency, while the customer expects delivery according to the original schedule.
Everyone is working hard. Everyone understands their responsibilities. And everyone believes their concern deserves priority.
Yet the program is moving toward a difficult situation.
The challenge isn’t necessarily a lack of technical expertise. It is that different teams are looking at the same problem from different perspectives.
This is where technical leadership becomes something more than managing engineering work.
Having worked in automotive technology, I’ve come to appreciate how much complex programs depend on the ability to listen, understand competing priorities, and bring people toward a common decision.
The technology may be complicated, but the real challenge is often getting people to navigate that complexity together.
Why Technical Expertise Alone Isn't Enough
In engineering-intensive industries such as automotive, successful delivery depends on multiple interconnected systems and teams.
Software development, hardware engineering, testing, quality, safety, suppliers, and customer-facing teams may all contribute to the same program. A decision made by one group can affect several others.
Each team also measures success differently.
Engineering may prioritize technical stability. Quality teams focus on validation and compliance. Program management tracks timelines and dependencies. Customers expect agreed functionality and reliable delivery.
None of these priorities is inherently wrong. The difficulty emerges when teams optimize for their individual objectives without fully understanding the impact on the overall program.
Consider a software team that wants to introduce a late improvement. From its perspective, the change enhances functionality. But the testing team may see additional validation effort, while program management sees a potential delivery risk.
A technically sound decision can still create problems if its wider implications are not understood.
This is why I believe leadership in complex programs requires more than being the person with the strongest technical knowledge.
It requires the ability to connect different perspectives and make decisions that serve the larger outcome.
Listening Is More Than Letting People Speak
Listening is often described as a soft skill. In technical environments, I think it is a practical leadership capability.
When teams disagree, the natural instinct is to move quickly toward a solution. Leaders may focus on identifying the correct technical answer or deciding which recommendation to follow.
But disagreements aren’t always caused by differences in technical understanding.
Sometimes teams are working with different information. Sometimes they interpret the same requirement differently. And sometimes a concern that appears technical is actually related to resources, timelines, or unclear ownership.
Effective listening helps uncover these differences before they become larger problems.
For a technical leader, that means listening at several levels:
- Listening to engineering teams: Understanding technical constraints, dependencies, and risks that may not be visible in a high-level project review.
- Listening to customers: Looking beyond stated requirements to understand the outcomes customers expect and which trade-offs they may be willing to accept.
- Listening to stakeholders: Recognizing the business priorities influencing decisions, including cost, quality, delivery commitments, and long-term product implications.
- Listening for what isn’t being said: Creating an environment where team members feel comfortable raising uncertainties, potential failures, or concerns about unrealistic expectations.
The last point is particularly important.
In high-pressure programs, people may hesitate to communicate bad news because they fear being blamed or appearing incapable.
But a risk identified early is usually easier to manage than a problem discovered just before delivery.
A leader who encourages honest conversations gains something valuable: better information for making decisions.
Empathy Doesn't Mean Avoiding Difficult Decisions
Empathy is another leadership skill that can be misunderstood.
Some people associate it with being agreeable, accommodating every request, or avoiding difficult conversations.
But empathy in leadership isn’t about making everyone comfortable. It is about understanding people’s circumstances well enough to make informed and fair decisions.
Consider a team struggling to meet an important deadline.
A leader could respond by demanding additional effort and emphasizing the importance of the commitment. That might create short-term urgency, but it doesn’t necessarily address the underlying problem.
Perhaps the team is dealing with unclear requirements, repeated changes, unrealistic estimates, or dependencies outside its control.
Understanding these constraints doesn’t remove accountability. It makes accountability more meaningful.
I see empathy and accountability as complementary rather than competing qualities.
A leader can acknowledge that a team is facing genuine difficulties while still expecting clear ownership, transparent communication, and a credible recovery plan.
In practice, this means asking better questions before assigning responsibility.
What is preventing progress? Which constraints can the team influence? What support is required? What commitments are realistic given the current situation?
The objective is not to excuse poor performance. It is to understand the conditions affecting performance and address them constructively.
Empathy helps leaders understand the problem. Accountability ensures that understanding leads to action.
Alignment Matters More Than Agreement
One of the more difficult aspects of leading complex programs is that not everyone will agree with every decision.
A testing team may prefer additional validation time. Engineering may want to protect the technical design. Business stakeholders may need to meet a customer commitment.
Waiting for complete agreement can delay decisions indefinitely.
Strong leadership isn’t necessarily about making everyone agree. It is about helping people understand why a particular decision is being made and what it means for their work.
That requires clarity around three things:
- The shared outcome
Teams need to understand what the program is ultimately trying to achieve. Is the immediate priority a safe and reliable release, a critical customer commitment, or resolving a technical dependency that threatens future development?
Without a shared outcome, each team naturally prioritizes its own deliverables.
- The trade-offs
Every significant decision involves consequences. Accelerating a timeline may increase delivery risk. Adding functionality may require additional testing. Changing a technical approach may affect cost or long-term maintainability.
Making these trade-offs visible allows stakeholders to evaluate decisions with a common understanding of their implications.
- Ownership and communication
Once a decision is made, teams need clarity about responsibilities, dependencies, and next steps.
Regular communication should focus on what has changed, which risks remain, and where decisions or support are needed. More meetings don’t necessarily create better alignment. Clearer conversations do.
When people understand the reasoning behind a decision, they are better positioned to support its execution, even if it wasn’t their preferred option.
What Complex Programs Have Taught Me About Leadership
The automotive industry provides a useful environment for understanding leadership because technical complexity, customer expectations, and delivery constraints are closely connected.
But the lessons extend well beyond automotive engineering.
A product leader coordinating design, engineering, and business teams faces similar challenges. So does a technology leader managing a transformation initiative or a program manager overseeing multiple interdependent projects.
Across these environments, I believe five leadership principles are especially valuable:
- Understand before directing. When a problem emerges, establish the facts and listen to the people closest to the work before deciding on a response.
- Make dependencies visible. A decision that benefits one team may create challenges for another. Understanding the wider system helps prevent local improvements from becoming program-level problems.
- Communicate uncertainty early. Stakeholders don’t always need immediate certainty. They need an accurate understanding of the situation, available options, and potential consequences.
- Balance empathy with ownership. Recognize the constraints people face while maintaining clear expectations around commitments and outcomes.
- Keep the customer outcome in focus. Technical excellence matters, but decisions should ultimately support the value, reliability, and experience the product is expected to deliver.
These principles sound straightforward. Applying them consistently becomes much harder when timelines are slipping, stakeholders are concerned, and teams are under pressure.
That is precisely when leadership matters most.
The Real Measure of Technical Leadership
Early in a technical career, professional growth often comes from becoming better at solving increasingly difficult problems.
You learn new technologies, develop deeper expertise, and become someone others approach for answers.
But as responsibilities expand, the nature of the challenge changes.
You are no longer responsible only for the quality of your own decisions. You are also responsible for creating the conditions in which different teams can make good decisions together.
That requires technical understanding, certainly. But it also requires patience, empathy, judgment, and the ability to communicate clearly when circumstances are uncertain.
I’ve come to see leadership as the ability to bring clarity when complexity begins to overwhelm a team.
Sometimes that means making a difficult decision. Sometimes it means asking a question nobody has considered. And sometimes it means listening long enough to recognize that the problem everyone is trying to solve isn’t the real problem at all.
Technical expertise helps leaders understand what needs to be built. People skills help them bring everyone together to build it successfully.
And perhaps that’s the question worth asking when evaluating leadership in any complex program:
When things become difficult, does the leader simply push harder for delivery, or help the team find a better way forward?
