Florian Herlings.

Over engineering management

One of the first teams I managed as an engineering manager put me through a bunch of very tough challenges. The team consisted of mostly senior+ developers. They were not only experienced coders, but als very experienced at questioning everything from product decisions to development workflows to scrum itself.

They also questioned each others decisions a lot, which resulted in a lot of conflict in the group. Two of the developers were especially hard on each other, which sometimes resulted in open conflict.

I got to work

I talked to them seperately in our 1:1 meetings about the situation. Both of them had good arguments for why the other person is completely wrong about everything, so it was clear to me, that it was not one of the developers’ fault, but actually a problem of the team structure and processes. I put a lot of effort into resolving the issue.

I did everything to reduce time pressure on the team. Nothing changed.I optimized processes to reduce any friction in working on the project. Nothing changed. I coached the product manager to be more clear and precise on requirements (I actually wrote down most of the requirements with him). Nothing changed. I did an Inverse-Conway-Maneuver. Nothing changed. We even bought new hardware for one of them. Nothing changed. The three of us had long discussions in which I tried to be a neutral moderator. Guess what: Nothing changed.

At this point, “the conflict” became one of my main sources of stress at work. The literature I consumed pointed me to the importance of a jelled team. At the same time we were shipping new features on a weekly basis, while at the same time refactoring the codebase.

What was actually going on

One day I was discussing the topic with the lead developer, and he was about to say something that completely changed my mind about the whole topic. He said:

Look: There is a guy at work who is an asshole. That’s it. This evening, I will go home to my family, and he won’t.

It might not seem like inspirational quote, but for me it was the exact thing I needed to hear at this point. I realized immediately, that I was doing too much. The team was productive and shipping features. Business goals were met. The customers were happily using the platform1.

The actual problem was not those two guys having an occasional fight. The problem was, that I was over managing the situation. I did not understand that some people will just create conflicts, because this is what they do.

tl;DR

Don’t overengineer your management. Don’t confuse harmonious and jelled. Because, you know, some people are assholes.

  1. Before this team of mostly senior developers got to work, the platform had reached a point where the platform became unstable. I actually saw this in many teams: The mindset, structure and processes that get you from 0 to 1 quickly, will prevent you from getting from 1 to 10 or even 100. For people with a business mindset, this is extremely hard to accept. If you are in a tech leadership role: Keep track of all the shortcuts you took, estimate how much time it will take to fix later and keep presenting this list to business from day 1. Initially, the business side of the company will be slightly annoyed as it might come across as complaining on your end. I guarantee you though: Business will be extremely happy to know how much technical debt you acquired. They will themselves feel the need to pay it back later, as they will see your engineering team slow down a lot after the initial release. ↩

This website does not use any tracking or feedback mechanism. Instead, I would love for you to get in touch with me to let me know if you liked it or if you have any suggestions or questions.