- TechParadox.dev
- Posts
- Flex Engineers
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."
Every project team has that person. You know, who dominates the meetings with phrases like “This will be easy”, “Microservice will fix everything” or “We should follow this cutting-edge tech”. They walk into a room with big ideas and even bigger confidence.
On paper, they sound impressive. In practice they tend to complicate the simplest things, throw over engineered solutions and confidently reject any ideas that aren’t their own. These are Flex Engineers - ones who flex more than they fix.
They speak first and loudest in meetings, dominate technical discussions, and often influence decisions despite having only surface-level knowledge.
And here’s the actual problem - in most organization (specially big ones), these voices often win.
The question is why does this happen, and what can we do about it?
Table of Contents
What Makes a Flex Engineer
These team members aren’t necessarily bad people; they’re products of certain workplace dynamics and human psychology. Here’s what you might notice:
Use lots of technical terms, often without proper context.
Carry bucket of their fav programming language, frameworks, tools, or pattern they throw everywhere.
Speak with absolute certainty, even on complex topics with little to none context.
Use phrases like “This is industry standard” to divert the discussion.
Quick to take credit when things go well but distance themselves from failures.
Rarely ask questions - they already know (everything)
Not all vocals engineers are flexers, of course, but if someone exceeds their willingness to listen, it’s clearly a red flag.
Confidence-Competence Paradox
In most engineering teams, it’s not always best idea/solution that makes it to production , but most of times it’s the best delivered idea/solution. That’s where the Confidence-Competence Paradox comes into play:
Confidence:
Flex engineer speaks with unwavering certainly, using buzzwords that make stakeholders nod without fully understanding.
Competence:
Skilled engineer knows the trade-offs, the risks and the messy reality (& even timelines). So, they say, “It depends”.
And that it depends? It sounds weak in a conversation, even through it’s usually the right answer.
This misalignment between confidence and competence can lead to misguided decisions that affect the long-term health of a project.
Dunning-Kruger on Dev Duty
Dunning-Kruger effect has a VIP pass to most tech teams. It's especially visible in how Flex Engineers interact with stakeholders.
Stakeholders love certainty. They often gravitate towards the engineer who seems the most confident, mistaking self-assurance for expertise.
Flex Engineers thrive here. They present polished, oversimplified answers that make stakeholders feel secure.
In contrary, Season Engineer’s "It depends" response doesn't inspire as much confidence as "Trust me, I've done this before."
The Illusion of Control: Overconfident engineers often promise a straightforward solution, creating an illusion of control over complex systems. Stakeholders find comfort in that simplicity, despite the risk of overshooting or missing essential nuances.
How Flex Engineers Impact Projects
Flex engineering isn’t just an annoyance but it’s dangerous. Here’s how they derail projects:
Overengineering: Proposing architectures more complex than they need to be ("Why have one service when you can have seven microservices talking via gRPC?").
Refactor Fever: Constantly pushing to rewrite stable components just to "modernize" them.
Decision Hijacking: Steering meetings toward their pet solutions, regardless of context.
Scope Creep: Divert agreed scope of project, or add more complexity by giving wrong perception to business stakeholders.
In tech, Confidence is 90% of the job. Rest 10% is just figuring out what you Confidently got wrong.
The solution isn't to silence confident voices but to create systems that evaluate ideas based on merit rather than delivery style.
Ask for trade-offs:
Politely but firmly ask, "What are the trade-offs of this solution?" Flex engineers often stumble here.
Bring data:
Back up concerns with data, metrics, or examples. It shifts the conversation from opinions to facts.
Encourage quieter voices:
Proactively ask other engineers for their input, especially those who tend to stay quiet.
Educate stakeholders:
Help product and business teams understand that "confident" doesn’t mean "correct." Let right people make right decision.
Use written communication channels:
Alongside meetings to give people time to formulate their thoughts.
Lead by example:
Model thoughtful decision-making. Show that caution and consideration are strengths, not weaknesses.
Advice for Quieter Team Members
Not everyone is wired to speak loudly in meetings, but your insights are valuable and often necessary. Consider doing these —
Prepare Talking Points: Before meetings, jot down key insights or questions. Preparation builds confidence.
Ask Clarifying Questions: You don’t always need to present a solution. Asking clarifying questions sometimes shift discussion to right direction.
Leverage Asynchronous Channels: If you’re not comfortable in live discussions, share your thoughts in documents, Slack, or comments after the fact.
Find Allies: A supportive teammate or manager can amplify your points and help you build confidence over time.
Moving Forward
The loudest engineer in the room isn’t always the smartest - sometimes, they’re just the best at looking smart. And while confidence has its place, in engineering, it’s competence that builds reliable systems.
Next time if you ever find yourself quietly questioning a "bold" proposal, trust your instincts. Chances are, the system will too.
Until next time, Cheers
Have you worked with a Flex Engineer? Or maybe caught yourself flexing a little too hard?
We’d love to hear your stories (anonymous flexing welcome)! Jump into the conversation with us on on LinkedIn and 𝕏
And if you find this newsletter useful and you want to contribute to sustain and evolve it, please think to "buy a coffee"
Reply