Why Your Engineers and Product Managers Still Don't Talk

(And How to Fix It)

Ever worked in a business that has your diary booked up from early morning to late in the afternoon? But you feel like you have all the meetings but still no real progress, still the communication is lacking, you all work remotely and don’t know what anyone else is doing?

You spend what feels like weeks in sprint planning, daily standups, twice weekly standups for something else, roadmap review meetings, backlog grooming. And then someone else from the business says “well actually we need this other thing.....” and the team just feels like they’ve been blindsided with some random request and project managers feel like they’re throwing specs over the wall and hoping they land somewhere useful.

This feels like it happens at some many different organisations. All the effort going into planning to then find that people are none the wiser, or worse, have literally no idea whats going on in general. The problem here though isn’t missing rituals, its that the rituals we’ve put in place are optimised for the wrong thing.

Cross functional ceremonies, meetings whatever you want to call them are designed to move information or status updates, requirement hand offs, timeline syncs, functional information. Whats the word? Perfunctory: carried out with a minimum of effort or reflection. These meetings answer the “what” and the “when” but without building the rapport between teams, people and employees needed for “why does this matter to you?” or “what are you worried about?” These types of questions are really key to the world we live in. Sure timing, requirements, they’re all important but developers developing without understanding the bigger picture, the concerns that others outside the develop bubble have, will forever be on the back foot.

I can give you some examples. First up an example of a well run, if not draining standup. So when I worked at NASA JPL we worked on a piece of science software that was required to process data downlinked from NASA’s Perseverance Rover. For years, 2 or 3 at least I joined nightly standups because I was based in the UK and we had to get Los Angeles, Melbourne and London on the phone at the same time. So 11pm for 20-30 minutes every night was the only time that really worked. Of course this wasn’t the most productive of times because I’d already been working all day, but they were effective, we could hand work off, discuss blockers etc without it unduly impacting too many people.

Then after that I went to work for a medical startup. We had a team on the US East Coast and a team in India. This made life especially hard, trying to keep teams in the US functioning, information handed off and project managers happy, with the scrum masters in India trying to wrangle ill defined requirements and me sat somewhere in the middle trying to both get my own work done and answer questions on both sides of the pond. The problem was, they kept having daily standups but the transactions were very much pure business, no questions were asked, no real conversations were had and as such the business owners were frustrated and the developers jaded.

The 5 Dysfunctions

So now I must ask the question. Who’s heard of Lencioni’s Pyramid? Excellent book and topic of many other blogs. I’ll just add this one to the list! In 2002 Patrick Lencioni wrote about the 5 dysfunctions of a team. And it walks through the many issues and sticking points teams face as they see to grow together, in doing so Patrick looks at the causes of organisational politics and team failure. Something a lot of us can relate to.

The five dysfunctions are:

• Absence of Trust

• Fear of Conflict

• Lack of Commitment

• Avoidance of Accountability

• Inattention to Results

The issue with the way a lot of organisations work though is that they operate at the top levels of the pyramid. They operate with a lack of accountability and inatention to results, whilst assuming that the foundations, trust, fear of conflict and lack of commitment already exist. Of course in so many cases they don’t.

Over time though what you will learn is that if your rituals, those meetings you all feel are so important are missing the foundation layers you’re building on sand and the whole thing will crumble around you.

So what is the absence of trust? The absence of trust is the unwillingness to be vulnerable within the group or within the wider organisation, which leads to a lack of trust between your peers. Fear of conflict involves seeking artificial harmony over constructive passionate debate and not understanding when to both push back and hold your ground when other people are passionately arguing in a different manner.

Lack of commitment is around feigning buy-in for group decisions which creates ambiguity throughout the organisation. People flip-flop between different points of view depending on who they’re speaking to and cause greater work for those who are then empowered to implement the changes.

Avoidance of accountability involves ducking the responsibility to call peers and superiors on counterproductive behaviour which sets low standards. Therefore people further down the chain are expected to hold themselves to higher standards than the boss is implementing the standards themselves which is counterintuitive. Lastly the inattention to team results which focuses solely on personal success status and ego before team success which of course is detrimental to the team output as a whole.

Of course this begs the question of what do we do instead? How about starting a meeting between technology groups with Q&A? Not forced icebreakers but structured moments where admitting uncertainty is normalised. I’ll give you an example: how about an engineering lead opening a planning session with “here’s what I don’t understand about this quarter’s priorities” and inviting the PM to do the same?

Therefore the backwards and forwards normalises the uncertainty between the groups, both dictating what should be implemented and the people doing the implementation work themselves, reducing the friction and allowing everybody to voice their uncertainties as a group.

On top of rituals that surface vulnerability, how about rituals that practise disagreement? Teams that only agree in meetings and fight in Slack have a ritual problem. What does it look like to build productive friction into cadence? For example, how about a team that introduces a red team rotation into roadmap reviews deliberately asking the questions that would create the friction to ensure that it is discussed during the meeting rather than offline while grumbling into your Slack channel?

Finally how about rituals that build shared context, not just shared information? The difference between “Here’s the roadmap” and “Here’s the trade-off I struggled with and why I landed here”. For example a founder who replaced quarterly all-hands presentations with smaller cross-functional context sessions. It allows people to be able to discuss smaller chunks of work while also understanding the cause and reasoning behind those decisions being made, rather than a holistic super-high-level top-down view of work that’s supposed to be carried out across a broad swathe of the engineering function. We actually saw similar with the medical project we were working on that I mentioned earlier when we split up the groups into much smaller teams, allowing for better communication across different groups while still allowing the managers to track the broader project goals at a higher-level delivery.

Of course involved in all of this is the conflict resolution dividend. When rituals build trust and normalise disagreement, conflict resolution becomes cheaper. Teams don’t need to elaborate escalation paths because I’ve already practised navigating tension in lower stakes settings. So when a problem arises, the fallout and the ability to deal with it is far reduced.

Over the years I’ve worked in both types of environments, where engineering functions regularly get overwhelmed by both requests, feedback, and negativity and those that thrive.

Having worked in various startups in London over the years, we often saw small engineering teams with unrealistic goals and deadlines required to deliver on time. Then project managers would get annoyed when delivery was delayed for reasons that they couldn’t comprehend. Of course if you had dealt with this at a smaller team level focusing on individual pieces rather than the bigger picture, this may have been alleviated or remediated earlier.

Equally having explained it in an earlier in this blog, I’ve worked in many environments where small-scale conflict resolution was dealt with both effectively and efficiently by product managers, project managers, and engineering leaders. That makes a huge difference when it comes to delivering on time and to expectation because there’s less fear of retribution from within the engineering team should something crop up that would negatively impact the timelines involved.

Conclusion

I understand why there is pushback when it comes to dealing with relationship building rituals. They obviously feel soft, they don’t feel like you are contributing directly to the delivery of the product or project, and so it’s harder to justify a relationship building ritual in a planning document than it would be a sprint review or something of similar nature. Leaders from large corps, non engineering corps etc may see these meetings as indulgent but when you’re talking about a large swathe of employees, trying to navigate requirements, deliverables and an ever changing tech landscape I believe they are invaluable.

If you’re a C-suite reader reading this article, then the return on investment is real but it compounds slowly. You won’t see results in the next sprint. But when it comes to the next crisis or when your team has to bail the company out because they’re being asked to do something that wasn’t in the plans or wasn’t in the roadmap, that’s when you’ll see the real return on investment. When it comes to these relationship-building meetings.

The organisations that get this right don’t have more meetings. They have meetings that do different work.

As we sum this blog post up, the structure of your rituals reveals what you actually believe about how work gets done. If the ceremony is about outputs and timelines, you’re communicating that relationships are someone else’s problem and not yours. Over time as we’ve stated earlier in this blog post, that will lead to larger problems that’s trickier to solve in ever-shortening timelines. Of course the other negative impact as well is the happiness and contentment of your staff. That also has a detrimental impact on output as staff get less inclined to do the extra work or put in all the hours as they get frustrated with an ever-ending list of stuff that needs to be completed.

We start this blog post talking about the requirements for meetings and how those meetings are structured. The organisations that get this right don’t have more meetings. They have meetings that do different work and communicate the requirements and deliverables in a way that resonates more effectively with the staff at hand.

It doesn’t all have to be transactional. It can be very much a relationship-building exercise while still getting the same points across in less time.

So if you’re a C-suite executive talking to your product managers or project managers, just have a think about how to best structure those meetings. What you can do as an organisation to increase the output and performance while reducing the friction and the resentment with inside the organisation by improving the relationships between different teams and the dependencies on those teams. They will forever thank you for it as conflict and expectations become a much easier attribute to manage across the organisation.