David led engineering at a 13,000-person company and noticed the function had almost no data on team focus or costs, unlike sales with Salesforce. By the mid-2010s, source control and task tracking made it possible to build visibility into engineering work. The founders say the problem existed for decades but only recently did the technology and data maturity align to solve it.
Chapters
Another question kind of related. I mentioned a little bit earlier about how, um, Andrea, you had first told me about the idea for jellyfish and how it was, you know, something that instantly struck me as being just a really fantastic idea and something that needed to exist. But we've never really gone back and dug into, like, how did you guys actually figure out the whole concept for Jellyfish, where did it come from? And we've got a question from Tom who would like to know that exact same thing. So David, how about you take that one on?
Sure. Yeah, so I mean, to back up a little bit, I mean, my career has been in startups from day one. I followed my advisor to a company that he started back at my first job. But my gig before we started Jellyfish, I, my startup was acquired by a much larger company in the space, and I suddenly found myself at a company that was 13,000 people. You know, engineering was like north of 1,000 people. I had like 500 folks working on the teams that I worked with. And it was an interesting lens as a leader of those teams where, you know, we would do things like weekly, weekly readouts for the executive team where we would go function by function through different departments. And, you know, sales would show up with every metric and KPI and leading indicator of how that team was doing, what they were performing in. We'd have all this insight into what was going on in that organization. Marketing, the same thing. But it would get to sort of the engineering section, and we had data to present, of course, but it was often stuff that didn't really map to the business. It was really hard to answer some really basic questions like, what are the teams focused on? How are they allocated? How much is it costing to do different things? So those meetings were often a little rough, and I didn't enjoy them very much. But it's there that I really started thinking about, like, how is engineering the least quantitative department in any company, and why can't we really explain and show our work? So, you know, fast forward a few years, I was there for about 3 years, and then I relocated to Boston and linked up with these 2 guys. And I think we had all had sort of similar experiences sitting in those rooms and not really having a lot of data to back up our intuition. And so, you know, I think the other thing that really helped us back into it is that we're all old enough to kind of remember the world before Salesforce existed. You know, back in the day at Indeco, when the VP of sales would walk into the room with his Moleskine notebook and open it up, and there was the forecast. And we could all debate, you know, and argue with him about whether a deal was real or not, but it was all his intuition at the time. And if you fast forward from there, you know, Salesforce really captured a lot of data, and a whole ecosystem has been built on top of that data that's really made sales a lot more understood, and you can really analyze what's going on with that. And I think we started the thesis with like, gosh, a lot's happened in the 20 years since we first worked together. There's a whole tool chain that engineers interact with, and there's a lot of data that maybe we can leverage to paint a better story and make engineering a lot more transparent to the rest of the company. So I think that's where we started. I don't know if you guys, it was any different for you, but that's kind of how I backed into it.
I certainly remember talking to you about all this stuff, Dave, and I also remember like all my versions of it, like whether it's like the 5-person team where the, you know, being founded by a CFO who just doesn't get engineering and they need help, or whether it's a, you know, any size company in between. And I think all signs pointed to like, you know, this is crazy. There needs to be, you know, there should be an app for that. By 2015, 2016, when we're seeing this in the market. And so I guess the only other plus one I'd add is that by that time, enough had changed because this is like a decades-old problem, right? We lived through this when we were in our 20s. We may be older than in our 20s right now. And by now though, it became possible. The data exists, the tools and processes existed. Where, you know, source control is no longer, you know, stashed on a server somewhere. And, and, you know, and, and the task list of what you're doing is no longer captured in some like 50-page Microsoft Word document. So it was, it was kind of a good confluence of, you know, there's a need for this, and we see it in companies large and small, and the technology exists and the data exists to really, to really bring something to bear here. And then finally Andrew agreed that this was a good idea after a lot of, a lot of cajoling. I was the one dragging my feet.
I agree, I will own that. I was like, "Ah, we're engineers, we're persnickety, this is gonna be hard." Right, it is hard, but I think it's all hard problems.
Tip for the audience: go after, find something hard and go after something that's hard. Like the hard is the reason why you should do it, not the reason why you shouldn't.
