/ software

Transparency vs. Understanding

Today a seasoned executive talked criticized his own team about transparency. This is an area I see a lot of people messing up, much to their detriment. When a leader doesn't understand what their organization is doing it's hard to put the blame on the organization in that case, but weak managers tend to do so. The accusation is almost always that the team isn't being transparent. This is one of the great cop outs, and nine times out of ten the CEO should start a search for a new leader.

The accusation is almost always that the team isn't being transparent.

In reality teams are typically doing the best they can. Transparency, especially in software development means that if someone tries to look in at what you are doing, they can see it. There are many viable methodologies for software teams to work under, each with their own artifacts. What matters from a transparency perspective is can an outsider see the artifacts the team creates through their work or are those artifacts obscured, locked down, hidden.

Examples of transparent teams:

  • The team the conducts all its business in a public slack channel.
  • The team that works in an issue tracker that all company employees can access and keeps their board and prioritized backlog up to date.
  • The team that publishes a sprint backlog at the beginning of a sprint, and then metrics on the result of the sprint at the end.

What all of these things have in common is that if someone wanted to, and cared they could dive in and observe or catch up with the flow, progress and process of the teams work. It's free to the team and just part of doing their jobs.

Domed glass terrarium on top of geometric pot with green succulent in it
Photo by Jonathan Francisca / Unsplash

Too often however a manager is just a little further away from understanding than they need to be. These managers have skewed expectations of transparency, and are really looking for something else. Proactive messaging to teach everyone something is a different thing. Not a bad thing, just different, and no longer free. If the team is open and transparent a professional skilled in the art should be able to use the tools and systems of communication and plug into the flow of work. That free nature of openness means that the team can support an unlimited number of observers, because the observer owns the time cost of their education.

It does however put the burden on the observer to manage the understanding on their own. This is where it gets tricky. Many organizations lack the broad technical understanding needed for someone to bring themselves up to speed from the free workflow; but they also lack the trust and/or structure to accept the short form version of a plan. All of a sudden your free transparency comes with a very real cost to the team, and every observer is now a stakeholder.

These uninvited stakeholders usually don't realize the impact they can have on a team. They don't coordinate, and they typically have an expectation that whatever they are doing is quite important. Managers are especially at risk of this kind of disruption. It's just one quick question after all.

It doesn't take long before this understanding gap teaches a kind of learned helplessness within non-team members. The expectation stops being that a team is transparent and starts being that the team has to cover the cost of understanding. Sometimes that understanding is as simple as what are you doing, but it seldom ends there, because what are you doing is an inherently uninteresting question outside of emergency situations.

People really want to understand the why questions, and why questions always require context. That context isn't free, and filling the gap typically causes a team to slow to a crawl. Many companies solve this problem by allocating time for teams to lift their heads up, slow down, and share this kind of material in the form of program reviews, or other similar conversations. This is often a very reasonable way to solve this problem, it comes at a cost in time, but you can push all that cost together into one block and treat it like a one to many communication. Some companies dedicate a full time role to this kind of communication with program or product managers effectively becoming internal marketers for the team. This can make sense as well, but again, it's not free unless you manage to find that group of amazing communicators willing to volunteer their time.

A manager not understanding what's going on in their teams or in their software is a lot like a rear-end collision. It's almost always the fault of following car.

I've found that when you see a manager challenging teams on transparency it's really a smoke screen for understanding. It's a statement that their time is more important than the teams time. Which might be true in some specific contexts but since a typical software team at a large company probably costs about a million dollars a year, the math doesn't add up. We pay these teams to build the right thing, the expectation on managers should be that they understand what their teams are doing and why at a deep enough level that they can make that investment pay off. Good managers and leaders intuitively know that an hour of their time is worth less than an hour of team time, and they find ways to make sure they keep their understand levels high without putting a frequent tax on the team to manage that.

A manager not understanding what's going on in their teams or in their software is a lot like a rear-end collision. It's almost always the fault of following car. Either the manager has let their team go so far off track that what they are doing doesn't make sense to anyone or the manager has failed to follow the teams journey through the free artifacts.

So if one of your managers or leaders starts talking about how a team isn't being transparent, that's a great excuse to dig deeper. You are likely to find that it's really the manager who doesn't understand.