Effective communication patterns in engineering teams
Over the course of my career, I have been part of several science and engineering teams. I have seen great leaders and terrible leaders, as well as junior team members who grew quickly and those who got stuck. People who led by example and inspired others, and people who drove others up the wall and caused untold suffering.
The defining factor separating the good from the bad in all of the above experiences was emotional awareness and empathetic communication.
Engineering education and professional training does not prepare new graduates for the intense teamwork required in professional settings. Except in some internship opportunities, most new graduates have very episodic exposure to working in teams. While ambitious engineers usually have a good idea of the technical achievements their next growth phase might entail (or their next promotion might require), they often have no idea or at least no clear incentive to improve their communication skills - critical for organizing their team, motivating and mentoring their colleagues, communicating product requirements to product management and executive stakeholders, and managing customer relationships (yes, engineers should play a role in that).
Effective communication is the limiting factor in most engineers’ professional growth.
Some scientists - and engineers with science training - have an advantage, as science training emphasizes written communication as well as teaching skills through TA work in graduate school. Even that advantage turns out to be relatively small, because most organizations don’t actually verbalize the success factors that enable effective communication in their engineering teams.
Google’s “people ops” (“HR department that hopefully doesn’t suck”) put together a nice website outlining some of these key success factors, but even that only just begins to summarize the key insights that engineers realize over time.
The key breakthrough in my understanding of the importance of practicing emotional awareness and empathetic communication came from my work with an engineering executive who stepped in to manage a bunch of teams as they struggled to find structure and clarity. After this woman joined the team, she did not focus on holding people to specific engineering objectives or product outcomes. Instead she advocated (but did not force) an overall project management process, and spent almost all of her time building relationships with team members without regard to their level in the reporting chain. Her calendar was always open for 1:1s, and after establishing initial rapport her next step was always to give the person a copy of the book, How to Talk So Kids Will Listen & Listen So Kids Will Talk.
The simple and profound truth is that truly empathising with each person on your team is a necessary and often sufficient condition for upleveling your communication skills to the point where they are no longer a limiting factor in your professional growth. The content of the book is just as applicable to adults as it is to children. In workplace teams, the default dynamic is to suppress the negative emotions that come from neglecting our need for empathy - with major negative consequences. If even marginally emotionally abusive behavior is normalized, the team suffers permanent damage and can no longer function properly. Conversely, empathetic, emotionally aware, and comprehensive communication empowers the team to make incremental improvements which translate to greatly increased performance over time.
The last key pattern that I have observed in successful engineering teams is a productive interaction between the customer champion, the internal product stakeholder, and the technical roadmap planner. Different teams have different names for these roles, but they are commonly referred to as a UX researcher, a product manager, and a technical product manager or scrum master. Each competency in this trio is necessary for the team to succeed, and effective, high bandwidth, low ego communication between the three is a key determinant of team productivity and happiness - of all the success factors listed on the Google website above. The customer champion must effectively and passionately represent the customer’s needs - in fact, they need to be backed up by each team member as well (this is the Amazon leadership principle of “customer obsession”). The product manager must determine product strategy, plan large long-term efforts, and steer the team through complex product improvements. The TPM or scrum master must have deep technical knowledge of the product’s infrastructure and the ability to plan tactical efforts to execute the team’s strategy. The TPM must also be an effective advocate for the team’s ability to manage technical debt (which works in a way that’s remarkably similar to sovereign debt). In fact, the third thing that the engineering executive I mentioned above did after impressing the power of empathy and establishing a PM process was to inquire about the team’s technical debt level and what it’s doing to manage it over time.
The interaction among the UX-PM-TPM trio can be evaluated to determine the level of stakeholder value alignment. Do the three parties have a shared understanding of the team’s priorities and how they will deliver customer value over time? If there is ambiguity about the answer, then they can go back to the communication first principles to improve this mutual understanding.