The primary goal of an engineering leader is to build software that meets customer needs and achieves business objectives. That’s it. Simple. Nothing else matters if this isn’t achieved.
Whether leading a small team or a whole department the goal remains the same. The customer needs and business objectives vary company to company and quarter to quarter but every company has them and whatever they are they should remain the sole goal of an engineering leader.
Often we lose sight of this goal. We start seeing the various tasks and tools an engineering leader uses in their day to day as an end in themselves rather than as a means to the end of the overarching goal above.
Performance reviews and promoting engineers becomes the end. ‘Correct’ technical decisions and working in a ‘modern’ tech stack becomes the end. Moving the needle on engineering productivity metrics becomes the end. Improving developer experience becomes the end. Implementing product delivery methodologies becomes the end. Engineers learning from their mistakes and gaining experience becomes the end.
All of these things are good and are essential tools for an effective engineering manager but they are not ends.
Performance reviews matter when centred around actual business value delivered and are used to reward engineers and managers who have been shipping software that has helped to achieve business goals and outcomes.
Technical decisions and a modern tech stack matter when they will impact a customer’s experience, a top level business goal or the ability to hire top class engineers.
Engineering productivity metrics only matter if the team in question are working on things that help achieve the overarching goal. Same with developer experience and product delivery methodologies.
Engineers learning and gaining experience only matters if it’s not harming the customer experience, if it’s while working on something that achieves the business goals or is preparing the engineer to work more effectively towards the goal in the future.
Why do we take our eyes off the prize?
Why do we as engineering leaders so often take the means for the ends? A company may have never made it clear what the overarching goals are or they change too regularly to take seriously. There may be no one translating the business objectives into objectives engineering can make sense of. Most importantly though, and often the root cause of the other reasons, the progress towards the real ends are hard to measure.
It’s very simple to measure basic engineering metrics. It’s hard to measure whether those 40 deployments or 1 day cycle time have resulted in software that improves the customer experience.
It’s easy to measure how many engineers a manager promotes. It’s hard to measure whether those engineers have had a disproportionate impact in shipping software that achieves a business goal.
It’s easy to know whether or not a service has been refactored to use the currently trendy framework. It’s hard to know whether that refactoring has improved customer experience or product NPS.
Why are these things so hard to measure?
Understanding and measuring engineering output (DORA metrics etc, story points etc) is fairly simple with the glut of DORA metric tools that exist today. Understanding customer behaviour and business success (NPS, user analytics, revenue) is also fairly simple.
The tricky bit comes from translating the former into the latter and connecting the two up. The tricky bit is going from output to outcome and understanding the actual value delivered by an engineering department.
What the best engineering managers do
The best engineering leaders are able to do this as they know to look beyond output to the outcome of their team’s work. They know how to get the best from their toolset. They understand what the tools are telling them about customer behaviour, how to connect that to the wider business objectives and to the output of their teams. And, crucially, they know how to present this information in a way that their team, their bosses and the wider company understand.
Great leaders such as these are rare, expensive and even for the ones that do exist it takes a considerable chunk of their time to search through all of their product development tools, collect and collate the data, manually compile reports and present these reports in various different formats to their varied stakeholders.
How Vizval helps
This is why we are building Vizval. Vizval takes all of the best practices the best engineering leaders use when understanding and sharing the impact their teams are having, codifies them and automates all of the manual processes.
Vizval integrates with and extracts data from the entire engineering leader’s toolstack.
Vizval equips every engineering leader of every experience level with the tools needed to keep their eyes on the prize, get their time back for higher leverage tasks and help everyone understand what their team and department are working on.
Book a demo to learn more or complete the form with your email address to be kept up to date!