When Everyone avoid the technical layer, the tech lead becomes the translation department.
The customer asks why a flow behaves differently after the latest release.
It is not a trick question. Nobody is asking for the internals of Laravel’s service container or the exact SQL plan behind a slow report. The customer only wants to understand the product they are paying for: why this status changed, why the API returned that response, why one edge case passed testing but another one failed.
Then the room goes quiet.
The BA waits because the question sounds technical. The QA waits because the question is not in the test script. The PM waits because the answer might affect timeline, scope or commitment.
So the tech lead talks.
Again.
That is the part people miss when they say technical leadership is mostly communication. They are not wrong. They are just skipping the ugly middle layer where every role around the tech lead avoids learning enough technical context to communicate responsibly.
At that point, the tech lead is no longer leading the technical side.
The tech lead is translating the company.
This Is Not About Making Everyone a Developer
Let me get the obvious defense out of the way.
No, the BA does not need to write code. QA does not need to design the architecture. The PM does not need to know which service owns which database table. A delivery team is not supposed to become eight developers wearing different job titles.
That would be silly, and probably expensive.
But working in IT should mean something.
If your job touches software requirements, testing, customer commitments or delivery planning, you need enough technical literacy to understand the shape of the thing being delivered. Not every class. Not every deployment script. Enough to know when a customer is asking about business behavior, system behavior or a promise nobody should make yet.
That is the line.
The problem starts when everyone treats “technical” as a room they are allowed to leave.
A BA can say, “That is technical.”
QA can say, “That is for dev.”
The PM can say, “Can the tech lead explain?”
Each sentence sounds harmless. Together, they create a delivery model where one person must absorb every unclear requirement, every testing gap, every customer concern and every risky promise before it becomes embarrassing.
That person is usually the tech lead.
The Translation Work Is Invisible Until It Fails
The tech lead does not only answer technical questions.
The tech lead converts vague business language into system impact. The tech lead converts system constraints into customer language. The tech lead converts QA findings into risk. The tech lead converts PM timelines into trade-offs. The tech lead converts customer frustration into something the team can actually act on.
Nobody calls this architecture.
It is.
Not the diagram kind. The social kind. The part where a system survives because one person understands how the technical truth should travel through non-technical conversations.
The work looks like this:
- customer says “minor change”
- BA writes “update validation”
- PM hears “small task”
- QA expects one happy-path test
- tech lead sees an auth rule, migration concern, backward compatibility issue and release risk
That gap is not a communication issue. It is a technical literacy issue hiding inside delivery process.
And because the tech lead can usually explain it, the organization thinks the process is working.
It is not working. It is being rescued.
There is a difference.
BA, QA and PM Have Technical Responsibilities Too
The easiest way to keep a tech lead overloaded is to define every other role too narrowly.
The BA only writes requirements.
QA only verifies tickets.
The PM only manages timeline.
Fine on paper. Dangerous in real delivery.
In software, requirements are never purely business. A requirement changes because a system has state, permissions, data history, integrations and failure modes. If the BA cannot ask how the requirement affects those things, the requirement is not complete. It is just confident.
Testing is never only about clicking through steps. QA is supposed to protect the customer from hidden behavior. That means asking what could break, where state can become inconsistent, which roles should be blocked and which previous behavior must still hold. If QA does not understand the system enough to ask those questions, testing becomes ceremony.
Planning is never only about dates. A PM does not need to estimate the code, but they do need to understand why a two-word change can touch authentication, reporting, deployment timing or data migration. If the PM cannot hold that conversation, the plan becomes a beautiful calendar attached to a risky guess.
These roles do not need to become engineers.
They need to stop outsourcing curiosity.
The Tech Lead Tax
Every missing bit of technical curiosity becomes tech lead tax.
You pay it before the meeting when someone asks, “Can you just brief me quickly?”
You pay it during the meeting when the customer asks a follow-up and every face turns toward you.
You pay it after the meeting when the notes are too vague, the action item is wrong or the customer heard a commitment you would never have made if someone had asked you first.
Then you pay it again in implementation.
The requirement has hidden assumptions, the test cases miss the risky path and the timeline has no room for investigation. By the time implementation starts, the customer expects behavior nobody validated and the developer is asking why the ticket says one thing while the real system says another.
Everyone is busy. That part is true.
But the tech lead becomes busy in a different way. Not just with work, but with interpretation. You are expected to understand what the customer meant, what the BA wrote, what QA missed, what the PM promised and what the system can actually do.
That is not leadership.
That is being the adapter between roles that stopped learning each other’s language.
Customer Calls Reveal the Real Team Design
Internal meetings can hide role weakness for months.
Customer calls expose it in minutes.
A customer does not ask questions according to your job descriptions. They ask according to their pain. One question can involve requirement intent, current behavior, data correctness, release timing and support risk.
That is why a healthy team should not collapse into one voice every time the question becomes technical.
The BA should be able to answer intent.
QA should be able to answer what was verified and what was not.
The PM should be able to answer commitment and sequencing.
The tech lead should answer architecture, constraints and risk.
Notice the difference. The tech lead still plays a central role. I am not arguing for technical leads to disappear from customer conversations. I am arguing that the whole technical burden should not arrive at the tech lead’s chair just because everyone else found a polite way to step backward.
If only one person can speak when the customer asks about behavior, the customer is not seeing a delivery team.
They are seeing a dependency.
The Minimum Technical Literacy for Delivery Roles
Here is the section I wish more teams used as an actual checklist.
Not a performance review weapon. Not a certification exercise. Just a practical line between “I work around software” and “I understand enough to help deliver it.”
A BA should be able to ask:
- what state changes when this requirement is accepted?
- which roles, permissions or customer types behave differently?
- what old behavior must remain unchanged?
- does this affect an integration, report or downstream process?
- what ambiguity should we resolve before dev starts?
QA should be able to ask:
- which failure path matters most?
- what data setup proves the rule actually works?
- which previous behavior could regress?
- where does the system store the result?
- what would make this pass testing but fail for the customer?
A PM should be able to ask:
- what part needs investigation before a date is promised?
- which scope option reduces risk?
- what dependency can block release?
- is this a UI change, data change, API change or behavior change?
- what trade-off are we asking the customer to accept?
A tech lead should be able to ask:
- what decision does each role need from me?
- what can I teach once so I do not explain it forever?
- which recurring question should become documentation?
- where is the team hiding uncertainty behind my availability?
That last question is painful.
Good.
Pain is often where the real process diagram lives.
Stop Calling It Support
When the tech lead explains every technical thing to every role, people call it support.
“Can you support the meeting?”
“Can you support QA?”
“Can you support the BA?”
“Can you support PM on this customer answer?”
Support is a nice word. Too nice, sometimes. It makes a structural dependency sound like teamwork.
Some support is healthy. A tech lead should unblock people, clarify risk and help others understand the system. I do not want a team where everyone is afraid to ask technical questions because the lead is keeping score.
But support should reduce future dependency.
If I explain the same concept three times and the fourth meeting still needs me to say the same thing, that is no longer support. That is subscription-based thinking with my calendar as the payment method.
The standard should be simple:
- First time, explain.
- Second time, explain and document.
- Third time, ask the role owner to explain it back.
- Fourth time, fix the ownership gap.
This is not harsh. It is how teams grow.
If every answer stays attached to the tech lead, everyone else remains safe from learning.
How I Would Say It Without Ranting
The rant version is easy.
“Why does everyone work in IT but nobody wants to understand the system?”
Accurate, maybe. Useful, not always.
The better version is colder and harder to dismiss:
“Right now, too many customer-facing technical explanations depend on me. I can own architecture and technical risk, but BA, QA and PM need enough system understanding to handle their part of the conversation. Otherwise every requirement gap, testing gap and commitment risk routes through the tech lead.”
Then make the ask specific.
Use this format:
- BA ownership: requirements must include behavior, affected roles, edge cases and open technical questions.
- QA ownership: test planning must include risk paths, regression areas and data conditions.
- PM ownership: customer commitments must separate confirmed facts from items that need technical validation.
- Tech lead ownership: architecture, risk, trade-offs and system constraints.
- Team improvement: repeated technical questions become shared notes, not recurring dependence.
That gives people somewhere to stand.
It also removes the easiest escape hatch: “But I am not technical.”
You do not need to be a developer to ask better questions.
The Real Standard
A delivery team does not become technical because it sits near developers.
It becomes technical when every role accepts that software has behavior, constraints, state and risk. The tech lead can carry the deepest understanding, but the rest of the team must carry enough to stop turning every customer question into a rescue mission.
That is the standard I want.
Not everyone coding.
Everyone learning enough that the tech lead is not the only adult in the technical conversation.
