Complexity Killed the Process Star | Robin Spencer, Purpose Built, Clearbit, Google

Ken Babcock (00:01.11)

Hey everyone. Welcome to the change enablers podcast. We are lucky to have Robin Spencer with us here today. Uh, Robin's the former COO of clear bit. She's currently an advisor at clear bit as well as the artisans cooperative. Uh, she was the former head of strategy and operations at google.org. Um, and now she's going out and starting her own consulting practice. She's working, uh, with purpose built, uh, which is a venture studio. Um,

which is super cool, working with founders, generating ideas, building teams, investing capital. These are all the things that myself as a co-founder, we're all like really hard doing it on my own. So I respect what you're doing, Robin. Super cool. Um, but welcome, welcome to the pod.

Robin (00:39.453)

Totally.

Robin (00:44.817)

Thank you, I'm excited to be here.

Ken Babcock (00:47.79)

And we'll get going with, you know, we've got a lot to cover today. I'm super excited, just like prepping with you about what we were going to talk about in this episode, but maybe one quick question, just to kind of break the ice for everybody. What are your three favorite software tools right now?

Robin (01:05.969)

right now. Let's see, I think I would say, it's an oldie but it's a goodie for me, which is Google Keep. I have tried every productivity tool and I always go back to their stupid little Post-it notes. I think it's one that I will use for forever. Chat GPT is kind of a given for me right now. And then Loom, as somebody who works fully remotely, being able to talk to people in that rapid format is really important.

Ken Babcock (01:34.006)

Yeah, that's amazing. And Loom, big news recently, you know, being acquired by Atlassian, which is super cool. I'm actually, I'm a huge user of Loom. And I'm pretty excited about that partnership too, because it just means it's going to be like more pervasive. They're going to keep the product alive. There's going to be better integrations. I don't, I don't know if you, uh, if you feel similarly.

Robin (01:41.046)

I know.

Robin (01:55.081)

I feel, yeah, very similarly. I mean, I think for the same things that where I would want it for actually implementing actions after, I think that'll be a common theme of our conversation, but I think it's exciting to see what they can do together. And I'm excited that the product stays alive.

Ken Babcock (02:10.506)

Yeah. And I'm super stoked about what you're doing with purpose-built. And I sort of mentioned that upfront. Um, anything you want to plug there or sort of talk about that you feel like is unique about, about the model that you're pursuing.

Robin (02:23.789)

Yeah, I mean, I think two things, if someone is interested or has an interest in this very early stage startups, I'd love to chat with you. And I think it speaks to something that's really important to me, which is figuring out the right people for the right roles. And I love what Purpose Built is doing around that, of making sure that the founders are getting placed with other folks that are really excellent. And I love talking to people, so it's a great.

a great fit there. So if you're interested in starting something new, we'd love to chat.

Ken Babcock (02:54.814)

Yeah, that's really cool. I, uh, I routinely, uh, I'm grateful for the fact that I, you know, met co-founders that I could work compatibly with liked. Um, and you know, we've been on this journey forever, but that's, that's not a given for everybody else. And, you know, I actually, um, spent some time at Atomic, another venture studio, and I loved what Jack Abraham who runs Atomic, what he had to say.

Robin (03:07.598)

Yeah.

Ken Babcock (03:23.018)

About this model, which is, you know, founding is such a huge leap that it actually prevents a lot of people from pursuing it in the first place. And so if you can kind of lower that barrier and provide resources, um, and, and maybe bring somebody in who, who normally would be too risk averse to do it on their own, um, that's a really powerful, he called it a talent realignment, um, which I love. So really cool. What you guys are doing. I want to jump in and just, just talk about.

Robin (03:45.461)

I like that phrase. Yeah, good phrase.

Ken Babcock (03:52.874)

You know, your experience, you ran operations, uh, at a part of Google and then you were the COO clear bit. Um, you know, one thing we come back to a lot of Tango is within operations. How much of this is process and how much of this is people. And I'd love to hear kind of your viewpoint on that.

Robin (04:11.581)

Yeah, such a good question. I think from my perspective, it's all about people, which is I think one that people will sometimes roll their eyes at, because there's gotta be some sliver that is process, but I think it's deceptively small and it comes really at the end. And usually we try to put process upfront. And I can illustrate a little bit with a story of when I started at Clearbit, because I was completely out of my element. I was coming from Google, huge company.

One where they had so many processes and systems that were already really established. So I assumed everything was about process. I remember coming home on the first day and being like, oh man, there's so many missing processes and every process is broken. I had this list of like, these are all the processes we're gonna need to fix. And I think, you know, what it ultimately ended up being was the wrong list. It was a list of a bunch of different tasks we needed to do. But what I was...

what I had kind of miscategorized as a process was really a lacking of documentation. There was no documentation, but the processes, if you think of a process as just a collection of the behaviors or actions that people are doing, those were all in place. They may not have been formalized, but that was already happening. And so what it really took was, how do we actually go back and uncover what are the current processes?

that are there and are they the right ones to have? And when we started to ask those questions, it became a very different sort than we started. And I think that ultimately came back to, okay, it's all about the people and what their actions and behaviors currently are, and are they the right ones? And then from there, that's the final sliver of the little bit of process at the end. But I had to learn that kind of the hard way.

Ken Babcock (05:59.022)

And that's a really interesting takeaway because it's, uh, it's almost because like something's not visible. It doesn't mean it's absent. Um, and so it feels like the gap that you're describing there was not necessarily, Oh, we don't see something. So let's create a process. It's more the process exists. It probably just isn't documented. Is that fair to say?

Robin (06:21.513)

Yeah, exactly. It was, and it may be the wrong, it may be a process that developed because there was a vacuum of a formalized process, but I think being able to still say that in and of itself is a process, it might be the wrong one, but starting from that point of view is so different than saying, okay, I'm new here, I've, you know, this big title and I'm going to come in and implement all these processes and everybody's going to just do them. First of all, no one does because it's not

kind of what they're habituated to do, but it really helped kind of, then you kind of need to step back and figure out, yeah, these are the ones that we should continue to do. These are the new, new that we implement.

Ken Babcock (06:58.934)

Yeah.

So it sounds like you had like this aha moment of, okay, I'm going home with this list. I'm trying to recreate all this process. It already sort of exists. And so it's more of a documentation gap. What was kind of the inflection point for you where you were like, oh no, this is all about the people that we already have. And then once you realized that, how did you continue to cultivate that within the team?

Robin (07:26.329)

Yeah, I think, so I think there were two things. I think what it helped me to do was to slow down that any, you know, as a COO, people are constantly coming to you with, this is a problem, this is on fire, this is broken. And my gut instinct was to, oh my God, we gotta fix it immediately. Like I just wanted everything to be fixed immediately. And I think if you're taking the approach of, you know,

This is either a process that needs to get formalized and documented, or this is a process that needs to change. You're asking a lot more questions upfront to better understand the current state. So is it really that it's broken or is that person's feelings heard about something else or is it something totally different? But spending more time in that analysis of like, what is actually working or not working, allowed us to put people first in a more cohesive way.

and then figure out the right process to go with it. And I think that's the piece that like, we didn't always get it right. You don't necessarily then make the right decision after that, but I think it allowed to have more of an operating rhythm that started with, these are the people we have, this is what they're currently doing, what are we gonna continue doing and elevate? And then what do we actually really need to do, like a specific change management approach around? And that became kind of our ethos and a lot of.

really in the beginning it became, yeah, writing down a lot of things that had not been documented before. We had this like mantra on the team of like, documentation is fun. And it was like really not that much fun, except that it made you really think about like, what is it that we're doing behind the scenes, then what are we asking all of the other teams that are so interconnected with ops to do as well? Because in the absence of that, people were just making up their own versions. A good example would be like,

We came in and we had no way of really kind of formalizing who is spending money where, and it was just sort of like be good stewards, which is an awesome, like that is a process, to be a good steward of the company's money. But to have a few more guardrails in place allowed for that to not be every single employee making their own decisions of what that is, but not so process heavy that you have to go look up 500 steps to figure out what it.

Robin (09:49.349)

what it should be, what you should be doing.

Ken Babcock (09:52.074)

Yeah, there's almost a balance there of like, how do we, how do we prevent people from like solving the same problems that have already been solved and, or, or like going through that decision-making process again, even though already someone's already gone through it. Um, and so I'm curious too, you know, you joined at a, at a stage where, where how big was your team?

Robin (10:00.793)

Yeah, totally.

Robin (10:16.345)

My team at the time was 12, 10 people, but that was spanning multiple. So operations there was everything from people operations, we had finance ops under it, to Salesforce revenue operations at the time. So it was.

Ken Babcock (10:34.506)

Yeah. So you're probably in that, in that phase of like, everyone's kind of a functional head in some way. And so it was like contained, contained to them. Um, which is, which is a, you know, you then reach sort of a scaling moment where all of a sudden they can't just live in that one person's head cause they aren't just the function. So maybe talk to me about maybe the team sizes where you felt like there was a real inflection point around.

Robin (10:40.845)

Yeah, totally. Yeah.

Ken Babcock (11:04.418)

how you optimize those teams, how you documented process, how that balance changed. Were there like key moments or key team sizes where you just, you felt that pain more acutely?

Robin (11:16.941)

Yeah, it's such a good question. I don't know if we ever like struck like this is the answer that every team should go for, but I can share some of the pitfalls we ran into and I think what principles I've gleaned from it. So I think some of the pitfalls we're thinking that if it's just a single person team that that, you know, that therefore that person can get away with just having things in their head. You are already as a one person team, part of a bigger.

organism of the company. And I think if you can take that mindset of, sure, I am the head of this function, but as head of this function in a one person team, I'm really all 90 roles that would be in place by the time we get to Google size. And if I take that mentality, and I'm not saying then put into a process that you have to then do 500 checks and balances, but if you're taking the mindset that it's gonna be more than me at some point, that forward thinking I think helps set up

for when you do get another person. Because as soon as you have one other person, things really can't live in one's head because we can't read each other's minds as much fun as that would be or as much as we think we can. And I think that's the piece is like, and because those one person teams are interacting with another one person team that is trying to get their work done. And so I think it's from.

I think my learning from it, because the pitfall was we kind of allowed some cutting of corners. It's one, you're one person, sure, you can let that live in your head a little bit longer. But I think if you can have that diligence to be writing things down at that point, you can always edit it. It can be a working document or a working kind of statement of this is how we do things. I think that's where it begins, because it A, starts the culture up front.

Ken Babcock (12:45.998)

Mm-hmm.

Robin (13:04.941)

and you get in the habit, it's that new kind of habit development early on, and be as soon as you get to a second person. Because once you get to 30 people, it's so crazy, right? Cause if it's not written down then and you're kind of back writing, which is a lot of what we would do, you'd find, we would find at least that our process got too complex cause we wanted to tighten down. Like it was like, we got afraid that we'd lose control cause there were more people.

And I think my learning from that time was, if I wanna tighten down, I probably need to loosen up and like, what's the minimum viable thing or process or statement or policy I can make? Otherwise you have people spending more time reading policies and processes than they do actually doing things.

Ken Babcock (13:54.006)

Yeah, I think that's, that's so interesting because I mean, even, even when I was asking the question, I was, my instinct was kind of like, ah, it's one person you could probably, you could probably get away with it, but I think you're so right. Cause also when you think about that one person, you know, that's like a key person risk, will that person ever be able to go on vacation? What if they leave? Cause they get burned out by the role that encompasses 90 roles. Um, so I really like your recommendation of.

Robin (14:13.095)

Holy.

Ken Babcock (14:21.806)

create that culture upfront when it is a one person team, when it's easier to manage before it gets like completely out of control. Um, so I, I hear you there and you know, we've, we've kind of touched on this idea that, you know, it's people before process and then process needs to be this balance or it needs to be lightweight enough. Can you talk to me a little bit about tools? So you had mentioned you got to clear a bit.

There were more tools than people, which is wild, but I think that's true of a lot of companies, honestly, I mean, we definitely have more tools than people, but you know, we're smaller. Um, what are some implications of that and what, how did you see it sort of manifest itself, you know, when you first joined?

Robin (14:53.424)

Yeah.

Robin (15:10.921)

Yeah, it was, I think it was really around, like we were around 100 people and we had about 100 or so tools. It may have been kind of over time we've fabricated it more, but I think everyone at Clarebutt would feel that kind of like same essence, which was at the time, the experience was, if I need something, I'm gonna get it. And I think like the intention was there, right? The intention was I wanna get my job done and the best way to do this,

is to kind of fill the void and get the item that I need. But I think what it was lacking was kind of any version of taking that step back that we were talking about before and saying, great, that was an awesome example of jumping directly to the solution. What is that problem that we are ultimately trying to solve? And then what are the different options to solve it? And I think that was what we ultimately needed to do. And it was.

It was a tiring process once you've gotten to that size and stage. I think this is something that if you're earlier on in the journey, being able to decide what are going to be our principles for how we bring on more software, who's going to be in charge of the tech stack and what that really looks like. Because what we ended up doing was really kind of putting, putting the power in the hands of each team leader and saying, great, you got to cut some of these pieces of software, what are you going to cut?

And it was a big back and forth. And I think one of my learnings from that was, I remember feeling as if, cause some people are so mad about it. It was just like, why are you taking away my favorite, you know, like I get these long Slack messages of like the reason this is like the most important tool and it would be, I don't know, we'd have two users who were using it somewhere for some small specific thing. But to that person, it was the most important tool they had. And I think what my takeaway from that

you know, kind of, I guess, give as advice to anyone else in this position is, how do I not look at that as like some problem I had to like overcome or steer kind of like strong arm them into my way? It was more like, what is it, what is it that they're needing so badly that we then have to kind of figure out another solution for? And I think that kind of taking that mindset of like, okay, there's something I haven't learned here yet. They're not, they're not the problem. The software might not be the problem, but

Robin (17:30.257)

There's some need that needs to be filled. And that really had to be kind of our ethos as we went through and really kind of called our list of software. And it got a lot better. And then I think ultimately we as an ops team had to like lower our expectation that it was never gonna be a perfect list. We were already starting kind of from this large one. How could we get it to a dull roar of things that we could manage and what was gonna be managed by the.

you know, operations team, and then what was going to be like, cool, you can have this as long as it fits our security guidelines. And making that distinction helped us not kind of pull our hair out and also make sure we weren't, you know, upsetting every single other person and having them lose total trust in the operation, you know, big bad operations team.

Ken Babcock (18:16.226)

Big bad operations team. I love that. Yeah, that's good. Yeah. The BBOT. Um, we also talked about a paradigm shift that you saw, and it feels like this was probably the time when that happened. When you were, when you were pushing on software or you're saying, what is this solving and, you know, I loved the way you describe that paradigm shift, which is, you know, telling teams, Hey, the core value.

Robin (18:17.693)

I know. I kind of like the ring to that actually. Yeah.

Yeah, exactly.

Ken Babcock (18:44.542)

of this team is not your ability to navigate software. Can you expand on that a little bit?

Robin (18:51.594)

Yeah. Yeah, absolutely. I mean, I think so often tools became the things we would hide behind. They'd be the things we'd hide behind for designing a solution. They're like, oh yeah, there's so many point solutions out there today of like, this is the thing that solves this one very specific niche problem. And to be able to take a step back and figure out what is it that we're actually trying to do, I'll pick on Donut for a little bit. So donut.com. Great.

very cute tool for connection between teams. But if that's going to be your solution for how to cultivate team development or team connection, it should not be the starting point. And I think that's the place. That's a very small example, and I think Donut's great, and we've had a lot of success from it. But to take a step back again and look at what is it that we're trying to do, and how does our software enable that?

Ken Babcock (19:35.691)

Mm-hmm.

Robin (19:48.853)

versus be the leading solution. And that's really what kind of, I think, got opened up for us when we started this exercise, was an operations team is not here just to kind of do the behind the scenes implementation of tools. It is really how are we functioning as an organization? And sometimes that answer is gonna be a software system. Sometimes that's gonna be a process. And sometimes that's just gonna be a behavior that we all kind of like get into our cultural fabric.

I think being able to know that difference is really key.

Ken Babcock (20:21.262)

Yeah. And you start to become beholden to the capabilities of the tool. You set a ceiling on yourself. I remember when I was at Uber, for some reason it didn't make any sense, but I had to sit next to one of the original team members from Netscape. Sort of this like Silicon Valley legend. We were not on the same team, but for some reason I'm sitting next to him. And when I was leaving Uber, he said, his advice to me for entrepreneurship was like,

Robin (20:41.336)

Yeah.

Ken Babcock (20:50.434)

Take the thing that you did at Uber that wasn't productized, that was as clunky as possible, uh, that people were really frustrated by. You probably didn't even feel like you did a good job at it and turn that into a solution. Like find the thing that you had to figure out the hard way and make it really good for Uber and turn that into a company. Um, and I'll, I'll never forget that because, because oftentimes when you find a tool for that niche.

thing that you're trying to execute against. You're just like, all right, well, the tool is supposed to do it. I'm not going to really think outside the box. I'm not going to think about a better way to do this. Um, so I love, I love kind of the way that you, you characterize that, um, with, you know, sort of these deep, deeper rooted issues, I imagine you, you've received some pushback. You had some people that were, you know, more tenured members of the team. Like you said, maybe the two people that love that one tool. Um,

Robin (21:43.471)

Yeah.

Ken Babcock (21:45.03)

How did you get that buy-in, especially being someone new who's sort of parachuting in and saying, we're using too many tools, we need to document more. You're creating all these behavior change, but how did you get people behind it?

Robin (21:51.237)

Yeah.

Robin (21:58.465)

Yeah, good question. There's a book that I love and refer to a lot. It's called, I think it's called Simple Habits for Complex Times. And it's one that I would refer to a lot because I would often think, one of the first things they'd always say was, yeah, if you're seeing people as a problem, you're looking at it the wrong way. That if people are giving you any pushback, there's more for you to learn.

from whatever perspective they have. And I really tried to take that as our ethos and instill that in the operations team because I think an operations team has put their heart and soul into rolling out a process and as soon as somebody else comes in and gives feedback, it feels like that's gonna feed, like that is our equivalent to the product. Like our product that we're delivering is this process. And it's so human nature to just get a little bit defensive of like, this is like a personal affront.

But if you can switch it to being like, great, what is it that they're either needing or that they either don't understand or that I don't understand, that they're up in arms about for this specific thing? And I think that really helped of like, just trying to lead with curiosity over what is so important in this moment that I may have missed in my calculation for the change that I wanna implement. Because I don't know everything.

And then there are some times where, and this is the part where I often, I think would, my feedback to myself would be like, would hear so many perspectives that maybe we would adjust too much. And there were times where you really have to go like, great, I've heard you, thank you so much. Like keep telling me all of your feelings about that. And then we're still going in this direction. And discerning between when you're gonna adjust the direction and when you're gonna hear it out, but continue the course is I think a judgment call and probably really depends on an organization.

But I think that's part of these leadership roles is figuring out those two. And I will say, I think what I found is that once people could vocalize what was so important to them, often they could come around and even offer ways in which you could get other people on board. And I think there's something around that kind of almost like magic of being heard, that you can then kind of turn yourself into more of a champion or at least somebody who can help.

Robin (24:23.989)

roll things out and I think this is a place where we would often get kind of creative like, okay great, now you're going to be one of the people that helps us, you know, bring this to that entire team. Identifying people in an organization who have that kind of trusted ear of everyone else was really key for us to roll out pretty tricky or new concepts.

Ken Babcock (24:44.382)

Yeah, absolutely. Um, and, and how would you, how would you describe the impact? You know, you got the buy-in, you started doing a lot of this, this implementing a lot of these changes. Um, what was the end result?

Robin (24:58.201)

Yeah, I think, you know, I think the end result was two things. I think once people were clear, it took a little bit of time for people to get clear on what the new process was. And I think there was always a little bit of grumbling of like, ah, what is that process? I got to go like look it up. We kept everything in notion. Got to go look it up there. But once people got the hang of it and it was no longer new, it just, that became the new habit. And suddenly it was sort of like, great. It's just like every other habit.

like brushing your teeth in the morning, type of thing. Like you just knew that's where you went for, to identify that process or to submit your expense reports, whatever it was. And then it freed up time to actually do the real work. And I think that's the piece that like really good operations can enable is it's less about kind of having it like somebody following it just to a T or having the perfect thing. It's once it's kind of ingrained in a culture, it can, it runs in the background.

And I think that became one of our telltale signs if we've outgrown a process, or if we put in something that was too structured, because that was often, that was kind of our learning curve, was like, oh no, we did something that was like, way too mature for where we're at. Roll it back, roll it back. And it was often.

about how much could it run in the background once people learned it. Like, yes, there was a learning curve, but if you get through the learning curve, if it could start to enable and free up more space, both for the operations team and for the teams that we were supporting, that's when you kind of knew you'd maybe hit the sweet spot, at least for that stage.

Ken Babcock (26:30.498)

Yeah, I think running in the background is a, is a great way to describe, you know, when, when you're really thriving, like, what does it feel like running in the background is probably an element of it. I think another element is probably like, how do you meet people in your moment of need, how do you make sure that like, it's as close to that end user as possible? Um, so can you talk about that a little bit? And, you know, this concept of like real time enablement, like how do you, how do you get people on stuck?

Robin (26:50.819)

Yeah, totally.

Robin (27:01.133)

Yeah, great question. That one is, I think, one that we always, I don't know if we ever totally figured it out, but I will share some of the kind of ways we kind of got closer, and I think this is a place, like, I'm super excited by what Tango is doing too in this space. We often would find that, yeah, there's a really fine line between too much ops and not enough ops.

And like that balancing act is hard to strike. I remember, I wish I could remember who told me this cause I'd love to give him credit, but it was like, if you're a little bit behind where an organization is developmentally for the ops team, that's a better place to be than like five steps ahead. And I think operations people are often trying to be five steps ahead, but if you're a little bit behind, it feels it's, you know, you're not creating an organizational drag cause you've put something in that's too process heavy.

And I think that's important for getting to this kind of like enablement piece, because I think, I think there's a couple of different philosophies, probably on enablement. One of my hot takes would be if it's a system that is pretty intuitive and you still need enablement, there's something that's broken in that system. Either you've developed too complicated of a system or it's maybe not the right system or process yet.

And I think that became our big kind of learning was that if we were spending more hours kind of training on a process or a system or a tool, then we were actually doing the end results that we wanted, something was misaligned. We had that for a little bit with our performance management process, which is a complicated process. But I think when I look back at like where we may have misstepped or where I think I led the team astray and would have course corrected now,

What are we trying to achieve by having performance management? Just because every team does performance management doesn't mean that they have their clear goals set out. If we had been really clear about our goals, I think we would have created a much simpler system that didn't take hours to train managers on and then hours to frustrate individual contributors on, being like, what am I working on right now? I want to get back to work and you're having me answer all these questions. And I think if we had stepped back...

Robin (29:25.021)

the enablement would have eased, like we would not have had to do as much enablement. And I think that would have been my telltale, like that would have been the signal next time for myself of like, if we are doing this much enablement for something that should be more intuitive, like that's a like timeout moment.

Ken Babcock (29:43.254)

Yeah. And you, you had mentioned too, and we were preparing kind of this idea of like over engineered process. We, we hinted at it a few times. You know, I think what you've, what you've talked about so far, you know, you, you've mentioned a few signals for people to look for, to understand, you know, when some things might be out of whack, but these are hard, these are like really. Intangible. You've got to be listening. It's not necessarily going to come through in the metrics. Maybe it is correct me if I'm wrong, but, um,

Can you talk to me about some of those signals for over-engineered process? How do you, how do you know it's over-engineered?

Robin (30:19.933)

Yeah, good question. There's part of me that's, I don't think it comes through in the metrics to your point. Maybe sometimes you can see it in some type of like ENPS score of like where employee, but I think if it's coming through there, you're already way too late. Like you have to be, cause like that is such a, you know, secondary metric for you to be looking at. I think for me, it came down to two things to be looking for.

I think it's so important for operations leaders to have a pulse on the organization, like boots on the ground, what are individual employees feeling? And that came of like continuously observing like what's happening now and asking more curious questions. Like I never want to be the one that thinks they know the answer at all times. And I think that's, it's a hard place to be, right? Like you're a leader, you're supposed to like come with the answers, but instead to be like, no, what is most needed? Like,

That would be a question I would often ask in scanning a room, and it's hard. When you're fully remote, you don't hear that same thing that you might hear in an office where you can kind of just overhear people's conversations. But what is most needed, I think, is one of the most critical questions to ask. And then I think the second question that I would often ask and ask of the team is what's the lightest touch solution that could work here? Because I think our tendency is to want to tighten control, especially when things start to feel

a little chaotic or out of hand. But I think that's the moment where it's like, great, we gotta put in some guardrails, but how do we loosen our actual physical control in something and what's the lightest touch solution for it? And I think those would be the two things that if I were to extract how you try to meet that need, it'd be somewhere within that realm. But I think it's.

There's part of me that's like, I think it's just like instinct and trial by error and being willing to be wrong. Cause you're going to mess it up sometimes. And sometimes that's what we had to do of like, okay, sorry, we got that one. Totally wrong. Let's start again. Um, keep bringing your feedback cause we can, we can get better.

Ken Babcock (32:26.474)

Yeah. And, uh, you also talked to you a little bit about pseudo enablements, which can, which can come about, you know, with these, with these over-engineered processes, can you just describe that term for the listeners?

Robin (32:39.837)

Yeah, I think it was, it's sort of, I mean, it's kind of a made up one to me, but I think it's this thing where it's, you know, if you have an over-engineered process and then you need enablement for it, like it's, you've, you've already, you're already way off track. And I think that should be the kind of like first signal of like the, instead, where are we looking at? We want light touch.

nudges to be able to have somebody understand a process or a system. And that's where we know we've hit the sweet spot of a system that is not over-engineered because you can have little light touch nudges or explanation points and that's very different than having something that is over-engineered and then you need this entire kind of enablement structure to handle it. I think that's what we were talking about.

Ken Babcock (33:30.67)

Yeah, I think it's like we often aren't aware of how much complexity we introduce for the sake of complexity, because it feels smarter or it feels more novel. I don't know what it is, but it's easy to fall in that trap.

Robin (33:36.317)

Totally, yes. For the sake of complexity, yeah.

Robin (33:47.605)

Yeah, I think it's what you just said of like, it feels like to do our job, it should be like a more complex thing. I also think sometimes, I've noticed for myself, I'm curious for you, of like, when I am doing something for the first time, I often have over complicated it and come up with like some complex thing. And it's like taking a step back and like re-returning to it, where I'm like, oh my god, we can like take out like five steps of this.

So I sometimes think like, and I've kind of noticed that on the team of like, if it was their first time ever implementing something, it was like, they didn't want to, they didn't want to mess anything up. They wanted to make sure like all bases were covered. So became like overly complex to cover all possible solutions or possible outcomes. Whereas when you get more comfortable with whatever it is you're doing, and you've kind of seen, seen the movie play a million times, you can, you can kind of loosen up.

Ken Babcock (34:42.146)

Yeah, absolutely. I actually, we make a lot of mapping and navigation analogies at tango. So anyone who's listening to us from the tango team is like, Oh my God, here he goes again to the GPS. But I think what you described is that moment where you trust enough where you're going, that you can turn off like the voice on Google maps. You're like, okay, I don't need every turn, but I'm like, I'm getting there. I know where B is. I know where C is. I'm trying to get to see.

Robin (34:43.767)

and simplify.

Robin (35:04.43)

Yes.

Ken Babcock (35:11.423)

I'm gonna, I'll figure it out.

Robin (35:14.789)

That is an awesome analogy for it, I think. Cause I do think it comes down to this thing of like, yeah, when you're going for the first time, you may need every single instruction and you don't want to miss any of them. But the more you can just give kind of the next, the next, I don't know, I want to now go to like a, this is, my team would also say this, you constantly are changing metaphors. So now I'm on like a hiking trail.

And it's like one care and a head, right? Like where it's like, you give them enough to be able to kind of see the next pathway, but there's enough space for people to do their own, their own thing within it. I think is a really key hard balance, but really important when you're to not over engineer something for a team.

Ken Babcock (35:58.422)

Yeah. Well, there you go. Tango team, you're Robin has just validated that metaphor. I'm going to keep using it. Um, but, uh, no, I think like within those bounds, that's where like the creativity happens and I think a lot of what we've talked about today is like, give people just enough, like don't give them too much that they're just beholden to everything that's been created or whether that's the process, the software, but like give people these milestones and these endpoints so that they can be creative in between.

Robin (36:05.693)

I'm so sorry team.

Robin (36:28.213)

Yeah, I mean, I think like, look, that's like why we've hired these amazing people at various companies, right? Is like, not to micromanage into just do this very specific process, but here are the guardrails that and here's the direction we're headed. You help figure out the most creative next step within those pieces. And I think that's like, that's where you've hit the sweet spot and to your point. I mean, that's where I think the map analogy is. I think it's a good one. I'm gonna borrow that one.

Ken Babcock (36:58.612)

And also revisiting process, right? Like these things are so iterative and like, it's going to change with your business and you might borrow something from your time at Google or I might borrow something from my time at Uber. And you're like, okay, like those things actually worked for us, but maybe these like two other things didn't quite work. So let's, let's tailor it to our own company. And so I want to, I want to actually transition with that.

Something that we also talked about, sort of this ops and box idea or this idea that like, there are situations where you reinvent the wheel and there are situations where you probably shouldn't like, don't make that your differentiator. And so can you talk to us a little bit more about that? Um, and maybe how you see tango fitting into that world.

Robin (37:45.321)

Yeah, absolutely. This is one I've been thinking about a lot in kind of transitioning away from day-to-day operations where it felt like I was constantly dealing with kind of fire drills and you were, if it was a new process, it was just like great make the thing, like get it out there and not a ton of time to think through what is the most elegant or simplest solution. And I think that's the place where as you're describing, yeah when do you reinvent the wheel or take pieces?

Robin (38:17.849)

I think there are certain processes that if you can have the baseline or framework, and I think this is what Tango has such an opportunity to help provide, which is like, we're going to give you this, the skeleton, the raw basics for you to start with. And then you can start to improvise or add cool colors or like whatever it is that makes it your own unique culture.

But the bones and the foundation are going to be something that's established. And I found, we found kind of like from firsthand experience of like, when we had that, then it allowed us to have a lot more creativity and agency where it mattered versus on the pieces that were like, that's already been done at hundreds of extremely successful companies. Just borrow that. And I think, but it's sometimes hard, like where we, where we struggled.

with putting that together, and this is again, or I think tango and this kind of like ops in a box concept can really come into play is, if you can have written that down already as somebody who has seen and felt it and gone through it, it's way easier than me trying to describe to somebody, well, at Google, we did X, Y, and Z, and they've never been at Google, and they're like trying to furiously take down notes and.

Ken Babcock (39:29.111)

Yep.

Robin (39:32.261)

give me back this version of a process that they've never experienced. I think that's the place where we kind of miss the mark, where we try to recreate it, but it's like three steps removed. I think that's what is so exciting about tango, to be able to take all these best of, so that you really could then allow people to do the part that they know best, which is every person who would be using it knows their own culture the best. That's the part that they should be improvising on and creating more about.

versus the raw bones of the processor system.

Ken Babcock (40:06.55)

Totally agree. And we had, we had Kristen Kaiser Mulligan on who's a friend of mine from Uber. She eventually led ops at lime. And the way she characterized this was like at lime. We don't need like, we obviously have to do it well, but we're not trying to be best in class differentiated in how we repair scooters, like scooters, scooter. There's a, there's a safety threshold.

Robin (40:30.834)

Yes.

Ken Babcock (40:33.398)

You know, but we, but we do have to be best in class and we do have to be really thoughtful about like the throughput of that and like the queuing and where we put, um, operations hubs to like go and repair them and how they come in and how people handle orders. And so I think like making some of those distinctions where it's like, what do we need to be best in class at versus like, what's just, it's been done. We know how to do it. Let's just make sure we like follow that.

So I really love that point you made.

Robin (41:04.461)

Yeah, I love that. I think if you can differentiate between like, what is just best in class operations generally, and then what is best in class operations for your company. I think being able to distinguish between the both, both of those and have Tango help with the first one so that you have the time and space to do the second. I think that's, that's awesome.

Ken Babcock (41:27.398)

Cool. We're reaching the end of the podcast. I have one, I have one question left for you. And I feel like we've, we have maybe talked about some of these. Uh, hills as you'll see. Um, but what's one ops hill that you'll die on the spicier, the better.

Robin (41:43.881)

Okay, I mean, the first one that comes to mind is definitely around. I love documentation, but it's not super spicy. I think the other one would be when in doubt, do nothing, which is definitely spicier because I think so many people want to just over engineer everything. And I think if you're not sure what to do, don't do anything yet.

Ken Babcock (42:09.554)

Interesting. Okay. Wait, talks to me a little bit about that. Cause like, I actually come from a different viewpoint where the cost of indecision is sometimes higher than like making the wrong decision, right? Like, okay.

Robin (42:13.713)

I know.

Robin (42:23.217)

Okay. Yes. I, okay. Good. Great point. Here's what I mean by it. And maybe it's too, maybe I got to work on my tagline for it a little bit. I think often people see a problem and they immediately come up with the solution before they've done the real. Do diligence on understanding what the problem is that they've seen it before. Oh, I saw that at Google. I'm going to do this. Or I saw it at Uber, you know, at Dropbox, we did X, Y, and Z versus like, what is it that we're actually observing here?

and teasing out what are your opinions on something versus what are you actually observing on the ground. And until you have that clarified, I don't think you should be doing anything. But that said, I agree, if you sit in indecision too long where you then get nothing done, that's way too long. But I think maybe mine is like the asterisks of like, within the first, I don't know, week of a problem, don't do anything if you don't know, you know, don't know what to do yet.

Ken Babcock (43:20.682)

Yeah. That reminds me of something a friend of mine says, and I love it. We've like brought it into Tango, which is name the mess.

Robin (43:31.661)

Yeah, love that. I love that.

Ken Babcock (43:33.226)

Name the mess. Just what's the problem, what's the mess. Everyone removes their ego, their pride out of it. And then we can get down to actually solving it.

Robin (43:42.105)

Yeah, that's a really good one. Okay. That might be the, I want a t-shirt with that. We should make t-shirts. That one before that's, that's maybe the first sentence to my, yeah. Name the mess and until you can name the mess, do nothing. Cause I think you got to name that first. Yeah. That's good.

Ken Babcock (43:44.206)

I want a t-shirt with that. All right, we're gonna make t-shirts.

Ken Babcock (43:57.854)

I love it. Look at this. Look at this collaboration. Well, Robin, it has been so fun having you on. I think there's a ton of learnings for our audience who's, you know, predominantly operations folks who are trying to figure things out or in some situations maybe doing nothing, maybe sitting back and like understanding a problem. So thanks for spending your time with us today and yeah, stay in touch.

Robin (44:26.338)

Awesome, thank you. Thanks for having me.