Amir Bormand: [00:00:00] On this episode of the podcast I have with me Ross Desmond. He’s the head of software at Butler. We’re gonna be talking about building teams that can make fast decisions. I think Ross has some, some great viewpoints on this. He’s seen different environments, different drivers for growth when you should hire and how you empower those teams.
I think we’re gonna get a bunch of examples and stories, which I’m excited to hear. Ross, thanks for being on the show. Thanks for having me. Absolutely. Let’s start off at the top. Get two things out of the way so everyone knows who you are and who Butler is. So if you could tell everyone what Butler does and some of your responsibilities as head of software we’ll dive on in.
Perfect.
Ross Desmond: Well, Butler’s the world’s first and only 100% wireless anonymous people counting an occupancy sensing platform. But what that really means is how can we use data in our real estate to help drive our occupancy and utilization of our space so that way we can make sure that we’re maybe the most productive [00:01:00] or the most comfortable as we start to move forward in, 2020.
And so I’m head of software for Butler, and what that means is I handle all front-end a p i and backend services, as well as some of the software architecture of how the entire system plays
Amir Bormand: Awesome. It’s, I think we could dive into an episode talking about what you guys do.
Cause it seems like a pretty cool product, but different topic, different day. This episode, I know we’re be talking about building teams that can make fast decisions. I guess before we, we dive in let’s actually maybe just talk about what that means. Cause I think it can mean so many different things.
It could go so many different ways. And I think, to start the podcast off I’d like to. Get your thoughts on, we’re talking about making fast decisions within engineering teams. What are fast decisions and what decisions need to be made quickly?
Ross Desmond: Yeah, so decisions come with this problem scope.
And that problem scope is directly related to decision [00:02:00] making and going fast. An example is a scope might be fixing a bug. We, if it’s within my system, then it’s pretty easy and I could probably do that within an hour or two and get that system deployed. But if the bug were, say, across multiple systems or across teams, that starts to increase the velocity or decrease the velocity, increase the amount of time spent, just trying to get a handle of that bug and then being able to deploy and solve that problem.
And this goes from bugs to features. It can go all the way into architecture decision. And we start to slow the speed of our team as we start to increase how many stakeholders and how many others that we actually interact with. And then finally, what’s it like to deploy a system and how interconnected that system might be.
Really decreases the speed at which we can start to make improvements for our customer. Absolutely.
Amir Bormand: And I guess you know, a couple things you said in there obviously you know your [00:03:00] system that’s different than being involved with a problem that needs a decision that you’re not necessarily involved in.
As the head of software, obviously you see across systems, you have different teams that handle different problems. Some problems might span different teams. As you’re looking at that and you’re trying to make sure that you’re building a team that. Make a fast decision. When you’re looking at that architecture, that team design, where do you start to make sure, like right off the ground, and I guess, you’re part of a, a startup, you have that opportunity to, build things a little bit differently versus more established.
And I know you worked at Amazon, which is different, career path, different environment. But when you’re looking at a startup, And you’re looking at wanting to build these teams that can make fast decisions, obviously within the scope of what they’re doing. What are some of the things that, you try to put in?
Ross Desmond: Yeah, so we can go back to simple object oriented programming. When we think about our system as a whole, we need to [00:04:00] define the boundaries between our between each subsystem. And it’s important that we define boundaries, both in terms of what other communications we have between other subsystems, but also what the, who the customer is for that boundary.
So an example we might have here is In robotics or in iot, ot, where I, my, I’ve previously worked, we have data coming up from our subsystem that’s on premise. We need to be able to ingest that and then work and chew that data and enrich it, enhance it, and get that into our data lakes. So if we were to define that problem and just draw a box around it and say, okay, this is our backend and no customer can touch.
And no one external except for these two teams, which is this hardware team on the ground and maybe the API team. What I can do is I can bound my problem. I don’t need to solve customer problems in there, and so that allows me to reduce the number of teams and the number of interactions. That team may have to work with.
[00:05:00] And so it’s important to basically take all of your hardware, all of the paths that this software can go through, that this data can travel, and then try to circle it. And if that piece touches more customers, you’re gonna increase the decision radius that you have to make and therefore decrease the velocity.
So it’s important that when you start to see these connections, extra connections come in, Hey, can we do this? Can we touch this backend for the customer? It’s important that a little red light goes off and says, okay, now I’m increasing the sphere. So any bugs that occur there are now going to be a direct correlation with those customers, and that gives us less freedom to upgrade that system.
Amir Bormand: So problem scope, it’s interesting, obviously how you draw that circle will expand that problem scope as it gets wider. The velocity obviously has to shrink cuz you’re gonna impact more people. There’s more moving parts when you’re looking at teams and at their [00:06:00] grainier level.
Obviously everyone wants to empower teams, but obviously, as this problem scope grows and you have to slow velocity down, make sure everyone understands. How do you coordinate that with the team? Because I think on one hand we want teams to move really fast, on their own, be empowered.
On the other hand, they need to be aware when it the, something’s outta scope, something’s bigger than they are, and then we need to slow down it. It’s not always cut and dry. It’s
Ross Desmond: not always cut and dry. And that’s completely true, especially when the needs of the business kind of come in. And so you have to ask yourself a question, am I.
Am I increasing the scope of this current product to do something that it was not designed to do? And if the answer is yes, then you have to slow down in order to go fast. If the answer is no, then we can start to draw some bounds. We can say, okay, actually let’s create a separate, smaller system.
That acts as a buffer between our customer and our backend system. So start to decide making, basically making decisions that separate responsibility and [00:07:00] using the group to do and so now you’re talking about how do we speed up or slow down so we can talk about velocity being related to scope and decision making.
When we think about the scope or the size of the problem, and every subsystem and stakeholder or customer that increases that size from what we originally perceived it to be, we need to then say We now have this system that has increased and we have to decide who do I talk to in this scenario?
And so something like building habits, some of the books that we’ve read on how to build a habit, building triggers, that’s all part of this. So we have to build a trigger. And your trigger in my trigger that I define with my teams pretty easily in our charter is the time it takes, I think it will take to solve the problem.
And so with software engineer, We can distill a little rule that I have, which is if an engineer says it’s going to take one day, it’s going to take three. If it’s going to take three days, it’s going to take a week, and if it’s going to take a week, it’s going to take three weeks. So with [00:08:00] that, armed with that information, you can also assume the size of the problem.
And so what we do in our team charters, and I make sure that every one of my teams does this, is that we break down the problem, say, and we have a decision making. Cause when can I make a decision? And then what other customers, stakeholders, or people do I need to bring in based on that size of that decision?
And so for a one hour decision, which and my role takes a day, you can do that. If it’s a day, you’re gonna want to check in with your team. You might need to implement something early on, especially if it’s a young team. You have to have a template. Let’s make a template. Show me what the problem is and how you plan on solving this problem.
And anything else you’ve considered. Small, short and sweet, less than a page. But that’ll give you some information about where the team’s at in their decision making. And then once it goes to a week, that’s a whole team decision. Maybe it brings in your senior, your team. Ensure that’s working.
And then as soon as it’s a week that requires a [00:09:00] high level design document and maybe a technical design document. Usually when it’s a week, the engineering effort might be only a week, but upgrade, rollout and impact are significantly higher.
Amir Bormand: When you, it is interesting. I think that’s I think you mentioned the team charter.
Is this something formal? Is this something that is just discussed? Is it tribal knowledge? Could maybe you just give us a little insight into that. Would.
Ross Desmond: Yeah, so actually I’m looking at one right now. We have our API and front end team charter. I pull those two together. The teams are actually separate.
I have a API team and a front end team. They do some cross compatibility, but otherwise they’re separate. But the reason I bring ’em in for this charter is that they’re small and that they need to know who to talk to when they make decisions and a p i and front end while they’re hand in. So we need to make sure that they understand how to make decisions together and they’ve agreed upon it.
So we go through and we have a meeting and usually it’s really fun. We do a summary together. We go over what that team owns, we put our customers in, so who do we do this for? And our customers aren’t just [00:10:00] Butler customers there, our other developers, they’re our install, install techs, and they’re also managers like myself because I need to know how I need to communicate with my customers.
Should something. Then we go through our team norms, how we work, cross communication, what does on-call look like how do we make, and then finally, how do we make decisions? And in this role we say when do we make individual decisions, team decisions? And also, how do I present my ideas to the team and beyond?
So we go through all of this, and usually in this area I give one one thing that I see based on the team dynamics and sometimes. That’s a kind of a story that we can start to talk about in a little bit. I think I have something prepared from teaching martial arts. But this is a very important thing.
It’s being able to give a specification that helps drive the team. So it’s like a team tenant, but you wanna make sure that from a management perspective, you’re not telling the team where to go. [00:11:00] You’re giving them a central idea to start building off of. And for startups, the build, measure, learn philosophy is one of those really good ones.
Making sure that we are learning every time we deploy something. And so in this case, when I arrived, we had no metrics bond. What our customers were actually utilizing in our system. And so that was the first thing that we implemented was how do we get that feedback loop? And now we’re deploying faster, understanding our customers better.
And that was one of the original driving factors I added to that team charter.
Amir Bormand: That’s awesome. And the team charter, is it, do you have a tool you’re keeping it in? Is it just, a pure document or how do you actually maintain that repository of team?
Ross Desmond: Yeah, so this one we ha I have a notion it’s only each team has their own team charter and I look through them to and work with them.
And these are also living documents. They change and every time we have a new person on, we get to do this again. Usually it’s a lot smaller, but also things change over the course of even the last six months I’ve been here. [00:12:00]
Amir Bormand: Yeah, I was gonna ask you, cause I think that’s the one thing that I was gonna, wonder is as this, as the team charters built and how quickly you go back and obviously you mentioned every time you hire somebody new, I guess as an example you mentioned you have either front end and the a p I team are smaller teams.
There’s one charter, they’re very related. What happens when they gotta grow up and separate and then you need two team charters and obviously the impact on. Customers or other teams that interact with the that frontend or API team?
Ross Desmond: Yeah. One thing I’ve had to do is we separate the team charter, but we ensure that in the decision making portion, we go and we talk to those teams that we’re going to work with.
And for us, we’re an API I first company, so we’re not only so creating APIs for the front end, we are creating APIs that work for our. And so it’s important that we bifurcate those and have two different customers with maybe two different ways to go about that problem. And usually that’s up to us on our leadership teams, on which one do we solve maybe first, [00:13:00] or how do we make sure that both those customers are being kept in the loop and working appropriately?
So this is all part of that decision making
Amir Bormand: piece. You said something. I just I remembered, I was like, I gotta come back to, cuz you said something about a martial arts example and I and I, and it’s been sitting in the back of my head outta curiosity and I was like, I gotta ask you before I forget.
Ross Desmond: Yeah. So this is, comes to like, how do we empower people to make that happen in the first place? Absolutely. People. Especially when our problems start to increase in velocity. So like I have this mental model, and the mental model is the velocity of the solution being implemented is inversely proportional to the speed at which that circle increases and the diameter of that circle.
So oftentimes for a junior engineer, they come in, I can solve this problem 100%. And then all of a sudden you add a customer on top of it and they go, oh I’m like a little bit nervous. I’m not sure if this is gonna like how bad this is gonna impact them. But then you add another stakeholder or you add a subsystem that’s not quite working appropriately, that you have to upgrade and then you reach stall [00:14:00] point.
And so depending on the level of the the experience of the engineer involved and the size of the scope creep from the initial mental model, what the solution is, you reach a stop. And so us as leaders, how do we make sure and empower people that they can push past that and that they have the resources?
And so this is important for us as leaders. So as in martial arts, I grew up in Trumps for Massachusetts, where I had a martial arts teacher who taught me how to teach. And I was young at the time and I would say I was probably around 11 or 12 when he started teaching me how to instruc. And one thing that’s stuck with me is no matter the age group you work at, depending on the level of interaction and how excited they are, you ha as an instructor have to be either on one end of the spectrum or on the other.
You have to find where they are, and then if you want to elevate them, you need to be higher. And if you need to bring them slower, you need to be slower. And so it’s important that we don’t, as leaders, [00:15:00] don’t just set the example at exactly what we want. They’re never gonna get to exactly which one. If you’re there, it’s like that.
It’s like a Taylor Series approximation. We don’t ever get there if that happens. And so what we need to do is be one up or one below. And so that includes on this team dynamic. So once we set those decision making, you as a leader have to start acting at that level. So if they act too fast and they try to get the solution out, you have to be acting as the person to slow them down.
You know this is gonna happen cuz you have a mental model about the size of this problem. You know that this deployment might reach 10 customers. You know that this person maybe jumps in and tries to deploy an entire. So the first thing I do is ask them, Hey, what’s the rollout plan? How do we expect to ensure that our customers are still going to be happy as this rolls out?
And how do we know when to turn back? And so having them write up a rollout plan ends up going, oh, actually the solution needs to change because we don’t have the ability to do [00:16:00] this one thing yet, so I need to do this, then this. And so that slows them down. On the flip side, you have the junior engineer that might get stalled.
And so you gotta provide a process for them to go through it. So I have this document that I had both at Amazon and here called How to Run a Software Process. Software project. I had to rewrite it again. But it’s good cause it helps me to think. But that one goes through and says, okay, I am here.
What do I need to do next? And it gives you kind of step-by-step instructions. Okay. Today it’s Friday on the weekend. I’m working on this project. I need to inform my stakeholders about where we are with this project. And then for them, for a junior engineer, you need to tell them what they need to inform on.
And so it’s important that you’re informing on a milestone that actually impacts your customers. So there’s all these different pieces and you have to play that role depending on the personality of who you’re working with. I
Amir Bormand: like that. That’s such a. I think it’s such a realistic example and I think anyone who’s ever tried to teach somebody has come across people who you both need to [00:17:00] speed up for for or slow down for.
Which is interesting. I was thinking about my own daughter who’s not, and I was thinking about that same thing where sometimes I find myself trying to slow her down cuz I know she’s missing something. As you’re looking, in your framework of, wanting to make the. Get to decision point faster.
Obviously it sounds like that empowerment all the way down to the junior engineer even is super important because you have to make sure everyone trusts each other’s decision making, scaling of the problem in their mind. Cuz obviously you can’t really trust somebody if everyone’s scattered in a billion directions and you always have to feel like you need to be responsible for their thought processes.
There’s a bottleneck there. As a leader, you can’t have.
Ross Desmond: Yeah, exactly. And if you put yourself in that process all the time, at every stage, we can’t possibly succeed. So we have to do, how to build a habit? You have to instill a trigger of when you should be called in.
And that all depends on the experience of the engineer as well. And you [00:18:00] can be a connector manager by installing a trigger to someone else as well. Okay, let’s go talk to your senior engineer when you hit this stage. Every time you hit this. Or and something I tend to do is engineers that are really fast.
I just say, give me your preferred solution and then gimme three others that you’ve considered and that May, may teach them something or they might grow from that. And guess what? I get to grow from that, from every single engineer doing that. I learn. 20 new ways to do 10 different things. So it’s been pretty
Amir Bormand: nice.
Interesting. I guess the one thing that I wanna touch on cuz we’re talking about faster decisions. We’re talking about empowering employees, at different levels to make decisions. I think we have to talk about when things go wrong cuz I think, that’s the key is everyone can make a decision.
The problem is people are worried. That accountability piece, and again, I’ll use my nine year old I tell her to go do something. If I react negatively and she’s made a mistake, she might think, oh, making mistakes are bad. And a nine year old in her world, I [00:19:00] could shift that. So I’ve gotta be super careful.
I feel like sometimes my wife and I are like walking up eggshells to make sure, Hey, we wanna make sure you’re, you understand it was okay, but how did you learn from it? What did you take away as an engineering manager? You want fast decisions, you have this really interesting mental model of having people be able to be empowered.
What do you do when something goes wrong? How do you help somebody understand the ramifications? I hate to use the word postmortem but what happens? And we do have
Ross Desmond: those, right? We have COEs, we have cause of errors. Cause I do come from Amazon and that process is pretty nice. The five why’s is really important.
We do it as a team and it’s really important that we tend not to call out names during that time. So we sit there and we go through, okay, what was the original cause of error? How did we end up here? Why did we even end up here? And when we made this decision, what other factors did we have? And One thing that I always reiterate when our teams are going on call, which we are always, when I, when the system is done, when we’ve solved it, I [00:20:00] recap to our team members, you know what we learned what we did, and I thank them for all the effort that they put in to make this right and that we make decisions.
And while maybe some of them don’t go out quite well, the. Response is also something we need to value. And so people sometimes get scared to make a decision, but if they know that I’ll be there and our team will be there, and we’re doing this as a team, that also means they’ll come to us before they make a decision sometimes because they know that we’ll be there when that happens and that we all want to work together.
And so it, it really comes down to this just trust that we have to build. And that’s part of the reason why I make sure that, I’m on call when a lot of these things happen and I jump on. I don’t need to control the situation. But an example is we had a server go down because of some thermal event, and it didn’t affect any customer data, which was fantastic, but as we were doing it we all got on [00:21:00] there and I didn’t really need to be involved with the solution of the actual technical piece.
Instead, what I did was I wrote up what was happening. I provided those updates into our channels that needed to be updated. Our business team knew, our engineering team knew what was going on so that they didn’t jump onto an accidental impact from this event, and then summarized our impact at the end.
And then thank the team for doing it publicly, so that’s kind of part of where this comes into is we have to own and be public about what our engineers have done and how well they’ve done it. And then also talking about future-proofing. And so in our one-on-ones afterwards, I’ll go through and we’ll talk about this.
Yes, we made a mistake here. I really appreciate that we’ve mitigated this portion and we future proof this portion. What would you do? Differe? What maybe should I do as an engineering leader to get us all on the same page to make this not happen again? So it’s really crafting that
Amir Bormand: narrative that makes complete sense.
And as you’re that [00:22:00] one-on-one piece and you’re asking. You somebody, what they think went wrong. I guess what are you looking for there? Because I think, obviously, sometimes, there’s gonna be some, they’re gonna feel maybe embarrassed or maybe it was a solution they easily missed.
So there’s a lot of emotion that goes with that, right? And I think it’s sometimes hard, everyone is unique. They’ll take, a loss differently when you’re going through that one-on-one. Are they, are you looking for something or are you, or it’s more of a guidance through that process for them.
What, what happens? Yeah,
Ross Desmond: Usually I’m looking for something when it’s a junior engineer because we’ve already, we’ve all been there. But how do you get them to know that we’ve all been there and not be in that moment where it’s oh no. And yeah, that one’s a really tough one. A lot of it comes down to being like, have you read the book with radical candor?
It’s really about being direct about the point and that it’s not something that the. Person. It’s not personal. It’s something that the way we think, it’s about our process and how do we change that process? Yes, people definitely get defensive. I [00:23:00] still get defensive in and out. It’s about recognizing that defense.
Now I’m able to do that. And in. Engineers and junior engineers, it’s, Hey, I let’s pause this conversation for now. I understand that we’re feeling a little bit this has happened pretty close to us right now, so let’s pause it and let’s come back to it, because remember, we’re on the same team.
We work together and we just wanna be here for each other and then kinda leave it at that. Usually it comes up, actually, most of the time if I leave it there, I’ll receive a slack message, be like, Hey, I’ve been thinking about what you were, what you said. Let’s re-talk about it cuz you know, I’m interested in how I can grow here.
Amir Bormand: I like it. I, Ross I think it sounds like a pretty cool environment to, to be able to operate in. I like environments where, you know it that, that empowerment and the accountability piece. It disproportionate. Meaning you want empowerment and the accountability, yes, you have to take, but there’s the consequence piece is missing.
And I think a lot of times different orgs say it, [00:24:00] but the consequence piece is all there. And you have people who are afraid to be empowered because they deep down know the culture is one of, we want blameless, but not really. Somebody still has to be held accountable and it’s that’s difficult. I like how you said, you guys don’t call out names.
I think that is.
Ross Desmond: And you do have to be accountable. You’re totally right. And that’s something that it’s really empowering to say, I am responsible for this piece. So instead of from an engineering leader saying, you are usually I’ll say, Hey, my mental model of this situation is that this system and this system are owned by this.
Can you guys confirm? Can you confirm what you own? And when they say it, it’s empower. It also triggers how they will respond and think about the solution when it goes out as a reflection of yourself, but it’s also important. My first manager at Amazon told me when I joined, he said, if you don’t break anything within a month, I don’t know what you’re doing here.
And I said, okay, fair point. I did end up [00:25:00] taking down a warehouse for 30 minutes which was like really scary and really embarrassing at six in the morning on a Monday. So this I felt it and then I never felt like I needed to fix something so much after that. And it was really empowering and so comes back to that manager as.
Amir Bormand: That’s awesome. That, that, that’s such a great story. I think if I was onboarding, I heard that, I’d be like, all right, now there’s not much worse that I could do than taking down the whole warehouse. I’d feel pretty good about myself as a, as one of your employees. That’s probably a good story to tell at times.
And thanks for being on. I think I could probably have you talk on the subject for hours cuz I think, you got such a great view on this stuff and I like the way you think through about it. Before I let you go, a few things I’d like to ask all my guests. If they could have a future guest cover a topic for you what would be something that you’d like to listen to?
Ross Desmond: Yeah, so something I’m really curious about and only have my experience to say is how does sprint methodology or combine methodology change based on your team dynamics? We have personalities that work [00:26:00] well in static versus dynamic environments. And I’m curious to see how do we ebb and flow at this?
A static process or product management process usually ends up failing at some point. So anyone have any insight into that?
Amir Bormand: That’s good. That’s a good one. I’m gonna, I’m gonna ho hopefully find somebody talk about that, cuz I think I’d actually be interested in hearing it myself contact wise. If somebody just wants to reach out to you, talk about anything about the podcast or just in general what is a good way of getting hold?
Ross Desmond: I think LinkedIn is probably the easiest way under Ross Desmond. Take a quick search and yeah, hopefully I’ll message you then. Okay. Yeah,
Amir Bormand: We’ll include that in the show notes so that somebody could, does wanna reach out to you. They can just click through. Ross, thanks for being on.
Thanks for sharing. I really appreciate it. Thank you so much. Absolutely. That’s it for this episode. Be back again. Different guests, different topic. Until then. Two things, one. If you do know someone or you yourself can speak to the topic that Ross mentioned about how does a sprint, orba, and methodology change [00:27:00] with team dynamics?
I’d love to know. I think other people would love that episode as well. And secondly, if you know you found the podcast useful, if it’s interesting, share it with somebody that also might like it. That’s how we grow. Drop a review someplace where you listen to it. All those things help the podcast organically grow.
And I can’t thank you enough. Until next time. Thank you. And.