Listen to the quiet ones

The nearly six years I spent at Cisco in the early to mid 2000s were critical to my early career progression and I’m not sure what I’ve path I would have taken me if I had not left SBC (now AT&T) after only nine months. Cisco was the first real tech company I worked for. I joined right at the height of the Dot Com bubble (and right after Cisco hit peak market cap) and stayed through Telcom bust and the years of half-completed office parks in Austin off 183.

I still remember wandering through the empty offices in Milpitas to meet with a Director of Product Management in the Service Provider BU who wanted our security research team to do competitive vulnerability research against Juniper M-series routers to blunt their market gains.

(Let’s say the premise that they were less secure because they build on BSD did not resonate with me, but that is a topic for a different blog. Since then, I’ve recoiled at competitive vulnerability research, but perhaps I am naive.)

My most important lessons were not about firewalls or network packet processors or VPNs or IPSEC acceleration or routing and switching or VOIP or MPLS or CDNs or BGP or embedded Linux.

But I did learn those things and that foundation in physical networking has been so important to understand the abstractions of the cloud. I struggle to understand how technologists that don’t have the previous experience in hardware can make sense of the software abstractions they consume via APIs, but that is also different blog for a different day.

My takeaways from Cisco were about the corporate echo chamber and how ideas propagate. Which voices are heard and actioned? Who wins and who loses. The lessons I took away from those years were about self-promotion and thought leadership. Speak loud and speak often. That really wasn’t me, though. People that were loud got their way. They got things done. They are believed.

The downside is that the people that are often the most confident can sometimes be wrong. Those that speak the most may sometimes have nothing to say. They may go unchallenged. They might drown out the voices of others.

I never became a manager at Cisco despite trying a couple of times and in hindsight, I was totally not ready. I did not deserve it. That would come later, but over the last few years one of the most damaging phenonenomon that I’ve seen in product organizations are singular loud voices (often male, spoiler alert!) dominating the field of discource, defining the problem space, determining what to do and why. They know all the answers. They are the deciders.

Some might cally them bullies, but they are often viewed as heroes by others because they “get shit done” in an organization.

While they do often can achieve great outcomes, they are not sustainable or scalable or resilient. They may be sponsored by the folks in high places because they are truly business critical. Toxicity is tolerated because they “drive things.” They are the “goto guys.” (Yes, gendered language intentional here.)

“I don’t know, ask Bob!” is a common refrain. In most cases this is not the designated product or engineering leader in a formal position of authority, because the leaders are often silent. They don’t want to deal with them. Or are afraid to. These individuals are competitive and “high ownership” and single points of knowledge. Single points of decision.

This is a corollary to the “Brent effect” popularized the The Phoenix Project. But eventually they leave (often due to burnout and frustration) and those that follow them (or who are left) must deal with the carnage. The solutions they create are brittle and fragile and they may not survive when they leave the organization.

Then there are the others on your teams that are not loud. They are sometimes more collaborative. They often keep to themselves, but are always listening and curious. They wait until they have something to say that they are confident and they believe in. They are comfortable with silence. They take a bit more time to process. They do not often say the first idea that jumps into their heads.

You need these folks on your team. They deserve your encouragement if you are a leader. Sponsor them and encourage them to speak up. You should introduce them to others and ensure their accomplishments are amplified. Explore the internal and external conditions that cause them to not to speak up when they could — or should! This is a tell.

But back to those that are “not quiet?” What is to be done?

Well, one thing is to paint the picture for them about the communicaiton process. People that are loud want to be heard. But when there is silence after they speak, what does that mean? When there is a communication imbalance between transmission and reception and response, what does that mean? Do others truly understand? Are they bought in? Coach them to slow down and speak less. Communication for Engineers is a good starting point if they are interested in professional growth.

When I was a teacher I remember learning about a “wait time” when instructors ask questions. Pause. Exploit the slightly awkward silence. That is where the processing occurs and thinking happens. (Re)set expecations on your teams about communication styles and patterns and the nature of solutioning. Just like with teaching, the best most resilient solutions need to be collaborative, not top down from on high. Everyone wins this way!