As a software developer, the products you build can have world-changing potential, which makes it particularly frustrating when you hit a bump in the road – when something stands in the way of getting your product to market.
Bottlenecks and roadblocks are not always easy to identify, and communicating these challenges to engineering leads and other teams can be even more challenging when you’re in the trenches.
Developers are technical wizards committed to being the best at what they do. However, communication is one thing that many struggle with.
I’ve been a software developer, and I’ve managed software teams. So as a member of both tribes, I have a good understanding of this tension between builders and managers.
As software developers, our work might make sense to us. But how can we make it make sense to those in leadership who aren’t spending their day building?
👉 Through visibility.
Making your software development processes visible through data and metrics doesn’t mean giving engineering leaders total control over your work. It means giving them the insights they need to make better decisions, so you can work together to address any bottlenecks you might be facing.
There are two ways to bring this sort of visibility to your work:
You can focus on doing what you do best with a visibility tool: building the product. Meanwhile, your manager can focus on doing what they do best: removing blockers to ensure the team is happy and maximizing impact on the end customers.
Remember when code coverage was the very latest in software testing? I do. At first, it felt like many software engineers didn’t trust it. But eventually, it became an indispensable tool for all developers. Too indispensable...
Code coverage gave teams more information than they knew what to do with. It gave managers far more data than is necessary to make better business decisions. We were overusing it and fixating too much on benchmarks - until we finally found a balance.
I don’t want visibility tools to have the same journey. Managers should not demand “100% visibility” from their development teams. Instead, they should aim to gather the data and metrics that will help them answer and ask the right questions, without asking the team to spend time doing manual reports.
For visibility tools to have an impact, leaders must consider all the insights they gather through the lens and context of their business.
Ultimately, visibility tools are just that – tools. They enable managers to highlight the key metrics in their development processes, but it’s up to you how you use these metrics.
Software engineers sometimes feel like unsung heroes. When a lot of the work we do is invisible, it’s easy to feel underappreciated, and lack of visibility leads to questions like:
“Can’t we build that feature faster?”
This, of course, is the wrong question to ask.
Better questions might be: “Is my team facing any bottlenecks? What are they? What can I do to remove them? And how much time and money should I invest in removing these bottlenecks?”
Great Engineering Leaders take context into account when analyzing engineering metrics, and ask the right questions. This way, teams can dedicate their time to value-adding, impactful activities.
💢 Be extremely hard on the questions, and remember that you are not questioning people, you are questioning workflows, so that you can have meaningful conversation to improve (Pixar calls this braintrust).
With the right data and metrics, engineering leaders can identify patterns, communicate effectively with leaders in other functions, and work towards a culture of continuous improvement.
Ultimately, visibility tools can make software teams more productive, work more rewarding, and deliver more impact to end-users.
Athenian doesn’t offer individual-level metrics and it doesn’t rank developers in any way. Instead, it offers a developer-friendly approach with a focus on empowering teams, rather than on holding individual developers accountable.