Back to resources

When Words Bear More Weight

Internal Communication
Collaboration
Team Processes
New Manager

27 February, 2021

Wissam Abirached
Wissam Abirached

Senior Engineering Manager at GitHub

Wissam Abirached, Senior Engineering Manager at GitHub, tells of his transition from an IC to a manager on the same team and how that impacted his participation in technical discussions.

Problem

When I was an engineer on the team I was able to participate in technical conversations and share my opinion like any other engineer on the team. However, as a manager, I no longer was able to provide my technical input or opinion because people on the team would take it as a directive as opposed to another, possibly divergent, opinion.

This is not what I wanted because we have smart engineers on the team who were more familiar with the technical architecture and day-to-day problems. Moreover, the longer I stayed on as a manager, the less I was involved in the code. They were more up-to-date than I was, and I wanted to empower them to be critical and don’t take my opinion as it was. At the same time, I had extensive experience being an engineer on the team and felt that my technical input would be beneficial. But people wouldn’t argue back or push on the manager’s opinion and were taking my arguments at face value.

Actions taken

What worked -- Be the one to speak last

I decided to be the last to speak in a meeting. I would sit back, take notes, and wait until everyone had given their opinion. If some of the engineers hadn’t shared their opinion, I would prompt them to see if they have anything to add. Only after everyone had shared their thoughts would I share mine too. All the opinions would then be laid out on the table. That allowed the team to hear different thoughts instead of having only me talking.

The privilege to be the last speaker enabled me to stir up the discussion. Sometimes I would have a certain opinion on things, but after hearing some other proposals, I would be persuaded that they were better than mine. I would make sure to emphasize that and how hearing all different opinions made me revise my own.

Sitting back and keeping quiet was not easy. I would listen to people share their thoughts and, on multiple occasions, would want to interrupt them and add my two cents, but I would remind myself to keep still.

What didn’t work -- Individual encouragement in one-on-ones

I tried to bring it up in one-on-ones and explain that taking my opinion for granted was not part of the culture I wanted to build on the team. I would explain how I wanted us to build a culture where we should share opinions, and they should feel free to push back on my or leadership’s proposals. I would acknowledge their expertise and their involvement in the code and encourage them to speak up.

While I am certain that this helped a bit, it never amounted to full acceptance. They would still wait for me to share my thoughts. I also tried to speak at the meetings by abstaining from speaking from a manager’s perspective. I would say, “I have some thoughts; it’s just an opinion and certainly not any final decision.” Prefacing my statement with an explanation simply didn’t work, and they did take it at face value.

Lessons learned

  • Leaders tend to take a lot of air in discussions or meetings. When they don’t listen, they unconsciously kill creativity, collaboration, and innovation, altogether. Your role as a leader is not to always come up with the best ideas but to provide more context and encourage collaboration. Because at the end of the day, the team is the one to build things, and you need to empower them to take part in those discussions. By sucking out air in the meetings, you do not allow your team to flourish, which will ultimately hurt the product.
  • Be aware of how much weight your words carry. Also, be mindful of how much time you are talking and how much time you are listening to others.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

How to Maintain Happiness: The Underrated Aspect of Creating Team Dynamic

2 August

Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.

Personal Growth
Company Culture
Leadership
Internal Communication
Psychological Safety
Jonathan Ducharme

Jonathan Ducharme

Engineering Manager at AlleyCorp Nord