/ Why

Software Complexity and Leadership

I am of the school of thought that says software products are complex. Even, or perhaps especially, when you try and make them simple to your users. The technology is a part of it, but most of the complexity comes from the fact that you are designing and building something new. The work to understand the problem space, customer need, and how that intersects with the technology you need to build is all part of that. The most efficient process to implement something is usually not the most effective process to design that same thing.

Properly done, teams are constantly moving towards their goal, think a little, build a little, measure and repeat. From the outside however, that often appears uncertain, messy, and unpredictable. That perception doesn't fit with most pre-existing management conditions, so a facade of sorts is often placed between the team and leadership. This facade is easier to maintain than getting leadership to understand the complexity.

The truth is however, that the facade costs something, and the less complexity the leadership team understands, the more the facade costs even to the point that entire teams exist to maintain the facade.

Every time you create an abstraction between the complexity of your software and what you leadership understands you have a new opportunity for the everyday changes you make inside the team to drift further and further from what the rest of the company is expecting.

Here is where good leaders separate themselves from the weaker leaders. You need to find a way that works for you to understand enough of what's going on in the software effort to trust that it's going the right direction.

There are two viable paths for a leader to take.

First, listen to the team, trust them. Let them tell you what's important, and what they are going to do about it. You don't need to get into the weeds of the complexity, but you also don't get to make any tactical decisions. You tell the team what's important, and let them respond. You can ask questions and challenge assumptions, but you are ultimately trusting the team to both define success and make it happen.

Second, dig deep, put yourself close enough to understand large swaths of the complexity your teams face. Spend the time to immerse yourself in their culture, process, setbacks and successes. Help them from where they are, not where you wish them to be. It's usually not possible for an actual human to maintain all this complexity at large company scale, but the more work the leader does to understand it, the less the team needs to do to explain. They will come to trust leadership.

In the end this trust can and should be bi-directional and these two paths which seem to diverge rejoin in a high trust/low blame culture. The leap of faith to put your facades aside and focus on the actual challenges is difficult, but if you mandate the facade, you will get it, and once you are only seeing the facade, the job of leadership becomes luck and guessing.