When Engineering team dismiss your technical research — What you should do
How to turn this negativity confrontation into an opportunity and build up rapport with your developers
This article is also posted on my Medium
How it all started
Last Thursday brought an intriguing challenge, the Tech lead in my team suddenly call me on the spot (during a team stand-up session) and asked me to go and find out what is the current implementation of a legacy solution in the codebase. Now, a bit of a context for readers, while my official role does not include the title Technical Business Analysis (just BA), my extensive background in passion projects and years of self-directed programming made this assignment feel like a natural fit. I embraced the opportunity enthusiastically, so I am happily proceed with the task.
The Question of Role Boundaries
Of course someone might say that this is a particular anti-pattern because that sort of work should be done by a developer, isn’t it? And indeed, some of the other developers in the team have also expressed such concern on the spot. They raised the question of whether that task should be assigned to me, a BA on the team while the task itself is quite technical.
From my perspective, it’s not a particular challenge because I have a background in Python and JavaScript coding. Aside from knowledge of coding language, I would rate myself as a junior to mid-level developer because I understand how programming concept, abstract work having building out data pipeline and web application myself. In my own experience, I even develop my library in Python, and C++ before (talking about Classes in Object Oriented Programming). So even-though the code base of our team is a Java code base. it’s not a problem for me at all.
Taking Action
Rather than rush into analysis, I developed a systematic approach that combined traditional research methodologies with cutting-edge AI assistance.
My Research Tools
I had several powerful resources at my disposal:
Direct access to the codebase
AI-powered code analysis tools that could help me investigate specific implementation details
Google’s Gemini for deep research, allowing me to explore how similar implementations work across other platforms using the same technology stack
I was confident this multi-layered approach virtually guaranteed robust, defensible findings that would yield high-quality results that couldn’t be dismissed easily.
The Stern Dismissal
When I presented my research findings to the team, I expected acknowledgment — perhaps even praise for the thoroughness of my investigation. Instead, the reality was quite different.
The developers simply stated: “Well, you didn’t need to do all of this. And much of this isn’t correct.” They said it directly, without hesitation.
What do you do in that moment? They can make you feel foolish, like you’re trying to be a show-off. It’s understandable to feel embarrassed, experiencing that cognitive dissonance where you know you put in solid work and followed sound methodology, yet your contribution is being dismissed.
Understanding The Developer Perspective
In many cases, the developers themselves are just being professionally cautious. It is natural for developers (an engineering-oriented job) to exercise healthy skepticism toward research they haven’t personally verified. And they migh have not had a chance to actually look into the code base themselves in those particular implementation yet. Their dismissal often reflects professional prudence rather than personal criticism
So, you have to be open-minded and put yourself in their shoes, because they are the ones who eventually will be looking at the current implementation, and try to design a solution for the future state. Bearing such responsibility, they have to be 100% assured about what the current implementation is in the first place. It’s would be entirely unfair for them to evaluate my research without having a look for themselves first.
The AI Knowledge Gap
The second reason is that developers might not all be up to date with the latest AI developments. In fact, many engineering professionals have not even fully grasped the transformative capabilities of modern AI research tools. A lot of deep research capabilities have been made available to the public recently. For example, notable tools like Notebook LM by Google, Gemini’s deep research capability, or OpenAI’s ChatGPT which now also has a deep research tool.
There are a lot of things that previously were really hard to be grasped by non-tech people that can now be easily accessible everywhere, and the research quality and credibility is surprisingly high with the level of depth and cited sources. And I can sense that this dramatically shift in term of easiness to access such high quality research would be easily create confusion from developer’s perspective. They would no doubt asking themselves the question which would hard for them to reconcile: why do I know all of this without a traditional programming background?
Tasks that once required deep programming expertise are now accessible to dedicated non-developers, often producing surprisingly sophisticated results. Developers may struggle to reconcile this reality with their assumptions about technical competency boundaries. I have even writte an article about this here:
Think of this as a Learning Experience
The third point: just treat this as a learning experience. It’s not about being right in the eyes of the developers in the team. It’s more about personal growth and how you handle communication. The most productive mindset treats these challenging moments as invaluable learning laboratories. Success shouldn’t be measured by immediate team validation but rather by personal development and enhanced communication capabilities
Consider the genuine value you extracted from conducting independent codebase research. The knowledge gained, research methodologies mastered, and problem-solving approaches developed represent tangible professional assets, regardless of initial reception.
So don’t be offended by their dismissal. This is all a learning experience, and you can use this opportunity to see and understand how developers feel about your own technical capabilities. And then you can go back and evaluate your future approach when something similar comes up in the future. Remember: Things in Tech moving really fast so most of arguments or conflict you have in an Agile team would not be matter much within two — three months down the road. Do not be upset against someone who might have an opposite or adverse opinion about your findings, as new things or new technology would render these arguments meaningless. Instead of focusing on making you looks or sound correct, take a tangent and note this down as a checkpoint in your memory lane
So What did I do in response (and I think can be a lesson for you as well if you get into similar situation)
When faced with dismissal on the spot, here’s exactly what I did — and what I believe you should do if you find yourself in a similar situation:
1. Acknowledge and Agree with the Engineer
The first step is to gracefully agree with their concerns (and make sure this come our clear with your words choice). I made it explicitly clear that my research had specific limitations:
A) This was a BA’s research, not comprehensive technical documentation
B) My scope was intentionally limited — I focused only on specific parts of the solution, not the entire system or its related components
This approach accomplishes two critical things:
Builds credibility by openly acknowledging the limitations of your research
Reassures the engineer by making them feel that they now own the responsibility to dig deeper into the findings
This way it will help to improve your credibility by:
(1) clearly call out the limitation of the research and
(2) make the engineer happy / assured because they are now owning the responsibility to dig into the finding further
Key principle: Even if you’re confident in your technical knowledge and capabilities, always maintain a humble tone. This isn’t about diminishing your worth — it’s about creating psychological safety for productive collaboration.
2. Transform Criticism into Learning Opportunities
When someone critiques your work, they’re essentially providing you with the “ideal” version of what the research should have looked like if they had conducted it themselves. This is gold.
Use their feedback as an opportunity to ask educated questions and learn more about the subject matter. In the process of explaining their perspective, engineers will often reveal:
Critical knowledge gaps you weren’t aware of
Technical nuances that only come with hands-on experience
Context about why certain approaches are preferred over others
This transforms a potentially defensive moment into a genuine learning experience that benefits everyone.
3. Redirect Focus to the Bigger Picture
Here’s the most powerful move: remind the engineer how your technical findings align with the key objectives and bigger goals the team is trying to achieve.
When you do this effectively, you shift the engineer’s focus away from challenging your technical research and redirect it back to the “why” behind the problem at hand. This reframes the conversation from “Is this research correct?” to “How does this help us solve our main challenge?”
This approach helps everyone remember that you’re all on the same team, working toward the same objectives.
Remember: The goal isn’t to win an argument or prove your technical prowess. It’s to contribute meaningfully to your team’s success while building stronger working relationships with your colleagues. These strategies help you turn potential conflicts into opportunities for growth and collaboration.
💡 Found This Helpful?
If this article resonated with your experience or helped you navigate similar challenges, I’d love to hear about it. Share your own stories of turning professional setbacks into growth opportunities.