For product-focused IT companies, engineering teams are the key to their success.
Still, these departments can be less represented in executive meetings, and their impact isn’t always visible to the rest of the company.
It’s your responsibility as an engineering leader to change this dynamic and become more proactive about visualizing your team’s achievements on a business level.
How do you go about it?
This episode includes:
We’re in the golden era of engineering leadership. I don’t think there’s ever been a better time to be VP of Engineering or a manager or director. The reason is, a lot of companies are product-focused, and software is the key to their success - when you’re an engineering leader in that environment, the business is relying on your expertise a lot.
There’s a stereotype that executives tell engineering teams what they want, and they just build it without any desire to be at board meetings and have a say in business-level goals. That’s not the case anymore.
It’s becoming more and more expected from engineering leaders to be actively involved in business discussions, as they drive one of the most impactful and expensive departments of the company. Being part of these conversations also helps tech leaders allocate their engineering resources more effectively.
At my company, we call this shift in engineering leadership roles the “dual mandate”. It refers to the fact that engineering leaders need to focus on technical aspects as well as business alignment.
I would say, when talking about your team’s progress, focus on predictable project delivery. You can always talk about the purpose of the project as well, not just the team’s progress on it, so it’s easier for everyone to understand what value it brings.
But the most important aspect for CEOs is knowing when the project will be delivered, what goals your team met during the last sprint, and so on. A great way to keep track of your team’s progress as a leader is to master your planning accuracy and capacity accuracy. Planning accuracy is about accomplishing the objectives you planned to accomplish within a sprint. Capacity accuracy is, for example, estimating that the team can do 100 story points worth of work, and comparing it with the actual story points completed.
When engineering leaders are very sharp about their planning and capacity accuracy, it means their teams are delivering on time, which allows the department to get acknowledged by the rest of the company.
It’s also a great idea to interact more with sales teams. They have so much appreciation for the product of the company, because their role is to tell others how useful the software your company builds is.
So you can talk to salespeople and let them know some engineering KPIs your team recently hit, telling them how their work will add new useful features to the product. You can do this on Slack as well - at the end of each iteration, you can write a post about your team’s achievements, for example.
You might be surprised at how much enthusiasm and celebration will follow your updates. Your non-technical colleagues might even start asking cool questions about recent developments that they can share with potential customers.
This encouragement and acknowledgment will boost your engineering team’s morale and while also making their impact more visible to the rest of the company.
First and foremost, if you’re working in an international company, write your updates in a language everyone can understand. Funnily, this language will be data. Everyone can read and understand numbers and charts. Everyone has a love language - ours is data. If you post KPIs on Slack, they’ll be easy to consume.
There are a lot of platforms you can use to track data - LinearB’s platform is just one of them. If you look up “software delivery management”, you’ll find lots of tools that will help you with tracking, understanding, and improving your engineering metrics.
Before you start sharing data publicly, make sure you talk to your team about it. Agree on what type of data they’re comfortable with sharing, and make sure everyone is on the same page about communicating the team’s impact to the company.
Never measure individual developer performance. It’s not interesting. Comparing your developers to each other is more of an HR responsibility - keeping track of who’s doing well and who might have some challenges.
Velocity can also be a bit dangerous to measure, especially if it leads to comparing different development teams’ progress. Focus on commitment instead, and communicate whether your teams reached the estimated goals of the sprint without comparisons.
At my previous company, I was VP of Engineering. We were acquired by Cisco for a lot of money, which was a great success. I had about a hundred engineers in my team, and I was sitting at the executive table. I remember I was surprised when all of the other executives came prepared with data regarding their respective departments. It was so weird for me, because my team dealt with data all the time, and yet, we had no data to show the impact of our work on a business level.
This inspired me to co-found LinearB with Ori Keren, so instead of tracking everything in spreadsheets, collecting engineering teams’ KPIs and data would be easier.
Dan is the CPO and Co-Founder of LinearB and host of the Dev Interrupted podcast. He’s always been the entrepreneur type - growing up, he was building and selling computers at school. He studied computer science and worked at startups throughout his career, working his way up from a junior developer to VP of Engineering. Before founding LinearB, he was VP of Engineering at cloud security company Cloudlock, which was acquired by Cisco.
At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.
Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀