Why Isn’t There An App for Engineering?
Sales has Salesforce. Marketing has Hubspot. Support has Zendesk. What’s the equivalent for Engineering? There isn’t one. And that is frankly quite surprising. Organizations of all descriptions have been trying to digitize / become software companies for a decade or more. Much of our day-to-day existence relies on software. Yet despite this strategic and practical importance, there isn’t a single platform Engineering leaders can use to manage and report on their function like we have for most other major business functions.
What Would an App for Engineering Look Like?
To explore this, let’s first review what a CRM like Salesforce does conceptually. It provides a CRO, a high level GTM dashboard with the ability to drill into how things are progressing, identify issues, investigate them, etc. For example, let’s assume that the company sells multiple products. Hitting the overall number requires that each product area hits its quota. How are the different product sales teams performing? How about each territory and region? What challenges or blockers stand in the way of progress? For example, are we getting enough leads at the top of the funnel? How about initial demos, follow on demos, POCs, etc. Are there segments of this sales funnel that are too leaky (ex. demo 2 to POC conversion is awful) suggesting there’s a blocker? Is the blocker an objection we don’t handle well? A missing feature? etc. Identifying and solving these issues to remove friction from the sales process is the hallmark of all great GTM teams.
You are probably already seeing how this relates to Engineering. The apps and services different Engineering teams are working on are Engineering’s “products.” The company needs Engineering to deliver those in the same way it needs Sales to sell. The Engineering leader, like the GTM leader, needs a dashboard that displays the overall status of the Engineering function as determined by the health of a broad range of factors, like delivery and quality. And as with Marketing and Sales, productivity metrics alone aren’t sufficient. You also need to measure quality. In the same way that a ton of poor quality leads aren’t helpful to the business, neither is a mountain of low quality code. Identifying and solving issues to streamline the delivery of quality code is the hallmark of all great Engineering teams.
Doesn’t this already exist?
Jellyfish, and things like it, come close as their metrics-orientation allows Engineering management to measure output and report it to the business. For example, these engineers are working on this project and made X commits each week last quarter, etc. This is great for reporting the “what” to stakeholders outside of Engineering. And it really is great – for decades Engineering leaders have been desperate to get this kind of visibility and to deliver it to the organization. But these metrics are not especially helpful for managing within Engineering because they lack context around quality and the “why.” For example, the reason we can’t improve the team’s output is poor code quality, which is the result of a junior team that doesn’t understand security best practices (or what have you) and keeps delivering subpar code. Blind spots like this writ large across an Engineering organization, plus the advent of code generation, puts Engineering leaders in a very uncomfortable position. You could crush all of your productivity metrics – Jellyfish is green like never before. But the code is so bad, that in the fleeting moments when the service isn’t down, it’s being compromised by bad guys exploiting the many security holes! In sales terms this would be the equivalent of hitting all the metrics – leads, demos, POCs, proposals – but missing the sales target by a country mile and having at best some hunches about why.
Hasn’t solving the why been tried before?
You bet! With a different tool – Sonarqube, Blackduck, Dependabot, etc. – for every aspect of quality, be it security, quality, or what have you. And each is carefully curated by some of the best Engineers on the team. Engineers know that doing this is important and want to do the right thing. So they find the tools, configure them, run them, parse the results and otherwise work hard to bring signal to the noise. But it’s painstaking, tedious work – no fun. And they’d rather be coding, which is what the organization really needs from them. “I know checking our dependencies is important, but can’t it wait until I finish this code so we can ship this month?”
Because evaluating Engineering for both throughput and quality has been so hard to do in the past, it is done sporadically at best. Probably the closest we get to this ideal is when a software company is bought. This process typically includes a substantial technical due diligence effort so that the acquiring company can thoroughly understand what they are buying. The nature of the software, how it’s built, its quality, its security, and so on. Also the size of the Engineering team, their skillset, throughput, and more. Lacking tools to automate this work, we throw bodies at the problem… a handful of senior engineers from the acquirer, more from the acquiree, and often yet more from an independent 3rd party. A few weeks / months and $1M+ in software and fees later, you have a detailed (but snapshot) evaluation.
Flux Solves The Why
AI plus automation has been the missing ingredient to date. We needed a way to not only run a multi-faceted analysis across an entire codebase, but also a mechanism to turn the resulting noisy corpus of results into insight. Flux solves for this – automatically surfacing issues across quality, complexity, security / privacy, and 3rd party risk. Engineering managers gain a comprehensive, top-down view of the code they manage. Next up is taking Flux evaluations from snapshots in time, to something you can run on a schedule, anytime there are commits, built into your CI/CD pipeline, and so on. Add productivity metrics to the mix, and voila, the elusive app to manage Engineering!
