Episode 9 is a whopping twenty-six minutes because there was so much I wanted to keep asking my guest, Juan Pablo Buriticá (@buritica on Twitter).
Juan Pablo Buriticá has been leading engineering organizations for the past decade. Prior to his engineering career, Juan worked as a chef and as a pharmaceutical chemist. We talk about timezones, how communications is the limiter on scaling organizations, how to create social rulesets for individuals to develop personal filters on communication, how to get a pulse on your organization when you're managing managers instead of individual contributors, and much more!
Transcript
JENNIFER: Welcome to Storytime with Managers, a podcast by Cohere.
I’m Jennifer Tu, and I’m here with Juan Pablo Buritica to talk about managing managers remotely. Juan, can you say a little bit about yourself?
JUAN: Sure. Thank you, Jennifer. I live in New York City. I was born in Colombia. I’ve been in New York City for almost 10 years. I’ve also been working in technology and in startups for about 10 years. Before, I used to be a chef and a pharmaceutical chemist, but that’s a story for another day. I’ve been leading engineering organizations for almost as long as I’ve been an engineer, just 9 or 10 years. And the primary kind of organization that I’ve been running are distributed teams between the US and Latin America.
JENNIFER: Wow, I definitely want to bring you on for a later show to ask you about the differences and similarities between being a chef and being a manager’s manager.
JUAN: So many.
JENNIFER: Yeah. Okay, we’re going to stay on topic and start with managing managers. So, you manage managers and you say that you do this primarily between Colombia and the US. Does this mean that all of this is done remotely or are there any in-person aspects to that?
JUAN: Sure. Right now, I work at a company called Splice, which is a music company with a tech team, is what we like saying. I’ve been here for about three years. I inherited a team of, I believe, five engineers. The first few months scaled that organization to up to 55. And how we did it, it was by building a distributed organization. Splice engineering works 100% distributed. We are distributed between the United States and Latin America. So there’s a few folks in Colombia. There’s one folk in Uruguay. The organization has been built and designed to operate 100% distributed. Even the folks who are in New York work remotely. Some of them have desks. Everyone except for me is considered a distributed or a remote employee. I do have to come in, or not have to come, but I prefer to come to the office every day. I don’t have a good place to work from home. So, that’s a little bit ironic. We’ve built management that operates in a distributed manner. We’ve built our teams to operate in a distributed manner. And our product team has been localized in New York and has gotten used to working with our engineering organization in a distribute way.
JENNIFER: Just to kind of get a sense for it, what about timezones? About how many timezones does your entire organization span?
JUAN: Not that many. That has been the primary constraint that I’ve put this time around. We operate primarily in American timezones. So we span from US West to US East. I think there’s four timezones in the US if I’m not wrong. Colombia is the same timezone as New York or US Central, depending on daylight savings, but the time in Colombia doesn’t change. And Uruguay, I believe, is an hour. I think right now, it’s Eastern and maybe sometimes they’re an hour ahead. So, fairly standard.
JENNIFER: Yeah. So you don’t have to worry about people being asleep in the middle of your workday.
JUAN: I’ve learned the hard way that adding timezones is one of the most challenging things, especially when you’re a small organization. So, I try to do the [third] as much as I can.
JENNIFER: You said your team is about 55 people. About how many managers are there out of that?
JUAN: Splice has about eight or nine managers. We’ve divided our team into two sections, product engineering and production engineer. Product engineering comprises our main business lines. So our sound store, our plug-in store, our studio collaborative app. We have a small machine learning team and our growth team. And then production engineering has SRE, QRE, which is Quality Reliability Engineering and developer experience. So, I have a Director for Production Engineering. I’m looking for a Director of Product Engineering. And then, these folks have, I think, in production engineering, we have like three managers. And in product engineering, we have four or five.
JENNIFER: And then across all of your managers and the engineers, how do you all stay in touch, given you’re all distributed? Do you do things a synchronously by text, by video calls or meetup in person?
JUAN: That’s a great question. I think the most important thing to figure out as a distributed organization is the communication channels. So, this all comes down from a few principles or philosophies I have. First of all, I don’t think that distributed teams or co-located teams are better than each other. I just think that they’re different. And I prefer relying on distributed organizations because it means I have to get communication right upfront. Otherwise, I won’t be able to scale the org. I never have been in a position sometimes where my team doesn’t fit the office we’re in and then we split into two offices and we suddenly became distributed. But all our communication patterns broke down because we can’t be in the same stand up or something like that. So now, I’ve learned to just build it in from the start.
We use a collection of tools to communicate. But more than the channel, the purpose is what matters. So for planning or things that require a lot of interaction, we usually use Zoom for calls. We also use chat like Slack to stay in sync. Big decisions or like important information happens through email. And our iterations are run using a tool called Clubhouse. That’s where we manage our cards and our products. That’s sort of the tracking system. Usually our philosophy is default to a synchronous communication as much as you can, so we can protect focus of engineers. No one should be expected to stay 100% up-to-date on Slack. I like saying that Slack is for gifs, but not for announcements or mission critical information. And I do this for my organization. I set the expectation that if there’s anything important, it will come through email. And I do expect people to be eventually consistent on email. I don’t expect people to be eventually consistent on Slack.
JENNIFER: Why is that so important to have that distinction between eventually consistent on email but not on Slack?
JUAN: I think it comes down to focus. If you’re always worried about missing out about discussions or announcements or things that are important to the company that happen on Slack, then it’s going to be very hard for you to be putting all your attention towards maybe solving a very difficult bug or finding where you forgot the semicolon. Just like there’s deep focus building software requires. And I think it is counterproductive to have this sense of missing out, like fear of missing out. I, for example, am a person who like to get notification anxiety. So if you send me a message and I see a little dot, I have to read it. So I’ve set up my system suite ‘not receive notifications’. The dot [inaudible] show up and I choose when to look at things. And then my organization is set up in a way where if there is something critical, like we’re down, I’ll get paged or someone will get paged. And if someone urgently needs me, they know that if they text me then that is mission critical, but Slack will be off. And I like that sort of control for everyone in my org.
JENNIFER: Yeah, it’s almost like you’re setting up some social rule sets around filtering, so that way people don’t need to all do the manual filtering of Slack to figure out what’s important or not.
JUAN: Right.
JENNIFER: That makes sense to me.
JUAN: There is some guidelines and expectations. It starts getting trickier when you start collaborating with other teams. I don’t have the authority to set collaboration rules for the entire org, but I do set expectations. So, I do let people know on the product or design or other orgs, like, “This is how we work.” It helps in many cases to define membranes for interface. For example, the product team uses Asana to plan and to discuss and have more product focused work. And then we use Clubhouse for iteration management. So, we know that if they’re stuffing us on other we’re not looking at, we don’t have to worry about it. It may be some work that the product team is really researching or discussing and it may be a roadmap or a plan, we can go look at it. It’s open for us. But we don’t have to be on it every day. We do have the expectation that if the product team, the design team, the CX team needs something from us, they will create a ticket in Clubhouse. And it will be like a very explicit sign like, “Hey, we’re here to work together. Engineering, this is for you to pay attention to.”
JENNIFER: Okay. So, almost like you’re setting up [links]. That makes sense.
JUAN: Correct.
JENNIFER: I want to switch tracks for a moment and dig in a little bit more on some ideas around managing managers. And one thing I’m thinking about is, as someone who has managed engineers in the past, both remotely and in-office, things that I would look for around if someone was having trouble would be how they kind of felt and looked in the office. And then for my remotes, I would rely on our one-on-ones to get a sense for how things were going. And I’m wondering how you do that when you can’t possibly have one-on-ones with 55 different people. And so, what are things that you’ve noticed that you look for with your managers and with your engineers?
JUAN: What happened in Splice is I’ve had the fortune of scaling the entire team right. I think I directly hired the first 30 people. And that gave me an opportunity to build relationships with every person. You’re right, I don’t have one-on-ones with everyone. I think I go try to do skip levels once a year with everyone because we are a decently sized team. But now, I’ve set a few expectations for my managers. I do expect them to carry one-on-ones, to have the closest or the most up-to-date sense of progress or the state of their teams and their individuals. Then I also stay up to date.
There’s a series of meetings where I follow up with the progress on the actual teams and how they’re doing. So we have product reviews where like every two weeks, teams come in for strategic discussions or information. And then I have a couple of tools that I’ve used in the past. I always have a public channel and a private channel on Slack for my team. Public channel is called Engineering Team. Anyone can join and take up what we’re up to and ask us questions and just see what we’re doing. The funny thing is, I usually start a practice of saying good morning every day in that channel. And then it picks up. Then it becomes a team practice, so everyone in the morning says, “Good morning.” And that starts some fun conversations and it becomes really, really friendly. At least you feel like you have a workplace. And then I set up a private channel, which is everyone who directly or indirectly reports to me, has access to this channel that is called Juan Team. And they get a chance to ask any question in that channel about absolutely anything. And I also do the same. So every few days, I go and say, “Hey, how’s everyone doing?” Some people start conversations. I usually see questions like, “How was the weekend?” “When was the last time you took vacation?” Or, “What do you think about our objectives for the core?”
I do try to maintain some sort of connection with everyone. I will say I hover on Slack a lot. I will accept this. I’ve gotten a lot better not interjecting or jumping into conversations, but I usually do use Slack to measure the temperature of the teams. I usually join channels too, to see how the team is doing, watching out for interactions that I should keep an eye on. But now I’ve gotten a lot better at not getting directly involved, but rather just putting managers towards these things. Slack is actually very useful for that. And I do keep an open door, an open Slack door policy for anyone. In the cases where folks don’t feel comfortable approaching me, I usually tend to reach out to them individually when there’s big changes, big announcements. Things that I know of particularly, I might just send them a DM, “Hey, how are you doing? What do you think about this? Do you have any questions?” And then the skip levels are really good.
I think the best tool I have is other individual contributors, like having good relationship with a few engineers on my team who feel comfortable sharing, in many cases anonymously, how some of their team members may have perceived company direction or announcements. And they just go like, “Hey, there was someone in the team who I’m concerned about. You should know about this.” That’s been very, very helpful in having really strong relationships with them, and that way has helped a lot.
JENNIFER: How did those things come up? Do people volunteer them in your skip levels or come to you privately? Or does it come up in the middle of a conversation?
JUAN: It’s a combination. When I run my skip levels, I set a list of questions ahead of time. It’s usually like, I think it was eight questions. It ranges from, can you tell me something I should stop doing, start doing or continue doing? Is there someone I should be paying particular attention to? How do you understand your goal? There’s a series of questions that help me identify patterns in what I’m looking for. There is usually surprises. I considered I usually have a really good idea about the team, but it’s not 100 people yet. So, I do know what everyone is working on still. If I hear things that I wasn’t expecting, that’s when I try to dig in. But usually, the teams tend to have a really good idea about projects that are challenging. And they raise those things like, “Hey, I think that this project is going to fail. The objectives are not clear. We have a lot of technical debt.” I expect that to come up with everyone who is close to that team or close to a person that is maybe struggling with something or need some support. So, that is a tool and that is helpful.
And a few other ways, there’s folks who I’ve worked with in the past who come from previous teams or my friends before working at Splice together. We have a strong relationship and then they feel a little more comfortable sharing difficult questions with me. There is a pattern that I have. I’m not a fan of anonymous questions, but I am a fan of questions, I’m not a fan of anonymous questions. But I also understand that not everyone feels comfortable asking things. So what I usually encourage people is this is a space for questions whether we are in a call or in a Slack channel. If you don’t feel comfortable asking the question, give it to someone else who will ask me about it, who will forward it to the manager. We will anonymize this question in the process. And then it usually ends up making its way to me and then I can address it. Usually what I found is when one person has a question, there’s 10 other people that have the same doubt, but it just helps me surface those things. So what I’ve noticed is when there’s periods of silence, especially in a distributed team where the information flows primarily through back channels, through like the DMs or small groups, the message tends to get distorted. And I have to take control of the narrative. “This is the context of why we made this change.” Or, “This is the context of why we made this decision,” or, “This is why you haven’t heard from me for a while.” That has happened sometimes.
JENNIFER: We’ve got time for me to dig into one little part of that that I’m very curious about. I like the idea that you gave of you identified problems, but then you delegate taking care of those problems and exploring them too, to your managers or to the managers who report to you. And one thing that I’m wondering is how you know when to stop digging in and when to hand something off, and also how you can tell if it’s something important or if it’s not going to be important, but it’s just someone complaining for a moment. But they’re fine once they’ve gotten it off their chest.
JUAN: That’s a two part question and I’m going to answer the latter part first. I like encouraging my teams and individuals on my team to express themselves, to complain. I think that’s even in the topic of the private channel that I have, like this is the number one spot to complain. Complaining doesn’t mean that I will take action unless you tell me to. Complaining means like, “Hey, I want a space to get something out. This may not be a problem. I just want to get it out there.” When I observed these in the wild, people are not just coming to me with challenges. There’s a couple of things that I use to understand if it’s working. First, if it is an interpersonal challenge that has been ongoing, then I consider that as important. When two people are not going along well, and it’s been going on for a few weeks and it hasn’t resolved itself, then it is important for someone to get involved. The first time it happens or somebody disagrees or something, that’s fine. People working with people experience this. So I also don’t overreact. But if I’ve seen a pattern more than a few times, I raise that to the manager. I used to be very quick to get involved and respond. But now and I think that’s been the biggest sort of challenge in the scaling of this team and learning when to step back is now I see problems and if the channel is not the main engineering channel, I do not get involved directly.
JENNIFER: Do you not get involved because you’re waiting for your managers to get involved instead? I’m wondering what drives that decision.
JUAN: Yes, it is because I have to give the space to both the manager to gauge whether it’s a problem or not, and decide how they’re going to solve it. We all have different ways of managing teams and individuals. It’s more of a sign of trust. I can’t undermine managers, I can’t hover and just interject in every discussion that the team has with my opinion. It is not my job. It was when I was a manager. Now, I am running an entire organization, I should think where my attention should be going to and I shouldn’t be the one that is solving all problems. I need to trust that the folks who I’ve hired for that job are capable of doing that in the same way or even in a better way than I would. And the second part is that I don’t always have all the context. It’s very easy for me to jump into conclusions about what I may have seen or discussions that I may have had, and sometimes I embarrass myself by thinking I know what I’m talking about and I don’t. So that’s also one of the reasons why I’ve stopped.
JENNIFER: Yeah, that’s a good reason.
JUAN: Going back to the second part of your question, the only time where I will interject immediately is when there is something in collaboration, like risky. I haven’t had to do it on the scene, but it is something where there’s a potential for harassment or abuse, or something that’s just really, really bad. That is when I just get involved. I haven’t had to do it. But the other question is, I’ve just stopped doing it because it is no longer my job. So, I now default to had to get off and I no longer consider that I have to make that judgment. I just say, like, “Okay, there’s a team that is struggling or there’s this conversation happening with your managers. Here’s the Slack link or here’s a ticket that I saw. Just wanted to bring it to your attention. Let me know if there’s something I can help with. I’m going to consider that you’re handling unless you let me know that I should get involved.
JENNIFER: Wow. It sounds like the biggest takeaway I should be coming from this conversation with is when when you go from managing to managing managers, you have to know what your job is and what your job is not, and always be checking yourself in that area.
JUAN: Absolutely. Especially if you’re growing into it. I think it’s much easier to come into a job and understand what your job is. Like, coming into as a director of engineering, where you know there’s managers and you already know their stuff. And I just have to focus on maybe the technical strategy or something like a little bit longer or [inaudible] a different way. It’s easier. But if you have gone from like a line manager to a senior manager, and you’re suddenly managing managers, even though I’ve been – before Splice, I was VP of Engineering at a different company, and I had also built this. Starting from scratch makes me forget about what my role was supposed to be and realized my job has changed every three months every time an organization is growing. So, recognizing what my job isn’t anymore and recognizing that I am handing off these responsibilities so that I can start looking further ahead is very, very important. There’s also a time where you go from as a line manager, your primary role is to support the people who report to you. As a senior manager, you’re supporting your managers. But there is a portion where like right now, my expectations for the folks who report to me is they are supporting me and not the other way around. They are helping me lead the organization, drive the strategy, set the planning. And the management relationship flips when you start stepping into executive leadership. I need their support and not the other way around. And that’s also how I manage my relationship with principal engineers. There’s some principal engineers that report to me, and my expectation is they are here to make my job easier in running the organization and not the other way around.
JENNIFER: That’s like an entire topic I feel like we can dig into in a completely other episode that’s going to be different from the comparing and contrasting being a chef and being a manager of managers. We are completely out of time, but this was incredible. Thank you so much for sharing this. If people who are listening want to keep asking questions and continue this conversation, what’s a good place for them to reach out to you?
JUAN: Sure. I love answering questions and [inaudible] out on all this stuff. They can find me primarily on Twitter. My Twitter is my last name, so it’s @buritica. I tweet about distributed leadership [inaudible] hardcore punk. So if they’re interested in that combination of things, they should definitely check it out.
JENNIFER: All right. Sounds great. Thanks so much.
JUAN: Thank you, Jen. It was a fantastic time.
JENNIFER: Thanks for listening to Storytime with Managers by Cohere. Our theme music is by Kevin MacLeod, and we are edited by Bryant from Zinc. If you like this episode and want to hear more, tell us on Twitter. We are @wecohere.
