Hey everyone, welcome to part 2 of my interview with Brian Pulliam. Brian is a career coach in the last episode. We talked about what does that really mean and why might it be useful? How could you integrate coaching into your career, some of Brian's ups and downs in his career, as well as some advice around your candidacy in your job search as an engineer or an engineering
leader. In this episode, we're going to talk a little bit more about those tactics in your job search and how to, for example, take the values of the companies that you are applying to and turn them into material for your interview. This is super extremely helpful. If you don't listen to any other episode about interviewing, I recommend you listen to this one. Brian is such an incredible coach for me and I'd love for you to check out his coaching
just a disclaimer. We said this in the last episode as well. I did agree to have Brian come on as part of my payment for my own coaching. Brian is not compensating me with anything other than his own services. I do believe in Brian's ability to coach. Brian didn't tell me to say any of that, but he did ask me to mention that he's offering listeners of developer TA 10% discount when they book their initial discussion with Brian. You can do
that at refactorcoaching.com. Make sure you mention developer T and you'll get 10% off of a coaching package, which is three or more sessions with Brian. Thank you so much for listening to this episode. Let's get straight into the interview with Brian Polio. Yeah. And even if the person who's asking you doesn't ask that exact question, you know, if it's close enough, they'll usually let you paraphrase it. They'll say, you know, well,
what comes to mind is not X, but it's X prime. So let me tell you that story. And then I'll ask you if you want to go deeper or if you'd like a different example, like how does that sound? And they're like, yeah, sure. Yeah, it's kind of going back to your direct. Yeah, go ahead. Going back to your discussion about the color palette. It's like, they're going to ask a question that fits on the full gradient or the full color wheel.
And you have to snap it to the closest one, right? You're going to snap it to and most of the time interviewers would rather you snap to than to say, well, I don't really have a good story. I don't really know what's the intent with asking that story. Yeah, exactly. You got to think a little, you got to put your big brain on, right? And you
got to say, I'll, you know, I mean, I'll share another like worst kept secret. You know, if a company's big enough to have a company values page or like a four values page, you should, you should convert every single one of those core values into a question that starts with tell me about a time when you demonstrated X and you should be ready to ask
that question. And I mean, I don't know what your experience is, but I've been flabbergasted by how few people are prepared for answering those questions that are effectively like an open book that are sitting on a homepage that anyone can go look at. Yep. Even before the interview. I'm going to do this live right now with you actually. I think it'll be a good exercise because I haven't announced this yet. And by the time this episode comes
out, I will start my job. So it's okay. I'm joining Calon link, which you already know. Yes. Congratulations. They have, they have four values that are on their careers page, right? Value number one is start with human value number two, find a way. Value number three is focus wisely. And finally, value number four is strive for excellence. And all
of these can be very quickly turned into multiple versions of a question, right? Which one do you think, what, which one should we pick for the, for the, for the, for the, we probably do all four. Yeah, we do all four. All right. So start with human. Tell me about a time when you had to make a decision on behalf of one of your reports to support them in a personal situation. That would be a good start with human question, right? Yeah. Probably
not going to get that necessarily, but something along those lines. Yeah. So based on the work we've done, you know, I'm going to have an intro sentence here that you that you'll recognize Jonathan, which I'd say, you know, hey, I'm the kind of person who thrives in an environment where, where leaders are seen as people focused and where they can create an environment
where success is more likely. And, and so when I think about your question about taking a human forward approach to a decision for a direct report, it reminds me of a, of someone who I will call Steve. It's not their real name. And Steve had a performance problem. And it was pretty glaringly obvious. Steve was forgetting things five minutes after we talked about something. And it, and it seemed like it came on suddenly. And the inexperienced
leader in me would have taken a very different approach to this. They would have said, Hey, you're not, you're not, you're not meeting the bar. What's going on? You know, I'd get frustrated. But the experience leader in me took a different tactic, right? I leaned in to my curiosity and I said, Hey, Steve, in my next one on one, I'm observing these things as backs. And it feels like your performance is different than it used to be. Is there
anything going on in your, in your life? Like what's going on? Like, you know, have you noticed these things as well? And the story I heard afterwards, I will never forget, you know, Steve, as it turns out, grew up in rural China. So as they went into, as definitely not, Steve, and, and he was in a horrific car accident when he was about five years old. And giving how remote of a village he grew up in, he never got medical treatment for
it. And so his back healed in ways that create severe amounts of pain for him, so much so that it's hard for him to focus. So now, you can see where this is going, Jonathan. Like, you know, HR will tell you and I, both as leaders, like, wow, you need to separate performance and medical issues like completely, but in this case, they're intimately tied together.
And so I had to say like, hey, I'm wondering, now this is before COVID. And I said, I, what is it that we could do for your working situation to accommodate, to make reasonable accommodations for you to go address this? Because I feel like this is interfering with your ability to do your job. Like, do you think, what do you think? And I got Steve to sort of admit that, yeah, this is a, this interferes with my ability to focus at work. And I said, well, let's
fix that. And this is maybe three years before COVID. And we had him go remote. We had him take a medical leave of absence, right? You know, short-term disability. When he got his his back looked at, and then he only came into the office like once a week after that. And it turned out that sitting prolonged periods at his desk and not being able to do like physical therapy, like every two to three hours, you know, not everyone feels comfortable laying
on the ground in the office, stretching in front of other people. I don't care, but, you know, but other people do. And creating that environment for him completely turned his performance around. And, and as of the day that I left Zillow, right, he was still, he was
still being a successful engineer. So I think there's a case there to say lean into what I learned from that is to lean into the curiosity of understanding why something is happening and not making a judgment call and not calling Steve a slacker or, or assuming that it's even intentional, but to better understand like the whole person and then see what you could do in order to create an environment where success is more like, because that's
what a good leader would do. And as an interviewer, I'm sitting here, I'm taking notes, I'm like, man, this is great. As, as somebody that you've coached, I know behind the curtain, I just heard the, the L at the end there. We can talk about that if you like the, the response that we have laid out with this question. So here's, here's what I love about what we just heard together, right? Yeah. We, and that was not prepared for just to keep
it everything above board. We didn't, we didn't talk about this. This is actually me putting Brian to the test a little bit. The, the, you pivoted this, this, the story that you clearly have prepared, right? The story was prepared, but you didn't know I was going to ask you about that. Nope. You pivoted from start with human to tell me about a time
that you took a personalized approach to performance, right? And, and that kind of, that's what we're talking about when we say snap to is you have this story that you have, you know, very good detail on it shows a lot of different important values that you hold, a lot of important kind of outcomes that a company would care about in a, in a single succinct story. But it didn't have to be only this thing about starting with human. You
don't have something on your side that is labeled start with human, right? It's, you're, you're adjusting and you're translating between these things. And so it takes a little bit
of practice. And I think that's kind of an underpinning of what we're talking about here is that your, your interview process and multiple interviews, hopefully that you're going to go through their practice, their, their opportunities for you to, and you can do this with the values, like you're saying, do it with the values on the page of the company that you're getting ready to interview at. Look at a value, look at your stories and
say, this one kind of fits that one. This one fits that one. Would you agree with that kind of approach? Yeah. Yeah. And you know, that's sort of, that's why code coverage comes to mind for me, right? It's like, well, what stories can cover these values that these companies have? And they're not, they're not that different, right? Right. Yeah. Companies care about teamwork. They care about excellence. They care about integrity.
They care about visibility. Yeah. You know, if you think about what a reasonable company would want to see in the behaviors that its employees demonstrate, you're going to get something like 80 or 90% coverage. So I would say a bad place to be. What do you think about potentially even referencing the values? If they don't ask you about the values, having those available and saying, Hey, this kind of reminds me of the value
of focus wisely. Here's a story that kind of matches that. Does that feel to on the nose? How does that feel? Just, you know, first hearing it. Yeah, I like to coach my clients to mention it, but not to be so overt about it. Yeah. Right. So, and so there's a little bit of subtlety here. You know, if, so at Zillow, they have a, they used to have a core
value called turn on the lights. You know, because Zillow was born out of the study idea of giving information to people that didn't have it before, like how much your neighbor's house is worth and being able to see that amongst those really broad neighborhoods and that that empowers you to make a better decision, whether you're buying or selling whatever.
And so they, they, they used to probably still do have a question about, tell me about a time when you discovered an issue and, but it wasn't like necessarily a great thing. Like you, you noticed a big mistake that you made, like, and it was going to impact the timeline for a project. Like, what did you do? And they're looking to see if you will tell a story about when you turned on the lights, either for something good or more importantly,
when something wasn't good, or were you're too afraid to share those details. Yeah. Yeah. Yeah. So, in a case like that, you can imagine that in it, I wouldn't say, well, since one of your core values is turned on the lights. Right. Yeah. Of course. And you're asking me a question that sounds like it's like you're looking to evaluate whether I have a story that aligns with the company value. That's pretty like bull and a china shop.
Like we don't need that, right? Right. Yeah. That, that doesn't maybe increase your chances of getting the offer. It just kind of makes you come across as a little junior. So, you know, more senior people are also have more mature communication styles. But I would reference turn on the lights. I'd say, yeah, you know, now that I think about it, I do have a turn on the light story. And that's all I would say. And then I would go tell my story. But
just mentioning those four words, right, so that they know that I know. Yeah. And that my story is very clearly connected to turn on the lights. Like you're going to argue that my, the HR story I just told you about Steve, you could argue that's turning on the lights too. I got someone else to turn on the lights about a real problem that was standing in the way of their performance that they hadn't shared before. That may even be considered that
maybe they didn't feel comfortable until you actually prompted them to tell. Yeah. Yeah. And in fact, for a while, I didn't get that answer. Yeah, I had to ask that person four or five times to order for them to finally open up about it. Yeah. Yeah. Because not everybody, not every leader that we know, would necessarily respond the way I did, right? That's just the truth. So. And here's an interesting thing. I'll kind of show how this framework
can is flexible. Okay. Yeah. The second value, we, the first value start with human. You answered that one. The second value is find a way. Now, here's the interesting thing. That story can also be a find a way. Yep. Because you're, you're looking at this situation and one path could have been, okay, we're not going to deal with this. We're just going to put this person on an improvement plan. You know, we're going to make life difficult
until they quit. Terrible. Terrible management tactic. But certainly one that people use. Or we're going to find a way. We're going to make this work. So again, it's not because you picked a broad story. It's that you're looking at different aspects or different kind of facets of the same story, right? Does that track? Yeah, it does. You know, when you say find a way, most people interpret that as like if they're an engineer, they think
of it as like find a way through a technical problem, right? That's how it was perceived that. But you're right. Find a way would work with leadership too. But the story that comes to mind for find a way, which is actually kind of funny. When it was in the Zillow, we were tasked with, there's a one of the use cases we support is like mom and pops that own like one rental, right? So not like big property management companies with 10,000
units. But Bob works in tech and he has a rental and he wants to list that rental on zillow.com is zillow.com has rentals. And so, but the the wizard to go through like that, a apartment owner rental owner needs to go through the landlord. It has a place where you have to add an address, not a surprise, but it doesn't real time validate whether that address is legitimate. It actually does that later. Now you already know where this is
going because you've been around the block. So if they make a typo and you get all the way through this process, there was like a two or a three hour delay before we would send you a notification that like, hey, you typed in the address wrong. But it's a lot of attrition. I bet, right? Yeah, not only that, but when you only own one unit, that's not
your job. Like you have other jobs, like you work it like in tech, right? You know, if you don't capture them at that moment or soon after, it's a really bad experience because this person doesn't have all day to go do this. They're doing other things. And so I asked I was the TPM for this project. Then I asked my engineers, what could we do here? Why is it taking three hours? Right? And it turns out and this is going to make you, I hope you
have a bucket nearby because you might want to tell you this story. But so the reason it was three hours long is because they were batching things together. You're like, okay, make sense. And they were batching things together and they were screen scraping. And you're like, oh my God, how could you do both of those at the same time? It sounds so terrible.
And so, and then they told me it was going to take six months to solve this problem. And I'm looking at the solution and I'm going, yeah, I guess I understand why it will take that long. Maybe there was some buffer there, but we couldn't afford six months. So I had to find a way. And and I dug deeper into why there was this delay. Why were these batch processes around? And nobody knew. It was a SQL job. That's all we wanted to go talk
with ops. And I said, can you look into this job? And they said, yeah, I said, what about it? It's been running successfully for a long time. I was like, okay, well, that's good. Like how long does it take to run? And they're like, on average or like the longest it's ever run. And they said, I'd say on average, like nine minutes, I was like, wait, what? And they said, yeah, it runs about nine minutes and it's scheduled to run every three hours.
Why do you want it to run more often? And I was like, yeah. Like how often would you permit us to run that? They're like, well, let me go look at three months worth of, like statistics here. How long has it ever taken to run? Right? Like that seems reasonable. What's P 95 look like here? And they said the most it's ever taken to run is like 15 minutes
is every 20 minutes. Okay. And it's like, yeah, that'll do. And so we had an, we had an OCR, you know, like, and for those that don't know, it stands for objective and key results. We had a K R, a key results for that quarter to reduce the turnaround time it took to notify people that their address was invalid. And this was one component of that. So with zero lines of code, right? Because the ops team just reconfigured a job to run more often. Yep.
Our turnaround time goes from three hours to 20 minutes, right? With a conversation. Just one. With a conversation, right? And you better believe as a PM, like, I'm not going to go after that six months. User store anymore. I'm like, dude, we got like 80% of what we wanted. We're moving on. Like this is infinite ROI. Yeah. So I wasn't able to deliver the sub-second
validation that was the original request. But to go from like 180 minutes to 20 minutes, like there is a chance that if they started this wizard, because the wizard takes maybe five or 10 minutes to go through anyway, that I will still be able to capture them before they go off and do something else. And so for our perspective, it wasn't like we like knocked it out of the park, but man, to spend no engineering effort and to get 80% of the way, get it 80% smaller. Well,
not even 80% eight times smaller is, is, is, is a, is that's how I found a way, right? So like, like I said, that I'm doing this live. So I would practice this and it would be much shorter. But yeah, of course, right, right. When you hear that story, like what do you think about the person that's telling the story? I think first, the way that you woven like the subtle, like we were talking about, it's not on the nose for the value, right? You quickly kind of you wove that in in a
way that felt authentic and true to what the value is actually representing. So that's one piece of it. When I hear it, I think, okay, this is a person who, again, the okay, our orientation, the Alchem orientation, you know, you're not jumping to code, you're not jumping to, you know, try to make your developers do, you know, go and go and try to code a new thing to solve the problem. You're not one solution, one type of solution minded. Instead, you're focusing on the variety of ways.
You know, you're looking at what is the actual root of the problem. And we can attack the root of the problem with, again, like a Pareto principle 80-20 kind of thing, right? So you, you accomplish a ginormous lift, recognizing that, well, there still is room for improvement. But product has chosen not to pursue it, which is the prerogative. And it tells me a little bit
about kind of like the power structure that you worked in in the past as well. So that kind of gives me some meat on the bone to discuss like, well, you know, at our company, maybe product holds a little bit of a different role than what you worked in there or whatever. So you're giving some kind of more than just saying, here's what I value. You're also saying, here's how I have worked before. So there's a lot that comes with this. And this is why I think stories are so valuable
because they communicate so much. Right. This is the key to a great interview. Is really just nailing these stories, I think. Yeah, stories move the world, right? I mean, people write them $50 million checks to start up founders based on stories. Yeah, there's data there too, right? But even if you have the data, if the story is not compelling, like stories move people, the data still has to be stitched together, right? It still has to tell a narrative of why now
and why this, why me, right? Why would you give me money to go do this rather than going and doing it yourself? Yeah. So we have, we've gone through two of these. Do you have time to go through the other two? Sure. Excellent. So, so we've, we've gone through start with human, we've gone through find a way. Hang on, airplane. Okay, they moved. We've gone through start with human, we've gone through find a way. Now we're going to go through the next one, which is focus
wisely. And to give a little bit of color, I'll read a little bit from again, this is on the Calamly careers page. It says, we recognize that all things do not matter equally. We are highly analytical in our approach, digging deep to discover the top priorities. Boots strap mentality keeps our focus on what is most important. We think lean, act resourcefully, and refuse to compromise on quality. So tell me, tell me about a time when you had to choose between two really good options.
Yeah. So definitely the kind of person that loves to think about global maximum. You know, and I think there's a lot of leaders that think about maximizing their team's ability to get something done, but there comes a time when you look sideways at a sister team and you look at what they're trying to accomplish and you compare it to what your team's trying to do. And if you were the director of the VP and that other team was struggling, you would offer some of your team's resources
to help them get things over the line, right? Because like, it's just how the way things play out, right? Sometimes we have the huge impactful project in Q3. And then our sister team has this huge impactful project in Q4. So I remember a time when my sister team was struggling. So I was in a growth org. You know, I worked for this engagement team. And this other, there was another team, there was this sister team of mine, and they had this huge project. And I remember looking at what
it was, we were going to deliver and talking with my PM about what was left in the quarter. We had already planned the quarter out. We had our stories lined up. And I just remember looking at the stories and being like, I just don't feel like this is, I don't feel responsible using my resources on the things inside my little ring fence. Like, you know, backyard pasture when I see my neighbor and what they're trying to accomplish and what our resources could do for them. And so focusing
wisely for me in this case was talking to that other engineering manager and their PM. So we had what's called the two unto you know. So we brought, you know, the PMs and the engineers together for sister teams. And, and I said, you know, a resounding success for my stories that I'm working on are not going to deliver a tenth of the impact. If I lend you some of my resources to go after this,
this big swing you guys are taking. And so I want to talk about a proposal we could make to leadership to cut some of the scope that we were going to deliver this quarter in favor of lending more engineering horsepower to your team. Because as it turns out, these two teams were once a single team and they had recently split when I joined. And so most of the people on both teams had the same domain knowledge. So there's not really a lot of ramp up time. You know, they could
really kind of pivot pretty quickly much more quickly than other teams could. And RPM was kind of a little frustrated about it, you know, which makes sense. They said they were going to deliver this when I said, but can you look at me and tell me that if we deliver this at a resounding success that that our impact will be higher than if we just helped this other team and they couldn't really say it. They were like, no, you're right. And so we went to leadership and we said, hey,
we want to lend some non-zero amount of resources to this team. And we have a proposal for how many people that is, but we want to explain why. And then we want to get your blessing on this idea. And then we want to talk about the minutiae of like how much, right? Because there's an if we should do this. And then there's a, okay, wow, many resources should go over there. And that worked really well. And it not only did it give my team an opportunity to work with people
they missed working with because the team had split. But it also gave them an opportunity on their own reviews that year to write about something that they were a part of that was 10 times larger than if they had delivered things on our back wall. Right? And what does that do to their resume? And their review and their ability to grow as engineers. And also what does it do when I can model as a leader, this behavior that I shouldn't just care about what's on my roadmap. I should have this
idea of global maximum. Yeah, just local maximum. Right? So, uh, how do I want environments will support that? But that's environments that I look for when I'm interviewing. And so I would kind of weave that into the interview and say, so is that type of, you know, is that type of behavior something that is would be encouraged at a company like this? Like, yeah, if the answers know that it might
not be a good place for me to take an offer. Right, right. And that's, and I think that's an important note here is that you're not, again, going back to what you said earlier, I think this is so critical. This is not a test. You're not trying, this is not an essay. You're not trying to score certain points. You are legitimately answering a question, right? Sure. You're answering a question in a way that shows, uh, kind of a thinking like a spectrum analyzer kind of
way of thinking about this. It's like, where do you live on this spectrum for focus wisely? Well, I live in this area where I think about global maximum. Is that something that makes sense? Or, you know, the alternative to that somewhere else on the spectrum is not necessarily positive or negative. It's more just, you know, how do you operate? Right. What are your ways of thinking about focus? Maybe you focus hardcore and you, you know, this is, this is an alternative version.
You focus very much so you protect your team from outside invaders. And it's not a global maximum. Hey, we have these things to accomplish with our team and maybe that works in particular environments or something. I don't know. Um, as a, as a kind of a, again, an illustration here
because we're kind of doing a mock interview. I just realized that we didn't really, uh, preface that I'm going to kind of respond as they interview our minds about that specific story you told to see, you know, so we can kind of explain like when you're prepping these stories, don't just prep the story. And then if you get asked a question about it, you fall apart, right? They're, they're some contextual information. So I'm going to ask you a question about that story.
Um, you know, I've seen a similar kind of approach where, um, you know, one team can say, oh, hey, I see you team A is struggling. So team B, I lead team B, I'm going to give you a couple of my developers for a few months. I've seen that fail in particularly strange ways. Uh, one way that it fails is, uh, if you're shoveling resources around constantly, so there's
not really a sense of continuity for the team. And then the second way that I've seen this fail is if the other team feels threatened by the need for those resources, they feel that their opportunity to show that they can succeed has somehow been diminished, that they need someone to come help them along. So I'm curious, you know, how did you, uh, did you think about those kinds of risks when you, when you made this offer? And then how did you mitigate those risks?
Yeah. So since that original team, so context here, when I joined this team split, this big team split into two small teams. So when this event happened, it had not been too long after that. So there's still a strong sense of camaraderie between these two teams. In fact, the best way to describe the environment is that they miss working with those people that they used to work.
And so in that sense, there's an advantage here because this is an opportunity to give them something that's hard to give them after a split, which is to like get the band back together, right? Yeah. Yeah. And go work on this thing. And, uh, and because they'd work together for a while, and the charter basically got split, they already felt ownership for that larger charter, and we're getting used to not caring about the whole thing. And so there's this real psychological
ownership that existed on that team, even before the split. And so this opportunity to help the co-workers that they enjoyed working with was something that they were looking forward to. So that's one thing. To, uh, you know, if we think about what the cellular process of mitosis, right? Like a cell kind of starts out kind of like a circle and then gets a little stretchy, you know, and then that the space between them gets a little thinner and then bonk, you know,
they kind of become two cells from them. And so that process was happening organizationally here. So I don't feel like it was chaos to help them, for them to help their prior co-workers get something really important over the finish line. And then secondly, in terms of did that other team feel threatened by that? It's like not really, you know, this is not some stranger team. This is people they'd work with up until four to eight weeks ago. And so they missed working with these
people. They wanted work with them. And then on top of that, you know, being a growth org, I don't know, you know, in an interview, I wouldn't be able to assume that the interviewer knows a lot about growth orgs in general. But a lot of growth organizations work in what's called an away team capacity, which is to say they work a lot on code bases they don't own. And so a growth team kind of goes around and looks at what other teams haven't prioritized for
the quarter because of other resources. And anything right below the cut line, we might volunteer to do work in that code base that belongs to another team. We have a good relationship with them and we've set up some contracts about what's expected, sportability, things like that. And so this idea of helping another team is also sort of embedded into the cultural DNA of a growth organization. So in that way, the worry about it feeling threatened, it's like, well, no, that other team is
actually doing the same thing we're doing. They are volunteering their resources to other orgs in order to work on things they don't have capacity for. So since we're in the process of offering our resources to other teams, there are a lot less likely to feel threatened when they are experiencing the other side of that. Yeah, it sounds like there's like a, this is a practice like a supported practice in the org. And so it's not an unusual or unexpected thing
for that to happen. And just so happens that you had the opportunity to tap into that established way of doing things in order to optimize for the global maximum. Yeah, for sure. And I've been in experiences where that didn't happen. The inverse of this for me is, I can't share the details of the metrics themselves, but I was once working on a team that was in charge of ensuring people buy more crypto. They've already bought once we just want to make them buy
more often. And then I remembered looking at a startling statistic of an upstream team. So in order to buy crypto, you have to have a payment method spoiler alert. You have to have a way to means to buy things when you want to buy them. So, but in crypto, you can't use a credit card. It's not allowed. So you have to be willing to connect. Basically, you're checking account to an app
to buy crypto. Not everybody wants to do that. Right? Yeah, sure. Because if a hack happens and suddenly, some, you know, like people just go immediately into nightmare scenarios. I would think that crypto is not the first like, trust and crypto, not the first two things. The first word that comes when we think about crypto, especially if you, even if you know more about it, the idea of undoing a transaction is not really possible. Yeah. Like, not the way ledgers work.
Right? So oops, extra zero too bad. Yeah. Or oops, send it to X, zero, zero, zero, zero, and address. And I just burned something right. Yeah. The transferring it just doesn't exist anymore. So, and I remember seeing this really startling statistic of an upstream team about how, what percent of the time when someone tries to add a payment method have they been successful one week later.
And there's a number that I thought, like a percentage in my head that I had. And when I heard what the real number was, it was off by a factor of 10, meaning it was 10 times lower than I thought it would be. And I was like, wait a second. In my mind, I'm like, you're telling me there are millions of people stuck behind this ad payment method, damn, that want to give us money and haven't been able to set up their payment method yet. And my team is working on all these tiny little features
to try and get people to buy a little bit more crypto. When if we went and helped that other team with that problem, it would be several orders of magnitude larger of an increase. Because if you've got a million people outside your restaurant that want to walk in, what do you do? You want to make you make your restaurant bigger, right? Or you make the doors wider. And I remember thinking, wow, I really, my number one priority now is to widen that funnel. Like, right, if this was an
hour glass of sorts, like, how do I make that choke point? How do I widen that choke point? Because just doing that would be so much more impactful than working on these features I have. But that requires being really creative and trying to convince people and other works to let you work on that could be not everybody's comfortable with that. So, right. Yeah. It reminds me of something we were talking about earlier, and I think it applies to the theory of constraints.
And really just thinking about system, system variables and where is the bottleneck? We were talking about earlier about the effectiveness or lack thereof of focusing on the technical aspects as not the bottleneck for most of these roles. In the same way, we can talk about this global maxima idea of recognizing where the bottleneck is for the organization rather than bottlenecking at some sub part, right? It doesn't matter how fast your team is running. The org can still fail and
just so happens, your team is a part of it. But yeah, now we're kind of piercing the veil of our mock interview a little bit. But this is so again, you've shown like you have such a good level or a high level of awareness about what these stories mean and contextually you didn't
memorize a script, I guess is what I'm trying to get out. You have certain points that you want to hit in the beat of the story, but it's not like you're reading a script out and then when somebody asks you a question a dig deeper on a particular aspect that you fall apart, you're able to talk about it because you understand the story, not because you've memorized key points or talking points
without the context. Yeah, absolutely. And I think one thing that's really important to know, like and you and I know this is interviewers, Jonathan, but to share with the audience, it is 90% more likely that you will talk too long than you will talk not enough. Yeah, right. So this is something you told me that actually was was good reminder and something that I had not really thought about in an interview and something that so go ahead, sorry.
Yeah, so there is no real downside to providing a concise verbal answer and then inviting more discussion because it feels more like a conversation rather than a soliloquy. Yeah, right. And so, but you and I have both, I'm sure written feedback like, wow, I asked a simple question and they went on for 15 minutes and in a way that's factually true, but there are not that many interviewers that will interrupt you to make sure that we set aside enough time to get through
everything we should get through. So there are people out there that if you talk too long, they won't stop you. Right. Yeah. So you want to eliminate that risk and tactically the way to do that is to have a concise answer and then not to say, would you like to go deeper, but just assume they want to,
where would you like to go deeper? You know, or what, where would you like to, you know, what details would you like to know and that making your responses more concise means you can't get too far away from what the interviewer wants to hear as long as you're asking these check-in questions. You go and you'll never get penalized for a concise answer with a check-in question. And because this goes back to you. Yeah. Go ahead.
All right. It's just going to say it goes back to the signal discussion. Yep. Because do you have the signal you need or do we need to go deeper? Right. And our default is likely to keep providing signal and keep providing signal like, we're a hose that they turn on. Right. Yeah. And and just wait for them to move it along. But actually what we should be doing is we understand, if you walk into an interview and you recognize, okay, this person has, let's say, you know,
10 things that they need signal on. And in order for us to get through all 10 of them, we might need every minute of this interview. Yeah. You want to get to all 10 of those. You want the signal to be there because if you only get through, let's say, a third and make no mistake about it, some things you're going to be weaker on than you are on other things.
Let's imagine that the first third that you go through, you're weaker on than you would have been to the second and third thirds, you know, the latter part of the interview. Then you've lost the opportunity to show your strengths. Right. So you're not able to get to
the important stuff. And now in the debrief, when they're looking at you versus another candidate that maybe has mediocre performance, but they got to all of the questions, they have signal across everything, they're likely to pick the other candidate to move forward. Is that does that squares that seem correct to you? Yeah. I mean, do you want to work with the person that rambles on? Of course not. Like, and stand up when stand up is supposed to be like seven
minutes and this person takes seven minutes themselves, right? Yeah, exactly. Like, remember, we want to demonstrate behaviors that make it that sort of accomplish, that answer this competence question, but that also passed this sort of co-worker. Straight to work with this person. And that is often harder to describe in interview feedback, but I know you felt it. Like, some of these interviews we take, we're like, man,
I wish I had an opening. I'm going to write this person's name on a posted note somewhere. And if I move to another company and we get an opening, I'm fine. Call them, like, yeah, call them and saying, dude, you need to come here because you're amazing. Because interestingly, I would say I've even had interviewers that I would put in that category.
Yeah. But that's a different discussion. No, yeah. Like, I've done it the same way. I gave a really good interview experience to a few people at Coinbase and they ended up not getting the offer. But they reached out to me later because they wanted to work with me in a different capacity. It happens, for sure. Yeah, absolutely. We'll be right back with a continuation of my interview with Brian Pley. How long should it take to write seven lines of code? Minutes?
An hour? What if it takes five days? You might be tempted to think the developers on your team need help writing code, but that's not usually the case. The biggest drag and software development isn't writing code. It's having enough context to know what code to write. In a perfect world, your engineering team wouldn't waste time, days even, searching for the context to understand your application. But on average, most developers spend more than two hours a week trying to find
information about how a codebase works. That's why there's Unblocked. To give your engineering team the answers they need to get their jobs done at the speed they and you both want. Your codebase is a compilation of thousands of past decisions and discussions that live across tools like GitHub, Slack, Gira, Confluence, and more. And Unblocked surfaces this history next to your code. So everyone on your team has the context they need. And when someone has a question,
Unblocked answers with the accuracy of your most experienced engineers. Get started today at GitUnblocked.com. That's G-E-T. Unblocked.com. This episode is probably going to be cut into two parts. And then we'll do another interview because what we really wanted to get into is this idea of starting out. What is the first 30 or 60 or 90 days, like the infamous first 90 days book that's sitting on my desk right now?
Literally I'm looking at it. I really want to dig into that stuff with you in the next interview probably. And we'll cut this one into two parts. But let's get into this last value and see how this what kind of story you could match to this particular value. Strive for excellence. A little bit of context. We are self-starters who crave empowerment, actively pursue opportunities for impact, take initiative, etc. This is the one that you kind of already mentioned. You're looking for
excellence, right? Yeah. So tell me about a time. And this might be the question. Tell me about a time when you really needed to go one step further than maybe what the base level expectation or what the spec said to go. Yeah. So I'm the kind of person who runs every role that I have in a very people
forward manner. So when I join Zillow, I joined as a technical PM on the CICD team. So for those that aren't familiar, it's like continuous integration, continuous development, build and deployment team basically. So a lot of tech companies have a team chartered with owning the pipeline so that all the other teams can push their code, right? And push it to test environment, share test environments. They have this idea of staging or production. Production is usually handled by ops,
depending on the culture of company. So I joined this company as a TPM. And one of the first things any decent PM does is especially if they want to platform team is go talk to people. I'm going to introduce yourself and ask them, Hey, I'm new here. What do you like about what we offer as a team? And what like makes your blood boil in terms of pain points, you know, and being a new guy, you can rail on me as hard as you want, right? I have no skin in this game. I didn't write these specs.
And I got a very vivid, consistent picture that went something like what you offer is so awful that I am investing money out of my own budget to buy an alternative even though yours is free. I was like, wow, wow, okay. So tell me more about that. And it turned out that we had built a system and tried to support it for a long time without doing a lot of without addressing technical debt. You know, there's side effects to that. We were using Jenkins and there was a highly variable
amount of time between when you committed and when a deploy started. Well, if you know CI CD, either the C in there stands for continuous. Which is to say that it shouldn't be very long between a commit and when a deploy starts in your pipeline. And our dashboards have told us that, you know, these delays were something like five minutes to 45 minutes. 45 minutes is a long time to wait for a CI CD pipeline. It basically was not meeting what I considered an acceptable bar.
Like these people don't consider this not only is it long, but it's inconsistent, long. And in some way, the inconsistency is worse than the duration. It always took 20 minutes. An engineer could go read a PR, like go get some feedback, right? Go open a design doc, go to a stand up, do something. But when it's inconsistent and highly variable and it could be long, it's like insult to injury. So the first thing I did is I partnered with some of the more
technical people on my team, my principal engineers I had to. And we talked about what are we going to do here to raise the bar on excellence. And it took a while, but we were we're factored, we significantly refactored what it is our customers were exposed to. They were actually exposed to how we were storing our data in Yamal files, which was kind of terrible because we could make it data change without them having to change the way they did things. So we had to create a bunch
of wrappers. And once we've done that and refactored everything behind the scenes, we got our P90 delay from commit to deploy start down to under three minutes. And while supporting a 10X increase in deploy volume. So 10 times as many deploy requests coming through the pipeline. And instead of up to 45 minutes being P90 being something like 15 times faster under 10 times the load. So you know, I don't think nobody told me and sat me down. My boss didn't say you need to go make
these happen. But when we started thinking about what's the right thing to do to encourage people to submit smaller PRs. It is certainly make make the right thing the cheap thing. Yes. So our solution with this highly variable and very lengthy delay was encouraging people to create larger PRs because they didn't want to have to wait. So it's like well that's working
against the spirit that we're trying to achieve here. So what would a delighted customer see in terms of a measurable success criteria around stability, you know, performance and friction. And so once I did these interviews, you know, our new mission became, you know, we provide stable, fast, low friction developer experiences for all engineering teams as a low. And all of those adjectives had metrics. And when we met those metrics, we raised the bar. And no one told us
too, but it was the right thing to do. So there's what we need to do to be acceptable. And then there's what we should offer, especially. And in our case, we just saw our team as the pit crew, right, for the race cars and these engineering teams are race cars. And when they pit and they need to submit a deploy, the longer it takes like the more competitors are catching up to us. So once we instilled that kind of culture, then what we went after was a lot higher than we were expected to.
So that tells me as your interviewer, that tells me one, you understand excellence in the way that I probably was asking about this idea that there's some quality that is not necessarily explicitly defined. You don't have to have everything, you know, handed to you in order to make a judgment call. Right, that's that's a part of excellence. There's an interesting wrinkle in this. And I'm curious what your thoughts are.
This idea that there are bars that we set that you have some intuition that 45 minutes is too long, three minutes is much better and probably acceptable. We're going to continue raising a bar. But, you know, that idea of there being some art to that. I'm curious, you know, where would that line be? How do you define what if it was 20 minutes or what if it was 15? You know, where do you, you know, how do you develop that intuition? It might be a question I would ask as an interviewer.
Yeah. Yeah. So I had never worked in a CICD team before I joined that team. So I didn't know what was reasonable when I started either. But when I went and met representatives from probably like 25 to 30 of the 35 engineering teams at the company, you know, a pattern emerges. And the types of questions we ask are, well, what sucks about what we offer and what would it look like for it to be a great
experience for you? You know, and I think you're probably familiar with John, I think the law of five, right? There's this idea that if you take five data points, the odds that the median is somewhere between the men and the max of those five data points is something like 95%. I can't remember what the exact terminology is. But in a situation like this, when you ask, like, what is a reasonable commit to deploy start delay, you're going to get a range of numbers. And the reasonable one is
probably somewhere in between that range. And then when you go back and you talk with a team and you say, okay, well, what can we accomplish? And then, and then we say, well, this is what we could do quickly. And then you ask, well, like, what, what would it take for you to be proud of what we've done here? Like, not that just we got the work done. But like, what's the bar that's exciting for
you to go after that makes you want to put that impact statement on your resume? Like when you move on to another job where you feel like you can kind of boast about how amazing we made this. Because I know a lot of people settle for, I'm going to insult people in an entire state when I say this, but like, I don't have like a lot of interest in going to New Jersey. So like, if I have to do a lot of work to win a trip to New Jersey, I'm not going to work hard for it. I'm sure people could
say that about a lot of other things. But if you tell me that I could win a week long catamaran trip in the Mediterranean, I will probably run through a few brick walls to make that happen. Right. And so there's this idea that, and yes, there is a bit of judgment and data that it needs to be compelling, but also feasible and exciting. It needs to be something that out sizes
are resources, but not our intellect. Right. This is a Simon Sinek quote. Right. Like if you, if a leader can give somebody a problem, a team that outsizes their resources, but not their intellect, then people will do everything they can to go after that problem. You have to give them something exciting to achieve. And sometimes that thing is harder to achieve, but we're more excited to achieve it. And it gives. Does that answer your question? I think so. Yeah. I think
part of part of the question is, how do you pick? And then the other part of the question is kind of like, how do you, how do you choose a threshold? But I don't think that that is necessarily the insightful one. I think to your point, there's the threshold is what is exciting. Like what, there's a problem here. Let's set a threshold that gets us to a place where we collectively are happy or are excited about the accomplishment that we've made, which may be going from three
hours to 30 minutes. Right. If you had a three hour CICD process, cutting that down to 30 minutes is a massive improvement, where 30 minutes may be again intuitively bad at another place. There's a lot of subjective kind of experience-based things to deal with in this kind of situation, but I think your, your heuristics are good on their own. The idea that, you know, you're not necessarily, you're not necessarily beholden to a specific number at every place. In other words,
you go to another job, you encounter a similar problem. Three minutes is not necessarily going to be your new standard that everybody has to meet from now on. Right. Yeah. There's a crawl walk run approach here, right? So there is a, like, how far away from running are we? And do we, can we make the investment is running necessary? Right? Right. I don't need to run in my kitchen. My kitchen is not that big. Yeah. I'm walking in my kitchen is sufficient. Yeah. And I can, in fact, it might be
quite dangerous to run in my kitchen to be holding in my hand, right? So I may not even want that. But you know, what I experienced in that environment was a, people don't really trust us to build the right thing because what we're offering is so far away from their expectations. Okay. So what is it? What are their expectations? Right? And what can we do to quickly make small improvements?
And in parallel, set up things to make a larger improvement so that we can earn back the trust for them to share feedback with us that they weren't even, they wouldn't even trust us with at the beginning. Yeah. Yeah. Absolutely. And how do we build those relationships and then show them that we are like a partner in them, right? Right. Again, this is where this idea of using a pit crew analogy was very compelling that it's like, you don't have to be the race car driver to contribute to
these teams. But if you have a bad pit crew, like you can lose races. Right. I wanted, I wanted our team to feel that sense of like this pit crew is really about like how quickly can we get these teams back out on the track because the other teams are not pitting. Like red is not pitting. This often is we are. If our system is slower than our experimentation feedback loop is slower. And if that feedback loop is slower, we are learning more slowly what works compared to our competitors.
So what can we do to excite people about working on shared library dependencies, which is not the sexiest topic for a lot of people. Even if you're not exciting. Yeah. So that's how we found a way to make the work meaningful, like to give people a sense of purpose. Yeah. Yeah. There's as a manager,
I often think about resume driven development. Right. It's the idea that like, what is something that we could say, this is bad enough that we could put it on our resume if we improve it to this point. Yep. And I know that of course that's not the only determining factor, but it's a good heuristic, right? It's, would I be proud enough of this work to talk about it in an interview setting? If not, then why not? Like what's in some, that's not the, again, not the only thing you would
you would want to ask about. But in a question like this, the excellence question, absolutely, absolutely. That would be the kind of thing that you would want to focus on is, you know, something that would that would land on your resume as a way of talking about excellence. So again, I guess kind of zooming out of this mock interview for a second and reiterating the importance of these, of the story driven approach and practicing these stories, practicing,
understanding the context for your own stories. You'd be surprised a number of people that I've encountered in interviewing where they would tell a story. But then if you ask them a question or follow up, it was almost like talking to two different people. So that's why I wanted to kind of go into those, just follow up questions with you. Brian, I'm curious, before we close out this part of the interview, what is one thing? Let's talk about, okay, you've gone over the hurdle
and I know we didn't cover resumes or anything like that yet. We can talk about that stuff in the next part of this. But let's imagine that somebody has gone through this process. They've gone through, you know, they've used some of these tactics we talked about. They've gotten an offer, they like the offer. We're making a bunch of assumptions here, right? Fast forwarding, but we're getting close to day one of this job. Is there one piece of advice for somebody who's launching into a new role?
One piece of advice that you would give them to start out well. Yeah, you know, when we join as an engineer and a new company, we tend to think from a scarcity mindset, right? We say, how long is it going to take me to get up to speed? I need to onboard, I need to ramp, how quickly can I ramp? There's this sense that there's not a lot you can offer because you believe that the only thing you can offer is to push a PR. Right, yep. And there's so much more that you can
offer that is not pushing a PR that you could do in your first week. So I want to make some assumptions since you made some already. So, yep, of course, and to do so. Sure. So let's say you're coming in at more of a senior role. So you're not, you know, and by senior, I mean, I'm expected to amplify the impact of the people around me. I'm expected to mentor and coach more junior people. The most valuable thing I can do every minute of the day is probably not always writing code,
because this is a senior. There's other things that are sometimes more valuable, like convincing an art director and not re-render art that's not necessary. And a lot of those things, you can observe a lot in your first couple weeks and compare it to what you expected to see. Right. Like if you think about, let's just take a simple like three-legged stool approach,
like people product process. You join a new team. If you're a senior, you have a sense of what a senior should know at this company or what a staff engineer does or what a college hire's capability is. And you should just listen and ask questions and observe a lot and document what you're seeing. Now this may be a little bit more lab code, right? You know, observe what you're
seeing. And I don't know if we ever talked about this onboarding exercise. I think we might do that in our next session, but this idea of just writing down observations, good observations, things that are working well, things that aren't working well, things that are confusing to you, and then just gathering them up and then talking with your manager about them in your first 30 days. You know, you have your next one on one. You're like, I have this list. I want you to look at it
before we meet. And then I want to talk about them. And that in your observations and sharing what you think is doing great and what is not doing great, the signal you get back from your manager will help calibrate you to the like what the expectations are in this team. And I think as a leader, like we've never talked about this before, but I think you'd probably agree that 90% or more performance issues come from a lack of crystal clear alignment
and on expectations between direct and their manager. Yeah, maybe if not more. And so in a way, just like we use this sort of check-in question in an interview, which is kind of like Marco Polo, right? We say Marco, and then if we realize the interviewer's way on the other side of the pool, we're like, oh, we've got to get closer. We don't want that distance to be too far. You don't want the distance to be too far when you join a new company.
There. So you want to share what you're observing like as a Marco. And then listen to what your boss says as the Polo, because you're calibrating yourself on what your leaders expectations are of what you're going to do. You know what? Yeah. I've seen senior engineers that write half the code for a team, and I've seen senior engineers that write, you know, a tenth of the code for a team, even on the
same team size, right? Because what they were expected to do was just different. One of those teams where he didn't write a lot of code, it was like he had to help a sister team as the architect because they didn't have any seniors. And so he had to build a system from scratch. But that was a lot of training that other team on how to be self-sufficient. Well, it's not like writing a lot of code, right? That's sitting down and talking about sound principles, first design, how to analyze
this system, all that other stuff. So there's one piece of feedback. I would say, don't assume you can't contribute, but the way you contribute might be to have conversations on your observations. And then you can calibrate to make sure that the distance between you and your boss on what you expect success looks like as small as it would be possible. Yeah, I'll reference the first 90 days
here for a second. I'm curious what your thoughts are on this because I think it's kind of echoes what you're saying, but it has this kind of odd, and for some people, I think even off-plitting way of explaining this or articulating it, they say to negotiate success, or I guess he, Michael Watkins, who wrote the book, he refers to it as negotiating success. So the idea being that you meet with your boss and you talk about, okay, what does success look like? And perhaps adjust
those expectations on both sides. So you get a little bit of a change, and let's say your boss thinks that success is, you know, you're bringing that CICD time down to under one minute. We might want to negotiate that up a little bit, or getting, like you said, alignment maybe is a better, I think a more palatable way of thinking about, is how can you negotiate success? Success is maybe defined outside of the negotiation table, but I think negotiating what your expectations are
that does track for me. What do you think about the language that he uses in the book for that? Yeah, so I'm a big fan of the first 90 days, like you know I am, but with some caveats, right? Yeah, with some caveats. I think the first third of the book is really good, you know, in a way that it helps to identify what scenario, like, you are you in, right? Start off, or you know, are you in
this, whatever, you know, it's the stars, is the acronym they use in the book. And I think that's helpful because there's some ramifications about what you should index on that doesn't require a lot of data for you to collect. In fact, I took a picture of that page in the book and I sent it to my boss and my skip level and I say, we're in A, right? I wanted to hear from both of them, both my senior manager and my director that they gave me the same answer. In fact, it was very
important that I heard the same answer. I wanted to make sure that they had alignment, right? Yes, and when I did, it told me a lot about what to go after. But I did have to negotiate success, like 10 days, 14 days, 14 days into my, that job, my boss came to me and said, I want to give you seven more direct reports. I had six at the time. So they wanted to go from six to 13. And I had to negotiate success. Now, maybe I didn't do a good job. I'll tell you what I did. You can tell me
a big job. So, I mean, I got laid off, but I wanted to. So I'm not sure what that means. So, I asked my boss, I said, how important it is to you that I have a successful first six months, first 12 months in this company. And I don't mean like that you care about me. And like how important is it to your career, like as a manager, that the managers underneath you are successful.
And he says, it's very important. I was like, okay. And I said, if we have a scale rating of one to five for employee performance here, and I don't remember if we did, but it's just pretend we did. I said, if you give me these people, what do you think the impact is to my performance rating, like just as a baseline? He's like, what do you mean? I was like, well, imagine an A, B test, where you didn't give me this team and what, and what kind of performance ceiling I have. And you
give me this team. He's like, yeah, you're probably going to take at least a one point hit on your performance. It's like, so if I could get a four without this new team, at best case scenario, then the best case scenario I could get, if you give me, if you double my team sizes of three. And he's like, yeah, that sounds about right. I was like, do you want the ceiling of my success to be a three in the first 12 months of me working at this company? And he said, no. And I said,
in that case, what I hear you saying is that we shouldn't give me these people. And he said, yeah, I guess that's what I'm saying. I was like, okay, like I'm open to expanding my span of control. But I don't know if like in the first two weeks of this job is the right time to accept this. What do you think? What do you think? You know, and I sort of had to use his own logic against him. And I'm really glad I didn't, but I probably could have shown more impact if I did,
but I don't think I would have been successful. I don't just allowed them to give me that a non-negotiable sheet. Yeah, I think it's a valid response. Right. I think it's, I think you're correct about what you're saying. I imagine the feeling for your boss was like, like a little deflated that this didn't pan out the way that he was most, most managers I've met, myself included, are hoping,
often, hoping that I ask somebody to do something like that. And they step up to the challenge and somehow, some way that I don't necessarily have direct impact over or control over, they hit a four with those seven extra people. Right. That's the hope. And of course, that doesn't make sense. And you kind of showed him that that doesn't make sense. So in that regard, I think it, I think that worked great. Right. Like you came out of it without being
overloaded. He came out of it having made the argument for you to not have the reports when he had walked in asking you to have the reports. And I think, yeah, I mean, I, many people might say, oh, that's an, that's an opportunity. But I think you actually showed your manager, my goal is not just to chase opportunity for the sake of opportunity in that situation. But instead to say, no, I want to actually meet a level of excellence going back to our
earlier conversation. That's acceptable. That's, that's where we set the bar. So if I'm not going to be able to do that with these people, do you still want me to move forward with that? Yeah. Yeah. Yeah. And I did. I probably lose that on career velocity. Absolutely. You know, I'm sure like that I'd taken on 13 direct reports. Maybe I would have got promoted to senior manager. Maybe I wouldn't have gotten laid off. But, you know, I'm being a thousand years old now
in tech, in tech terms. I'm very clear what it is I want. Right. And the type of environment I going to thrive in and to, and to just say yes, boss, and to accept those people. A lot of people would make a different decision there. But it's not what I was looking for. Yeah. I didn't want to look back and say, I wish I said no. And things would have been better. Because it would sacrifice my ability
to lead people in a way that I feel like philosophically. It's the way I want to lead people. Like, I'm a very people forward leader. Anyone who's worked with me will tell you this. And that has implications. You know, we went through an exercise to identify your strengths. I've done that with every direct report I've ever had. And, and to have that kind of insight into every direct report. And then to be able to look at the team structure of who's good at what? You know, if we look for
the strengths that overlap, what is the most overlapping strength on our team? That starts to suggest the type of culture or team norms that we want to enforce. Yeah. Yeah. And so I want to be able to devote enough time to my individuals. And I didn't feel like having 13 direct reports is going to let me be able to lead the way that I felt was most important to lead the way I wanted to lead. And that was the conscious choice on my part. But, yeah. Other people
would make a different decision. And that doesn't mean that my decision was wrong. It just was wrong for me. Right. Well, and I think, I think that, well, this started out as a question about the first, the first, like, initial, I guess, like, first week on the job. But I think your point about negotiating success in this particular manner, you have an opportunity in that moment to kind of set the tone and expectation. There was a manager I worked with one time. And this particular,
the company I worked with at the time was mostly remote. They had kind of a central group of people who worked in mountain, mountain time. And this particular person worked eastern time. And periodically, the company would ask people to travel for, for like, summits or her, you know, all hands kind of stuff. Okay. This person doesn't like traveling for work. And so right up front, they kind of negotiated in this position of, I don't really do that. I don't really travel. Now,
hear me clearly. I don't necessarily think this is like a good negotiating position to take, per se. If your company is actually in your travel and that was part of the expectations, when you were hired, and it's probably a tough sell, but this person was able to successfully do that. So that now, when it's time to travel for most people, this person just doesn't have to do it. Now, to your point, like, when you're negotiating, that's not a, let's see, everything that I can get.
There's a two-sided part of that conversation. You are also giving something up potentially, right? Yeah. There's a trade-off. Yeah, absolutely. Okay. Brian, I think we could talk for another three hours, and we wouldn't get through everything that we have that we could talk about here. I'd like to kind of get a final, I'm going to ask you one of my questions that I ask everyone
that comes on the show. And I'll ask you the other one on the next episode. The first one is, what do you wish more people would ask you about? What do I wish more people would ask me about? I think, while the first question that comes to mind is, why did you make this transition? Because for the people that don't know, I pretty much made a conscious transition to go from full-time work, earning a lot of money, like a lot of money,
and Fintech, to earning like 84% less. I took an 84% pay cut to do what I do now. And I think I would love for everybody to ask me, why did you take that pay cut? And how did you convince yourself that your happiness, your fulfillment, was worth that much? Because I think for 20 years in my career, I would never have thought that my fulfillment or my
happiness was worth a pay cut of that magnitude. This is a lot. I mean, just to be transparent, like we're talking about it, like a half a million dollars a year pay cut, like not trivial amounts of money. And so I wish everyone I spoke to would ask me that so I could just share my story and provide maybe some feedback about what I thought about my career five years ago, what I think about my career three years ago, and what I think about my career today, because those three answers
are so different. And I would love to share that with other people so they could find their own version of what a rich life is for them, which is not always financial. I would say rarely is financially only part or the only component of that. Yeah, for sure. That's a very long answer to very short questions. Yeah. I would say given the number of answers that have gone longer, I would put this in the shorter column of all the all the answers that I've gotten to that question.
Yeah. Brian, thank you so much for your time. I look forward to our next discussion and of course to our sessions upcoming as well. If people are convinced, if we have convinced them that coaching is worth their time, worth their effort, worth their money, where would you send them? Yeah. So if they're interested and they want to talk with me specifically, the best way is just to go look me up on LinkedIn, Brian Pulliam. Brian K. Pulliam is my URL handle on LinkedIn, or they
just go to refactorcoaching.com. That's my website. It's a really crappy landing page as most engineers would make. I'm not a designer. But if you're curious about career coaching in general on how you might find a better one, we can talk a little bit about resources in the next episode. Sure. Point them at. But the TLDR is don't settle for a coach that isn't a good fit for you.
Because there's a lot of options out there and they all offer something different. And so making sure you interview a few before you decide, I think would be a good decision, you know, what I offer is different than what other people offer. And I don't hide that. So if you're interested in coaching in general, get clear about what it is you want so that you can go determine whether these people are a good fit for you. And if people are interested in talking with me in
particular, can you just go to refactorcoaching.com or look me up. Oh, and I'm not the Brian Pulliam from Alvar, Kirk, New Mexico, who is a convicted double member. That's a different Brian. That's a different person. Okay. Good to know. I don't think he's going to be on LinkedIn if I had to Yes. Yeah. I will. Yeah. I will also say that I have done exactly what you're saying. I've worked with multiple coaches and you're exactly right that finding the right coach to help with the
things that you care about. And with the kind of like awareness. Working with you, Brian, has been the first time that I've worked with a coach that has the technical experience to speak the language that I speak. And that's that was one of the critical factors for me. People who are listening to this right now, you may have other critical factors. You may have like cultural factors that you care about, like a location. You know, they need to have lived in
in the Bay area because a big part of your career is based in that or something like that. I don't know. Those are the kinds of things to think about when you're talking to your coach. This is totally I guess like within your realm of decision making. Nobody is pushing you to work with a particular coach. It is entirely for your benefit. So be picky. Right. I think that's that's the the key factor with with picking coach. I was just very fortunate to to come across Brian.
And if you if you have similar in taste and in considerations that I have, Brian may work well for you. And dear, I say he may not. He may may may not be the right fit. Yeah. The people the people that get success with me because like a lot of people ask me that question. People who are willing to experiment to try different things to achieve their goals. I think that's a really core critical thing. You know, I've been brought up making billionaires richer on AB testing. So I believe in
AB testing and the scientific method should be applied to our own careers. And someone who wants somebody with a couple decades of tech experience in 17 years of coaching. And someone who's been in tech like the people who are looking for that. Like those are the people that tend to work really well with the coach like me. But other people want something else. Those are that that's sort of the profile of the people. Absolutely. It tend to be a good fit for me. Yep. That makes sense.
Brian, thank you so much for your time today. Yeah. Pleasure being on here. Looking forward to the next one. And thank you for listening to today's episode of developer T my interview with Brian Pulliam. Again, if you have not set up an intro call with Brian, I highly suggest that you do if you are looking for a coach to help you either in the interviewing process or maybe you're just looking to improve your chances at a promo and your current role. Whatever your reason is for
wanting a coach, Brian, maybe the right choice for you. Brian is offering 10% off for folks who book three or more sessions. You can get an intro call with him at refactorcoaching.com. Thank you again to today's sponsor Unblocked. Your developers probably already know how to write code and what they're actually missing. This context to know what code to actually write. Unblocked gives engineering teams the interest they need to get their jobs done without having to wait on or interrupt their
teammates. Get started for free at GetUnblocked.com. If you enjoyed this episode, please consider subscribing and whatever podcasting app you're currently using. And until next time, enjoy your team.