Albert Strasheim, CTO at Rippling, on Embracing Rapid Iteration and Setting Goals for Accountability 

Albert, welcome to the show.

Albert Strasheim  03:26

I am excited to be here.

Aydin Mirzaee  03:29

Yeah, there’s so much for us to talk about today. One of the things that super interesting for me is you’ve had a pretty interesting career worked at a lot of companies that all of us have heard of, you know, Cloudflare Mesosphere segment today, you are the CTO at rippling, which is one of the fastest growing tech companies out there. What I wanted to maybe talk to you about is it seems like you’ve had a pretty rapid path in terms of getting more senior in your career, it seems like at some point, you made a decision to take the manager path in your career. After that you’ve had progressively more senior roles, you know, today, the CTO, I’m wondering for all the people kind of listening in the audience, what are some learnings that you’ve had in that career trajectory and things that you would pass on to other listeners wanting to do something similar? Yeah,

Albert Strasheim  04:20

I mean, to some extent, I find you, you’re gonna like figure it out as you go. I mean, ultimately, if I look back, you know, so join Cloudflare in 2013 company was about 50 people at the time while you were early. Yeah, it was it was pretty early. So moved from Cape Town in South Africa to San Francisco. I still remember coming out of Montgomery Street station here and like being amazed at the tall buildings, but yeah, kind of like joined it pretty early company. I think that’s generally a good idea, right? You learn more through chaos and kind of like dealing with things at earlier stages and, and I think in each progressive step after that, and you know, So sphere to segment two rippling, it’s kind of been like taking the next bigger challenge at a slightly bigger company each time. And I think what you find then is like you can apply some of the lessons from the previous run, but you also have to learn a couple of new things. So that’s kind of like been the journey over the last little over a decade, generally, things that are probably in common across all of those career steps, gently tried very hard to be, you know, hands on, I think in my own career, I stayed, I’d say like very technical. For a number of years, I found in the kinds of roles I’ve pursued, really knowing what’s going on being able to work closely with the engineering team, the product team, and going working from this position, have a deep understanding of what is being built, what customers need, et cetera, has been super helpful. And I think, over the course of you know, CloudFlare, to rippling is, has been doing that at a larger and larger scale, you’re building on the experience of the previous one. So that’s maybe been like one common thread thing, something else that I feel like you learn, especially you’re working at a Silicon Valley startup, or maybe startups in general, is this idea of like, rapid iteration, and being comfortable with building things that are potentially not going to live forever. I remember back in the Cloudflare days, Dan connect, who was running product at the time there and you talked about baby steps. So as I joined the data team there and we built a new log processing pipeline was like, a few baby steps every week to get this thing out, or something very similar. I’d segment recombinant Ilya, the two technical co founders, were very passionate about weekly demos, a very similar motion at rippling where your teams are getting together, every week or every second week, just showing what they’ve built, getting feedback, changing plans, being very flexible, and kind of like iterating really quickly. And so I think putting yourself in that kind of environment, and taking on large challenges, almost like pulls you up through the ranks quite quickly. So pick the companies wisely, pick a rapidly growing fast shifting environment and work hard, and the rest of it kind of happens. So

Aydin Mirzaee  07:09

a few things to dig into there. So you mentioned this idea of being hands on you, obviously, like we’re in the role, you know, you build things you’re very close to it. I mean, this is a question that comes up, especially for technical leaders, which is, do you still continue to code? And so I’m curious, do you and you know, how do you keep being technical? How do you keep getting close to the problems at hand, especially as your teams grow and your responsibilities grow?

Albert Strasheim  07:35

I think in my role today, not a ton of code, something I actually spend a decent amount of time on, though is is like keeping a close eye on the rippling developer experience. So every month or two, I’ll sit down, I’ll say like, Hey, let me start from scratch, pretend I’m a new engineer at the company, like what does it take to get up and running, you know, make a one line code change, I actually found that quite instructive. Beyond that, and especially as teams get larger, you know, there’s a lot of meetings, there’s never really a ton of focus time, your goal was to create that for yourself a day, or two a week, maybe on weekends, but it becomes harder and harder to really write large amounts of code yourself. The thing I do instead is spend my time looking at the other dynamics of the systems the team is building. It’s things like dashboards, the code pull requests, so I’m not writing code, but I’m looking at the kind of code we’re writing, hey, does this change Have a taste? What How is the taste read? And what what is the test infrastructure like, looking at incidents, reading bug reports, that kind of thing? It all helps you are going to get a handle on what is happening day to day? Yeah,

Aydin Mirzaee  08:45

I love it. So it seems like you’re focusing a lot more on the systems that people use. And so that’s how you’re seeing close to the problems at hand. So maybe you can talk a little bit more about what you mean, by being hands on. And so sometimes, you know, when you say being hands on, people look at that and say, Oh my God, they’re a micromanager run for the hills. But other times, it’s actually especially when it comes to being really good at your craft or really caring deeply about, you know, the outputs. You know, a lot of people a lot of very famous people have been very, very close to the problems at hand and have been very hands on in some ways. So, I was just curious what hands on means to you and how hands on are you? Yeah,

Albert Strasheim  09:27

it is definitely not micromanaging the way I would probably think about that as like, you know, are you needlessly wasting time asking questions that isn’t actually contributing to the team or like having the team do busy work? For no clear reason. I think one good hands on looks like is you’re actually advancing the team in their mission through your own efforts to build your understanding of the situation. If you’re reading code, you’re actually pointing out like real issues in the design of the tests, for example, or if you’re looking at dashboard If you’re melding in with the operational processes of the team, and for example, pointing out an anomaly that they might have missed, or whatever the case may be. And so, you know, to some extent, it’s about putting yourself in the shoes of a team member contributing to the discussion contributing to the debugging effort, whatever the case may be. And through that, also learning about what’s going on. It’s not like micromanaging exactly how the team solves a problem or the order in which they do small tasks. It’s much more about making sure that the strategic approach is correct. And learning in the process.

Aydin Mirzaee  10:36

You know, as we were about to hit record, you said that there was a value, I think at rippling, were you just going and seeing value? Is that what you mean by that?

Albert Strasheim  10:48

Yeah, exactly. Yeah. So we call this idea of the just the right kind of hands on going and seeing here, and think maybe an interesting story of the current state of rippling leadership values that the way we came up with them, as we actually sat down now about two years ago, and assembled a lot of folks at the company that had been successful over the years, and boss them and asked the others about them, like, hey, what do these people do that makes them successful in our environment, and the, like, the number one trait that rose to the top is like, they are in the details that are hands on, they are going and seeing to a high degree. And so that essentially got codified as leadership value number one, I think today, too, as we hire folks into the company, and you look at how the team is doing, probably the ability and tendency to go and see correlates most strongly with success here, you can very clearly see folks that are successful are the ones that go and see. And the ones that don’t sometimes don’t work out, it’s gonna like proven through, you know, five, six years of data dropping at this point that you’re going and seeing is, is usually correlated with success for us. Yeah,

Aydin Mirzaee  11:59

that’s super interesting, because replaying is a pretty big company. Lots of people work there. So this was an activity that you only did two years ago. So these are the company values, these are specifically the leadership values that you were able to pull together.

Albert Strasheim  12:15

Yeah, exactly. So the company essentially had a version one of it’s somewhere between company and leadership values that I think were written down a while after the founding. And my guess is a year or two in until we did a big refresh of this, you know, about two years ago. Now, the idea was specifically not to take an approach where we write nice sounding values on the board and say, Hey, like, you know, everybody, this is what you value, it was exactly the opposite to say, let’s really get down and see what we value as an organization. And let’s write those things down for new people joining the company. And so I think it’s a it’s a subtle difference, but the outcome is pretty different in what you come up with. And it’s like you really have on the wall or in the slide, the things that are actually valued. And so I think this exercise, maybe a few years into a company’s existence, or a team’s existence to kind of like reverse engineer the things that the team or the company actually cares about is super valuable.

Aydin Mirzaee  13:21

Yeah, I really liked that answer. These are different than the company values, right? Like, these are almost like instructional, if you want to be a successful leader here, here are the things that successful leaders have exhibited. It’s almost like a playbook of success. As a leader like company,

Albert Strasheim  13:39

I think to be clear to me, we really define leader as anybody at the company. So it’s not like, hey, managers do this. And ICS do something else Israel, like, in order to be successful here in any role, like you’re probably doing these,

Aydin Mirzaee  13:53

these basically supersede the original. Yes, core values written, okay, so they just became the new values. Exactly. There’s

Albert Strasheim  14:00

no other sets of values. Okay, got it. Got it. These nine are kind of like the golden nine things where if you manage our aspirational, everybody, myself included or successfully do you know, like, eight of the nine on a given day, but from time to time to time you line up all nine? And it’s just beautiful. And so yeah, that’s how we think about it. Yeah.

Aydin Mirzaee  14:23

I love it into this idea of the other thing you mentioned is rapid iteration. And I know this is a thing that a lot of companies do really well. I am curious, especially startups, like really focus on one of the things that curiosity they have is once a company gets as large as rippling, and when you have so many products, and the platform is so big, how do you end up doing the planning and how do you figure out what things need to be planned and other things, it’s just rapid iteration and the plan kind of gets built. So this basically, you know, long term versus short term planning, how does that all happen? Yeah, at a high

Albert Strasheim  15:00

level, probably not that dissimilar from a company our size, you know, there is an annual operating plan, especially, you know, as we keep growing and eventually, you know, look ahead to becoming a public company, you know, there’s a certain set of financial metrics, you know, sales, targets, etc. And a ton of modeling and analysis goes into setting those targets. How that bomb impacts me most directly is the budget we set for r&d, right, which, and then from that flows, a hiring plan, it informs how we want to staff, the recruiting team, etc. So there, you know, I would say is pretty standard series a year standard Series F company planning, and obviously, with each year gets a little more rigorous or a little more detailed, but pretty standard there. Beyond that, we plan quarterly, there’s each team prepares a set of slides, again, like a pretty standard, like look back look forward, I think we do a reasonably good job of also, you know, really reflecting what from the previous plan actually got done, right. And so if we committed last quarter to doing something that we actually do it, you know, lots of slides you’ll see are either in green, yellow, or red. Green is, like we said, we were going to do it, we did it, yellow is like, it’s very close, the planning meeting generally happens two weeks before the quarter starts. So if it’s just just about to squeak over the line, you’ll probably see it in yellow. And then also, importantly, if we didn’t do something, it’s in red. What you’ll see, too, is notice kind of like two kinds of red one is like we didn’t execute on this successfully. But also we will deprioritize work from time to time. And so we try to follow the plans, you know, especially if there’s, you know, customer commitments with dates next to them, delivering those on time. But there’s also a decent amount of the plan where there is flexibility, as new information comes in about the product or what customers care about, or maybe unanticipated scalability or reliability issues, we give ourselves permission to change the plan, even in the middle of the quarter, I think you have to be willing to deal with some of the change management, the communication, etc, when you do that. But I think ultimately, the outcome is better, right? Like following a plan for three months, when it isn’t exactly the right plan can put you pretty far off course. And so we’re generally pretty open to adapting the plan, even inside of our culture,

Aydin Mirzaee  17:28

you people get disappointed when you change the plan. That’s one of the things say that people are working something and Midway you have to make the change. I mean, it happens, but is it just cultural that hey, sometimes the plan changes? Or do you all do a really effective job of communicating? How do you handle situations like that?

Albert Strasheim  17:45

I think there is a cultural element here where you know, over the years, the team has learned to be more flexible to reprioritization. I think if you never do it, and you’re suddenly chopping and changing, that can definitely be challenging. But a lot of the changes are ultimately rooted in there’s a real why for it, right? It’s rooted in wanting to achieve a better customer outcome, or helping out a enterprise customer with a very specific feature request, or we learn that a certain product feature is or isn’t working in the market, and we want to respond so that it sells better or whatever the case may be. And I think what you find, then is like if the team understands the why if you can tell the story of like why the planet is changing, they’re generally much more bought in than if you deliver some top down commandment without any context that says, Let’s delete a and do B, that’s obviously much more painful. A lot of this is generally about pausing work on thing a and starting or accelerating thing B, we generally come back around to the previous thing, it’s rare that we would build something that is just completely throw away. Maybe that helps do is like knowing that eventually we will pick things up again, build some confidence when a reprioritization discussion needs to happen. Yeah,

Aydin Mirzaee  19:03

because this is a thing that happens all the time. Right? Whenever I suppose you create the plan, you think I mean, based on the knowledge that you have, you have a set of priorities and the important things, but then things happen and the world changes, then there’s new information. And so it makes sense for you to be able to do this kind of prioritization. And it’s really great that you’ve been able to figure out how to communicate it with the team and and get everybody bought in. One thing that I wanted to ask you about, which seems like a really interesting idea, and it’s kind of related to prioritization. You came up with this idea called quality weeks and at the free to explain what it is. And just like the story of like, how it was created and and how it all played out? Yeah,

Albert Strasheim  19:46

I imagine many companies wrestling included, have this idea of a hackathon or a hack week. So a company sets aside a week where engineers and product managers and designers and Sometimes even the whole company can work on new product ideas, passion projects, you know, things that aren’t generally on the roadmap. And so rumbling does a heck week, every year, generally around August timeframe. So we’re kind of like q3 for us. And people loved it. What I heard from the team over the first six months or so, that I was here, though, is a feeling that we sometimes prioritize or reward or recognize the new the shiny, like new products shipping above work done to improve the foundation or reduce toil or increase developer productivity. And so you know, the thinking was like, hey, this hack week thing is beloved, right? We have a kickoff ceremony and a week of work on exciting projects, and then a no, like voting and awards, etc. Can we repurpose that structure in a way that also encourages work on improving product quality, improving internal processes, and improving internal tools, it’s a drawing, so a bit of a like ying and yang kind of way of thinking about it. And so what we started doing is saying, like, hey, early in the year, you know, kind of like mid q1 For us, we’ll do quality week, and then about six months later, we’ll do a hack week. And so that’s essentially how quality week was born was a new mechanism to signal to the team that, hey, we do actually don’t, it’s not just about like shipping new and shiny, it’s also about firming up the foundation. And so that is the genesis of the idea. Very

Aydin Mirzaee  21:30

cool. And so the way that it works is it sounds like you have hack week, once a year, and you also have quality week. But here’s the premise, still the same, you know, in hack week, typically, you know, people come up with their own ideas, and they build whatever they want, is that the same thing for quality week, but just it just has to be related to the quality of the non shiny non new stuff, just like making things better. Very

Albert Strasheim  21:52

similar. So both in hack week, and in quality week, we do some top down guidance, right. So myself, you know, other leads on the team will propose a set of projects that they think will be very impactful and can with a strange be achieved in a week. But we also very much want the team to come up with their own ideas. And so the ultimate list and we actually built a small application inside of the rippling platform to manage this, the ultimate list of projects is submissions from managers, leaders, and also submissions from the team. And at that point, we basically go hands off, and we say, everybody can sign up for whatever project they want. If you want to work on a top down project, or one that was guided from the top down great, but also if an engineer on the team or a product manager, or designer came up with something more compelling than the leadership team did like the best idea or the best project when and by all means, go and work on that. If I had to guess, for example, in the past quality week, probably the most exciting, most impactful projects, probably like 99% of them were not conceived of by the leadership team. And we’re actually conceived by the engineers themselves. And so maybe one or two projects of mine got some attention, but actually most of them came from the team.

Aydin Mirzaee  23:11

Yeah, that’s what I was gonna ask you, which is what ends up being the ratio. And so it sounds like you’re part of the crafting of it. So maybe the leadership team might add some ideas. But at the end of the day, it’s just an idea in the pool, and then people decide which things they want to take on.

Fellow  23:29

Does this sound familiar? You wake up, take a look at your calendar and see it’s filled with meetings, project meetings, stand ups, weekly check ins, one on ones, town halls, and those are just the internal ones. Some are productive, but some are a total waste of time. How often have you thought about the time your organization is wasting in unnecessary meetings? I bet a bunch now consider that in the US. There are 55 million meetings happening each day and 85 to 90% have no agenda fellow is on a mission to solve the meeting problem by offering the only meeting management tool that optimizes every part of your team’s meeting workflow with 500 Meeting templates, integrated action items, collaborative meeting notes and AI recording and transcription fellow helps teams and organizations get more done with less go to fellow.app to start your free trial and start having fewer more effective meetings today.

Aydin Mirzaee  24:30

Is there any sort of process around bug fixes? And how do you prioritize new feature development versus maintaining the status quo and keeping the lights on and those sorts of activities? Is there any sort of special cadence to that work or do bugs get prioritized with regular feature releases? Or how does that all work?

Albert Strasheim  24:51

You mean specifically for going day to day product development?

Aydin Mirzaee  24:54

Yeah, exactly like building new features or improving enhancements versus just fixing bugs

Albert Strasheim  25:01

is obviously always a trade off. I think when it comes to bugs, especially if you think of critical rippling products like viral, or parts of the HR system where you’re either hiring or onboarding employees, certain parts of the ID product where you’re managing Single Sign On into other tools for customers, they’re essentially customer issues, Trump basically everything else, especially if it’s some kind of urgent issue that impacts like a mission critical workflow, right? Somebody’s not getting paid on time, or not getting the right benefits or not being able to log into the tool they need to use their do their job, is always the highest priority for us above all else, frequently for bugs like that, you know, it’ll be escalated by the support team to the engineering team, you know, a product manager or an engineering manager will take a quick look, they’ll either fix it same day, if it’s a more urgent and maybe more customer impacting issue, obviously, you will declare an incident internally, there are some guidelines around like, hey, when is it just a urgent bug fix when is it an incident etc. So I think that’s my the story for like the most urgent fixes we do. Beyond that, there’s generally a sprint planning process, I’d say we do a lightweight scrum agile type approach. Different teams here run a little differently, more of them. Some of the more mature teams working on mature products, you’ll typically see a two week sprint for teams doing zero to one development, you know, it’s a very lightweight, like one week planning and execution cycle. And so through that most of the other bug fixes and feature work get prioritized relative to one another. Maybe one or two thought for us, we look very closely at the number of support issues coming in from customers that get escalated beyond the support organization to the engineering team. Basically, all of the teams have been steadily improving that metric over the last two years, where customer tickets escalating to engineering, but divided by the number of customers we have has been trending down. And if we see any kind of reversal of that trend, which generally indicates either some kind of a recurring issue in a part of the product, or an opportunity to build better operational or other tools for the support teams do help customers use the product ongoing, prioritize them as basically the most important thing in the next quarter. And that also helps keep day to day running of the product in terms of level of effort under control.

Aydin Mirzaee  27:38

Yeah, that makes a lot of sense. So it’s essentially, you know, as you’re adding more customers, that the issues that get that make their way all the way to the engineers doesn’t increase linearly. So that’s really cool. So in terms of objectives for the engineering team, sometimes the company tends to have OKRs in place. And sometimes the engineering teams don’t necessarily follow the OKR framework, they follow something different. I’m curious, in terms of the goal setting that you have for engineering, do you follow this same goal setting framework as a company? And what kind of goals do you typically put into place? Yeah,

Albert Strasheim  28:15

I mean, running does not follow a strict Okay, our process, it’s more like high level, firstly, a vision and use kudos to Parker, he’s incredibly good at that stuff. As we raise money reasonably, for example, he published and it’s available on our blog that the memo is shared with investors. And so it’s a great look at the five year 10 year plan for the company. So that’s almost like the long term thing we’re executing on. There’s roughly a three year to five year financial plan. And then there’s essentially, in each function for the year ahead, some numerical targets some like bold X by wide date style of target, you’ll frequently see that with goals that repelling is, it will be to deliver something by a very specific date, it is generally frowned upon to say, by the end of the year, or by the end of q3, for example, we will say 5pm on May 31. And generally, that gives us confidence that we are actually thinking about when something is going to get done. And so generally you’ll see you’re gonna like at the engineering and product level, each of the major product verticals or major sub teams have a set of major features that are trying to deliver for the year, maybe a few key metrics they’re trying to move. And then beyond that, you know, there’s the quarterly planning process. Yeah, we do not generally spend a ton of time obsessing over too many OKRs as much as there’s a lot of metrics under the covers being looked at as we decide what to build and how to prioritize.

Aydin Mirzaee  29:50

Yeah, so it sounds like that you’re keeping your eye on a set of metrics, like the one you just mentioned, how many what percentage of tickets make their way to the engineers, but It largely it’s a lot about deliverables. One question I have in general about deliverables with deadlines associated with them. A lot of times those things are taken a lot more seriously. When there’s a customer involved. On the other end, something’s promised the customer generally happens pretty much on time, there’s a lot of pressure. But when it’s an internal deadline, that set, I know that a lot of companies have more difficulty setting to those deadlines, because it’s an internal deadline, there’s no necessarily outside pressure for it. And wondering how that works. And if you found effective ways to more often deliver things on time when there isn’t a customer requirement. Yeah,

Albert Strasheim  30:39

great question. I would say we are not perfect either in this respect. But I do think rippling has generally achieved a pretty high degree of accountability, even for these kinds of internal goals. I think something that generally helps there is setting goals that are not too far out, right. So obviously, when you’re delivering things for customers, sometimes it’s like, hey, customer X needs this feature. By September, because they are moving the company over to reapplying on January 1, there’s frequently deadlines of that nature. But for a lot of the internal goals, many of them are one or two weeks, you know, maybe four weeks in some of the bigger projects out. And so we’re actually generally on top of whether it’s in a team meeting, or they’ll sometimes be a meeting we call a blitz, which is something we use to manage bigger initiatives in a management meeting like that, for a critical project will generally be looking at milestones, especially internal ones that are quite near term. And so it prevents this drift where one or two teams are wanting to engineers maybe fall behind, you don’t really notice for a while, by the time everybody wakes up and wipes the dust from their eyes. It’s basically too late to do anything that deadline sales by and so I think this rapid iteration, but also like not like every 24 hours, but this like relatively short term goal setting actually, and then staying on top of those helps with more predictable delivery. Interesting,

Aydin Mirzaee  32:10

a blitz also sounds really interesting. So what is a blitz? Is it just a project planning meeting? Or is there more to it?

Albert Strasheim  32:17

Yeah, there’s a there’s a few interesting elements to a blitz, what you’ll generally see in a blitz dribbling today is so number one marker is there he is going and seeing on key things that we’re up to sometimes it will be, you know, r&d activities, you know, you’ll see this in marketing, sales, etc, is generally a pretty small meeting seven participants, Max, everybody in the meeting is able to affect, you know, like outcomes related to the project or the initiative that’s in flight. And then something else we do, which I think is really a superpower of that entire process is we have help from our business operations team, to essentially drive the meeting, take notes, capture action items, help us prepare for the next meeting, make sure everybody’s doing their homework, etc. And so that, that kind of like feedback loop and control mechanism so that we can all remember, you know, in a rapid fire meeting where we solve, you know, 50 or 100 problems in 60 minutes,

Aydin Mirzaee  33:16

do you actually do 50 or 100 problems in 60 minutes? I mean,

Albert Strasheim  33:20

that might be a slight exaggeration. I think in a very busy bloods meeting, we will easily make 1000s of decisions in 60 minutes. Yeah, so making sure decisions are captured. If someone has to go and do something, there’s an action item it is captured. All of that is shared with the team directly after the meeting, going into the next meeting, we’re checking in 24 or 48 hours before the meeting on like, Hey, did we do what we said we were going to do a week ago. And so that structure and just that help from the business operations folks to run those meetings effectively. You know, it’s been responsible for really embracing turnarounds on projects that were kind of stuck or going sideways or not quite getting to the impact that we needed. And so I think, over the last two years, or close to two years that I’ve been here, like just seeing this blitz mechanism play out, maybe like half a dozen or a dozen times since it’s been, like transformative for my own mental model of how to do project management when it comes to a high stakes project or initiative.

Aydin Mirzaee  34:23

It’s super interesting. So it sounds like when something is super important, and it seems like it’s cross functional in nature, there’s a lot of groups and so getting kisi closer together, I assume it’s on some recurring basis until the issue is exactly handled. Yeah. And in passing, you said, Max, seven attendees. Is that like a hard rule or they’re hard the rules like that for meetings that we’re playing?

Albert Strasheim  34:48

I think generally we try and keep these lean, you know, I think seven is also frequently the magic number for quarterly planning. And it’s sometimes interesting, right? You will be like that. Hang on, there’s actually like eight people working on this thing. Or if we look at it carefully, there’s nine. But we always try and boil it down. And so I think it keeps the meetings are relatively efficient. People can still consume the slides or the notes or whatever it may be a sink, but I think it’s a powerful mechanism for keeping important meetings, pretty effective. And so really thinking about the number of attendees, again, I think you can, you can always justify like one more person, but you end up with these massive meetings where ultimately nothing is decided no one takes an action item, like no real outcomes are achieved. And so keeping it tight with small groups, I think is quite helpful. But you know, it varies from time to time, it’s on a principle and we follow to our doom, either from time to time a big team meeting, or a big demo, or whatever the case may be, is completely appropriate. But for selling the stuff where we’re really trying to decide quickly about key issues, we try and keep the meetings pretty small.

Aydin Mirzaee  36:01

Yeah, yeah, that makes a lot of sense. So Albert, one thing that I did want to chat with you about is the future of HR software a little bit, especially with the advent of AI as a building block for a lot of companies, just thinking about, like, how are you thinking about, you know, the future of HR software and software in general, like trends and things that you’re seeing? Or that you’re embracing even, you know, with your own teams, just anything that comes to mind? Everyone’s super excited to understand, like, what everyone is doing planning for this rapidly accelerating future? Yeah,

Albert Strasheim  36:38

I mean, I think ultimately, the way we’re thinking about it is HR software as broadly as like one critical step towards generally software that helps you better run your business. I think ultimately, if you think about rippling starting with HR and Payroll, it gives us a pretty clear and unique vantage point i Who are the employees at the company, their comings and goings, like every key piece of major data about them, their department, their level, anything else, you might need to understand all of their other work. And so I think that’s where the rippling idea kind of starts is like, get a really good record of all of the employees, and then a lot of other delightful products functionality can flow from that. And so I think what you see with your point solution, SAS products in adjacent spaces is they kind of struggle to deliver an amazing experience because they don’t have this like deep understanding of the employee, or they need to sync it from other system, and they maybe don’t get the full picture. So that’s maybe like one key piece is I think, you know, to deliver great business software, you really have to understand the employee really well. You know, the other thing we really focus on here is essentially like building blocks for all of the other software really well, right. So this is things like reports, permissions, workflows, a policy engine, etc. I think reveling has done a great job of building one amazing one of each of those, and then having all of the other apps on the platform, leverage that. And if you do a good job there, you have these, like exciting emergent use cases where the spin product connects to the IT product connects to the HR system, and allows you to materialize some kind of special process for your company that rippling didn’t even conceive of when we built the individual apps. And it’s all going to woven together by these platform features. So that’s where like, another piece that I’m seeing generally, and you know, how I think business software is shifting is like, the platforms that have amazing capabilities in that area are going to do well. And then finally, I think, if you think about the advent of AI, and kind of like where it’s all going, I think one thing that launched language models, a lot of the other exciting research has in common is that it really allows us to make sense of larger and larger amounts of data, you look at, you know, even just the beginnings of these summarization, use cases, taking big chunks of text, turning them into small chunks, being able to index a bunch of data and interact with it through a chatbot interface or have some kind of LM style system like recommend the report or some kind of insight to you. That is I think the next wave here is like large data getting synthesized into small data. And so when I think a lot of the work we’re doing and other platforms, too, is going is ultimately ingesting more and more of this data into a central place. And then summarizing and understanding what’s going on there. And I think to build amazing software in that space, it also really, really helps if you deeply understand the employees that are generating and interacting with with all of this business data and so being able to put the data and the basically the objects of the When’s working with the beta inside of one system looks like it’s going to be really powerful to really unlock the promise of some of this new AI technology.

Aydin Mirzaee  40:08

Yeah, that makes a lot of sense. And thank you for explaining that. So this has been an awesome conversation, we’ve talked about a lot of things. We’ve talked about your leadership, joint journey, this concept of going and seeing rapid iteration, seeing close to the problems, we talked about quality weeks. And of course, we talked about the future of HR software. So we always like to end on a few rapid fire questions. And so one that I wanted to ask you is, what do you think is the most underrated leadership advice for leaders out there? Yeah,

Albert Strasheim  40:40

I think the advice is probably go and see, right? If you are not in the details right now, you really should be so get your hands dirty, and figure out what’s going on.

Aydin Mirzaee  40:50

Love it. And what is your favorite resource for leader sent? You know, this could be a book, it could be a class, it could be like some sort of other resource yet, what would you recommend people go and consume? Yeah,

Albert Strasheim  41:03

probably my favorite. I don’t read a ton of these. But yeah, my favorite management book of all time is a book called The Goal, which is about continuous improvement, the author to guy named Ely Goldratt. This book was written back in the 90s. And was recommended to me by one of the best managers, I’ve worked with a guy named Gerhard Knowles, who works with me or a dribbling, and is essentially a parable about management. So it’s not a standard management book, it’s actually a story, but it really helped me think about, you know, solving problems in a large organization, you know, applying systems thinking, you know, to scaling your teams, etc. And so, if you read one management book in your life, be the goal. Oh, wow,

Aydin Mirzaee  41:45

that’s really cool. And you know what, I have not heard of that book before, and no one else has recommended it. So I’m excited to dig in. So thank you for recommending that. Is there anything that you wish that leaders would stop doing? Yeah, I

Albert Strasheim  41:58

mean, maybe I guess the very popular thing right now is to is feeding the AI hype, Beast, right. And also, you know, like, holding up is the solution to all of our problems. I definitely think this technology has a ton of potential. But I also think, as with other hype, the reality and what is being claimed is, is not quite the same yet. And so it’s like, thinking a thoughtful, sane look at all this new stuff. Reasoning and talking about a thought for me would be great.

Aydin Mirzaee  42:28

Yeah, it’s, that’s a little bit counter narrative, but it sounds very truthful. So I’ll read this has been excellent. So many great learnings. Thank you so much for doing this.

Albert Strasheim  42:40

Yeah. My pleasure. I really enjoyed the chat.

Aydin Mirzaee  42:43

And that’s it for today. Thank you so much for tuning into this episode of the Supermanagers podcast. You can find the show notes and transcript at WWW.Fellow.app/Supermanagers. If you liked the content, be sure to rate review and subscribe so you can get notified when we post the next episode. And please tell your friends and fellow managers about it. It’d be awesome if you can help us spread the word about the show. See you next time.