This article is the transcript of a spoken talk. The brain and behaviour mechanisms described are simplified for a general audience and are not clinical guidance. Sources for the research referenced appear at the end.
Collaboration between engineering, leadership, product management, architecture, and design is fraught with challenge. Too often it becomes a tug of war that leads to bad decisions and poor adoption. I'm Floyd Kelly, founder of NEUVERO. As a VP, I led global software teams, and now I use neuroscience to help executives and entrepreneurs unlock the unique potential in themselves and their teams.
In this video, I'll share five anti-patterns that cause cross-functional collaboration to fail and what you can do instead. Let's dig in. Number one, overuse of positional authority. Play your positions. Look, collaboration between disciplines is very complicated. That's why leaders fall back on positional authority instead of collaboration.
In reality, this is one smart group of people and you need the very best they can give you, not a role-based defense against cognitive complexity that limits their potential. So instead, make it a principle: best idea wins, no matter where it comes from. Build a shared mental model of what you are trying to accomplish and be sure every functional perspective is represented, even if someone contributes outside their lane. Number two, confusing designs with requirements. Look, it's natural. When we imagine what's next, we picture features, mockups, or tech stacks, but fights on this level usually signal something deeper: a hidden assumption, an unstated constraint, or a misalignment on strategic purpose.
So instead, as engineers ask hard business questions. Would there be more value in this outcome or that? Would you accept a delay to get more value? Would you reduce scope to get more speed? And as PMs ask hard engineering questions. Why is this complex? What technical debt does it add? Is there a priority that should be challenged for technical reasons?
When debates flare up, step back, ask, why do we see the path differently and how might our mental models be different? Next, ignoring architectural opportunity. Software is malleable, but teams treat it as fixed. I once saw a six month project shrink to just six weeks when we stopped, got curious and explored a new architectural approach. We had to overcome our own bias to stick with the known path, which is a classic cognitive shortcut. So instead, promote cognitive flexibility and encourage what-if thinking in your team. Treat architecture as a strategic enabler, not a distraction.
Anti-pattern number four, engineering delegating sequencing, or architecture, to product managers. Dev leaders who are overwhelmed often say, too many priorities, talk to PM, but that can be abdication. The engineering leader's role is to synthesize all of the perspectives, market opportunity, design intent, architecture, and technical debt, together with their deep knowledge of the team and the system.
So instead, take full accountability for how your team invests. Make trade-offs visible: when prioritizing features will add debt, or taking an architectural spike before a design change will accelerate velocity, make sure people know what the real trade-offs are. Make your decisions with eyes wide open.
And then there's anti-pattern number five, relying on opinions, not data. Too often the loudest voice wins the day. If you Google animals of product management, you'll find colourful characters like the seagull who swoops in, makes a mess, and then leaves. Or the wolf who's always working on the latest fire and the rhino who is always chasing the next really high value, new opportunity.
But two of the animals are far more dangerous. The zebra, who has zero evidence but is really arrogant, or the hippo, the highest paid person's opinion. In fact, I'm told that some folks at Microsoft go around saying, watch out for the hippo. Look, our brains are wired for authority bias. Yes, sometimes the senior person has vital context, but the evidence should always come first.
So instead, test your assumptions, validate your decisions with data, and respond quickly when the evidence shows you are wrong. So to summarize, number one, let the best idea win. When debates arise, check the underlying assumptions. Number three, remember that software is malleable. Big problems can become small ones with new creative thinking.
Number four, take full accountability for your point of view even if you don't win the debate. And number five, watch out for those hippos and zebras, especially if one of those describes you.
NEUVERO is here to help. If you would like individualized training or coaching on the neuroscience of leadership, please book a call.
References
- Kool, W., McGuire, J. T., Rosen, Z. B., & Botvinick, M. M. (2010). Decision making and the avoidance of cognitive demand. Journal of Experimental Psychology: General, 139(4), 665-682. doi:10.1037/a0020198
- Tversky, A., & Kahneman, D. (1974). Judgment under uncertainty: Heuristics and biases. Science, 185(4157), 1124-1131. doi:10.1126/science.185.4157.1124
- Cannon-Bowers, J. A., Salas, E., & Converse, S. (1993). Shared mental models in expert team decision making. In N. J. Castellan (Ed.), Individual and Group Decision Making (pp. 221-246). Erlbaum.
- Cialdini, R. B. (2009). Influence: Science and Practice (5th ed.). Pearson. openlibrary.org
- Peters, D. The Dangerous Animals of Product Management. ProductBoard. productboard.com
Adapted from the Neuvero video Five Animals of Product Management. Related: Why Smart Teams Leave the Same Meeting With Different Conclusions (the shared-mental-model problem up close) and How to Break Your Team Out of Analysis Paralysis, on the cognitive shortcut behind "play your positions."