Give a S**t : That´s The Seed All The Good Things Come From with Sphira Tucker

Most tech leaders think productivity means doing more, coding more, hiring more, or stacking more tools. But what they often tend to overlook is the real blocker, the friction buried in day-to-day workflows. So, the argument is, you don't get velocity from effort, you get it by removing the friction. Today, we're unpacking what truly drives momentum and why slowing down to fix the friction might be the fastest move you make. Hey, what's going on everyone? I'm Mike Sirius and this is Meister in Tech Growth. Every week we chat with industry leaders to bring you no-fluff tips on how to grow. If you enjoy the show, please do me a favor, leave us a review and do send us your biggest growth questions at masteringtechgrowth.com. I'd love to know what you're working on and what's getting in your way. Today I'm joined by Spreeha Thakkar. Spreeha is a field CTO at Buildkite, a two-time Y Combinator founder. She built dev tools at Google and Microsoft, co-founded Aviator, a platform that helps teams like Slack and Figma ship faster. She's here to break down what really drives developer productivity and why it starts with leadership. Hey, Spreha, welcome.

Hi, welcome. Thanks. I said welcome on your own podcast.

Well, thanks for inviting me. I'm glad to be here today, right? So let me start with this, and we love to start this with every single guest as far as I remember. When I say mastering tech growth, what comes to mind?

Well, this may be, this may be a bit philosophical, so let me know if, uh, go for it, it's too, too wooey. But, um, yeah, it's ultimately, um, it's ultimately about helping others achieve things they want to do through tech or through, you know, tech, i.e., tooling, through better, you know, better tools to help humans get the things we really do want to get at the end of the day. Okay. Yeah. And growth through, you know, from a company lens just means being able to do more of your mission, the thing you set out to do.

Okay. So helping people to get what they need from tech, we are effectively saying solving their problems or whatever challenges they have, helping them to overcome that with technology.

Yeah, yeah, because ultimately if you're not, if you're not doing more of your mission, of the thing that you initially set out to do, um, which is likely to help someone in some form, um, that could be yourself, that could be, you know, the folks you're trying to serve, that could be your, your, you know, your, the market in general, or a problem, a specific problem. But yeah, if you're not, if you're not doing just more of that What are you doing?

Yeah, exactly. Whose problem are you solving? It's going to be very hard to sell your service or a product if you're not really helping anyone. So are we— so if I would rephrase this question and say we can only choose one thing which has the biggest influence for a tech company's growth, are we saying a market fit or effectively a solution to a problem fit? Is the most important one for growth?

Ah, well, grow— the bottlenecks to growth seem to change depending on the phase of the company you're in, what other bottlenecks you've solved. And so I would just look at it from a systems perspective, look at what it is that's bottlenecking your growth at the given moment. Super early on, usually it's product-market fit. Once you've figured that out, then it's usually scaling concerns and just actually getting what you know works to grow. And the way you handle scaling concerns, I mean, you can throw people at it, you can throw processes at it, you can throw tools at it. But basically, the way you scale is look at what the current biggest bottleneck is and just singularly attack that and then move on sequentially to the next one and just singularly attack that. And so it's basically just sequentially attacking the biggest bottlenecks to your highest top-level metric.

Okay.

Um, so that would be, that'd be at the scaling phase. And at some point your growth plateaus, and then it's time to figure out what, what next, and like how, what the next sort of level in the game is. Um, because what worked before probably doesn't work now. Um, and then unlocking that and going from there.

Yeah, I love you calling that one out. You definitely move through levels. It's like It's a little bit like a game, isn't it? It's like you're at the level 1. So you just mentioned all of these challenges of scale. You overcome that, overcome that, overcome these bottlenecks. And you're like, you know what? I cleared this level. It's like, like I'm ready to go to the next one. And it's next one and the next one. You are new again, right? It's like it's a next level. Like things you did in the previous level, they do apply, but they're not going to take you much farther.

Okay.

So you mentioned throwing people. Or throwing tools. Can you talk us through the situation where you think throwing people is better than actually tools and vice versa?

Ah, it depends on whether you found the right people or the right tools. Oh, here we go. Yeah, sometimes finding the right person is the solution, um, because though, and if you have access to the right person and they've got the right— if they're enabled and they've got the right context and they're good to go, Sometimes throwing people does make sense where, you know, you get the right person, you give them the right context, high enough agency, and they're able to, they will end up probably picking a tool or a process or fixing the problem in some way or questioning a constraint and then having the problem disappear on its own. But short of hiring people, we tend to go to process as a band-aid very often. And that's fine if, you know, if time is of the essence and, you know, you really just need, like, it doesn't really have to be super seamless sort of solution. Process is a fine band-aid. But tooling, often very, very good tools, the beauty of great tools is that they disappear and kick in only when necessary. So they feel like they're really enabling you and more than you're having to tolerate the tooling. I would say if you found tooling that helps you feel like you're moving faster than you were before, or you've unblocked whatever the biggest bottleneck was at the company or at your organization, whatever type of organization it is, if you found a good tool that just— that helps you move faster, use it. And that meets the constraints that you've done, absolutely use it. And then at some point when you find that, hey, you're having to tolerate the tool more than it helping you, okay, maybe it's time to reevaluate whether this is the right tool or whether perhaps you need to change the way it's being used.

Okay.

Or the context it's being used in. Yeah.

So there's a couple of things here. So we start with people and we start with right people. I feel like that's a challenge by itself. It's just like, you know, getting that good flavor to your culture, you know, like getting that high performer or getting that, you know, excellent hire. That's usually on a smaller percentage, you know, compared to, to other challenges you have in that space. People come in, they go like, okay, here's my process, you know, I'm bringing this, I maybe from another company, maybe organically creating something in this spot. And then there's tools. So when you think about the workflows, right, and you, when you think about the handoffs, and let's take a, a software development lifecycle, you're going to have developers, you're going to have someone looking at code reviews, it's going to be release cycle, there's going to be QA somewhere in the mix. Someone's going to be making releases, then someone needs to maintain all of this. There's customer support, there's some potentially defect team, or maybe it goes back to the team. So the whole workflow has a lot of handoffs, if I might say like that, right? So the question is, I personally see these handoffs have some type of friction, and sometimes they're not done well. And as well, that applies to the tools when the tools don't actually talk with each other. Integration perspective. What's your experience, Priya, when it comes to people, you know, handing over work from each other and then the tools?

That's a, it's a great question. Um, from what I understand, your question is, um, talk about processes and handoffs and junction points. Yeah, I think, I think they're very important to look at. Ideally, the minimal, the The fewer joints there are, the better in whatever process it is, because that just means it's a tighter feedback loop. And the tighter your feedback loops, the faster you can move, generally speaking. And the less context needs to be shared between people and tools and, well, the less handoff. Yeah. Would you like me to talk about that in the software engineering context? Would you like me to talk about?

Yeah, I mean, yeah, I would say, I mean, in software engineering context. So let's say we have, you know, we have the teams which develop, there's, you know, DSKA, there's a release processes. So the whole, we producing something, you know, like we coding up a value, a feature team, let's say as an example. And these handoffs, they feel just a natural software development cycle, but they do tend to sometimes break. And I feel like, you know, like, from your experience, where the breakage is, you know, and what's a common solution?

Okay, I get it. So, I would say the most common problem, the root cause of this sort of friction is when there's not a shared understanding of what the meta goal ought to be. And then you end up with optimizing for slightly different things or not caring about certain constraints. Which is why having context is important in general. When you're talking about, you know, ideally, when you're talking about software engineering, ideally, you'll have— the loop is very quick. Your engineer who fully understands what, what needs to be built and more importantly why, so that they can make, they can make their micro decisions. And then you've got great, a very quick feedback loop between it being built and test, tested, and then just shipped as quickly as possible. If you've got the more, if you've got a separate QA team, a separate team that, that figures out, like a PM team that needs to figure out what needs to be built and why it needs to be built. Before that, you've got a separate UX researcher team. And then maybe in between, for the tooling itself, you've got a separate, you know, like a deploy— like a release manager type team. The more of these teams and processes you've got, the more points of friction you've got. And so the more important it becomes to ensure that the entire ship is sailing, the entire crew is rowing in the same direction. And the way you do that is by ensuring that the higher level objective is crystal clear and ideally measurable. So if you've got one, if you've got one metric to unify the both sides of the joint, the better. If you've got one metric to unify, you know, three parts of the pipeline, the better. If you've got one metric to unify like the whole company, the better. And so if you find friction between, I don't know, say the engineering team and the QA team, and maybe that's your current biggest bottleneck, that it's taking, the handoff is taking too long, or there seems to be too much back and forth, like too much ping pong going on between sides. Those are usually signs that, like, that there's not enough shared context. And the way you, the way you resolve shared context is you, you anchor both teams to a meta-metric, to something that, like, assigns, aligns both of them. Things like shipping speed or iteration speed or, or, um, you know, the DORA metrics, right? Shipping speed without, um, taking into account how many, um, how many rollbacks you need to do, that sort of thing. But basically come up with a composite metric that— metric or a, um, uh, ideally something measurable. So ideally come up with a composite metric. I was going to say come up with a goal, but you know, if you're, if you're scaling, sometimes metrics really do help. Um, so come up with a composite metric that encapsulates both, um, both sides of the joint, so to speak. And then let the teams have at it and ensure that they get why, the context, why, the context of why this is important. Ideally, this all flows from your top-level business goal of trying to just, you know, win. And the way you win is being very clear on what your mission is and then being very clear on what the biggest bottleneck, the current biggest bottlenecks are to achieving said mission. And so ideally, your metrics flow from there. And then every person on the team knows what their role is in fixing said bottleneck at the moment.

I love that. That's excellent advice. I love the compositive goal or KPI or OKR or whatever potentially new tactics people use, but you want to take a left and the right side in their joint and you want to create a composite metric for both of them to sort of go after, which means they will be a lot more aligned And they will have a lot more shared context because it's the same metric for both. That's excellent.

Um, the biggest composite metric of them all is the rate at which you're fulfilling your mission. You know, like, how hard are you— are you as a company, how hard are you going? Like, are you, are you capturing a lot of market share? Or like, meaning, like, are you serving more people? Are you, do you building your product better? Are you shipping faster? Whatever your, your mission is, like, that's the ultimate composite metric is how effectively you're doing what you set out to do as an organization, in life, whatever, you know. Yeah.

Why, from your point of view, Priya, why leadership tend to sort of miss these friction points? It's like, maybe it's just my experience, but when I go through businesses and team, I see a lot more weight in these higher-level metrics like, uh, you know, market share, sales, leads, and things like that. And a lot less, um, a lot less view in the— in those deeper metrics, which is things like, you know, how quickly we closing MRRs, how quickly or how much we sending, um, to production. And, you know, these dollar metrics, they do come, but I feel like they come with maturity. At some point, you know, you get that maturity phase where you get like a good head of engineering or CTO and they come in, they go like, you know what, my function requires as well to have some data, so I'll put in these. But when startups sort of kick off, it's never like, you know, they never look at sort of like production line, which is effectively engineering, as in you're building software. They always look at that, you know, higher line. It's like, do you have any views on that? Like, why, why that, you know, naturally is not the beginning?

Yeah, I mean, it makes sense that it's naturally not the beginning because the first thing you'd say, like the most obvious signs of how effectively you're achieving your goals are just directly measuring how effectively you're achieving your goals. And if those goals are getting the rate of customers signing up or your ARR, MRR, whatever, great. Like that's a great thing to look at. I think that there is real skill though in trying to figure out what the— in trying to be able to niche down to exactly the right bottleneck or the highest leverage bottleneck that you can unblock to then accelerate your broader goal. So, if you're at an organization that only looks at top-level, like very business-level metrics, And they're unaware that engineering is actually a lever, a very effective lever to increasing said ARR or MRR or whatever. And you are aware that it could be actually a very, working on tooling could potentially really help move the needle on your ARR, MRR, whatever metric you're tracking. Either by increasing, the rate at which you ship features, or if you're selling technical tooling, or if you're not at a company that sells digital stuff, enabling, then building internal tooling to enable the machine to move just a lot faster, i.e., building tooling for support or for whoever else, like just levering up the organization in some way. If you realize that, hey, this is a lever that could potentially move the needle, make that case. Make the case to leadership and speak in the terms that they care about. And if you're a leader, ideally, you look at the thing that you care about and also then look at the various inputs to that metric and look at which ones have the highest leverage to move your top line metric. And if those things end up being processes or tooling, great, focus on those. And if they aren't, then focus on whatever. If it's a culture thing, turns out like the highest, the biggest thing you can do is actually, I don't know, make a push for a slightly different culture as a leader. Great, then focus on that.

Okay.

But I do think that it is important to take a minute at least once a week to just see whether you're at every level of the organization, whether you're working on the the thing that moves the needle the most on whatever it is that you're trying to achieve, because that's just how you get efficient.

All right. Let's zoom into metrics a little bit. I mean, we all talk about you have to be data-driven and, and we know how important it is to capture metrics and to actually make your decisions on that. Is there a Is there a metric which gives a full sense of progress from your perspective? Like, you know, like people tend to just capture stuff, but like from your point of view, like, do you hear metrics where people are capturing things and you just go like, you know what, like that's not— like that's just a false sense of progress?

Ah, false sense of progress. Oh, there's so many fake metrics out there.

There you go.

Well, there's— again, it depends on the context, as always. But a very common— there are a bunch of ones where the metric sort of gets, uh, it gets sort of corrupted in a sense. Um, code coverage is a very common one, um, where you start looking at, at just how, uh— I mean, it's a great proxy for lots of other things But it's very easy to just fall for the trap of, oh, we've got high code coverage. Code coverage meaning we've got enough tests that cover— that run on our codebase. So, it's very easy to fall into the trap of, oh, yeah, we've got— we've hit the threshold of code coverage we wanted to. But not actually look at what the tests are testing. So you could write terrible tests. You could write very obvious things that don't actually capture edge cases or actually put the product through its paces or look at the system through whatever— through robustness lenses. But you can still write tests. You can still have the metric go up for the sake of the metric going up. And this is exactly where it's important to look at look at the higher-level composite metric your metric is feeding into. I think as long as you've got the bigger North Star, at least the one level up North Star, and use that as the guiding light, you'll know that you're not over-indexing on the wrong metric. The lower-level metric isn't being corrupted because the higher-level metric is still moving forward. Okay. Higher-level metric stops moving forward, but your lower-level metric is, perhaps it's time to look into other levers and stop optimizing for whatever it is that your lower-level metric is optimizing for.

What metric do you personally love when it comes to team performance?

Oh, just ship rate. Like the, you know, the how fast— well, the DORA folks would call it deployment frequency, but really ultimately, I really like the throughput, basically the composite of like, you know, the lead time for changes, deployment frequency, the change failure rate, you know, what was the other one, the time to restore, all of that. But basically, like engineering velocity in general, the meta metric for me is just how fast we can ship stuff. Because if you can ship stuff, ship high quality stuff very fast, you're moving at the speed of thought, or at least at the speed of, at the speed of business needs. And the more you can move at the speed of, at the speed of business needs, the, the more likely you are to, um, to react to customers' needs faster, um, to serve more of the market if, uh, or to scale faster, whatever. Like, basically, the better you're using engineering as a lever in the organization in general.

Usually speed comes at a cost of quality. And you said high quality at high speed. So that's, I mean, that's great if you can have that, right? So from your point of view, does quality do suffer if you're getting under the pressure from, you know, from effectively business where it goes like, look, we do have that date. We do need to hit it. There's marketing campaigns aligned. There's things are happening. Like we need to ship that. That out, just like make it happen. So that usually goes like, okay, well, let's jump over some, some best practices and let's just make it happen, right? So if you're in this type of situation, I mean, clearly some of your metrics will go down, but let's say you have a quality bar. How do you sort of like measure quality bar when it comes to, you know, the code and the features you ship? And then if you compromise it, it's like, um, what comes out of that?

Yeah, yeah, no, that's a great question. Um, and most questions of these flavors, you know, oh, when you've got this thing and you've— you need to make a trade-off with this other thing, uh, it usually means there's an implicit constraint within which you're working. Um, in this case, the constraint is usually the toolset you've got, or, uh, you know, the, the capital you've got, or whatever. It's usually like, if all of that is stagnant and you've maxed out, you know, your current current processes and your current, you know, your current resources, um, some— something is going to give, you know, like if, um, something is going to give meaning, uh, if you don't relax one of the constraints that you're existing— that your system has, including in the system— my system, I basically mean at this point the argument that you're engineering org as a system, um, if you don't relax one of those constraints, something is going to have to suffer. So you either figure out, um, your prioritization where you, where you realize that, you know, you have to cut something so that it fits into the, the, uh, the constraints your system is working in, or relax a constraint. And that's where I think a lot of companies forget that you actually do have levers that you might have not thought about before. Things like tooling. The smartest companies, um, will usually invest at least a little bit, like, you know, at least have a small, like, developer platform team or a developer experience team or a tooling team of some sort, a leverage engineering team of some sort whose job is to figure out leverage. Basically, how do you, how do you get people to do more with the existing resources they've got? And the way to do that is usually through tools, through like actively looking at processes, just make, just removing friction as a job and ensuring that you know, you increase productivity in the very economic sense of the word. You know, like given one unit of labor, how much can you produce? Ideally, if you actually take that very seriously as a dev platform team, okay, given one engineer's time, how much can they produce? Turns out if you take that problem very, very seriously, you can create a killer engineering team with a small number of people. That can produce a lot, can produce high-quality stuff that can ship very fast because you've got folks thinking about the platform. And because you've got folks who are thinking about the shape of the constraints, not just the shape of the things inside, not just the shape of the resources that you've got associated with it. And the more you can relax these constraints, ideally through tooling, and these days, my goodness, there's just so many types of tools available. If you're very smart at looking at your system, looking at where, like I was talking about, like I was saying before, look at where the bottlenecks are and then just see how you can lever up the organization in general. Like, oh, turns out, you know, code review takes forever or build times take forever or whatever. And there is someone in the company, even if it's just 1 or 2 people at the company who are looking at it and treating that as their problem. As long as you spend a little bit of effort there, you're likely to move at a much faster pace. You're less likely to run into these trade-offy type questions because you've got this other lever that you can pull, which is the tooling itself. And so yeah, maybe you don't have to sacrifice quality for speed, but only if you invest in the right tooling that enables you to do so.

Hey, guys.

Yeah.

Okay, so we can relax constraints. I love how you put it, relax constraints. So we say, we're saying, hey, you know, we're looking at quality, uh, here's our quality bar, 90% coverage, uh, all the good things happening. So we're gonna relax this a little bit to gain more speed. Maybe we'll jump to like 70 or whatever that means.

Relax some constraint, either relax the quality constraint, relax the speed constraint, or relax the tooling constraint. Yeah, what I mean is like Perhaps you can— I meant constraint in a very pure sense of the word, not just a literal constraint. What I meant is in a very mathematical sense of the word, meaning this is a thing you need to take into account while solving your problem. And here, if the problem is, oh, we need to ship this thing, we need to ship something that's super high quality and really fast. The constraints of that system are usually, oh, with this many people, with these sets of tools, with whatever. Perhaps you might want to question those constraints as well. Perhaps there are tools that help you ship higher quality stuff faster. Usually in the software engineering world, it's, you know, there's— you can, you can look at modern build systems, modern security system, modern this and on that. There's, there's all sorts of enablement now, like Yeah, like look to see what— why does it take so long for me to ship my— ship a feature today? Oh, it turns out it's because there's a lot of ping pong going on between engineering and product once a feature is built. That means we should probably invest a little bit into that initial context being passed on from product to engineering. Or it turns out, like, the reason that our features actually take a while to ship is because our build times take forever, or we've just got so many tests or that, you know, when something breaks, it's just a very fragile system. And so we need to— and that's why engineers take a while to figure that out. Perhaps there's ways to parallelize testing. Anyway, just figure out why is it that it takes a while to ship. Takes a while to ship whatever your system is. Like just zoom in as deeply as possible as you can to the thing that's that's, that's most blocking your speed of shipping. Um, and then question the constraints, really question the constraints, because if there are tools that— if you need to ship right now, great, ship it. Um, but if this is something you're going to have to do regularly, it is worth investing in, in a small team or at least one person to look at, um, how can we, how can we have this not be a pro— How can we have this not be a trade-off we are forced to make in the future? Like, is there like, all right, Spreeha, you're on the DevEx team now. You figure out how we can not have to make the trade-off between quality and speed.

Can we walk through a real example together? Let's just brainstorm together. So, we have a workflow, software development lifecycle. Effectively, it has a step in a, in an old cycle which is, uh, which is effectively MRs or pull requests. Someone effectively, you know, has a branch, they work on a feature, they want to merge that in your master. So someone owns or gatekeeps the quality which goes into master. Makes perfect sense, right? You want to protect the quality, and maybe that's the choice you made instead of something like, uh, static code analysis and code coverage and stuff like that. You want to actually look at the code, right? And someone, team lead, tech leads, you know, whatever, the most capable person within the team looks at it, right? So it's one person, right? And then let's say you have like 6 developers sending code to it, right? And what you usually get at the end of a sprint when everyone's, you know, rushing to basically close the stories and get, you know, committed story points, actually get that done Suddenly, boom, there's a bottleneck, right? It's one person looking at the code reviews and stuff like that.

So you have it right there. That's your bottleneck. So if the question is, how do we speed this person? So you've got a few options. Either distribute out the bottleneck so that that one person isn't the— like, either get those checks, the checks that that one person is doing, either get them checked more parallelly, earlier in the process, later in the process, or get more of them. More of them, meaning get more of that one person so that you can speed things up, or lever up that one person so that they can produce a lot of— they can— their throughput increases, meaning invest in whatever tooling. Like, why does it take this one person so long? Oh, it's probably because they spend most of their time just getting context on the code. Perhaps invest in some context tooling. Or, oh, it's the— it's because, you know, they, um, the specific test they run itself needs to be run sequentially and takes a while. Great, look at how you can speed up that sequential thing. Maybe you can skip a few steps in there, you can parallelize a few things within there. But basically, if the constraint is a single person, someone who needs to review or someone who needs to gatekeep, ideally question the constraint. Does this person— does it have to be one person and does it have to be gatekept? Really sometimes questioning the gatekeeping itself is worth it if it's truly a constraint. Sometimes maybe you don't need to check it. Maybe just deploy stuff and then check it after or check it in a parallelized way or whatever. Invest in systems that can catch things early on, like shift left, do all of that. Basically, if you know that the bottleneck is this one person, you've already solved half the problem because you've identified the bottleneck. Now it's just a matter of, okay, we know this is the bottleneck. How do we solve bottleneck? Put all your brains on it. You could even lever up that person, pressing the need for the bottleneck itself. Yeah, it's just basically go and solve the problem there.

So first, of course, yeah, you identify the bottleneck and then you're like, okay, what options do we have to actually, you know, resolve that? And then you effectively make the adjustments. I love what you said about effectively relax on the constraint on protecting that quality, allow a working code, you go in because, you know, hopefully you have QA in the process. So it goes in, maybe it doesn't go in the quality you would love to, so you're sort of accumulating some, some code-level technical debt. What was that?

Either, either that, or you shift the quality checks left so that, like, meaning, yeah, the devs check it more. Like, basically you can either push it further down, push it, move the check in a different— to a different part of the system that isn't as constrained by one person.

Okay, that's excellent. That gave me some ideas, and that's a real case I have right now. So thanks for that. Yeah, so you, you re-articulated some of the ideas I had in my head, so that's great one. Uh, so another thing which I want to run by you is, is an actual continuous integration pipelines, right? So they tend to be quite simple, you know, smaller teams, smaller businesses, like, hey, You know, we have some Jenkins together, has a couple of steps, you know, here's a build, here's a ship, boom, done. I don't understand what's the big deal. And then you go into big organizations, you know, enterprises, many, many teams, hundreds of developers, and the complexity of these pipelines, they bulk up, you know, you have like 12, 15 steps, and it's from static code analysis to build tools to backups and security checks and all shebang, right? And they become quite complex by general, and then you start releasing something and they fail, and then you just end up looking at fixing the pipelines and why they failed instead of actually doing development work. So from your perspective, is like, do you have like a dedicated pipeline teams, or like do you shift left on, you know, do you give ownership someone within the team to own pipelines, or do you somehow not even walk in that complexity? Maybe you somehow I don't know, split it? Like, what's your take in general to battle that pipeline complexity which comes when you scale up the business and the teams?

Yeah, there's a few ways. Well, first, yes, I would put at least one really smart, intelligent person on the problem if it is in fact affecting everyone, because this is a high-leverage thing to solve. Like, if all your engineers for every pull request or every code change are running into this issue, it is absolutely a high-leverage problem to solve. So I would put, I would put an intelligent person on there. If I were put on this, I would then look at, look at the, look at the current system. And basically you've got a few, um, at Buildkite we think about it this way too, um, you've got a few different, again, levers at your disposal to speed up a complex, to speed up an otherwise slow system. And this is general, these concepts come up a lot in engineering in general. And so, uh, you'll find that these rhyme with many other, many other engineering problems. But basically you've got, you You can parallelize things if you want to speed things up. You can reuse things, things that you've worked that you've previously done, or cached things. And you can ideally skip things, skip things that are unnecessary at a given point. And if you've got the tooling to be able to skip, to be able to parallelize, to be able to cache and reuse, you've already, uh, you can then speed up your, um, your sequentially slow system quite a lot if speed is the thing. If complexity is the thing, it might be worth it. It's— I genuinely do believe that simplicity is worth investing in. Um, try and, try and reduce down the complexity of the pipeline. Like, why does it take, uh, all these different steps? Okay, maybe Maybe the code linter and what was the other step you said? Maybe two of the steps can be run at the same time and they don't actually depend on each other. Fine, parallelize them. Maybe then there is a gate in which something like the artifact needs to be built and that absolutely needs to happen in a sequential form before anything else needs to be done. Great, just throw a lot of compute at it and make sure that that part is fast. But yeah, I would basically put in a— because this is such a high leverage problem, like it's such a— it's a problem worth solving because it affects so many engineers on every code change. I would absolutely invest at least one person in it. And if I were that person, I would look at the pipelines and see what can be parallelized, what can be reused and cached, and what can be skipped. And obviously with Buildkite, we give you all the tools to do that. Plug. But even otherwise, like whatever your system is, You've got a few levers you can pull on, pull on them.

Okay, I love that. So, let's say we have 10 steps. So, first thing we do, we're just going to question all these steps. Do they have to run when you're making a production release? Like, are they critical? If we remove the step, how faster can we become?

Because ideally, like, the fastest step is a step that never has had to run. Yeah, exactly. Question the thing. Yeah.

I love— I said that a couple of times on the podcast, so people listening, they will be like, Mike, stop saying the same thing. But I, I took this from Elon Musk, right? So he talked about automation in general. And basically his first point was like, people, if you basically don't say— if you don't react things back very often, that means you're not removing enough. It's basically just a flip of the mindset, because when people think about automation and pipelines, they, they do tend to just over-add more things. Like, oh, what if, what if this happens? What— oh, okay, what if we need to, you know, what-ifs. And, and he basically goes like, no, it's actually be very aggressive with taking things out, and you need to be occasionally adding things in when the demand appears. And if you don't add things in occasionally, it means you're not removing enough. And I said that probably like, like 10 times across different episodes, but it's such a mental shift. Like, it's such an unconventional way of thinking that it really goes against like, uh, just like how mind works. But I love that as well when it comes to pipelines.

It's like, yeah, exactly, because the fastest, like, the fastest thing you can do is not do the thing. It's not, don't do the thing. So question if it really needs to be done.

I love that.

But for that, you often need good tooling to be able to do that, really. Like modern build systems that are graph-based, those are very good tools to have because knowing a dependency graph, for instance, can power the logic around what can be parallelized, what can be reused, what can be skipped. So just having some knowledge of, again, of what the real constraints are helps you in making these decisions of, oh, do I really need to run this thing? Do I not? Ideally, you know, like modern— like Bazel and whatnot. A lot of these modern build systems let you skip things and let you reuse things, let you parallelize stuff. Yeah. Buildkite, we work very well with a lot of these systems. But this is our— our core principles are also ensuring that our users have all these levers to pull on. Like our north star is getting developers actionable feedback as fast as possible. And so the time to an actionable insight for the end developer is what we try and really enable our customers to do. And that's how we, you know, that's why— that's how we offer features around parallelization and skipping and reusing and whatnot. Skipping especially, it's very important to to know when, uh, to know general properties of your system so that you know when you don't have to run a thing.

So when we say skipping, uh, we're saying you have multiple steps in the pipeline, but then when you're doing merge in an ad hoc way, you can just go like, hey, I don't care about step 7, 5, and 6, just, just go in, right?

Exactly. Like, if you've got a set of, um, if you've got a code change that comes in Your overall test suite is, I don't know, like 8,000 tests or whatever. Maybe this code change doesn't need to run all 8,000 of them. Maybe it just affects a subset of them. Pick out that subset. The way you'd know that is usually through a build graph. Pick out that small subset. Once you know that, okay, I just need to run these 800 steps instead of the 8,000 steps. Great. Now you know these 800 steps need to run. Do all of them need to be run sequentially? Maybe not. A bunch of them can be parallelized. Great, let's parallelize them. You've already— you've now— you've reduced the problem from 8,000 to 800. Now for the ones that do need to run, great, you parallelize them. While they're being parallelized, perhaps there's work they can reuse from, from previous runs. Um, some of them maybe can reuse work, maybe some of them can't. Great, for those that can reuse those, that'll go way faster, and then you can bin it with other steps. So anyway, um So we then give—

so we're basically saying the whole pipeline run just gets dramatically decreased, meaning that you can just ship more.

Yeah, exactly. And that's the thing, like, that's how we think of product internally, um, at Buildkite, that like if we give you all these levers to be able to skip stuff, parallelize stuff, cache and reuse stuff, you know, like optimize things as much as you— as much as hardcore as you want Then when you as a customer come in, you can choose where you want to start, and we give you all the tooling to help you with whatever approach you initially want to take. And that may be initially, that may just be throw more compute at it. I don't want to sit and figure out which tests need to run. I don't want to do all that. Let's just run all of them, but just let's run them faster. Great, Buildkang can help you with that. It could be, well, we've maxed out the compute. That's a constraint now. We do need to figure out what to skip. Great, we can help you with that. It could be, oh, we need to start reusing caches and we need to be able to like— we can't entirely skip it, but you know, we want to be able to— we can reuse some past work. Great, we can help you with that.

Okay.

Um, definitely, yeah, the time to feedback is what we can—

that time to feedback. I mean, you mentioned as well actionable insights, so I, I took a note of that. Like, what's like— what is that? Like, give us an example of what is an actionable insight for a developer from a pipeline?

Yeah, an actionable insight. So both of those words are important. And in time to actionable insight, that entire phrase is important. Actionable, because we care about not just dumping you with a bunch of logs, where then you have to— you've got a bunch of information. But there's a lot of work you need to do to be able to then figure out what is the action I can to take. We give you tooling to pull out just the right needle from the haystack so that your developer at the end of the day is like, all right, great, this is the problem. And the way we do that is, you know, each of our steps can have an annotation. I mean, if for those watching, if you're interested in how BuildKite specifically does that, I'm more than happy to chat. Yeah, you can reach out. But we basically, in a developer CI/CD loop, for instance, The actionable insight is, A, did your build pass or not? If it's passed, great, you don't have to do anything. It's not really actionable. The actionable part of it is that you don't have to worry about this anymore. But if it hasn't passed, the actionable part is basically helping you hone into what the real problem was so that you can then take action on it and solve it as quickly as possible.

So, effectively, it's not just raw logs of systems running. It's getting to convert it to something, "Hey, if you do ABC, you'll be just faster or better," or whatever is actionable.

And I do, like, these days with AI tools, you can even try to auto-remediate yourself. Like, you can just try and offer a fix and try to fix things yourself. Anyway, yeah, there's a lot of cool things you can do these days. These days.

That's great. I mean, with the advance of AI as well, helping with just reading logs and just giving an actual actionable insights, that's— I feel like systems—

well, not just giving you actually, right? You can even take it a step further, taking that action on your behalf as well.

Yeah, yeah.

And then, you know, there's a lot of things you could do. At some point you'll want, you'll want the human in the loop.

Yeah, it's just gonna be click a button, it's done for you, problem solved, go home, not need it. Maybe, maybe someday. So I want to ask this, Priya. It's, um, I tend to see people normalize pain points. So we talked about friction and, and, and the whole, you know, argument of the episode is that do not ignore that because the velocity is not by putting more effort. It's actually by, hey, let's look at the friction. Let's look at the bottlenecks. Let's understand the root cause of it and let's just go solve it. And that's where you actually get that efficiency. But I do see teams, they just normalize pain points. They basically go like, look, we have so much to do, as in roadmap, right? We need to release and we need just to build and, you know, and people expecting this pressure and being asked and deadlines and whatnot. So we always just sort of building something new, right? And then we know there's a pain point, like we know this is annoying, you know, copy-paste or whatever. But we still do it because there's no time to actually address these, you know, these friction points. It's like, from your point of view, do you see that? And as well, if you did in your career, so you see that, like, what's like, you know, like, what hope can we give to our listeners who are actually in situations like that?

Yeah, I've thought about this a bit. And I think really the scarcest resource we really do have is people caring at the end of the day. Like, just pardon my French, but people giving a shit, you know? Like, yep, yeah. Um, and that is very important to protect at the end of the day because that's, that's the seed from which all the good things come from. Um, the more The more you kind of chip away at that, um, giving a shit, the less effective your organization is ultimately going to be, um, and, and the less, the less joy you get from life in general. But, you know, yeah, um, my extremist view on that is that neutral days are actually bad days, um, meaning like you're either It is more binary than you think. Neutral days over time just sort of add up to just slowly fizzling out of the giving of the shits, you know? And so you do need momentum and you do need progress to feed that precious seed, which is people giving a shit. Yeah. And the more you can do that, the better your organization is going to be. And if you think, oh, like, it's, you know, it's fine and it won't really hurt in the long run, there's enough tolerance usually for a little bit, but beyond a certain point, neutral days are bad days. So it's very easy to just get complacent. But the less you give a shit, the more you give a shit as an organization, the less you're actually going to be able to achieve in the market. And basically the less you're going to be able to win at the end of the day. And what is win? Win is win by whatever metric you want, you know? And so—

That's excellent.

Yeah. If your developers or your— well, I say developers because that's the audience I care about, but in your organization, whatever Basically, if your workforce feels like there's no point in giving a shit, that's actually a very insidious— it's a very insidious cancer that sets in, which ultimately just leads to rot and death in the long, long run. So protect that, protect that at all costs. And if you see that it's it's fizzling out, try and inject some enthusiasm back in. Try and inject some momentum. And momentum really does feed that, feed that precious giving of, precious caring, which is ultimately where all values is created from. But yeah, invest in, invest in the tools, invest in making people feel like there is progress and there's momentum. Invest in progress because that's how That's how you feed the, the soul of your, of your organization.

That's excellent, Priya. You just basically nailed this. It's almost like a gospel you just put in there. Uh, I, I took this quote, give a shit. That's the seed where all the good things come from. I'm gonna make this a title of your episode.

Give a shit. Yeah, I mean, because if you don't, like, what are you doing? I mean, you've got one— you as an individual have one precious life. Give a shit. Go get good at it. You as an organization, you've got one chance to do the thing that you're set out to do, and there's a reason you started it, or there's a reason, you know, you joined it. Like, remember that and try and move the needle on things.

Okay, so we're basically saying do not normalize the pain points, effectively take initiative to prioritize them. Yes, we understand that you need to ship the product and you have the deadlines and you need to compete and everything, but in the long run— and you are in the long run because you are a business, you're not like 1 or 2 years, I mean, you're effectively constructing a business— you'll be here for quite some time if you're successful. So we're saying put more emphasis on the problems people are having, and especially if they're giving a shit and they're sharing these pain points, allow them to sort of deal with their own frictions. Do not normalize them in exchange to get, you know, shipping everything under that, uh, pain point or with these frictions. Yeah, I love that. I mean, I think more leadership should listen to you.

You'll stay around as an organization. That is how you stay around. It's by people caring ultimately. And so you want to make sure— and people care usually when there's momentum. And so you want to make sure you remove barriers to momentum, whatever those may be. Yeah, yeah.

I love that.

If you're not a successful company yet, this is how you will be successful. If you are a successful company, this is how you will stay successful. Ultimately, it all comes down to whether people care.

Whether people care. Yeah, I never seen people who don't give a shit, they actually do great job. Like, I think it's just one of the realities of life. If that people don't care, it's just so unlikely that they will, you know, they will push the needle, they will be there to, uh, you know, play the game, to exchange time for money.

It's the only way they'll actually try hard, and trying hard feels so good, you know, like just in life, because yeah, it's such an experience.

So I love that. All right, let's, let's do some rapid questions for you. So 30-60 seconds questions, straight to the point. Let's see, what's something you've seen slow a team down that no one thought was a problem?

Agency. Or yeah, um, yeah, if you need the one-word answer, it would be like the slow sap of agency within, within Give us more context.

Like what's agency? What do you mean?

What is agency? Yeah. Yeah. Oh, it's something that I can't solve by myself or I can't do anything about. Like the slow death of an organization is when people increasingly start feeling like, oh, it's not my problem to solve or I don't really care if it's solved or not. And that, yeah. Okay.

I see what you mean.

Yeah.

Is that not what we just discussed? Is it just people not giving shit?

Yeah, yeah, basically, isn't it?

Yeah.

Okay.

When you walk into a new team, what's the first signal you look for to spot hidden friction?

Ah, the ping pong. Ping pong means— sorry, ping pong tables. No, I'm kidding. Yeah, no, backflow of whatever it is that they're trying to ship.

I use literally the same term, ping pong, when I, when I describe team just, you know, bouncing the problem from one to another. Hey, what's up? I'm not sure, you know, back to another team. Or you, oh, we just checked it, it's back to you. Oh no, we just checked, it's back to you. It's like, yeah, I, I use the same term, ping pong. You get that a lot, right? Right. Is there a metric you once believed in but now think does more harm than good?

Yeah, well, then there's so many contexts, like there's the engineering stuff, there's business stuff, but yeah.

Just anywhere your mind change, you know, any metric, could be engineering, could be business, you know, could be how quick you, you know, you cook a steak, or it's like, it's up to you, but any metric where you were like, I really believe in that, and then you sort of deployed and sometime past you were like, Nah, it's not good.

Yeah, it's you. It's usually not so much that I lose faith in the metric itself, it's usually that I remember that, that, that the bigger thing comes into view more often. Then you're like, oh, wait a minute, this wasn't the only thing I was trying to optimize for, you know. Like, even when for health and that sort of thing, like, uh, the more holistic you get, the, the better you are at tweaking the, um, tweaking the system so not no one thing goes sets the entire system out of whack. But yeah, I mean, in the developer productivity world is chock-full of these metrics. Like, there's— there are famous stories of back in the day how, um, um, you know, I believe it was Microsoft, uh, that, that judged developers on lines of code shipped. Yeah. And, uh, and that obviously became very corrupted. You know, it's a very gameable system. Um, there's— there are so many of these. Like, here, like, even Any of the, any of the common metrics we measure can be taken to an extreme or can be, can be just measured— the, the spirit of the metric can die if, uh, it's like the AI pay-per-click problem, you know, if the broader context is not taken into account. Um, so things like even deployment frequency can totally be gamed if all you're— if you're just deploying a whole bunch of stuff but turns out you're not actually moving the needle on helping your customers really solve pain points that they want. Or sometimes, you know, we think about this as an organization internally. You may feel like you're moving a lot. My current CEO was talking about how sometimes it feels like organizations are like a car that's upside down. And you've put the pedal to the metal and the wheels are spinning and the odometer says you're going at like, you know, 100 miles an hour. Car, but you're not actually going anywhere because the car is upside down. Um, and so yeah, like optimizing for, for a metric for the sake of optimizing it might end you—

yeah, this is such a nice analogy, Priya. I'm gonna use that. So you have a car, right? And you're hitting a gas pedal, so you like, oh, we're going whatever miles per hour, but cars upside down, so you're just at the same spot. I love that. I'm gonna use that.

That's nice.

I love that.

So, um, yeah, and so you might be moving a metric, but just make sure that, that, that it ultimately feeds— like, you're taking it in the context of, of why it matters in the first place.

Yeah, I do agree metrics can be, can be played in big organizations. People, I don't know why, but like, you often get this default behavior where like, okay, you're giving me OKR, the very first thing I'm thinking, not how to achieve it, but how to game it.

And I think this is a great— honestly, as a leader, it's a great— it's a law of nature that given, given, especially if you've got human beings that are good at like that, are incentivized for a given metric, that metric will be optimized. So metric design is just as like incentive design is just as important while figuring out your organization.

I do love it. One thing which I learned from my leadership back in the day is to balance metrics. So you basically, if you put one metric in, you have to put another one which balances that one in the opposite direction.

It's more composite.

Yeah, yeah, exactly. So you can't just put one in, 'cause people will be like, how can I game that? Right, so we go—

Or just put the higher level metric in, you know? Like put in a company ARR component in there ultimately if you care about it or whatever, yeah.

All right, so we've got one question from audience, so I'll put it on the screen. What are the most overlooked signs of workflow friction that leaders miss until it's too late?

Yeah, it's this ping-pong stuff. But like I said, the real, the most insidious overlooked sign is the slow sap of enthusiasm, really, within the company. It's momentum. The only way to protect enthusiasm is through momentum. And I sort of take a take an extremist stance on this. Like I said, I think it's not that you have good and neutral and bad days. If you're not feeling momentum, you're actively dying. It's just the beginning of the slow death. So yeah, the lack of momentum is, I think—

And we define the lack of momentum, Priya, like people just feeling and looking like in a funeral? Like, what's a lack of momentum?

It's just— no, it's actually— it's actual output. It's actually, it's things actually moving, you know. Turns out it's very difficult to feel low if you've actually shipped things, because change begets change, you know. Like you ship things and then things react to that and you will have to react to it. And so, yeah.

How do you measure momentum? Like, do you have a measurement? Like, is it just like, hey guys, you know, Are we doing good or is it like a—

yeah, for different themes it's different, but for, for engineering specifically, it's, um, it's just how fast they've shipped things and how often they have to roll things back. Um, it's the, it's the, you know, it's the DORA stuff. It's like how long they ship things, like the lead time to change, how fast they ship things, how fast, how much they've had to roll things back. Um, and ultimately, like, whether, like, if it's a dev platform, um, type org like a lever-type organization, it's measuring through success of the engineering organization that they serve.

Yeah.

You know, so how, how much has our engineering team shipped? Okay, where, what are the bottlenecks there? Like, if, if that, if that overall number has not increased, then you as a Dev Platform team have not either identified the right problem or sufficiently solved the problem that you have identified. If it's a product team, it's figuring out, you know, the, the momentum there is again shipping product. If it's a, I don't know, if it's a a support team, the momentum there is scaling up support and like, you know, ensuring that like it can be response times. It can be ideally the North Star for support is just not having, it's just reduction in the need for support, you know, like top of funnel reduction. If it's a marketing team, it's, you know, the leads you're getting in, the qualified marketing qualified MQLs, whatever. There's all sorts of things. There's just brand recognition. And depending on the team you're on, momentum looks different. But, um, yeah, if it's, if it's too long without momentum on any given team, you can rest assured that that team is in need of, uh, in need of saving. Indeed, of saving the seed that we were talking about of giving a shit needs to be saved.

The seed of giving a shit. I don't know why, but I love that. I'm gonna put it somewhere in the title or thumbnail or something like that. That's happening. So what's the thing high-performing teams do differently when no one's watching?

They invest in leverage.

Yeah, give us more leverage.

Yeah. Yeah. If you've got downtime, invest it in leverage, meaning tooling or ideally tooling that can, that helps you do more with what you already currently have. Because that'll help you to just move faster and just win as a company, you know. And the beauty of the current day and age is that the world of tooling is changing so much. Like AI has just opened up a whole new set of tools. That mean leverage is worth investing in. I would highly, highly encourage every organization to just look into leverage as a function. How can we make— how can we get our existing team to produce just way more? And how can we just win at our mission way faster than we could before? Because guess what? One constraint has just been loosened up. There's actually a lot of constraints have just been loosened up now. This is a very fertile time to rethink tooling and leverage. And when I say tooling, I mean tools that give you leverage.

I love you. I mean, you mentioned leverage at least a couple of times during the episode. So it's very clearly something you strongly believe in. And that just gave me an idea. I need to do an episode on leverage for businesses because it is Yeah, it is very, very real. Like, people who understand—

yeah, it's, it's, it's one of the biggest drivers of value. Um, doing more with the same amount or less, yeah, is incredible because it means you can ideally just do a lot more with more, you know.

Yeah, this is the— and it multiplies as well exponentially. Like, if you create a good part of leverage within your workflows or whatever is your value stream which you provide as a team or as a business you have 1 employee and 10 employees, that leverage actually multiplies. Maybe not like 10 times, but it does multiply the more you have, which means—

which just means you can win. You can serve your customers faster, they're happier. You can just, you know, dominate faster and just do better.

Yeah, definitely.

Right.

What's one thing leaders should stop doing if they want their teams to move faster?

Remove agency, basically. Do things that, um, Whatever it is, one thing that leaders should stop doing, yeah, would basically be the category of things would be things that remove, that chip away at that core feeling of, hey, I'm here to do some, to move the needle on something. Those, I mean, that's such a team-dependent question. But yeah, at its core, it's just things, whatever it is currently that you're doing or that your team is doing, um, that is stalling momentum, um, is what you should absolutely stop.

Yeah.

And if that means investing a little bit of time in fixing the core of the problem, um, while sacrificing, you know, whatever short— like, shortish-term goal, um, if now is the time to— like, if If you've ignored it for long enough, realize that there is in fact a cost to doing it. And so at some point it is worth investing in, investing in, you know, the unblocking of the momentum.

I love to stop telling the team on how to do things.

Yeah, exactly. Because it chips away at this agency feeling.

Yeah, yeah, exactly that. I experienced that myself. I didn't really, uh, was able to articulate it well when I was part of the coding experience. I was individual contributor before, you know, many years moving to leadership roles. But while I was there, you know, I couldn't articulate what's actually going on. But anytime I would get people telling me how to do my, you know, my thing or my work, I would just lose interest instantly.

I don't know, it just took this old drone because then you just start feeling like, oh, I'm just, I'm just a runtime environment. If you're giving me commands, I just run it.

Runtime environment, I love that. You just run time environment, right?

Yeah, nobody wants to just feel like that because especially when they've got more to give, that's the, that's the worst part. Like, then if you've got more to give and you're not allowed to give it, um, that's when you start feeling like, oh, what the hell am I doing here? Like that, that feels bad. And so figure out what your employees can actually give. Let them give it because it feels good to them and it'll feel good to you, and that's how you'll win.

Yeah, yeah, I love that. All right, so one, one thing, uh, well, not necessarily one thing, but everybody has some type of engineering dashboards. You know, DORA metrics came up a couple of times. I feel like these guys nailed it. Like, it's been like, what, like 15 years? It's still the only almost like de facto, right? Um, so everybody has engineering, uh, dashboards tracking some type of metrics. From your point of view, like, if you see them and you would be able to sort of pick at that, do you have metrics where you would just go like, let's just remove these, like, these are just noise, you know, like things like, I don't know, code of lines or something like that?

Like, just like, there's a lot of— if you're talking about things to remove, we can come up with any number of ridiculous things. I think the more interesting things are like, what do you have on those dashboards?

So everything Everything goes out and you just keep DORA metrics.

Yeah, keep the DORA metrics. Keep your, like, obviously selfishly build times. They're very, like, build times and basically that time to actionable insight for every team. Figure out what that is. And then if it's for developers, usually it's build and test times. So yeah, figure out what is the core metric to this unit producing momentum and just measure that. Ideally, it's some time. Like it's build times for developers or ship times for whatever, deployment times for the deployment team, or whatever it is.

I really love the time to actionable insight. Yeah, I never heard of that, but now a couple of things going through my mind is especially with support teams, um, when they get, you know, they get something, um, reported like boom, issue X, right? They usually look at that and they provide some type of, you know, here's a log, here's this and that, and then it just sort of like sits as a comment in the, in, in the flow. So that would be like, how quickly can you go from I got this to giving you an information where you can action that? Like time to an actionable insight. Yeah, that's an excellent metric. Oh, I love that.

But, and it depends on, on What the actionable is, what the insight is, it all depends, it's all contextual. But overall, if you can reduce the time to actionable insight at every level of your organization in sort of a fractal way, you will move faster as a company. If you as a company have shortened that time to actionable insight, you will then be able to move faster, better, you know, stronger, all the Olympic superlatives.

Okay, so we got one more question, uh, from audience, uh, Briha. But I mean, it's not in the soul with the episode, but I'm still gonna put it on the screen. Let's see if we want to tackle that one. So here we go, we go. I am able to make an efficient timetable, but I'm not able to follow it. I procrastinate a lot. Please give me a solution.

Come on, man, let's like solve the procrastination. Then that means it's not the If you're already able to make your timetable and you know that, that these are the things to do, it's, it's not knowing of the things to do, it's something, it's something else that's actually holding you back. Figure out what's actually holding you back. Perhaps it's, it's motivation for the problem in general you're trying to solve, or it's, you know, maybe you just— it could be something is— maybe it's just biological. Maybe you just need to go and work out a little bit and like have the, the brain feel good. Um, anything like, uh, Basically, if your timetable is not doing it for you, that means that's not where to look anymore.

Yeah, I had the same. I honestly, I use timetable as well. I love timeboxing. I think it's a great way of taking control of your time. When you work for big organizations, especially if you work in fully distributed teams, I'll be honest, people tend to steal time because, you know, like you need to cater different time zones, so you just get meetings added. So you lose that control. But if you work for yourself, you can absolutely take control of your time with the time boxes. When it comes to actually doing work you're planning to do and, and you procrastinating, um, the only advice I have— and I actually made the post on LinkedIn like a day ago, so that's a very interesting coincidence— I took that from, um, this guy which is very popular online. He's a, he's a, he's like a professor. I think he's called like Huberman or something like that. And he talks about like a lot of how, you know, brain works and chemistry and things like that. And the advice he's giving is anytime you procrastinate, actually go ahead and do much bigger task than the one you procrastinating for. It needs willpower, but apparently, if you scientifically proven, if you do this couple of times, next time you're gonna go against the items which you previously procrastinated before, they're not— they don't gonna look that big. They're gonna look like a breeze, and you're just gonna go ahead and do that. So it just takes one couple of tests.

Yeah, yeah, I've heard some— so many different approaches, you know. Yeah, like there's some folks who swear by, well, if you've got this thing, then just break it way down further. Like, oh, you don't even have to— like, just make— just do the smallest possible task. And like, looks like doing the way bigger task also helps. And so yeah, I'm sure there's all sorts of ways, but Ultimately, if it's a motivation thing, it's a tactical thing. Like if you've tried the timetable a bunch of times and it doesn't work, go look elsewhere, friend. Yes.

First, first, how it's called, first level thinking of, you know, first, I forgot the term, where you just dig deep, dig deep, dig deep until there's nowhere to go and you actually are at the root cause. Of your issues, and then you start solving from that point on.

Yeah, yeah, yeah. I think first principles is what you were—

first, yes, thank you. First principle thing, here you go. Right, so, so we are at the end of this episode. Uh, Priya, you come from Buildkite. Give us a little bit more about Buildkite. And as well, I'm sure people listening went like, okay, I really care about things you just said. How do I get in contact? You know, how do I have more conversation around the topic?

Yeah, yeah. So great. Yeah, so I'm at spriha@buildkite.com. And I'm on LinkedIn and whatnot. So yeah, you can add me there. But Buildkite, yeah, Buildkite is the world's most powerful CI/CD and workflow orchestration platform. And the reason I can say world's most powerful is because— so the company has been around for 13 years at this Oh, nice.

Okay.

We've invested— the largest codebases in the world all use Buildkite. The most nimble codebases in the world use Buildkite, even if they're not large. And basically, the world's best engineering teams have realized that Buildkite is the tool to do workflow automation with, including CI/CD. A lot of folks start with CI/CD, start with Buildkite through CI/CD. But increasingly we're finding folks use us for all sorts of other workflow automation stuff. So at its core, Buildkite is a system that lets you define a set of tasks that need to be done and then run them on whatever hardware you need to do. And like I said earlier, we give you the ability to parallelize things, to skip things, to cache things, to reuse things. So to be able to scale up, that's, that's definitely our sweet spot. But we also, because of our flexibility, we're also used as a— our primitives are used as a base for a lot of other systems. So we've got customers who use us for, you know, an auto, auto version upgrade tool. We've got customers that use us to call to as a base to build LLM-based workflows. So, like, with Buildkite, you can have, as a platform team, you don't just offer your build-test-deploy systems to your engineers. Now you can offer a system to fix errors or like basically much higher order systems, you know, like just code review tools and that sort of thing, all through Buildkite. Buildkite is basically a developer platform tool. So we help you, uh, we help you build a developer productivity suite of things, um, by giving your developer platforms all the right primitives they need to be able to build out their— to lever up your organization.

So if I'm a startup, Priya, like, um, what's the pricing module of Buildkite? Like, if I'm a startup, you know, can I experience, you know, the power of Buildkite?

Yeah, and funny you bring that up because internally we're just talking, we're going to be re-releasing our free tier soon at some point.

Okay.

But yeah, but you can in fact today start Buildkite for free as well. And if you're a startup, that— we will also just very soon we'll have a free tier. But yeah, you can try Buildkite out at buildkite.com. Try it for free. Run— you can run it locally on your computer, you can run it on the R cloud. We've got a hosted version you can sign up there. You run it on your infra if you bring your own compute. But yeah, you can, you can try Buildkite for free at buildkite.com.

Excellent. Okay, well, we'll have everything in show notes if you're not tuning in live, or even if you are tuning in live, I'm quite sure I put everything in the description. So just scroll down, check that out, get in touch with me if you care about the ways you can help your engineering teams in their workflows, or if you want to learn more about Buildkite. If you find the episode valuable, do share with any tech leaders you have in your network. We'll have some feedback, and make sure to subscribe to masteringtechrole.com. And as always, guys, until the next time, see you online.