Neo4j just raised the biggest round in database history and their CEO, Emil Eifrem, joins us on the podcast to tell us about his experience transitioning from a day one CEO to running a company with more than 500 employees.
In this episode, Eiso and Jason start to scratch the surface on the importance of data and metrics for software engineering teams and how engineering leaders can use data to ask the right questions and help their companies to thrive.
https://www.podbean.com/player-v2/?i=dhncr-10c136f-pb&from=pb6admin&share=1&download=1&rtl=0&fonts=Arial&skin=f6f6f6&font-color=auto&btn-skin=ff6d00
Heard a term or concept you want to learn more about? Jump to topic explainers
So I call this the competence, confidence spectrum. Most engineers are going to grow up, trying to show their competence. Most high-level executives don't understand the competence, so they need to proxy your confidence to competence. This is why sales leaders in my opinion make wonderful - or have in the past made wonderful, - high-level executives. Because, to the jock mentality, they're like, "shit, yeah, we got this". And the CEO is like, "they got this, they'll figure this out. I'm confident". But when you walk into a room and iterate 15 different ways, something could go wrong, the CEO is like, "I don't know what to do with this information". So the trick I found is to blend those into the competence confidence argument, which is: "lead with confidence, show a little bit of competence, and end with confidence again".
Everyone who knows me knows that I very commonly say "all problems in the company are communication problems and all communication problems root from lack of trust". And I know that's an exaggeration to an extent, but you see this even within your personal relationships, you need very few words where you can even say the wrong thing, but if your basis of trust between two people or two groups of people is strong, then you assume the best intentions and you go to the next step. And so I think that, as the foundation of best in class, it probably couldn't have been said better.
The data helps you ask the right questions. And that's really where it needs to be used. And it's this fine balance between some level of target setting and some slight level of gamification. There are things that we can all agree on, like CI time. You want the engineers to work on bringing CI time down as low as possible within reason because it's going to make everyone in the organization faster. But if you go and say, "Hey, velocity is the one metric we care about, and everybody has to optimize for that", you're going to have unintended consequences. But like Jason says, if you see velocity slowing down, and your release frequency slowing down, quality issues going up in the time to respond to bugs, that raises interesting questions, and those questions actually get answered 80% with qualitative information, not with quantitative information.
It's critically important that engineering leaders hear on this podcast that velocity is their responsibility. That's part of what an engineering leader is supposed to do. Now the challenge is going to be about where the prioritization happens. And so this is where the CEO's empathy has to come in. You have to be able to articulate why a set of things are happening or prioritization. You have to get everyone on board with that. You do have to socialize that, and you do have to let people understand why you're making certain decisions and trade-offs. And then your job is to ship software, to ship high-quality software. And realistically, you're supposed to get better as you grow, faster as you grow. But this is actually the counterexample. Most organizations get slower and more bureaucratic, but the point of adding more people is that you can go faster, do more things and do it in scale. So you should be able to find a way to keep your velocity or even go up as you scale. Most people don't.
<aside> đź› PLG: Product Led Growth
</aside>
Product-led growth (PLG) is a business methodology in which user acquisition, expansion, conversion, and retention are all driven primarily by the product itself. It creates company-wide alignment across teams—from engineering to sales and marketing—around the product as the largest source of sustainable, scalable business growth.