July 01, 2020
Recently, Jellyfish CEO Andrew Lau sat down with Dave Vellante at SiliconANGLE to discuss the importance of engineering project management platforms and why automating and contextualizing insights with data provides a better way to inform the decisions of engineering leaders and executive teams and drive alignment among all parts of the business. Watch the video, or read the interview below to learn more about engineering management and Jellyfish.
Dave: Hi, everybody, this is Dave Vellante, and welcome to this episode of Startup Insights. Andrew Lau is here with me. He’s the co founder and CEO of a relatively new company called Jellyfish. They focus on engineering management, which is kind of a new space that we want to present to you, Andrew, great to see you, thanks for coming on.
Andrew: Hey, Dave, thanks for having me on.
Dave: So when I see co-founder in a title, I always ask why did you start a company? What’s your “Why?”
Andrew: So the three co-founders myself, Dave Gourley, and Phil Braden, we actually met more than 20 years ago, at a company called Endeca. We had the chance to kind of bring the proverbial band back together, just ’cause it’s rare, the chance to work with great people. And for us, Jellyfish really was coming out of our own experiences. All three of us grew our careers running big engineering teams, big product teams. We realized how hard it was to really lead those teams and connect them to the business at scale. And that’s the problem we just got together to solve.
What is Engineering Management?
Dave: Yeah, so interesting. And Endeca, another East Coast company, great exit, brought by Oracle. And of course, when you say in Endeca, I always think okay, Jellyfish, you guys in the search business, but you’re not, you’re in engineering management. What is engineering management? And how does it relate to some of your past experiences?
Andrew: Great question. So engineering management, the engineering management sector or engineering management platform, as we talk about, really comes down to how we can facilitate the tools to make leading big teams easier. We’ve realized that as you get to larger teams, teams bigger than 50, bigger than 100 engineers, it’s really hard to understand what the team is doing, really hard to make sure that they’re working their best in making sure they’re pointed in the right direction. And even further, how to connect that to the business and how to make sure the business is successful in the effort that the team does. And as for us, it’s really around making tools and processes available that they help accelerate the act of leading big teams.
Dave: So when you think about it, I mean, it’s really the problem you’re solving is visibility, kind of what’s going on in engineering and providing metrics. Is that a sort of a fair, high level?
Andrew: I think it’s a perfect high level statement. When we actually got together and talked about the problem space we all saw as we led these big teams. We quickly drew an analogy to, when I started my career in the late 90s, there was a time before Salesforce and CRM were pervasive. And so really quickly, we drew a quick and easy analogy that said, hey, why isn’t there a Salesforce for engineering? That is, why isn’t there that same leadership and executive visibility into how a team is progressing and to make sure it’s aligned with the business?
What are some of the metrics you need to be tracking as an Engineering leader?
Dave: So I don’t run engineering at SiliconAngle, but my co-CEO and partner John Furrier does. But I’m always like asking him, hey, what are you guys working on? What are the deliverables? What am I going to get and when? How we do it on quality, and so forth and so I think just scanning your website, reading some of your blogs, these are some of the things that you really focus on. You wrote a five-part series. I’m dying to see part five, but four parts are out. I want to dig into some of those. I think you called it, five things that you should present to the board.
Andrew: Yeah, you know, a great question around, there’s a series and we’re four or five into it. I’m talking about: what are five slides that heads of engineering should be showing to their boards or even their executive management teams? You know, early on in the process, before we actually started the company, we did a ton of research, talking with leaders at scale, trying to ask them, “how do you manage your team? How do you connect into the business?” And out of those conversations, asking folks, well, what slides do you show your board meeting? And the answer was, there wasn’t a ubiquitous answer. People were looking for answers, and so we really synthesized a number of different leaders that we thought were really successful in this world, and put together this series to talk about, what are the metrics that people should be measuring?
Dave: Well, let’s talk more about some of those metrics so you know, I mentioned so what am I going to get? When what are some of the other key things that people are focused on? I mean, obviously, quality, where I’m spending my money. But what are some of the ones that you’re seeing, aligning with business and really driving business outcomes?
Andrew: So part one I think you talked about which is, what are you getting? What got shipped out the door? What’s coming down the pipe? I think job one for a leader of Engineering and Product is to talk about what’s coming out, in the same way that sales’ job is actually hit a revenue number and talk about the pipeline coming down the way it’s an engineers job to actually ship new product that you can sell, your users can engage with, so that’s definitely slide one.
Slide two, you already alluded to too, is about quality. I think if you’re shipping product that actually can’t hold quality in the eyes of your customers, it won’t last very long. So it’s really important to show command of quality and actually show metrics that actually measure quality over time in the lens of your customer.
Slide three, we’re really talking about alignment. Making sure that your team is spending your dollars, time and effort in the right way that actually aligns with what the business wants. So examples might be, if you’re a company that splits time between enterprise and SMB efforts, well, making sure that the features the team is working on actually aligned to the strategy of the company, right? And you can’t do that if you don’t measure that.
And then slide four is around capturing broad level productivity. Is the team healthy moving forward?
And then the last of which, really the preview coming up for the next segment here, is going to be around the team and hiring. How is the team holding up? How’s the morale? And how’s the actual hiring pipeline looking and ramp? All in terms of new employees. It’s really the people side of the engineering leadership.
Why Developer Productivity is Necessary but Not Sufficient
Dave: Cool, thanks for teasing that a little bit. I’m glad to hear it’s not just about productivity, ’cause there are tools out there that can measure developer productivity, but seems like you’re taking a broader approach and building a platform to really take a more end to end sort of lifecycle view.
Andrew: Yeah, I think the way we really think about it is, look, productivity is really important. I think it’s necessary but not sufficient. You can talk about a boat: you can row faster. But if you’re rowing the boat in the wrong direction, who cares? So it’s as important to make sure that alignment is in place and actually making sure that the rest of communication and context is really in place to make sure that team succeeds in the lens of the business.
Use Cases of an Engineering Management Platform
Dave: So let’s talk about customers, I mean, maybe you could give us some examples, some of your favorite examples how you’ve impacted their business.
Andrew: Well, I think if you look at our website, there’s a few case studies up there. There’s Buildium up there, there’s Salsify, and Toast. I think all three of those really talk about different kinds of use cases around how we actually affect them. So one of which we’re really helping them on alignment and making sure that their team is working on the most important things, And, and in those situations, when you’re working on the most important things, you’re really essentially getting opportunity cost of engineers and making sure that they’re driving towards things that you really will help the business. So if you’re looking at it that way, you’re finding engineers that can help you progress faster, but you’re building more product faster, because you can focus the energy where the team is going. And so that’s case one, I think another case is really making sure around quantitative management visibility, making sure that the team is visible in the metrics and in their output to make sure that they’re performing their best, and that might mean everything from automated performance management to just making sure that people aren’t left behind and making sure that they’re the team is actually healthy in their function.
And then the last of which is really around capitalization, which is a financial process and really automating that side of the house. Capitalization requires, traditionally, Engineering leaders have to manually fill out spreadsheets for finance, and for the accounting team to make sure that they’re actually able to account for where the team effort is going, and then it can actually capitalize it correctly when we treat it from a financial perspective. And so we automate that process that just makes everyone’s lives easier. So you’re no longer manually entering data on a week by week basis.
Digging Deeper: How it Works
Dave: What else can you tell us? About your pricing model? And how you’re going to market?
Andrew: Yeah, we are a SaaS hosted application. We also have open source agents that have been deployed on premise, whether to work with complex network architectures or deal with specific redaction concerns, so we’ve got to operate in on-premise environments in that way. You mentioned our pricing is SaaS-based. We broadly price annually. From a broad strokes perspective, it’s relative to the size of the engineering team. Very simply put, an engineering team of 300 people is a lot more complicated than an engineering team of 30 people. Put it that way. And the pricing reflects that. And then to your question around what else I can talk about? Well, you know, I made the analogy earlier around like they were trying to differentiate like what Salesforce did for sales.
What I mean by that is providing that executive and leadership visibility to that department. If you’re looking at the innovation that Salesforce brought in the early aughts, it was really getting stuff out of notebooks into the cloud through manual data entry, and in contemporary sales, I think there’s less of that these days, it’s all through plugins and voice recognition and stuff. And in the same way, on the engineering side, we’re not in the business of actually asking for new data entry. In fact, we connect with systems engineers already using the JIRAs, the GitHubs , the Gitlabs, their testing tools and their CI tools, and all of those things emit what we call engineering signals. So the engineers don’t do anything differently. We collect that data, we connect to those systems, we clean that data, normalize and contextualize it with respect to business data.
And that’s where the insight actually comes from. Because if you just look at the raw engineering data by itself, there’s not a lot you can do with it. I joked with you in our kind of earlier conversation, which is, you might look at the 300 Git pull requests your engineers are producing. It doesn’t really help you figure out if you’re going to do great this quarter, right? And so for us, we really bring that and contextualize it and make sure that you understand it in a business context, to talk about like, hey, is the team accelerating and being successful in the ways that we need the business needs them to do.
Want to Learn More?
Software engineering is the core of modern business. There’s been so much innovation in how software engineering is done, but so little on how to lead that organization. Jellyfish is elevating Engineering Management. At Jellyfish we want to give engineering executives the tools they need to be great leaders – to drive the product strategy and company direction, and optimally execute the operational components of that strategy. To learn more about Jellyfish, visit our website.
