People Problems
Three months into a new role as the CTO of a small media company, I walked into the CEO’s office and told him that one of our senior engineers had quit. As he started to reassure me that everything would be ok, I quickly cut him off. “I just avoided the most difficult issue I was going to have to deal with in my first six months. I just won the lottery.” Clearly not the response he was anticipating. So I explained that despite being a good engineer, he was difficult to work with, disrespectful to his peers, and did not enjoy collaborating with anyone on the team. In short, he was toxic to the team and we got very lucky that he decided to leave.
I knew going into the role that there were fundamental issues that had to be fixed ranging from poor software architecture to a complete lack of process on the product and engineering teams. As challenging as those types of problems are, they are nothing compared to people problems.
People assume the biggest challenges for a CTO or VPE are technical ones. Technical challenges can be hard to solve, but they are also fun to solve. Engineers are at their best when faced with a seemingly unsolvable problem. People problems are not fun for anyone, and unfortunately, are often insoluble.
Another people problem emerged recently. Unlike the first situation where the guy was a straight-up jerk, disrespectful, unprofessional, and someone who took pleasure in actively putting down his peers — this engineer had the best intentions. He was always looking to improve things and deliver quality software. The problem was that, despite this, he was a poor cultural fit for the team; a much more difficult situation.
My initial look at the situation gave me only a partial understanding of the problem. It seemed like this engineer had strong opinions that just happened to deviate — often heavily — from those of the rest of the team. His approach to almost every aspect of developing software was just different.
But what frustrated the other team members most was less about the technical particulars and more about how he collaborated — or rather, how he failed to collaborate — with the rest of the team. Often, other engineers would describe his behavior as “bikeshedding”. (A wonderful term, click through if you aren’t familiar). His believed he was being thoughtful, seeking out discussion, trying to make everything better. But functionally, he was consistently turning simple conversations into big discussions regardless of the topic. From larger architectural issues to coding styles — even how people should word their commit messages — he would initiate a discussion that rarely led to a conclusion or even a next step beyond more discussion.
After gaining a better perspective on the conflicts it was clear the tension on the team was getting to be too much, and something had to be done immediately. I did not want to lose the contribution of a good engineer, and I thought I could solve the problem by moving him to a project where he wouldn’t have to collaborate. He’d be working with only one other person — a product manager and recent engineer who could do code reviews but would no longer offer engineering-related opinions. I was curious how this engineer would do working alone, in a situation where collaboration wasn’t even possible. Unsurprisingly, he did much better.
This went on for a few months, but ultimately projects and priorities shifted around and it was no longer an option to keep only one engineer on this project. As soon as other engineers were introduced, the exact same issues came up again. It occurred to me that I’d just been postponing the problem. That said, the time afforded me the opportunity to speak to this engineer more often and learn more about how he approached his work. When tensions (inevitably) arose again, I had much more useful information to inform my decisions.
I realized that my initial assumption — that this engineer had a different, but equally effective, way of doing things and that it was my job to make the best use of his contributions — was simply wrong. With more time and more conversation with him, I came to understand that his approach to work was more than just a fundamental misfit with our team. The first big revelation was that he conflated best practices with personal preferences. He could spend five minutes or a full hour arguing with other engineers for his approach, but at no point was he ever going to consider the other engineer’s opinion. He also made issues out of very small things, things that no other engineers on the team felt were worthy of discussions. (One of the more notable ones was how and when we should update our statuses in the #status channel on Slack. When the rest of the team blew-off his incredibly specific recommendations of how we should all speak to each other, he petulantly left the channel.) He always spoke about collaboration, but actual collaboration was beyond him. He would relentlessly push his own ideas on everyone else under the banner of collaboration, but that was the exact opposite of true collaboration. There was a disconnect.
It wasn’t all making mountains out of molehills. He also tended to over-engineer solutions at the onset of a project. Rather than take the simplest approach — develop working software, and refactor later as needed — he would “pre-factor” overly-complex solutions. This fit very poorly with with a team that believed in simple solutions and an iterative process.
As my understanding of the issue grew, our conversations got more difficult. It was then he started to demonstrate one of the most troubling and toxic behaviors of all: blaming others. He blamed everyone and everything. He argued that the root cause of the conflicts were due to the flaws of other engineers, or being the only one who “cares about the craft”. He cited being a remote worker as a cause. When I pointed out that these conflicts never arose with the other remote team members, he fired off other reasons why this was someone (anyone) else’s fault. There was no introspection, ever.
Functionally, in the end, this engineer’s problem ended up being the same as the first one. When push came to shove, he didn’t play well with others. And at this point, I knew that the situation was unfixable. To be honest, I’d probably known it for several weeks but I tried — possibly to a fault — to figure out a way to make it work. Why? I’ve been much less forgiving with other people that have wound up leaving the team I’m running, but for some reason I had a hard time getting past this engineer’s good intentions. I think it was because he framed everything as a commitment to quality, which is an ethic I hold in high regard.
The most valuable thing I took away from this experience was a strong reminder about the importance of cultural fit on a team. The first engineer was an aggressive jerk who took pleasure in putting down others. The second was a really nice guy who thought he was making things better. Both created a toxic environment that was a contributing factor to valuable engineers leaving the organization. In the end, intentions didn’t matter, and paying too much consideration to them only prolonged a bad situation.
Unlike technical problems, people problems are often insoluble. Ultimately the best resolution is often removing the person from the team quickly. And also unlike technical problems, that is never fun.
Matthew Eckstein is the CTO of charity: water and doesn’t care what color you paint the bike shed.
