Today, Rebecca and Ben discuss non-linear careers, traditional engineering career ladders, acquisitions, and more.
(02:33) Ben’s journey to VP of Engineering
(03:24) Sentry’s growth
(05:08) The ladder: differentiating engineering levels
(08:45) How Ben became the Co-VP of Engineering
(12:42) A new role focused on innovation
(16:40) Building an emerging tech team
(19:26) Preserving innovation outside the innovation team
(21:37) Lessons from acquisitions
(26:11) Leading Syntax.fm
(28:34) A company within a company
(30:36) Non-linear careers
Rebecca: Ben, hi! How’s it going?
Ben: Hey, Rebecca. It’s going okay.
Rebecca: It is great to see you. We were in a pre-recording session just now and we were talking about how long it has been since we last saw each other, and I think neither of us can actually recall anymore, but it’s been a while.
We’re going to talk about a whole bunch of stuff. Your career and your kind of recent project, which I’m fascinated by. But first, just tell me who you are. Who are you? What are you doing? Where do you work?
Ben: Yeah, my name is Ben Vinegar. I work at Sentry (sentry.io) which is an application monitoring platform, error monitoring, and performance monitoring.
I’ve been at Sentry for over eight years now. I joined in 2015 when the company was only about four or five people. At that time, I joined as a software/UI developer. I had a couple of roles. I have a background in building embedded commenting widgets.
Rebecca: Right so you were at Disqus before, back when like blogs existed.
Rebecca: All that fun stuff.
Ben: So UI developer, library and SDK developer.
And as the company grew and sort of became more successful, I became the company’s first Engineering Manager. I’d had some management experience in the past. I suppose technically I was Disqus’ first engineering manager for a very brief period, and I led a team at Shape Security briefly. And I was pretty motivated, I think, by those experiences to get back into management.
Rebecca: So from there you continued to climb the ladder. I’ve never been a VP of Engineering. How was that journey and how was that role?
Ben: Before I got that job, I even had an intermediate job, which was Head of Product Engineering. And, then again, as the company grows, you need people in these different roles: who’s going to do the planning and the hiring?
The company just gets to a size where you need somebody dedicated to these responsibilities. And, I suppose that I looked the closest like the person who was doing that. But I do feel a measure of pride that I joined the company as a developer, then a manager, and then became a vice president.
I feel like these were sort of acknowledged steps — like a journey — because sometimes you can join a company and just roll right into vice president of engineering with very little experience, and that’s totally okay, too. I do think that these sorts of interim steps of demonstrating success at different levels worked for me.
Rebecca: So tell me about the growth of Sentry during that time — eight years is a long time. You were there pretty close to the beginning. Now it’s kind of a household name in developer land. What did it look like going from 3-4 other people to how large Sentry is now? Were there any interesting moments along the way that were particularly challenging or particularly enlightening?
Ben: I can think of a couple of moments that were interesting to me and I think are relevant to this podcast and what we’re talking about.
A good example is when I became Vice President of Engineering. We were a 20-person company, and when I first joined, and probably for that first year, it was seven or eight engineers, a designer, and a growth hacker. And then maybe an office manager and an HR start to show up — all these facets of the business just start showing up. At 20 people, it starts to somewhat resemble a healthy business.
But some of the moments that stick out for me are when you inevitably hit thresholds where what you were doing before just doesn’t work anymore. Six or seven people in a room, and Sentry's first office, which was in Pachero Hill in San Francisco, was literally just a room with one conference room. It was probably 400 square feet. So communication is super easy.
We had one remote person, and everybody else was in the same physical space. You just take your headphones off, look across the room, and get someone’s attention if they’re not responding to you on Slack — communication is really easy. But then you get to 20-30 people and these things have to change and also the relationships change, right?
A lot has been said going from like a pretty flat hierarchy to now needing communication channels. And so I got to be a part of that in introducing some of those earlier concepts, like engineering levels and titles. That was a moment that was probably very frustrating for me and for others, because we made a conscious choice that we were going to sort of acknowledge that people had different skills on the team.
We were also bringing in people with different experience levels, as this is expected of more mature businesses. And then you start to have people in hiring conversations asking “Am I gonna be a senior software engineer?”
And when your answer is “Well, we don't actually acknowledge any of that” you don’t sound very credible as an organization. I think externally you see an organization through their marketing content, their website, the product that they’ve built, and perhaps the personas of the people that work there, right? I think it feels always more professional, that’s by design.
Ben: Of course. But the reality for many of these businesses is that you’re figuring out as you go, you face these problems and try to solve them. At that point in time, that meant introducing levels to solve a host of things, whether internally, externally, new hires, etc.
Rebecca: What do you think of — this is a little bit of a diversion but I've been thinking a lot about — career ladders? I'm just curious how you’ve seen a career ladder work.
Ben: That is a great topic. I would say what I was referring to earlier was sort of the very beginnings of that, which is just even acknowledging that different levels exist and the guides. I'm sure you're familiar with this.
I remember looking at Camille Fournier’s content which I think was the very beginning of companies getting very public and talking about what their ladders were externally, which was a bit of an interesting time. And that coincided with what was going on at Sentry around 2016-2017 when we were starting to do that. And that version was very minimal. It has been a constantly evolving thing. I want to be very clear to say I didn't come in and in one fell swoop institute a successful…
Rebecca: The perfect ladder?
Ben: Yeah, it didn't look like that — it's an iterative thing. I would say that when it comes to ladders, for me and my career as an IC, I never had any of this. That could be a combination of things like the time – it was a different time. The maturity of the companies that I was working for – I worked for a lot of startups that went through what I'm describing. I was so engrossed in the work that I just didn't pay a lot of attention to it.
In 2014 I got a job at Shape Security, and that was the first time I'd ever been acknowledged as a senior software engineer, and at that point, I'd been doing this for 10-plus years. I suppose I looked at it and thought I guess that makes sense – I didn't put a lot of weight in it. But today there's a lot of weight in it and that's my perception. I don't know if that's right or wrong I just think that the expectations have changed. This industry and how we develop talent has really matured.
I think part of that maturity is in the way that we talk about it in the guidance that we give people. Part of it is also that there's been a little bit of an alignment between companies — not planned, just sort of... It probably even goes back to Camille Fournier and the public dialogue that has occurred in which people have published a lot of their engineering ladders.
Rebecca: So, you become the VP of Eng, and then you became the Co-VP of Eng. I'm really curious to hear the story of how you arrived at that decision to be a Co-VP.
Ben: I think that that would probably be an honest conversation with me and my boss – then who at the time was the Co-Founder of Sentry, David Cramer, who was CEO at the time.
I did feel a lot of pressure, and a ton of responsibility having that job, and I wanted to demonstrate that I could do it all. I think there was a little bit of hubris back then and feeling that I could be successful at that… But you don't know what you don't know.
And it’s so much easier to look back at that moment and to see I was probably quite misguided. Frankly, I don't think that this was a dramatic decision or a disappointing decision for me. But I think there was an element that I was trying to manage everything and it was really hard. And so, it didn't take a lot of convincing, frankly.
Sentry is a unique product: it is an engaging product for software developers that lets you debug your software. It has a pretty slick UI. I enjoy using it. But it’s also a pretty deep infrastructure product. It's ingesting — at the time, I’m not actually sure of the number now, but — billions of errors a month from 100,000 software products distributed around the world.
I think not really having that expertise puts you at a disadvantage in many ways. Your ability to gauge the designs and the decisions of the people who are working under you. Your ability to attract talent. If you're a deep infrastructure engineer, do you want to work for a person who doesn’t potentially have the expertise, deep appreciation, or understanding of your field?
Deep appreciation isn’t the right word — I have a deep appreciation — it’s more about whether am I going to recognize accurately how people are putting this together in the same way that somebody else might, who has done this for a long time, who has worked with teams, who has solved, who has seen many of these problems, who can identify talent differently.
Ultimately, we hired a VP of Infrastructure. We worked together for the next few years. That VP of Infrastructure is now and has been the singular VP of Engineering at Sentry for the last few years. Name is Vlad Cretu and he’s great. We worked together for a while and we did things like build out more of that engineering ladder and introduce new layers of management.
It’s also just fantastic to have a peer. Having other people with whom you can collaborate and brainstorm and solve problems just as you would if you were ICs on an engineering team trying to solve hard technical problems.
Rebecca: You switched out of that role pretty recently into a different VP role at Sentry. Tell me about that.
Ben: About two years ago — and this is probably four years as VPE / Co-VPE — I took on a different role, which is Vice President of Emerging Technology.
And I do want to say this: I think that a lot of the ways I found myself in these jobs were the result of just honest conversations with my boss about how I was feeling, what was energizing me, and what could I be doing that could bring value to the company and be interesting.
I guess that's a bit of a way of saying I was a little burnt out.
It's a hard job. I have a lot of empathy for people who take on sort of, you know, senior leadership positions. Add the pandemic on top of that — I suppose that I was ready to do something new and so I had a conversation with my boss and, at the time, we thought it’d be interesting. Would there be a way for us to introduce new products or new solutions to Sentry?
And I'll add a little background to that, which is: it’s really just a continuation of the story: at this point, I think Sentry could have been 200 people, maybe more. Today it's approaching 400 people to put this into context. Earlier we talked about having a few people, you’re all in the same room, super easy. Then you introduce different mechanisms and ways that you get together and build stuff.
I would say another probably big moment for us in the company was when — and I think a big moment for any company and I’ve spoken to other companies about this moment, which is for a long time, you get away with like very sort of top-down product development: ideas come from the top, people kind of riff on that, but that breaks down, right?
If you’re going to scale — and scale means so many things: scale the infrastructure, scale the people, scale in the sense of how you bring ideas and actually execute on them. If one person is just coming up with all those ideas, and that’s a real simplification here. I don’t want to say it’s singularly one person, it’s more complicated than that. But let’s say it’s a handful of people who are really driving some of that. There's only so much you can do with that.
And I would also add that the further you become removed from people who are setting that direction — as an engineer or product manager or designer — you just become less enthusiastic.
Ben: Right? You get more and more removed from the decision-making. At some point, we handed more of that over to teams. Like this is your team, you have this identity, this is the problem that you’re going to solve, this is your focus area, this is what success looks like for you. Can I even argue almost like a little engineering ladder, right?
And I think that’s that is such a great mature moment when companies get there. I’m sure we could have done better on so many details I’m glossing over. I’m sure that there are people in the company who would argue that maybe it’s not that great. But for me, with the context of what it looked like before and what it looked like after, I look at it as a dramatic improvement.
That allowed teams come to the table with their ideas and speak more about what projects they wanted to invest in that would get them the success. That worked for a while, and it certainly let people execute more, and I think we managed to achieve more as a bigger group.
But of course, inevitably, everything has trade-offs, everything. Just when you define these structures and you have a team with a mission and they’re executing on that mission, what becomes hard — and what happens — is when people want to do work that’s outside of those missions, right?
Well, here’s a possible solution: you build a team whose mission is to step outside of the scope of those teams, and that’s what emerging technology was for us. And I don’t think it’s a unique thing that we were doing. As we were sort of coming up with this, we were looking at what other companies were doing in this space, many of whom have talked publicly about it.
I remember being influenced at the time by Cloudflare. They had an identically named team, and my understanding is that Cloudflare Workers — and a big part of their business — came out of that team. And I do like like that example because I think Cloudflare Workers was not in the traditional space of what Cloudflare was doing at the time if you went back in time.
At the time, this is more internet firewall, whereas today you think of them as a cloud company, right? That’s that’s some terrific innovation. So what could that look like for us?
Rebecca: That’s what I was going to ask. What does that look like for Sentry?
I was very interested in pursuing that more from a developer focus and being able to connect it to the observability data that we already have: errors and tracing. If I could watch a replay, see somebody have a poor experience, and then trace that down to a server call in Python… that would be incredible. That’s what innovation looks like for me.
So that was part of what we did, and at the same time another part of that with what I worked with was an acquired company. So Sentry acquired a company — and this was all announced and talked about a couple of years ago — called Specto. They were building a mobile continuous profiling solution.
And since I had worked on Sentry’s APM product as part of emerging technology, I kicked off the Session Replay initiative and also worked with the founders of Specto to bring them into the company, to create a plan for how we integrate their technology and bring this to market. So that was also a really fascinating part of that job.
Rebecca: How does it work when you have this emerging technology team? Doesn’t everybody just want to be on the emerging technology team? How does that work culturally in the organization? Is it a destination?
Ben: That’s a really good question. I think a couple of things we did is we did recruit from different teams in the company. It’s not that we built another team, and hired 10 people externally to work on that team… that would never sit well with me. So we built a plan for the things that we wanted to build and we looked around the company and thought, who has skills that would match well with this. And it was a bit of greenfield product exploration. Are there people who’ve participated in hack week, or done some demonstrative work that we felt that would help us be successful at this?
So whether there was some simmering resentment at not being able to join this team, maybe, but I think the best answer to that, Rebecca, is that there's just a lot of cool stuff happening at Sentry.
Rebecca: “You don’t have to be on this team to be doing cool stuff.”
Ben: Yeah, I say that really honestly. It's a source-available product — depending on the point of time, it was an open-source product, but there was a licensing change. That’s a whole topic, won’t get into it. We’re building software for developers and it’s a product that we use ourselves.
So everybody here is kind of like building something they selfishly want and get to use. So I think a big part of that dialogue is that innovation isn’t strictly happening over here on this new kind of team that we’re building. We really want it from everybody. It’s: how do we create new categories of the product to allow for more innovation?
And today, by the way, those products were successful and they became parts of the product. And those are product teams now, like any other team.
Rebecca: It’s a great point that innovation doesn’t need to just happen on the team that has a name that sounds like innovation. It can happen throughout the company and I enjoy very much working on products that other developers use because that is very rewarding.
You’ve had a couple of experiences — you just mentioned one — with acquisitions and then more recently another. I haven’t ever been very close to an acquisition. Do you have any sort of lessons or are they distinct and unique?
Ben: I would offer that I had not really been a part of that as well, right? Disqus did get acquired at one point. I wasn’t present for that. So I guess I’ve always skipped town in terms of being acquired. And have certainly never been in a position before to be in a leadership capacity to oversee some of this.
So I do think that a big part of my management and leadership style is really trying to put myself in the place of people and how would I like to be treated. I think I’ve touched on that a couple of times over this conversation.
I have been fortunate to know people who have sold companies – sometimes in a fantastic way, sometimes in a tears way. Where “Hey, we made some money” and then I probably never see them again cause they’re out in Macau gambling. But I would say a more common version of that is that acquisitions are not always like how they’re portrayed. For many people, it could mean a great bonus. And here you go, here are the assets, I will support this for the next year and then I’m gone. I think that’s a very common version. I’ve chatted with people over coffee or at the bars on that topic like “Hey, congratulations, that must be incredible! Well, let me tell you…”.
I think in approaching this and being somewhat responsible for the success of bringing another company to the company and being successful — and I want to be very clear that this is a huge team effort; I do not take any kind of singular victory here, but only to say that — I certainly was a part of it in terms of the org chart. I think it’s not unlike traditional management in the sense that when people come into the company, there is a different range of expectations from who’s working there. In an acquisition situation that could be a multi-month or longer conversation with the founders, at that point they may have a great understanding of what’s going on and of course, they’re probably the most financially incentivized — that’s kind of how startups work, as we’re all aware.
But if you’re an employee, there's a lot of different feelings that come with that. Ideally, it’s also financially lucrative for you, but even if it is, there are anxieties. You were working for a company before and you kind of understood what those expectations were. You had a relationship with your boss and now we’ve just gone and switched it.
So I say that I think it’s like traditional management because if I think about the things that were helpful it’s really trying to understand what motivates everybody. Why did they join the original company? What do they want to do? Do they want to continue on that? Are there other career things that you think you could achieve now that you’re part of this bigger organization? That’s something to look at. Maybe there were parts that we could fulfill in a different way?
And it’s just trying to match up, trying to do a decent job of trying to understand where everybody is. What are they enjoying doing? How can we make each other successful? I think that if you do an okay job at that, ideally, when a year goes by, people are still around because you’ve created plans for people, or they enjoy the working environment, or we actually delivered on the promise of not throwing out your product, right?
You have no trust — I think that’s what it really is — and you have to build that trust and you do it incrementally. Then over time, if you deliver on what you said you were going to do, then I think things get a lot easier and it’s not too crazy. This probably sounds like it’s loaded with drama, but…
Rebecca: It is! It’s an upheaval. I haven’t been acquired. I have been in the vicinity of acquisitions, but never directly related to it. It’s an upheaval and it’s sudden. Suddenly, your job changes overnight and I can imagine that there’s some drama, of course.
I want to wrap up here, but I did want to make sure we talk about Syntax, which is another acquisition that y'all have done recently, and it’s a little bit odd: it is not a software company. So tell me a little bit about Syntax and what you're up to with them now.
Ben: So Syntax — or Syntax.fm, if you want to check it out on the web — is web development tasty treats. It is a web development podcast hosted by Wes Bos and Scott Tolinski. They've been doing this since 2017. They are independent educators and creators who came together and — like other people — started a podcast, but they’ve been pretty successful at it. They have a pretty large audience and we like it. Sentry has been a supporter of Wes and Syntax for a pretty long time. I think we sponsored one of Wes’ Redux courses at the end of 2015-2016. He remarked to me that only Sentry and Firefox have done something like that: been the singular sponsor of a web course.
So we have a relationship together and we’ve sponsored the podcast. So I think that businesses right now are looking at ways to engage their community and their audience and we see just a tremendous overlap in what Syntax talks about as being very relevant to Sentry’s customers. What we want to do is make it bigger. Like “Wow, you’ve been really great at this!” and running a podcast is a lot of work, as I’m sure that you know, Rebecca.
Rebecca: It takes a village.
Ben: It does. It takes a village. It’s a lot more than just the recording. And what would it look like if — this team has been successful at reaching people, how can — we help you reach more people? That’s the way that we’re treating it. Syntax is its own independent entity within Sentry and we try to support them. One of the ways is that I work with them full-time in a similar kind of role as previously with a previous acquisition.
Rebecca: I think it’s cool. That’s a neat story, and yeah I mean I’m doing a podcast right now for the same reason that we want to engage with people who we hope are our users. Are you enjoying getting to be back in a smaller and less defined role, maybe? And no, I don’t mean your role is smaller — sorry — that’s not what I mean. I mean you’re working with a smaller group of people than you have.
Ben: If you’re talking about managing an organization with directors, managers, engineers, and everybody has their own unique ladders and things that they have to execute on… Yes, it is smaller. I think it is a unique role. And I’m certainly excited because Syntax is really cool. Wes and Scott are cool, and I think people do incredible things out there on the internet and it’s fun to be close to it.
For me personally — I’ve been eight years at Sentry, and I think over the course of this — this has been like a career retrospective and picking things out. I don’t know if this is wildly out of touch or crazy, but I do encourage people when they want to do something new. Some people — I wouldn't even say some people, I think a lot of people — would rather just go interview somewhere else than have a frank conversation with their boss about what motivates them and what’s interesting.
And I want to be clear, that's a really privileged thing. There's a reason why people don’t do that, because maybe in expressing that desire, there’s a fear that maybe some will feel that you’re not 100% on board with what they’re doing, and that could put you in a position. And depending on where you work maybe that’s a very real risk. I don’t know. So I do want to acknowledge that.
But I think that if you have a good relationship with your boss… Companies have a lot of problems to solve; they’re very messy and the problems don’t always line up cleanly with the engineering ladder. I think that if I were to bring this full circle a little bit, in some ways if I had a complaint about engineering ladders, it’s that they put you on a rigid path. It’s helpful because it gives you a guide to follow but it also limits your imagination a little bit for what that is, and that’s kind of by design because you’re not going to put skills for one unique role on your ladder. Do you agree with this by the way?
Rebecca: I do. You’re actually speaking my language here and — I think we were talking earlier — we have both had interesting and not entirely linear careers and I’m grateful for that. But the ladder didn’t tell me I could do that.
Ben: It doesn’t and I think that you only find out about what those opportunities are by talking to people. And so I do encourage people in their careers to talk with their manager and with other people in the company because I think that companies just have a lot of problems to solve, and they really value people who put their hand up, who are willing to help solve some of those things. I think there’s a fear that if you step off that very linear path “Can I get back on the path?” I suppose I have some trepidation about that too.
But at the end of the day — whether you are a software engineer, designer, product manager, or a manager and so forth you’re really just solving problems in the company, and that’s the real value that you’re bringing. Your boss is looking for your help in solving problems and there are many that are not right in front of you. I encourage people to look around, talk, and find what some of those other ones are because they’re they could be pretty neat.
Rebecca: Such an inspirational ending. On that note, Ben, thank you so much for talking to me today. It’s always great to catch up. Maybe it’ll be another five years and we’ll do another podcast! This has been a real treat. Thank you.
Ben: Thank you, Rebecca, for letting me blabber on. It’s been great to see you.