Navigating the day-to-day of software organizations can be daunting. Companies demand their teams to meet multiple goals. These teams must interact and support each other, but the fact that everyone is moving, changing, and doing different things translates into chaos, friction, bottlenecks, and misalignment. Leaders can help mitigate or eliminate some of those challenges by providing clarity and creating a predictable environment that people can learn to navigate.
Two ways leaders can increase clarity is by making decisions and providing consistency.
Making decisions
Making quick decisions is one of the most important things we can do as leaders to add clarity to our teams. Here are a few examples:
- Put constraints on which paths are possible: Putting constraints early on can eliminate cognitive overhead on the team.
- Choose among multiple possible paths: Teams are often blocked because they wait for a decision on which path to follow.
- Resolve conflict: When people or teams are blocked because their opinions are odd, leaders can add clarity by quickly resolving the conflict of which path to follow.
- Delegating decisions: This is important for not being a bottleneck in decision-making; we want to provide direction so that teams and people can make decisions aligned with the company's goals and constraints.
The timing of the decisions is important as well. We should make most decisions quickly, especially when they are reversible.
Predictability
Leaders must create an environment where the direction is clear and people know how and when to make decisions. When people don't know, they will be stuck overthinking and figuring out how to move their goals forward or whether they will stay the same next week when a shiny new thing pops out of the leadership team.
For instance, I recently gave feedback to a colleague about how his lack of clarity impacted his team's adoption of better practices. In this case, the team was working on improving the quality of their deliverables. More than half of the time, the root cause was that they skipped testing altogether because their internal customer was pushing them to deliver. His lack of clarity was that he needed to clarify to the team that they should not skip the testing phase but evaluate it case by case, creating overhead and confusion for the team. The result was that the team was skipping the testing phase in 50% of the cases.
Will Larson has a short but interesting piece on this topic.
Follow me on Twitter or subscribe to the newsletter for more articles on software engineering leadership and troubleshooting software engineering teams' problems.
