This was a great conversation about human systems. How so often we over-focus on the technical systems we can build or put into place without considering the importance of how we organize our work, our interactions with each other, and how we use those technical systems to create a human outcome.

In the second half of the conversation, we got into the topics of the different types of organizational cultures, missionary vs mercenary mindsets, and how important it is as a leader to understand the context you're operating in.

What do you mean by 'the human systems that surround the technical systems'?

You know, there's the technical systems that we all know fairly well, as far as like the work we do. People with engineering backgrounds, people that build... that includes a lot of different people within the organization. Salespeople build, Marketing people build... that world is one where the feedback loops are pretty tight.

If I speak about a developer and what I used to do... if you fix the bug, you get instant feedback. You have a general idea at the end of the week, all the different things you did, how you added value and what that meant.

But that's not the only system that's at work. It's an important system, but not THE system at work. There is this other system that's in plain sight, but I think we don't spend enough time talking about, which is the dynamic system of humans in the organization and in the company that have to collaborate and interact together to do work.

And this system is very different from the other systems we might work with, whether they're financial or engineering, in that it's subject to unpredictability at times, it's subject to a lot of complexity in terms of the communication paths and people's behaviors, people's habits... telling stories, explaining narratives. There's just a lot that surrounds it.

There's been a lot of people Conway, for example, that has talked about the interaction between software architectures and the organizations that produce them and how communication paths are mirrored within the things that we build. So there's a lot of different literature about how those systems interact. But yeah, there's this big, really important people system that I think that, especially as technical people are people in the tech industry we're not as comfortable working with or talking about.

When you say this human system is "here in plain sight" -- do you think we can all see it but choose to not talk about it, or do we need to do work even to start to see and understand it?

I think we all see it per se. I think learning to influence it, learning to shape it, learning to work within it effectively towards ends like telling the story of what your team is doing, or, advancing your own career or organizing a whole group of different people as an executive towards one end... Notions like motivation. There's a lot of fairly abstract or complicated concepts around it. I think we all see it. I think we all know it's there. But I think there's a lot of fear and anxiety around what to do with it, how to influence, how to tell your own story.

And I think we have a lot of personal barriers perhaps that prevent us from participating within that system as fully as we want to. Butit's all very understandable. These are all things that... especially in all of our academic careers, there's not a whole lot of time spent discussing.

And I think maybe it seems like dark arts at times, but yeah, I think largely it's just fear and discomfort. And not fear because of lack of knowledge, but also sort of our inherent feeling that these things are unpredictable, that we're not sure what's going to happen. We're not sure how it's going to work. I think we're inherently uncomfortable with working with chaotic systems. So I think, yeah, all of those things maybe prevent us from participating fully within that context.

How can you create more predictability within a human system?

I think the one notion I usually go to is that of a feedback loop, which is a critical part of explaining these types of systems and how systems feedback onto themselves to generate different types of behavior.

The biggest tactic that helps bring some level of order, at least observability that's reasonable to these types of systems, even if you can't look several steps ahead is the notion of where your feedback loops are.

There's a lot of different, very tangible feedback loops that exist within an organization. Examples of feedback loops within the human domain that are that are interesting are things like conversation. And these seem sort of trite in a sense, but it's true.

We talk about it in tech as a one on one meeting, or channels and forums for ideas to be exchanged. And those are opportunities to ask questions about what people's state of minds are allowing you to make some reasonable opinions on where people's heads are at what you think they're going to do next, how you might need to help them. At a group level, there's all sorts of interesting tactics like retrospectives.

I don't come into this with a real hard line on process, just that, having some observability in some process, feedback loops in the system are critically important in terms of predicting where the team might go next. Well, we've done these things, these things are working really well. We really wish we could do these other things. And, you know, it's important now. So we take these improvements seriously as we go week to week, month to month.

And you can start to understand through that where the system might go and how you might nudge it in a direction you might want to send it, which is another important concept that I won't go too deep into right now, but the notion thatone should act as if one doesn't necessarily have complete control over that system, rather than implying that, you know, instantaneous and dramatic change can be can be implemented with a group of people in a system like this. So I'll talk about nudges a lot.

But if you talk about those different ideas, you can start understanding where the system is and where it's going. And I think that the guiding principle here is leaving yourself as a leader, leaving the organization open to possibility. Knowing that this is the system underpinning what we're talking about, that you're not ignoring the fact that some unpredictable things could happen. How would we react to that? And do we have some basic mechanisms and principles in place to allow us to reasonably respond to that rather than continually being surprised when things act chaotically, when you think they're going to be a very predictable linear sequencing of operations around activities like delivery or collaboration.

How do you anticipate areas of potential chaos, and how do you set up the organization so that it's able to adapt to those?

Just like anything I'll keep drawing these analogs back to things like software architecture. These are principles that work well in other types of systems as well, like not going too far, or not making too many assumptions at one time that may prove to be false and end up constraining you further in the future than you thought.

But from an opening possibilities standpoint its less about predicting than being open to things not going the way you think they're going to go. And this touches on concepts of the act of creativity and the act of inspiration.

Engineers and tech organizations and business organizations are inevitably as full of creatives as any other organization and that's how the mindset works, but remaining open to possibility allows for the system to optimize the answer.

Rather than someone that's inherently flawed, like any leader, like myself, to make broad claims of whether or not something is optimal or not. It's more about setting up the appropriate constraints, allowing the team, the people to react according to what they know, given that they're closer to the right information. And this gets into notions of autonomy and ownership. But it's allowing the system itself to react to change, coming from other systems, coming from within, rather than setting up a rigid strategy, which can take the form of a leader micromanaging or a group of people not feeling that they can respond or that it's gone off script and I don't know what to do.

So yeah, it's really just a notion of embracing the fact that maybe it won't go the way you think it will. And if that inevitably happens, whether by degree, small degree or large degree, that, you know, the system and the people within it will be able to react that appropriately rather than remain stubborn against what your previous assumptions were, fail to recognize the change or the reality of the situation, not bring their full selves or full creativity to the problem solving because they think they're working in a different system than they really are.

So yeah, to me, it's about remaining open to the fact that the chaos will happen. And it's really about how you react to it rather than how you attempt to control it for whatever reason at the outset.

What's an example of changing the system to create better results?

I can think of one example, and it kind of actually... the process can operate in both directions. You can go from the business constraint to the behaviors and back the other way. This one sort of operated in the reverse way. That's maybe a good illustration of how you can play with these different systems in different orders.

I was running P&L responsibility for an organization. And I think the biggest thing you want to do within a services organization is prevent escapes. And what I mean by an escape is a project that doesn't go well to the point where you are actually losing money quite significantly against that contract and against that particular gig.

And in general, I think what I've seen in that kind of vertical and the way of working is that most projects have outcomes in states that are largely clustered within some level of profitability. They're kind of around the middle. But every so often you get a black swan event, you get an outlier as far as it's negative implication or how badly it's going for various different reasons. That's always a struggle in any services organization I've been in.

And I think one of the biggest things that we saw is that we were observing in different projects that maybe despite everyone's best intentions and the right cultural factors there, that the results sometimes weren't happening or teams weren't responding fast enough to the right business stimuli.

And this is a situation we have a lot of different simultaneous teams working on separate contracts all at the same time. So as an executive, you're looking across all of these checking their health. You've got some wonderful ops and delivery people that are providing all sorts of context to this, but you're looking across the organization and the dynamic behaviorally to this, given that we want to eliminate these black swan events, is to figure out why they're happening in the first place and how do we prevent them?

And what we tied this to is that... it either resulted from poor initial conditions, which was not really relevant because we can work on kind of how we negotiate these deals. But the other one was teams weren't reacting fast enough or the feedback loop, as far as adjusting team size approach, changing requirements, constraints, other parts of the system that the team needed to work on... these things weren't happening fast enough.

Tying up a lot of conversation into a nutshell, the round trip to affect change within that context was up to somebody like me sitting in the VP chair and then back down to the team to say, "yes, you can do that, yes, that's a good idea," or "by the way, you're trending non-profitable right now, what are you gonna do about it?" Was problematic in a very long feedback loop.

So what we decided to do is we had all the model kind of at the top level... make sure that on a real time basis, each one of these teams had a view into their own profitability. So they can make decisions on a daily basis based on things that would steer them towards profitability, because that was our clear mission as the business. And they can change the behaviors accordingly.

So this was a situation where just giving the right context to those teams actually shifted the behaviors in the right direction. And it was a question of transparency around that.

And the result of that was that we, we removed those black swans. We suddenly had better profitability from these projects because the people closest to the action that could influence the behaviors of the rest of the team better were actually equipped with the right information and context to do that.

Instead of being forced to work in a rigid way in a very linear way, according to some other model of how that work should probably go. And going up to somebody like me to ask me if I thought something was a good idea or asking me what I thought about how the project was going right now, we just concentrated that context within the team itself.

And just that notion of visibility coupled with what had already existed as far as people's extreme accountability they felt already around the outcome of their project produced the right behaviors in terms of adjusting right away. Not coming to me for permission for these things, obviously keeping us informed of things, but introducing a bunch more dynamic behaviors around making the broader project a success.

So again another very concrete example of how transparency and maybe uncomfortable transparency from a business standpoint for some organizations at the team level actually produces better results for the entire company because you're giving those people the ability to navigate that dynamic system.

Links to Jason

• LinkedIn

• Website

• Substack

For another, after determining she didn't like Leet Code style interviews but still wanting to work at top tier tech companies, she found a different path, becoming a public speaker and using that as an alternate way to prove her abilities.

In this conversation, we covered a lot of ground, but the big theme that stood out to me was one around control. Figuring out what things in your career and job are in your control to influence, which are outside your control but worth fighting for, and which things to let go.

Note: As regular readers may have noticed, there was a substantial gap between the last interview and this one. Since starting a new job in the second half of next year, I have been struggling to keep up the weekly pace. For 2024, I will be dropping the pace of Human Skills interviews to once a month.

What is something you brought from art school into working in tech?

The biggest thing is how to take feedback.

I was one of those kids that like always did really well in school and didn't have a lot to like challenge me. And then when I got to art school, it turned out I was very bad at art. The only art that I was good at was watching cartoons. So I wasn't very good.

And then they had these things called art critiques where you would put your art at the front of the room and then everyone, the teachers and the students could say whatever they want. And they did.

So I got a lot of feedback that way. And at first it's very difficult, but I could see that they were right. So every week I would do it and then slowly, you know, after a year, I was pretty good. And after four years, I was pretty good as an artist. But it really helped me understand how to take constructive feedback and meaningful feedback and incorporate that into my work.

So then, when I decided to go into engineering, it was really important for me to find mentors to always seek out other people, always look at other people's code and see what they're doing. And that really helped me grow and not be precious about my work. Like the best work is what's best for the consumer, not for whatever you think the best is, right? So it's a lot of that I got from art school.

Are there particular things that go into being good at getting or handling feedback?

It's all about making sure that you get meaningful feedback. A lot of people give bad feedback, whether it's negative or positive.

They can say things like, "this is wrong", or "you're not working hard enough", which doesn't mean anything. Or they could say, "you're doing great, keep going."

Both of those things I've gotten from bosses and they don't really mean anything, and you can't take action on them. So I would always follow up and be like, "What exactly do you mean? Like, what do you think I'm not doing well here?"

I had one boss who was like, "you're just not getting these projects done fast enough. You're slowing everyone down." And what I did was I wrote down every single piece of the workflow and where the gaps were like, I was waiting for this person, I was doing this part. And he was like, oh, I didn't realize all these pieces were involved in what you were doing. Okay, carry on. Like there was no fixing what I was doing.

But it could have been that I was doing the wrong thing, I wasn't doing the priority thing. So it's all about the follow-up questions and not just accepting when someone gives you feedback that you just move on, right?

Because you always want to get good feedback that's actionable and then you can do better. Some of the best feedback I've got was like, "hey, you should try working on distributed systems. That's the future of technology. You should try that." And I was like, great. That's extremely actionable. I'll try that right now.

Or like "in your pull request, do only one thing at a time." That's what a mentor told me early on. And to illustrate that, he actually made me take my pull request and write in plain English every single thing that I was doing. And then when it got to a full page, he was like, "you see, you see how much you did in that pull request? I can't review this." And I was like, oh, okay, well now it's gonna be 10 pull requests. You know, things like that where it's very actionable.

On managing up

I think managing up has happened in every single job that I've been in. Where you don't always get stuff from your manager because they don't know what you want. So you have to ask for everything. You ask for the right projects, you see something coming, you volunteer to do things.

The number one thing I always think about for my manager is how can I solve problems for him? It's not about what I want, it's about what will make life easier for them and then tie it into what I want.

So you always phrase it as like, "hey, can I take this project off your shoulders? I really want the experience doing more machine learning, or I really want more experience doing project management, or I want experience doing a leadership thing." But you phrase it as, "I saw this is a lot of work, can I take it from you?" So that's always how I focus on getting what I want from my bosses. What can I do to make their life easier?

Do you have particular things you do to develop professional relationships?

Over time, I've kind of developed scripts that help me introduce myself to people and have conversations with people.

Because I know how difficult it is for people to just like go up to someone and start talking, right, it's a very dangerous scenario. I think for years, I was always like, I don't know what to say, I don't know what to say. And then I realized there's like five questions, you can just keep it in the back of your head, and then always talk about that.

There's the weather, there's the most recent holiday, there's the most recent weird thing your company did and you want to talk about it. There's what's on TV. There's like so many little things you can go to people and be like, "oh man, have you seen this? This is so cool." And then you can talk about or like ask about what they're doing.

And I think, you know, it'd be different for other people. I mean, I love TV and movies, so it's very easy for me to relate to people on that. But if there's other things that you love, like sports or video games, just have a question in your head to just talk to people and don't feel bad about being a robot that has a bunch of pre-programmed questions, because after you break the ice, you can just start talking to people about that.

And then later, you just remind them about that. Be like, "oh, remember when we talked about this movie? I watched the sequel. Did you watch the sequel?" And just try to remember. And if you have trouble remembering, use technology. Write things down. Remember, oh, that person, I met them there. And this is their name and their pronoun. And they like watching Love Island. So that's something I can talk to them about.

So it's just a way, you know, to just connect with people as humans and make friends really. And even if you don't have a ton in common and they would never be your best friend and you never invite them to dinner, you can still find at least like one thing you both like, even if it's like sunshiny days.

On using scripts for getting out of bad conversations

I've had really bad conversations that have taught me what not to do, I think. Like I've had conversations where someone starts asking me very personal questions very quickly and it turns into like this interview and then that's where I bring out my other set of scripted answers which is how to leave a conversation.

So I always carry a cup with me and I'm always like, "oh I gotta refill this"... that's really good or like, "oh, I gotta go to the restroom" and then you can get out of those conversations. In case you're in a really bad conversation, that's always good to have. I've seen people at events who are just like stuck and I'm like, no, get out. There's more people to talk to.

How do you change the topic when you're stuck in a conversation about something you don't want to talk about?

That definitely happens when I give talks about working at Netflix. So like when I give a presentation on my own work on the side, I can say whatever I want. When I talk about my job, I absolutely have to run it through our team at work to make sure I'm not saying anything bad and then the hardest part is the Q and A.

People ask me questions that I can't answer. I think that's a similar situation to what you're talking about. Like someone's saying things and you're like, I can't answer this, whether it's that situation or you're stuck in line and someone's saying something that you don't want to respond to, you just change a subject very abruptly and it's fine.

Or you just don't answer it and just say something completely different. It's something that politicians do all the time. I think it's very valuable to become a very observational person and watch other people to get those skills out of it.

A great example is I'm trying to be a better speaker and one thing that I coached on was to watch comedians and watch how they talk and watch how they move.

Use your physicality well, which is what really good comedians do. And then if you watch politicians answer questions, they just like say whatever they want.

Another scenario that works really well is in job interviews. So in job interviews, I have like five skills I want this person to know about, right? I know my audience. Whether it's a recruiter or a technical manager or someone else, I can see in my brain, they have like a checklist for the job and they want to know I'm a problem solver. They want to know I'm good at learning. They want to know I'm good at Java or whatever it is.

And then when they ask questions, I just answer what I want to answer. It doesn't matter what they just said. I'm going to give them my answer. And usually I talk long enough and it's the answer they want it anyway. So even if it wasn't the right question, you just give what you want to do. You can watch politicians do it all time.

And it's a great skill for interviews. Make sure they know all the things you want them to know. And then at the end, you still get the job. Well, at least you told them everything you wanted them to hear.

What other professions or specialties have you found particularly helpful to watch for skills?

I think marketing skills have helped me a lot the past couple of years. This is more of what I talk about in my keynote. It's all about branding and marketing and telling stories.

So like going back to my example of talking to my boss, I'm telling him a story. The story is "I'm gonna help you," but secretly it also helps me. It's the way you explain it. And people sometimes think that like their work will speak for themselves, but that's not true.

Everything you do is a story somehow. And if you're not controlling the narrative, it's controlling you and people are just gonna make assumptions about you or make assumptions about your work and like not understand how it works. So every time I work on something, I think about what's the story of this project? Who am I helping? What is the improvement that I'm making? What is the money I'm making for my company?

Because that's, unless you work for a nonprofit, and then you have those other goals. In the end, you have to draw the line between what you do and how it affects your company and how it's making them money. Because if you're not doing that, then why are you working there? What is your point of your job? And if you can't say that, then you're in trouble. Maybe not like today, but at some point, you will have that.

So learning a lot of marketing skills, I think it's been really helpful about storytelling and knowing your audience and things like that I think is beneficial to anyone in any career trying to make the best of themselves.

And I think it's even more important when you're not in the majority. Like being a woman in tech, I'm in the minority, right? So it's a, I have to put out my story about how great I am even more so, right? Sometimes it seems like I'm just like over the top, but that's what has to be done to make it happen. I've talked to a lot of people and it's more likely that someone in the minority is doing a lot of these branding efforts because they just want to shine really bright so that they're seen a little more.

On changing your communication styles to be better heard

I'm from Philadelphia, I'm from the East Coast. And when I moved to Los Angeles, people often said to me, "oh, you're very direct." Which I... you don't realize your dominant culture until you leave that culture, I think. And you experience other cultures. I always recommend people like move somewhere else, at least for like a little bit, just to like understand yourself a little better.

And when I heard that, I was like, "great, I get to the point, let's just talk about the projects." I just wanna get to the point and get back to work or get to the point and go take a nap. I don't wanna goof around with this. And that did not create positive relationships.

People took that in a way that I didn't expect. I thought people would like that I just talked about work and got things done. But people found me, I would say phrases like brash and abrasive.

And sometimes of course I wonder, is that me? Is that me being a woman? Is it like how society is? But I can't change that. The important thing is that I communicate to people in a way that they do the things or they hear me, they hear what I have to say. I want them to absorb what I'm saying. And if I could add an emoji after every sentence to get people to think I'm friendly, that's what I'm gonna do.

And I'm not gonna stress too much about it, you know? There's only so many stands you can take. And I think about what's important to me, and what's important to me is have a great job where I have a lot of freedom. And my coworkers respect me, and I respect them, and we get things done. And sometimes you just have to change the way you communicate with people.

I mean, people are human. People are gonna take things good ways and bad ways. And once you learn that, like, "oh, if I communicate a little differently, if I have a little softer touch, I can get what I want."

Some great advice that I got was, it applies to I think everything, "do you wanna be right or you wanna get stuff done?" And I think early career, I wanted to be great all the time because I'm right. But now I'm like, I wanna get things done because I want us to make money and then I make money. So then I can enjoy my life.

On ways to take control of your own career

One way I controlled my career is I hate leet code questions. I just can't wrap my brain around them because they're so theoretical. I love real world questions. You tell me you have a problem, I'll build an app in 20 minutes and I'll be like, oh, this will solve all your problems. That's great.

As a junior, mid-level engineer, people were like, "oh, you have to learn this, you have to learn this." And then I would go to these interviews, and I'd be like, I just don't understand this question. It just doesn't make any sense to me. And I was like, how do I get past this? How do I get past this barrier in my career where they expect something that I can't give? And then that was part of the motivation to become a public speaker, which other people would think is insane. They're like, why would you go to that much work to be a public speaker?

And it's because I can show my work in a different way and get the job that I want. I got the job I am now because someone came up to me after a talk and said, hey, can we have a conversation? So it was a way to build my brand in a way where I didn't have to do something I didn't want to do. I don't think it's less work. I think it's a different type of work. And it's work that I wanted to do versus work that I really, really did never want to understand. Every time I open cracking the code interview, I would fall asleep. I just couldn't. So I'd rather be a public speaker.

On other ways someone can take control of their career

I actually went to a workshop about this like 10 years ago and I like blew my mind with it like "oh my gosh I can become a public speaker instead of doing leet code. This is amazing."

And at that workshop They offered a couple different paths that weren't my path, but could be for others.

One of them is uh being a writer - documenting everything you do. So you like to learn code just write down all your notes and then you turn into a blog post or video or something that's like just online, and that's a way of showing your work.

Another way to show your work that is desperately needed is open source contributions. I never got into that, but I can see how it'd be very well taken. So if I was interviewing someone and they said, "hey, instead of doing a leet code question, can we just walk through a project that I worked on?" I would much rather do that. That sounds great.

I've done that before with someone where I said, tell me about the project. And then I was like, okay, if you had five engineers in 10 years, how would you make it better? And that was a great conversation.

And that's the type of thing where it's off the beaten path, but it shows your quality. And just being very proactive when you're trying to get what you want to not just accept "this is how you do it." I talk about this all the time that I never go through the door. I always walk around and go through the window because the door doesn't work for me. It's not, the door knob is too high. I'm only five feet tall. I can't reach it. So I always go around.

There's other ways to do things that can fit your personality and your brand. It's not going to be easy, and there's lots of different ways that this can be approached. Things like just like making friends and networking has been really huge for me in terms of getting the jobs I want without going through all the hoops of things that I don't want to do.

And also just something to note is like, when you are looking for jobs, you can ask. You can say, can I show you a project? Can we pair a program? Can we do something different?

There are a lot of times people are just interviewing you in the ways that are easy for them. But if you give them options and say, hey, I will really shine if I can show this to you, I think it will help you understand that I'm going to be great at this job. If they're cool, they'll say yes. If they're not cool and they don't say yes, you probably don't want to work there anyway.

I think the overall theme here is just ask. Don't say no to yourself before someone else says no to you. Just try things. And if they don't work, I don't know, try something else. I tried blogging. And then I was like, this isn't fun. No one's clapping for me. And then I realized, oh, if I speak more, then people will clap for me. That's all I want is clapping. So let's do that instead.

Links to Michelle

• Website

• Mentoring

• Booking

In this conversation we spoke about shifting engineering organizations to be more customer minded, product minded engineers, working with product, and more. But the theme of the conversation was around organizational change. What the process looks like, how to help people change, the importance of respecting the past, and much much more.

How do you bring people out of cynicism to accept change?

I have been cynical. I think that cynics are failed optimists or disappointed optimists. The pattern that I saw with failed changes was a group of engineers would get excited about some new way of doing things.

And in this company at this time, the executives were all from a hardware background. So they did not understand software at all. And so they would just sign off on the change. And then the team would start or the group of people would start using the new tool, the new process, and they'd run into problems. And I'm going to use the analogy of getting married and everything's fine and wonderful during the ceremony and the guy is beautiful and all that kind of thing. And then six months into the marriage, the woman sees the toilet seats up and socks are on the floor and she's like, what have I done?

And I think we all face that kind of thing. We get excited about doing something new, and the reality is always less glorious than the dream, in my experience. And so how do you persevere through those things?

That's where the organizational change aspect comes in, and if you don't have that, what can happen is people just abandon doing the change, whatever that change might be.

And then - engineers, we're good at seeing patterns. And so we see this pattern happen one or two times. And then the third or fourth time that someone comes along and said, I've got a great new way of doing things. We're like, "yeah, I've seen that movie and I didn't care for the ending."

What does it take to get past that "toilet seat up" moment?

I think that whole sequence of events when people see the changes being positive is extremely mysterious to people.

We all know there's changes that come out that we don't like right off the bat. There's a reorganization and I got, now I'm reporting to a boss I don't care for. Okay, that's pretty simple to realize, but when you think that this is a good thing, it's mysterious when it doesn't feel so good in the middle of the change.

And so I think there's four steps to change.

First is realizing the status quo isn't working. Second is, "what are we going to change to?" And then the third and fourth steps, I think are the most important to avoiding this cynicism sort of cycle, if you will.

One is breaking the change down into steps that can be achieved sequentially. Like I said, we're not code. We can't be recompiled. So how do we take ourselves from where we are today to where we want to go That's the stepwise process.

And then the fourth part that is the most important part and the one that I see most often not working well... The fourth part is the most critical and the least understood, especially by executives.

It is support and sponsorship along the way. So the executive sponsor that says "we are going to persevere even though this is hard right now" is absolutely critical to making change in an organization.

And then because change is hard even if you wanted it in the first place, support, of whatever kind of support you want to give people, is also very critical.

But sponsorship, if you don't have sponsorship, most large scale organizational changes are not actually going to occur.

Breaking down changes into steps is hard - What does it take to do it well?

I think you have to think about, okay, here's this thing that I want to see happen in my organization. What is a relatively small, and let's say it's a year-long effort, what is something that could be accomplished within the first few weeks that leads us in this direction of this change that is achievable and not too hard to kind of get things started?

When I was working as this internal consultant, we would produce short, medium, and long-term roadmaps for the organizations we were working with. And the short-term roadmap was three to six months. Maybe nowadays it's one to three months, or perhaps even one to three weeks. But you have this short-term thing that you're trying to do. And then you kind of map out some medium-term things, and then the long-term thing is the final vision.

And just like in Agile development, you start into the process, you realize, okay, I thought this was easy, but it's hard. I thought this was hard, but it's easy. You adjust it as you go. You figure out who in the organization is good at helping provide that support. You work with the sponsor, your sponsor or sponsors to make sure that they're doing what they need to do and so on and so forth.

How do support and sponsorship end up showing up?

I've been an engineering manager, I've been a director, and I've been a vice president of engineering. And at each level, there is some amount of check-in with where is your project at, when is it going to be done. There's some sort of dialogue about that.

That kind of dialogue and attention from the various layers of management in the chain is equally important, if not more so, when it's organizational change.

Because when you're working on a project, you understand, okay, we're in a business, we need to make money, this thing's going to make us money, so it needs to be done, maybe there's customers that you've committed to. There's a lot of external pressure to make this thing happen.

There's not as much external pressure when you're making organizational changes. You're trying to become more efficient. Well, what happens if you don't?

No customer is going to come to you, at least not in my experience, and say, "oh, you didn't implement your new tracking CI-CD tool at the time you thought you were going to. What happened, and what are you going to do about that?"

That never happens. But if you commit, I'm going to provide this feature for you by that date, and you don't deliver, there'll be external pressure.

So this checking in, this it's a balancing act, because as a leader, you have to listen to what people say. It's hard. It doesn't work exactly the way they thought it would. There are problems. And so there's that balance between, I want to hear the problems, I want to solve the problems, and we're going to do this thing that we said we were going to do. We're not going to just abandon it because we've run into a problem here.

On respecting the past while working for change

So one of the things that I think is important in change, and I had not talked about this before, is respecting the past. Sometimes in change, you know, we want to get everyone excited about the new way of doing things, and so we kind of trash the old way.

In this particular case, basically would have meant disparaging people's work for several years, and I didn't wanna do that. what I've come to realize is that there's a reason why things are the way they are. And the organization has been successful up to this point doing things the way they are.

And so respecting that and finding out the difference - What's causing us to want to make this change?

In this particular case, it was pretty straightforward. It was, we need to take this product to a global market, and it's infeasible to send an engineer to every customer site when there's a problem in a global environment.

But when you're making change on some other less obvious level, I think it's still worth thinking about what is the business reason or impetus for this change and what's changed externally that's causing us to want to do this.

It's not that people were stupid, it's not that we just didn't know what we were doing. We were being successful and now we want to be more successful.

What are the different types of conversation that happen during a change process?

I think there's conversations about understanding how we got to where we are. Like, why is this thing happening in the movie, and I think it's important as much as possible to spend time in conversation really listening to what people say about that and trying to figure out how we got to where we are.

Then there's conversations about where we're going. And those are kind of like, a lot of times people will talk about what they don't want. We have too many bugs. I don't want so many bugs.

Trying to help people figure out what is it going to look like when we're successful is painting that picture of success and both for yourself and for - I'm assuming now we're the person I'm talking about the person that's trying to make the change or design this change - figuring out what exactly we want to accomplish and how we know how we'll know we're successful. Those are conversations also that are important.

And then when you're in the middle of the change, the conversation is about how are things going and being open to hearing people say "this isn't working" and being inquisitive about what's not working and trying to figure out how can I solve this situation?

So there are really three different conversations, I think, at three different stages. And then the fourth stage, well, maybe the the fifth stage, because I have four stages, maybe the fifth stage, which honestly I'm not personally as good at, is solidifying the change and celebrating that we actually did this thing. I'm kind of wired to go find new problems to solve. So once the problem is solved, it becomes less interesting. And I sort of forget about that piece.

Does that ever cause problems?

Well, it can. I mean, people like to be recognized for a job well done. And they like their boss to have some amount of recognition. And so I try to mitigate that through various ways.

There's also the risk that people snap back to the old way of doing things if you don't embed it in, again, the human system. If the human system doesn't have this solidified, you can snap back.

One of the things that I saw a lot as a consultant is people jumping to tools without really thinking through the policy changes that need to be in place to make that tool be useful and the process changes. And so I try to design policy and process into the change, but if you don't have that, yeah, you can get people to do things for a period of time and then they go back to their old ways.

Recommended Resources

• The Leadership Engine

• The Product Minded Software Engineer

• Product Engineers

• Inspired

Links to Elaine

• LinkedIn

But those weren't the meat of this interview. What make's Amy's experience unique in folks I have spoken with so far, and what we spent the majority of our team talking about, is managing people in the globally distributed, remote and asynchronous company that is Gitlab.

Truly working asynchronously is something many companies aspired to when forced to go remote during the COVID pandemic, but few actually succeeded at. GitLab has been that way from the beginning. So we dove deep into how it works at GitLab, how an asynchronous approach makes some things easier and others harder, what the 'A B C's of async look like, and how time horizons shift when you account for asynchronicity *and* global distribution.

How is working at GitLab different from most other companies?

I think people who join GitLab come in and it's globally distributed, and we're remote first. But the thing that seems to surprise people is it's async.

So it's not that you are on Zoom calls with people from across the world or Zoom calls with people in other cities in your time zone. It is first and foremost, things are written down and then secondly, spoken.

There's some benefits, there's some challenges, there's some stuff that's just different. And I think it's the single thing, it's interesting when we onboard people because you actually have to be very, very deliberate on teaching people "here is how we communicate."

I think in a normal office environment, you have to teach people a level of professionalism, and you learn that through your career, but they'll reach a point where people know how to go to a meeting, and they know how to talk to their peers.

When you join GitLab, because it is asynchronous and it's not so common, you do end up almost needing to... sort of walk people through like, here is what this looks like.

There's a few really fundamental things. I think we are very, very lucky. I think through the pandemic, we saw lots of companies having to suddenly go remote. And I think in lots of cases, they perhaps tried to go async and it didn't always work out. I think at GitLab because it has been like that from day one, we are lucky. there's lots of things just built into our culture that's like, that make this stuff work.

For example, everything is going to be written down. And it should be written down in a place that other people can discover it. At GitLab, we're using GitLab, so it's GitLab issues. But there are other ways of doing that. But I think it's not email. Crucially, it's not a private email thread that nobody else can ever discover ever again. Because the real benefit of async, and the thing that justifies the cost of async, is the fact that you almost get your documentation for free.

So you wrote down that discussion, and you wrote down that decision, and hopefully you added all the context about why you made that decision. And then six months, 12 months, or however many years in the future, it's just there. And the next time when somebody says, "why does this thing work in this way," you hopefully just have the information right immediately there.

Starting from the fundamentals, what are the 'A B C's of how you work professionally in an async environment?

I think the things that are most difficult is unlike in, say, an office environment or a here's a meeting and calendar invite and a link that you can join, what can feel quite difficult is how do I get to that person? How do I reach that person?

So you do end up having to do some sort of onboarding and training to help people navigate that. Here are your teammates. That always happens. But... this is our process. You will receive notifications in this way. When people want something from you, this is what that will look like. So again, at GitLab, you usually get a ping within a GitLab issue or a merge request, or you will be assigned to a merge request to review it. Your notifications will appear within the product. So it's helping people understand where they will find those things and helping them understand "here's where your work is living."

You actually do need to go and find your work. Otherwise you'll just sit at your desk all day and you may not be in a time zone with other people. So if you don't go and engage in the conversation, it may not come to you.

So it's helping people actually find a way to sort of firstly connect with the team, and then know what the norms are for team communication. How do you indicate that you are working on something? How do you indicate that you are seeking feedback or this is a very sketchy, like, you know, super early thinking and you're looking for other... you sort of have different types of communication. So how do people indicate that to other people?

And for others, often, just like titling of an issue or the certain labels we use. It's not complicated. It's just helping people understand what the norms look like.

Then the next challenge of GitLab is if you get asynchronous really right, the problem you have a bit later, once you've got hooked into all these workflows and people suddenly realize who you are and what value that is, you get what we call the fire hose of information. So suddenly you're connected to everything.

And then you have a new problem, which is, how do you possibly keep up with all of this stuff? So you may get like... there's all kinds of interesting discussions or projects. You may be asked for your input into all kinds of different things. And then there's all other things that you may just stumble across that are also interesting to you.

So there's always this like secondary workflow thing where you have to find a way to put some process in place. And this tends to be a little bit individual. I think different people have different ways of working that work for them.

And I think I found that my way of working will usually work for six months or maybe 12 months. And then you reach like a breaking point and you're like, oh no, too much information, I need to revisit and sort of recategorize so I can stay on top of things.

But how do you make sure you are seeing and responding to the right things and spending your time wisely, even though there is like an infinite amount of other interesting things. It's kind of like if you imagine in an office, if you could eavesdrop on every meeting taking place all the time. Fascinating stuff, but you can't keep up.

Given there still need to be some synchronous meetings, what do those look like in an async culture?

Yeah. Oh yeah, definitely. So this one is really interesting because I have previously worked in teams in sort of more office-based environments, which as I look back now, I'm like, some of this stuff, if we'd have had that, we would have just avoided certain problems. So the basic one is just every meeting has an agenda. That's just standard. If there's no agenda, there's no meeting. And then the meeting, so I like the...

There's lots of benefits, I think, to asynchronous work. But the one I particularly like is the fact it's a lot more inclusive. So it isn't just the loudest person speaking, or it isn't just the fastest thinker getting to drive the conversation.

We are varying degrees of good, but when we get it right, we're brilliant at having an agenda written up in advance. That should be editable by everybody... everybody is not a "I'm coming to present to you." It's asynchronous discussion.

So the general thing that normally happens is the topics are added onto the agenda. People will add discussion points and questions and answers to the agenda ahead of the meeting. I always found that quite interesting because in some ways, some meetings almost conclude before they even begin.

But it works for time zones. So the agenda will be up, and it will have topics in. And maybe the meeting is taking place my morning tomorrow. But there are people working in other countries who actually are going to have an entire work day between that.

So they can actually join into the agenda. They can add to the agenda, even though they won't be physically in the meeting. And that's OK. Somebody else will verbalize their points, or we'll share something.

But the general idea is that the meeting is a discussion. And it is a document that's accessible by everybody. And it has the minutes. Unless it's genuinely a private meeting, that's fine. But for a team discussion or project updates and discussions, then that's the idea.

The meeting is not really intended to be the first time you heard about something, because we are asynchronous. So we're quite good on the culture of if somebody comes up and, "oh, I've got this idea, I've been thinking about all of these things," okay, where is this written down?

So there was a kind of normalization of, you wrote down the first version, and then we discussed it. And again, I think that really helps the people like myself who like to read something or hear something, think about it, and then have an answer. So you kind of get that thinking time.

Are there other rules around meetings, or what should and shouldn't be a meeting?

I think one rule that we have which I mean I think it actually like blew my mind when I first heard it is we don't present. Because people can read.

So if you're gonna give them a slide deck, give them the slide deck and then have a discussion meeting. So we have quite a lot of meetings where you'll prepare slide decks. They're a little bit more texty than, like a flashy conference slide deck, for example, but all the information is gathered on a slide deck, shared in advance, and then there'll be a meeting, which is just questions.

And that's really nice, because it means if people don't have questions or they don't want to go to another meeting, they don't have to. But if they do have questions or they want to discuss things, they also have a place they can go to. So that works really well. And I think it really cuts down on the number of meetings and the length of meetings.

How is management different in an asynchronous environment?

That's a good question. It's reasonably similar. So yes, I still have synchronous one-to-ones with everyone. I think that's really important. And you have very different type of conversations one-to-one. And I think that's when you really can check in and see how people are doing.

But I think there are a few things that are interesting. I have found that in many ways, it's easier to give people good feedback, because their work is so much more visible.

So if previously, in an office where you know this person's having trouble communicating with that person, it's all a bit hearsay. It's all, "well, they said this and I said this and they're not listening to me." And it's really hard because a lot of those things take place in a closed meeting room. It's very hard to get to the real bottom of, like, where is the problem? So I find those things can sometimes take a lot longer to resolve.

One of the great things about being mostly asynchronous is a lot of those things are visible. So you may not see the full problem. It may still have happened sort of synchronously, but if you get feedback that, you know, I'm finding this person difficult to work with for these reasons, you usually have a decent sense from the work you can see of okay I could see how that could come about.

So I think in that case, it's a little bit easier to gather those examples and give feedback that's actually a bit more specific. I've definitely had cases in offices where you, oh, make sure you give that person the feedback on their communication. You're like, I don't have any examples. And it just doesn't land at all.

Whereas I think one thing that's good when you have asynchronous is f you did get something like that, if you were going to give the feedback, if it did feel valid, you could probably get together some of your own examples where you can literally walk through, "you wrote this sentence, and how do you think that makes people feel?"

And quite often, I think it's a, not everyone's got English as their first language. So often, it's just a simple translation. When you say this word, actually for some people, it sounds more like this word. So you can go into, I think you can give slightly more useful feedback just because you have that visibility.

How do time horizons change in an asynchronous environment?

They absolutely change. It's interesting because it goes both ways. So one I think that can feel frustrating, so I'll start with that one, particularly if you come from more of a synchronous environment, is the sort of things where you would previously have, “let's get a group together and we'll just quickly discuss this thing and it'll be all done and dusted one hour, off we go."

So for example, say like a retrospective. Lots of teams, every few weeks, get together for an hour. I've worked in places where we've done 15 minute retrospectives once a week, really quick and everybody just drops in their ideas and you're done.

Take that asynchronous, but also crucially globally distributed.. and that is the key thing that changes it because if you write something, you really need to give at least 24 hours before you make the firm decision. Because otherwise, you've not allowed everybody to really take part.

But also, it may not have been everybody's top priority. So that's probably your minimum. So if I open up a retrospective, if we do our retrospective, it's asynchronous. We use a GitLab issue, and it sort of has the sort of usual information, like here were the goals we went in with, here is the outcome, here's what we achieved. Here was a rough timeline of events, and then some fairly standard retrospective questions.

I would usually give my team one or probably two weeks to respond. And then we summarize everyone's comments, draw some conclusion, set some actions. You've probably got another few days to get everybody to really agree to some actions, and then you're done. So we do them less often and they take longer.

But the actual actions we get are very high quality because the benefit we have is that it wasn't, you know, 9 a.m. on Tuesday and this person wasn't feeling that well and this person hadn't slept well because they had childcare issues last night. And you just got what top of mind on Tuesday at 9 a.m.

Because people have that longer time, they're actually able to think about it and be a bit more thoughtful and respond to each other. So sometimes people will add their comment, someone else will add a comment the next day and that will trigger a different discussion.

So it feels like we get a more useful retrospective, but the overall end to end that you're going to need three weeks to get through your retrospective is a real shift compared to what many people are used to.

Links to Amy

• LinkedIn

• Humans+Tech Podcast

In our conversation, there were two overwhelming themes: Handling conflict, and leading with swagger. Handling conflict is one of the fundamental jobs of a manager, and we talked about ways to reframe it, how to use it as a way to learn about others, and when to walk away. Conflict is an uncomfortable topic for many of us, but there are some great concrete tactics you can use to get better at it.

Our other theme is a little more vague but Kate mentioned that some of the best leaders she has worked with all had a certain swagger to them, and we spent most of the second half of the conversation breaking down what that meant. We talked about building the confidence to make decisions in uncertainty, own up to what you don't know, and maintain a certainty that you and your team will get through whatever is thrown at them.

On handling conflict as one of the most important skills in the workplace:

No matter who you are, being comfortable with conflict and comfortable with that negotiation is a skill that will always serve you well. And what I mean is, specifically: people talk a lot, you hear people saying, "I don't like conflict," "I'd rather avoid conflict," or, "I don't do conflict well", can you handle this kind of thing? You hear that a lot from ICs a lot, but also even from other managers as well.

So I think a lot of people just avoid things altogether. And I sort of shudder to think about the number of problems that could have been solved if people had approached conflict from the idea that conflict is an opportunity.

I know that sounds like super trite to say, but just that conflict is an opportunity to build a better relationship. Some of the best working relationships I have were with people that we butted heads all the time. And it was always done with respect, right? But we were just usually on different sides of the fence, had different things and different priorities that we both had. We were both trying to do our best for the project. We were just coming at it from different sides. And so ultimately those discussions and those points of conflict strengthened our relationship over time.

There's a number of ways you do that. There's, one, you have to know what kind of person you are and how you handle conflict. And so self-reflection is really important, we could talk about that a bit, but also knowing what they want and what they are trying to achieve out of a particular interaction.

One of the things specifically, I think has been helpful for me. If you've ever listened to Kwame Christian, he gives a great TED Talk on this, on conflict, but he talks about compassionate curiosity. And one of the key things there is inviting people to tell you their side of the story. What are they trying to achieve? And not in any sort of a, like, "what are you trying to do here?" But just a, like, "I really wanna know. I really wanna help you. I wanna come to an agreement with you."

And taking it as an opportunity to learn about somebody as opposed to we have to get this done, I need to win, is a drastic difference in how you approach conflict. I wish it was talked about more. And I wish conflict was talked about in that way because I think if more people approached negotiations in that way, things would be a lot smoother. We'd have stronger relationships a little bit easier just across the organization.

On reframing conflict to target problems, not people:

I think it's the difference, if I were to boil it down, it's the difference between "either I win or you win," and instead it should be, "okay, either we both win or we don't play at all."

We need to find a way to both succeed here. I think that's really like what it comes down to. And that does take time. That takes time, it takes effort. I know when people look at how daunting that can be.... People say that's just a lot of work, I don't wanna engage, right?

And then you get back into that kind of avoider kind of mentality for conflict, but it is important and you end up better off because of it with stronger relationships, with better understanding. And really for your team as well, for the managers that are kind of engaging in this, making sure you've got the full story and you're protecting your team with all of that information.

How do you bring someone from an adversarial mindset into a collaborative approach to conflict?

It’s tough, right? I mean, I think it comes down to understanding the person you're dealing with and their motivations. I think the first thing I'd say is, try to understand where they're coming from and what they're trying to achieve. And there are going to be cases, there's no one recipe for how to handle conflict because every situation's going to be different and every person's going to be different. And sometimes people just have bad days, right? It happens.

And so I think being, first off, being as clear as possible and as much as you can, removing the emotional piece. Like you talked about, people tend to make it about you and I. And like it's a personal failing.

It's where you get into, I'm sure other people have talked about this on the podcast, but you know, a blameless culture, remove specific people from blame, talk about we, invite that other person as like, we are a team.

Even the small things about how you talk about the problem and talk about the solution, inviting people into being a team with you is pretty important. Making sure you are, I will sometimes bring up a word document and be like, okay, let's talk through the requirements together. Help me understand. Like, I'm gonna write it down, you dictate, let's go.

And so as much as you can, separating the emotion out of it is really important and probably a good first step. It's not always gonna succeed and sometimes there are cases where you need to make a judgment call and you might have to clean it, clean up that relationship a little bit later, but when you can and if you have time, I think it's important to spend the time trying to negotiate.

You brought up that the best leaders you've worked with have a swagger to them - what do you mean by that?

Yeah, mostly it's a confidence, right? How you present... I mean, first and foremost, I think part of it is having the confidence that you've honed your good instincts, that you were put into this position for a reason, that you're able to make decisions.

You might not on the inside feel very confident, but knowing that the way you present yourself, like are you wringing your hands constantly? Are you able to make decisions, based on feedback and seeking diverse perspectives and everything else, but are you able to effectively make a decision? Or are you constantly questioning every single time you do? People notice that.

And there's a difference between engaging others in a discussion to a final solution and letting other people make the decisions for you. [Leaders like] Lauren, Bradford, very good at making that decision. Very good at engaging other people in that decision, but ultimately the decision is theirs.

I think also leadership can get overwhelming. We talk about churn, we've talked about churn and my own career path has been wild over the last few years, but just the knowledge that things get better. The churn is temporary and knowing that looking back, we will have found a solution, things are going to get better. And keeping that in mind as well, I think, as you go forth in your career, that becomes more and more apparent. It doesn't make it easier at the moment, but having that confidence is pretty key. And again, it's hard to define, but I do think it's something people see.

On why confidence letting you move through uncertain decisions is important:

No decision is also a decision, frankly, and it paralyzes people. And so sometimes you do just have to pick a direction. The thing that I tell my ICs all the time... I get a lot of questions about, "I have a problem" or like, "how do I solve it?" Especially in skip levels, like, "hey, I have a suggestion. I have a thing that I'm thinking about, or I have a problem, what should my next steps be or what should I do?"

And often I'll say I don't know the answer. And often the next thing I'll say is, you don't have to have the answer, but you do need to have at least a next step. You do need to show that you've at least thought about a potential solution or a potential direction to go to. That is really valuable to leadership. Valuable to me as a manager certainly, because that will help me make my decision.

But even for me presenting to my higher ups and to my leaders, I might not have the answers. Things get really, really complicated as you go further and further up the chain. There's more and more dependencies that you're trying to account for. But what is your next step? Sometimes that's the only answer you need. And that gets you moving forward. But yeah, to stagnate would be the worst.

How do we hold on to swagger while also being humble?

Yeah, great question. So I'll clarify, I think when I say swagger or confidence, it's not so much somebody that is like, "I have the answers, I know it all." That's not what I mean there. There's certainly people that I've met that are like that... Those are not fun people to work with.

What I mean by confidence... I think it's still just as valuable to me to work with somebody that's like, "This is my decision. It's a grand experiment, and we'll see what happens. I don't have all the answers, but this is where we're going with. And we'll make adjustments on the way. "

And that's fine. That answer right there, just as important, still shows a lot of confidence, even though you don't have all the answers and you are being very transparent about that.

I think often people confuse, "we can't tell people that we don't know what we're doing" or "we don't have an answer." They wanna hide that from people. And I think it's more valuable when you can to be really transparent about, "these are the things I'm thinking about, this is the decision I made, it's a path forward, let's go. Let's try to figure it out together."

Links to Kate

• LinkedIn

In our conversation, we dug deep into that line of thinking, exploring what it means to thrive, how uncovering and tapping into our innate senses of joy and play can help us as leaders, and diving into the tactical underpinnings of how seemingly more "woo" things like positive intelligence and visualization can help us even in our work in tech.

You're focused on helping women in tech thrive - what does it mean to be thriving?

Yes, thriving for women in technology... and actually for folks in general, but let's start with focus on the thriving for women in tech first.

So often we feel like we're the only ones in the room, we're not being heard, we're not getting paid as much, we feel there's a lack of promotion.W have to prove ourselves versus our male counterparts are getting promoted based on the potential.

And so that's definitely one aspect that I lean into. But another aspect of thriving is leaning into asking the people I work with, "what is it that you really want?"

Because so many of us, I say, are high achieving, good girl people pleasers. And we've spent our entire careers doing what everybody else wants us to do. What we were praised for, what we were rewarded for.

And I work with so many women who get to being in the industry for 20 or more years. And all of a sudden they wake up one day and realize, I don't know why I'm doing what I'm doing. And I'm not happy. And I don't know what's going to make me happy.

And so I work with a lot of folks and help them figure out first, what is it that you really want? It's fascinating sometimes how ingrained this can be. I was speaking to a client a few months ago and I said to her, "what is it that you loved doing when you were a little girl?"

And her answer to me was, well, there's all these things that I used to do, but I did them because I got praised for them. And so I said, like, let's get some more play into your life. What do you want to do for fun?

And so that's one aspect of thriving. And another one is again, because it's lonely at the top and the biases that come into play thriving can also mean that we're overcompensating so often to try to succeed in our careers. And we're so used to being the caregivers that we put our priorities last.

And so a big part of what I also focus on is what are those small skills... like self-care journaling, going out for a walk in the middle of the day, that are going to actually help you succeed and show up as a better leader. And that's a practice for everybody.

And then it's also a lot of mind-set shifts. Again, and I think this impacts really everybody in this industry, we're kind of sold on this... All right, to be quote unquote successful in tech, you need to have like a huge purpose and be changing the lives of millions of people. And you need to be constantly going after that next promotion, that next pay raise. And if you're not doing that, you're failing.

And I call BS to a lot of that, because what that ends up doing is leading to a lot of people thinking that they're failures, that they're not worthy. And so I work on a lot of, but you are worthy just for being you as an amazing individual human being. And the part that gets triggering to everybody when I tell them is if you delivered nothing else for the rest of your life, you would still be completely worthy.

It's really helping them realize that their worthiness comes from within. And that can really help them thrive in this industry.

It's easy to get into the pattern of doing work to make others happy... How do you get started identifying what it is that brings you joy?

I have a few questions that I tend to have people really walk through because it's so true. It is so common.

I used to go through what I would call my three month burnout cycles, which is I take a vacation or a break, I come back well rested, I just worked really hard, and then I burn out and I would do it over and over and over again.

And because we're such high achievers, we're constantly just looking for that next success. And the thing is, for so many of us, we're so good at what we do that we're not celebrating the wins along the way and realizing that we are really successful.

And then also, when we're feeling failure, that is a normal human emotion. Because we live in such this like social media world where everyone's just posting like everything's good... You know, I had a coaching call very recently with a client and she was like telling me like "I feel like a failure again, Josie. I thought we had dealt with this a few months ago"

And I said no and she's like, am I alone? Is this just me? And I was like, no, absolutely not. But we don't talk about the fact that we do all end up feeling failure.

And guess what? There's a law of polarity... for us to feel true joy and happiness., we also have to be able to feel sadness and frustration. And so it's okay. It is normal human emotions.

And so if you're listening to this and you're like, oh my gosh, I so resonate, take some time to reflect in both your personal and your work life.

Starting with your work life. Look at jobs that you've enjoyed doing, and what are aspects of them that you truly enjoyed. And then take the time to think about, did I enjoy doing this because I intrinsically enjoy doing it? Or because somebody else told me I should enjoy doing it? Or I was rewarded for it?

Because what it ends up being very true is, you know, similar to how I was speaking about earlier, we are we get the dopamine hit of that external praise and validation. And sometimes we really need to journal out and reflect, "huh, is this something I actually enjoy doing? Or is this something I just get praised to do?"

And then I have people look at it in their personal life as well. What are your hobbies? So often, people in tech do not have hobbies. And I'm like, you need to have some hobbies here. It doesn't have to be something crazy, right? I mean, for me, it's building Legos and painting, drawing a little adult coloring books... and I love to read and my hammock in my backyard.

But I realized when I get so out of touch with those things, because again, one of the pitfalls I see on the personal side with high achievers is we can focus on personal self development and think that those are hobbies... I'm all for personal self developmen - I love self development - but I notice when I get too far down the self development rabbit hole I am not focusing enough on doing the things that just light me up and bring me joy.

So what are things that you do just because they bring you joy. And this is where that question of what is it that you did as a little kid that brought you joy? And again, really reflecting on does this bring you joy truly or is it because you were rewarded and praised for it?

How do you help people shift their mindsets around work away from ladder climbing?

I see this again in this pattern where... people want a promotion, right?

And so I tell them to step back and say, "all right, I completely agree, you deserve this promotion. Sometimes the work life is not fair." Like, I just have to admit, hey, the corporate world is not fair. You might deserve this promotion and you might not get it.

And I'm not saying. You shouldn't get it and you shouldn't fight for it... But we drive ourselves crazy sometimes going after that next promotion. And that's where I again have people step back and think about the self-worth piece. Really reflect on, "I am worthy just for being me."

I have people have affirmations around their worth, their value, their abundance, their ability to attract and magnetize things to them. And then also tuning back into what are the parts of your job that truly make you happy and light you up and how can you do more of those and delegate the things that are not in your zone of genius that you don't enjoy doing as much because that tends to be much more in our control as leaders than whether and when we're going to get that next promotion or pay raise or title.

Can you expand on the zone of genius?

Yeah, Zone of Genius is a combination... it's like beyond your strengths even, because we all have strengths, but it's really taking those to a next level and being like, "what is it that I am personally uniquely suited to do through my combination of strengths that I love doing?"

And it's that other part too, because there are things I am very good at, but I'm going to be bored out of my mind to be doing. But when you're in that zone of genius, that's when you get into flow. When you start doing something and hours go by and you produce amazing things and you don't even feel like it was work.

That's when you know that you're in your zone of genius... and this really goes a little bit back to the diversity piece. So often we end up hiring people that are like ourselves, but that actually ends up being problematic because what we really want is people with vastly different zones of genius so that we can complement each other and also provide more diverse ideas so that we can build better products to fulfill more people's needs.

How do joy and playfulness help at work?

We build better products when we're more playful. I think so often, I talk about the fact that we don't do brainstorming and decision making in a very good way, because those two things should be totally separated. And the more play you have the better your brainstorming is going to be leading to better products.

A lot of people first just have this resistance of like, Jossie, it's work, we should be working hard, and not taking breaks. And I'm like, well, no, if you keep filling up your emotional and happiness cup, you will be a better leader, because you will have more possibilities and think about more open and creative answers to these questions.

If we get into the whole positive intelligence topic, this is really looking at it from that sage perspective, of using empathy and creativity and all these positive emotions to really create more amazing things.

And so, playing joy does not mean like, you're gonna kick back and just play video games all day at work. But it's how can you do this in a more fun way? How can you do this in a way that aligns with your energy?

I've realized over the many years that I tend to be more productive around like three to six or seven. Like that's kind of my sweet spot for creation. I spent many years trying to fight that and become the morning person, because everyone always says you're more productive in the morning, and all of that.

And I finally just was like, let me lean into when I feel most productive and do the things that I enjoy doing in those times then. And maybe I'll set up meetings earlier. So bringing in that joy and play also sets such an amazing example for our team members as well.

Going back to being an effective leader, you don't want to be this like controlling person who's just trying to call out people's mistakes because you're not going to be getting the best of them.

If you can really allow everybody to work in the most effective ways possible for each and every person and again, respecting that diversity that it's going to be different, that is going to bring so much more joy into people's lives.

And for one employee that might mean, hey, I wanna take a break in the middle of the day for lunch to have lunch with my kids who happen to be homeschooled or something like that. And for somebody else that might mean, hey, I go on a few walks a day to clear my head. It's about really respecting that time.

But we're so afraid, like I've literally worked with people who I said, "hey, when I used to work at Tile, I was a Vp... So I had the very traditional manager schedule where I was booked all day, every day. But three times a week for an hour, there was a block for Pilates, because Pilates is my jam. And everybody knew, you do not book over Pilates, because Jossie will not show up. This is a non-negotiable. "

And I had one person tell me like, well Jossie, you can do that because you're a VP, but I can't do that as an individual contributor. And I said, no, you absolutely, everybody has the right to do that.

And as leaders, the more that we can model that, the more that we can hopefully teach our teams. And no, it's not like this isn't just a privilege I have because I happen to be the VP. Everybody gets the privilege of being able to take the time I need and get their work done.

And I mean, I think one of the fallacies of the fact that we have this 40 hour work week is... that all came from factory work, right? And the work we do is very different. It is very much mental work. And you cannot do this for eight to 10 hours a day, all day, every day. Creativity comes in spurts.

It's about when you're most energetic. And so...going back to play, it's the more that you can allow your team members to enjoy life a little bit, socialize more, really build team camaraderie and let people play in their own individual ways as well.

And realizing, hey, some people get introverts and get energy by going off and doing something on their own. And other people are extroverts and they're gonna get energy by going out and socializing with others and really creating spaces for everybody's unique way of finding that energy, joy and play is what can really help a team thrive.

Recommended Resources

• Positive Intelligence

Links to Jossie

• LinkedIn

• Website

We talked about a number of things - we talked about authenticity, we talked about management, and what managers can do to create safe spaces for diverse teams, but the overwhelming thread in this conversation was about caring. How important it is to truly care about your work and about people, how to expand your circle of caring, and how to care for yourself.

What do you think about/mean when we talk about "caring" in a work concept?

So I have a very short, interesting story. When I was asked to become a manager, actually, I was tech leading a team, I was unsure. I was actually nervous.

Two reasons. One, I feel as a woman, I felt like my software engineer title was hard earned, and I felt like I would be diluting it with manager, so I was a little reluctant there. But the other one was also, I was not sure if I could really be a good manager and a technical person and a leader at the same time.

And I think this is something many of us struggle with in general, I realized over the years. But one of my ex manager, I asked her like, "do you think I can be a good manager?"

And she was, she just said a short thing. She said, you know, Garima, I think there isn't like a recipe or a training to being a great manager. And by the way, this resonates even with being a great parent, I realized as I.., As you said, I grew with Google. And so there were multiple things happening in parallel in my life. I became a parent, I became a manager. It was actually on my second maternity leave, I became a manager for the first time.

And she said, the main thing is, if you really truly care for the people you are leading, you will automatically show up as a good manager. And I think that was a very simple thing. It was very crystallized, but I think it holds the essence.

When you care about the team, when you care about the product you're leading, automatically you will be putting a lot more effort than is required by the job. And the outcomes will reflect that because the product will show up better in ways because you deeply cared. The people will go above and beyond to do things because they know it's not just about the job or the task at hand.

It's about somebody who is noticing their work, who cares about their long-term growth, and things get aligned. So I think that's where the caring piece started from.

What are some examples of how caring shows up?

I think in the caring for people aspect, especially your reports as a leader or manager... there are multiple ways you can be a manager. You can actually really take interest in the work they are doing and go deeper with them in that, in terms of problem solving, helping them with their code and output and stuff.

You can go, I would say, next level deep and care about what do they want out of their work in a slightly longer term timeframe. It's not about delivering this project. It's like, "where do you wanna go?" And I would say that's a step two depth.

And step three depth is caring about that human, that person, because work or this job may be one aspect of their whole. And a lot of things interplay in our lives. So when we care about the whole, we can actually see a bigger picture.

And when something else is draining them out, work also suffers. So we are actually partnering with them in making progress on the whole, which I think is a net win for everything involved. But it requires patience and it requires time.

Because for example, there was a time when I had a report who was, and this was during COVID, and I think this was a pretty common thing which was happening. This was a single person who was living in an apartment, they were not allowed to go anywhere, they did not have roommates or other partners.

So basically their social connection was the job and Google used to provide a lot of things where people could stay at job pretty much, you know, the whole from morning till dinner time and then just go.

And now they were suddenly cooking for themselves, they did not have people to hang out and it was a really hard time for them. And yes, we did talk about the project that they were assigned to and the progress they were making. But I think in more of our deeper conversations, I realized this person's really struggling to just be. And at that time, having all these expectations.

So we had a more productive conversation, I would say, saying how do you take care of yourself so that you can show up better at work? You need to take the time off, you need some resources from work which can help you. Do we need to figure out something where you get to interact at least virtually with more people so that can become your support system.

So I think, yeah, that's an example. I would say, like I said, three levels... I think you can even go deeper, but I would say this is a two-way street. And one thing I sometimes now feel we tend to forget when we are trying to care too much for others is taking care of ourselves. So there is that aspect too.

To be able to care for others, to give to people, to community, I think the individual also needs to make sure that they are nourishing themselves and doing.

And not only does that help us as individuals, but also it sets an example again around us when we do that. We say, "hey, I have to take this week off because I'm just not able to deal with the five things and I'm going to actually turn off my email."

And that happened. I used to be one of the poorer examples earlier on in my management career where I would reply to emails on weekends. I would reply after hours. And to be honest, after hours is sometimes a necessity. When you have young children, you put them to bed and that's when you pick up your laptop again and get... And I think that was fine once I told people that, "hey, this is how I am splitting up my work time. This does not require you guys to be on at that time." And I actually started using the scheduled send feature or Gmail, which I think also helped.

How do you expand your circle of caring? Or if you're struggling with burnout, should you even extend your caring?

I think it's a great question. And I do hear you on the burnout thing. There have been times where you reach a point where you're like, nothing else matters. I don't care at all. But I think that goes back to that point. That means that we have not been caring for ourselves.

I have this, I guess, huge faith that in general, humans tend to have a tendency to give when they are in a healthy place. So I think that's an alarm bell actually, when you are getting to that point where you stop caring, that means, "hey buddy, it's time to take care of yourself."

And I think maybe the best way to encourage or teach somebody to care deeper or in those levels for somebody else is to first mirror it how it would be for them. Are you caring enough for yourself? Are you just doing the job and producing the output and going home and then getting up in the night and then again, you know, just going through the motions of doing the work or are you actually looking at is this what is the purpose? What gives me fulfillment from my work? Am I headed in that direction?

I think that's a next level thinking for yourself. And then even deeper thinking was "What do I want from my life? Am I able to balance the things, my work, my family, my relations, my other hobbies, to a point where I will feel fulfilled from my life?" And that's the third level of deep, and that's for yourself.

And I think if a person actually takes the time and does a little bit of that, I think the extension of that will come naturally once you have done that for yourself. It's actually easier for us to see that in others when we have actually mirrored it within ourselves. So it's a little bit of introspection there.

Recommended Resource

• Designing your life

Links to Garima

• LinkedIn

I’m currently single parenting as my wife travels, and I didn’t have the bandwidth to edit a new interview for this week. Instead, I’m taking inspiration from a recent question someone sent about good resources for someone becoming a manager for the first time, and going to highlight some previous interviews that were great on this subject.

First, this interview with Kyle Jaster was phenomenal:

Since doing that interview, I think I’ve shared his key mindset shift at least a dozen times. It’s helpful for me, and I think it’s been helpful for everyone I’ve shared it with:

There's an emotional experience that I've seen. I saw it in myself and I've seen it in a lot of people and I especially see it in new managers. I'll describe what happened to me and what made me have this realization.

When I was working at Noodle, I was having these massive mood swings in the course of a day. I was like, "oh my gosh, I've got everything figured out, I'm the best." And then I was like, "I know nothing and I'm useless and I suck."

And there was a period where it was happening in one week and then it just got to the point and you see it where it's like every day, every hour, I don't know what the hell is going on. And I was thinking about this a lot. Like it was like really fucking me. And I was thinking about my life on the x-axis and how my emotional experience was shooting up and then dropping down and shooting up and dropping down and shooting up and dropping down. It's like this crazy sine wave.

And at some point, I was thinking about it and I realized that the problem was the way I was looking at this was that I was looking at it from outside of the experience, and saying just measuring the emotional experience, and not what I was looking at that gave me the emotional experience.

And so suddenly I realized that actually what was happening was I'm climbing a mountain of knowledge. I'm learning all of these things, and when I feel like I'm at the bottom of something, it's because I'm looking up at the mountain of knowledge I have to climb to get to the next thing I want to get to. And when I feel awesome, it's because I'm looking down at the mountain of knowledge I've just acquired to get to somewhere.

And so the thing that I talk about with a lot of people on my team is like, when you're having that emotional change, it's like, "Are we looking up the mountain or are we looking down the mountain right now?"

Nothing has changed within the day that should make you either amazing or terrible. It's just which direction are you looking. For me it helped me become like, "oh, when I feel bad, it's because I actually just learned what I need to do next." And that's the next piece that I need to climb. And that became very motivating for me, whereas before I was just feeling really kind of lost at the same time.

Second, I loved this interview with Miriam Connor:

Miriam’s mental model for what being a manager is has also been incredibly helpful for me:

As a manager, there's a way to think, "my goal and everyone's goal is to climb the nodes in the hierarchy and extract the maximum income from those nodes", and there's a management style that will do that. There's a management style where you just do that by yourself, there's a management style where you try to bring those people up with you and maybe that helps push you up even further.

But I think that ignores the human element that we're going to work every day, we have to talk to these people every day, it's a huge part part of our lives and it's actually just like a lot less crappy if those are good positive relationships and you are treating people kindly.

And so as I'm talking this through, I think the one way I think about this as my role is "I have been granted a certain amount of power. How in the context of having that power and being in this particular structure and hierarchy, do I treat people kindly?"

And that is to me by giving them the maximum opportunity and making work as positive as I reasonably can, while still contributing to the goal that everybody in this hierarchy or in this organization has decided to move towards. I will say that's a lot easier is you and everyone in the organization think that's a good goal and think that's something worth doing in the world. But in any case, "how can I organize the people I'm responsible for to make progress in service of this goal?"

Part of the goal is "make money." How can I make money and do whatever the hopefully good thing is I'm trying to do in the world? And set these people under me up for success, both while they're working for me and in a way that once I'm not there and we're all in a different hierarchy and a different structure, they have the skills to both operate successfully in that structure and be kind.

I think that that's just one way of thinking about management. I think most people think about management in some sense of mentorship, although not probably 100% of managers. But mentorship can mean a lot of different things depending on what you're trying to mentor somebody to do. And I think for me it's how can I make it possible for these people to succeed and also be kind in a way that that makes the organization a more positive organization.

Other Resources

Some other resources that have come up in different situations and may also be useful are:

• Books

  • The Five Dysfunctions of a Team

  • The Manager’s Path

  • Managing Humans

  • Death by Meeting

  • An Elegant Puzzle

  • Engineering Management for the Rest of Us

• Communities

  • Rand’s Leadership Slack

  • The LeadDev community

Hope you enjoy these, and I should be back next week with a fresh interview!

In our conversation, we talked about a number of parts of that journey. We talked about planning, ways to improve communication and shift updates from push to pull... but the biggest theme that emerged was this focus on process. How broken processes shows up for an engineer, how to get changes unstuck and moving through an organization, and then as a manager how to empower your engineers to do the same.

What is an example of a process change you tried to make while still an engineering IC?

We always had a problem on my team of too many tickets in the code review column. And so I started debugging, like, why is that? And we would talk about it in retros over and over and not ever try to figure out the root, which was: why aren't people reviewing other people's code.

And it turns out there were some, like we weren't given enough context, like all these things that you see now about what is a good PR, right? Write a good description, review the PR yourself as the person who's putting up the PR review it yourself, add comments, smaller PRs are often better than gigantic ones.

That's something that we had on our team. So people just didn't have the context and couldn't find time to invest two hours to review a certain PR. And so we did a couple of tactics. I don't know if you've seen these, where you kind of prefix as you're going through, you prefix a comment with like nit or education or like edu or suggestion or recommended something like that and that would help the feedback loop as well.

Did it work?

I think so, yeah, to an extent. I mean, that kind of change takes a long time. And teams change as well. So we get new people and they're like, "why are we doing these prefix things?"

And it's like, "well, let me tell you a story..." And then it's a good way to kind of educate them and to what makes a good PR.

The context thing I think was a big one, like have empathy for your teammate and that they haven't been staring at this for as long as you have. And what context do they need that they might not have coming into this PR?

You said this had been stuck in retros for a long time, why had it gotten stuck?

I think probably a similar reason why a lot of things get stuck in retros. I don't know if you've noticed this before, but there are a lot of things that come up over and over and over again. And so that could be people don't feel empowered to go and solve the problem, right?

An engineer might be like, "well, like this is a process thing and that's not my role." And maybe I don't have the experience to debug this problem or figure this out. Maybe I just don't observe it happening. I don't understand the impact. Like "so what we have too much, too many cards in code review. What's the problem? We'll get to it when we get to it."

And then also in retro, I find it hard to balance how deep we dig into a problem and not spending all of our time talking about one retro item. We do want to dig deep that, requires vulnerability and trust and all of these things. And so, I mean, imagine jumping into a retro and then like, "okay, everybody, how do you feel about this thing? And what can we do?" People aren't just off the bat ready to talk about this stuff.

And so I think it's all of those together and us maybe trying something and it not really working out in observing what the impact was of that change and then iterating and iterating and iterating, which is fine.

How did you end up getting the problem unstuck?

I think for us, the big reasons why things would get stuck was because people didn't have the context for some of these PRs and the PRs were so big. I mean, developers didn't even know this stuff was getting worked on sometimes and then would just see the PR come through and they're like, "well, I guess this isn't my repo, put up by my teammate. I don't know what, why, how important, what's the impact of this thing, I'll just put it off.

And so making sure that people have that context is something that we decided to address. And I think I just kept bringing it up, Kevin. I just kept bringing it up and over and over, like these PRs are taking me half a day, like two hours or something, and I need focus time, and then that impacts my other work.

I think I cared a lot about spending time and being meticulous with these PRs. And I think it's hard for me to say like, "Oh I'm gonna just let that sit there for another day." So it impacted me a lot. And I was, I think proactive about going and spending the time... it was like half a day, every day, you know, with these large PRs. And so I just kept bringing it up to my manager and talking about the impact.

How do you think about empowering engineers on your team to make similar changes?

I think it means to give people a lot of space to do whatever it is that needs to be done. And I do still sometimes go back and forth and struggle with this a little bit because how much is too much space, right?

It kind of goes back and forth between the mentoring versus coaching model. I prefer the coaching model and just asking questions and having people arrive at the solutions, like have them figure out what is the root cause of whatever problem that we're talking about and what can we track.

Like, how can we figure out how to solve this problem? And I think that method shows the engineers that they can solve these problems and they can figure this stuff out and they can do it without me. I don't need to be the one to take the action.

Yes, I want people to come to me and talk about problems that they're having. More often than not, it's not even something that I can solve myself, right? That I can figure out myself. And so I try to be like, "okay, so what can we do about this thing?" and see where it goes from there.

And sometimes they take the action and sometimes they don't. And they're like, "can you do this thing? "And I'm like, "yeah, I can do it." And then next time I'll be like, "okay, so you know what to do now, right? Now you can do it."

How do you help your engineers empower each other?

Yeah, that's a great question. I think having a culture of collaboration is automatically going to help here. And if you have certain engineers that already do feel empowered and do feel like they can just go out and solve whatever problems themselves themselves, and they do feel that ownership to fully own the code and our processes and the way our team works, then collaborating with other people, like whenever people come together to solve a problem, it's going to be much better, right?

Like they're going to come up with more ideas and also have more support in whatever changes they propose. And so I'll often say like, "oh, ask so and so for help," Or somebody will come and ask me a question and I'm like, "oh, that's a great question for a team chat." Put it in our team channel, and work with the team on it.

Even stuff like having an engineer set up a meeting to talk about something. When they set up a meeting, they're going to own that meeting. They owned the agenda. They own guiding the conversation, they own figuring out what they want the outcome to be.

And all I have to do is be like, "yeah, set up a meeting." And then the next time they're just going to do it, they don't need to come to me to say whatever, they're just going to be like, "Hey, Loren, I set up this meeting" or not even tell me, just put me as optional on the meeting. I'm like, "Oh, great. You're solving this problem. Awesome."

Links to Loren

• LinkedIn

This was such an interesting and ranging conversation. We talked about the tradeoffs of different business funding models, and how those play out into management choices. We dove deep into the knotty challenges that managers face navigating supporting their reports through various ups and downs. But more than anything, we talked about values, how they drive our work, and how high level values get operationalized into day to day work.

What are some of the trade-offs you end up making based on company funding models?

One of the biggest things that I learned early on about the VC startup world is the throwing money and people at a problem. And that has been actually a source of actually a lot of startups that I've been at really struggling later down the road.

Because for example, if CS is bombarded with a lot of issues, customers are reporting bugs or something like that, in the VC model, I was very accustomed to, "let's just hire more CS people and worry about the actual root cause of these issues later." Which down the line ends up becoming, "well, because we took shortcuts when we architected the system or we chose not to fix bugs and instead ship more features."

And so that whole... going fast and just kind of throwing more bodies or more money at a problem, definitely comes to bite you later on, I would say more often than not, right?

And so part of the intentional growth that I seek to bring into my teams is to have that conversation around what is the actual cause of the issue that we're trying to fix? And can that actually be fixed by us rethinking our methodology? Changing our processes, taking a step back and maybe delaying something on the roadmap... if it means that later down the line, you know, we don't have a headache from skipping this one maintenance task that really needs to be addressed.

Is there a framework you use to help make decisions around these types of tradeoffs?

I would say there's a lot of constraints to management in those discussions. I wouldn't say that there's a tried and true formula or anything like that, that I think about as I'm helping to guide teams to these types of decisions, but there are, I would say, different vectors or different aspects of the problem that, that I would look at as a result of these conversations.

And so it would be things like, "what is the current business priority?" And then almost like doing like a pros and cons list of if we took this route and did things according to this scenario, what is the possible and probable outcome versus the other route?

And then considering, okay, the business priorities, what do individual team members actually want to do or what do they feel strongly about potentially is like the right or the better thing to do? Does this align with maybe a longer term strategic thing that we're trying to do?

So, for example, the decision between, I don't know, let's just say like doing some optimizations for automation or something, you know, automated systems, whether it's like automated testing or maybe automating some deployment stuff that the team wants to do.

The trade-offs there are what's the opportunity cost, right? If we spend this time now, what do we potentially miss out on and are we okay with that? Is that worth the cost now? And so it's, it's really about balancing a bunch of those different kinds of constraints for sure

How do you think about the roles of values at work?

It is something that I think about a lot. And in fact, I'm having many conversations with my team members about this right now. I think for the purposes of building trust within a team and building credibility between leadership and the people who are actually executing on the leader's plans... that feeling of authenticity. Do the values reflect the behaviors?

I'm having a lot of conversations right now, for example, around, "So what are our values and how does it actually show up in day-to-day work?"

How does that show all the way up in how an engineer does a pull request comment? How does that show up in the way that people respond in Slack messages?

And you would think that, you know, some big grand values list that's on a marketing website doesn't have anything to do with that, but it really does. And so for me, it ends up becoming the thing that I do on many of the teams that I've joined in the past is to take the company values and one, do kind of like a gut check with people to see if like these values actually resonate with them and with how they work and then to actually start to codify a lot of that.

In terms of how do these values then get translated into practices, team norms, behaviors, and the way that we actually work together to make that more concrete.

Because everyone's interpretation of company values or even like personal values can be very different depending on who you ask, what their background is, how they were raised and what culture they grew up in and all those sorts of things.

And so there's so many ways to interpret this big broad value statement that it's really beneficial to get into the nitty gritty details of what that actually means.

How do you draw the connection from a high level value statement to e.g. how it shows up in a pull request (PR)?

Let me think about which value I want to pick out from our current list. So we have one value around learning: Always be learning. And that also coincides with a value that we also have around caring deeply about each other.

And so those two things are really important. And they can show up in PRs, for example. So what does it mean to care deeply, what does it mean to value learning?

When an engineer goes in to look at someone else's PR, that's an opportunity to potentially teach someone something or to share knowledge that you as a person may have that this person may not.

But then to care about someone means to be able to share that knowledge in a way where it's not to nitpick. It is not to deride or demean someone for not knowing a thing, but it's really like, "hey, on this line, I saw that you wrote X, Y, and Z, and perhaps a better way to do it would be ABC." In an effort to help you grow your own skills.

And so to just approach those PRs with a kindness, right? And to come at it with the intent of helping someone want to... help someone grow their career, is how something like those two values can trickle down into, let's just say, a PR comment.

How did you come to your personal set of values?

A lot of that comes from my own personal experiences. Professionally, there was the whole growth at all costs, right, in my early career that just I burnt out multiple times early in my career. So there was like that, that really influenced a lot of the values that I hold now.

But there was also the fact that I was often the only woman on the team. I was on a team where there were more people named Dave than there were women on the team. And then I had a child. So then I was also often the only mother on the team. And then oftentimes the the only Asian person on the team.

I think in these situations where I have been part of the group of others for so long... but then also having to figure out how to fit in. And how a lot of that just felt very inauthentic to me, but I did it in some ways for survival and to gain the credibility and the respect in order to do my job. I had to fit in.

And so I think all of those experiences are really what led me to where I'm at now, in terms of valuing people, valuing trust... and then knowing that there's other ways to build an organization that do not require all these things that generally happen in the startup world.

Because I've had that experience, like a positive experience at a company that was not a startup, and it was like a healthy one. And people were... able to be vulnerable with each other and to have hard conversations and make hard business decisions and favor people over profits.

And so knowing that there are successful businesses, however small, that I can do that just means that in, in tech and startups that we just haven't figured out how to scale that yet. And so that's where my values come from. That's what I'm trying to prove in the work that I'm doing.

Links to Amy

• LinkedIn

This was one of those interviews where I wanted to clip almost every section. We talked about values, the leader/leader model, organic metaphors for organizations, and more. I highly recommend listening to the entire interview. But the biggest theme in our conversation was around feedback and complex systems. How to set up feedback loops at different scales of an organization, why feedback is necessary to improve a complex system, and why every team is complex and how we can deal with that.

What types of systems do you set up for feedback loops as a director or VP?

Well, I think a very important one is what we commonly call like pulse checks. Engagement surveys and that sort of thing, which to be honest, I think these days get a bit of a bad rep and there's some survey fatigue, if you will.

And I can totally understand where that comes from. I've seen that done well and I've seen that done poorly as with anything else. What I learned, and what I seen working in my teams is you need to create an actual loop.

So when we talk about feedback, do we have a feedback loop? Do whatever we hear get fed back into the system? In other words, are we actually using this information, this signal, and feeding it back into the system to improve it? Are we changing as a result of having this conversation ongoing?

And where I see it done poorly is just this idea that, "OK, here's the whatever app we use for this. Give us your feedback." And then it's like people feel like they're shooting their feedback into a black hole or something of that kind, which is very demotivating as you can imagine.

I think it's the responsibility of leadership to establish that loop and to make sure that people understand how is that being used, what transformation, what change that is leading to.

One thing that I have to say since we're talking about this, that I pride myself looking back in my career, is that when I was a VP of engineering, I was able to establish... this feedback loop to a point where we had 100% response rate to these surveys. And I was very proud of that because I really wanted everyone to be invested in improving things and feeling like they did have a say and an impact in how we shape the organization. And so that was very gratifying.

So that's definitely one way that I think leaders can leverage much better than I think we're doing in general in the industry to improve their teams and their organizations.

What would you do to help people see where their feedback is going?

The first thing is to make the implicit explicit and just set the right expectations. We're doing this not just because it's something we're supposed to do, or just checking some box. We're doing this because we want to improve the way we work.

And this was something that was always very clear with every team that I joined. I certainly was not perfect at it, but I had the intention of always having a continuously improving organization. So that means that we need to learn. Hopefully every day, maybe every week at least, we need to keep improving things.

How do we improve? Well, the only way to improve a complex system is through feedback. And so I would try to connect these dots for people and create that awareness that we're doing this for a reason. Not just because it's fancy or it's what you're supposed to do, but because we need to collect this information so that we have a chance of saying, okay, what is most important here? What is the one thing that we can... tweak or change or improve that gets us to a better place as an entire team or organization.

So just setting those expectations, creating awareness and kind of creating a bit of inspiration around this, I think definitely helped create that activating energy, if you will, that got the ball rolling.

Then the question to your point is how do you keep the ball rolling? And so I would, for example, leverage all hands meetings and something that I used to do that I called the top-of-mind email where I would share regularly with the team on a weekly basis. What were my priorities, what was I seeing, et cetera, et cetera. And I would leverage, especially the all-hands meetings, where I would have a couple of slides that would summarize what I was seeing on the back end of the tool that we were using and what insights we were getting from that.

And then there would be a little bit of Q&A, and people would express whatever questions or suggestions or insights that they would have. And they would see then, OK, what are the actions that we're taking from here?

And then I would announce what those actions were. Obviously, they were articulated with my engineering leadership team, and we would try to collect as much feedback from other sources as well throughout the line. But ultimately, awareness, and then exposure, and then action. so that we see, okay, this is actually leading us somewhere.

What do you mean by a 'complex system' and how do you think about that?

I think one thing that really helps wrap our minds around this is something that is called the Cynefin framework that was created by Dave Snowden a while back. And basically Snowden is telling us that there are certain situations or problems in the world that are simple. Some of them are complicated. Some of them are complex and some are just downright chaotic.

And this distinction really matters because the way you tackle a simple versus a complicated versus a complex or a chaotic problem really is different. And I'll give a couple of examples.

When a problem is very simple, like I don't know, something at your house where it's completely predictable how to put up a fixture or something like that, there's a best practice for that. And usually it's not that hard.

When you have a complicated system, in that case, there are some good practices, usually requiring expertise. So for example, putting a budget together is something that I probably wouldn't do a very good job at, but a good CFO or a good accountant, they will know the tips and tricks and the techniques and so on and the good practices to put something like that together. But there's multiple ways of doing it competently.

When it comes to a complex system, then we have a different situation altogether. Because there's no necessarily good practice. Why? Because cause and effect cannot be predicted in a complex system. You can only see it after the fact, which means you need to run an experiment or multiple experiments to see what happens out there. And this is where the feedback comes in. And this is where something called safe-to-fail experiments come in.

So for example, to put this in more tangible terms, let's say a retrospective of an Agile team. A team of people is always going to be a complex system because it's the interaction between the parts, in this case people, it's the relationships and the way the information flows and how we work together that is going to dictate the results and the outcomes that emerge from those relationships.

But you cannot predict them beforehand just the same way that you cannot predict how traffic is going to flow. But we do things when we create certain constraints and we experiment with certain things.

I'll give you a quick example here in the city that I live in, Berlin, Germany. There's this huge street, one of the best known shopping streets in Berlin, that was closed off to traffic for two years or something like that. And I learned recently that there was actually an experiment to see how traffic would flow elsewhere in the city as a consequence of that street being just for walking only.

That's an example where we cannot predict, because how can we predict the behavior of people, right? But what we can do is that we can run that experiment and then we can look back and see what did we learn from this? Does it make sense to continue or not?

And so this is a very long way of saying that when you try to solve a complex problem as if it was complicated, you run into problems. Because the system, the complex system is not amenable to control and to prediction.

What are some patterns that show up regularly in the complex systems that are teams and organizations?

One pattern that immediately comes to mind, and I wrote in my newsletter recently about this, this individual Deming, Dr. Deming, who is known for what's called statistical process control, which is a bit of a mouthful.

And that was basically how he helped the United States win the Second World War, because the United States just completely out-manufactured in quantity and quality everybody else. But he also helped rebuild Japan after the war with the exact same method.

And a big part of that is what's called the PDSA cycle. Plan, do, study, act. And this concept is very simple. Plan something, do it, then study what happens and then act on that... as in, is that part of your process from now on or not.

And so you have this continuous improvement loop that is familiar to anyone that is into Kaizen and those sorts of approaches from the Japanese and Toyota being like maybe the most well-known example of that and the primary one. But ultimately that PDSA, that's essentially what you have with a retrospective, for example, an agile retrospective.

And so this is where I sometimes get a little bit upset. Maybe that's the right word. When I see teams that do retrospectives, but what they ultimately are doing is a box checking exercise because they're sort of blindly following some sort of a framework. Might be the start stop, continue might be the four L's might be whatever other esoteric framework there is.

But they are losing sight of the fact that the whole purpose of this is to iterate on the team itself and on its process of work... and then end up getting to the end of the retrospective either with nothing to show for it other than a good feeling, maybe, or with a long list of action points, because we're trying to please everybody and contemplate everybody's ideas. And then none of this actually gets tackled, and we perpetuate the cycle from that point on.

So back to your question, what is the pattern? Well, the pattern should be to have that continuous improvement loop and to use an engineering analogy that is familiar to both of us, I like to use semantic versionings, like your team is versioned.

Your team is like 1.5.6 right now, whatever that means. We don't want to go to version two in one shot, but we also don't want to stay stuck in 1.5.6. What is the .7 that gets us to a better place through the process of continuous improvement and leveraging retrospectives?

I think that's a good mental model to think and to kind of like go back to your question about what's the pattern. That would be one pattern of continuous improvement that I would be looking at, which, again, respects the complexity of the system. Because we're not saying this is going to work... we're saying this is our best shot as far as we can tell with information that we have. And then we're going to see what happens in two weeks later. We're going to reflect on that as a team.

What are other core principals of complex systems you have uncovered?

Well, one thing I would point out, and maybe this is coming back to the idea of mistreating complex systems as complicated and the attendant consequences of that, is that when you make that mistake and there's that confusion, and I think there's a big one that happens in most companies just by virtue of the way companies work and how they're organized, that ends up creating a lot of lack of success to begin with business-wise, but then in the process of that outcome, a lot of burnout and disengagement and people being unhappy and so on.

So maybe it's worth us exploring a little bit what I call the great disconnect, maybe in a grandiose way, but what I mean by that, right? And it's intimately connected to these aspects of complexity.

Long story short, the idea, and I realized that because when I was a VP of engineering, that's when I got the in a leadership team and reporting to a CEO that was not technical and being exposed to board meetings and meeting investors and understanding that, quote unquote, the game that was being played there was not necessarily the same game that was being played then in the teams that are building the product on the day to day. So that's where the disconnect lies.

And what I realized is that at that level, everyone is, typically in venture capital-backed companies, looking to the next milestone. How do we grow from here? How do we grow? What's the next milestone? How do we unlock the next funding round, et cetera, et cetera. Maybe that died down a little bit these days by virtue of the consequences. Maybe not, but definitely the game.

Let's examine what are the consequences of that game, because at that level of executives and leadership teams and boards and investors, what we're seeking, because we're constantly looking at the future and codifying what that future must look like in the form of a budget that has forecasts, that has all sorts of predictions... We need predictability. We want certainty. We want to make sure that we drive towards a certain outcome.

The problem is, what do you have, let's say as a CEO, what do you have to bring this reality about to make it real? Again, like you and I were talking about, we have a complex system made up of those humans that are unique and snowflakes and have ambitions and worries and fears and anxieties and all sorts of things. So. Here's the conundrum, right? The great disconnect that I was talking about.

You are seeking predictability and certainty through a complex system, which is not amenable to control, is not predictable where behavior emerges, and so on and so forth. And so when we think about it and we look at OKRs that pretty much everyone in a company is exposed to in some way, what we don't see is how those OKRs eventually ladder up to the company's OKRs and then they connect with the budget that then connects with some promises and things that must happen.

And so a lot of that pressure gets downloaded throughout the organization. And it tends to be about "we need to meet this target, we need to do this, we need to do that, we need to reach this and that," and ultimately creates a lot of silos because everyone is really trying to move their metric when the reality is that there's a ton of dependencies. And one thing we know is that often we cannot optimize both the local, so for example, the team and the global, which is the company.

So there's an inherent tension that kind of comes because of this disconnect, essentially, or at least partially explained by it, that creates a lot of problems on the day to day and a lot of changes in direction and a lot of bureaucracy that tries to kind of keep things in place just enough when the reality is that it's very unpredictable behavior emerges and we're back to all the tools that we were talking about, experiment, learn, experiment, learn, continuous improvement, et cetera, et cetera.

Resources that came up in the conversation

• Turn the Ship Around by Captain David Marquet.

• The 7 Habits of Highly Effective People by Stephen Covey

Links to Paulo

• Newsletter

• LinkedIn

In our conversation we talked about that transition, how he had to come up with new ways of thinking about what it means to do a good job, and how to determine what work matters. From there we went deeper into the human aspects of leadership, talking about vulnerability and mental health. Jamie has been open about his struggles with depression, speaking about them both publicly and in more private settings, and we talked about how doing that as a leader can open the door for people that are not in positions of power to talk about and seek care for their own mental health challenges.

Do you have a framework for assessing if you're doing a good job as a manager?

I think the first step of it was to, even for myself, just come to terms with the fact that my contributions were not going to be based in the code that I wrote.

That's what I was used to. And so when I started as a manager, if a problem would come up, I'd sort of be like, "oh, I can fix this". And it was sort of like a learning process to be like... sure, maybe I can fix this, but there are other ways that these can be fixed. It makes opportunities for other developers, giving people a chance to do this.

And Instead of that feeling of" I'm failing because there's a thing that I could do that I'm not doing", feeling like, "oh, this is actually a win in the sense that it's a learning opportunity for somebody else." It's a chance for me to spend time working on something that's higher leverage like communication alignment than fiddling with a PR that a senior dev can do way faster than me.

So part of it was just that mindset shift. I think the other part of it is understanding the time scale of what success looks like. I got into web development mainly because the feedback loop is so fast. I loved being able to write JavaScript or change CSS and immediately see what the impact was on the screen. I'd done back-end before that, and it was less rewarding to work for hours, days, months, and then hopefully data got transferred to the right place or whatever. It was just far less tangible and visible.

So front-end web development, feedback loop is very quick... management less so. So you're thinking in terms of years when it comes to people's growth, learning skills, getting promoted, all those kinds of things. So you also just have to like realize that your day to day activities are really going to be cumulative in terms of like major outcomes as opposed to you finish an eight hour day and you're like, "here are the 10 things that I like took from start to finish" because that just doesn't really happen anymore.

How do you help people know their work matters?

I think there's the easy answer to this, which I don't know if it's the most effective answer. I've worked in companies that are, say B2C for example, where you can point to, here's the feature that you're working on and like, here's a customer that's gonna use it.

And sure, therefore you know this work you're doing is improving their life in some way, which is like not wrong or anything, but. But again, I found that even that feedback loop is longer than you want it to be.

Like by the time a feature gets developed and tested and rolled out and through feature flags and A-B testing or whatever else it takes for it to finally get used. And then hopefully you get actual feedback from a customer saying, "this is a great thing." There's a long time between starting that process and ending that process.

So that may be the most direct line to draw, but it's not as tangible, or as rewarding maybe as developers want. So I think one of the things you can do is look at the people who are much closer to you and how your work impacts them.

Especially working with say, senior developers, mentoring for example or pairing are really nice, quick, tangible ways for you to realize that "okay, yes, sure. I'm helping a customer with this thing they need to do, but also , I'm helping this developer that I sit next to learn this skill or get this PR done or figure out what's wrong with this test, why it's failing."

And so that measurement of value and reward doesn't have to always be drawn all the way to like, the bottom line and ARR and customer satisfaction. There's lots of internal metrics for who it is that you're helping. and what your work is doing to benefit your peers.

How do you think about vulnerability as a leader?

I learned years ago that the more that I'm able to be vulnerable and share things with people, the more it gives them an opportunity to.

And this to me ties in with leadership and management because it almost becomes an obligation to some degree. The power dynamic is such that if I'm a manager and I'm speaking to a direct report, it is riskier for them to tell me certain things, right? They might be concerned about the precariousness of their position or even just basic stuff.

If they're worried that if they talk about struggles they're having they're going to get fired as opposed to supported, that's a very difficult place to have a relationship that is candid and is useful and valuable.

So for me, I look at it as, for me to be vulnerable, for me to talk about challenges I'm having and things like that, it just helps sort of open the door and like helps lead. And basically use the fact that I'm in this power position to be the one to approach it. To make a demonstration that like, "Yes, we can talk about this stuff and I'm willing to go first because, I have theoretically less to lose."

On how public speaking is different than you might think it is

I remember going to conferences and seeing the people presenting up on stage and being just in awe of these like these incredible, brilliant, wonderful people, like these celebrities or whatever it was.

And I remember a number of years ago, I sort of decided that getting into public speaking, presenting at conference was something I wanted to do.

When I got into it, I was like, "oh, I'm just a guy." There's nothing that magical about me getting up on stage and doing this. It's a skill, sure, and it's something you can practice, but it is not the sort of rarefied air that I thought it was, of only the most elite could possibly do this thing.

It's also nice to be able to relate to people on that kind of level, to reduce that gap. I've done speaking before, I coach people on public speaking and have done before because it's a skill you can learn, but also, it's neat.

I like going to conferences and having people come up to me and talk to me about stuff that I'm interested in because I gave a talk about it as opposed to me walking into a room full of strangers and being like, ugh, I have to make small talk.

On mental health and being a leader

I can sort of bring this back to, we were talking before about vulnerability. I have been pretty open with mental health challenges that I've had in the past. I have talked with public speaking, I have gotten up on stage multiple times and talked to people about my depression.

And again, that is something I feel like I can do. But I also feel like doing that, hopefully either opens the door or at least gives other people an opportunity to see someone in my position, being open and vulnerable about that.

It's not like... I don't go around waving a big flag about or carrying a big sign that says how depressed I am, but I mean, it's a humanizing thing.

And so it's both useful in... presenting and in public speaking... but we talked about building relationships in one-on-ones and because it's something that I've been open about and will be open about...

So at work, for example, like there are days where I just need to not be at work. I just can't, and need a day off. And historically that was sort of stigmatized. Like... you take a day off, you sort of have to explain it or whatever it is. And I think it's really valuable to give people an opportunity to take time off and give them the trust that if they need the time off, they should be able to take it without a detailed explanation of what's going on with them.

That being said, I am generally pretty open about the fact that like, if I'm taking a sort of mental health day or whatever, that this is why I'm doing it. And what that means is sometimes in, in one-on-ones and with relationships that I have with reports, they are more willing to talk about their challenges.

And I'm not a therapist, I'm not a doctor, and the point of that is not sort of like, so I can help them with it, but at least I can accommodate more effectively, I think. If they're able to tell me what's going on, again, I have no interest in being sort of intrusive and knowing more than I need to know about people's lives, but it's sometimes useful context to know that this person is dealing with a long-term health condition and they're having a difficult time with it right now, or they're dealing with something at home that is very stressful and it's been affecting their performance at work.

If people aren't willing to talk about that, then I think you can get into situations where, if performance gets impacted, you don't want to make assumptions about, "oh, you know what, this person's just sort of not working out," when in fact they have a real situation at home, it's making it very hard for them to concentrate at work.

So the vulnerability piece for me, is leading or being the one to open that door by talking about some of my own challenges. And... often that leads to people being more open with theirs, which in turn means I can support them better, which is great.

Links to Jamie

• LinkedIn

• Website

Of course we talked about that system in our conversation. And it was striking to me how many of the methods that work for data analytics stakeholders are similar to methods I've used in software development. But the conversation didn't stop there - we moved through stakeholder management into cultural norms, communication, and how to teach yourself to succeed in U.S. corporate culture, even if you come from somewhere with very different norms.

Note: We had some audio challenges at the start. I cleaned up as best I could, but if you find them bothering you, skip forward to about the 8 minute mark.

How do you communicate with people with very different backgrounds than yours?

The first step is listening.

As simple as it is, but it's extremely crucial that when, for example, law enforcement, when they come to you, what usually happens is that they want a yes and no answer because that's what they do. Yes, there's a fraud, we're gonna do a warrant, arrest that person, no, we do nothing.

But the thing is, you know how data analytics is, like it's not a clear answer. and I don't want accidentally send people to jail so what I do is I listen to what they're saying and they said they have this need to do X, Y, and Z.

And then I just take a step back: look this is what it is and I hear what you say and I paraphrase like you say A, B, and Z this is what I'm hearing is that right?

They were like "oh it's right" so then we can get to the point that you can find the problems And usually the problems is not what they say.

Like they say, maybe it's just a problem of unclear data, or maybe it's a problem of they need different kinds of data pulled. And if you don't listen and paraphrase, you're never gonna get there. So that is the beginning.

What techniques do you use for paraphrasing back to stakeholders?

There are actually three levels. The first level is the easiest one. It's called repeat.

So if I don't know anything about you, let's say I'm talking to an astronaut and I suck at physics. Okay. He says something I understand. Or she says something I don't understand. I'm just going to say it back to him.

"Are you saying that the aerospace pressure is going to do this to the spaceship?" I'm basically repeating it. And then people understand like social curiousity is there like, they're "okay, so this person doesn't really understand what I'm saying at all. "And so they say in a different way.

It's a way to push the conversation forward without saying, "I have a dumb question" or something that disrupts the communication flow. That's not what I want, I want the conversation to flow not be transactional and so that's first step.

If you don't know anything about like finance or you know let's say SAP - just completely out of it - you're like "okay so this is what you said". That's the first step.

Once you get over that... and hopefully when you're that naive there's managers or your stakeholders that can help you out a little bit... once you get to the second step it's called saying your own words.

For example the accountants they're like, "oh you know we need to close this month there are certain things that ref 606" and you're like "what's ref 606?" and they just keep going on and on. So you can say "Did I hear right? that you say you want to close the book " -so this is my own words I'm not saying close the month - "you want to close the book, you want certain summaries you're not getting it is that right?"

This is level second, I am internalizing it with my own words. This takes a lot of time to practice. If you have contact with these people it's getting easier.

The third level is the level that I strive to do... it's also going to take the longest but it's the most effective one. If the financial people come to you you're not going to say "okay so how the company is doing" you're not going to say "oh how's it going? how much money do I make?" That doesn't make any sense. You have to talk about EBITDA.

That is the word they're using to assess the health of the company for the lender, for anyone that they talk to the board. Because I worked with them for a while, I can be like "oh you want EBITDA? okay so I can get it for you". And that's because I have accumulated experience to the point that I'm not even saying my own word or repeating I'm talking in their own lingo and that's how I see the progression of paraphrasing. But it takes practice.

On communication with stakeholders during a project:

After you get a solution, you go through all the difficult part of prioritizing, making everyone like commit to that solution, budget, time, efficiency, whatever. Then you start the project. This is when things kind of just go sideways, because you start, everyone was like, great, we want to start. But then no communication until the delivery.

That's usually what happened, right? It's kind of just radio science. I think it's most of the time just busy, you know, people are busy. It's not a rhythm, something that they do project by project. And so I want to implement this communicate regularly.

And how do you do that? There are some details I provide in the seventh step. Communicate regularly doesn't mean you have to talk to everyone every day, once a day, at stand up. No. You have to look at it more holistically. Every group has a personality. I

I work with some groups, they love doing Monday.com. We have tasks. We tag each other. We update regularly. We don't talk to each other that much. It's task driven. Fine. That's fine. As long as everyone's happy, right?

And there's some group, they don't have any set process. They just like when you show them, oh here's the progress once a week. Or a short email like, this is what happened. Or even by asking questions like, oh, this data point, is that how you need it? And they were like, "oh yeah."

Even that little conversation is counted as regular communication because they see that there is progress being made. That's why you have problems or questions.

So I think that it has to be to the group's personality. If they want an update every day, not recommending it, but do it. And if they don't bother, they just want to know that things are making progress, do it once a week or maybe twice a week you have a demo. "This is how what it looks like right now. Anything you want to add, do you like the color, the arrangement?"

And this gets to a point that you also want to make sure all the key stakeholders are there. Who are the key stakeholders? Because if you talk to the key stakeholders helper, the helper knows what you're doing, but the stakeholder doesn't know.

And this is about looking better. Everything that I do, I have to be very intentional. There's so many people that have different things that distract them. You want to make sure that the people really know that you're doing it, and then you're showing them the results. And the key users will see it. And that is the process.

What is the goal of continuous communication?

Let's say you start off on step A. Usually what happens is the stakeholders realize they want more because they see what you show them... "I didn't know that power BI can do this", "I want to add this graph", and so from the data people's perspective they're like "oh scope creep. I don't want scope creep".

I see this as increase in trust because they know you can do it. So you say okay, but that doesn't mean that you need to do all the stuff in the same time frame. It just means that, okay, you want to add three, four more things. Can we extend the project a little bit? And I'll still show you the weekly progress. Are we okay?

Most likely they will say yes, because there are more things that needs to be done. And so you just have to keep up with it. That's why the regular communication is so important because they are going to change their mind, add new things, or you're gonna realize something is wrong with their backend database that might need some time to be fixed. And you wanna save that time for that. And they need to know about it. This delay is not caused by you.

What are some cultural nuances in the workplace you've noticed moving from Taiwan to the U.S?

When I came to the States I realized how Americans say it is that they tell you what it is and then provide the reasons. It's like thesis statement, then blah blah.

In Chinese culture, I don't know about other Asian culture, it's the opposite. You first explain the need. "Oh, because the company needs this and it will be faster and so that's why we need a dashboard." In America, it's like "we need a dashboard. because blah blah." It's the opposite.

So when you talk to an American colleague, you want to make sure you get to the point. I always tell people "Just tell people in 30 seconds what you want to say". Like "I want to help you build a dashboard." That's the end the story. That's basically what I do right. I want to build a database or I'm here to help you with your data problems. The end. Then like "oh I have years of experience in data engineering" and I have this. Doesn't matter. You're here to solve their problems. Just say it and then you can say I can solve your problem because blah blah.

And so that's something that I've seen, with different contractors form different countries. You just have to get to the point. That is not how Chinese speak but that's how Americans do. Most of the time, you have to to get to a point like super fast.

Also if you want something just say it. You don't have to be like "um I don't know like I really want this but well.. if I do well people notice."

No. You yourself is a product. I'm talking to you, I'm selling you something. I mean not physical things, but I'm selling you my expertise, I'm selling you my personality,.I want your attention, I want to buy your attention, so just say it, right?

I mean how we come up with this podcast is very obvious example. You said you want someone that knows the human side of things. I tell you that I just wrote a book about it. So I'm telling you I want to be on your podcast. I'm not waiting for you to be like "oh Mo wrote a book maybe she's good to be on my podcast."

I just fill in the blank for you. I want it. And if you don't want me to be on your podcast that's fine. At least I said it.

How did you teach yourself to be blunt and say what you want?

I do feel uncomfortable when I say things I want that might be too blunt. But I'm convincing myself that there are two things that will happen. I like to say that "crybaby gets some milk," it doesn't matter what the baby is sick or the baby really needs milk, if it cries, it will get the milk.

There are many people in this world, they might not be as competent as you are, but they get what you want. Why? Because they asked for it. They might take time to match up to your level, but eventually they get it. They win in that sense.

So I tell myself, if I want something and I'm not saying it, and people that are not as good as I am, they get it... I'm happy for them. Because they have the courage to ask for it. And if I don't do that, I'm doing myself a disservice.

So yes, the process is very painful because you gotta say exactly what you want. Your culturally not inclined to do this. Your personality prevents you from doing that. But think about it, what is the downside of this? You don't get anything. Is that good? So that's one way I convince myself.

And second, is I've noticed that American culture rewards upfront attitude. That's also a thing that we can take advantage of. The American culture rewards people who are bold and upfront about what they want. It might not work in China or Taiwan. I can tell you that it does not work in Taiwan, but it works here. And why not take advantage of that?

Links to Mo

• Mo’s Book: Data Insights Delivered: 7 Proven Steps to Understand Stakeholders, Manage Expectations, and Deliver Actual Value

• LinkedIn

• Website

In our conversation we talked about some of those team dysfunctions, and Joel shared a great story of breaking out of disfunction by creating alignment across engineering, customer success, and sales. But that isn't what stood out to me most in this conversation.

This discussion of dysfunction led us into the question of decision making, and that became the common thread through the majority of the conversation. Where decision should live in an organization, how making decisions quickly is often more important than making them perfectly, different models of decision making and how they break down, and how you can step into a decision making gap even without explicit authority to break through a logjam and make things happen.

How do you think about where decisions should live in an organization?

There's a book, Turn the Ship Around, which I think has been quite influential on me. It's written by a nuclear submarine captain. He talked about intentional leadership and delegating decisions to where the information is.

And so I think that's a really good start, in terms of making sure that decisions are made as close to the coal face as possible. But he also talked about, well, the one decision he wasn't going to delegate was launching missiles, that's on the captain there.

And I think that's important as well to think about the things that you wouldn't delegate.

I think it's really important here that you have to teach your teams to do this. It's not enough to just say, "I won't make decisions." That's not helpful in itself. Um, and so as you say, you do have to consider for each decision, what's the decision you're going to hold onto, what's the decision you're, going to let the team make, for example, but you want to be informed about, which decisions you'd like them to just make without even telling you what's going on.

And clearly your team are making decisions every day. They're sat there, at the bare minimum, they're sat there coding and they're deciding what lines of code to write, you want them to do that. So where do you find those boundaries?

And I think there's a level of comfort you need to get to when you're leading a team, to take responsibility for decisions that you're not gonna be involved in.

As a CTO, if you have 100 people in your team or 50 people in your team, they're all gonna be making decisions every day that don't go through you. And so highlighting to them the decisions that you don't want them to make without you is really important.

And there you should be thinking about where if they make a decision different from the one that you would be comfortable with, you'd want to overturn it, for example.

And I think the answer to which decisions you do that on is the perennial "it depends."

On why making a decision quickly is often more valuable than making the right decision

I think that's something we often underestimate. It feels like the the cost of not making a decision is zero. That's often what we implicitly, whether we explicitly say it to ourselves or not, feel.

And that's definitely not the case. I think many of these decisions are too complex to decide on by pure analysis. A lot of the work we do in software development is in that complex space. And any assessment... relies on so many guesses about what the future will hold, that it's very hard to have confidence in them.

And so I think if I wind back what I said earlier, I think it's about trying to get feedback from the system as soon as possible. So try, as soon as you can try a thing, try it and get working with it, and then see what feedback that gives you to... keep deciding how to change

How do you deal with a team that wants to keep relitigating a decision?

I think this is a real responsibility when you're leading a team. In an ideal world, everyone roughly agrees on things. You'd like to believe that there is a way of reasoning to an answer that everyone will be happy with.

And in practice, that's not true, and some of this will be at the level of tabs versus spaces and some of it will be at a level that really does matter.

As a leader, if you're seeing your team thrashing about, then it is up to you to squash that thrashing about and take responsibility for that decision. Take that responsibility away from the team... for their own good.

And you can explain why you're doing it. I'm laying down the law as the authority in this space. This is the decision we're going with at the moment.

And you can, depending on what it is, perhaps offer up the conditions under which you would change your mind. Maybe it's to do with where the focus of the team is, and it's like, well, when we've raised our next tranche of money, we can revisit this. Or when we're getting too many bugs every day or whatever it is,depending on the decision you're making.

So you can be explicit with the team about what you would allow to change the decision. But I think that taking that decision away from the team when they're finding it really hard releases them from worrying about it to a certain extent.

What type of education do you need to do with your reports around decisions?

There's a few things going on here, I think.

One is assumptions people have about leadership and about leadership making decisions. Often people will come to you to make decisions because they believe you're the person who should make the decision. Whether or not you know most about the decision or not. Whether or not you are the right person to do it.

And so I think it's important to be aware of that, as a leader, that's going to be a natural thing to happen. And I think there, when someone comes to ask you to make a decision for them that you feel is not decision you should be making.

So for example, maybe your tech lead comes to you and says, well, "We're choosing whether to build a feature flag system or buy a feature flag system. Joel, tell me what I should do." The first thing you can do is lead with curiosity there.

Find out from them what they already know and what they think the decision should be. Ask people the question, "If you ran the team, what would you decide? What do you recommend?"

And often they will have a strong opinion on that. And then you can ask them why, what's behind that strong opinion. Maybe your tech lead says, "Well, I don't think it matters a great deal which one we pick, as long as we pick one and we start working with it and we're ready to change our mind. And so I think we should build a little system. It'll only take us a few days and start using it and see how we get on."

And so if you can get them to tell you what decision to make, and you can then ask them why you need to be involved in the decision. What do I need to add to this? And so that's the sort of conversation you can go through around learning.

I think another way is having explicit discussions about this. I think it's really good to set expectations with one another. Certainly with your reports. "These are the sorts of decisions I want you to make. These are the sorts of decisions I want you to talk to me before you make. And these are the sorts of decisions I want you to make sure that I make."

And you can make it explicit with them that you want to move things down the track with them. This won't be the same with everyone who's a report to you, depending on their areas of expertise, depending on their experience. But you can set it as goal.

If you're explicit about these things, then when we next have our review, I would love to be saying, you can make these decisions. All right, what do we need to make happen in order for that to be true?

So again, that's a way of you both thinking and being explicit about this. And it's also really important to tell them that not everything will feel like it's covered by any explicit arrangement and that we both understand that sometimes we'll get it wrong.

They'll push a decision towards me that maybe I shouldn't be the one to answer. Maybe they should make that decision. But similarly they'll make some decisions and I will be gasping... But, they've made it. That was their best call. We can talk about how to learn from that in the future, but that doesn't mean we have to overturn the decision.

What are different models of decisionmaking you've seen and transitions between them?

One of the teams around, there was a real heavy focus on collaboration. And that translated in the team often to assumptions being made that every decision needed to unanimous.

That makes decision making really hard, and particularly as a team grows. If you've got three people in the team being unanimous, that's not that hard. It's possible for all sorts of things, but it will still slow you down.

If you've got 10 people in the team, there's almost nothing that will have a unanimous decision. And so there,I think firstly, having those explicit conversations about why, the cost of waiting for a unanimous decision is really important.

And I think being able to tell stories about collaboration that aren't the same as every decision being unanimous. Collaboration is about people sharing their expertise. It's about people inputting into decisions, but it is not about every decision being unanimous. Talk about disagree and commit as being important.

I think in teams like that, it's really useful to introduce very explicit models for making decisions. And so one model is, "we'll only decide this if we're unanimous." That's maybe a model that a team has been working on for a while.

But you can introduce different models, so maybe, well, "This decision is Kevin's decision. He's going to decide, but he's going to talk to all of you beforehand, you know, so he's going to get your input and then given all that input, you trust Kevin. He's a sensible guy. He knows a lot, you know, and we're going to go with his decision. We're going to back it." So that's another model.

Or you can go for some decisions, it may make sense to have a voting model. And again, if you're open ahead of time, "On this, we're gonna decide what the majority thinks." That can be useful.

But I think that setting the situation up so you say how the decision is going to be made before it's made really helps with all the interactions. If you say, "Kevin's going to make the decision, but he's listening to everyone," then that gives everyone the opportunity to speak to Kevin, talk to him about what's going on, share their views.

But then they know they're not responsible for the outcome of the decision. And so that can make it freer for them to speak, for example. So yeah, so I think being explicit about the mode of making a decision. And you can have a conversation if need be about why that mode has been chosen for that particular decision.

On decisionmaking in startups and scaleups

I think on decision-making, we talked about it from a leadership perspective, but one of the things that I see happen a lot in startups and scale-ups is decisions not being made because no one's really sure who can make the decision.

In an organization that's very stable, you feel like, "oh, there's these responsibilities written down, you feel somehow it's clear." I think in practice it's often not, but in startups, you can see things get stuck because people are worrying too much about who makes the decision and I think there are a couple of tactics you can use that are really helpful there.

One is imagine that you're making the decision and that it is yours to make. What do you need to know? What help do you need in order to make that decision, to make a good decision? And then who you're perhaps consulting there and finding out information from.

I think this can work really well with being open about your intent. "So look, I'm not sure who can make this decision. So I think I should make it. Here's what I'm gonna do. Here's who I'm gonna involve. Shout if you're unhappy. If you don't shout, Friday or whatever, this is, you know, I'll assume I can make this decision."

And so I think that being really open about your intent and then thinking about what you need to make decision can give you a lot of power when you've been stuck with this.

For example, there aren't training budgets in this company. I don't know how much money I can spend on training. Can I do this or not? A you talk to your boss and they go, "well, I don't know, we don't have training budgets either." We haven't sorted them out. I don't know who you speak to.

So you can go, great, no problem... all the people who might need to be involved. That's my boss. Maybe it's the CFO because he manages all the money. I'm going to make this decision. Here's why I think it should be done. Tell me if you think I'm wrong. Otherwise, I'll book it on Friday.

That can be a really useful way through those impulses.

Links to Joel

• Website

• LinkedIn

Not many people can put "Chief of Staff at Google" on their resume. But Eric Nehrlich can. He held the role for almost seven years, reporting up to the product VP of Google's Search Ads team. Knowing only that about him, you might assume our conversation would be about productivity, career success, and effectiveness in a high-powered leadership role.

But this conversation is much more human than that. Eric, like many of us, worked himself almost to death because he assumed that was what success looked like, and almost convinced himself there was no other choice. Until his own body forced him to reconsider, and the realizations he had set him on the path to his role today, as an executive coach.

Choice was the theme that kept coming up. The ways we overconstrain ourselves, lose track of the choices we are making, and how that traps us in cycles that are not only painful but also reduce our impact. Eric shared compelling stories of himself and others, continually highlighting our ability to make choices that align with our values, get comfortable not making everybody happy, and dramatically increase our impact.

Please enjoy this conversation with Eric Nehrlich

Do you have practices you recommend to identify what is important to you?

Yeah. Oh boy, there's a bunch I could go with, but I'll start with two that come to mind. One is just tracking energy. And that may seem like a very internal metric, but I find that when people are in the flow and they feel energized by what they're doing, they get more done. They're more excited by what they do, and they're more effective at what they do.

And so... people who are doing work they find energizing all day get more done, because they have more energy. And so that's kind of an internal metric that can be very effective to help understand the types of activities that maybe one is drawn to.

And then a more external metric is, a question I often ask is, "who do you want to serve?" And here's the thing, especially as you become a leader, you can't keep everybody happy.

This is something that drives a lot of my clients crazy. Because they're used to being able to excel and get the gold star from everybody. And everybody gets some give us an A plus and they exceed expectations for everybody. Then you reach a certain scope as a leader, and you have people that want different things under you. You can't keep them both happy.

It's like, "well, what do I do? How do I keep them both happy?" I'm like, "you can't, you have to choose." They're like, "But then somebody's gonna be unhappy with me." Like, yeah? What do I do? You choose. There's no secret here. There's no magic trick I have to give you that keeps everybody happy.

The best you can do is articulate, "this is what I'm doing, this is how I'm serving, this is the principle I'm using to make this decision." And some people will be unhappy, but at least they'll understand.

So to circle back to your point about impact, if I've chosen that I'm going to prioritize the team under me.. Great. You have a metric. I can get them promoted. I can increase their scope, so forth and so on.

If you're saying I'm going to prioritize the company, which is what you kind of should be doing as an executive, then the company metrics are a good proxy. Or if you're working in a nonprofit, you could say, it's the community we want to help. How are they benefiting from what we do? Whatever it is, you can find the people you want to help and some measure of their success and use that as a proxy.

How do you get comfortable with not being able to make everyone happy?

It starts by trying it.

I mean, there's really no answer here. So I guess I have two stories I'll share here. One was... I worked at Google for many years. And early into my time at Google, I was working way too much, like 8 AM to midnight every day. Sometimes I would take Saturday afternoons off. It was brutal.

And the really annoying part was I was not actually being that effective or impactful. I'm like, "this is not working for me." And my director at the time, a guy named Sanjay Dutta, who is now the CFO of Upstart.

He was very effective, very impactful, people up to and including Eric Schmidt, the CEO and Patrick Pichette, the CFO would listen to him. And he left work at 6 PM each day.

I'm like, "how the hell do you do that?" He's like, "Well. I come to work and I work on the most important thing first. If I don't get to the next thing, that's okay. It's not as important."

And you're like, that can't be that easy. But the secret of what he did was he chose what was most important. People would send him email... He would never respond to emails. People would put meetings on his calendar. He would never show up. The only thing he would work on is the thing he was doing for the CEO and CFO. And everybody else could wait.

And they would be annoyed with him... they'd be like, "you're not responding. Why aren't you boing to my meeting? I set this meeting up with you." He was like, "I'm working on something more important."

And the contrast between what he did and what I was doing was I would show up, I'd spend two hours on email when I get to work. I'd go to six hours of meetings with anybody who put time on my calendar. I'd do another round of email at 5 p.m. and then at 6 p.m... there's one thing I had to get done that day and I hadn't started on it. Which is why I was working until midnight every night.

And he just didn't do any of that. He just started on that thing at 9 a.m. when he got to work. And then whatever time he had left over, then he would spend on emails and meetings.

I think, to answer your question, how do you learn to do it? Seeing the difference in impact that he had by being willing to just tell people no and say this is more important was really critical for me.

On choosing your work for impact

Here's the thing about high performers: they could do a lot of things and they could do a lot of things well. So just because you can do something and even that you can do it well does not mean it's a good use of your time.

This is where we introduce the idea of opportunity cost. What else could you be doing with your time that could be doing more, it could be more valuable?

An advisor I heard about once asked the question, "are you doing $80 an hour work when you could be doing $8,000 an hour work?" And I just love that because it's like $80 an hour work is valuable. That's an important work. It's not just something you get somebody off the street to do. It's important.

But if you're the CEO of your startup and you're not setting the strategic direction and you're not doing fundraising and you're not figuring out the culture and the things that are holding your team back, that is millions in opportunities you're missing. And if you're filling out your expense reports instead of doing that, it's like, what the hell are you doing? So I think that idea of opportunity cost is really another kind of key concept here.

How do you help people realize they have more choices than they believe?

I'd like to believe that I help people see that as a coach. And I've helped a few people through to understand the options that are more available to them than they think by asking them to talk me through. Like, okay, so what happens if you don't make your manager happy? If you don't get that promotion, if you don't, whatever.

And talking it through and then sharing my own story often helps them go, oh, wait. Maybe there's a possibility.

This is where I often use the framework of experiments to help people kind of realize they have a choice. Like, I'm not saying like quit your job tomorrow and go do something else. I'm saying "what happens if you push back on this one thing in a small, safe way?"

"Oh, they'd never accept that."

I'm like, "can we try it? "And they try it and like, "huh, that didn't go as I expected." And then we can kind of extend a little further and a little further. And that's how you can realize there's more choice available.

One exercise I actually run people through is to think of somebody that they know who has what they want. It could be executive presence, it could be influence, it could be lots of things.

Okay, look at that person. Watch what they do. And then look at what you do. What's different? They're like, "oh, well, that person has these conversations, that person does this," whatever it is. There's your first experiment. Can you try being more like that? And they try it.

And sometimes it works and sometimes it doesn't, but it's like, okay, now at least we're in a different loop. It's not "I can't do it". It's like, "oh, what's a different thing I could try?"

I think that's the hardest step is realizing I could try something different and coming up with something to try that is not just the default reaction that I've learned over the previous decades of my life that's been very effective for me, that got me to where I am.

Because that's why it's so hard. to change because it means letting go of something that works. Like I have this tool that works great. And you're asking me to put it down and pick up something that I don't know how to use. I don't like that. Understandably so. And that's why I'm talking to you. I want to share it. You can try something different.

On how we overconstrain ourselves

I work with a lot of engineering leaders. So I often put this in terms of loosening constraints. Your problem is over constrained. That's why you're stuck.

Cause you have this rule that says you can only do this and this rule that says you can only do this and this rule that says you can only do this. And there's no room at the middle that allows you to move. And that's why you're stuck.

So how can we loosen one of those constraints? I once saw at a workshop, this guy worked with a client, basically live coaching them. And the rule they had was "I can never ask for help."

And that was kind of a good rule as an engineer in a lot of ways, because it's like, I'm going to figure this out. I'm going to solve the problem. I'm going to show that I can be independent and learn it myself.

But there's times when it holds you back. There's times... I mean this was many years ago. This is before like Stack Overflow and things like that. It's like, no, of course you just look it up on Stack Overflow. But this guy worked with this person around "I can never ask for help."

Well, let's invert that. "I never want to ask for help". Or "I can ask for help if these conditions apply."

Like there's an expert I know, or I'm physically limited for some reason or whatever. And you start realizing, oh, there's exceptions. I can create exceptions for myself around this and then loosen that constraint a little bit.

And if you do that for a number of constraints, you're like, "oh wait, now there's some room to move." But when you put these mental models or these rules in terms of absolutes, "I must always," "I can never," that's when you get really stuck.

On how you can start loosening the constraints you have placed on yourself

A thought experiment that can help there is, you mentioned different domains, and it's like when you impose a different domain, how this changes. "Oh, I could never take time off work."

Okay, what if your mom or your spouse or your kid gets sick and you take them to the hospital? Well, of course I would leave work for that. Okay, we've now shown that is not an inviolable rule. So what is important enough to you that you would take away, step away from work for? And then it becomes a matter of a trade-off.

I remember one client I worked with, he had this important strategic vision document he was working on and he hadn't made progress literally in four months. He's like, "I just need four hours to concentrate."

And I'm like, "and you haven't made progress?"

He's like, "yeah." I'm like, "is it important?"

He's like, "it's really important. This is going to set the direction of what we're doing for the next year."

What the hell are you doing, first of all? And secondly. you're going to be sick on Friday.

He's like, "what do you mean you're sick?"

I'm like, "you are taking a sick day on Friday. Because if you were sick, you would stay home and be in bed and your team would figure out how to get along without you. So you're going to do that, except instead of being sick, you're going to actually get this document done with one day of uninterrupted time."

He's like, "can I do that?"

I'm like, "I dunno, maybe let's try it and see what happens."

And he did it. Actually, he didn't have to do it. Once I told him that, he's like, "I could actually just clear my schedule on Friday afternoon and do this without taking a sick day." Great.

And then having given himself that permission, it was like, "oh, I can do this whenever I think something's important enough to do this." But he had been so fixated on the idea that a good leader in his head was responsive, always available on Slack and email. able to get back to you right away, unblock you so quickly that he was like, "I can't walk away. I can't. People are always picking me for stuff."

They're picking you for stuff because you're always available.

Links for Eric

• Eric’s recommended resources page

• Eric on the web

• Eric’s upcoming book

• Eric’s newsletter

• LinkedIn

He is an incredibly clear thinker with a very fast and clever wit, and in this conversation he managed to boil down almost all of engineering and product development to a single tool: Checklists. With the core tool of checklists and the core goal of systematically destroying ambiguity, we spanned an incredible range of important topics of personal and team productivity, deadlines, and more.

Note: I will be traveling next week, and so will not ship an interview. The next Human Skills interview will come out on August 15.

Do you have things that you have gamified for yourself?

Yes, in that everybody loves a checklist. So that's a productivity thing that is good for me and good for the people that I have to foist tasks upon. You know you love checking the box. You love the dopamine hit and you love like, "here, we're getting closer to having zero things left to do.

And assuming you're not a project manager and derive innate joy from burndown charts... you do probably derive joy from watching the thing or being done with the thing. Or having accomplished it.

Plus, I think in checklists. People will write paragraphs and paragraphs of text, that I will write in bullet points instead. But whatever form the list takes, having the list brings like clarity to everybody, to yourself and everybody around you.

And actually, I was thinking about this in the shower this morning. of like, "what should I maybe bring up with Kevin?" I think it's ambiguity that destroys velocity almost faster than anything else.

Ambiguity of like, "what are we gonna build?" or "how are we supposed to build this?" Or was it supposed to be A or B or why did we make this decision? So having the checklist of "this is the thing," it is a very, very cheap way to eliminate most of the ambiguity.

And then everybody feels good because they're like chugging along the top speed instead of kind of thrashing between tasks to figure out what's happening.

Do you have other tactics you use to move from ambiguity to clarity?

The checklist is 95% of my tools. Because somebody says, "hey, how is this thing?" And the answer is this way, this way, and that way, right? Or "hey, how are we going to do this thing?" And the answer is ABC.

You do at times need to elaborate... and so that gets more into the one to many communication on how the project is going to go down or has gone down or maybe is currently going down... or in better cases up.

There's a book that I should read called The Checklist Manifesto by the surgeon general. I forget his name. He's a doctor. I think a surgeon, where checklists are important, right? In the same way that they're important for airplanes.

I should probably read this book, given my love of checklists. But I also kind of assume that I know what's inside. I should probably verify that.

So the other thing is, like in non-checklist formats, the heuristic that I try to employ whether it's a ticket or a tech spec or a project one pager or whatever, the heuristic I try for is: if I close my eyes for some substantial amount of time... If I go chill on a beach for a bit, and then I come back, has what happened been substantially similar to what I thought was going to happen?

And how can I write this document or whatever it is in such a way that that is likely to happen? So in a ticket, that means, a clear acceptance criteria. However you want to do your tickets and in whatever ticket tracking system you're using, whether it's a checklist in a VIM file or Jira. Write down, "this is what we need to do," If you know anything about where to do it, give them pointers. They don't have to start from scratch. Whoever picks it up. And then acceptance criteria.

I've been in so many retrospectives where the team was like, "we need better acceptance criteria." And then a month later, "we need better acceptance criteria." It's like, OK, "what happened? All you had to do was write it."

That works in tickets, that works in tech specs... here's what I know, here's what we still need to find out, here's, given what I know is how I think we should go about this. And very importantly in there, wait, why are we doing this again? Not from the, "what is the purpose of this project" perspective, from the, "why did we choose this way" perspective?

Write down the ways you didn't choose, for God's sake. Because otherwise you're gonna run into... every approach has a problem and as soon as somebody runs into the problem they're gonna say "oh, why didn't we do it the other way?"

If you write down why you didn't do it the other way they'll look at it and be like "oh, right, right. Yeah, it sounded worse the other way" and they can move on. Otherwise the same conversation happens again.

What goes into writing useful acceptance criteria?

To sort of put it in one sentence, it should be a clear statement of "the thing that happens when." Like when I load this page and I click this button and I enter this data and I click this other button, this is the result.

There are a bunch of things implied in that of like, I didn't find any errors along the way. Those are obvious, people will find those.

But you need that simple statement of the desired fact to be clear and everybody can infer what needs to happen to get there. People use phrases like outcome-driven development or whatever the thing is. Here's the outcome. I try this and this happens.

Whether you're front-end or back-end or wherever, it's going to change maybe what that means.

I'm nearly a hundred percent back-end. So my acceptance criteria is the case analysis resident in the unit tests. You had these inputs. They had these ranges they could all cover. And so you've picked interesting cases from each and in all their combinations. And you've proved to me in a test that that is what happens. So from the backend, I feel like the unit tests are the acceptance criteria. And the case analysis.

When you're writing a ticket, you don't want to be doing that. That's the job of the person building it to think through. But they need at least enough to go on of like, when somebody in the UI clicks this, this thing happens, okay, that boils down to this backend function, here are my domains and ranges, and then I've walked through all the possibilities.

That's what the one sentence in the ticket needs to be, sort of drill down in detail but also be interpreted by the implementer.

But if you're a front end person, it's going to be your playwright tests... or your manual clicking God forbid, or whatever. It's going to mean a different thing in a different place. But hopefully you have people on the team or can train people on your team to, given the one sentence outcome, figure out the interstitial pieces.

And if you can't write that sentence, you probably need to make more than one ticket.

More on the destruction of ambiguity and acceptance criteria

There's a lot of work that people don't like doing that doesn't actually take very long. It's just not very interesting. But doing it destroys ambiguity.

I'll just give you my current example. We're working through a bunch of API upgrades, and some of those APIs have needed to span out to other tasks, because they're not actually the one API. It takes in a keyword that's effectively a function call of "which of these 30 things are we actually gonna do in this API?"

So it started out looking at the initial tracker as one API upgrade. It is actually a set of 30 things, independent tasks to do. And I realized at some point, that only 10 of these things were written down.

So the thing that nobody really wants to do is find the other 20 and write them down. Or in this context, ask the person very clearly who is responsible for that thing, "where are these 20 things?" In fact, not where are they, but please put these in the list.

Just be clear at every step of what the necessary outcome is, what the acceptance criteria is. Because acceptance criteria is happening all the time, not just in like... what code gets written, it's in how the meta process is happening and it's being tracked.

So the acceptance criteria I have for you right now is all of these 30 functions need to be in the spreadsheet. Because even if you know you're about to do them by yourself, everybody else needs to know that they exist. Because otherwise they think we're done and we're not, we have 20 left to do.

Do you have a system to evaluate how much ambiguity is remaining?

So the system is checklists. If a question exists, a list is missing. I would happily put that on a t-shirt. If a question exists, a list is missing. And I've seen this recently.

I was just giving somebody advice on... there's the sort of end of the project, the almost end of the project, the transition from done to done done, where everybody knows that the work is winding down, but nobody will say out loud, we're finished.

And my question is, where's the list?

If the list is empty and we're not done, what's missing from the list? If the list is not empty, but we feel done, do we still need those things on the list?

And that's kind of it, right? Only one of those two things could be the case. And then the work that nobody particularly wants to do and often is unaccounted for is make the list. Just write it down because now everything has, everybody has one place to look to know when we are finished.

And if ever there's a mismatch between the list and the feeling of being finished or the ability to click the launch button, turn off the experiment, it's ready, then fix the list.

On deadlines and ambiguity

This is another thing that I've appropriated from my aphorisms guy. His name is Paw, by the way, P-A-W. Nobody likes deadlines. Nobody likes to pick a date.

For whatever human reasons, uncertainty that you will hit it and the feeling of embarrassment if you fail. The idea that the data is being chosen by somebody else, but engineering has not yet had input and we don't know if we can do that... all kinds of things, whatever.

The deadline doesn't matter. Usually, unless you have a contract with the government and your funding will be pulled if it's not June first, usually the deadline is fully under your control. Or at least in many cases.

And I haven't worked at jobs that typically have customers waiting on us. You have freelanced and contracted, so perhaps you have a different perspective on deadlines.

But, so the framework here is you don't start with a deadline. You start with a target date. Here's what you're shooting for, but everybody needs to be clear that that's a target date, that is not a deadline. And it will move if it needs to move.

The only reason it's not a deadline is there are things we don't know. We have some uncertainties or some ambiguities or whatever. That, by the way, is a checklist.

So you write up your tech spec, you make your tickets, you do whatever your process is. And then you say, okay, given this, and we've done our planning poker and we have a hundred things, they're going to take three days each. And we have 10 people. So that comes down to whatever the math is. Given that our target date is this. But here's our list of stuff we don't know.

Some of it is stuff that we need to go prototype to discover, like how this code works. Some of it is stuff that we need to talk to some stakeholders and decide. Some of it is user research that we need to do to see if anybody actually likes this approach. Whatever the uncertainty is, that's on the list. And that's why this is not a deadline yet, it's target.

Now you have no ambiguity. The uncertainty is there, but it's clear what the uncertainty is. And there will always be an item of like, "shit we didn't think of." Everybody just needs to be okay with that. You'll find them. If you never find them, you didn't need them.

But now your stakeholders, the people who want the deadline. Right? So this is a Paw saying: "Every target date deserves to grow up into a deadline."

At some point you're supposed to launch this thing. It's going to happen on a date. If you can know that date beforehand, that's lovely. Right? Because then you can talk to marketing and whoever and do your whole go to market thing.

So every target date deserves to graduate into a deadline. The way it graduates is by eliminating your uncertainties.

So any stakeholder is now fully within their rights to come to you and say, "how is that list?" And if the list is not getting smaller, you're not doing your job.

And so the list itself is a set of tickets to do a set of tasks to perform. Of like, "okay, I'm going to go prototype this. I'm going to figure out some things that's going to turn into task tracker tickets, and now this uncertainty is gone." When there are no longer any uncertainties, you have a deadline.

Links to Kristján

• LinkedIn

• Twitter

With that unique background, it's perhaps unsurprising that he has a different perspective on a lot of things than many engineers I've interviewed. In this conversation, we talked about the ways that has shaped his approach, how most disagreements are more about context than content, and how learning to see power and the different ways it is exercised in an organization is key to success.

How has your humanities background influenced your approach to tech?

I think that you can't get at sort of a graduate level in the humanities without being exposed to postmodernism. This idea that as I think it was John Berger who said that you can never tell a story again as if it was the only perspective on that story, that everything has multiple perspectives, that people have different truths.

And a lot of the stuff that I think in tech people are being exposed to under the auspices of sensitivity or diversity and things like that in the humanities... you were exposed to this a long time ago as part of your understanding of the world of human beings.

I remember when I was at, I studied Wikipedia for a while. and did some research on that. And I was at one of these Wikimania conferences, this was years and years ago, at Harvard. And I was being interviewed by a reporter from NPR, and they said, "well, you know, isn't Wikipedia garbage?" because you go to the George W. Bush webpage, like page on Wikipedia, and it's a mess of people arguing about George W. Bush, who was the president at the time.

And I pointed out to them that no, it's because we still haven't figured out in this sort of encyclopedic way who George W. Bush is. We're still wrestling with that. At that time, and we're even still wrestling it today.

And so that awareness that when I go and speak to somebody in a professional industry setting, whether that person is an engineer, product manager, somebody in people ops, is always there. I'm always aware that when they disagree with me or they disagree with others, that that disagreement is not necessarily an argument to be resolved with one person being right and another person being wrong, but rather a communication layer that probably needs a lot of translation.

That doesn't necessarily mean that everybody's right about everything that they feel, of course. But oftentimes, what we see as fundamental disagreements on content are actually fundamental misunderstandings of context, and I've found that to be extremely valuable in how I've navigated my professional career.

How do you draw the distinction between disagreements on content and disagreements about context?

We tend to think, especially in tech, we tend to have this idea of the rock star engineer and another engineer. And one of them is simply smarter or at least more experienced with the problem that they're trying to solve. And one of them will be right and one of them will be wrong.

And that does happen. You know, we deal with technology, technology is a very constrained space. And so it is possible for me to know more than you about say a library like D3. I'm an expert in D3, data visualization library and JavaScript.

But oftentimes what happens is that we actually don't fundamentally agree on what the problem is. We don't necessarily agree on the definition of the terms that we're using. It might be that for you... I'll use a technical term that to me covers this problem and to you refers to a different problem. I don't wanna go too specific or even too wide, because like you can go forever talking about language. And I know that your audience is practical and in industry you wanna be practical.

But we do have to recognize that people show up at work, not as like a fresh face out of the computer. They show up just like these large language models do with a huge amount of implicit context that they were trained on a certain set of material and as a result their responses are going to be influenced by.

Most of the time you run into in situations - especially like I did where I could I jumped around a lot in organizations especially at Netflix and worked with a lot of different teams - and you find that people are... concerned with whether or not you're helping them or you're helping yourself. And you have to understand whether or not you're wasting their time.

And to do that, you have to expend effort to understand the language that they use to describe what they do, to understand their domain. And then you have to sort of prove it to them. You have to build trust with them, but you also have to kind of spend that trust. You have to say, "Hey, now that you trust me, I'm going to make a bet that I understand you well enough to push you to do this other thing." And those aren't always the case.

So the context, what I guess what I'm trying to say in that regard is that that context isn't static. It's not like, Kevin, I entered this conversation with you. I know that you were at these startups. I know that you had this background in physics. So therefore I'm gonna talk to you this way.

It's also that as I'm talking to you right now, 30 minutes into this conversation, you'll have this updated context with me, being aware of how I communicate, what I do, and that will change what we're able to talk about 30 minutes from now.

What tactics do you use to deal with someone who is not interfacing well with the rest of the team?

I think in every situation, short of somebody who is just a confirmed malcontent, who is toxic... and also keep in mind that even somebody in that situation, you can find ways to frame that. If somebody is just the worst, and then you dig into it and find out they're the worst because their personal life is horrible right now, then you can help everybody by saying, "hey, you have to be empathetic toward this person. We're all human beings." And that's a great way to build camaraderie and to make more effective things.

There are times when somebody's completely just tuned out and there's not much you can do in those cases. But in most cases, it's that someone is more interested in experimenting with new technologies rather than... maybe achieving the practical goals on time, and maybe they're from a unit where they're not gonna be evaluated by whether or not this project hits its milestones, and so it's doubly difficult.

But in those cases, you can find what they're most excited about. And as a senior technical leader, you should be able to figure out, okay, well, they're interested in this technology. They wanna rewrite this entire framework. We can't do that, because we'll miss our milestone. But maybe there's some aspect of it that you can just give them control over that they can really geek out on and feel empowered by you.

And maybe you see in what they're doing there, a pattern that the rest of the team might get excited about. I'm gonna give Kevin the ability to rewrite this notification API, because I think Kevin, he's got a great idea for it. And I know that it's not on a roadmap, but I think it's going to ultimately in the long term be of value.

If I'm on a team that cares that, I don't think, "oh, Kevin's getting special treatment." I think, "oh, that's exciting. Maybe there's some way that I can also help in that way."

So it's about contextualizing people's trajectories. It's about contextualizing a person's actions in a way that the rest of the team doesn't doesn't take the least charitable interpretation of it, which is actually a logical fallacy as someone who studied logic. You're actually supposed to, in an argument, assume the most charitable interpretation of someone's argument. And if you don't, then you're actually in the wrong. So once again, humanity is providing me with all the tools necessary to succeed.

Given your background both in academia, big tech, and now a startup how do you think about hierarchy and power structures?

So I wasn't just in academia, I was at Stanford, which can get very hierarchical, very quick. You know, you're a full professor at Stanford... you have a certain expectation that the people around you are there to help you be productive. And that expectation can come out in very sort of explicit language. I don't mean cursing, but I mean very sort of like, these expectations are part of the job. And for a lot of folks, that can be very hard because we all in our personal lives have had times when we think that the person in charge shouldn't be in charge and they have too much power over us.

To me, it isn't one thing or another, it just is. It's a constraint that you operate under. You accept it, you understand it, and you either work there or you don't. And I don't mean to be blase about that, but. It's one of many styles. In contrast, Netflix, especially Netflix in the era that I was at Netflix, was very flat. It was very flat and very exciting. And you really did, you had work that you expected to do and you had opportunities like you're saying, Kevin, to change your role, to really change your role.

But to go back and contrast that with Stanford. At Stanford, you know, because of that strong hierarchical nature, if I happen to work with an extremely well-respected scholar and get that scholar a story in a magazine because of the work we did, then that person is motivated to support me, to allow me to further redefine my role, which is literally what happened.

At Netflix, it was more about less hierarchical power and more implied power. What we think of as kind of a healthier kind of power, where people want to work with you because they know you're a high performer. You want to work with them because you know you're a high performer. You both know it's an impactful project. And even though there are definitely units and there are managers and things like that, you have these mechanisms available to you to work cross-functionally and accomplish really sort of amazing things.

The challenge I think is for when people grow up in that, the latter environment, when they are promoted to a position where they actually have hierarchical power. And what I've seen there is that those folks don't have the best grasp. of how hierarchical power works. And I've gotten very, very theoretical here. So let me get very sort of practical in my language.

If you've spent years motivating people to support you through interpersonal relationships because you cannot order them to support you, then you might think once you get into position where you can order people to do things... that you wouldn't want to do that because it's clumsy and mean. And instead, you want to develop a personal relationship with all of your reports. And you want them to work for you because they want to work for you. When in reality, when you're talking to them and you have power over them, it is not the same peer relationship where you're negotiating peer trust.

Instead, you're talking to someone who reports to you, who you control their salary, who you control whether or not they get promoted. And even though they might respond to you in a language because they have figured it out of "I'm your buddy and we're figuring this out together," they might not mean that. They might be trying to navigate what for them is a very unequal position.

There's another problem too, which is that, and I was one of these people at Stanford... you know, sometimes I like to get ordered around. Sometimes I like for somebody to come in the room, kick down the door and say, "we need this, you need to do this by this. Like we need this. The order came from the top and this is what's happening."

I'm not saying all the time, I think it's clear from my personality that's probably not like my number one way of working with people. But there are people who enjoy that. And there are times in their lives when they enjoy that. When you just like you go home and everything's a mess. We built a house and for years it just felt like everything was a mess, and I just wanted somebody to just tell me what to do. That would have been much better. Instead of figuring out how to run the startup with no rules.

So when you don't do that, you're actually not honoring someone's working stuff, you might have a team then in this, in what I've described here, like the horror situations, you have a team, let's say 10 people report to Kevin, five of them are pretending to be your friends because clearly that's what you want us to do is pretend to be your friends.

And the other five are sitting there saying, this person doesn't inspire me, this person doesn't have any vision, they have no authority because they're not telling you, "this is what we're doing, this is why we're doing it, and now get to work guys, let's go."

That can be a blind spot for folks because to go back to, I think a common theme here is, there's only one truth and the truth is, is that there are no hierarchical relationships. We're all equal human beings. I fundamentally agree with that, but in a professional setting, that's just not the case. That's not what we agree to in our sort of social contract when we join an organization. And if you don't own up to that, if you don't acknowledge that, then you're operating sort of... You're not operating with reality.

Do you have recommendations for folks who are trying to learn to see power?

One thing is to start to see, like split it into those two dynamics we were talking about earlier. The person who has authority versus the person who is great at building consensus.

Walk into a room and see the person who gives orders that people enjoy hearing. Like the classic Steve Jobs thing, the person who for some reason can come into a room and say, "this is garbage, do it this way." And everybody smiles and they're so enthusiastic and they're like, "I can't wait to work until one o'clock in the morning."

See those people, but also see the people who enter into a room and say, "well, I...", you know, there was an old Saturday Night Live skit. The unfrozen caveman lawyer. "I don't know much about this or that, but it sounds to me like you're saying this. It sounds to me like you're saying that." And notice that there are some people who can do this. And then suddenly people are agreeing with them. And when the meeting is over, the decision very much tended toward what it seemed like benefited, not benefited them, but matched up with the way that they seemed to be positioned.

I'm trying to avoid like these judgmental things because it's all business. Like it's all made up stuff anyway. It's not like there's good or bad, when it comes to what is... Acme chemical company decide to do with its coding platform with its, you know, CI/CD implementation this year. Who cares? There's somebody who has one idea about it. There's another person who has another idea. Third person might have a third idea and what you end up doing is gonna most resemble one of those people's ideas.

And look for the people who didn't tell somebody what to do, but it seems like they're the most trusted advisor for many people who know what they're doing and when they're in those groups situations, they don't speak much, they happen to speak and when they do, people happen to agree with them.

And that helps, because that's two kinds of power. And then what you're gonna find is you're gonna probably find that one of those more suits you, and then challenge yourself to understand the other one, and understand the applicability and value of the other one, even if you find that you prefer one of those two.

Links to Elijah

• LinkedIn

Our conversation went in a bit of an unexpected and serendipitous direction. We started talking about what makes for a good team environment, and realized that we've both had experiences with teams that seemed magical - hard to predict, filled with intangibles, but the best experiences of our working lives.

We covered a range of other topics - deliberate practice, transitioning to leadership, and more - but we kept coming back to this question of "magical teams", what made them magical, and how we are both searching in our careers to find or create that experience again.

How do you identify what team and environment is going to be good for you?

Yeah, that's probably a lot of self-awareness, a lot of trial and error. Being honest with yourself about what's worked and what's not. If you work in these little pods long enough, I think almost everybody I've talked to can think back through their career, even if that career is only five years long, but certainly as it gets longer than that... And they can point to pods that they were extremely happy, at least from their perspective or... you know, performed in and operated in a super healthy way.

And they have counter examples as well. But I feel like at some point, we're constantly chasing getting back into one of these environments that we've had, for some fleeting amount of time that we just, which felt so great.

And it's always a bit fleeting and you kind of know it, like, you know it's not gonna last forever because change is inevitable. So when you're in one of those situations, you just relish it and you hope it lasts for as long as it can. And when you're not in one, you're always just trying to get back to one.

I feel like that's the sort of the cycles of career and software development. And yeah, how to know if you're gonna be one of those things. I think that's incredibly hard. I think you can have a sense of the types of groups you're gonna match with. Like for me personally, I'm like a highly collaborative person. I want interactions, I want shoulder taps. I want us to whiteboard everything and talk through it.

But not all groups want to work that way. I also want very direct communication. I want you to tell me when my work sucks and I want to do the same for you... not that it means you as a person are not great, just that this particular thing that you did wasn't as good as it could have been.

So I know that about myself and those things are definitely key ingredients to getting in these magical situations. I think that I call them magical situations because there, I think are these intangibles that are kind of impossible to know until you get in them. Like these group dynamics that happen that are really difficult to predict. You only know it when you're there.

How do you create a 'magical' team environment?

I think that's a full-time job in and of itself. I also think it's, at least for me, more challenging in an all remote environment. So in our current world is an all remote company. We're all spread out. And as this person who wants to be highly collaborative and shoulder tap and whiteboard, like that stuff doesn't work super well in an all remote environment.

And so I think I definitely miss the in-person dynamics quite a bit. And I think I'm still very much on a journey myself and with our current team on how to get back to some of those magical states in a remote world. Is it even possible? I don't know that I can yet point to an all remote team where I felt that sort of feeling. I'm like, "oh, this is magical."

I mean, I think there's lots of great things I can point to about our current team and pods and how they operate. But to your point that you can think back and sometimes there's something special about certain interactions and it's not obvious what made them that special.

So if I can't be a wizard, what are actual real tactical things I can do to at least help build pods that are successful in what they're trying to do in an all remote world? Certainly that is matching, to your point earlier about matching company culture. What kind of culture do we set at this organization? Can we find other individuals who match and enhance and enrich that culture?

And then you just get into the very nuanced conversations about matching versus also bringing new perspectives Because you can be overly matched. There's also a thing, like too homogeneous of a pod is also not the best outcome.

If you think back on the ones that were great, they always had some amount of heterogeneity to them. They were people who came from different backgrounds, different perspectives. So that's part of the magical formula for sure.

At the same time, there are people who clearly just don't fit and that can be really toxic for a group. So finding that balance I think is hard, but I think you certainly look for folks who you think are gonna match on some of these dimensions. How do they communicate? How do they wanna collaborate? Are they passionate about the work that they're doing? I think those things being matched on some of those attributes, I think it's really important as a starting point.

Are there skills you deliberately practice outside of work and then bring back to the workplace?

Yeah, I think so. In particular... Being able to try and see a situation from as many perspectives as possible in the most objective way possible. I think that there's many opportunities to do that inside and outside of work and that can be super helpful.

Even with my kids sometimes, they'll come home and they'll be complaining about something that happened at school and like, "hey, let's go through an exercise of looking at this from as many perspectives as we can. what do you think the teacher thought about this? Or what do you think your friend thought about this? "And like, let's put ourselves in their shoes and let's just talk through it.

Maybe that's also hopefully good for them as young people to learn to do that. But I think it's also just a good exercise for me. Like, let's practice that. What would that look and feel like? Let's talk through it. There's lots of opportunities to do that.

And I think that getting good at seeing a problem from multiple perspectives and being able to put yourself in other somebody else's shoes, those cliche things. But they're really important when it comes to leading teams and just work with people in general.

Without necessarily compromising on things that are important to you or important to the team's success. So it's okay to see things in many perspectives. I think it's still important and necessary. Especially leading a team that you have to find ways to go forward and be successful. And there's things you can't compromise on.

What are the lessons you wish you had known moving into leadership?

There's two and they're related. You can be more effective by letting go of more things. As a leader, the more things that you can let go of that you can not be indirectly responsible for actually increases your ability to be an effective leader and to get a group of people to get more things done.

And that's very contrary to individual contributing where it's just like "the harder I work, the more I will get done." And it's a very like 180 mindset to be in. And that was a very difficult transition as somebody who like prided myself and all the stuff that I could get done, which was sort of like makes you stand out, which is a weird thing about how we raise our top performing ICs to be leaders, because it doesn't actually match up very well.

And the second part of that is related is like how I would get job satisfaction, how I would be satisfied with the work that I was doing, how I could look back on my days and feel good about what I had accomplished when it wasn't me directly accomplishing these things and getting these things done.

So those two transitions were really hard... continue to be difficult for me. And maybe I should have known that going in, but it actually... wasn't maybe as obvious as it should have been in hindsight, that that was gonna be the case.

How do you think about delegation?

I think the analogy here, which is overused, but resilient for me is how I approached coaching. I had played collegiate athletics, I was a volleyball player, and then I did a bunch of coaching young people throughout my career as well.

And there it was easy. My playing career was over. I was clearly a coach now. And so... I was getting satisfaction and evaluating performance on the performance of the team. So I didn't have this weird thing where I was the one who should be out there playing because that wasn't even an option.

And so when I was thinking about it through the coaching lens, it was... how do I ensure that I take the strengths of all the players, combine them in a way that as a group, that we are better. Super cliche stuff, but I think still very true things. How are we better together than we are as individuals? And so that means playing to our strengths, all of our strengths and making sure that people are in positions which allow them to leverage their strengths and then hiding our weaknesses to the best of our ability, letting other people's strengths cover our weaknesses and so those don't get exposed.

And when I came to leading teams of engineers through a similar lens, actually it worked relatively well for me, it got a lot better. And so in thinking through like, I'm not gonna be the one doing this stuff. How do I make sure that I set up and break out the work such that people are playing to their strengths, mostly covering their weaknesses. At the same time, just like as a coach, you are expected to help everybody in the group improve.

Part of your team success is everybody improving. So it's not about hiding weaknesses and pretending they don't exist. It's about covering them, but also... closing those gaps over time. So those weaknesses don't exist anymore, and it's about taking strengths and doubling down on them and making them even bigger strengths. So all those things are still true. And I think those same principles certainly apply when leading teams of people through, for software engineering at least.

Do you have approaches you use for managing your emotions?

Yeah, I'm sure there's always ways that we can do better. I think naturally I'm a pretty steady, pretty happy, optimistic person by nature. I think I am naturally inclined in a way that works. So that helps.

And then on top of that, I certainly lean on my partner a ton. We have a fantastic relationship, thank goodness. And they help me stay happy or at least a place where I'm able to talk through situations that are affecting me negatively to help sort of right the ship. So that support network, whatever that support network might be... like any human, those support networks are super important.

And ones that are outside of work. I mean, you need your in-work support network for sure, but you definitely need your out of work. That can be in the house. I have some, some great friends as well, that I lean on.

I think taking mental breaks is a, is a really big part of that story. I've been pretty good, I think in my career about giving myself breaks from, from work. I probably average six, at least maybe weeks, you know, a year, maybe more than that, out of work. Regardless if I was in IC or in high level leadership roles, but I think maybe people expect that you can't take as much time when you're in these bigger roles. And I just, I really combat that. I disagree with that completely. And maybe it's the reverse. You just have to take more time. And that's good.

And at a place like Netflix in particular, where the sort of unlimited vacation policy and you know, whether that's draconian or not, I don't know. I think it is what you make of it. I certainly, I tried to use that to help keep my mental state healthy and I got a lot of support from everybody at Netflix. And then we do the same thing at Tabular. We don't have a fixed policy. It's like, "please take what you need to be healthy and effective." And I try to model that for the rest of the company by taking time when I need it. And I do need it, absolutely.

On the search for magical teams

I'm glad we got into this conversation a bit about what makes these certain team interactions really amazing. I've read a bunch of the books and management books and team, and there's lots of good tidbits in there, but nothing that I've ever been able to pattern out to say, "Oh yeah, that's the thing. If I take that nugget and I reply it historically, That was the big unlock for why that happened."

And this is true, whether it was professional teams or athletic teams, all of it has this magical quality to it. I don't know what... actually if we ever could figure it out, probably we'd be bestselling authors or something. But it's really fun.

And I think maybe part of the fun of it is the search for it. It's sort of like you get to go on this hunt and journey in your career, and then once in a while you find it and it's magical, then you lose it again, then you just go searching for it again. So maybe it's meant to be that way. It's a bit of this treasure hunt that we're always on.

And yeah, I think some folks maybe haven't experienced that or think they need try to force their current situation to be that. I think I at some point learned that sometimes change is really the only way forward. Don't continue to force this if it's not working. It's okay.

It always seems in the moment that change is going to be really detrimental on one vector or another. And that never tends to turn out to be the case. Maybe some things were better, some things were worse. Sometimes it's great.

But yeah, I think I've learned to be less afraid of change, even when things seem like they're going well. Humans are really adaptable. More than we think.

Links to Jason

• LinkedIn

• Twitter

In this interview, we covered a lot. We talked about how Sarah first came to engage with people as well as code, and tactics she's found to engage people with curiosity and empathy. We talked personal effectiveness and filling your own bucket, making sure you stay happy and healthy. And we talked about the importance of "throwing the gauntlet", challenging your teams to step beyond the comfortable and make real, substantial change.

How did you start to care about human skills as an individual contributor?

Yeah, I guess I was always a heads down engineer. I've done a lot of open source for a long time. And some people may know me from my work. I was a Vue core team member before I was at Google. I went into emeritus status when I started caretaking the Angular team, because that's just too weird.

And then before that, I was really heavily involved in the React community and gave keynotes at React conferences. I'm probably one of the only devs who's gone through. all of the major frameworks and involvement in that way.

I love open source. I love coding. That's a huge passion of mine. I think one of my favorite things to do is code.

So, in going into some of those things, what I noticed was even on the open source side, when projects that I worked on became popular, I'd have to deal with humans. And sometimes I was really bad at that, to be honest. People wanted features that I wasn't aligned to. You have to learn how to communicate with grace under fire, especially in open source.

And also for jobs - I'll just say one quick story - I used to work at Zillow and I was like heads down coding all day long. I was definitely like, "I don't want to go to meetings. Those are dumb. I don't want to talk to other people. That's dumb." I just wanted to get my work done. I just want to code.

And at one point there was like a company party and this guy came up to my desk who ended up becoming a good friend of mine and a good peer, like a collaborator of mine, he came up and he was like, "Hey, why don't you come to the party?" And I was like, "no, I want to code. I need to get stuff done. "

And he was like, do you really think that you're gonna be able to get stuff done and if you can't get along with people and get to know them? And I was like, "no..."

And that was probably the kindest thing that someone has ever said to me at work. Not... we talk about kind, not nice sometimes... that was a very kind thing he did that day.

Are there any particular tactics you've found helpful engaging with people in open source?

Yeah, I think approaching with curiosity is something that I try to do. I'm not always successful at doing, especially if something doesn't seem right. You kind of want to push back initially. I've really tried to learn how to not do that and ask questions instead. I'm not always good at that.

Another one is the fundamental attribution error. I I struggle with that one. The premise of that is basically that you attribute any wrongdoing of yourself to conditions like, "oh, I was tired that day, I was sick, I wasn't feeling good," or, you know, whatever.

And with other people, you attribute that to their person, you're like, "that person is mean, that person was bad." And that's a really... that's a big thing. Like you have to think about that a lot and remind yourself, or at least I have to think about that a lot and make sure that I'm not doing that and making sure I'm showing everybody else empathy and grace.

What have you found helpful to develop empathy for other people?

One thing that I talk about in the book in the first chapter is I think a lot started to resonate for me and gave me a system for thinking about these when I started learning about values.

Values are really interesting because when you talk about values, there's no judgment attached to it. Like if you have a value that is family or a value that is humor or a value that is beautiful mess or meaningful work, there's nothing wrong with having that as a value and not having that as a value and people have different values.

And so what I notice a lot of times when people can't get along, it's usually because their values are misaligned. And I think in movies and TV and books, what people want to do is make a good side and a bad side. And that's very infrequently the case that one person is on the side of light and the other one is on the side of evil.

Usually people either are outcomes misaligned, they're looking for different outcomes or they're valuing certain different qualities and things.

And the more you can understand someone else's values, the more you can say, "Okay, they value X, that's not my value, but that's fine. And that's why what we're aiming for is slightly different. And that's why we're not seeing eye to eye." So it can be a nice framing in a way where you're not like judging each other. You're just understanding where the other person is coming from.

Do you have any exercises you use to help identify your values?

Yeah, so with groups, what I'll often do is put a bunch of values on the board, like a big list, and then have everybody pick either three to five, depending on the group and how much time we have. And then people speak to their values and they say where that value resonated and came from for them.

Sometimes values are things that you've always had and you don't know why. Sometimes values are something that you developed over time.

Let's say learning is a value now, but it wasn't when you were a kid and you went through some process where you learned that was important to you or some event happened in your life to make that important or something didn't happen in your life where like you were let down because of something and now you really value the presence of it.

Talking through that as a group can be really useful. Every time I've done it with a group of people, it's been really grounding and people go, "ohhhhh", and there's a lot of insights and then people can kind of match up and be like... "Oh, that's why when we talked about X, like this, Y happened."

For myself, you know, I'll be honest that I've, you know, previously in time had a hard time making boundaries for myself. I'm the kind of person who is a hard worker. You give me a challenge and I'll run towards it. I'm easily nerd sniped.

And as I started working in the community more and more, people wanted more and more of my time until I didn't have any left, and I kind of ran out of tools for what to do. And I wasn't seeing my family or my friends as much as I wanted to.

So I actually got a coach and she really helped do some work with me that was kind of tough love of like, "Here's what you say your values are. You say you care about coding, you care about your family, you care about your friends, you care about this, but you're only making time for coding. Are you really honoring your values?"

And what tends to happen if you don't honor your values over time is you start to burn out.

Or if you don't like your job, sometimes it's not because you're working hard, it's sometimes it's because your values are misaligned with your leadership or your values are misaligned with where the company is going. That can burn people out just as much as hard work can.

And so, I've done some exercises with myself to make sure I was... doing things to honor my values. So one that I did to figure that out was to write down what I think my values are into four different buckets. And then I would make a list of all the stuff that I was working on. And I would have to map it into those buckets.

It could cross multiple but then I would notice when something wasn't hitting any of the buckets.... And I'd be like, okay, those things gotta go.

At the time I was doing a lot of work for CSS Tricks. CSS Tricks actually hit almost every bucket for me. And I was like, "Man, I should be reinvesting more of my time into doing stuff writing there or like Vue core responsibilities."

So it can also be a good reinforcing thing of like, "oh, OK, now I know, this is something I'm doing on the side, but I appreciate now that that's really helpful."

How do you manage to be so prolific in your writing?

It kind of comes down to the way that you think. When you're a principal level TL, a lot of your work ends up being in design docs in order to communicate an idea. Sometimes my technical writing is a breadcrumb trail for myself because I solve the same problem twice now. And I'm like, "man, If I don't write this down, I'm going to solve it again for a third time."

I have this post that's like, "how to build a Chrome extension". I wrote that because I kept making them and then going like, "how do I do that?" Reverse engineering my own work because enough time had passed.

And it's also for other people. I learn a lot from other people. The way that I've learned how to code and evolving that... I mean, evolving your coding discipline is a constant process, right? I don't know about y'all, but I'm always learning. I'm always learning new things. And I have to rely on people putting things out in open source or tutorials or writing.

And so for a long time, I consumed that for probably 10 years of my career, I just consumed that. And there was a point where I said, "I need to start giving back a little bit too, because I can't just only consume other people's material."

No judgment for other people, but I just felt like I was taking a lot and not giving enough. And so, some of that is definitely that and that if I could even just write something down that saved other people some time, that was really meaningful use of time for me.

I think a lot of writing the book was that I was mentoring a lot of people and I noticed that people came to me with the same things over and over again. And I was like, "there's no way I'm going to scale myself jumping on one or two calls every month. I think it's better if I just write these down and if people want to read it, great. And if they don't, you know, no worries."

What are the similarities between working as a principal engineer and an engineering director?

I think something similar that I see in principal level IC work and principal or director level or VP level strategy is the idea of throwing the gauntlet. When you're at that level, sometimes your job isn't dealing with every single how or executing every single how.

That was really challenging for me as I was learning and developing and moving up. because I want to work on the house sometimes. And sometimes I know I'd be faster at it than other folks who are just learning. And I had to learn a lot of patience and also learn how to trust other people to execute. And that is a lot easier said than done if you're like a perfectionist or something. Thankfully, I have wonderful teams that are really deserving and go far beyond that trust.

I think both in principle and director level, you are throwing the gauntlet. A principle level activity for something like that would be to design an entire architecture of a system, but not necessarily execute every single part of it. So you're kind of writing a design doc that's high level. That's like, "here's how everything could work. Here are the reasons why we might do this. And this is here are the risks. Here's conceptually how all these things plug together."

And then you work with other people who are going to execute the smaller bits to make sure that you're validating your approach and that it's going to solve the problems that you think and that you're not gonna run into massive tech debt that you may not know about or something like that.

When you're a director, you do the same kind of work. You're still throwing the gauntlet and you're saying that there's strategic direction to go in. I'll give an example of that on the director level. So I mentioned that one of the teams I run is the Angular team. When coming in from Vue, at first I was like, "are they going to be weirded out that I'm from the Vue team? How's this going to work?" And I was really pleasantly surprised to find a humble, thoughtful, curious group of people who are hungry to evolve.

And so what I ended up doing with that team when I first joined was, I wrote up a doc of all the things that I saw coming from community to community and just asked them a lot of questions about "what was the design idea behind this? Why are we doing X, Y, and Z?"

The asking of questions is interesting. From their perspective, it gives them an opportunity to either articulate strategy or articulate "Well, this made sense eight years ago, and maybe it's the right place for us to innovate and things like that."

And then even further throwing the gauntlet of like, "Hey, I think we're here. Do we agree that we're here?" And they go, "yeah," or they go "no," or whatever, but usually we align. And then say like, "I think we gotta go here, right?" And they go, "yeah." I'm like, "what are the things that we need to do to go from here to here? I think that there are some things in this area that could be revisited. Do you agree?" Yes, no. And we talk about those. What are the things that we need to do to iterate on those things?

And one of the outcomes of those is Angular signals. That's the product of many of these kind of conversations. The Angular team is so good at dealing with me throwing the gauntlet. They're so kind and thoughtful. And to be clear, they're the ones doing the work. They're the ones designing signals and deciding that that's the ultimate direction.

I'm asking questions and like kind of, you know, poking on things. So you can see how like the principle mindset and IC world is not too dissimilar. It has... curiosity pieces, it has like, here's the overall strategy that we're thinking about. It has other people executing more fine grained work... and all those pieces are critical too.

So it's a lot of that orchestration and to your point about it always being human, so much of that is communication.

What makes a good gauntlet when you are "throwing the gauntlet" to challenge people?

I think it changes depending on the team. I'll give another example and then I'll pull it back.

One of my teams is the BuildServe team... and Google's infrastructure is different from external's infrastructure. So we can't wholesale adopt something like ESBuild or Parcel or Webpack or anything. But even though we cannot change those things wholesale, the thing that I asked them to do was, "hey, go, I'll time box some time for you, go reverse engineer those things and come back and let me know, did you learn anything? And is there anything that we can evolve?"

So you could see how there's difference there, right? I'm not saying to the BuildServe team, "go change your direction." In the Angular case, I am sort of... I mean, I'm not telling them what to do. I'm just... Or like another question that I asked another team was, "are we set up for success for the next 10 years in this direction? Think about it and come back to me and think through these things."

And they would come, they came back to me and they're like, "actually, no, we've got to do this and this and this."

In all those cases, I'm not coming to them and saying, "you need to do X." I'm just asking a strategically placed question that they are empowered to answer. They could come back to me and be like, "yeah, we're totally good."

It's still in their hands to decide the direction and execute. But the strategy is something that I'm like kind of throwing the gauntlet, like, "I think that we need to consider this. Come back to me."

Recommended Resources

Straight from Sarah in her voice

• Range is a great book: https://www.amazon.com/Range-David-Epstein-audiobook/dp/B07N6MPWLS

• Michters is a great whiskey: https://woodencork.com/collections/michters

• Another great book: Thorsten Ball's Writing an Interpreter in Go, Writing a Compiler in Go

• Another: Randall Monroe: Thing Explainer

Links to Sarah

• Web

• Twitter

• Sarah’s book: Engineering Management for the Rest of Us

This conversation focused around diversity. Diversity of race, diversity of culture, neurodiversity... there are a multitude of different ways that who we are, how we show up, and how we are treated vary in this world. We talked about the ways that those difference can lead to challenges, and ways that we as individuals and leaders can work to overcome those challenges for ourselves and for our teams so that we can all thrive.

NOTE: Next Tuesday is the July 4th holiday, so there will not be an issue of Human Skills published. During the week I will still be publishing smaller clips from past interviews on the Youtube Channel, so if you don't want to miss any go subscribe there. :) The next interview will go up on July 11th.

How do you set yourself up to thrive if you are different than others in your organization?

That is very dependent, first of all, on how psychologically safe you feel in your role in your organization. This can vary greatly.

So you might be in the situation where you feel quite comfortable disclosing something about yourself that might be different or specific accommodations that you might need, but you might not.

So assuming that maybe you're not so lucky and you're not feeling like... this is a place where you want to have that type of conversation... my perspective is that what everybody can do, no matter whether you identify as neurodiverse or what have you, is have a conversation with your team members, with your manager, about expectation setting. Ways of engaging with each other.

This is a really important thing to do for any new relationship, I think. And it's often something that we skip over. We make a lot of assumptions about what good work looks like, what an engaged employee acts like and how they interact with others.

So having an early conversation with the people that you're working with, particularly your manager. How do you like to receive feedback? How do you like to set deadlines? Do you like to... come up with your own prioritization, or would you prefer a little bit more coaching as to what is the most important thing to be working on?

These types of things can help everybody be more successful at work, no matter who you are. And it's really worth taking the time at the beginning of the relationship, if you can, to have those kinds of conversations.

What types of challenges happen when you have a multi-cultural workforce, and how do you address them?

I think a broad example is when we're breaking down engineering work and we're writing tickets for tasks, do you expect as the engineer that absolutely everything expected of you is documented in this task? And if you have a thought, "hey, this is maybe not gonna be the best approach to solve this problem and I have another idea," what do you do with that?

Do you keep quiet and execute on the task as it's been described by your lead or your manager? Or do you take a moment to have a conversation, pull in some people say, "hey, I'm thinking that this might be a better approach."

Our culture, our workplace culture very much favors the second, right? We want our team to be coming to us with new ideas, helping us see things from a different angle. This is the beauty of having a diverse team - people think differently and then they can call out things that we might not have noticed.

But if you're coming from a previous employer or a culture where things are a lot more hierarchical, it might look like insubordination to be saying, "hey, I don't think this is the right way to be building this feature and I think we should be doing something else."

So making sure that people know that it is safe to raise questions, to have a conversation. To challenge maybe an approach, even if it's somebody more senior than you that has suggested this approach, it is gonna make us build a better product and have better results overall.

But if people aren't feeling safe to do that and that might make them look like they're, I've already used the word insubordinate, it seems like such an extreme word, but yeah...

You have to create that safe container for people to say, no, we want our engineers to be coming with new ideas and challenging our assumptions, rather than simply executing on tasks.

How do you suss out cultural expectations when joining a company?

Yeah, it's a great question. It can be really hard and kind of scary sometimes to be the one that has to bring that conversation to the forefront.

Clearly stating your expectations for the conversation, saying, "hey, I wanna do great work and I want to be comfortable contributing to this company. So I'd love to have a conversation about what good looks like."

I think... from Brene Brown's work, Dare to Lead, there's a kind of a phrase in there, "paint what done looks like", or set clear expectations for what a project done well looks like. So if you have a project that's been assigned to you, defining success criteria for that project, that is a conversation I would love for my team members to come to me and say, "hey, can we talk about, if, X, Y, and Z is accomplished, do we both consider this project to be a success?" Having those kinds of alignment conversations is really great.

In general, if there isn't any sort of documentation on engineering cultural norms, asking about what is our code review process and what are the expectations around that? Do we do code reviews? Do we require two approvers? If somebody has a change request and I make it, can I merge it or do I have to wait for another approval? All of these little things are really, really important to know going into your role.

And they're not always well documented depending on what stage your company's at. I think that any engineering manager would be happy to have their new report look for clarity around these expectations, because it's often a factor sometimes of not having the time, depending on what's going on. Maybe nobody's written that documentation yet, so it doesn't exist.

And then treating every new person joining your team as an opportunity to reflect on "are we setting up our new employees for success and how much of this conversation that we're having or issues that are coming up could be resolved by creating some clear documentation, adding some content to an onboarding session, things like this."

We can be iterative about getting better and better at creating these safe containers where people understand the unspoken rules of operating successfully in the company.

How can you design processes to work well for a variety of people?

A conversation that we've been having recently at work is we have an architecture review process and it's not always the most exciting meeting. It's often, you know, we're all quietly reading a document and then we're looking for feedback. Anybody have comments? No? Okay, I guess that was it.

We've been talking about how do we get people more engaged in the architecture review process, asking the right questions and so forth. And a lot of it, I think, comes down to thinking about how people like to think. Not everybody is great at thinking on the spot on the fly in a meeting. I'm certainly not. Often in a large zoom call, the more people there are, the more distractions there are for me. Being at home is really nice for a lot of people, but for me, it just adds to the things that might distract my attention away from the subject at hand that we're discussing in the meeting.

So kind of understanding that having all of the thinking and the workshopping and the solutioning done on the fly on a live Zoom call is only gonna work for a very specific subset of people who thrive in that kind of environment.

So what are some things that we can do to make our architecture reviews or solutioning meetings more accessible to everybody? Some really small things: sharing pre read information in advance. We're going to be going over this document, here it is 24 hours beforehand. So you can digest it. You can think of questions. You can add comments.

Also leveraging more tools for comment other than just putting your hand up in the meeting. Having somebody be the chat moderator. And if you don't feel comfortable vocalizing your question, you can put it in the chat and the moderator will ask the question for you. That go a long way in helping reduce barriers for people speaking up because they don't actually have to speak up themselves.

Another thing is thinking about how you want people to engage with the content being reviewed. This is something that I think about when it comes to code reviews as well. If you've got a huge multiple file PR, that can be a lot to digest and consume. And I love when people go through and add comments saying, "hey, I wasn't really sure about this decision. I'd love feedback on whether we think this is the right approach or we could do it this way." That gives people an in and a little bit of guidance on how they should be engaging or how they could be engaging in the conversation.

How do you as a manager suss out how people like to show up?

Yeah, so there's a lot of great resources online now that have suggestions for questions for first one-on-ones. One that comes to mind, Laura Hogan has a great template for both giving feedback, which is really useful, as well as great questions for your first one-on-one. And it goes through these types of things.

What I love about her questions is it asks questions in a very human way. So rather than it being like, "are you an introvert or an extrovert?" The question is, "how do I know when you're grumpy and what does that look like?" Like, what makes you grumpy about work?

And I love that, the way of using the word grumpy, which kind of makes me laugh. And it gets people a little bit outside of this very narrow way of thinking... People are introverted or extroverted. They are more technical or they have stronger soft skills. We're so much more complex than that. And so thinking about it like, "here's a scenario, what would you do in this scenario?" Or humanizing it a little bit with different types of language, like "what makes you grumpy?"

"What is the most important thing about work to you" is a really good question too. Understanding what is motivating people to show up every day and understanding that that's not going to be the same for everybody. Becoming a manager is like an immediate crash course in people are not all the same. Oh my goodness. People don't think like me.

And it's something that I think people know, but you don't really know until you start having these relationships with people and realizing, "Wow, we were in the same room and we heard the exact same thing. And we came away with two completely just different perspectives on what just happened there." You can't assume anything about anyone and you have to ask the questions.

So doing it in a format where it's more scenario based, it's more "What do you like to do? How do you like to spend your time? What types of tasks give you energy? What types of tasks are really draining?" That can help you have a more holistic and well-rounded picture of who this person is. And also what motivates them to work.

For some people, it's just a job and what motivates them is a paycheck. And you know what? That's totally fine. Now we know that we're optimizing for how do we grow your salary in the quickest way possible based on the constraints that we're working with in this organization and how we promote people.

For other people, they're very mission led, they want to be connected to the values of the organization. And so making sure that we're always thinking about that and pulling that into the story of why we're doing our work is going to be really much more impactful for that kind of person.

Recommended Resources

On the topic of building inclusive cultures and diverse teams, there's a ton of great resources. The first one that's popping into my mind is a newsletter called Better Allies. I think it's a weekly newsletter and it covers all sorts of topics around inclusivity and diversity in tech that I highly recommend.

And then the other recommendation I always like to make to people in leadership roles that are trying to learn more about how to be a more inclusive leader is to read more fiction, which is not always the first thing that comes to people's minds, but we only have the perspective that we have ourselves from our own lived experience. And as we're trying to learn more about the lived experiences of others, it can be really the natural inclination to just go ask a person. to educate you, right?

Especially if it's in the dynamic of a manager in a report, it's not your report's job to educate you about their lived experience. It's your job to support them no matter what. And so a great way to educate yourself is to look into reading fiction or non-fiction, but I think fiction is really valuable too, to read stories written by folks from diverse communities, different backgrounds than you. Because it's a really great way to be educated by somebody who's not on your team about some things that they might have experienced in their life that might resonate with them.

A few Fiction recs I've enjoyed lately(and I'll add some memoir /  nonfic for good measure).

Fiction

• The Namesake - Jhumpa Lahiri

• Detransition, Baby - Torrey Peters

• Homegoing - Yaa Gyasi

• White Teeth - Zadie Smith

Memoir

• We Have Always Been Here: A Queer Muslim Memoir - Samra Habib

• Good Talk: A Memoir in Conversaiton - Mira Jacob

• Know My Name - Chanel Miller

Non-Fiction

• Unmasking Autism - Dr. Devon Price

• Hood Feminism: Notes from the Women That A Movement Forgot - Mikki Kendall

• Burnout: The Secret to Unlocking the Stress Cycle - Emily Nagoski, Ph.D and Amelia Nagoski, D.M.A.

Links to Kristen

• LinkedIn

• Substack