From Code to Cuisine: Balancing Tech and Business Strategy at 7Shifts

Welcome to another episode of the SaaS Cast, the show that flips the traditional podcast format on its head. Here we have a simple rule one question, one answer from some of the biggest names in the SaaS world. Today, we're thrilled to have the CTO of Seven Shifts, the all-in-one team management platform, built for restaurants, and here's some numbers that are hard to ignore. Their solution boasts an astonishing time savings of over 48 hours a month for simply just managing the process of distribution of tips and staff scheduling. Luke, it's an honor to have you with us. Why don't we kick things off with you telling the audience a little bit more about yourself, your company and a little bit about how you got started as a CTO?

That sounds great. Thanks for the introduction, jason. Well, yeah, as you said, I'm Luke Galea. I'm the CTO here at Seven Shifts. These days. I lead an org of around 110 engineers and responsible for technology here, but fundamentally I'm a big fan of technology, people, food and restaurants, and that's exactly what Seven Shifts is all about. Right, we're a SaaS service for restaurant operators and employees and we do everything related to team management covering the entire restaurant employee lifecycle. So that's hiring, onboarding, training, paying, engaging and retaining so tons of fun there.

But ultimately, my background is that I've been a tech technology leader for a long time. I've been at this since the early days of the dot-com boom and I've had the opportunity to write code and lead teams across a broad range of areas, everything from. I was a founding engineer at Blue Cat Networks and I got my start designing and building DNS network appliances, which was super fun but very much behind-the-scenes technology, and I really love impactful technology that changes people's lives in a way that a network appliance might struggle to. So I worked for many years in healthcare, both in Canada and the US, and that's where I first fell in love with the problem of scheduling or team management, and that was dealing with the complexities of cancer patients and drug research and basically trying to find that union of how do we test these drugs for these patients without causing conflicts. And that's fundamentally the same core problem that seven shifts solves how do I schedule staff, how do I engage them, keep them retained Is really, on a technical level, the same problem as cancer research. So, anyway, lots to cover.

But fundamentally, I'm also a huge fan and advocate for remote work. I've worked pure remote for over 12 years now and by some definitions of remote, even longer. And I highlight my time as CTO of precision nutrition, which is an online nutrition coaching company, where I led technology there, bootstrapped all the way up to 40 million in ARR and, yeah, beyond that. In terms of technology, I love it all. At an org our size, I don't get a ton of time to code, but deep down inside I still like to think of myself as maybe a Ruby elixir developer or maybe a Postgres DBA, depending on the day. So all that to say you can talk geeky to me is what I'm trying to say.

Yeah, amazing and so on. That that's like the perfect segue. And no, it was not rehearsed. But when we're talking about the nerdy and the business side of the business, it's always been a struggle to balance tech and business strategy. And so, as the CTO, you're at this intersection. You have to ensure that tech advancements in the platform align to the broader business strategy, coupling that with the pressures to adopt the latest tech trends and, obviously, understanding when your CEO comes in and said we sold a new feature, we need to deliver it in a week because I said so and promised it, and so many CTOs are known as these superhumans that pull off missions impossible. But getting to my question, what are some of the ways that you found most successful as a CTO to balance that fine line of tech and business strategy and then unlocking the broader outcome?

Yeah, no, I love that question. I think it's super timely too in the context of, you know, ai and oh, I'll get there. But Honestly, I think one of the most important roles of a technology leader is encouraging innovation in the org, but also harnessing it and Finding ways to make that innovation productive. And I think the truth is that there's different kinds of innovation and not all kinds are productive in all contexts, which you know I'll elaborate on. But you know, the reason why I think it's super timely is I note today that everyone is kind of falling over themselves to find ways to slap a Powered by chat, gpt or powered by AI badge on their products. Give it some AI bling. Yeah, and Honestly, like, as much as I love technology, I learned early on that I don't love technology for technology's sake. Yeah, and and, and. So I think it is important to like create. Well, I'll say I've had a success with a bunch of different approaches over the years, but what's really worked well at seven shifts is to create different spaces, processes and ceremonies, to encourage Different types of innovative thinking in different contexts.

I know it sounds like word salad, let me dive in a bit here, but really what I mean is like on the most granular level, we follow the Spotify squad model, so we have 14 squads and each has a ton of autonomy right. So each squad Organizes around a specific company goal and the squads drive their own roadmaps. And so fundamentally, like the fetch wood carry water of our Squads is to be innovative about how we solve our customers problems, not to be innovative about introducing new technologies, which isn't to say that we don't do that, but but that isn't what our squads goals are. There there, to you know, use the lens of technology to solve customer problems and rinse and repeat and continuously improve. So what we do have is we do a company-wide hackathon every quarter, so four times a year, where the entire company is invited to present pitches and then our squads break from their normal sprint schedule and they explore those ideas. And in a lot of cases, engineers come and pitch ideas that do reflect that intersection of like business and some new technological Advancement. Like I wonder what AI can do to help our customer service team. Or here's this old thing we built. I wonder what's possible today using this new framework, and I think I know a lot of companies do hackathons, but the reason why I feel it's part of like.

The secret sauce here is that these hackathons are like a relief valve, right, because our developers know that they're not to be doing crazy exploratory work mid sprint. They also know that we don't just like throw a new technology at a team and say, oh, we need this out in a week. It's that there are these regular opportunities for them to stop and go deep and explore these new technologies and at the end of these hackathons they present their findings and often these new technologies make their ways onto the squad's roadmap, like via, via that hackathon path, right, because they've been de-risked, improving and what have you, and I guess like it's turtles all the way down. The next layer is our staff engineers. So we have a pool of staff engineers that aren't on any one squad and they're not working on sprints and they're empowered to identify opportunities and problems in that intersection between business and technology and effectively we have a prioritized board of problem proposals, many of which came from hackathons or they came from squads identifying potentially new opportunities from from technology.

And effectively the staff engineers will get these innovations into a state where they can move back to the squads because ultimately, our squads still prioritize everything through that lens of customer and business impact and we don't want them thinking about not to say we don't want them thinking about the technology, but we want to de-risk it, figure out what the opportunity is and then allow the normal product prioritization process to fit it in where it ought to be.

Right Like, without our foot on the scale, saying, hey, we need some bling, we need. So you might note that our product is kind of bling-free, right Like. We do use a lot of old, boring technology to get the job done right. We're using PHP, we're using React. We don't have our squads constantly chasing down every new technology mid-spring, but where there are opportunities, we've got rules, engines behind the scenes, we've got crazy stuff that may not hit the feature sheet, but they're the result of that kind of process of encouraging innovation, shepherding it down the right pathway where it can be explored and de-risked, and then prioritizing it like any other business opportunity.

That's amazing, and so you're. If I were to summarize, it's really around, you know, focusing on the outcome, de-risking as much as possible for those ambitious new ideas that we want to innovate on. And then one thing I really like that you mentioned was like the squad, and so just to kind of close the loop on that, are you integrating in product and design and all of those components into a squad that is that responsible for the release of said feature or product or service? Take the thing correct?

Yeah, 100%. So we, our squads, are fully cross-functional. They span like engineering product product marketing, data product management. Yeah, I'm sure I'm missing design. Yeah, I know it's okay, qa, yeah, so each one of them is the complete slice and they own. We also follow domain-driven design, so each squad has autonomy over their set of domains and in a lot of ways, what that means is they sure they have the autonomy to swap out technology and introduce new technology within their domains, but nine times out of 10, that isn't where you introduce new technology.

It's everywhere or not at all, not in the scheduling domain or in the communication domain. Right.

Got it Well. Thank you so much, luke, for sharing how you and the team are balancing tech and business strategy. You've got over four in an employees, as you mentioned. You've got a hundred engineers that are helping make it easier for restaurants to manage, grow and operate their business. You can't wait to see what you guys do next and what your next big round of growth will look like. We'll watch along and cheer you on on the sidelines and again, thank you so much for taking the time to chat with us today.

Oh, thanks, jason, it's been a lot of fun.