Move beyond AI notetaking: Be the first to see the new features in Fellow 4.5

X
Guest

123

What's really important is that the people on the team know their priorities and know what matters. If someone comes out of the blue and says, ‘Hey, I need you to drop everything you're doing and do this.’ They should be in a position to say, ‘That seems odd, because I feel like as an organization, we're aligned around these priorities. And that feels like it's not lined up with that, can you give me a little more information'?

In this episode

How often do you ask your team what’s on their mind? Asking what matters to them can tell you a lot about the organization, and if everyone is working toward the same mission. 

If everyone has a different answer, then something may be off. 

In episode #123, Rob Zuber explains why having skip-level conversations is so powerful in ensuring there is team alignment and mutual understanding. 

Rob is a three-time founder and five-time CTO. Today, he is the CTO of CircleCI, a continuous integration and continuous delivery platform that can be used to implement DevOps practices. 

Rob goes on to explain his process with skip-level meetings, his role of being a CTO, and what failing gracefully means to him. 

Tune in to hear all about Rob’s leadership journey and the lessons learned along the way!


Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review and share the podcast with your colleagues.


04:11

Founders and management alignment

13:48

Phases of growing an engineering team

22:52

Specialized hiring

24:49

Structure of an engineering org 

26:11

Role of a CTO

30:09

Tactical ways to address strategy

33:27

Skip-level one-on-ones

39:59

Talent retention through scale

44:25

Failing gracefully


Resources


Transcript

Aydin Mirzaee (Fellow.app)  00:33

Rob, welcome to the show.

Rob Zuber (CircleCI)  04:13

Thanks for having me. I’m excited to be here.

Aydin Mirzaee (Fellow.app)  04:14

Yeah, it’s, you know, I’m very excited because obviously a huge fan of circle and the work that you guys do, but also you are also a podcast host for the confident commit podcast. Tell us about

Rob Zuber (CircleCI)  04:29

that. That’s correct. Yeah, you know, it’s a fun adventure. I’m sure you’ve experienced this it’s exciting to get a chance to talk to a lot of other leaders people in the industry here different ways I think, you know, people think about things and approaches they take i feel like i i go back and listen to the episodes not because I want to hear myself but rather because I know I didn’t even get all the content. So I’m just constantly learning from other people gives me a great vehicle to do that. We focus primarily on software delivery unsurprisingly, as CircleCI but you know, soft We’re delivery is a lot bigger than just the tools that you have at your disposal, right? It’s how do we think about things? How do we think about experimentation? How do we work effectively together as teams, I mean, it’s such a broad space. And it’s tons of stuff that I just love to talk about.

Aydin Mirzaee (Fellow.app)  05:13

You know, for me talking to another podcast host, this is gonna be a fun conversation. I know. Let’s talk about circle, just to give some background here, you have founded a bunch of companies, you’re no stranger to startup life. You’ve been at circle for a while. And now circle has grown to roughly order of magnitude, how many people work there,

Rob Zuber (CircleCI)  05:36

you’re about 650. Okay,

Aydin Mirzaee (Fellow.app)  05:37

so pretty big number. You’re the CTO there today. Let’s start at the beginning. Before we talk about all the fun CTO stuff that you do and all the things you’ve learned. Let’s start with the beginning, when you first started to manage or lead a team, do you remember some of those early mistakes, some cringe worthy ones that we can tell everybody about today?

Rob Zuber (CircleCI)  05:57

Yeah, I think as human beings, we’re really good at remembering the cringe worthy moments, and they’re innumerable. So I got into tech startups, sort of a year out of college, I’ve been working in a manufacturing facility, totally other story, we can talk about another time. But some friends started a company in Toronto, we were just talking about about Canada, so and I joined them. And I didn’t have a background in CS or anything. They just, you know, they needed people, people they knew and trusted. And so I joined and, and started doing effectively QA work. And soon after was building and running a QA team. We called it quality engineering, because it felt better. But whatever I mean, was the late 90s. So it was very, you know, waterfall, we, we had that really exciting job of trying to scramble at the last minute to make up all the time that had been lost in the schedule, and to get things out on time. And so as I built that team, I mean, I would say at a high level, the things that I really struggled with, were helping people understand why we were doing anything like it really just I had a sense of what we had to do. And just I mean, it was like a giving orders, you know, you go do this, you go do this, and then had to be back in five minutes to make sure that that had gotten done, and that someone was, as opposed to helping people understand goals, what we were trying to achieve, etc. But I think we also talked about being really concrete, like one of the moments that I really remember, and it stuck with me, my whole career was this moment, this is over 20 years ago, 25, whatever details are lacking, but really, like getting really, really frustrated. When someone else asked someone on my team to do something, you know, I had this very, like, I need to be in control of what everybody does sort of thing. And like, I mean, that doesn’t scale at all, certainly, as I’ve learned over the years, but like, immediately reflecting on that. I was already like, that’s not who I want to show up as at work, right? Because being frustrated in general. And second, clearly this other person who was an executive or a founder of that company, or whatever, like they have objectives that they’re trying to meet that are probably in the best interest of the company, like, what am I so worried about? And that sort of like, I think a lot of people go through this in early management days, even in early IC days, like I need to demonstrate my value. And I need to control that and make sure that everyone sees it and have like a good message around it and all this sort of thing. And I think, luckily, that was a pretty early place where I just it was honestly, it was disappointment in myself, right? Like, again, very old. So maybe I wasn’t actually yelling at this person. But I was like, why am I so upset about this like? And I think that was a very early shift in the way that I thought like, how do I participate in the organization and be helpful to our overall goals instead of trying to worry about what is my piece? And how do I own it and demonstrate my value sort of thing. So I would say that was an early one that, you know, I just don’t yell at founders just have a normal conversation. But second of all, when you do when you totally blow up and lose your cool at least like take a moment to go, wow, what was it that got me into that spot? And like, how should I be thinking about this?

Aydin Mirzaee (Fellow.app)  09:05

This is a very interesting one. And I feel like it potentially goes deeper, right? Because on the one hand, sure, you know, people can talk to people on your team, and maybe, you know, ask them for things. But I think like sometimes in organizations, you also have this situation where say someone maybe skips you and goes to your team and tries to get things done that way. So it is kind of a I guess it does bring up questions like that. So how do you think about that? I mean, was it that they were trying to, like, go to people directly and kind of like skip a level there or was something else happening?

Rob Zuber (CircleCI)  09:46

I mean, honestly, I’ve tried to be concrete, but at the same time, it’s so fuzzy and so long ago, but I think like it was 100% in good faith, like we have a thing that’s important. I mean, in a small startup where you don’t even know what you’re Businesses and weather, you know, whatever, like, there’s just so much happening so quickly. And introducing really strong layers of hierarchy and difficult communication patterns doesn’t help, right? It everyone’s under pressure. You know, this is a time when probably our founders were like, paying payroll off their credit cards, because we didn’t, you know, like, everyone’s under a great amount of duress and showing up and being like, No, we’re gonna sit down, and we’re gonna have like, really concrete like, process or whatever, it just, it’s not the right time for that. I think what’s important, like, as I reflect on that, and sort of larger scale organizations, and whatever, to me, what’s really important is that the people on the team, know their priorities, know what matters. And if someone comes out of the blue and says, Hey, I need you to drop everything you’re doing and do this, they should be in a position to say, that seems odd. Because I feel like as an organization, we’re aligned around these priorities. And that feels like it’s not lined up with that, can you give me a little more information? Or maybe we should? I mean, if I was the manager in that situation, like, we should probably just check with Rob and let him know, let’s just figure it out. And if there’s a change in priorities, we can have a real conversation about okay, how do we adapt to that? Like, should this one person run off and do this thing? Or do we need to understand better what that is? Like? Really, you know, the key point being that the members of the team, again to the other part of that, knowing why they’re doing what they’re doing, even being able to say, oh, okay, I see what you’re asking for, and the impact on the organization, if we shift our attention, there will be this, are we comfortable with that, because the thing that does happen in these kind of like flyby scenarios, if you want to take the least generous view of it, is now as a team, we feel like we have to deliver what the founder just asked us for, because there’s this massive sort of power gap or whatever. And we feel like we have to deliver what our manager asked us for, right? This is like, is it all, you know, the buck stops at the IC and kind of inverse sense that the work still has to happen? And they don’t necessarily feel in a place to say, I totally hear where you’re coming from? Are we cool with like, delaying this other thing? That was our priority? As we understood it previously? Yes. Here’s the business context, that’s changed. I’m totally comfortable with that. Let’s go do it. Awesome, right. But if it’s the, you know, what I was describing as the other part of my lesson, like, I’m not telling anyone why we’re doing anything, they don’t know that I’ve just said, Do this, do this do this kind of thing. You know, again, my early days, then they don’t have the context to know, oh, we can actually, this is the impact it will have, we can have a discussion about trade offs, like really building people up to be able to have those conversations, I think,

Aydin Mirzaee (Fellow.app)  12:33

yeah, I think now that comes full circle for me. So I definitely understand you’re hiring these incredibly smart people. And if all they see are disjointed tasks and projects, and they don’t necessarily holistically understand the mission, and what’s happening and what the broader outcome is, maybe that’s okay. But it’s going to put them at a not a great place to be able to make those sorts of prioritization decisions. And, and if they’re not making it, it just means you’re gonna have to be micromanaging. And nobody likes that. And so, yes, spending time on making sure that they understand that context, I can see how would add a lot of value there.

Rob Zuber (CircleCI)  13:15

Yeah, that’s exactly right. I think that’s, I mean, one, as you go through your career, like you learn lessons, you also end up managing more senior people under you who themselves are even more capable of taking, you know, fairly nebulous context or, or high level perspectives, and making great decisions about what to do. So it’s, you know, I guess on one hand, it’s nice to be able to work your way up through that. But it becomes even more important, you know, as you get to higher levels in an organization.

Aydin Mirzaee (Fellow.app)  13:47

Let’s talk about that moving up higher levels in the organization, you’ve had the unique opportunity to see circle as it’s grown. So you’ve played the role of, you know, CTO and chief technical person effectively at the company, when it was very startup oriented, and it was less process oriented, and now to where you are today, in your view, if you were to kind of break this down, like do you see the startup as different stages, you know, say when we were under 30 people, and then maybe 30 to 200? Like how would you break down the different phases? In your opinion?

Rob Zuber (CircleCI)  14:24

Yeah. So for context, it was about 14, I think, when I joined, and there were three of us that came in together through an acquisition, so but whatever I mean, it’s that three is large in the context of 14, not larger than the 650 that we have now. And yes, absolutely. There are phases. They’re kind of different in every organization, but some key things that happen like within engineering, you start out as one team, right? You’ve got even just a couple people who understand the entire system, right can work on anything. Have, you know the knowledge of how everything works? So if something goes wrong, you know, anybody can fix it sort of thing. And work coordination is extremely lightweight. For the three of us that were acquired. I always joke that we, you know, there were basically two engineers and one not working on code. And, you know, it was like a Slack message in the morning, Hey, what are you going to do today? I’m thinking about doing this. Okay, cool. I’ll go work on this done, we just coordinated Right? Like, why would we have a JIRA board or whatever, like, I can hold that in my head. And so, you know, one big transition point is we feels too big to be a single team. And what’s right, you know, I would kind of hold on to that single team vibe, as long as you can, maybe you need a light, you know, like a Trello, or a pivotal tracker, something like something simple, where everyone can see what’s happening, because I can’t remember what everyone’s working on. I’d say there’s a lot of Dunbar influence in there. Like everyone talks about 150, as this really important, Dunbar number buddy, you actually describe different levels, where you go from sort of, you’re really close personal relationships to like, up to I can remember be this number of people’s names. And so there’s like, like, trust is a big part in there, right? You know, in that two person scenario, it’s like, I totally trust you to just go do the thing. We’ve been working together nonstop for years. And that might work up to like eight people, you know, kind of the size of a standard team, you could push the boundary because you’re trying to keep it as one team. But at the point that you go from one to two teams, a lot of stuff changes. Right now I have this coordination across teams that just didn’t exist before. And so I think some of our tougher times in like in the growth of the engineering organization at CircleCI, were when it felt like we needed to be team oriented, but we didn’t have enough people to kind of staff really sensible teams. And so we were constantly moving people to oh, wait, no, that’s not quite right, like, move some people over into this team. And maybe if we rename this one, and whatever, I feel like, I’m not really an expert in that murky middle, because I don’t know how much of it we got, right? Like we stumbled through a lot of it, and then got to a point where we could say, oh, like, I guess another point in that growth for us, which is probably skipping a couple stages was a call it divisions. But at the point that we said, we’ll have a platform team, and a product oriented engineering team, right, like these people focus on and we see this and lots of our customers, because it’s kind of who we talk to, these people are focused on the ability of other engineers to do their work effectively, you know, my job in a platform organization is to, you know, build CI and CD or deploy CI NCD to build security tooling and basic shared pieces that folks can use. So they can go do their job, their own job, which is to work or to focus on the customer, right, like our end customer of CircleCI, what are they trying to do? I’m building the use cases for them, that engineers is supporting the use cases for me like I the internal engineering the customer, and that’s a really big transition point in organizations,

Aydin Mirzaee (Fellow.app)  17:51

roughly how big your engineering org was, when you started to have a platform team?

Rob Zuber (CircleCI)  17:58

I don’t, I’m gonna call it 100. Ish. I think you could do it earlier. I think the roll like the hat, if you want to call it that exists much earlier. Right? If you have two people, somebody’s thinking, hey, wait, let’s just make sure that as we make changes, you know, they don’t know you don’t break my stuff. Right? Like, so people think about doing that work, but they do it in, you know, at first kind of in shifts like, Oh, this is getting really frustrating. Our bills not working very well, whatever. Let me just go spend a day fixing that. It’s not like I’m the platform person at that point. I just like, this week, I was the one who decided to make this little tweak or whatever. So it gets pulled out and solidified. I’d say at that scale. 100 ish. But you could do it at 50. You could do it at 200. I mean, it depends on your organization, and how people behave and what kind of product you’re building all that stuff. But yeah, I think we’re in that we’re I mean, every one of these boundaries, much like shifting from one team to two teams, as you add larger divisions in the organization, right, basically saying, Okay, now we have a director of platform and a Director of Product Engineering, or whatever VP is like, however, you want to think about that. The higher up that division goes, the more overhead you get in that collaboration. And sometimes that’s great, right? I’m a big fan of Team topologies. And the kind of grammar I guess, that they’ve applied to this. So if you think about platform teams is defined in that model. Right? Low collaboration is the goal, because the interface of the platform is very clear to me, right? I just take these things, and they work for me, I don’t need to go every project doesn’t involve me working with a team. But in the early days, as you don’t really have a built out platform, you just have a concept that you’d love to have one, you actually want a lot of collaboration, because the customer who is the product engineer, if we can call them at the person working on you know, again, the use case for the end user needs stuff now. And the platform team can’t be saying well, we just we have our own priorities. We’re gonna go work on that stuff, right like you want them to be served. As the customer, you have to really orient around that lower kind of overhead of coordination. So I gotta you know, there’s lots of ways that that can play out. But I think that is the big transition, which is the, we need to make our engineers more effective. And part of that will be dedicating people’s time to that task, not just making it a cultural thing, right, like early, it’s like, we value productivity. Therefore, let’s have a CI CD pipeline, you know, let’s build automated tests as part of building software. Like that’s cultural more than its team, honestly, like if you have a team building your automated tests, whatever different story, but at some point, you say, Wow, this is so big, and is its own unique problem space. And therefore, we’re going to carve out a team of specific people who that is their strength. And certainly one of the transitions through all of that growth. You know, when you go from engineers that joined a 10 person startup to being in a 250 person engineering team, which is about where we are now is, you specialize when you’re one of 10 people, you know, every piece of every corner of the system, and you can work on whatever you want, you wake up this morning, and you feel like being a UI engineer, like that’s what you do today.

Aydin Mirzaee (Fellow.app)  21:11

Hey, everyone, just a quick note, before we go back into the interview, if you’re listening to this podcast, you’re probably always looking for ways to get better at the art of managing teams. And that involves managing a team budget, given the current economic times, it’s really important for managers to understand financial forecasting, and how it impacts their organization. And also, I think it’s just in general, very good for everybody to have a good sense of what a balance sheet is, what a profit and loss statement looks like what a cash flow statement is, and really get down into the financials and how it impacts your teams, and how to get really, really good at forecasting. So the good news is our friends at morning brew one of my favorite newsletters, they’re running a course, it’s called financial forecasting. And it’s a carefully curated set of lessons, it provides leaders the essential tools on turning mushy strategy stuff into quantifiable metrics, to basically go from a blank spreadsheet to projected performance and define what financial success actually means for your team, your division, or your business. And the best part is all Supermanagers podcast listeners get $50 off, when you register through the URL. Now, we’ll leave the URL in the show notes as well. But it’s education, dot morning, brew.com/fellow, you heard that right, just go to education, dot morning brew.com/fellow to get $50 off your course membership. And with that said, let’s go back to the interview. And you also like from a hiring perspective, you try and hire generalists as well, right? When you’re 10 people,

Rob Zuber (CircleCI)  22:59

exactly, probably on the senior end, because they’re going to face a whole bunch of unknown things. And they’re going to have to have a toolkit that allows them to adapt. But you know, all senior engineers just doesn’t really work at 250 people and beyond, right? There’s many, like, how do I grow in this organization, when everyone else has the same skill sets that I have kind of thing? Like, where do I fit in and become a leader and all that? And yeah, so as you get into larger organizations, you’re like, Okay, I need to own a piece, not the whole thing. Otherwise, like, we can’t all be just all over everything. Right. And that’s true of engineers. It’s true of executives, you know, like, there was a time when the executive team was comprised of me and the CEO. That is not the case anymore, right? Like, there’s huge things that I don’t participate in at all that I used to spend a lot of time on, which is great. I mean, it’s nice to be able to bring in really experienced skilled people in particular areas. But I think it’s a that’s more of an evolution than a particular phase. But it’s something that you when you hire someone to run sales, that’s a really big transition in a startup, right? Where’s this? Like? We’re, obviously developer tools, developers selling to developers, right? Sounds great at the beginning. But it turns out that you, we don’t have the skills to go negotiate contracts and work with procurement teams, and whatever, like there’s real real capability there, right? And we don’t necessarily understand every customer. So now we have product management, like all of these things get layered on and each one changes the way the company functions. But ideally, for the better, right as as you’re growing through that. You could say, Okay, what do we want marketing to be here at this organization? Like, what’s the right approach to marketing for who we are? What’s the right approach to sales for who we are, and then we go find a leader who shares that vision, and then get out of their way help them understand our space, but let them build.

Aydin Mirzaee (Fellow.app)  24:48

Yeah, so I guess one super small question, which is the dessert product or roll up into USPTO? Or is that a separate

Rob Zuber (CircleCI)  24:56

or for clarity? Almost no one rolls up into me He anymore, I built the engineering organization to about 250. And then I hired an SVP of engineering. So speaking of specializing, I stepped out of managing at 250. Because there’s enough for me to do to not run an engineering team, our product organization has always rolled up independently. And you know, I’m smirking, which I guess people can’t see, because it’s one of the like, classic, and evergreen questions of tech companies. And it totally works. Either way, it just works differently. And myself, and Jim, who’s our CEO, and we were cofounders of a previous company. Jim is a product person by background. And I think of myself as a technology person by background, I love product, I love thinking about customers, I love all of those things. But because we have such a great relationship, I also love having a partner to think about these really complex problems of how do we take engineering investment and use it to deliver great value to our customers. And I wouldn’t necessarily want to just own that on my own. Like, I love having a partner in that. And so that’s how we’ve always thought about it in our organization.

Aydin Mirzaee (Fellow.app)  26:10

That makes sense. So I have to ask you, then this is an interesting topic. So starting with the role of the CTO, maybe you can kind of describe in your own words, sounds like there were two phases. I mean, there’s many phases, but I’m going to break it up into two, either the phase before you brought on the SVP of engineering, and now that you’ve brought someone on, so prior to bringing one on, how would you have described your day to day or role as like you would say that the objectives and and the things that you cared about and your priorities as a CTO? How would you describe those?

Rob Zuber (CircleCI)  26:45

Yeah, I mean, that transition is pretty abrupt. Right? So when you are running an organization, regardless of when I joined, and I had maybe 10, out of the 14, or something like that through to last year, when I first joined, I was just writing code, but soon after I was managing the engineering organization. And so your objectives are around effective delivery. Right? Do we have a process? Do we have the capabilities to get things done? Do we have the right technology underlying that to support us? And do I have the people right? Am I bringing in the right people in those early days, you’re kind of realizing you were talking about senior folks like I’m relying on them coming to the table with the skills I need. Later, I’m thinking about building bench growing people like do I have the processes internally to help people develop in their own careers to get from where they are to a have their own development in a way that makes them want to be here because they feel that they enjoy that and be become greater and greater contributors to the organization? Right, like, modeling out over multiple years? How do people arrive here? How do they leave here? How do they contribute along the way? How do we build them? All of that stuff? Is stuff that you think about when you run an organization like that? And how do we coordinate with product? How do we make sure we’re focused on the right things? You know, all of that is probably front and center, like that’s the top and then shifting out of that. For me, personally, I kind of split my work between two, I’ll call them two buckets. Again, there’s many but well, like for simplicity. One is really strategic. Right? We’re a company building tools for software engineers. So as a person who’s been in the software engineering industry for 25 years, like, what can I read from signal out there about what people are doing and how they’re thinking about it, that allows us to understand how we evolve as an organization to continue to deliver great products that allow them to do what they need to do in what is a very rapidly changing space, like how we think about delivering software changes, hourly, this community just loves to do things differently today than they did them yesterday. So what of that is noise, and just people goofing off? And what of that is like a real signal that something matters, and is going to fundamentally change our industry? So how do we take all that and then think about the next many years? So it’s like, I always joke that my time horizons are 10 years and 10 minutes, like the other thing is what is totally on fire right now, that needs, I guess, executive perspective, right? Like one team doesn’t have the ability to solve this, but we can’t just drop it on one person’s plate. And they’re like, oh, yeah, I own this, like the big cross cutting problems, where, you know, my understanding of the organization of what we build, have every I mean, across all departments, not just engineering allows me to navigate those problems quickly and say, a yes, this is really important to the business or b It’s not let’s stop stressing about it. And if it’s the former, here’s what we need to do to get ourselves back on track. So it’s like a weird combination of really far out and sort of helping with those really immediate problems that are, you know, tough to put in just a single bucket if that makes sense.

Aydin Mirzaee (Fellow.app)  29:59

Guys but I really liked the way you put that, which is, you know, my time horizons are either 10 minutes or 10 years, I can definitely relate and identify with that. How do you make time for the strategic stuff, especially like prior to bringing on the SVP there? Was it hard for you to do that? Or were you able to make time? What did you tactically do to make sure it happened,

Rob Zuber (CircleCI)  30:23

I would say it was a big factor in choosing to go the SVP route was I was struggling, I had attempts and plans to carve out that time. And when you own a lot of the operational element, it’s hard to break away, I think people solve the problem differently, right, with different structures underneath them, or whatever. But my ultimate goal there was to get completely out of the escalation path, right, like that SVP reports to our CEO. So it’s not like it goes through me anywhere. It’s just, it’s not me, I can now truly defend a huge amount of my time. I’m a big fan of this book, which all business books could have been a blog post, but it’s called The One Thing, and one of the models that they like, it’s about prioritizing the most important thing. And at some point, when they talk through it, they express that you should be able to look at your calendar and say, 50% of your time, is being dedicated to that thing that you believe is the most important thing that you could work on. And you know, you say that to any executive, and they’re like, Yeah, right. But now I’m in the position where I can do that, right? Where I can say, this is the most important thing for the business. That is something that I am in a unique position to solve. Like, there’s lots of things that are important that shouldn’t go to me, but I can truly carve out time to go think about those things. And yes, like, what’s one of the transitions that I’ve gone through that’s been really hard is I put all of this energy into getting to this place where I have that kind of space on my calendar. And then when people ask if they can have 30 minutes of my time, I look at my calendar, I’m like, oh, yeah, I have tons of time, of course. And then I look back on it at the end of the week, and think,

Aydin Mirzaee (Fellow.app)  31:53

Oh, I didn’t even fill this calendar.

Rob Zuber (CircleCI)  31:55

What was I doing? Like, the whole point was, you know, very active in like putting blocks, not because people just put stuff on my calendar, but putting blocks to say this is the time that you carved out, like use it wisely. You know, where your list of stuff is, that’s really important, like just get to work on that stuff. And I think it’s hard to get your head around, again, in that growth, like both in the growth of the company and your growth as a manager. But realizing that somebody has to see the big picture. Very few people can because they’re in that operational firefighting day to day like, and then they come up for air and a years gone by, and many opportunities were missed. So acknowledging, like really, not just acknowledging to yourself, but having that conversation with folks and saying, Look, I’m carving out this time, because I’m taking this responsibility to see the big picture. And then, you know, communicating out, and therefore here’s some outcomes, here’s what we’re thinking about. This is the kind of direction change that we’re taking whatever, like, hey, everybody I’m covering at this time, but no one knows what you’re doing is also a problem.

Aydin Mirzaee (Fellow.app)  32:55

I really like this. And it’s so hard. It’s not a blanket solution that anybody can just go and apply. Because every person is different. Every organization is different. But in the past year, for example, I personally hired a Chief of Staff and I can basically relate to everything that you said it was firefighting operations, lots of things that needed to get done, but they were never urgent and important. They were just important. And if you want to spend more time in that important area, sometimes different structures like that can definitely help. But there is one thing that I know that you think is very important, and I’d love to get your take on it. We heard from one of your former direct reports, Maggie, who is director of engineering at circle, and she said that while she was reporting to you, she had never come across anyone that took one on one so seriously. And she really appreciated and enjoyed the one on ones that she had with you. So I wanted to ask you, what do you do with your one on ones? And why was Maggie so impressed with the way that you ran them?

Rob Zuber (CircleCI)  34:02

I mean, not to be pedantic, but I think it’s important for that. She worked for someone who worked for me. So it was the I remember, because she she said this to me at some point as well, like as a skip. She was surprised that I would that I would turn up but I was like, I was baffled, which is, you know, interesting. I think it just frames mentality. I think, you know, there’s two parts to that. Why do I show up? I don’t know, maybe lots of people like to joke that Canadians are nice, but it wasn’t that just being nice. Like, there’s so much value to gain from that conversation. And I think one of the things like we talked about growing, right, like, Sure, I’ve been in many startups and, and management teams, whatever. But this is a very large organization compared to most of the orgs that I’ve built in the past, etcetera. So you end up at this place where you’re trying to communicate effectively, and have that percolate down through an organization. And one of the best ways to test whether that’s working is to go talk to people who are multiple layers down and get the feedback of what they’re hearing and And it’s difficult many levels down because there’s, you know, power dynamics and trust issues and all the other stuff that comes up not because you’re not trustworthy, but people just don’t know you enough to be truly honest, right. But if you can build that relationship, if you want to build trust, like show up on time, and you know, be there for the calls, or whatever, right, number one, then you’re gonna get real feedback about what’s happening in the organization that’s a little bit outside of your view that’s typically presented, right. So as an executive, it’s often roll up, right? These people said, all these really interesting things that then got summarized by these people that they got summarized by these people, by the time it gets to you, it’s like, this is what others have decided, you think is important, right? And often framed in in a way that’s their bias, or, you know, maybe they’re trying to make it look a little different. Maybe they don’t see things the way that you do, you know, as many different reasons that it gets, we all play broken telephone as children, right? Like, what comes back to you is not necessarily what we said at the beginning. And so, you know, talking to people about a just like you asked about structure in those communities, it’s typically from another book, I start with the question, what’s on your mind, right? Like, what matters to you right now? is really the purpose of that question. And that tells you a lot, right? Just ask someone like, and what’s on their mind might have nothing to do with what’s on your mind. And that’s interesting, like, why is an organization are we not worried about the same thing, if we’re all worried about very, very different things, then something is off, right? Like, we’re not driving towards the same goal, or there’s details at your level, that are not percolating up to my level and keeping you from even creating the space to drive towards the goal that I’m talking about, right? Like, hey, we’re all gonna go do this thing. This is our mission and our vision. And you know, I keep saying you, but like, an engineering manager is like, that sounds fine. But like, I can’t even get my hires done. How am I supposed to pursue the goals of the company when I don’t have anybody on my team sort of thing? Or like, you know, these and you think, Oh, well, that must be infinitely solvable, right into, like, do I want all of that to escalate up to an exec? No, it’s not like, I’m gonna go solve all those problems. But I think the last thing I would say on that is, is I’m looking for patterns, right? If I go talk to three people in the organization, and they all raise the same issue that I’m not thinking about, then there’s a problem that I’m not paying attention to, that may have a more systematic solution, right? All those managers are, are off trying to solve the problem for themselves. When, you know, at a higher level, you could say, oh, actually, I’m seeing this problem across the organization. And my guess is, it’s this conversation that I had last week that landed poorly, right, when it was communicated out through the org, people didn’t hear the intent. They kind of projected something onto it, or whatever no fault of their own, like, context is hard. That’s something I can go fix. Yeah, cuz I’m gonna fix like the high level point.

Aydin Mirzaee (Fellow.app)  37:50

Do you ask the same questions just to you start with what’s on your mind? And then see where that goes. And sometimes if there’s like, recent things, maybe that you communicated, you might ask about those. And it’s almost like you’re playing detective? And once you do this enough, how much time do you again, very tactical here, but large company? How much time do you spend on skip levels? And, you know, what effort do you make? Do you decide at the beginning of the week, who you’re gonna meet with? Or do you have like a cadence that I’ll do X number per month?

Rob Zuber (CircleCI)  38:22

Great question. Again, this has shifted a little bit in recent history. For me, I tend to target those types of conversations more to our more senior engineers, like ICs. But you know, we’re like staff engineers, and that sort of thing. Now, with the same goals, I’m looking more for systemic technical problems, or process problems, more than management problems, I could easily say 30 minute meetings with those folks, once a month, or once a quarter or whatever, it’s not particularly helpful. I think that the thing that’s interesting that I do in that is I actually take the time with my EA, who not everyone listening to this gonna have an EA, but if they’re senior leaders, probably many of them do, where we walk through, like historical data from my calendar and say, Where’s the time going? Right? Hey, you currently spending 23% of your time on one on ones with, you know, in this category? Does that feel right? Is that what you want to be doing right now? Feels like it should maybe be 10%? Because that stuff is kind of, you know, on cruise control, and I need to dedicate more time to this project. Great. How would we adjust that? Okay, then we would say, Well, now it’s every two weeks, probably every four is fine, because this is more like a maintenance thing, right? And a little bit also just got, I’ve had a one on one with this person every week. And we’ve literally had nothing interesting to talk about. Okay, neither of us are getting great value out of that. Either. We should figure out something more useful and valuable to focus on or we can, you know, put that on a little bit of maintenance right now and target in another area. But I think that the thing that’s really worked well for me, is that reflective like, you know, data, we all love data. That’s a really interesting piece of data like where is my time going? Is it divided up according to what my priorities are?

Aydin Mirzaee (Fellow.app)  39:58

Got it. So one thing that I did want to ask you about just because you’ve experienced so much growth at Circle, which is the, you know, growing the people that you hire like the first 2030 people, you know, they’re different. We talked about how they’re more specialized. But one of the questions is, you know, how do you keep these people like all the early folks that have so much contacts and, you know, carry so much knowledge? And were there and saw those things? How do you keep them motivated and staying at the company over the long term? Have you discovered things that you’ve done that have worked?

Rob Zuber (CircleCI)  40:33

Yes, there’s no silver bullet, right? That’s gonna be the answer to every question. But at the same time, there’s also the question of whether that’s the right thing for everybody. Right? If I love early stage startups, and I helped this organization get through its first, you know, I’m going to pick four years, because I spent a lot of time thinking about vesting schedules and other random stuff like that. But like, I get us to a place, right, I get us to a place where now I’m just going to be the tech lead on a particular team. And I’m constantly frustrated, because so and so over there is working on the system that I built, and they’re not doing it right and whatever, like, I might just be in a place, it’s not going to be fun for me, regardless of how I approach it. So we have the whole spectrum, I would say we have people who’ve left long time ago, and we have people who’ve been here longer than I have, right? So a big part of it is honestly just a conversation, like, what motivates you what is happening, that would be interesting for you, how do you want to grow in your own career, like, I’ve been here eight years, so we have people in that sort of timeframe, that’s a long time. Like, if you’re gonna spend eight years at a company, you don’t want to just come out the other side saying, Yeah, I built that. Because you could have said that three years ago, after three or whatever, like, what are the things you want to personally develop? How do you want to set yourself up for the rest of your career after this, right? Because now I’m a firm believer that if you’re a big part, long tenure at a successful company like ours, you’ll have opportunity, right? But you’ll want to bring skills to that opportunity as well, you want to be like, I think a lot of early engineers end up being like directors, because they were just there early, not because they’re cut out to be directors, right? In the early days, they can dabble as a team leader and manager and say, You know what, I don’t like this work. I just like being really good at the technical stuff. Okay, awesome. Like, and we have now, you know, a we have legacy systems like everybody does, it’s been around as long as so that’s interesting. But you don’t want to end up being the person that everyone goes to to solve the legacy system problem. That’s a real problem. And it’s an art, you can’t fix it with that person, you have to fix it with everybody else. Right? How do we build an organization that’s now capable of dealing with this? So I can create space for this person to go do? What will be interesting and valuable to them and valuable to the company? Right? Like, okay, you get to go do research projects, because we’re not really sure what else to do with you. I don’t know that anyone’s going to benefit from that. But hey, we have this really interesting, hard technical challenge that we’re going to try to pursue, that’s going to move the product forward. Would you be interested in solving that? Or, you know, we’ve done a couple acquisitions? Are you interested in like helping this team really understand how our stuff works, so they can integrate and define this vision of this product? You know, as we move forward, is, it’s not really a different management problem. I think it’s like, what are people good at? What do they want to do? And can I align them up with that? I think it comes with this unique sort of challenge that we have of almost feeling like you owe that person like they’ve been here a really long time, they’ve contributed a lot, therefore, I owe it to them, to have them continuing to work on whatever versus you know, at some point in any conversation, and this isn’t true of everybody. But you know, it’s we’re saying, it’s worth identifying there’s not a good fit for you here. How can I help you go be successful out in the world, like, you know, we’ve had people leave and go become CTOs of other startups, I think that’s great for them, right. And I don’t feel like CircleCI is less afford. I’m proud of that. Like, we built some amazing engineers, we gave them awesome opportunities, they learned things. And they went off and did different great things. And some have stayed and love the work that they do. Like, I think we end up in this weird dead end, where we’re like, well, we have to keep that person because they’ve been here a really long time versus that person has been here a really long time they have this value, how can we give them a place to grow? And you know, have them deliver that value to us?

Aydin Mirzaee (Fellow.app)  44:14

At least that reframing and you’re right, it’s very individualistic and spending the time to really understand what that person’s goals are will definitely guide what one should do here. We are getting close to time. So I did want to normally my final question is for all the managers and leaders constantly looking to get better at their craft. What are some parting words of wisdom that you want to leave them with? But this one time I may seed that question a little bit and say, in the world of parting words of wisdom, I know before we started the conversation you had mentioned that you are thinking a lot about you know how to feel gracefully and learn from that. So I wonder as your parting words of wisdom, if you have anything that you’d like to share about failure

Rob Zuber (CircleCI)  45:03

of rallying listen to the second season of competition maybe covers so much of it, but I can’t cover it all. I think one of the things that has been most interesting to me in that conversation, and in thinking about that is I am very comfortable with the word failure, because I don’t put a lot of weight on it, I talk a lot about, we tried to do something that didn’t go quite as we expected, which is like, I expect that things won’t go the way we expected. I don’t know how they’re gonna go. And that’s not universally true. A lot of people for whatever reason, either the last company that they worked in, where it was treated very differently, or, like different cultures talk about words like that differently. And many other reasons. I think framing the question, framing your work around being hypothesis driven around running experiments around saying, we’re going to try something. And the result we’re looking for is new information. All right, we’re going to ship a product, and we’re going to learn if people like that product, we’re not shipping this product, cuz we’re 100% confident that we’re right. And Jim or CEO, like we use similar expressions a lot, like, we’re gonna be wrong. We just don’t know what we’re wrong about or how wrong we are. And so what we’re trying to do is learn right now, what is the fastest way that we can learn? And when I think I’m learning, then I’ve succeeded. I’ve succeeded at learning, even if I didn’t move the number up into the right in terms of, you know, signups. Right, it’s like, I now have new information about what doesn’t drive signups. So I’ve closed off a space of exploration, I closed it off quickly, hopefully. And now I can go investigate a smaller space and look for the thing that does matter to people. Right. And I think how we talk about, particularly failure, but turning that around into learning, really gives you an opportunity to open up discussion in an organization around things that have you know, they’re uncomfortable, and we talk a lot about psychological safety, etc. And yes, there are things that literally are failures. Sure. But we call so many things failure that I think we closed down avenues of learning, instead of really opening them up, and I guess I’ll leave somehow, my now 13 year old, he’s my younger son loves the expression, the only failure is failure to learn. I think I said it to him jokingly at some point and then like, you know, he’ll be playing us in a soccer match on the weekend or something. And I’m like, how did it go? You know, what did you think? And he’s like, Well, I’m really not happy about this. But now I’ve learned something, you know, the only failure is failure to learn, like, this is what I’m gonna do differently next time, but just kind of building up that mentality. Kids are like, sadly, a great testing ground for some of my theories. But I think if you could shift the conversation into, we’re trying to learn, everything we’re doing is teaching us something and that’s a positive, then you end up in a much better place in terms of how you, you know, how you experiment and how you move.

Aydin Mirzaee (Fellow.app)  47:48

That’s so good. Great advice. Rob. This has been a great conversation. Thanks so much for doing this.

Rob Zuber (CircleCI)  47:54

Yeah. Thanks for having me was tons of fun.

Latest episodes