Dealing with smart but territorial engineers.

Problem

"I had a staff level engineer (pretty senior in our company) on the team that was very good at what he did, but he wanted to do everything himself and not be very transparent about statuses either. He wanted to run the show, take very little input from others and only deliver the end product, which was usually good but there are times when expectations are not met. Firstly - he was a staff engineer because he came with many years of experience, and made very valuable contributions to the team. Also he was dependable, meaning he would deliver on the timelines promised, but many times others would not have had a chance to weigh in with their opinions. Because of this, at times, even though the end deliverable was elegantly engineered, that was not what we had wanted."

Actions taken

"Like most things in life, peeling through the layers and getting to the bottom of it will only yield positive results. In this case, his behavior was because of 2 main reasons:

a) His philosophy that multiple opinions lead to more talking than doing and slows things down. b) Lack of trust when it comes to delegating tasks to others.

For a) - while I believe that too many opinions can slow things down, shutting down all opinions will only lead to resentment within the team. In order to address this, I formulated the idea of architecture/design review sessions for every project undertaken in a quarter. The goal here is to provide a forum for others to weigh in with their ideas. While all opinions are welcome in that forum for an assigned period of time, the decision makers ultimately decide which ones to use and which ones to discard. After the design review, we share notes on all opinions provided, which ones made the cut, and why. Once the design review is over, we only focus on execution and no more debates about designs are encouraged at that point. This solved his problem of slowing things down because while we welcome opinions from everyone, we do so only for a set period of time, and we still set the expectation that opinion providers are not the ultimate decision makers.

Tackling b) is a bit more challenging because it varies from individual to individual and there is no one size fits all solution. It took a series of one on ones to solve this problem because I had to thoroughly understand why there was a lack of trust. It boiled down to a couple of things - lack of clarity on what was expected, and sub-optimal communication. I asked the individual to spend enough time up front providing clarity on what's expected when delegating tasks to other members in the team. This included setting up kick-off meetings instead of just email communication, and these meetings are not just limited to engineering, but includes product and business teams as well. In time both the engineer as well as the rest of the team became good at this - he started providing more clarity on things as well as learned when and how to follow up on statuses. And the team also proactively started communicating updates which gave him more confidence in them. Things have drastically improved and we have much more synergy and trust within the team."

Lessons learned

"As an engineering leader, you are part technical leader and part psychologist. It is vital to put yourself in others shoes to better understand why they are acting like they are. You should encourage candid discussions and timely feedback about issues, and work with them hand in hand to come up with a solution. Also communication is key - state clearly what your expectations are so that everyone is aligned from the start and no drastic course correction is required later."