Kevin Boyle is the CEO of Gearset. Today, I sit down to talk with him all about his journey of building out Gearset and developing it into what it is today. We also discuss DevOps in general throughout our conversation.

Kevin’s life trajectory was mostly set from the moment he was first introduced to gaming and coding and was instantly hooked. He went on to do an internship with Microsoft which set his career in stone. Tune in to learn more about his history and what he’s doing now with Gearset.

Show Highlights:

  • What Kevin’s experience at Microsoft was like.
  • How he went from that to working with DevOps.
  • How Salesforce’s approach to metadata layers changed his thinking about DevOps.
  • The pitfalls of an org-centric model.
  • Qualities that make for a good DevOps practice.
  • Common misconceptions around DevOps.
  • When Kevin decided to start his own company and why.
  • The importance of surrounding yourself with a great team of people as an entrepreneur.

Links:

Episode Transcript

Kevin Boyle:
What was super about computers of that era was to load a game or do anything, you had to learn a bit of basic. You had to just execute a few commands. So, I got exposed to programming and stuff from an early age too.

Josh Birk:
That is Kevin Boyle, CEO of Gearset. I’m Josh , your host of the Salesforce Developer podcast, and here on the podcast, you’ll hear stories and insights from developers, for developers. Today, we’re going to sit down and talk with Kevin about his journey into building out Gearset. We’re going to talk about DevOps in general, and we’re going to start with a little gaming.

Kevin Boyle:
Yeah, that was pretty much it. Games were the gateway drug to bring me into computing, and then I just liked computers, and then I learned you could make computers do stuff by telling them to do stuff, so I liked that, that you got to be a little bit creative. I’m one of those very annoying, obnoxious people that knew what I wanted to do from a very young age.

Josh Birk:
From a very early age.

Kevin Boyle:
Yeah. Very, very early, I knew what I was doing, so my life trajectory was set early.

Josh Birk:
One of my earliest memories, one of my fondest memories, and I think led me to want to be a programmer, and this was on the old Apple IIs, the teacher at the time was like, “You can do whatever you want and it won’t break this computer.” Basically-

Kevin Boyle:
Challenge accepted.

Josh Birk:
Challenge accepted. Exactly. Right. It’s like we’re doing go-to statements and basic stuff and things like that, so he’s totally right. But I’m like, “Wait, really? Let’s see what happens if I do recursive statements 15 times in a row.” Tell me a little bit about the Microsoft internship. How was that like?

Kevin Boyle:
I did two Microsoft internships. As I said, part of my university degree was you got a year of industry experience, and if any students are listening to this, or if anyone’s listening that’s got kids, internships are just amazing, at least in the UK. I know there’s a little bit in the US if they’re paid and stuff, there’s a whole bunch of stuff, but in the UK, they’re pretty well regulated, and it’s just a chance to go and get a job and experience what it’s like to actually work. So, I did two. I did a year working for Microsoft in Dublin, working on the Office suites, so a bunch of the Office online properties, and then a bunch of the desktop products as well. That was really good fun. Your family knew who you worked for and stuff, which was nice. Then the year after that, just before my final year, I did the internship program in Redmond out in Seattle, and that was cool because you’re at the Microsoft campus.

Kevin Boyle:
To me, again, if I haven’t made this clear enough, I sort of grew up a bit of a nerd. So,, by age 19, 20, the idea of going to the Microsoft campus and being a blue badge employee, that was a big deal, and it was an awesome summer, and met some really great people. It was my first time properly away from home. Grew up in a pretty rural part of Ireland, in Belfast, a lovely town, but it’s pretty small. So, going to Seattle and meeting people from all over the world and meeting people that have gone to all the Ivy League schools in the US and stuff was just sort of this big horizon expanding thing for me. So, that was really good fun.

Josh Birk:
Yeah. Well, and that’s so cool, because it’s like at that point, Microsoft was sort of the epicenter of the computing world. All things revolved around whether you’re doing web stuff or desktop stuff or kind of anything. That must have also been just kind of a great learning experience into tech itself.

Kevin Boyle:
Yeah, it was cool. It was cool to see the impact that tech could have and the ambition that Microsoft had. I guess you see that with Salesforce now and other companies, where you just understand the work you’re doing, the impact that that could have in the world. What was nice as well, the intern program at Microsoft, the way they ran it was you were essentially treated like a full-time employee, so you had access to everything.

Josh Birk:
Nice, nice.

Kevin Boyle:
So, you could read the plans behind things and why they were doing stuff, and you could speak to their technical fellows, or these folks that are had held in such great esteem, they were very generous with their time, and you could sit down and have a conversation with them.

Josh Birk:
Gotcha.

Kevin Boyle:
So, I thought that internship was great.

Josh Birk:
Very cool. When did you first start moving out of, I hesitate to use the word normal, let’s say normal programming, and getting more interested in things like DevOps itself?

Kevin Boyle:
That’s a great question. I did my internship at Microsoft, loved that, loved working for the company, but when I was there, it was an 85,000 person company or something. After graduating, I wanted to try something a little bit smaller, so I moved from Belfast to Cambridge here in the UK, the original Cambridge, to all those Boston folks, and had worked for a company here for a little while. It was 2,000 employees, and that was good, I liked it being a smaller company, and then there was a company in the city hiring for C Sharp developers, which is what I was trained as, and it was a 200 person company, so it was just getting smaller and smaller and smaller. That company built DevOps tools for the SQL server market, Microsoft market generally, but SQL server in particular. That was my exposure. I actually came at it the other way. I came at it from building products to solve DevOps challenges on the Microsoft platform, and got exposed to, “Oh, this is what these folks are trying to do. This is cool.”

Josh Birk:
I mean, this is a Salesforce podcast, blah, blah, blah, but that kind of interests me. I never really thought about my experience with DevOps focusing on something like SQL server. What are some of the specific challenges there that you’re building towards?

Kevin Boyle:
Some of it’s actually really analogous to Salesforce. I guess if you think about what DevOps is with the tools, culture, and process stuff, there’s a bunch of it that’s common to all platforms, like, how do you get folks to collaborate and stuff?

Josh Birk:
Gotcha.

Kevin Boyle:
That’s totally common. I think the differences and some of the real interesting challenges come from the specifics of the platform, some of the technical challenges, and particularly if you’re wearing my hat and you’re trying to build tools to make this easier for teams, some of the platform challenges make it really interesting. With SQL server, you have state exists. So, if you’re doing DevOps for a nice Java app or Kubernetes pipeline or something, you can just throw away the computances and bring up something new, a bit like Salesforce functions. You don’t think the lifetime of those, they come and they go, and that’s great.

Josh Birk:
Right.

Kevin Boyle:
Whereas if you get something like a database and you want to migrate that, in the old, archaic world of SQL, you had to actually think about how that data migration was going to happen. You couldn’t just go to the object manager and add a new field and have Salesforce take care of that for you.

Josh Birk:
Right.

Kevin Boyle:
Those challenges of how you orchestrate that make those changes safely, whilst also protecting all of the state and all of the data that’s within that SQL server instance, that was what made that real, real interesting.

Josh Birk:
Interesting, interesting. What was your first experience with Salesforce itself?

Kevin Boyle:
My first experience with Salesforce was at that company. Every Cambridge company is full of super smart Cambridge and Oxford grads, and there’s a really healthy, or unhealthy, not invented here syndrome, so everybody just thinks they can build it better. They had built their own CRM, because smart people, we can build a CRM.

Josh Birk:
Sure. Why not?

Kevin Boyle:
Yeah. It’s not their business, they’re not selling it, but we’ll build it, because those folks over in San Francisco, the thousands of smart people that are doing it over there, we can [inaudible 00:07:28] it’ll work just as well. The truth is it actually did work quite well when they were a very small organization, and then as they grew-

Josh Birk:
Right, right.

Kevin Boyle:
Yeah. It just doesn’t make any sense. Right?

Josh Birk:
Right.

Kevin Boyle:
So, you go and you bring in an external CRM, and you look around the market, what’s the best CRM out there? It’s Salesforce, so you bring in Salesforce. As part of that implementation, I got exposed to Salesforce, I got exposed to the platform for the first time. Understood, “Oh, it’s awesome in so many ways. There’s so many things I don’t have to think about that I used to have to care about quite a lot, but also, I really want to use source control.” That to me was sort of tables stakes, hygiene factor, like, “Why can’t I use source control?”

Josh Birk:
Right.

Kevin Boyle:
So, there was a bunch of stuff that made Salesforce challenging that way.

Josh Birk:
Yeah. How did the approach that Salesforce has to a metadata layer change your thinking around DevOps?

Kevin Boyle:
Oh, that’s a great question. I guess I sort think of these things a little bit more abstract. I think of them as just ways of representing the business logic and data layer and the UI, so you can represent it as metadata or you can represent it as SQL statements or you can represent it as whatever you want to use. They’re just ways of representing what that system looks like.

Josh Birk:
Gotcha.

Kevin Boyle:
I think Salesforce, in terms of that DevOps challenge, in terms of what the metadata platform brings to productivity and how you build apps, yeah, it’s clearly a novel approach that has paid dividends. But from a DevOps perspective, I think it still comes back to how do you have folks collaborate? How do you make changes to it? How do you understand changes flowing through a pipeline and the representation of those changes? Yeah. I don’t think it matters so much.

Josh Birk:
Interesting. On that core part, and going back a little bit, what are the risks? Because when I was a consultant, and a lot of the times we were going to spin up a new project, it was all dev org, dev org, sandbox, sandbox, right? And source control for us was something we kind of used internally, but less so from a project point of view, because you’re saying that was the center of development at the time. What are the risks you think there? From an org centric model versus a source centric model, what are people who are still doing the former, what are they lacking? What might be their potential pitfalls there?

Kevin Boyle:
I think the potential pitfalls of the org centric model are… I think there’s two. I think the more interesting thing might be the missed opportunities. Even if you don’t think about the risks involved in the org centric model, you miss out on just all of the benefits that come from using source control, really effective collaboration, really effective peer review, all of the tooling that’s built up around source control systems, and how you have changes flow from different environments;.

Josh Birk:
Yeah.

Kevin Boyle:
Reporting and change tracking and integration with things like JIRA or Agile Accelerator, whatever, choose your poison. So, I think that’s probably the bigger thing, is not that the risk those folks are carrying, but that they’re missing out on a better way of working. Even saying that, there are definitely some risks to org centric model as well. I think you have all of the usual risk of, “What have I actually done within this org?”

Josh Birk:
Right.

Kevin Boyle:
“Is it actually in the state that I think it’s in, or has it actually drifted a little bit?” Or, “Are me and my colleague looking at the same thing, or did that I miss out on a change set that I didn’t migrate?” Or, “I included most of the components, but not all of the components, and now that flow just behaves just a little bit differently. Why does it behave a little bit differently? Oh, it’s because it’s different.” So, there’s a few things like that that I think are the biggest pitfalls of working that way, is it’s very opaque.

Josh Birk:
Yeah.

Kevin Boyle:
It’s very, very hard to get a good understanding of how the org is actually constructed.

Josh Birk:
Yeah. It feels like your source of truth is just sort of whatever you happen to wake up to that morning, not necessarily what everybody agreed on the night before.

Kevin Boyle:
Yeah. Everyone’s got their own version of the truth. Everyone’s got their own spin on it.

Josh Birk:
Right. Exactly. Exactly. But a little bit more broadly, what are some of the qualities that you would say makes for a good DevOps practice?

Kevin Boyle:
I think a good DevOps practice is I think, again, if you take DevOps back to the root of the culture process tool stuff, there’s, again, a bunch of common things, so transparency, understanding the state of things, having a robust pipeline that you can flow changes through, I think all of that stuff’s important in any good DevOps process, but I think the more important thing is building the process that works for your team. I think DevOps as that cultural change is the real thing to tackle. Right? So, do you have a good understanding of how your team currently builds stuff on Salesforce and how that gets from idea through to your users actually getting the benefit of your work? And really mapping that out for your team and understanding for you folks where the roadblocks are at, and where can things be improved? If we think back to our last 10 bugs that we introduced, was there any sort of pattern or theme? So, I think that’s the more important thing, is to think about your team uniquely rather than reach for best practice or tooling or a platform or whatever it is.

Josh Birk:
See, I find that fascinating, because every time I get into conversations about DevOps, it always holes its way back to the human element of it.

Kevin Boyle:
Sure.

Josh Birk:
Like when you think of the philosophy of DevOps, how much do you think starts with the human being and their behavior versus the actual tool that they’re actually using?

Kevin Boyle:
I think it’s all the behavior. It’s all the collaboration side, because ultimately, what are you trying to do by bringing in the [inaudible 00:13:26] process? You’re trying to deliver software robustly and predictably. Well, who’s doing that? Right? It’s not robots writing the software, it’s humans.

Josh Birk:
Right.

Kevin Boyle:
So, we’ve got a human collaboration challenge. How do we work together? How do we have visibility into what each other’s doing? How do we map out dependencies between each other? All those sorts of real human things, and then your tooling supports that. So, your tooling helps you solve some of the collaboration challenges, but it’s always starting with the human side of things, because ultimately software is a team sport when you’re doing it at scale, so how do we have folks working together effectively? That’s always the more interesting thing.

Josh Birk:
Right. So, you would say humans should be driving the technology, not the other way around?

Kevin Boyle:
For sure. I think humans understanding their situation uniquely, understanding what it is about their team, really having that conversation internally, then going out to look at, “Okay, what’s the art of the possible? What’s out there? What are other teams doing? We don’t want to reinvent the wheel. What does best practice look like?” And then putting in place a plan that gets you from where you are to where want to be, and do that in an iterative way, so again, DevOps and Agile, they’re all about continuous improvement, they’re all about an iterative process, and apply that to how you adopt DevOps.

Kevin Boyle:
I’ve spent the last five, six years speaking to just thousands and thousands and thousands teams that do this, and the ones that are most successful always take the iterative approach. They don’t try and boil the ocean and have a here to there down tools whilst we implement something over four months and then life will be better. It’ll be better in some ways and it’ll be worse in some ways. In the meantime, you’ve lost four months, so take your time, understand what’s slowing you down and what can speed you up, and then fix that problem and then move to the next and the next.

Josh Birk:
Nice. I think you touched on it a little bit, but even when we were talking before, and I don’t know why I didn’t think about this, because now, especially in the middle of this conversation, it seems so obvious, but what are some of the different challenges that small teams and small businesses face versus large teams and large enterprises? Is it merely an example of scale and complexity, or is it more fine tuned than that?

Kevin Boyle:
I think scale and complexity is the obvious one.

Josh Birk:
Right.

Kevin Boyle:
It’s harder to get a group of 40 or 100 working together than it is four. If you can all get around a table or a small Zoom window, some of those barriers of communication and collaboration are just a little bit easier in small groups as a generalization. So, when you’re doing it at scale, there’s more people. Okay?

Josh Birk:
Yeah.

Kevin Boyle:
So, if you’ve got more people, you’re probably going to have a lot more parallel work streams.

Josh Birk:
Yeah.

Kevin Boyle:
You’re probably going to need some ways to bring together those parallel work streams. You’re probably going to have more dependencies between them. Those dependencies are probably going to be in longer running projects. So, there’s definitely a scale thing. We also find that large organizations just have different requirements around risk, compliance, audit reporting. Not always, and again, I’m sort of doing generalizations here, but large organizations, you tend to be supporting an even bigger sales team or service team, so the impact of shipping a bug tends to have a slightly higher dollar value attached to it.

Josh Birk:
Yeah.

Kevin Boyle:
So, you have a different risk appetite and a different necessity to make sure you’ve done absolutely everything you can to prevent those bugs coming to production, even if it means moving a little bit slower than your four person team small business.

Josh Birk:
Gotcha. I think we’ve touched on this a little bit, because I think when people first hear about DevOps, they think, “Well, that’s my tooling. That’s my continuous integration. That’s my tool stuff.” But what are some other common misconceptions do you think people have around DevOps?

Kevin Boyle:
Yeah. That’s the big one. We’ll speak to folks who will come in and say, “We don’t have DevOps. We want DevOps. Can we buy DevOps from you, please?”

Josh Birk:
“Could you just put it in a box, leave it on my desk, I’ll open it later and read the instructions, I promise.”

Kevin Boyle:
Yeah, so there’s that sort of approach. I think that’s on all of us for doing a [inaudible 00:17:51] job of communicating what DevOps is, right? So I’m not mocking people that come with that preconception. That’s us doing a bad job of educating folks as to what DevOps actually means. I think that’s the big one. Folks come in and want a DevOps thing to solve a lot of their problems without having the conversation around what it is within their team that’s actually making development challenging, and what things are trying to solve. So, I come back to what we were chatting about earlier, it’s a more human and philosophy and culture and process stuff. It’s as much that as it is a software problem.

Josh Birk:
Yeah. How much from your company perspective, so you’ve got a product, you’ve got that tooling, you’ve got that thing in the box. Do you also have people who are in charge of that process, making sure people are sitting down and thinking about, “Hey, wait, what’s your human behavior? What’s your team process looking like?” Do you have counselors for that kind of thing?

Kevin Boyle:
Yeah. We have sales team. Our sales team is a little bit different than most other sales teams you interact with.

Josh Birk:
Interesting.

Kevin Boyle:
Where our sales team are real interesting bunch from a bunch of different backgrounds, like lawyers and marine biologists and just everything, and they are all super talented, smart folks that have taken the time over a number of years to really become experts in DevOps. The first thing they’ll do when they sit down with a customer that’s come to us is really try and understand what their situation is. They’ll do a diagnosis and start to advise how software and how Gearset might support it. But we’ll also show them that some of their processes might need to improve as well, or there’s some prioritization for them to do in terms of which problems they want to tackle first.

Josh Birk:
Gotcha.

Kevin Boyle:
We’ve got this model, which we call the maturity matrix, this maturity model, where we’ll present a timeline for how folks can go from where they are today. Let’s understand that. Let’s map you out for where your team’s at, then let’s talk about your ambitions. Where do you want to end up? Do you want it so that every single commit is automatically deployed so there’s that continuous delivery type thing going on, or are you happy with daily releases or weekly releases? What’s right for you? And then we’ll help them put together a timeline for doing that.

Josh Birk:
Gotcha.

Kevin Boyle:
We don’t have any services or anything yet. This is all just done through our sales team and our customer success team who are just a super talented bunch of folks.

Josh Birk:
Nice. Now, when it comes to the people who are in that room, from a Salesforce perspective, are you talking mostly developers, admins, architects, both? Who’s the core audience, or is there a single core audience?

Kevin Boyle:
It varies from your SMB through to your enterprise customer.

Josh Birk:
Gotcha.

Kevin Boyle:
There’s different folks at the table and a different number of folks at the table, and different levels within the company in terms of, “Hey, as a CIO in this conversation,” or who’s there. For Gearset, the way Matt and I and the folks we started with started the whole thing, we are developers, right? We are unashamedly developers and tech folks. That’s what we get excited about. That’s what I come to work to do is, to talk to technical people. As the company’s matured, we’ve also brought in a lot of other people who could have a different conversation, but our general approach is still to speak to the Salesforce team and those developers and architects and talk turkey, get into the nuts and bolts of how they build software and how we can help improve how they build software.

Josh Birk:
Got it. So, let’s talk a little bit about you and Matt in the early years. When did you decide, “I want to do this as my own company. I want to go off on my own and actually start something completely new.”

Kevin Boyle:
Yeah. I’d kind of harbored the ambition for a few years, maybe from around 2013 to 2015, and ended up running part of the R&D division at the company I was working at. Lots of very short, iterative, Lean Startup, if you’ve read that Eric Ries book, lots of those types of things, where we were trying to quickly to see if we could build a business in a new area of emerging tech landscape. We’d done that and I had failed again and again and again, just everything I had tried that I thought was a good idea, and surrounded myself with smart folks and stuff, we just failed again and again and again and again.

Josh Birk:
Nice.

Kevin Boyle:
So, I was almost just ready to give up. I was almost like, “Just this entrepreneur stuff, I have learned if I am good at it or not. The message is clear. I am not.” Then we started doing the Salesforce stuff internally. We were trying to build software the way we thought you should build software. We thought building software without source control, without continuous integration, without these tools of the trade made collaboration real challenging. So, we sort of looked around, we thought, “Hey, there must be something out there that allows you to do sensible growing up software engineering and DevOps on top of Salesforce,” and there were some products out there, but there was nothing that we felt did it the way we wanted to do it, not to knock those other things, they just took a different approach, and we took a product approach.

Kevin Boyle:
We thought there was a product solution where technology could automate away a whole bunch of the challenges and technical things that made Salesforce and the [inaudible 00:23:25] API and the TuneIn API, made that tricky to work with. We thought you could bring technology to bear on that problem, and we spoke to everybody we could speak to at other companies about, “Hey, are we just ignorant here? Is there a really good way to do this that we don’t know about?How do you folks do it?”

Josh Birk:
Right.

Kevin Boyle:
Because every single person we spoke to said… I know this is a Salesforce podcast, so I’ve got to be very diplomatic, everybody we spoke to had the same view, right? Where in 2014 or 2015, the pre Salesforce VX, pre DevOps center, pre all these things, it was really hard. It was really, really, really hard, and folks loved the power of the platform and got frustrated when it came to actually delivering and releasing. We just thought we had something there. I was excited about the community, I was excited about the Ohana stuff. I came to Dreamforce, what year was that? I think that was like 2015. I came to Dreamforce just as an attendee to try and understand the thing, and I just got swept up in that I loved how open the community was, I loved how much everyone’s so willingly shared. If you join the Salesforce Slack, Ohana that Megan runs, there’s a generosity of sharing of information and sharing of knowledge. There’s nothing guarded.

Josh Birk:
Yeah.

Kevin Boyle:
I love the ecosystem. So, it all sort of came together. A few of us thought, “This is too good. We can’t not do this.” So, with the blessing of the company, because we started the R&D there, and the CEO was really, really supportive and invested in Gearset, and we left, and yeah, we then did this thing, and it’s been-

Josh Birk:
Nice.

Kevin Boyle:
… the hardest thing I think I’ve ever done.

Josh Birk:
Yeah.

Kevin Boyle:
It’s been just so challenging and such a thing for triggering imposter syndrome, just you constantly feel like, “Oh my God, what am I doing?” But it’s been amazing fun and amazing fun assembling the team. I think we’re a couple of people away from 200.

Josh Birk:
Oh, wow.

Kevin Boyle:
Based in Chicago and Cambridge and Belfast, and just thousands and thousands of real happy customers. It’s been the hardest thing, but one of the most rewarding things I’ve ever done.

Josh Birk:
This is going to sound entirely cliche, because it is, but if you’re having somebody, they’re like, “Wow, I kind of want to try that myself,” what’s the one big lesson that you would tell them you learned?

Kevin Boyle:
Yeah, that’s a really good question. I think the biggest thing for me was the team of folks that I did it with and that I continue to do it with, right? We’re still a very small company in the grand scheme of things, and very small in terms of the ambition of what we think we can do. I think that team that you surround yourself with, because they’re going to be long days, they’re going to be hard days, they’re going to be argumentative of days from time to time, and having a group that you trust and that’s fun, and doing a company, you’ve got the opportunity to create a company that you want to work for, that would be proud to work for and run.

Kevin Boyle:
At Gearset, there’s a bunch of stuff around transparency. We’re totally open internally in terms of our numbers, our customers, our strategy. It’s all just totally open. So, if you’re a junior software engineer that’s just joined three days ago, you have access to more or less all the same information that I have access to as a CEO, and all that’s built on top of this foundation of trust and how we do feedback with each other. Those are all things that I get a kick out of that work. I like working in that environment.

Josh Birk:
Okay.

Kevin Boyle:
So, if you were going to do this, think about the company that you want to create, what’s its impact in the world, what are the folks that you’re doing it with? How are you going to work together? What are you trying to do? Because it’s going to be 60, 70 hour weeks for a long time, so make sure you’re doing it with folks you enjoy doing it with in a way that you enjoy doing it.

Josh Birk:
I love that we keep coming back to a theme of support a human-centric model.

Kevin Boyle:
Yeah. Well, that’s what it is. Right?

Josh Birk:
Right.

Kevin Boyle:
You spend so much time at work doing this thing, you better enjoy it and you better enjoy who you’re doing it with. Ultimately, at the end of the day, we’re all just monkeys trying to get along, so how do we that?

Josh Birk:
Yeah.

Kevin Boyle:
How do we interact with each other and do it in a way that you can stand over it and say, “Yeah, this is good. I’m proud of that work. I’m proud of the work that we did together. I’m proud of how we did it together.” Important.

Josh Birk:
Nice. Nice. Now, when we were talking during the prep call, and I cannot remember how this came up, but one of the interesting things I thought that you mentioned about how you’re running the company is that people managers and engineers, they’re in their own swim lands, and there’s no financial incentive, necessarily, for somebody to go from a senior developer to a senior manager kind of thing. Could you tell me a little bit about that philosophy? Because I think a lot of developers feel they often have career paths that have a ceiling to them, because if they want to keep moving forward, they either have to get into executive leadership or management.

Kevin Boyle:
Yeah. I think that’s the way it’s set up in a lot of companies, where you eventually reach that level where you’re got a financial incentive to become a team leader, product manager or something, basically a people manager. That’s the big transition for me, where people management carries a higher financial reward, and I don’t think those things should be linked. I think some people managers that manage… I think it’s areas of responsibility is the thing that should be roughly correlated to financial competition, so people managers obviously have a big old area of responsibility. But if you’re an IC, that’s a subject matter expert, and instrumental in how we create software or how we market our software, how we sell our software, how we support our software or how we run our teams internally or do recruitment, whatever it is, I think that impact and that responsibility should be rewarded just as much as, “I manage a group of 10 people.”

Josh Birk:
Gotcha. How do you personally weigh out the balances of being a CEO of running a company, but also still being that classic nerd who wants to build stuff?

Kevin Boyle:
Yeah. I think I’m lucky, because my job as CEO is of a tech company, is a tech company that’s full of nerds, right?

Josh Birk:
Yeah.

Kevin Boyle:
So, if I jump on a zoom to chat with my colleagues in Chicago, or if we’ve got everybody over this week, we’re doing a big party, and we’ve got all the folks that work from Chicago and Belfast, that sort of stuff. Some of these people, I don’t speak to them that often, or certainly not in person, and so you think we’d be doing loads of stuff where we’re instilling company values or reiterating our strategy, but we’re not. We’re just having a bit of a party this week. Loads of it’s just talking. I was chatting with one of the guys, one of our sales guys in Chicago I found out is a massive video game nerd.

Josh Birk:
Nice.

Kevin Boyle:
So, I just spoke about video game stuff with them for about 30, 45 minutes over a beer. That’s also part of my job, right?

Josh Birk:
Right.

Kevin Boyle:
I do whatever the CEO is supposed to do to run the company, and in the process of my day and the progress of my day, I often get lots of chances to nerd out with a bunch of folks that think similarly to me.

Josh Birk:
Nice.

Kevin Boyle:
Then if I’m having a particularly stressful week, though, if I’m particularly busy, if I need a chance to unwind, I’ll often still do a bit of programming on the weekend.

Josh Birk:
Gotcha.

Kevin Boyle:
I have a quite strict rule for myself, and the folks that work with me enforce this rule quite rigorously as well, that I can’t do any programming on the job, so I can’t do any programming that Gearset’s paying me for, because it’s just too easy, right?

Josh Birk:
Right.

Kevin Boyle:
It’s basically an avoidance tactic.

Josh Birk:
Right.

Kevin Boyle:
But sometimes on the weekend, my wife will see if I’m particularly stressed or something and I might jump into the office and close the door and code for an hour or two, which, yeah, I said out loud, I appreciate exactly how this sounds. But anyway, that’s how this guy destresses.

Josh Birk:
I do like that rule in force, though, because the last thing you want to be is like, “Well, Kevin broke it.”

Kevin Boyle:
Yeah. I used to do a lot of the code for our Salesforce instance and how our different systems hang together and how our payment processor feeds through and stuff, and we’ve now got a team of people that do that. Every time I get on a call with them, I have to apologize. They’re like, “We’re going to rewrite this apex,” and I’m like, “No, don’t open that file. Don’t open that file.” So, yeah, yeah, I still get blamed for stuff.

Josh Birk:
I love it. Side question and this might bleed into the final question, but what games are you playing right now?

Kevin Boyle:
I actually don’t play very many games anymore.

Josh Birk:
Okay.

Kevin Boyle:
The games I play most often these days are… you know the Lego games?

Josh Birk:
Oh, yeah. Yeah.

Kevin Boyle:
Those games. I like those because I can’t die. You know? They’re designed for kids primarily, Right?

Josh Birk:
Yep, yep.

Kevin Boyle:
So, they’re fun, they’re quirky, they’ve got nice animations and stuff, and all I have to really do is press forward and green occasionally, and I’ll probably come to the end of the level.

Josh Birk:
I hear you.

Kevin Boyle:
They also have that nice gamification of the completionist thing. I can collect every coin? You give me a percentage to game? So, I quite like that. The game that I’m actually hankering for but haven’t had a chance is Half-Life: Alyx, the VR one.

Josh Birk:
Yeah. Yeah.

Kevin Boyle:
Half-Life 2 is the pinnacle of gaming. I don’t think it’s actually been improved upon since then, and I’m really looking forward to playing Alyx. I know it’s like two years old at this point, but I haven’t got around to it.

Josh Birk:
It’ll still be fun the first time you open it up.

Kevin Boyle:
Yeah, absolutely.

Josh Birk:
Yeah. No, I was having a conversation with a long time gamer friend of mine, and we were like, “Yeah, we’re old these days. We don’t want the challenges we did when we were kids.” I don’t have four hours to dedicate to make [inaudible 00:33:28] actually work. I just want a success story and go home.

Kevin Boyle:
That’s the thing, I don’t have the time.

Josh Birk:
I don’t have the time.

Kevin Boyle:
Yeah. I’ve got 30 minutes to play the game, maybe. I don’t want to die six times and make four minutes of progress.

Josh Birk:
Right. That’s our show. Now, I did ask after Kevin’s favorite non-technical hobby. It turns out when he’s not de-stressing through programming, he likes to hit some slopes.

Kevin Boyle:
Skiing.

Josh Birk:
Nice.

Kevin Boyle:
Skiing is my favorite non-technical hobby. Skiing might even be my favorite hobby.

Josh Birk:
Nice.

Kevin Boyle:
I love skiing. I got into it super late in life compared to lots of folks. I didn’t start until I was in my twenties. Truth be told, the first time I went was with my two brothers and a brother-in-law, and I’m not the world’s most athletic, sporty guy, so I thought I’ll go along, I’ll do a little bit of skiing, I’ll do quite a lot of [inaudible 00:34:14] ski and hit the lodge, and then I just love that. I just fell in love with being out in the mountains, exploring it. That is my absolute favorite place. One of my favorite places in the world to be is in the Dolomites in Italy, either in the summer for bit of cycling, or else definitely in the winter for a bit of skiing. It’s just an awesome place to be.

Josh Birk:
I want to thank Kevin for the great conversation and information, and as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer.salesoforce.com/podcast, where you can hear old episodes, see the show notes, and have the links to your favorite podcast service. Thanks again, everybody. I’ll talk to you next week.

Get notified of new episodes with the new Salesforce Developers Slack app.