Skip to content

Episode 24: Designing Team APIs as a manager of managers and more with Jess Mink

    Guest Biography

    Jess is passionate about building strong, productive technical organizations that are focused on outcomes. While some people are fascinated by architecting code Jess loves to understand and debug human systems.  Developer tools and health tech companies speak to them and despite seeking engineering roles they have a habit of taking on product roles when needed. They’ve worked at companies such as Auth0, FOLX and Amazon and held roles from Director of Engineering to VP of Product.  They are currently Director of Platform Engineering at Honeycomb.io.  In their spare time they volunteer doing Search and Rescue.

    Social media links:

    Links and mentions

    Transcript

    Patrick Kua: Hi everyone. Welcome back to the Managing Managers podcast. Today I’m really excited to have Jess Mink. Jess is passionate about building strong productive technical organisations that are focused on outcomes. While some people are fascinated by architecting code, Jess loves to understand and debug human systems. Developer tools and health tech companies speak to them and despite seeking engineering roles, they have a habit of taking on product roles when needed. They’ve worked at companies such as Auth0, FOLX and Amazon and held roles from Director of Engineering to VP of Product. They are currently Director of Platform Engineering at Honeycomb.io. In their spare time they volunteer doing search and rescue. Welcome to the podcast Jess.

    Jess Mink: Thank you! I’m so excited to be here.

    Patrick Kua: It’s really great to have you on the podcast and such a really rich history. Lots of different roles. Lots of different companies. So very excited to get into that and also very wide range of interests. Love that. Maybe you can give us a quick overview of your journey in tech so far.

    Jess Mink: Yeah. I got lucky. I ended up at a magnet school that was tech-focused in high school. Oh, I’ll go to college for that. Once I figure out what I want to do it’ll be great. Programming’s fine. Then went and worked at Amazon. Didn’t love it. Went and worked at a startup. It was okay. But I was realising people are really the part that speaks to me a lot more than the coding. So after that I worked real hard and I was able to get a management role with some great sponsorship and then life got wild. I happened to know a physician who was starting a startup and he recruited me originally to be CTO and then at the last minute it switched to VP of Product which I was wildly unqualified for. So that was a wild ride to go from my first time being an engineering manager to being a VP of a department I’d never been a member of before. Then from there I went to more traditional director of engineering type roles. So I’ve had 3 different director of engineering roles that are all really different.

    Patrick Kua: Wow. That’s really fantastic and great that you found your calling, I guess, dealing with the people. We need more people who think about that in tech. Not just the tech but also have that tech background. You also bring this unique perspective of bringing in product which I’d love to explore in this podcast as well. Given that you’ve had a number of different roles, can you remember when you first started managing other managers?

    Jess Mink: Yeah. In that VP of Product role at Call9, I technically was managing other managers but they only had one employee, so it wasn’t really deeply managing other managers. The first place where I got to do that in a really deep way was at Auth0. I had 5 different managers with 7 different teams and they were almost all first time managers. So it was a really interesting challenge.

    Patrick Kua: Wow! Very exciting. I could imagine those people probably would have needed a lot of support. Was there any surprises for you in that experience, the first time managing five first time managers?

    Jess Mink: Oh my goodness. So many. So many. First, how much I could trust my instincts. Another is how little control you have. You’re both coach and accountability at the same time and you have to really think about what’s the API you need a team to provide you? And being really crisp about that. And then how much flexibility are you going to allow in implementation and being really clear about that. I think really helps a team know where they can innovate and what the guidelines are so they don’t get frustrated trying to change things that they can’t or feel they can’t change things that they could.

    Patrick Kua: Amazing. I love the way that you use the term API and implementation. I’d love to delve into that. But firstly let’s talk a little bit about the five first time managers because I heard you say, trying to find the right level of detail or interface but also there’s going to be differences amongst the managers that you had in terms of, I don’t know, style or preferences. How similar or different were they and how did you deal with that – the set of differences?

    Jess Mink: There were definitely differences. They weren’t completely across the map. But they were definitely strong differences. They were each facing different challenges. Whether it was being a brand new manager and building confidence. Or not having as strong of a technical background. Or being really worried about politics of the company and being really caught up in that. Or having trouble building confidence in senior leadership or communication or poor performers on the team. Each of them had a different challenge they were working through.

    Patrick Kua: All right, great. Then let’s go back to this API. So I mean you’ve managed managers for quite some time now and you did say part of the challenge is defining your API with a manager. In that context what do you mean by an API and can you give us a concrete example?

    Jess Mink: Yeah. So if you think about why we have a company. We have a company because we want to do something that’s bigger than an individual can do. Then we have multiple teams because we’re trying to do something that’s bigger than a single team can do. So we need to structure it so the teams are all working together towards a common goal. Which means interoperability between the different teams is super important. So certain parts that I would consider part of the API is: Where is your work visible? How do new projects get proposed? How does code reviews work? All those things that impact other teams. So that people know how to operate in the space and they don’t need a personal relationship with someone on that team to be able to collaborate effectively.

    Patrick Kua: Great. Yeah. I love the use of that I can see some of those thinking organisationally. Maybe the influence on Amazon as well in terms of interfaces and data contracts first.

    Jess Mink: I left there pretty quickly. It was not for me.

    Patrick Kua: Just good design principles. But the other thing I heard was around the implementation detail. Because I’m sure you’ve got opinions and preferences about how people implement certain things. So is there anything where you give either very strong guidance or things that you like to encourage in your engineering managers?

    Jess Mink: Yeah. Having a retro every two weeks is something I really really strongly recommend because that’s the way that you build that feedback loop and the team can iterate on their own process. You don’t ship something and walk away and never see what the impact is on customers. You need to keep iterating on your team’s process. That’s how people on the team feel they have agency and they understand why the pieces are there. So that’s a thing that’s arguably in implementation detail. But I really really strongly advocate for them.

    Patrick Kua: I’m a huge fan of retrospectives. So I love it.

    Jess Mink: They’re so Important. It’s an oil change, right? If you’re doing them a lot, they can feel boring and nothing real comes up. But they bring the things to the surface and they also build a culture of bringing things up and understanding that there’s agency. So they’re just so critical that way.

    Patrick Kua: Absolutely.

    Jess Mink: Another implementation detail that I feel is important is knowledge sharing. I think it’s really important to make sure that people can go on vacation. If only one person knows a system they’re going to have a hard time stepping away. Also people need to learn to feel good in their job. You want to make sure you don’t end up in a situation where the longer someone’s been at a company the more toil and maintenance work they’re doing because that’s just encouraging people to leave. So there’s a lot of different reasons why knowledge sharing is important for organisational resiliency.

    Patrick Kua: Great and I love that focus. I can imagine some of that tension because a manager might be going, oh it’s easy because that person knows it and it just gets it done. But yeah, there’s that risk and the other consequence that you’re always managing against.

    Jess Mink: Yeah, whenever you have only one person who knows how to do something and you keep throwing those types of projects to them I think of that as taking on organisational debt. Just like you can take on tech debt. Yes, you’re moving faster in the short term but you’re setting yourselves up for long-term pain.

    Patrick Kua: Absolutely agree. Let’s explore a little bit more about that first situation with the five first time managers. That’s kind of a unique situation because you know everyone needs support. How did they end up in that role and how did you support them?

    Jess Mink: Yeah. They were a little late hiring a director. Which is fine. That’s a thing that happens. Either companies are late or early and they’re usually late because you’re facing this. Do I hire someone who’s overhead, or do I hire someone who can actually code? And move the product roadmap forward. So the product roadmap usually wins.

    Patrick Kua: Always does.

    Jess Mink: Yeah. Yup. Each of them needed different support and they weren’t all successful. Most of them were. So there was a certain amount of setting expectations. I focused a lot on setting them up as a team. We worked through the 5 dysfunctions of a team as a group. I had them meet without me once a week too to talk through problems and peer support each other. I did a lot of trying to identify different people’s strengths and weaknesses and set them up as coaches for each other on those strengths. So if you think of just setting up a coaching relationship. Person A is person B’s coach, that implies a power dynamic. But if you say person A is coaching person B in communication and person B could actually be coaching person A in technical vision. That really helps identify people’s strengths and weaknesses and how to lean on each other. So I set up this network of coaching between the 5 managers as well including external resources too. But I worked really hard on setting them up as a cohesive team and they actually still all talk to each other and have a signal group together. It’s great.

    Patrick Kua: Oh, that’s great. That’s an amazing result and I can see the acknowledgement of strengths or weaknesses. But also focusing on building that team which sounds like it was very successful.

    Jess Mink: Yeah. And then since they were all first-time managers I did a little bit more top-down. I was like, each of you are having a retro at least once a week. Each of you are putting your work on the board. Each of you are implementing a certain amount of pairing. Everyone’s working on the same project. We’re not going to have a project per person. Then what I did is I looked at basically where are the fires? Who needs support right now. Then I did either a lot of coaching. A lot of reading the slack channel. Sitting in on meetings. In some cases I actually temporarily took over the team and had the manager shadow to see how it worked. If I really needed to swoop in a sudden way. I don’t recommend that but in an emergency it can smooth things out and buy someone more time. So there were a lot of different strategies depending on what each person needed. It was a bit wild. There was a lot. It was a lot going on at once.

    Patrick Kua: Yeah. I can imagine. But I could also imagine with the right sets of people they could also see tremendous growth in everyone at the same time.

    Jess Mink: Absolutely. And I think in that role I had a product partner and each of the managers had a product partner. So I also did a lot of really clear collaboration with my product partner. About where I thought each team was and what they were working on. So I was able to also get her perspective and her guidance on what she was seeing. Because different roles are going to be able to gather different types of data.

    Patrick Kua: Absolutely. I heard you say that you provided external resources or support as well. What were some concrete examples you were thinking of?

    Jess Mink: So books and articles are easy ones. Suggesting conferences is a good one. Either here’s a link. Go look at the Lead Developer. I’m sure they have a talk about subject x right? Go watch it. Or let’s get you a ticket and you can go. So different levels of investment depending on the time and the budget at the moment. I currently have someone I’ve got set up with a coach. I also like to set up cross-org relationships if someone’s working on… say someone really is trying to gain more business context and I know of a salesperson who’s really curious about what’s going on in engineering. Pairing them up can really help with getting a broader picture for both people.

    Patrick Kua: Fantastic. That’s a really great concrete set of ideas and examples and also a wide variety of different resources that you can support your team with that mean less work for you to a certain degree.

    Jess Mink: Well. Each person learns differently. So I think it’s important to see people’s learning style and what resonates for them.

    Patrick Kua: Absolutely. Totally agree. You were just talking about your product counterpart. So maybe that’s a good time to segue into your experience because you’ve played a number of roles. So let’s talk about the VP of product role that you were responsible for the first time. Can you talk about that experience? I heard it was a surprise. How did you fall into that? What were some of your expectations or expectations of the role?

    Jess Mink: I was wildly underqualified for that role. I’m just going to put that out there. There are roles that maybe you should say no to. It was really good for my career and I learned a lot but I think it maybe would have been more responsible for me to say I’m not qualified for that role and I’m happy to take the CTO role and help you find a product person. But yeah, what I ended up being responsible for was product which, to give some context, this company is a healthcare care company. Was a healthcare company. They’re providing emergency medical support for people in nursing homes. So there were paramedics on site and ER doctors working remotely using telemedicine. The idea was to provide patient support to people so they didn’t have to be transported to the ER because transporting especially a really elderly person with a lot of comorbidities does not have good outcomes. It’s really really traumatic for someone to be taken out of their environment. Not necessarily get the meds and water and food they need on their on a current schedule. There’s a lot of disorientation and a lot of long-term effects of that. So we were working on safely providing higher level medical support on location. So it was an incredibly high-stakes role. We did a lot to make it safe. In the early days the CEO, who’s a doctor, actually was on location. So if the software broke he could run up the stairs and treat patients.

    Patrick Kua: Wow.

    Jess Mink: So there was a lot of figuring out how to do things safely. When we iterated on the process we usually had a second doctor shadowing so that if things started to fall apart or fall between the cracks they could jump in and take over. So there was a lot of figuring out how to build safety nets. A lot of my job as head of product was coordinating with the doctors and helping them figure out how to safely run iterations on their process. So some of it was the software. But some of it was working with ER doctors and shadowing ER doctors and thinking about what they needed to be more effective. How are they taking notes? What’s their process like? Does it make sense for a nurse to do this part? Like obviously I wasn’t the one making the final calls there because I’m not a doctor. The doctors were. But they’re not used to necessarily thinking about how to change things at the rate that software people are.

    Patrick Kua: Wow. What a learning experience. It sounds like both a fascinating product and a very helpful product. But also such a great learning opportunity for you from a product perspective.

    Jess Mink: Yeah. I actually had 2 other teams. I had the data team and I also had the process/design team which went around and helped departments that were having trouble scaling with the rest of the company. And also took on special projects. Like working with finance to figure out how to get to a profitable unit model. Those things that just different departments didn’t really have the bandwidth for.

    Patrick Kua: Wow. It sounds like a little bit of operations stuff as well.

    Jess Mink:

    Yeah. It was a weird mix of COO and product. Which was a lot at that stage in my career but I definitely learned a lot.

    Patrick Kua: It’s very rare that people, particularly managers in technology, get to see those other disciplines so closely. Normally they’re working with a counterpart. How do you think that has shaped perhaps when you manage engineering teams today?

    Jess Mink: Yeah. I think it brings me to the big picture a lot more. Whenever I did demos at that company in particular I was instructed to start with the company mission. Then all the way down to what’s the point of this change. Company mission. Current goals. What was the patient pain? Okay, here’s the solution. I think that in particular is a really useful framing. It’s really easy as engineers to get focused on the details and lose track of the impact on the larger business and the end user which fundamentally is the reason there’s a business hopefully. So I think that’s the biggest thing. The other thing that was really interesting is being in board meetings and seeing fundraising rounds and understanding how much investors really… they care some about the story and they care some about the people. A lot of its confidence. But at the end of the day it’s about financial numbers.

    Patrick Kua: Yes.

    Jess Mink: And just understanding the level of detail the board cares about and what an executive team is accountable for is really useful in how to frame projects and how to pitch them and how to understand what’s likely to be accepted and not.

    Patrick Kua: Yeah, fascinating. What I’m hearing here, it gives you that exposure to be able to communicate better. Particularly across those organisational boundaries or outside of the organisation in the board case.

    Jess Mink: Yeah.

    Patrick Kua: Excellent. And in that role or when you’ve managed a product, I’m sure you’ve probably managed other managers outside of tech, do you think there’s any difference between managing other managers in other fields versus engineering managers in particular? One thing I heard is maybe the level of detail that engineering managers get into?

    Jess Mink: Oh my gosh. Engineering managers are the curious cats. Engineers… and this is something I’ve had to explain to so many other leaders. When an engineer is engaged with an idea, they’re going to try and pull it apart. An engineer finding all the holes and poking the edge cases and stuff means they’re really excited and they’re really into the idea.

    Patrick Kua: So much so.

    Jess Mink: That’s not how other departments work. They find that to be rude and disrespectful. And you don’t trust them unless you help explain that. So that’s a huge difference. Especially interfacing between engineering and the rest of a company.

    Patrick Kua: Fascinating. Yeah, absolutely. I can totally see that with people trying to almost disassemble things. To try to understand the inner workings or the understanding way. How do you work with engineeringing managers or to help them step back from that habit?

    Jess Mink: I mean, I don’t know if they need to step back. It depends on the audience. I talk to them about the audience and about what is the impact. Like what’s the emotional impact of what you’re saying. But also I work on giving engineering managers a ton of context. As much as I can. Because they usually are people who… not all. Some deal with… there’s different appetites for uncertainty. Some people are really comfortable with uncertainty and some people really need certainty. So that’s a thing to think about with how much information to share. Or how the information is shared. But I find that engineering managers really really want to know why more than almost anyone else I’ve worked with. Though everyone benefits from really having context to their work. But I definitely share just like, so you know this is going on over here and here’s what the implications might be, constantly with engineering managers.

    Patrick Kua: Fascinating. That’s quite a big difference then. Maybe let’s pivot to your current role then. So can you talk to us a little bit about what your current role is and what’s your current scope?

    Jess Mink: Yeah. So I’m director of platform engineering at Honeycomb. So I currently have 2 teams though that’s looking to grow. I’ve got the SRE team and the core services team. So basically responsible for reliability, performance, latency, scalability across the entire company. It’s especially fun because we sell into platform orgs. So my part of the company. The part of the company I work with, I should say, is our target customer at other companies. So I get to work with sales and CS and stuff for case studies and for understanding how the product is used and things like that. Because we use our own product really heavily internally so that’s a fun cross-functional tie-in.

    Patrick Kua: Great. Fascinating. Very technical and I actually forgot to ask and maybe you can go back to it.. maybe can you give us a short description as to what Honeycomb does as a product?

    Jess Mink: Yeah. Honeycomb lets you know what your system is actually doing in production so that you can quickly debug it. You can quickly get insights into how customers are using it. It’s an observability tool. Early in my career we got all our logs on a machine. You SSHed. And you used ack or perl or vim in terrible ways. Then you got tools that you stream the logs to and you can do searching. Now observability is the next step in that evolution that lets you solve problems much faster and fundamentally more accurately.

    Patrick Kua: Great elevator pitch. I can see the product hat there as well.

    Jess Mink: Can’t help it.

    Patrick Kua: It’s good. It’s very helpful. It helps you communicate very clearly. Maybe you can help me understand then who are some of your peers or the people that you work with across the organisation? I heard customers and clients a little bit.

    Jess Mink: Yeah. So my first team is the engineering directors. So there’s two other engineering directors and the three of us talk and hang out quite a bit. And then, obviously, my manager I talked to quite a bit. The VP of product engineering. And then I do talk to the director of product fairly frequently. I also talk to the manager of support a ton and the VP of customer success. Because I strongly believe that support is an ignored function that engineering usually is almost always better talking to more. The more powerful we make them the fewer escalations there are. Also they’re really amazing information around where customers are feeling pain. So just anything you can do to make that relationship smoother and more effective is going to make the entire company run a lot better.

    Patrick Kua: Yeah. I completely agree as well. When I’m working with engineering teams try to get them to even shadow or go listen to some of those customer support issues. It’s such an eye opener for a lot of teams.

    Jess Mink: Yeah. And whenever I can hire someone who has a support background especially from the company I’m currently at, that’s just straight gold. Because you can’t ask for more customer empathy than having had your whole job being talking to customers when things aren’t working well and seeing their confusion. It just completely changes how people approach the job.

    Patrick Kua: Spot on. Absolutely. And maybe concretely because I heard you say a lot so with your first team, are you talking to them on a daily basis or a couple of times a week basis, what’s the cadence there?

    Jess Mink: Yeah, we have face-to-face meetings through Zoom. Obviously. We’re all remote. Twice a week. Well 3 times a week now. But we’re also in a slack channel together and we’re constantly updating each other on projects or frustrations or insights that we just got. So that’s the channel I probably speak in more than any other channel because keeping that organisational awareness is super important.

    Patrick Kua: Great. And then in terms of the counterpart in product. How often do you touch base with them and what are the frequencies there?

    Jess Mink: Yeah, so because I have platform engineering I don’t have as much dedicated product support as I would love. So I would say I probably talk to him about every two weeks through Zoom and then I’ll slack whenever things come up.

    Patrick Kua: Got it. Excellent. Great. Yeah. So then let’s take a bit of a dive into your organisation or team. So I heard you say that you, I think, currently have 2 teams. So what are some of the activities that you use to run your organisation?

    Jess Mink: Oh so there’s a bunch of different cadences. I have an all hands every two weeks. Because it’s a small org. I think as it grows that’ll become less frequent. Because right now it can be a working meeting where the 2 teams are collaborating. And other people are often bringing and presenting topics. As the org grows those meetings tend to be more talking heads so they can be less frequent and more things are through slack. But as a company grows I think it’s important to convey information in a written form. In a video form. And cascaded if you actually need people to internalise it. So having some type of all hands meeting is really important. I also have a weekly meeting with just the managers. If they had product people and design people I’d probably set up some type of triad meeting. But since we don’t, it’s the managers. I also have a slack channel with the managers and our principal engineer. And the director of product though. He’s not often contributing a ton. We talk in there. Figuring out logistics and talking through questions and stuff that are coming up. Of course I have one-on-ones with the managers weekly and then I have skip level meetings with all the ICs monthly.

    Jess Mink: And for the managers one thing I’ve set up is I actually have tactical one-on-ones. And I have career growth one-on-ones because there’s so much more tactical stuff to talk about with managers than there is with ICs. With ICs, all your one-on-ones can be career growth because hopefully you’re figuring out most of the tactical stuff in your team meetings. But with managers you’ve got a ton of tactical stuff to talk through, so I actually schedule separate career growth one-on-ones.

    Patrick Kua: Totally makes sense. And can you give us some concrete examples or what are some topics that typically come up in the tactical one-to-ones with managers?

    Jess Mink: It might be, how’s each person on your team doing? What’s their growth edge? How are team dynamics? What’s going well? What’s not going well? It could also be cool, so this is the current project you’re working on. Looking at your roadmap. These are the projects coming up. Are those still the right things? What are you thinking the timing is on there? Who do you need me to coordinate with on other teams? Do I need to give this director a heads up that team’s going to have a project coming their way to support yours? Also going through, hey, our incident communication process needs to be revved. What do you think of these ideas? Here’s the problem statement. Let’s brainstorm some solutions. I’ll send you some docs. So there’s a lot of different things that can come up tactically.

    Patrick Kua: Makes sense. There’s some terrific examples there as well. So thank you for articulating them. As a platform group, I guess, a lot of your customers are other internal teams and so how much of your time is spent with other teams in your organisation?

    Jess Mink: Yeah, so I spend a lot of time with the other directors. And then I do have a monthly one-on-one with many of the managers in the org. We’re still a fairly small company. So it’s very feasible to know each of the managers personally. If it wasn’t, I’d probably pick a few key ones to have a deeper relationship with. And then work through the other directors for the other ones but as it is I can definitely meet with people regularly. I do try and let a lot of the things flow through the SRE team in particular has an embed in each team. So I will sit in on the syncs, where they discuss their embeds because they talk about what’s happening on each team and what each team’s needs are and what the dynamics they see are. So I’ll often listen to that and then I’ll check in with the director for that org and be like, hey, does this match your perception? And if not I’ll help them work on debugging that.

    Patrick Kua: Makes sense. I here you use a term embed specifically, so maybe for the listeners you can explain what do you mean by embed?

    Jess Mink: Yeah. So each product team has an SRE that’s assigned to it that goes to that team’s meetings. That pays attention to that team’s designs. That pays attention to that team’s on-call and their on-call health. And is that reliability and sustainability-focused person who’s not accountable to the product roadmap the way everyone else on the team is. And they’re still on the SRE team. There’s still SRE team projects that they’re spending a lot of their time on. But it allows for that relationship and that coaching towards operational excellence on those teams.

    Patrick Kua: Great. Thank you for that explanation. We’ve heard about some of the activities that your managers do through perhaps some of the tactical topics that come up in your one-to-ones. Maybe you can help us understand what are some activities that you’re responsible for that maybe your managers aren’t, so we get that understanding of maybe what’s different at a managing team level versus managing managers level?

    Jess Mink: Yeah, and so I want to be clear. There are many ways to be a director. The 3 different director roles I’ve had have had really different responsibilities and managing managers is actually a separate thing from being a director. The last director role, I was director of all of engineering but I didn’t have any managers because it was a small company. I joined as the fifth person. It was a tiny startup. And in that company my responsibilities were almost all cross-functional. Not down. Whereas at Auth0 my responsibilities were almost all down for the org I was managing. Here at Honeycomb, it’s more of a balance. So what the job looks like is really different in different places. So maybe I’ll go through Auth0, FOLKX and Honeycomb and tell you what the things I was doing that the managers weren’t?

    Patrick Kua: That sounds good.

    Jess Mink: Auth0. I was basically making sure the managers were functional. So it was a high-level overview. I had a lot of teams there. I was focused almost exclusively on making them successful. So does the manager have what they need? Are the people being successful? What is product thinking about how fast this team is moving? What are they blocked on? One huge pain point I realised in that org was that they had more ways to deploy code than they did teams. They had 12 or something. It was ridiculous.

    Patrick Kua: Wow, That’s a lot.

    Jess Mink: So I ended up going on this whole side quest with the platform engineering team and trying to get a consistent way to deploy code which is something the managers didn’t have to worry about at all. But I was, like, this is a systemic problem over the entire org. That means it’s my job to fix. Or whenever a manager had something bigger than they could handle, that was my job to fix. So at that company I was pretty tactical. Although I did do some strategy work with the CTO.

    Jess Mink: At FOLX it was a tiny company. We were going through a launch. We didn’t have a product out yet. So as a leader sometimes you have to decide in selective neglect. Because you can’t always do everything.

    Patrick Kua: Absolutely.

    Jess Mink: So I got there and I’m, like, cool, what’s the plan? And they’re like, we launch in six months. I’m, like, cool. What are the milestones? And they’re like we launch in six months. I’m like okay, who’s my product partner? And they’re like, there isn’t one. And I’m like, okay. So I purposefully did a minimal level of one-on-ones. I was really clear with people. This is not the moment I’m going to be pushing you on career growth. This is where we’re trying to go as fast as we can to launch this company. You’re going to have to yell and scream for what you need. I’m going to trust your technical judgement. The CTO will be focused more on the architecture. And then I actually ended up running all company meetings around defining milestones and figuring out how to do iterative development. And like what are the ways we can set up the code plans so that we have things we can test in front of potential customers as soon as possible? How can we de-risk? So I went with that direction, which is a completely different thing than the previous company where products set the roadmap and I was responsible for execution.

    Jess Mink: Then here at Honeycomb I’m doing a lot of what should platform engineering be? What does platform engineering mean in the market? What do the other departments need? What does CS need? What does sales need? What’s our scaling plan? If I talk to our COO, what’s the projected financial growth that we’ve told the board? What’s the ARR predictions? Then if I talk to sales and product, what does that mean for the way customer shape is going to change? What are our scaling numbers for all the different services we have so that I can give those to engineers so they can figure out what the projects they need to hit those are? so it’s a lot of really cross-functional cross-discipline work. Things that approach all of engineering or all the company. So supporting a manager and running the manager skill share. So all the managers can grow. Giving feedback on product strategy. It’s a lot of connecting the dots and also planting ideas. So that when a particular team is ready to execute on a project, everyone’s like, oh yeah, of course we need that. That’s a good idea, right? There’s a lot of behind the scenes work sometimes in being a director to just make other things go smoothly.

    Patrick Kua: Yeah, yeah. I love the planting seed idea as well because a lot of people on the podcast have talked about that long feedback cycle. It’s kind of similar is that you have to sow those things early if you want to have something green and beautiful later.

    Jess Mink: The feedback cycle is so slow. I think one thing people don’t realise earlier in their career is you actually get the most feedback as an IC. When you’re an engineer that’s when you get the most feedback and the most accountability. The higher the title you have, the less people can directly day-to-day figure out what impact you’re making and the more it’s long-term impact. So you get a lot less day-to-day feedback and have a lot less day-to-day accountability. But if you lose trust it happens all at once and there’s no recovering. It’s much more a binary thing in terms of whether you’re a successor or not.

    Patrick Kua: Agreed. Agreed. I think the three example scenarios of the different responsibilities give us a really good example of how adaptive these senior leadership roles need to be in terms of, sometimes, people might call it being glue and tying whatever the organisation needs together. One thing I heard within some of those stories was the ability to choose where you put your energy, because I think you can have 10 fires or 10 things that seem urgent and you’re going to, as I heard you say, deliberately maybe let one slide. What are some of your heuristics for deciding where you focus your energy and which things you accept, OK, we’re going to take a hit there?

    Jess Mink: I don’t know if I’m as structured about this as I wish I was. I think it’s the old effort versus impact, as well as urgency. But there’s also a relationship component too. If there’s an org I’m trying to build stronger ties with, I’m likely to do small things for them quickly because I want to build that feedback loop. So they know they can reach out. Whereas if it’s an org I already have a stronger relationship with, I can be a little bit more like, here’s my current priority list. Where do you think your thing falls? Help me. Also it’s a little counterintuitive but I’ve found there’s certain types of fires that you have to jump on faster the more senior your title is. If there’s a team dynamic issue you’re seeing as an IC you’ve probably got weeks or months to fix it. If you’re seeing it as a manager probably weeks. If you’re seeing it as a director you probably need to solve it definitely that month, if not that week. And then if you’re seeing it as a VP you should probably fix it, address it that day because if it’s gotten to you it’s actually a really burning fire and everyone’s at the end of their rope. So if you ever feel your leadership is reactive to stuff that feels isn’t as that spicy to you, it’s because they’ve learned by the time things get to them, it’s probably exploding and the rumour mill is probably going and if it’s not put to bed really quickly, it’s going to fester, badly.

    Patrick Kua: Yeah. I could definitely see that. And I’ve definitely seen that in many organisations of somebody turning a blind eye or hoping somebody else will address it but the need is there.

    Jess Mink: Yeah. Yeah, so I have different themes for different days of the week. There’s a day where I’m focused on the org I manage. There’s a day I’m focused on my peers. There’s a day I’m focused outward. There’s a day I’m focused on solo work. And there’s a day that’s for chaos. To try and help give focus and make sure each of the aspects get the attention they need. That’s not what actually happens. Because I’ll be like, oh, I need to hire a manager.

    Patrick Kua: Of course.

    Jess Mink: So I’m going to spend this week writing the job description in every spare moment I have. But having that intention helps at least to think about those different aspects and making sure that I’ve paid attention to them recently at least.

    Patrick Kua: Well. I think that is an important aspect of the aspiration to do that and have some guiding thing that helps you get there over time. But reality is always very different from the ideal.

    Jess Mink: Yeah. I think one thing that’s useful is it’s really easy to get stuck in day-to-day tactical. So having something that brings you out of it. Whether it’s a coach. Whether it’s a peer you talk to regularly. Whether it’s a group of peers. I have all of those set up. I meet with a friend locally once a week and we coach each other. There’s a monthly CTO roundtable I go to. I have a professional coach. I have one-on-ones with my manager. All of those help me step back and think about what I haven’t been thinking about. The other thing is the more you can trust your managers and the more you can delegate to them even when you feel like it’s stuff you should be doing, if you can delegate it, delegate it. Because there is stuff that you should be doing or could be doing that would be really high impact that you’re not seeing because you’re busy. The more you can open up time the more you’ll see other high impact work to do.

    Patrick Kua: Great. Yeah, fantastic advice there. I’d maybe start heading towards the end then so what advice would you give somebody who is making this transition from managing a team to starting to manage other managers.

    Jess Mink: Yeah. So remember that transition from IC to manager and how it felt. Maybe you would know how to do that job from watching someone for a while but actually it was a completely different job with completely different skills and success criteria and feedback loops. Yeah. It’s not quite that extreme. But it’s almost that extreme. As a manager your success is execution. As long as your team is executing well and everyone on the team is fairly happy. You’ve won. As a VP, your job is company success and strategy. So your org needs to function but most of your attention is sideways and to the business. With your first team which is the other execs. Then the directors. That managing manager level is this messy glue in between where you have to give feedback on the strategy and also work with other directors across the company to figure out tactical details that are cross-org. That are a broader perspective than the managers will have. And you also need to be mentoring the managers and making sure the individual teams are successful. So there’s a lot of different thinking. There’s a lot of different problems. And which one of those is going to be in the forefront is going to depend entirely on what’s going on.

    Jess Mink: You’re likely to have to step in and manage a team while doing all this other stuff at some point. Or have a manager who’s managing 2 teams and needs support. There’s just a lot of different aspects. So give away your legos. Delegate every single thing you can. Yes, the stuff the managers know how to do is the stuff you know how to do. So it’s the stuff that feels comfortable and successful and is going to give you that dopamine hit. But really really as much as you can, at least for six months, give it all away. Every single bit. Do only the things that you can do. For each item, be like, am I the only person who could do this? If the answer is yes, or maybe the only other person is your boss, then definitely do it. And if there’s anyone else you could give it to, just try. Just try giving it to them because there’s more work out there to do than you probably realise and you’ll start seeing it as you invest in those relationships and read those strategy docs and read the board deck and start internalising that larger company culture.

    Patrick Kua: Excellent. That is some tremendous advice there and lots of tips jam packed into that answer there. If you were to buy a book or some books for that new person transitioning into that role, what would be on your list?

    Jess Mink: I really like The Manager’s Path by Camille (Fournier). That’s a great book. Also if you haven’t already read 5 Dysfunctions of a Team, just go out and get it now. There’s a manga version. It’s really short. Strong recommend. The other book I think is useful to read at some point is Good Strategy, Bad Strategy. His examples are kind of terrible but it’s the best book I’ve found that describes what strategy actually is and what it isn’t. The company I’m currently at, Honeycomb, does a really cool thing where we do book reports. Where someone will read a book and they’ll write up a 1-pager of how it relates to the company and what they think we could learn.

    Patrick Kua: That’s a great idea.

    Jess Mink: So if there’s anything like that in your company, definitely spend some time reading those. As you get more senior the roles get bigger. And you can’t possibly do everything that could possibly fit in the role. So to some degree you have to figure out what shape you want to be and how you want to specialise. So I can’t tell you all the books you should read. But I can say start with those and then think about what you’re curious about and don’t be afraid to follow that.

    Patrick Kua: They are some terrific starting points for people at least and some of the concrete ones. I agree with the examples in the Good Strategy, Bad strategy ones. I do want to make a call out to Will Larson, who’s writing a book about engineering leadership management and I think he’s been writing a lot of good examples of engineering strategy there for folks who are listening. My final question for you then is we’ve had some great discussions and I’m sure people have some other questions, so if they were to reach out to you, what would be the best way for them to do so?

    Jess Mink: Yeah, Linkedin is probably the best place. You can find me there as Jessica Mink.

    Patrick Kua: Excellent. gGreat and we’ll make sure that your link is in the show notes as well.

    Jess Mink: Sounds great. Thank you.

    Patrick Kua: Fantastic. So thank you very much just for spending the last hour. I’ve really enjoyed our conversation. Lots of great insights and I hope the listeners have enjoyed this episode.

    Jess Mink: Yes, sounds great.

    Patrick Kua: Thank you.

    Leave a Reply

    Your email address will not be published. Required fields are marked *