/ software

Making Space

Two Weeks ago I quit my job. A point comes when if you want to actually be open to doing something new, and be able to think about that thing for real, you need to make some real space for it. That's for me.

For the organization I'm leaving behind, a medium to large software development shop at a mid-size public company, I'm making space of a different kind. Space to lead.

This is my second senior leadership role in a company that needed to make a substantial transition; from an old business model where the market was shifting out from under them to a company that needed to figure out how to deliver a complex, software enabled product.

Companies tend to under-estimate the complexity and difficulty of this transition. Technology companies who have grown up around software development internalized the idea that the most powerful tool for creating a new product is to empower and trust a group of talented people to work toward a vision. These teams typically have a high degree of ownership over their space. They are accountable to management, but the accountability typically includes ownership of a portion of the vision, development of the strategy, and the implementation.

Companies that haven't made product and software development a core competency tend to adopt methodologies that superficially look like empowered teams but too often it's a veneer. If your team can't make a decision that impacts the business in some way without stopping and asking permission you are perhaps not empowered broadly enough. This breadth of empowerment to think about the whole goal is key.

It is very easy to fall into the trap of predefining a goal, which turns into scope, and requirements. Doing an estimate before you start, probably passed down from management instead of letting it flow upward from the team effectively locks in all sides of the triangle before you start.

Certainly it's normal to have a team checking in with management, but that should be in the form of the team asking management for help, advice, or making a very substantial change. In some companies the management has a lot of internal wisdom around product development and can provide this help easily. The companies that are making this kind of cultural transition however typically don't.

It puts them in very dangerous territory. From this starting point it's probably easier to fail in a very expensive way than to succeed. When a team asks for help they have consciously made space in their product for outside advice and guidance. It's not a disruption. When management demands it's almost guaranteed to cause some form of breakdown. This can be problematic enough, but in transitioning companies the lack of management experience in complex software creates scenarios where management can't actually help.

It is usually made worse in organizations where the leadership team claims skills in other types of business. This confidence leaves them unprepared for the types of complex decisions needed by software teams. The team as experts in the space are often operating across a broader scope than their executive leadership. In siloed organizations you might have a team working on something that cuts across technology, business, marketing and more. Aiming squarely at something valuable.

Legacy management isn't set up for that. Now instead of the team presenting an idea, they are instead justifying their work to some version of a committee. That committee by definition can not know everything the team knows, and you basically end up in one of two places.

Either you can have a bunch of people who don't have enough context to be making decisions pushing implementation details into the team from the outside, or you stall endlessly while the team attempts to push enough context into managers who may never have worked on a similar project. Either way management strips away the empowerment from the team through these rituals.

The instant this happens all the benefits of independent teams moving quickly toward a goal evaporates, and that team has to slow down to the speed of the rest of the organization. The clutch is now disengaged and your software team can only run at the same speed as the management team, trading the work output of an entire team, or more likely multiple teams for the speed of management decision making.

I've spent the last several years in this team creating space for teams to do their best work. Trying to lead when teams needed leadership but creating space when they could lead themselves. Now in leaving that space will need to be protected. It's always a touchy thing, the values required to implement a modern software team often run counter to corporate instincts. People have rigid systems that worked for them in the past, and inertia or fear makes those top down structures seem very reasonable. You often see leadership teams splitting up the ownership of the elements of the product. More managers results in more command and control at exactly the wrong time.

Instead embrace the empty space to lead, not manage. Get the entire leadership team on the same page about where you want to go. Acknowledge the inherent uncertainty in a multi-year journey. Share that vision with the teams, repeatedly and consistently. Give them space to respond to that vision. Good teams will respond to that space. That response may not take the form that you expect, but the fact that it is a response matters most. It demonstrates that you expect the team to find their own way to their goals. It's also the one thing that every manager can do, even if they don't understand the technology; make the vision clear and then make space for your teams. It's one of the most powerful ways of leading a software team.