GLOW 2022: Key Takeaways From The Engineering Leadership Summit

At Jellyfish, one of our 5 cultural values is Glow Brightly. This value is all about teaching, learning, and growing. We all share a thirst for knowledge, we are all here to grow, and we’re constantly learning from each other. It was refreshing to see just how much our engineering leadership community embodies this value of Glowing Brightly during our first inaugural engineering leadership summit, aptly named GLOW.

GLOW was only made possible by the inspiring engineering leaders who volunteered their time and efforts to help others within this community. The topics were completely crowdsourced, and the leaders created their own presentations. Our technical leadership led the networking sessions, where leaders spoke openly about their challenges, how to hire in this market, deal with rapid growth, and/or times when resources are tight. It was a summit about sharing knowledge and experiences, growing in our careers, and working together to help solve the challenges that technical leaders uniquely face. 

To continue in the spirit of Glowing Brightly, we wanted to share some of the key concepts shared by some of the leaders at GLOW. 

Everyone is in pursuit of the perfect balanced metrics approach

Engineering teams such as Auvik Networks, Hootsuite, and DataCamp have been transformed by leveraging data-driven insights, but each of their approaches is slightly different. Their teams have worked hard to avoid the potential traps of Goodhart’s Law and the tragedy of the commons, and what they’ve focused on directly reflects the needs of the business and their engineering teams. 

For example, Charlcye Mitchell, Director of Engineering at Auvik Networks, detailed the importance of Jellyfish as a readily available common source of truth regarding Engineering’s work allocation. Charlcye even uses Jellyfish in real-time conversations with her executive peers when they need to discuss the trade-offs required to achieve certain strategic business priorities. 

Hootsuite looks at a wide variety of data across their engineering teams, and focuses on metrics that lead to desired outcomes, not specific work outputs. More specifically, measuring progress against specific outcomes is much more important than measuring metrics that designate the completion of said outcome. Starting with the highest level business objectives and working their way down to their team’s specific OKRs, they decided that they wanted to increase the predictability in their sprint planning as an outcome while reducing issue cycle time. These two outcomes led them to monitor themselves against complementary metrics that hoped to increase planning predictability without sacrificing the speed of new code deployments and bug fixes. 

R&D Cost Capitalization – The Process Can Be Much Simpler

We were fortunate to have Katelynn Blasi, Senior Manager of Technical Accounting and Reporting at Contentful, join us for a discussion on R&D Cost Capitalization. What’s clear is that this is a difficult but necessary process to get right between Finance and Engineering. Finance will always need to ask Engineering for specific inputs required to capitalize costs properly. This can be very painful for organizations that do not have a non-intrusive process for tracking the amount of time that is spent on capitalizable development work. Luckily, Katelynn was able to provide a few useful tips.  

1. Executives, managers, and C-suite members will find value in understanding your work Allocation or how work is distributed across your engineering team. You’ll be able to drastically reduce the friction between the two groups when you can leverage work allocation reports for management for Finance’s purposes as well. The goal is not to track the work of your developers, but rather use existing tools and processes to allow Finance to take the slice of data that they need to capitalize certain costs. 
2. Explain your software development process to your finance team. Don’t be afraid to lay out the good, the bad, and the ugly. This is crucial as it will allow them to understand what really matters and how R&D work can be translated into capitalizable work. 
3. The more consistent you are about the definitions for parts of the development process across your teams, the easier it is on Finance. Think about how your work can be categorized across all of your teams under a common taxonomy. The less time that is spent explaining what certain work types mean, the easier it is for everyone involved. 

Empowering agile and autonomous teams

Lode Vannacken, VP of Engineering at DataCamp, detailed the impact of engineering team metrics on the Agile mindset, and specifically on the DataCamp engineering team. The DataCamp team has been keenly focused on what metrics are most valuable for gauging and enabling the adoption of agile practices. What they found is that metrics that measure achieving certain outcomes can be too late for the purpose of evaluating processes while they are occurring. For this reason, DataCamp encourages using team metrics as leading indicators of a healthy agile mindset, in a similar way that tracking your diet and exercise regime can help ensure that you achieve your physical fitness and health goals. Metrics that measure Flow/throughput, quality, team happiness, and customer happiness have all helped teams like DataCamp more deeply understand the overall health of their engineering teams. 

In the final session of GLOW, Jessica Matthews, Directors of Engineering Operations, and Diane Yarbrough, Senior Engineering Director, discussed how they set up a methodology for meeting the expectations of Storable’s customers by enabling their software teams to operate autonomously. Their approach is both simple yet deeply impactful, and it starts with transparent communication. They ask a standard series of questions to their teams during their delivery review meetings to ensure that teams are agile, adaptable, and as autonomous as their customers are. Some of them are:

• What is our Do/Say ratio?
• How are we spending our time today vs. how we want to be spending our time?
• When things break, how quickly do we restore them?
• How confident are we to make changes without breaking things?
• How much friction is there to deploy changes?

Thank you to our customers 

The few takeaways that we shared above just scratch the surface on the insights that were so generously shared amongst the engineering leadership community over those two days. What’s clear is that we’re so much better as a community when we share our stories, lessons learned, and ongoing challenges with one another. We thank you for your time, your willingness to share ideas, and the courage it takes. We’re so proud that our customers have leaned into the value of Glowing Brightly, and we’ll do our best to foster spaces for you to continue doing so.

P.S. Aston’s music playlist was the talk of the chat. We’re sharing the Spotify playlist for all to enjoy. 🙂