Did We Expand the Engineering Role Too Fast? Technical Excellence vs. Communication Skills

eng_director_luis · March 14, 2026, 8:40am

Over the past five years at my company, I’ve watched the definition of “good engineer” undergo a radical transformation. What used to be straightforward—write clean code, solve technical problems, deliver on time—has expanded into something much more demanding and, honestly, much more ambiguous.

Engineers on my team are now expected to not just build systems, but to articulate why those systems matter to the business. They need to mentor junior developers, communicate effectively across departments, translate technical decisions into ROI metrics, and somehow maintain their technical edge while doing all of this. I’ve seen brilliant architects struggle in performance reviews because they can’t “tell the story” of their work to non-technical stakeholders.

The Business Translation Tax

The most jarring change has been the expectation that engineers translate every technical decision into business impact. One of my senior engineers recently rebuilt our data pipeline, cutting processing time by 60% and reducing infrastructure costs significantly. Technically brilliant work. But during his promotion review, the feedback was that he didn’t effectively communicate the business value to leadership. He built something transformative but couldn’t sell it internally.

Is this fair? On one hand, I understand that engineering doesn’t exist in a vacuum. Our work needs to serve business objectives, and being able to explain that connection seems reasonable. On the other hand, are we asking people who chose engineering specifically because they preferred working with systems over politics to suddenly become evangelists?

The Depth vs. Breadth Dilemma

I’m watching engineers who used to go incredibly deep on technical problems now spending 40% of their time in meetings, writing documentation for non-technical audiences, and mentoring. The communication skills are valuable, no question. But I’m concerned we’re creating generalists when what we actually need are specialists who can go deep on hard technical problems.

At Intel and Adobe, I saw the pendulum swing back and forth on this. When we emphasized breadth, we lost technical depth and made costly architectural mistakes. When we emphasized depth, we built brilliant systems that nobody understood or adopted. There’s a balance, but I’m not sure we’ve found it yet.

Real Impact on My Team

Three examples from my current team:

Engineer A: Exceptional technical skills, can solve problems that stump everyone else, but struggles with presenting to executives. Recently passed over for promotion despite being our most valuable technical contributor.

Engineer B: Good technically, excellent communicator, great at aligning work with business objectives. Got promoted, but now spends so much time in meetings that their technical skills are atrophying.

Engineer C: Trying to do both, spreading themselves thin, showing signs of burnout from the constant context switching between deep technical work and communication/mentoring responsibilities.

None of these outcomes feel optimal.

The Real Question

Here’s what I’m struggling with: Did this shift happen too fast?

Are we asking engineers to evolve faster than is realistic or sustainable? The engineers who’ve been in the industry for 10+ years chose this career path partly because it valued technical depth over soft skills. Now we’re changing the rules mid-career and wondering why they’re struggling to adapt.

I believe in the value of communication, mentoring, and business alignment. I’ve built my career on bridging technical and business worlds. But I’m questioning whether we’re building better engineering leaders or just diluting technical excellence by spreading people too thin across too many competencies.

What’s your experience? Are we seeing engineers evolve into more complete professionals, or are we creating an impossible standard that leaves everyone feeling inadequate?

vp_eng_keisha · March 14, 2026, 8:40am

Luis, I hear your concerns, but I’m going to respectfully push back: this shift didn’t happen too fast—if anything, it’s been overdue.

For years, engineering operated in a bubble where we could throw solutions over the wall and expect others to figure out adoption, business value, and cross-functional alignment. That model was fundamentally broken, and it led to brilliant technical work that went unused, misaligned priorities that burned resources, and engineering teams that were disconnected from the actual problems the business needed to solve.

The Cost of the Old Model

Last year at my company, we almost made a catastrophic architectural decision that would have cost us months of work and significant technical debt. The engineers pushing for it were technically brilliant—they’d done deep research, built prototypes, and could articulate the technical benefits clearly.

But they couldn’t answer basic questions from our product and sales teams: How does this improve customer experience? What’s the migration path? How do we communicate this change to enterprise clients?

It was our engineering lead—someone with both technical depth AND communication skills—who uncovered that the proposed architecture would break a critical workflow that 40% of our customers relied on. She only caught it because she regularly talked to customer success and actually understood how our product was being used.

That’s not diluting technical excellence. That’s enhancing it with context.

The Best Technical Decisions Come from Understanding Context

Here’s what I’ve learned from scaling organizations: the engineers who understand business context make better technical decisions. Not just more aligned decisions—actually better technical decisions.

When you understand the business model, you architect differently. When you talk to customers, you prioritize differently. When you can communicate with sales and support, you build more robust systems because you understand the actual failure modes, not just the theoretical ones.

The engineers who resist this evolution often frame it as “I just want to code,” but what they’re really saying is “I don’t want to be accountable for whether what I build actually solves the right problem.” That’s not sustainable, and frankly, it’s not professional.

This Is Evolution, Not Addition

You mentioned Engineer A who got passed over for promotion despite exceptional technical skills. I’d ask: were they really solving the most important problems, or just the problems they found technically interesting?

Engineer B spending too much time in meetings—that’s a management problem, not a communication problem. Organizations need to protect deep work time while still requiring business alignment. It’s not either/or.

Engineer C burning out from context switching—again, that’s about how work is structured, not about whether engineers should communicate.

The Real Question

The question isn’t “did this shift happen too fast?” It’s “how do we support engineers through this evolution while maintaining technical excellence?”

The answer isn’t to retreat back to siloed engineering. It’s to:

Build communication skills alongside technical skills from day one
Protect deep work time while requiring business alignment
Value both specialist and generalist career paths
Hold organizations accountable for developing these skills, not just demanding them

The world changed. Software isn’t a support function anymore—it’s the business. Engineers who embrace this have more impact, make better decisions, and frankly, have more interesting careers. Those who resist will increasingly find themselves solving the wrong problems brilliantly.

We’re not asking too much. We’re asking what’s always been necessary—we just didn’t realize it until the cost of misalignment became too high to ignore.

maya_builds · March 14, 2026, 8:41am

This conversation hits close to home because designers have been living in this “expanded role” space for years, and watching engineers grapple with it now feels both familiar and a little validating.

When my startup failed, one of the painful lessons was that I’d built something technically impressive (for a designer—nice animations, thoughtful interactions, clean component system) but completely missed what users actually needed. I could design beautiful interfaces, but I couldn’t articulate business value, didn’t understand our customers deeply enough, and struggled to translate design decisions into terms that investors or enterprise buyers cared about.

I thought I was doing great design work. I was just doing it in the wrong direction.

It’s Not About Doing More—It’s About Doing the Right Things

Luis, I really empathize with your three engineers. But I wonder if the framing is off. It’s not that they need to do more things—it’s that the definition of doing their job well has evolved.

Your Engineer A who’s technically brilliant but struggles with communication: are they really being asked to become evangelists? Or are they being asked to ensure that their technical brilliance is actually solving problems that matter to someone other than themselves?

When I was deep in startup mode, I’d sometimes build design systems or components that were technically impressive but totally disconnected from what our small team actually needed. I thought I was doing my job well. I wasn’t—I was indulging my interests while the business struggled.

Context Switching vs. Context Understanding

The burnout concern for Engineer C is real, and I’ve definitely felt it. But I’ve noticed something: when I think of cross-functional communication as “context switching,” it feels exhausting. When I think of it as “context understanding,” it becomes part of doing good work.

Understanding how sales talks to customers isn’t a distraction from design work—it makes my design work better because I understand what questions people actually ask and what concerns they have.

Talking to engineering about implementation constraints isn’t taking me away from design—it’s preventing me from designing things that can’t be built or maintained.

The shift isn’t about becoming a generalist. It’s about being a specialist who operates with awareness of the system they’re working in.

What If We Reframe This?

Instead of “engineers now need communication skills IN ADDITION TO technical skills,” what if we said “great engineering has always included understanding the problem space, the users, and the business context—we just used to let engineers get away with skipping those parts”?

Your Engineer B who’s great at communication but their technical skills are atrophying—that’s an organizational failure to protect deep work time, not proof that communication and technical excellence are incompatible.

At Confluence, we have “maker time” blocks where designers and engineers don’t take meetings. We have clear swim lanes for who owns communication with stakeholders. We invest in tools that reduce documentation burden. The goal is to support both, not sacrifice one for the other.

The Real Cost

You mentioned concerns about diluting technical depth. I get it. But here’s the other side: how much technical depth was wasted building the wrong things? How many brilliant solutions solved problems nobody had? How much architectural elegance was spent on systems that didn’t fit the actual use case?

Keisha’s right that software is the business now, not a support function. For designers, the web made design central to product experience, and we had to evolve. For engineers, digital transformation made code central to business strategy, and the expectations evolved accordingly.

It’s not that the shift happened too fast. It’s that it happened at all, and now we’re catching up to a new reality.

The question isn’t whether to go back—that’s not an option. The question is how we help people navigate this evolution without burning them out, which means organizations investing in development, protecting deep work time, and being honest about what the job actually requires now.

product_david · March 14, 2026, 8:42am

Coming from the product side, I’ll be direct: engineers who can’t communicate create massive, expensive problems that someone else has to clean up.

I’ve worked with brilliant engineers who built exactly what I asked for—and completely the wrong product. Three times. Same engineer, three different projects. Each time, months of work down the drain not because of technical failures but because we never aligned on what problem we were actually solving.

The issue wasn’t technical capability. It was the inability to ask questions, push back on requirements, or articulate why the proposed solution wouldn’t work for the use case. The mindset was “tell me what to build, I’ll build it” instead of “let’s figure out what problem we’re solving.”

It’s Not Technical vs. Communication—It’s Depth vs. Breadth

Luis, I think you’re framing this as an either/or when it’s really about different career paths that should both be valued.

Depth path: Deep technical specialists who solve hard problems. They need enough communication skills to collaborate with their immediate team and explain their work, but they’re not expected to present to executives or evangelize.

Breadth path: Technical leaders who translate between engineering and business. Strong technical foundation but not cutting-edge. Excellent at communication, strategy, and alignment.

The problem isn’t that we’re asking engineers to do both. It’s that we’re promoting people on the depth path into roles that require breadth, then acting surprised when they struggle.

Your Engineer A sounds like a depth person being evaluated by breadth criteria. That’s a mismatch, not a deficiency.

The Real Cost of Poor Communication

Let me give you a concrete example from last quarter.

We had an engineer build a feature that technically worked perfectly but was completely unusable for our enterprise customers because it required admin-level permissions that most users don’t have. Months of work, beautiful code, thoughtfully architected—completely useless.

Why? Because the engineer never asked “who will actually use this?” or “what permissions do they typically have?” They took the spec, built it, and shipped it. That’s not technical excellence. That’s building in a vacuum.

Compare that to another engineer who, halfway through a project, came back and said “I think we’re solving the wrong problem. Based on customer support tickets, users aren’t asking for feature X—they’re struggling with workflow Y. Can we pivot?” That engineer saved us months and delivered something that customers actually adopted.

Both had strong technical skills. One understood context. Guess which one had more impact?

Framework: The Communication Floor

Here’s how I think about it: there’s a minimum communication floor that everyone needs, regardless of role:

Baseline (required for all engineers):

Articulate technical decisions and tradeoffs clearly to other engineers
Ask clarifying questions about requirements and use cases
Push back when specs don’t make sense or miss edge cases
Collaborate effectively in cross-functional teams
Document work so others can understand and maintain it

Advanced (required for senior+ and leadership track):

Translate technical decisions into business impact
Present to executives and stakeholders
Mentor and guide other engineers
Drive alignment across teams
Advocate for technical investments

The baseline isn’t “becoming an evangelist.” It’s being a professional who operates in a collaborative environment. If someone can’t meet the baseline, they’re not a senior engineer—they’re a talented individual contributor who needs support.

What Organizations Need to Do

Maya’s right that this is partly an organizational problem. Companies that expect both depth AND breadth without supporting either are setting people up to fail.

Here’s what actually works:

Clear career paths: Depth (staff engineer, principal) vs breadth (manager, director)
Protected focus time: No meetings during core hours for deep work
Communication training: Don’t just demand it, teach it
Realistic scope: Stop promoting depth people into breadth roles

But here’s the thing: even on the pure depth path, you still need that baseline. You can’t build the right thing if you can’t understand the problem space. You can’t be effective if you can’t collaborate. That’s not asking too much—that’s asking for professional competence.

The shift happened because software became central to business strategy. The engineers who evolve with that reality will have more impact. Those who don’t will increasingly find themselves solving problems that don’t matter.

cto_michelle · March 14, 2026, 8:42am

Luis, this is an important conversation, and I appreciate you starting it. From the CTO seat, I’ve watched this evolution play out across the industry, and I want to offer both historical context and a path forward.

The Role Expanded Because the World Changed

When I started my career at Microsoft in the late '90s, software was a department. We built tools that supported business operations. Engineering decisions were technical decisions, made by technical people, with limited business impact.

Today, software IS the business. For most companies, engineering decisions directly determine competitive position, revenue potential, and strategic direction. Architecture choices affect go-to-market strategy. Technical debt impacts product velocity and time-to-market. Infrastructure decisions determine unit economics.

The role didn’t expand arbitrarily. It expanded because the scope and impact of what we build fundamentally changed. To ignore business context while making technical decisions that shape business outcomes would be negligent, not specialized.

The Uncomfortable Truth

Here’s what I see from the C-suite: Engineers who resist developing business context and communication skills are choosing to limit their own impact.

Your Engineer A—technically exceptional but struggles with communication—might be your most valuable technical contributor today. But are they solving the most important problems? Are they architecting for the actual constraints and opportunities of the business? Or are they brilliantly solving problems they find intellectually interesting?

I’ve had this conversation too many times: “Why didn’t we prioritize the migration project?” Because the engineer championing it couldn’t articulate business value beyond “the current architecture is old.” When the CFO asks “what revenue does this enable?” or “what costs does this reduce?” answering “it’s better architecture” isn’t sufficient.

That’s not unfair. That’s accountability.

Two Critical Clarifications

First: Organizations must invest, not just demand. David’s framework is spot-on—there’s a baseline that everyone needs and an advanced level for leadership tracks. But companies can’t just raise the bar and expect people to clear it without support.

We need to provide:

Communication and presentation training
Clear career paths (depth vs breadth)
Mentorship and coaching
Protected time for deep technical work
Frameworks for translating technical decisions to business impact

At my company, we run quarterly workshops on technical storytelling, maintain strict meeting-free afternoons for engineering, and have both IC and management tracks that pay equivalently. That’s not optional—it’s how you support this evolution.

Second: The “depth vs breadth” framing can be a trap. The best technical decisions I’ve seen came from engineers who went deep on the technology AND understood business context. They’re not mutually exclusive—often they’re mutually reinforcing.

Understanding customer workflows helps you architect better systems. Knowing business constraints helps you make smarter tradeoff decisions. Communicating effectively helps you get buy-in for technical investments that actually matter.

The Generation Gap Challenge

You mentioned engineers who’ve been in the industry 10+ years feeling like the rules changed mid-career. That’s legitimate, and we need to acknowledge it.

But here’s the reality: the rules DID change because the industry changed. We can be empathetic about that while also being clear that adaptation isn’t optional.

I’ve been in tech for 25 years. I learned mainframes. I learned client-server. I learned web architecture, mobile, cloud, microservices, containers. Every shift felt disruptive. Every time, some people adapted and some people got left behind.

This communication/business-context shift is another inflection point. It’s uncomfortable, especially for those who chose engineering specifically to avoid communication-heavy roles. But the alternative—staying in a bubble while the business makes decisions without technical input—is worse for everyone.

The Path Forward: How We Support This Transition

Instead of debating whether the shift happened too fast, let’s focus on how we support engineers through it:

Explicit skill development: Make communication and business acumen part of professional development, with training and resources
Role clarity: Be honest about what different roles require and stop promoting people into roles they’re not suited for
Psychological safety: Create space to acknowledge this is hard and some people are struggling
Resource allocation: Protect deep work time and provide communication support for those who need it
Measurement: Evaluate both technical excellence AND business impact, with clear criteria for each

The engineers who embrace this evolution—who develop both technical depth and business context—will be the most impactful contributors and leaders. Those who resist will find themselves increasingly marginalized, solving problems that don’t move the business forward.

We’re not asking engineers to become salespeople. We’re asking them to be professionals who understand the context in which they work and can articulate the value they create.

That’s not too much. That’s the job now. The question is how we help people rise to meet it.