Biography
Phil has been leading software teams in their hyper-growth stages since the early 2000s. He headed product engineering at SoundCloud and DigitalOcean, and platform engineering at Meetup and SeatGeek. He is currently a co-founder of Outropy.ai, the Copilot for Leaders.
Links and Mentions
- Phil’s website
- Phil’s socials: Twitter, LinkedIn
- The Engineering/Manager Pendulum
- Outropy.ai
- Scaling teams by Alexander Grosse and David Loftesness
- Attention is all a manager needs and the original Attention is all you need paper
- The original Backend For Frontends (BFF) article
Transcript
Patrick Kua: Welcome to the Managing Managers podcast. I’m your host, Patrick Kua, founder of the Tech Lead Academy and curator of the newsletter for leaders in tech, Level Up. In this podcast, I’m chatting with senior engineering managers, directors, VPs of engineering and others who have walked the path of managing other managers, where we will uncover some great stories and lessons learnt.
Let’s get started.
Patrick Kua: Hi everyone, welcome to the Managing Managers podcast. I’m very excited to have Phil Calçado. He’s a very experienced engineering leader. Phil has been leading software teams in the hyper-growth stages since the early 2000s. He headed product engineering at SoundCloud and Digital Ocean and platform engineering at Meetup and SeatGeek.
Hi Phil.
Phil Calçado: Hey Pat, how are you doing?
Patrick Kua: I’m very well. How are you?
Phil Calçado: I’m good, I just realised that in that bio. It misses the places where we met, at ThoughtWorks. It’s back like 15 years ago.
Patrick Kua: This is very true. We never really got to work together. But I’m very fortunate that our paths have crossed professionally over the last couple of decades still.
Phil Calçado: Sure, it’s a consultant’s core.
Patrick Kua: Excellent. So you’ve got a huge history and I’d love to delve into particularly your leadership journey. Can you give us a bit of a high level overview of what it looks like so far?
Phil Calçado: Sure. So you know, it’s the typical story. Especially for the early 2000s of people who fall into management. I never really wanted to be a manager or a leader. That was, maybe, I mean, I would say I didn’t want to, but I just never thought of it. I was like 22, whatever I was. From my very first job, I was working on that kind of digital agency back in Rio, I was quickly made team lead and as things happened back then, my first job was to fire two people from my own team that I had to work with before, just like, just up to then.
So you know, having to learn how to do these things on my own, because, to be honest, mentorship was not great, was a huge component of my first few jobs, usually starting as a senior engineer in some way, and getting some leadership positions. That’s actually one of the reasons I joined ThoughtWorks back in the day, because I wanted to be around people who knew what they were doing. It turns out nobody knows what they’re doing. But it was still very, like the community was great and the exposure to different projects and different sizes was an incredible growth opportunity. And then after ThoughtWorks, which, you know, has a leadership component to consulting, but you’re not really managing people as much. It’s really like influence, which is a good muscle to exercise and learn about anyway, but then I, that’s when I moved to Berlin and I joined SoundCloud.
It’s kind of completely by accident. I really just wanted to move to Berlin. I think I was the eighth engineer on our team at SoundCloud. The company was probably 40, 50 people total. And same story, I just wanted to move to Berlin, write some code, you know. Deal with some electronic music. Quickly ended up running the product engineering team, but the app team, we used to call it, became the product engineering organization, and it was a crazy, crazy journey.
So after that, one thing, and we could talk a little bit about more of this, I would talk about managing managers, but I realized that I was over relying on my technical skills as an engineer. Actually, it wasn’t that I had this realization. I received this feedback from a boss I really respect. From Dan, it was like 2015, up to, well, I don’t know, five years maybe, I decided to kind of swing the pendulum back and try to stay as much as possible, you know, exercise my leadership and management muscle.
Fast forward to now, I am actually starting a new endeavor, which means it’s me and my co-founder, I’m just cranking out code every day. I tried to manage him, but he slaps me, so let’s see how that goes.
Patrick Kua: Yeah, it’s very exciting, and I’m very enthralled by what you’re building, which is a tool for engineering managers. We’ll talk about that later, but let’s delve into, particularly, the managing manager part. So I got the impression that when you joined SoundCloud, and those years there, it grew really rapidly, and so you started ending up managing managers. What was that sort of transition point? Was it something that you got pulled into? Was it something that you just got thrown in, you like every other role?
Phil Calçado: Yeah. I just like perpetuated a curse a little bit probably. So I was moved into management at SoundCloud, as part of a restructure when our first group of engineering, who was Alex Grosse, who was still lives in Berlin. He decided to create a management layer, because up to then, everybody was managing to him. We were hiring like crazy. It was getting complicated. So we split into maybe four different groups. Product engineering was one of them. Then we had data and infrastructure. Yeah, I think it was the groups we had. And I then started off with a team of maybe eight people. Three months later maybe I had already 25 people reporting to me.
Patrick Kua: Wow.
Phil Calçado: So that’s the point you realize that you’re spending more times in 1-1s than anything else in your life. And also, I was really worried because I just, I was not able to follow what was happening in the company. In SoundCloud, always moved very, very fast. So at that stage, I started thinking about introducing a new layer. I talked to my leader and what we worked out. Ok, I should probably pick a few different people and not think too much about the structure, because we were in a hurry, there’s not a lot of time to plan.
So I looked around my staff, because I’d never really hired an engineering manager and back then, you know, all this culture, we have now, with the material, you and other folks producing in these areas, this didn’t really exist. In fact, I think Alex wrote one of the first engineering manager’s book from the experience at SoundCloud a few years after this event. Anyway, so I looked around and I kind of tried to get feedback from people on the team. Like who would be good candidates.
I’ve got two people who were very strong technically, but also were very kind of people people. Those are the folks who would come to me and say, hey, you should pay attention to this person, I think they are struggling a little bit. And they, they would tell you, both of them, that I kidnapped them into a room and made them managers. That’s a lie. I did not agree with that. I do not condone this version of the events. But I did talk to them. Say, hey, I want to try this out. I don’t know how it’s going to go. What do you think?
And that’s when, you know, in one week, we had two new managers taking care of two slices of the team. Eventually it grew to be, you know, three different verticals under me, that each one had a lot of different managers. But that’s kind of how my first managing managers experience started. I had no idea what I was doing. All I knew is that this was not scaling. We need to build all these different things and we need smaller teams that have dedicated support.
Patrick Kua: Amazing. So a couple of things. So the Scaling Teams book. I think that was the one that Alex wrote as well. So we’ll add that in the show notes as well. Really great book. Not so well known, I find. But I can see some of the lessons probably from SoundCloud there.
Let’s delve into the sort of two people that you, not kidnapped, but convinced to step into a management role. So it’s an interesting mix because they were, they had that technical background, but they had that sort of people focus. And so when you put them into that sort of role, and you know, for you, I guess it was also relatively early in a sort of management sort of skill set or career. What sort of support or how did you support them being successful as engineering managers?
Phil Calçado: So that’s probably the time where I developed a few of the things that I still apply today as a manager. One of them is, everybody who works with me knows that I talk a lot about accountability and responsibility. And these words in English are terrible because they could mean whatever the person wants them to mean. So I have to spend some time defining what that means to me, so I can use it as a framework. And I mean in general times, if you’re accountable for something, you are ultimately responsible for the success of that whatever that thing is. If you’re responsible for something, then you know, repeating words again gets complicated, but responsibility in this, basically means you’re doing the work.
And there’s a very interesting dynamic that happen when you’re accountable for something. So if that fails, it’s on you, but you’re not responsible for it. So somebody else is doing the work and like, oh shit, how can I control this thing that I can’t control? And also the other way around. When you have responsibility, but no accountability. So it doesn’t really matter if it goes well or not.
So I started thinking a lot about how to establish this framework, which is important to me, plus something that, obviously, took a few years to develop. But the idea that as your leader, as your manager, I’m working with you, it’s the same for ICs and first level, for several management as well. But it’s more important for when you’re managing managers in my experience, which is that you need to tell me what hat you need me to wear right now. Because I could be a coach and let’s sit down and work on this problem together, or it could be more of your boss. Maybe I can escalate something, or you need more context, or, you know, I need to represent the company often times, especially the higher up you go. The worst thing that happens with this thing is when it’s mixed and you’re bringing something to me that I think you could try to escalate to me and know, oh, we wanted to have a conversation about how to deal with that thing. Or, vice versa. You bring something that you really need me to act on. And I’m like, oh, yeah, let’s whiteboard this idea. It’s like, no, dude. Do something. It’s your job.
So these are the first few pieces that I put together in trying to work with them. One thing that’s really important to me, and also it was part of the selection of these two particular people, was that I, my general feelings that, I hate the concept of managers as gardeners of people. I think this is not something, that’s to be honest, makes any sense to me. If I wanted somebody to be just a people manager or a coach, I would hire somebody who actually has studied that and not try to shoehorn a software engineer into this. So this is the component of people management, delivery management, and the technical accountability for what’s going on in this strategy of the team. I think are really important. I tried to use these generic building blocks in helping people through that.
Patrick Kua: Great. I mean, I love the distinction that you make between the accountability or responsibility. And I think what you’re trying to say, or what I understood was that, clarify expectations around what are they, particularly between managers, because that’s where it gets fuzzy, I guess, where people are making assumptions as to who is responsible and accountable.
Phil Calçado: Yup.
Patrick Kua:
It’s a lot easier when an IC is taking on, or an individual contributor is taking on very specific work. You see who does the work. But at management, it gets a bit fuzzy because everything is more conversation or sort of hidden work or not necessarily something that you’re producing as such.
Phil Calçado: Yup.
Patrick Kua: So I love that distinction that you make around that. I also love that you sort of define, I guess, sort of three capability areas that you talk about with engineering managers. Around the delivery management, the technical management and the people management as well. I found, personally, delivery management seems to have gone down a little bit, skills wise, in our industry. How would you describe what you mean by delivery management?
Phil Calçado: Yeah, I definitely agree with that face value. So the way I see delivery management is really, you, again, going back to accountability. You are accountable as a leader of a team. For something, let’s say, it’s a delivery of a feature or a product or whatever it is. As a manager, you need to look at how things go from somebody gave you a task delivery to how that goes, how that’s live in production and working, right? And everybody’s responsible for this but the manager’s accountable for that. And figuring out, and that’s, you know, that’s where I think we lost, figuring out what’s the value stream to get there.
I don’t want to throw a lot of terms that might not be familiar to people. But basically, what are the steps to go from A to B and manage that. I would say that in a healthy organization where you have enough technical skills, your people are not, it’s not a people crisis every day. This is the most important job for manager to look at this pipeline. It’s a factory from an idea to production and realize, “What’s missing here? What can be better? How can we prove this?”
And I definitely agree that, for various different reasons, a lot of what we have developed as a culture of delivery in the 2000s has kind of died off. I think some of these reasons are valid. Because, you know, the work, the word back when people talked about the agile manifesto, it was very different.
Yeah, IT was really outsourced, cost center, a whole different organization. And right now, we have a lot more contact with the business, especially like the tech industry as a whole. Banks and big corporations might be different. So it requires some changes from what was written 20 plus years ago. But it’s still, there’s a lot of practices that people are just like completely ignoring. And, funny enough, reinventing as they go.
I guess, Pat, we’re old now. And when we were fresh, junior engineers, it was like, oh, I’ve seen this in the 90s. It’s like, oh, shut up, old man. It’s like, now, now we’ll see this. But yeah, I think it’s a, it’s a most important, well, I don’t know most about most important, but definitely one of the three most important responsibilities of a manager, a leader, whatever it is.
And I don’t think we’ve been paying enough attention to this. In fact, it’s very easy. Just go to any kind of conference or even book in software engineering right now and try to assess how many chapters or amount of content there is around delivery versus people management. Or, you know, how to create a cohesive team. You know it’s more people or soft skills kind of things. I think it’s really bad for the industry.
Patrick Kua: Yeah. Yeah, it’s definitely a swing in emphasis in one area. And your trifecta, the delivery management, the people management, I think lots of stuff and resources around people management. Let’s talk about that’s sort of technical side. So how technical do you expect engineering managers to be? How do you know, like, what’s technical and what’s technical enough?
Phil Calçado: I don’t know if I have a good litmus test, but they should know what’s happening within their system. So if there’s a, there’s an issue because we have too much tech debt, because they need to be able to explain that to me. And one thing that’s interesting is that I don’t think that they should know the detail. I don’t want them to necessarily write code every day or even at all. And within the team, I’ll also make sure that I have a good relationship with, at least, the most senior technical people, the most senior engineers. It’s better you know the side of the company with all engineers, but you know, there’s only so much this scales.
And so I want to, I want to ask the more deep technical questions to this person. Not necessarily to the manager, but the manager needs to be able to understand because if, if that person is not understanding, so they’re in a meeting with managers from peer teams, they need to be able to represent that team at that level. The worst thing is we have a meeting. It’s very costly with representatives from different teams and they’re like, oh, they make a decision that it’s not the right one because they don’t know what’s going on, because they can’t represent the team technically, or they have to go back to their team and ask the question.
So they need to be able to understand at least at that level. And I don’t believe that it’s, I don’t think that people necessarily need to be writing code, as I said. But they should be able to. Even if it’s just like, you know, smaller tasks that are well defined. They don’t need to be the best engineers in using a team. But they should be able to, otherwise. I don’t, I’ve seen it working before, but I’ve more often seen it not working at all.
Patrick Kua: Yeah, great. Yeah, I totally understand, which is knowing enough to understand the risk factor and to call people out if they feel that something is maybe being misrepresented as well.
Phil Calçado: Absolutely.
Patrick Kua: So let’s talk a little bit about sort of broader, because I feel looking at your sort of career, you sort of done this pendulum between being a manager to being sort of a IC as a architect and back. Were there any reasons you did that and how did, how did you find yourself in those roles?
Phil Calçado: That’s a, this is the, especially this one, experience in my career is was what breaks my nice narrative of becoming more of a manager. It was basically when I left SoundCloud, I moved to the US, I ran product engineering for Digital Ocean. And it was, it was a very different experience. I learned a lot. Digital Ocean is a very successful company. But while I was there, some people I know, who used to work at Twitter, and Twitter and SoundCloud shared a lot of technology, a lot of the core micro services tech stack, we built together.
They called me and they’re like, “Hey, we just got seed funding. We’re going to get this piece of technology that we built, you know, the two companies, we’re going to make it into a product. Do you want in? And I’m like, oh shit. OK. Yes, I do. So that was Buoyant. Basically, the people who propagated the concept of service mesh.
Patrick Kua: Great.
Phil Calçado: With Linkerd. And so I joined them and it was very, you know, was thrown from not writing code at all to basically just write the code with eight people. The whole company.
Patrick Kua: Really early stage.
Phil Calçado: Yeah, we, the only person who didn’t write code was our designer. Everybody else from the CEO. It was, it was a very interesting experience. But one thing, though, is that even, you know, these people are very senior, right? Everybody at Buoyant, especially back in the day, had like senior staff level in engineering. So they come in, but you still see the confusion that generates when you just get a bunch of engineers. And they were trying to work on the same things and stepping on each other’s toes.
So I had the opportunity to kind of help structure work around a few different initiatives and slice projects. So that was good. Ultimately, that was a short-lived adventure because that was way before remote working was cool. It was like, 2017. And I was the only person on the east coast of the US. Everybody else was on the west coast. That was not working very well. And I didn’t want you to move to San Francisco. So ultimately, like, okay, I will, I will probably find something in person in the city.
Patrick Kua: Great. Yeah. And I mean, it’s such an interesting opportunity to join in that. And the fact that you can go back to being hands on, I think is a really huge testament. When you moved back into sort of the management track, do you think that had an influence of being relatively recently hands on or has it affected your leadership or management style?
Phil Calçado: It did. The biggest change was that I actually started working on the platform/infrastructure side. As opposed to product engineering. So I joined MeetUp immediately or, not immediately, a little after the WeWork acquisition. So there’s, you know, there was this very complicated point in New York.
Patrick Kua: Turbulent times.
Phil Calçado: Yeah. Well, WeWork acquired a lot of random companies, including MeetUp. And I was brought in as part of a group of people who were basically trying to shore a company that’s, I think, MeetUp is from 2001. And the culture from 2001. So they’re like. Okay, we need to be hypergrowth. What you’re going to do about this? And I was looking a lot at the platform. And, how the architecture needs to evolve that way. And funny enough, like, while I was at Digital Ocean, after I left SoundCloud. I left SoundCloud. We were the first company, I think, or one of the first 10 companies adopting Kubernetes.
And fast forward when I was at Digital Ocean and not paying attention to code so much, Kubernetes just became a thing that exploded. At Buoyant, my work was actually to integrate against Kubernetes. So this, like, code is, I don’t know if it’s still there, but I had to submit code to the Kubernetes core project and various things. So I became really familiar with that word, containers, and how these things work. Uh, which I then could use to help my team make decisions at MeetUp.
So at MeetUp. I wasn’t writing code as much, although my team was pretty small. So like 10 people, when compared to others was not so big. But I used this to guide the team towards, you know, what kind of technology choices we’re going to make. So it was good to keep fresh. I think ideally, if I had my way, I would do, uh, one stint as a more manager focus and another stint as a technical focus. Kind of switching. I think it’s a good way to keep my brain, both of my interests fulfilled. About also keep my brain sharp in both ways.
Patrick Kua:
Also it’s kind of rare. I think there’s a lot of depth of being sort of up to date in terms of what people are using, the challenges and understanding some of those things, but then be able to leverage your management and sort of structured thinking. It can be very helpful.
Phil Calçado: And I would say that it can be very helpful. But also can be a disadvantage in many different ways. Like the worst thing is when I need to interview for a job. And they’re like, “Wait. So are you technical? Or are you a manager?” I’m kind of both. No, no. You cannot be both. Pick one. And I’ve been rejected for being too technical. I’ve been rejected for being leadership-y. So it’s like balancing, creating a narrative that fits what most archetypes, uh, work, how most archetypes work is, is complicated.
Phil Calçado: I would argue they have missed a lot of potential. Right? I, I appreciate both sides. But I can understand for some people, they see that stereotype and they like only want that picture.
So, they missed out. Sorry.
In that MeetUp space, you’re leading platform, how many teams, how did you structure that organisation? What was the shape and size of that?
Phil Calçado: So, at MeetUp, we had, I think four different teams. We had the web, platform teams – basically all the frontend components. There was a infrastructure team. I had, you could call it an architecture team, but it was more like a special project. This was basically the people that tried to build the new architecture for what MeetUp was going to be. I forget what the fourth team was. So, please forgive me, fourth team people.
But basically, there was one thing at MeetUp that I think was pretty bad on the way that we structured the team. Within the the platform organisation/ infrastructure, we had one VP and we split into two groups. My group was forward looking. We helped how MeetUp needs to evolve. And then we had another group about the same size, we were a little smaller, that took care of the current code base and make the code base usable. And I think this split was really detrimental to what we’re trying to do. Because there were competing interests.
And it was really hard for us to, keep evolving the platform. We tried convince others to use the platform, while somebody else tried to make the old platform easier to use. Those structures were not very aligned. And I think it has, I don’t know what would have happened if WeWork hadn’t crashed so much. But this didn’t help us move forward with our goals.
Patrick Kua: Yeah. And if I understand it right, that was in another director’s or a different team, so that’s not something that you could really influence, right? Or, well, you couldn’t control.
Phil Calçado: It was another director. It was somebody I’m very close to, and in fact, I joined because of this person. So there was no, you know, bad blood between the teams. It’s just, it was clearly, you know, we were clearly diverging in our goals. And it was hard for us, even with a good personal relationship, to get them together aligned towards the same goal. It felt like we were basically hedging our options a little too much. Instead of committing to something.
Patrick Kua: Completely understandable. Let’s maybe move on to a more recent role or the next role around the senior director of engineering at SeatGeek. In that world, what did your scope look like there? How many people and how did you structure them?
Phil Calçado: So there was, uh, kind of a similar spirit. SeatGeek, people in the US, and maybe in the UK know the brand, as a secondary market place for live event tickets. So, you know, it’s similar to StubHub or Vivid Seats in the UK. It’s probably illegal in Germany, I am assuming.
SeatGeek was more like this. The company was already 10 years old by the time I joined. But, you know, they eventually realized that there’s only so much market in this space. It decided to kind of go big or go home and embrace what we call the primary ticketing market. So basically, go against TicketMaster and other big, ticketing names. They were managing everything from venue, concession stands, inventory, to selling admission, that kind of stuff. So they were very successful in signing a few different clients, like big NFL teams and, and other venues on this effort. But the problem they had is that the software was not made for that.
They had a consumer facing website that was not bad, but it was made for a secondary marketplace for tickets. And the back office software that was in acquisition was a really, really old piece of software that was made for much smaller requirements in terms of performance and attendance and venue size and things like that. So I knew the person who had just come in as the CTO. He invited me to join and focus on how can we get these old systems and make them work better? Because it’s still a startup. You can’t just like rewrite everything from scratch.
So this is, I think, 2019, when I joined. And I joined with a super small team. It was literally three people. I tried to find opportunities to make things better. We migrated Python versions to Python 3. We migrated MySQL versions from a 10 years old MySQL build to something more recent. There was a lot small changes here and there to improve performance. But we were still gearing up to see what would come.
And then eventually I ended up running all of infrastructure and this team grew. So ultimately, I had maybe eight different teams working on different parts of this problem. We also had to lift and shift a lot of systems that used to run inside box offices in venues to run on AWS. Like super old versions of .Net. It was, it was a whole thing. There was a lot of, you know, fun things to do it from A to B. And we’re doing great. That was like, everything was flowing. Our speed was good. Velocity was great. We’re signing contracts like crazy.
And then February, 2020, we had the largest on sale that we ever had. I think it was a Justin Bieber concert in the Dallas Cowboys Station. So the Dallas Cowboys Station, I don’t know if that was the configuration they used for Justin Bieber. But it’s held one on the biggest configuration with 150,000 seats.
Patrick Kua: Wow.
Phil Calçado: So you have to, you know, sell. We sold out in 5 minutes. Everything was great. But again, February 2020, fast forward two weeks. Pandemic hits. Our revenue. I don’t think our revenue ever dropped to zero, but it was very close to that for a quite extended period of time.
So it’s funny how I had to switch 180 completely because I was focused on how can we grow this system. And now, especially because I was responsible for infrastructure and other things, I was, I spent three months on the phone with vendors trying to pause our contracts. You know, make sure that we could keep cash in the business. It was, it was also a very different thing for what I had done in my career, even in larger roles. I think, oftentimes, engineering managers, and even directors, are really shielded from cost, thinking of cost in general. We’re given proxies like headcount or, you know, whatever kind of fake money to pretend that we don’t, we don’t have cost in this.
So this was basically the first experience I had, I had to sit down, look at contracts and bills, and like, oh shit, how can we reduce these? What kind of spend do we have here? Maybe we could change vendors? So there was a lot of the first few months of the pandemic, which is like having these calls and trying to downsize everything as much as possible. So we still have a working website, with people wanted refunds. There’s a lot of things that was still happening. But the business side was kind of dead.
And the interesting thing is that we did all this work, downsizing things, but because the event industry was, they didn’t really have anything going on. We ended up signing a lot of new clients. So we also had to onboard new clients. It was like, oh, you know, I always wanted to migrate from vendor X to you. We never had time. Now was a good time to do this.
So we started having to onboard all these people with a lot of development work, custom development here and there. And then by, I think, November 2020, the event industry decided that, okay, this pandemic is not going to last forever. So, in fact, we’re going to have some of these big acts coming up. And I think with December 2020, we were selling tickets for Bruce Springsteen on Broadway.
Patrick Kua: Wow.
Phil Calçado: And Bruce Springsteen on Broadway has always been the largest Broadway event ever. Even bigger than Hamilton. So we were like, oh, shit. Now, we’ve spent months turning these things down. And now we have a week to get back to the peakest performance we could be. So it’s a lot of fun, interesting things, in that way.
But I’m not going to lie. The whole working in live events during the pandemic really took its toll. Yeah. It was tough. It wasn’t a good spot.
Patrick Kua: Yeah, I can imagine. And I mean, I think that experience that you got of managing cost and doing something that’s very different in that context. Let alone leading organisations through that crisis. And you know, it sounds like at least the business still ended up in a good place. Despite all those pain points, hopefully led to some good insights and lessons for you.
Costs are one of those things that you said a lot of engineering managers are shielded from. Looking back at your experience with managing managers, what are other sort of activities or responsibilities that, you know, engineering managers probably wouldn’t be responsible for, but probably directors or other people who manage them would be? What are some other examples that you can think of?
Phil Calçado: Aside from cost?
Patrick Kua: Yeah.
Phil Calçado: I think it’s less practical, more fluffy, but understanding the business and business strategy is something that I think, at all levels, people still kind of [???] each year as a lot. And a lot of it is self-inflicted with the way each year’s behaviour can drive. Engineers tend ask for very specific things. A very actionable request, which means that they’re not invited to the conversation about this thing that might or might not happen in one year’s time.
This is something I had to learn the hard way. Why am I not in this meeting where this was said? We thought that you prefer to have the information as it’s certain, instead of debate the uncertain side of things. So I think, especially the management level, but it also happens at the director level, not being exposed to where the business is going, in terms of more strategic, iffy, inspirational or speculation scenarios, it’s something that’s definitely missing.
Patrick Kua: What have you found are really good approaches to getting more involved in that? I mean, it sounds like there’s definitely going to be more meetings for people. How do you get invited to them? How do you get more insight into influencing them?
Phil Calçado: So I think the easiest, or the only way that I’ve seen working, is first to change this attitude personally. I was this person. I was a person who would be, you know, if it’s not certain don’t even talk to me. I have so many important things to do. There’s somebody I’m a mentor of, and the way I always talk to her about this as, “Don’t crush other people’s dreams.”
Patrick Kua:
I love that.
Phil Calçado: So somebody comes to you with a crazy idea. You kind of, yes and. You know, like from people who have visited improv comedy. You always go ahead. Just get that idea, and stressed that I’m thinking about it, and find ways it could work. And maybe it could work. So like, okay, we sure, we want this crazy thing. We would need to do this and this and that and kind of spar with them on the idea, whiteboard.
Be a partner, more than just the person who says no all the time. Because what’s going to happen if you say no all the time? These conversations will keep happening. You’re just not invited to them anymore because what’s the point to have you in a room? If we’re brainstorming and you’re just saying no to everything.
This stereotype of the grumpy rational engineer in the room. It doesn’t really help anybody. Being able to collaborate on these things, I think it’s very important.
Patrick Kua: That’s a really great tip. And I could definitely see that. Imagining a lot of people going into a room and saying, that’s not possible or, you know, here’s why that’s not going to work. And I can see that happening quite a lot. Absolutely.
You’re probably seeing a lot of people transition from that first level manager of individual contributors or teams, to manager of managers. Are there any common mistakes that you see? One of them is definitely been this one that you’ve talked about, which is the, yeah, not getting so involved in the business strategy. What are other maybe common mistakes for first-time directors or managers of managers?
Phil Calçado: So something that I could be thinking a lot about in terms of codifying as like discrete topics or things to think about. I think it’s the fact that once you stop, you step up, looking at your team. I keep saying that, hey, you’re looking downwards to your team. And hopefully, by the time you get promoted, you know how to do that very well. We know exactly what’s going on in the team. When you take a step up to become a manager of managers, you know, manager, whatever you are, these two things happen. First, you have more teams. So you might have to manage across multiple different things. But also the most important thing, which is related to the whole strategy conversation, is that you also need to look sideways through your organization.
You’re going to have to build a relationship with a person from marketing, that maybe you don’t even know. Is the person you always see in the kitchen and you never really know what this person does. So you actually need to build that relationship. You need to know what’s happening across the company, because you are expected to work as part of the leadership team. And obviously, depending on the size of the company and how it’s structured, you’re immediate leadership team might vary. But usually, at least whoever is under your direct manager, so, being a CTO or VPE, whatever it is, you really need to understand those people as your team, build good relationships to them. Know what’s happening within their world and let them know what’s happening in your world.
So this kind of step is, I think it’s where a lot of people struggle. When I’m working with this transition with engineering managers becoming senior managers or directors, a lot of what we spend time on is figuring out who they should meet with regularly, how regularly, what the blind spots they have, the organization, how can we expose them to things that influence their work, so that they can build these relationships. I think the worst thing that could happen is when you talk to somebody, who’s a stakeholder, even if it’s a distance stakeholder, but the only time you talk to this person is when something wrong happens. That’s where, you know, all this kind of us versus them and weird dynamics start happening. So build this relationship.
Even if it’s just coffee every month, where, maybe you don’t really talk about so much about the project. Just have face time with these people. This is probably the biggest caveat or the biggest struggle I’ve seen people developing. Because again, at the same time, they still need to look down and oh, shit, now I have three teams or four teams or whatever. So I also need to know what’s going on in this. But I think this is the more intuitive place where people spend their attention as they go and looking out to the sides.
And you know, looking upwards, too, because you are always managing upwards, looking sideways seems to be a struggle.
Patrick Kua: Yeah, I could definitely see that blind spot. And I think those conversations of who should you be thinking about talking to that you’re not and not just when things go wrong, that’s a really good tip for people transitioning into this role.
With the managing more teams that often means a little more context switching and more things to take care of, how do you stay in top of all of that? So how do you help people switch between product domains and different team contexts? What have you found personally work when you have more teams and more things going on?
Phil Calçado: I think the the most important thing is to establish a process by which you’ve got access to this information. If you just try to go down Slack or email, whatever it is. I’ve been this person, I’ve been the person who reads everything that’s on Slack. Every single email in my inbox. It’s not only that doesn’t scale, but this probably is probably not the best use of your time. So figuring out how can you make it such that the information flows to whoever they need to or whoever it needs to flow to, at the right time is really important.
The ways I’ve done this in the past is being a little more prescriptive around a few things. When I’m playing a manager of managers, director, or VP role, I will not tell you how you run a individual team. Again, I can put my coach hat on and talk to you about my experience in many different ways that teams could go good or bad. But I’m not going to tell you, you need to use this process or to do this or that. But I’ll give you some hooks. Basically [NPIs]??? that I need your team to fulfil.
One of them is, you know, maybe every second week, there’s going to be a report that looks like this. Like what we’ve done, what’s coming up next, maybe some narrative around people issues you’re facing, risks and this stuff. It’s a specific format, but that doesn’t mean that you have to have two week iterations. I don’t care. You could have no iterations, one month iterations. But every two weeks, I expect that report to come and to follow this specific format because, you know, when you look at 10 of these reports, it helps when they look the same.
So these specific hooks in the process that I ask people to fulfil and to comply. These are one way that I, as a person who’s sitting on top of so many different teams, keep track of what’s going on. Another thing that’s, so, you know, this is the day-to-day kind of the baseline part of communication. You need to create a system that’s resilient enough for ad hoc communication as well because the most time sensitive stuff will come ad hoc.
So a few different things from this. Please do have office hours and encourage people to actually use those slots. It’s funny. I spent the last 15 years working for global north companies. And more recently, my most recent job was back working for a Brazilian company, which is my culture, but I’ve lived out of the country almost 20 years now. It’s sometimes a reverse culture clash for me. But it was the first time I saw, when I had everyday, I had at least 30 minutes with 2 x 15 minutes of appointment or office hours slots. And everyday would be filled. People would book them for months in advance.
Whereas in other countries, in other the cultures I had to nudge people, or sometimes people ask me something. I was like, oh, this is a great idea. Let’s, why don’t you book sometime in my office hours we talk about this.
But to have that conversation with people, because that creates this space. Again, when somebody can come to you and say, hey, have you heard about this thing or this thing that might happen across a team? It might be a problem that you never heard of before. But if the person can only talk to you or has only talked to when he brings a problem, they’re not going to come to you. Like, okay, this is escalating and I want to escalate this. So building this space where people can come to discuss whatever, invites them to come and bring topics that are probably more time sensitive, or even more important than they may even realise.
So having these hooks in the process where ad hoc information can flow to you and be mindful that as a senior leader, people start looking at you differently. It may be people you were working with, just five minutes ago, cranking out code, but they will look at you differently now.
So you need to make sure that you create safe spaces and good relationships with them. Because the relationship would not flow naturally as they once did.
Patrick Kua: Yeah, I love that. And I think what you talk about with those hooks, that brings it interesting dilemma, because I think one of those interesting things for engineering managers is, complete autonomy around how they’d like to run their team. But you, having many different teams, that’s difficult to plug into if each team is running teams very, very differently.
How do you find that balance of, where do you standardize what? So I understand that’s maybe some of the hooks that you’re talking about.
Phil Calçado: Yeah, usually I tend to have very few requirements. Bi-weekly report being one of them. I always used it. I don’t even know if there’s anything else I would say, is a hard requirement on how people do their work. But then I think there’s also a difference between what’s the baseline communication. And also how I believe a person is performing at their job. So if the person fulfils everything that’s in the baseline, that’s the bare minimum.
But you deploy once a year or once a month or whatever, okay, this is, you know, let’s talk about this. Why is it the case? Maybe you have blockers or maybe you don’t understand the philosophy. You, you know, continuous delivery is not something you believe in and we might have a culture clash that might go one way or another. So I think there’s, in terms of just expectations, again, as long as you are fulfilling that few little, few things, it’s fine. But we need to talk about the performance of the manager and then goes back to the conversation around delivery, people management, technical strategy, how well are you doing in these part. And then, you know, there’s other frameworks that we can use to assess performance. But within, in terms of autonomy, within the team, I don’t, I really don’t like to be prescriptive around that.
One of the reasons that’s actually interesting, I think, you know, similar to you, Pat, I cut my teeth at ThoughtWorks, where we had all sorts of different projects. But they kind of all look the same, which is great because it could just drop people in and out and they would like immediately know what’s going on. But when I started working with startups, especially as SoundCloud, it was during the mobile revolution, you know, well, mobile first and all that. And that was the first time in a decade that I had seen a process that was much more complicated than what I was used to.
Mobile engineering was, is already hard, and is still hard these days, but it was much harder back then. There’s only so many people available, so you can’t have fully functional teams cross-skilled. And I had to break my own biases instead of, oh, no, it must work this way because that’s how high-performing teams works. Like, no, we need to adapt to reality of, there’s only so many people who can do mobile development. It takes so much.
You can only deploy once a month because Apple says so. All this kind of stuff. So that’s when I started changing my behaviour and becoming a lot less prescriptive. I still have my preferred way to work with teams, when I’m lucky enough to work with a team directly. But I tend to give them a lot of freedom to choose and use me as a resource. I have a toolbox full of different things that we can look at and maybe processes that will help or not.
Patrick Kua: Yeah, and what I’m hearing is that even if people have a different way, you could still have a conversation, asking them about if it’s a deliberate thing or if it’s a default behaviour and do they think of other ways of doing things as well. Um, so I think that’s a great approach.
Let’s talk about something that you’re working on, which was connected to time and it was a recent article that you published, which is “Attention is all a manager needs.” So why did you write that article and what’s the essence of that article?
Phil Calçado: So this is something I’ve been thinking about for a long time. And the title of the article, I realised that the joke didn’t land with a lot of different people. Like, some people have been exposed to kind of the AI revolution and know that there’s a very important paper called, “Attention is all you need”, right? Yeah, I think that’s title. Uh, that was a pun with that.
But the general feeling I’ve had for years now, especially after I left SeatGeek was that there is so much, let’s put it like this. Every senior manager I know, and it doesn’t need to be somebody who has done consulting or more horizontal jobs. But you know, if you’ve seen a senior manager at a few different companies, they all have a Google Drive folder somewhere, with a lot of templates or articles, sample of how to write an RFC, how to do this, how to do that. And this is, this reminds me a lot of when I first started in this industry as an engineer where people would have their little codebases and the zip files because there was no such thing as GitHub. Carry it around and build your own best practices. My whole idea was, can we automate this? Can we make this, display books, more, not only more available to people as a library that people can consume from, but also executable?
And one frustration I always had as an engineering leader is that you need to do something like I need to invite everybody in this Slack channel to a meeting. This is going to be 10 lines of code. 100%, 10 lines of code. Super easy. And then you start looking at Google Calendar’s API and it’s a mess. It’s like Slack’s API’s is another mess. You have to create two different applications in one of the platforms. It’s crazy. You invest, you waste too much time even thinking about this and nobody does it. It’s quicker to just like manually automate, or worse, hire somebody to do their work like a Chief of Staff and Executive Assistant, whatever.
So I’ve been juggling with this problem for a little bit and in 2021, I took a break when I left SeatGeek and I decided to explore this idea, thinking of it as an equivalent to DevOps. I even, registered managerops as a domain because I want to work in this space.
And one thing that I quickly realised was that this, there’s a lot of interesting things that can be done. But management is so different even from,infrastructure, let alone coding in the sense there’s so much nuance and conversations about what’s really important. There’s a lot more that was very hard to… there’s no terraform for management. It’s a hard thing to do. I parked this idea for a little while, took a job somewhere else. But then earlier this year, I found myself in the same situation, again. I want to start working on this problem.
And eventually, I was talking to somebody who’s my co-founder now, who has a huge background in AI. And this person was, you know, we could actually, literally just use, a large language model to start understanding conversations and suggest things. We can train this model with what is considered to be best practices around engineering management, leadership, whatever it is. Oh, wow, that’s interesting. So we got together for a few weeks, cranked out some Python notebooks, validated the idea, created a first pitch deck and started talking to people who have money to see if anybody would like to fund this. Eventually start building what’s this product.
This product is called Outropy. It’s a terrible name, especially pronounced by somebody who has an accent like me. But it is what it is. I’m known for being terrible at naming things. I was the one who named the BFF (Backend for Front-End) pattern, so you can all blame me.
But anyway, what we’re building right now is based on the idea of “Co-pilot for managers.” We have a lot of interesting things that we want to explore within this space. Our first release, which is coming this fall, really focuses on attention management. Basically, we crawl all of the systems you already use. Slack’s the main one that people are interested in. But Google Docs, Google Calendar, everything, and we try to understand not only what you create. You know, the artefacts, the documents, the conversations, but also how people interact with each other. So we can get the actual org chart for your company.
Because, you know, you can look at the org chart in Workday or what have you, and that’s not how people work. That’s just who reports to whom. Who can fire whom? But figuring out which people are interested in which projects, how they collaborate and gives you a lot of different possibilities from this kind of graph. The first thing we’re releasing is a daily brief. Where you can figure out what different subject, what different conversations are important to you that are happening across the company. So again, you can look sideways and downwards without having to scroll through multiple different slack channels. But we are going to evolve it further and further, basically applying, good engineering, well, best practices, if you will. Training our LLMs with this, so that we can have actionable follow up actions and interesting things that a manager can do within this co-pilot space.
Patrick Kua: That sounds amazing. And I can imagine that would be a huge value add. Both time, attention and focus for managers, because particularly as scope grows, it becomes smaller and smaller or there’s more things that can pull of that. So I can definitely see a lot of space for that. I’m very excited to see what you and your co-founder are going to be building over the next couple of years.
Phil Calçado: Yeah, I mean, the waitlist is open. We’re going to be (live) very soon. I’m sure Pat’s going to put the link there, so you don’t have to figure out what I mean when I say Outropy. We’re super excited. It’s this space. There’s a lot happening in AI right now. I don’t know of anybody else working in this particular space.
Patrick Kua:
No, definitely not. Not that I know of. Not as active or as focused with your experience as well. So that’s a really valuable add.
Well, thank you very much, Phil for joining me on the managing manager’s podcast. It’s been a real pleasure to hear your experiences. Thank you very much for sharing your stories. Lots of great insights and tips. I hope the listeners enjoyed it as well. So thank you very much for being on the show.
Phil Calçado: Thank you all.
Patrick Kua: Thanks for listening to this episode of the Managing Manager’s podcast. You can find the transcript and the show notes at www dot managing managers dot tech. If you enjoyed the content please be sure to rate and subscribe, to be informed about new episodes. Also consider sharing this podcast with another person who might benefit. Until next time.