This was a good read. Review is good but it does slow things down.
With async PR review, I prefer the “✅ with comments” review. Unblock the person from merging with trust they will read and resolve your comments first.
https://apenwarr.ca/log/20260316
In case you missed it in Homebrew 5.1.0 release notes: we’re doing a short user survey to inform future development.
https://docs.google.com/forms/d/e/1FAIpQLSeeNd7T0Zj9zOl8Y2MP1YITPk_qNUIP5knfCqSmOH2oB2O_UQ/viewform
Today I’m proud to announce the release of Homebrew 5.1.0. The most significant changes since 5.0.0 are expanded brew bundle support, brew version-install, new -full formula handling and installer updates.
https://brew.sh/2026/03/10/homebrew-5.1.0/
Great post here from Andrew, particularly on why Homebrew doesn’t need a NPM-style cooldown.
Should be obvious but seems it’s not: don’t spam OSS maintainers or coworkers with AI code you’ve not reviewed yourself.
For coworkers only, sometimes fine explaining your testing and why reviewed isn’t necessary e.g. a one-time script.
https://simonwillison.net/guides/agentic-engineering-patterns/anti-patterns/
It’s hard to understate just how much more productive coding agents are at some tasks in YOLO mode. Essential to have a good sandbox for this, though. My favourite so far is sandvault: no Docker nonsense needed.
https://github.com/webcoyote/sandvault
The year is 2068. All matter in the solar system has been consumed for energy. All energy is used for the system’s sole remaining purpose: AI generation of another new frontend for Homebrew.
The author and I are convinced AI is net positive in engineering today but worth engaging seriously with the downsides.
https://tomwojcik.com/posts/2026-02-15/finding-the-right-amount-of-ai/
Google continues to take money for malware pretending to be Homebrew installation.
There’s nothing Homebrew can do about this. Google needs to fix it.
Please put me in contact with someone at Google high enough level to actually fix it.
https://github.com/Homebrew/install/issues/1074
Andrew nails here many parts of what actually makes OSS maintaining hard work.
Empathy is needed more for OSS sustainability than money.
https://nesbitt.io/2026/02/13/respectful-open-source.html
“This new technology will replace developers!” is not a new thing.
Nice look at what some previous claims were (and how they resulted in more developers and more software).
https://www.caimito.net/en/blog/2025/12/07/the-recurring-dream-of-replacing-developers.html
31 January 2026
Thank you everyone for having me today, this is my first time at the big stage in Homebrew, in Homebrew, Fosda. I've been here many years, I love this conference, it's the best open source conference in the world, but first time here. So I thought, given this topic is potentially contentious, I would get a friend of mine, hopefully make me feel a little bit better. So I sent him the screenshot of when this got accepted, and I said, oh, fuck. So he congratulated me, which was very kind. He thought nice things about the title, and then unfortunately let me down. So hopefully I am not in fact fucked, but if I am, hopefully it is entertaining for all of you to watch me, as we say in the UK, die on your arse. Anyway, so some important framing, right? We're going to talk about some stuff today, which is pretty fresh, like literally some people who have been involved in the story are possibly in the room, and I've seen people at FOSVEM, right? So who already has an awareness of what happened with RubyGems, even a vague one, right? And who has like strong opinions about maybe who was in the wrong and who was in the right? Trick question. But yeah, okay, so a few of us. So what I ask us to bear in mind, right? This is not a trial, right? It doesn't really help us to go and point fingers, particularly at individuals, actually, because this is mainly a story about groups of people, and communities, and open source foundations, and open source maintainers, and companies, and all of that interesting stuff, right? And I actually think this stuff gets, particularly when I'm sitting on a stage, and people won't be in the room, it's a bit mean, if we start pointing fingers at individuals, so I'm just not going to do that. I'm going to try and avoid naming anyone except myself, because I'm allowed to be self-deprecating because I'm British. So the next thing, again, I want us to just encourage anyone who right now is like, this group with this person, completely fucked this up, and this group of this person did everything right. Like, that's a bit of a red flag, right? You know, many of us in the room, I'm sure are engineering, right? And this group of this person did everything right? Like, that's a bit of a red flag, right? You know, many of us in the room, I'm sure are engineering, right? And this group of this person did everything right? Like, that's a bit of a red flag, right? You know, many of us in the room, I'm sure are engineering, right? We work with engineers, right? And we work with software, and complex systems fail in complex ways, right? So if you feel absolutely certain about something, that means either you're probably missing something, or maybe you have a bias. That's okay. No shame, no shade, whatever, right? But just let's try and try and come into this with an open mind, right? Again, another important framing, I think, for all this is incentives of everything, right? Like, very rarely in the world do we actually have particularly in things like open source and in workplaces and not Netflix shows or whatever like people who are just unbelievably evil and cackle away as they deliberately do the thing to maximally fuck over as many people as possible right like people are responding to the incentives that are put in front of them right people don't go into things generally with bad intentions and generally the people who we look at in these situations who we think maybe have bad intentions just have a really bad incentive structure set in front of them right so I'm also need to look at things through that lens and we're gonna try this being a lot of I guess the word drama has come up again and again when people have been talking about this right sometimes like favorably sometimes used to critique one side or another or whatever but I feel like we thankfully have moved past the drama stage right and we can be in the learning stage so let's do that this talk is about free and open source software and specifically infrastructure projects which I'll talk a a little bit later on why this is a particularly important topic for me specifically but these projects underpin an enormous amount of the internet right like for most even kind of commercial software developers who are not here who care nothing about open source who probably don't even really understand open source the amount of open source software that has to work and go right and be lined up and perfectly orient itself for that person to do their day job and increasingly their day job far removed from technology is pretty breathtaking when you think about it right it's arguably open source software is one of the best achievements we've made as mankind and I love conferences like this because I think it really highlights the kind of beauty of what we're doing here right we are creating this worldwide system of software which is incredibly powerful and many people rely on empowers so many other fields right but because it's invisible when it's working and because people don't think about it often it just fades into the background and that success that comes from making things invisible and transparent and just smoothly flowing makes it even more dramatical that's not a word even more dramatic when things fail when things fail they fail loudly they feel globally and the blast radius on important projects it's never small so Ruby gems is one of those systems and that's what the story today it's gonna be about not talking about heroes we're not talking about villains we're just talking about systems of distress and what we can learn so who am I why am I talking about this and what can you maybe learn from me firstly I think that's legitimate to ask particularly in something like this story because I think a lot of the people who maybe have a strong opinions like when you understand a bit about their background it's maybe clear why they have the view they have so I'm the project leader of homebrew a Mac package manager it runs on Linux and stuff as well so I've worked on that since 2009 so that'll be 17 years this year which is slightly terrifying and I think what that does is it gives me a little bit of context about what it's like to run a package manager what it's like to work on these open source projects for long periods of time but we'll see later I'm not super involved with this story beyond that right I was a principal engineer at github for a while that told me a fair bit about open source it told me a fair bit about Ruby because that's what github is primarily built in and scale security liabilities etc I think most importantly actually for the story I'm a Rubyist I first wrote some Ruby in 2005 I've probably written Ruby more than any other language since about 2009 and I deeply love it I like the ecosystem I like many of the people I have friends I've met because of Ruby I have jobs that I've got because of my work on Ruby and I have depend on it for most of my career finally and somewhat least importantly like I have a day job right open source is not my life I'm a CTPO a small training management software company in Scotland but as a result of that I have had to do an awful lot of like work around growing as a leader and trying to understand how systems and cultures and incentives are set up and what happens right I'm not a Ruby James maintainer I never have been I have similarly with bundler I have no affiliation with Ruby central I've never been involved with them I've never given them any money I've never done any work with them or anything like that in this situation that I was asked to mediate so some people we'll talk about later on like the way homebrew does governance was kind of cited relatively early on in this situation and as someone who was kind of very involved with with homebrew and our governance process I was asked to kind of come in and see like well how can this apply to Ruby gems or not but unfortunately my mediation did not manage to stop happening what's happened right it's interesting because pretty much this whole story takes place between September and October 2025 we've we kind of have a bit of stability now I think some of the kind of strongest emotions were kind of past that stage which probably helps us to look back a little bit so we're talking about weeks for most of these events rather than years although the context set beforehand and the stuff we'll learn afterwards we'll go back and forward I help gems that co-op you don't need to know what that is if you don't already and I help them kind of set up their governance process I learned some stuff along the way so okay who knows what Ruby gems is hand up okay most people so I'll keep this brief rubies package manager is Ruby gems it's technically you could use another package manager but that's the main default that the vast majority people use it was actually founded in 2004 and after Ruby had been around for a fair wee while like nowadays often the software kind of comes with version can version locking and package management along with the language right out the door but that was not the case with Ruby gems and Ruby there's millions of applications that are on Ruby gems and as a result it's we're not talking about some niche tool used by a few people we're talking about kind of critical infrastructure on the internet which brings up things like software supply chains and all these other kind of big grown-up selling words it's not side project as well right many open source projects are essentially run by one person in their evenings and weekends they never get any money for it they never spend any money on it and it's just like a fun little hobby but Ruby gems is not in that category Ruby gems is much more critical so money money money is messy particularly when you involve it with open source who feels a little bit uncomfortable talking about money sometimes yeah quite a lot of people and like open source money is even more potentially uncomfortable because well some things cost money servers cost money storage cost money bank with the cost money on coal if you want to pay someone well sorry if you want someone to be woken up at three o'clock in the morning on a regular basis when stuff breaks then generally you need to provide a bit more incentive to that than just peer pressure and community goodwill incidents cost money and if you've got years of work you can have it undone in a few hours when you have some critical incident and it's why organizations behave differently under stress because depending on where the money is that tends to focus attention even more closely when incidents are going on but not everything costs money let's compare with the open source project I've worked on for a while with homebrew right so this is not to say homebrew is better or worse it's just a comparison because I think we're two projects both written in ruby but we have a different approach to these things so homebrew's hosting when you download homebrew's binary packages we do not pay any money for that because we were originally hosted by sourceforge then bin tray and then nowadays it's github so the trade-off for that is that homebrew is not as independent as something like rubygems is right like rubygems is not relying on any single vendor like they push their servers on every us but they could move relatively with big finger quotes easily to another provider and probably certainly a lot easier than homebrew could so in some ways we're not even independent we're somewhat dependent on retaining in the good graces of github right I used to work there I still know a lot of people there so I'm not as worried about that as I might be something else but again that may or may not be a decision that makes sense for your project or for rubygems so let's quickly scan through the timeline of what happened these events right so ruby central the organization that's kind of often cited with this discussion was founded originally in 2001 and by a couple of people in the ruby community who wanted to provide a permanent nonprofit for running ruby community events and handling sponsorship and logistics a few of those same people were involved with releasing rubygems in March 2004 and then we have to go forward about 11 years before we kind of reach the next group that's kind of relevant this story which is ruby together so they were actually announced by ruby central in 2015 and they described their purpose as funding on-call rotations maintenance work and improvements to shared ruby infrastructure which included bundlers rubygems and rubygems.org which had in their words historically been done by volunteers in 2022 these organizations merged and became a single nonprofit described the motivation as reducing duplicated nonprofit overhead and unifying community for the events under the events under one roof so this brings us to basically the more contentious events right hands up if you were following this live on social media when it was going on in 2025 right yeah a few people here so September 2025 everything kind of goes down within a few weeks right and again i think there's some interesting context when we talk about the setup for this taking you know almost 15 years and then within a few weeks things radically change so one of the first things i think that happened was control of the main github organization which was used by rubygems related projects was changed in a way that restricted or removed access for some of the people who are maintaining rubygems and this came out of some folks who were involved with ruby central that also involved reading the github organization from rubygems to ruby central and essentially there was as far as as various people involved various people involved are concerned some people say this was very long time coming and this should have been expected and other folks felt completely blindsided by what happened there wasn't certainly any public notice of this people had some sort of behind the scenes warnings that something might be happening but certainly a bunch of people were as i said essentially blindsided by what happens and the problem with this is when you make decisions quickly and when you deliver them somewhat abruptly that always tends to you feel hostile right it feels it can feel malicious it can feel difficult it can feel targeted even if it wasn't necessarily intended that way and particularly in open source when we assume so much stuff is going to be done in the public when there's no public communication at all then it can make this very hard there was also essentially no governance process so i mentioned before homebrew's governance process we'll talk a little bit about that later but essentially at the time when this was all going on there wasn't a documented process about how people get added to how people get added to how people get and removed who controls what which non-profit is responsible for what what taking money means as a contractor or an employee or whatever with this organisation and the problem is when you don't have a written governance structure then whoever holds power ends up filling the gap and getting to make the decisions so after the initial shock we had an attempt at recovery right it looked like things were going okay to begin with so we got to mid-september there was multiple possible futures it looked like maybe we could get everything back everyone could get back on the same page there might be some hurt feelings but we'll be okay there was a governance PR proposed on september the 14th and you can go and see the url show on the screen in a few slides where you can see the kind of conversation that was going back and forth this is how I kind of ended up getting pulled in as well because it was based off homebrew's governance and then I was I kind of offered to give some input there and then got pulled into mediation as well and then shortly afterwards the access was restored for most of these people right so if you go to the PR you can kind of see how this went on and like the sort of tick-tock of what was going on in the event right so then by September the 18th we get to a point where I've offered to kind of step in and mediate between both sides there's a lot of private conversations going on a lot of private contacts going on and in public it looks good it looks like we're both sides are discussing governance and then we get to the point the access gets removed again for a bunch of people right and this is when things get a little bit messier because some folks who had their access removed and then claimed that it was a mistake that their access had been removed and then others took offense and essentially things get very messy very quickly right and then trust just gets destroyed and never really rebuilt this is when we start to get security concerns invoked as a justification as well there was mention of supply side security which in recent history there have been NPM supply side security attacks so RubyGems having a relatively similar trust model like that was concerning to people being involved it also concentrated power very quickly and made clear who had power to do what and who was citing these concerns and using them to make what decisions so by the time we get to late September we have another inflection point where it becomes public on the 28th of September the root level infrastructure access still existed outside the new control structure so the people who were maintainers and had either been removed from the project or had quit the project in protest at the changes some of them still had AWS access and AWS root access even more severely right so again this back and forth about exactly who had what access and when why and what this meant but essentially regardless this is a bad situation right you have a situation where the theoretical control of the project and the actual control of the project are diverging pretty far right and then essentially there was a lot of back and forth but eventually we reached the end state where almost a month later in October the 17th RubyGems and Butler moved to the Ruby core team so essentially Ruby central who had taken ownership of these projects then gave ownership elsewhere and then the people who had been existing maintainers of RubyGems declared that they were happy with that and they were going to allow things to move on So you can see you can read the route access event this has got kind of Ruby central's take of like what went down with the AWS access and stuff like that this was posted on the 9th of October and then while this is all going on it gets to the point where there's enough drama that like various parts of the tech press started reporting on it and people are getting quotes blog posts social media press coverage essentially take over we're not having really any discussions on PRs anymore this is all happening out in the open and then the narrative stops being controlled by the people who are just involved and things become a little bit reactive people start raising privately a lot of people in the Ruby community people's confidence drops like what does this mean for RubyGems is RubyGems still going to be running anymore and worst of all lawsuits begin like we have again publicly on the record both sides have talked about how they've engaged in legal action with the other high we have no insider knowledge as to what the statuses of said lawsuits but I think it's relatively predictable that once that happens people are no longer interested or able really to make good and be friends with people they are in lawsuits with at that point so what were the consequences what happened here well talk failed pretty quickly right so people tried to voice what was going on and how they were feeling and how they could improve things but then when people get kicked out the project then all of that just becomes public discussion instead of private discussion so a bunch of maintainers exit the project some people removed against their will and then some people removed protest so you get to the point where the majority of people who are working on RubyGems in the space of two months essentially have left and gone and done their own thing so doing their own thing what does that means well there was a single gem co-op which some of the maintainers went off and decided to build so they essentially built their own alternative to RubyGems both centralized service and they have forks of various other projects and stuff as well so this was not an overnight replacement but it was spun up relatively quickly and it built essentially a separate kind of side ecosystem which changed the power landscape right so forks don't need to necessarily win or get more users to matter and in this case I think this kind of sent a message about how things could be done differently and it also made clear that that group of people were not interested in re-entering the fold again so another interesting kind of consequence of this is I guess what I would call professional open source so what I mean by that is we have a bunch of people in this room I would guess probably the majority of people in the room how many people are paid to do open source work for primarily at the job okay I guess if you look around the room everyone that is the minority right and I would say in the open source community in general it is in the minority right so when you have people whose full-time salaried work is focused primarily on open source and when they have bosses and leaders and HR teams and their mortgage depends on them making those people happy then the incentives are radically different right and it introduces different incentives to what exists before when you have volunteers working in their free of time and also you have the blurring between the two where you have people taking contracts and doing paid work on open source they might not be an employee but they have agreed to some sort of transactional relationship in exchange for money and that makes things hard and this is even more tricky when you have a project like rubygems which is already hard because you're running critical open source infrastructure and it requires many skills outside of writing code right which is sometimes the easiest skill to be able to get from the community in open source because what this means is that volunteers have their limits and people run out right so what does this mean for careers right so a bunch of the people involved in this story had at some point been paid either full-time or part-time or were full-time employees of ruby central or ruby together or whatever it may be well my potentially contentious take is open source is not a career right and by that I don't mean those you said it's your full-time job to work on open source I don't mean that you somehow don't have a job and you're in a haze and don't really know where you are what you're doing like obviously some people do have that but most of us don't open source can be part of your career and even those folks I imagine who are working full-time open source I would imagine your day-to-day looks pretty different to how it did if it was just your evenings and weekends right it's a very different way of working and I don't think we help our community by making out that the way you work worked before you received any money can just be paid a bay area salary without any change to it so I think we also need to plan for our exit as individuals and as organizations and exit of funding and all these types of things right we need to plan for the transitions that are going to happen even when they're deeply uncomfortable because ultimately one size does not fit all every project is going to ebb and flow and change the years and context is everything so what can we learn from all this well as I said at the beginning it's not about blame right we need to not blame because it just simplifies and polarizes and it prevents learning if you're 100% sure about who's right who's wrong then that's going to feel good maybe for you but it's not going to explain very much governance and open source is really boring until it's not and at that time it's probably too late to introduce it okay maybe money entering the equation makes things better but it certainly makes things a lot more complicated and we should think really carefully about how and when and why you introduce money to the open source project let's all not focus on who was right and who was wrong not who messed up but instead just try and ask better questions let's ask about what broke and why it broke and not who did what and then we can learn something about governance or money right if your project hasn't argued about governance or money yet it probably will one day be prepared and try and do this stuff before it becomes a problem and that's the transferable lesson if you've got questions then come and speak to me outside you can email me or you can find how to contact me other ways on my website thank you very much Thank you.
31 January 2026
I like to do people putting their hands in the air in the talks because it stops you from falling asleep and it makes me more visibly aware that people are actually listening to what I'm saying. So put your hand in the air if you've ever used homebrew, okay, a reasonable number of people. Put your hand in the air if you ever contributed to homebrew, put your hand in the air if you ever tried to contribute to homebrew and I closed your PR. Sorry, sorry, yeah, so I'm, we've been, I've not been able to hear all the talks today. I do follow, try as much as I can closely what's going on in package management world. Shout out to Andrew's written a lot of very good comparative blog posts on this stuff this year that I've enjoyed. So I'm going to try and talk about today is like a bit more high level than I might say with homebrew stuff about, okay, what have we been doing in homebrew now and why and what can we maybe learn about it in other package managers. So who am I? Hello, I'm Mike McQuaid. If you want to know about me now, my website is the best place. It's all connected to social media and stuff. I don't read anything on social media anymore. So email me if you want me to actually see it or post on social media if you want to talk shit about me behind my back and feel great about it. My background, I guess, like how I've got into homebrew and stuff. So I've worked in software for almost 20 years. I've been working on homebrew for 17 years this year. I'm the project leader, which is an elected sort of dictatorship sort of position thing. So I'm a CTPO in my normal life, day job, whatever, and that sort of vaguely overlaps with homebrew but not very directly. So why should anyone care about homebrew, package managers, why I have to say? I mean, who in here cares about package managers? Okay, good. I'm glad that someone does other than Andrew because otherwise he'll probably cry. But I guess in my life, the thing that's great and terrible about homebrew is that it's somewhat taken for granted. Like a lot of package managers, it's just part of the infrastructure of how the internet works, how I do my job, whatever, right? So if you go and run, who's run Bruin still in the last week, say, okay, right? Like you probably didn't really think very much about it, right? Because you probably just ran something and then hopefully it worked. But then when it doesn't work, then everyone gets upset. Like most of the time, it only specific things are broken in specific ways for specific people. But then when it's all broken for everyone, then everyone gets very concerned. And the emotional reaction that people tend to have to when these tools break is heavy because they're so reliant on these tools. Like it's really important to them that it works. And in some ways it's, if I can be a little bit philosophical, it scares people a little bit when they are forced to actually think how many bits of the internet and tools that they rely on by all these people at all these places all around the world that they are completely unable to do their job unless all of these things connect together. And often the people who are the most involved with open source are the people who are the most forgiving when homebrew breaks. And the people who are the most disconnected from open source are the people who are the most angry and sometimes abusive when homebrew breaks. It's a bit like your toilet, really, because when it's working, you probably don't spend a lot of time deeply thinking about your toilet unless like me, you've recently been in Japan and you're like, wow, their toilets are so much better here. Why is my toilet like that? But then when your toilet breaks, then we just get shit everywhere, right? Like there's chaos. No one knows what they're doing. No one knows how to fix it. No one really wants to stick their hands in there. We have friends at the beginning of the talk. We may be at the end. So most people get very frustrated when their tools are slow. Another one, bundler is slow. Like everyone often complained about that for a good many years, right? And then what gets done, people get frustrated. So in, I feel like in many ecosystems, people get the same feedback about things being or feeling slow. They maybe don't even know why, but then sometimes the reason why it feels slow is because we get new tools. So cargo is often held up as an example of a package manager that like feels fast, right? And I've not done huge amounts of rust stuff, so I'm not super familiar, but it's, you know, that reputation for speed is something that's appreciated in the community. It sort of founds the community's expectations of what these tools should be like, how they should behave, how fast they should feel, how responsive they are. In some ways, it kind of helps to buy into like, what does that language community care about? Like the rust community seems to care deeply about building lots of tools that are responsive and fast, well-paralyzed and all these type of things. You know, a lot of the tools that I, one of my favorite tools that's embedded just about everywhere now is like RIP grep, which if you were like, how many people went down the path of like, oh, AK and then the silver searcher and finding the perfect tool to search through your code base increasingly quickly, right? Yeah. So if you went down that line, then you learned a few years ago, like a lot of these tools started to be built in rust and there just became this little niche of people in the rust ecosystem who really care deeply about just being like, I'm going to make the fastest version of X or I'm going to make a really paralyzed version of some existing Unix tool that hasn't really been updated in 20 or 30 years, right? UV, obviously that's another example now, right? Where that in the Python ecosystem is kind of reshaped expectations of what speed we should be expecting from these tools. What we can do and I think UV is an interesting example because I, again, I'm not super au fait, so excuse me if I misspeak slightly on this, but my understanding is some of the reasons why they've been able to be faster is because they've kind of dropped some support for legacy things, which tools like PIP or whatever might still have to rely on, right? And again, like, this is where things get a little bit more tricky and a bit more murky for us as like package manager like developers. It's like, okay, so what, to what extent do we prioritize speed or backwards compatibility or following the leads of other tools or maybe we have multiple tools in the same ecosystem? Who can say, right? So Bundler, right? Like, I feel like Bundler was a tool that 10 years ago I heard people complaining about how slow it was all the time and then a lot of work went into it and then now it's a tool where, you know, it's not the fastest thing in the world, but it's still like, it does not seem to get that complaint levied against it nearly as often as it once did, right? And I think Bundler is a nice example because they didn't throw out everything that they were doing. A lot of just time and effort went into it behind the scenes that meant that the tool ended up just being fast. You can add a few more things, then you'll have 10% that don't work, then 5% that don't work. And if you want to get 100% of packages working 100% all the time, you essentially have to reimplement most of Homebrew and that's probably going to be a bit slower than you have right now, right? So I ask us all to be collectively both inspired but cautiously skeptical of some of these tools that appear out of nowhere and say, "Hey, we've been able to do this 10x faster than anyone else." Because there's some stuff you can learn from that for sure. Like, we have learned from that in Homebrew. But there's also, it's very easy to make a prototype version of this which never quite gets around to iterating into something that works reliably and can be used at scale. Thank you. Why do people do that? In some ways, this reminds me, I don't know how many people ever saw the legendary Stack Overflow answer that descends into madness about parsing HTML with regex. Yeah. It reminds me a bit of this, right? Because it's like, you can parse HTML in a simple way with regex really quickly and easily. And it's like, look how little code this took. And it was really quick and efficient. And like, I'm 90% of the way to solving this problem. And then I just need to put a bit more time. Oh, I'm almost there. I'm almost there. But then if you know essentially enough about the problem states, you know that like fundamentally, you are trying to do something that is with most regex parses. I know this pearl does some special things. It's fundamentally impossible, right? And it's a similar sort of vein here, right? Where what they are trying to do is admirable, but they have taken a shortcut to do so that makes the end result essentially fundamentally impossible. So back to homebrew. Like, so the big thing we did recently in the last year essentially was if you've used homebrew, you've seen we do this kind of concurrent downloading stuff, right? So in fact, the person who did much of the work, Marcus, is in the room with us right now. Hats off to Marcus. And we also have done some work on like a slimmer like internal API and stuff like that to try and focus on this stuff with speed, right? Ruby 4.0.1, like the time it takes to output hello world to a terminal is dramatically slower than the time it takes back to do the same thing. And okay, most people like someone literally with the homebrew performance stuff I posted recently on social media, someone replied saying, in what world does homebrew's performance actually matter to end users anyway? Like, yes, this is a good point. But we still get people whining when like their shell initialization takes 0.1 seconds longer than it should have done or whatever, right? And then porting stuff to bash makes things, you know, in our case, sometimes 100 times faster than just by the time you spin up the Ruby interpreter, right? So again, like it's a weird thing and it's very project specific and it's not general advice. But again, for all of you working package managers, probably your three items are completely different. And some naive person from the outside looking in will probably have ideas of why you're slow and what needs to be fixed. But you will know what these things are and you need to make sure you put these things in front of your team and in front of contributors who might want to come in so that they actually know how they can improve this stuff in a meaningful fashion. So as a result of that, like I think homebrew with the 5.0 release, like people are complaining about it less. I think we've done a bit of a bundle of thing where homebrew is definitely not fast compared to its competitors, but it certainly feels a bit faster than it was before. And I think we have now room for understanding and improvement of how we can move forward. Right. So act two is let's think about like what we're doing in package manager land. We talked about like user expectations, performance and things like that. But I think another big part of software in general, right, like I've taken over as like a CTO relatively recently. And one of my big things is like, how can I make things go faster? And one way of making things go faster is performance and profiling and optimization. And let's like do that. Another way of making things go faster is thinking about what are we doing today? And what are the things we can stop doing? And if you can just do fewer things, you get this combinatorial explosion of once you have these different options and ways of building packages and their dependency trees and everything like that, such that it became almost impossible to debug these issues in a meaningful way and support them and stuff like that. Because again, we had limited CI infrastructure. So we're not able to just go and say, okay, well, we're going to build everything in every combination every time for every dependency and figure out if that works. So instead, we moved essentially to a model of like our binary packages where instead of going from Homebrew compiles a bunch of your machine, it's Homebrew gets a tar bowl that's already been built somewhere else and extracts that, right? So that was dramatically faster for users. It was dramatically less error-prone for users. But for power users, that resulted in us basically being like, hey, there's a bunch of stuff that you could do with Homebrew before that you now can't really do. Or at least, to be more exact, if you want to do this, you need to go over there and do the work yourselves because we're not going to do that work for you. Which, as far as a lot of open source users are concerned, is the same as saying this is now fundamentally impossible. But the tricky thing with this is now we're in the situation where, because not everything's being built on individual user machines, we need to figure out like, well, what are we going to support and what are we going to build and all that type of stuff. So it started off with just like, okay, we build one package on one platform. We pick a macOS version. We build on x86-64. Great. Then eventually we add Linux support. Then Apple came along with Apple Silicon. And then we have to do ARM64 support. And then we decided because we hate ourselves, we're going to do ARM64 support in Linux as well. And then I'm sure at some point there'll be something else, right? So like, yeah, exactly. Risk will come. I'm sure you can run homebrew on your toaster or whatever, right? So if, hands up, any folks in here who support like software on multiple platforms or more platforms than they did 10 years ago, right? It, it's a bit of a pain in the ass, right? About what works for 90% of people most of the time, right? And then that was their primary focus, right? So in homebrew, we've tried to do the same thing, right? We, we tried to focus on like, what do most of our users actually do? And what that looks like is getting to a point where you realize, well, we're supporting a bit too much, right? So we used to support, in theory at least, every macOS version. And then a few years ago we decided we're going to support three. We're going to support the current one and the two preceding ones, right? This makes people upset sometimes because they're still using their old Mac and they feel like Apple's abandoned them and now we've abandoned them and this is really unfair. But then even then, even with these three versions, what that looks like is, okay, well, does that mean we have to support all of this? Or actually all of this? Which just gets into madness, right? Because every like line here, if you're going to support that, like we're saying we expect all of 10,000 packages that we claim that will work on these are going to work on these all the time. And when it doesn't, it's a bug and we're going to fix it and it's going to break or whatever. And then it's come back to the like, well, Humber is slow, right? And maybe this isn't slow in terms of the behavior, but Humber is slow to fix bugs. They're slow to merge our PRs because we have this matrix of issues that we have to deal with all of the time, right? And what that means is you end up having to slim it down, right? So we say, okay, well, we're not going to support everything all the time. So we now don't build binary packages for the newest versions of macOS because we're like, well, A, we don't need to necessarily hyper optimize for that. B, we probably get reasonable matrix coverage from the otherwise and C, like Apple are dropping this, right? So on the 9th of September, sorry, on September 2026, we're going to stop building binary packages for Intel altogether, right? On macOS, still on Linux because that's the majority architecture there. But it's like, well, why are we doing this? Could we indefinitely build this? Sure we could, but it's going to make the project slower. And we're at a point where Apple will have announced their plans to get off this. So again, multi-billion dollar corporation, 30 volunteers, right, who receive a small stipend. But we should not be holding ourselves to a higher standard than multi-billion dollar corporations, right? On this particular, we have to fight harder and harder against that in order to have something that works for our users. And eventually we get to a point where we're like, well, this is a security feature anyway. No, no, we're not interested in doing this anymore, right? So we, we used to just go, okay, we have these features and we turn them off. And then now we have like with a major or minor release, we deprecate, then we disable, then we delete that code, right? And again, that, if you don't already do something like this in your project and you have like a clear cadence, please, it's, it's so satisfying going and having all that code that causes your pain in the ass. And knowing putting little markers and then be like in six months, I can just delete all of this mess and not have to think about this ever again. Okay. Yes. It breaks backwards compatibility, but then if only we like one day, I think someone will invent something. Let's hypothetically call it a version control system where if they wanted an old version of some code, they could in fact go back in time. I, it's a crazy idea, but I think one day it might pay off, but you know, people, again, it's this thing, it's entitlement. We don't have to deal with that and we shouldn't have to deal with that, right? Rust is a nice, good example of this, right? Where they just state, okay, here's our platform support. Here's what we have. We have tier one, tier one targets can be thought of as guaranteed to work. And in the spirit of open source, we almost directly stole this. And we now have our own support tiers in homebrew where we say, here we have our tier one platforms. These are what we expect to work. Tier two is like, maybe this is going to work. Tier three, it's probably going to be broken. And then to homebrew sucking, we want you to know like, hey, we told you to do it this way. You are doing it a different way. Someone said you are sucking. For those at the back, I will neither confirm nor deny that. But yeah, but it's important, right? If you can just write this stuff down, you will find people are a lot more likely to accept a thing which you put in a document or a section on your website. Even if you repeat yourself verbatim in issue comments all day long, they will argue with you until the sun goes home. But if you say, here's our support document, you can submit a PR with a proposal of why this should be changed. They will never do that and they will stop arguing with you. So, there we go. You are as welcome, asshole. Relatedly, we're going to enter the-- I thought I added disclaimer here, but I think it's maybe gone. But no, in fact, no, it's coming. Right, let's skip over that for a sec. Right, so act three, sustainability stuff, right? So what do we think is the most important thing in open source sustainability, right? Money? People, people. Put your hand up if you think it's money. The hecklers in the front are ruining this delightful setup. Ironically, the hecklers in the front have given HomeRue quite a lot of money to do that. HomeRue did without any money for many years and it worked fine. Code? Let's just fix all-- but we can fix human problems with code, right? We just need to write enough. No? No? No? Okay, yeah, okay. Like, yeah, we don't like-- yeah. Humans, okay. The humans, we are what matter, right? Like, if you are a maintainer or an open source project, it doesn't matter how much money you have. It doesn't matter how much code you have. It doesn't matter how many users you have. If you decide and you're the sole maintainer that you're not going to work on this anymore, this project is effectively dead, right? Someone can fork in it and they can take it on and lead from where you left off. Sometimes people do that. A lot of the time they do not, right? So, what this means is we need to take care of the humans, right? If you're in a project where you've got multiple maintainers, take care of each other. If it's just you, take care of yourself. I apologize in advance. There's a lot of self-promotion coming because I've written a bunch about this stuff. It's a topic I care an awful lot about and I'm not going to reiterate all my own blog posts, but I am just going to put them on the screen. So, you can go and look them up if you're really that bored. Right. So, the first one. I wrote this thing a while ago. Ironically, before AI stuff, robot pedantry human empathy. So, this idea of like what we should try and do in our projects is automate as much as we possibly can, but also not automate the stuff that humans are actually good at. Like, I remember I wrote this party in response to seeing projects that were like automating their messages of being like, you have made a new PR. Good job. You are valued as a human. And it's like, well, that doesn't really mean a lot to people. Let's have the robots do as much as we can. Get them to do, again, pre-AI. This is me mainly talking about CI when I'm talking about this. I love an AI. I'm not going to get into AI today. And that's, as humans, right, we can tell people like, good job. Thank you. You kicked ass. I'm looking forward to seeing another PR from you because you did such a good job in this stuff. That really makes a difference. There are people who contribute to open source for a long time just because of nice things one or two people did, right? There's a guy here at this conference most years, Cornelius Schumacher. He was my mentor on Google Summer of Code 2006 when I worked in KDE. I can say there's absolutely no way I would have done any work on homebrew were it not for him being a really good Google Summer of Code mentor, right? There's so many people throughout this entire conference, entire industry, who have stories like that where this one person made a difference and put me on a trajectory, right? That person could be you by just being nice, saying nice things, encouraging people, right? And I know we have to deal with a lot of toxicity and it's hard. You can get a thick skin. I have a very thick skin. But trying to free yourself out for those moments where you can connect with someone else and be like, good job, well done. It makes a big difference, right? Next thing, contributor funnel, right? All very brief TLDR of this. Think about you have a nice funnel on your project, right? A bit like a sales funnel of any of you know what that is. But basically just this idea of like the people who use your project, some small proportion of them will end up contributing to your project. And then some small proportion of them will contribute enough that you want to make them maintainers, right? But like if you can get that funnel to be as effective as transitioning between each stage, that's going to be really good. So one of the things Homebrew did really early on was some of the expectation that like, this is not a project run by us for you. This is a project run by all of us together, right? Homebrew had no way of doing automatic version bumps or anything like that when it first created. Max, the creator, was just like, right, I'm not going to appoint maintainers for every package. I'm just going to say, if you notice this is outdated, submit a pull request to fix it, right? That did a really good job of getting Homebrew a really, really decent number of contributors for the number of users we had. And we have a tiny number of maintainers, relatively, we have like 30. But still, that's way better than it was like 10 years ago. Open source economics, again, just restating the stuff about like money, right? Like money is not really what matters, right? Money helps with some problems. If you want to come to my RubyGems talk later today, you'll hear me talk about how money creates some other problems. But what we want to use is the money to help the humans, right? So we can help the humans do the right things. Because ultimately, I think the scarcest resource in open source is maintainer, not even maintainer time, maintainer motivation, right? And if you have a project where the environment and the users and the support structure and whatever makes you go, this fucking sucks, I don't want to do this anymore, then that project will die very soon. Cool. So, how do you do that? Say no to things. Say no to most things, most of the time, right? Like chances are, unless you hear a feature request a bunch of times or you strongly disagree, you can say no. That's fine. You're allowed to do that. Because ultimately, you owe no one anything. Read the licenses of your software. It says pretty much, and I'm not a lawyer, so please don't do this. If I fuck up your shit on purpose, you still can't sue me because you agreed to the license. Again, I'm not a lawyer. Do not do this. So, what do we talk about today? Default to fast, right? Like performance, people care about it, particularly when other tools are faster than yours. It's not a bad idea to think about performance, even if you're just thinking about performance from the scope of what you do with support, right? Having a support reality that you can publish, and you can use that to set expectations. And then finally, optimize for the maintainers, because they are the people who keep your project alive. So, one change is enough, right? Just think about today, the projects you work on, what's something you could do to help one of these three things. Make something faster, maybe clarify, even if it's one sentence in your readme, what you support and what you don't. Or set a boundary for yourself or other maintainers for how you can better support yourself as a human. Hands up, who's going to be one of these three things in the next month? Some people put up their hand while saying no, which is confusing. If you have questions, I don't know if we've got time for any now. We don't. But send me an email. Go on my website. You can find how to contact me. And thank you very much for coming. Thank you. Thank you. Thank you.
27 January 2026
Interviewed by Screaming in the Cloud
Mike McQuaid explains how Homebrew grew from a side project into macOS’s de facto package manager and how the project is sustained today.
if you want to release a new version of your package or whatever we yes we have lots of automate update tooling or whatever that might pick that up but the process of like actually getting that out to users one of our humans is always looking at that and saying yes this looks fine welcome to screaming in the cloud i'm cory quinn and today's guest is one of those he or at least his work needs no introduction to most of us mike mcquade is the project leader for homebrew if you have not been become acquainted with homebrew you either have been living under a rock for 15 years or alternately you probably don't touch mac os which is like living under a rock for the last 15 years mike thank you for joining me thanks for having me here cory this episode is sponsored in part by my day job duck bill do you have a horrifying aws bill that can mean a lot of things predicting what it's going to be determining what it should be negotiating your next long-term contract with aws or just figuring out why it increasingly resembles a phone number but nobody seems to quite know why that is to learn more visit duckbillhq.com remember you can't duck the duck bill bill bill which my ceo reliably informs me is absolutely not our slogan and i feel like i just misstated already off to a great start because i've always used homebrew on a mac but apparently it supports linux as well uh as as a first party target operating system am i misunderstanding something here no it's yeah it's been doing that for a wee while a lot of people are surprised both that that happens and then generally the next reaction is why would you do such a thing like linux has a lot of perfectly functional package managers why would you bring your no it doesn't it has things like apt and yum and that would start replaced by dnf there's there's always a thing like uh it's like thomas jefferson once said that the tree of liberty must be refreshed with the blood of patriots and it feels like generationally we need to refresh package management with a new version to supplant the old one in linux distros every distribution i can think of has gone through this entire process and it shows no sign of stopping but what's the linux story for homebrew so the linux story for homebrew i guess it started out with being a bunch of people in bioinformatics labs who were like uh i don't have root so i can't use the system package manager and if i sort of like fiddle with homebrew enough then i can use it to install shit in my home directory and then like hey presto fast forward a while and a non-trivial number of people who use it and the kind of cross-platform nature is kind of appealing for some people because you can have the same package manager commands on mac and linux and ci and development perhaps and whatever and all that good stuff and then more recently we've actually seen like there's a couple of linux distros that do the whole like immutable root file system thing and then they use homebrew uh and flatpak as their kind of primary package manager basically and so that's that's been interesting seeing those like homebrew being mentioned on the front page of a linux distro that's a new development yeah for me it came back for a very simple starting point of once upon a time back in the day a thursday i believe was the day but that's neither here nor there and i wanted to i was trying to copy and paste a command off of stack overflow which was a best practice as is for many of us and wget wasn't installed on a mac and huh what's the best way to get this installed so first i went down the primrose path for a couple of years of playing around with mac ports because i am an old dsd saw and i don't believe that homebrew really existed back in those very early days but it was just night and day once i first encountered it uh and it had all the hallmarks of a terrible decision let's be honest here oh i just copy and paste this curl bash equivalent though we didn't call it back then into my terminal it'll just do all the magic things it needs to do and set it up from a security perspective it was something of a nightmare oh it'll just install the latest version of everything so what you run today and the new developer runs next week are going to be not exactly the same thing but it worked and i started using it extensively i became a i started doing some of the packaging for a few things back in the day for homebrew i'm running my own tap now with a couple of things that have now gotten enough traction that i probably should try submitting them to core and see what happens but everything i've ever really wanted what lives inside of homebrew and when i redid a laptop for the first time in a few years a month ago suddenly all the stuff that i installed that were that was graphic utilities live within casks which used to be its own separate thing and now seems to have more or less merged into mainline what's the history there yeah so casks were again you've probably clicked on if you haven't already been familiar with homebrew before this podcast that we like our beer metaphors over here uh this was partly because max the creator of homebrew uh conceived it while under the influence uh after being in a pub in london whining about package management and having his friends tell him presumably also under the influence well if you're so smart why don't you make your own package manager and turns out thank god usually those drunken belligerent conversations turn into and that's how i built a database engine so at least this one's novel yeah exactly exactly so casks were uh again you're seeing a bit of a running theme here like also a kind of side offshoot of homebrew where some people were like okay homebrew installs all your nice open source stuff uh but what if you could use it to just like download google chrome and put that on your machine or one password or any of these other things right yeah so basically like they were running their thing it got a bit of traction we noticed in the main project and we like brought those people over and merge the two projects essentially so that's been one of the nice things with the homebrew ecosystem is that over the years essentially when people do cool stuff that are like broadly in the ecosystem we try and like bring them into the fold and make it all official and part of our main thing which is a nice approach it's i've also found what i was looking at the submission requirements recently that if you have auto updating nonsense uh claude code is a good example of this uh it doesn't really belong in homebrew core that's what casks are for i guess how do you view doing an installation dance like that where at any given moment what is being installed on your system is not going to be what it was 10 minutes ago yeah i mean that's the fun of i guess homebrew package management you alluded to that earlier right we've always been i guess what you would call in package management nerd land aka my life a rolling release package manager and what you mean by that is like we whenever we get the newest version of stuff if it doesn't break humbrew itself we generally just foist that upon people right so in casks as you say there's some more extreme stuff where the cask itself can update auto update so humbrew doesn't necessarily even know the version of the cask that you have installed at this time but that we found that works a little bit better than you know a lot of tools like maybe claude code or google chrome or whatever nowadays that end up shipping their own auto update engine and it's like there are four releases a day in some cases yeah and we could try and fight that but again like i mean the homebrew in many ways like keeps after me in terms of like i'm exceptionally lazy right so it's like if there was some so say like debian right debian is a beautiful morally pure distro and on a lot of this stuff they're like well if there's like the kindest way you could have found to put that if they're like got an auto update or they're like yeah we'll patch out that auto updater and we'll just keep patching it out forever or whatever whereas i'm just like ah that sounds like a lot of work like that's what if if that's what the software project is trying to do let's try and find a place in our ecosystem that we can slot in and they can do things the way they want to do it and we can do things the way we want to do it and users can end up ultimately moderately happy yeah i prefer being able to do it through cask just because that way i don't have to crawl across half the internet to find stuff that i care about the only time i've run into trouble with it has been oh there's this thing that i want to install forgot i got it from the mac app store and that's where the license is tied to it so okay now i have to keep a separate exception list for that but oh well too bad so sad if you didn't know about this already i'm gonna i'm gonna transform your life here cory right so they're hit me with it please i'm about to redo this machine so tell me oh yeah oh yeah it's coming it's coming prepare yourself so homebrew has this thing called homebrew bundle which uses brew files right and it's loosely based off gem files in the ruby ecosystem order so what you can do in there is you can specify your taps your formula which are things that built from source supply by homebrew your casks your mac app store apps uh recently your go clis if you've got them your visual studio code plugins someone was proposing adding cargo the rust package manager support in there as well so that file lets you basically be like okay you can dump everything you have installed to that file and you can install everything on that file um and so you could have like a global wide thing i keep mine in my dot files and then i also have a little mini open source project the most successful thing i've created by myself called strap which is basically like the idea when you get a new computer you run this one script installs homebrew it looks on your github if it finds your dot files repo it pulls that down if there's a brew files inside it it installs from the brew file so you basically have like one command you can just run to basically like install all my stuff and get my all the software on my computer released back to where it was before right so hopefully this is gonna make your new build experience that bit more pleasurable than it currently yes and the counterpoint that i find here because i built a bunch of these things before this machine has been around for a while uh let me just for example run this now brew list pipe to wc-l i have 365 which is a suspicious number of packages installed on this thing so part of me like a lot of that is stuff i needed for weird one-offs that i no longer need i honestly on my laptop i have about i don't know 15 to 20 percent of that where it's i just because i just recently did that one and it'll eventually grow in time but i don't necessarily want to have all those things reinstalled part of the reason to do a fresh install is to get away from the legacy cruft i have something like four different ways of managing nvm on this system which is kind of a problem i want to start standardizing around which is the one that i've found that i like the most these days for python it's strictly uv system wide and so on and so forth asdf get rid of it because its ergonomics are terrible i can never remember which command parameter goes where and they're positionally dependent which is just wonderful simply wonderful i have opinions and i'm belligerent and i refuse to learn new things i am the worst engineer you've ever met it's great but also a typical one yes i wish i could say that that uh rant was not representative of the typical home brewery user but you you will fit in well with our community of people who do not like it when we change their shit i guess on that so while i'm evangelizing the why brew files will change your life right so if you run brew bungle dump which dumps all your things out one thing at least of that list of 365 is that it will only output the things that you have intentionally installed so anything that was not its dependencies a lot of dependency exactly unless you also intentionally install the dependency in which case that it will remember and know to do that as well so the little workflow i have after that like sounds like you have a you know a world of craziness to unpack but maybe on this new build if you're doing it from scratch then what i do is i have my brew file i keep that in my dot files directory which is a github repository and a locally checked out git repo and then what i do is i just install my stuff and then every so often i run brew bundle dump dash dash global and then i get my brew file in my dot files repo is like being nicely replaced and because it's a git repo i don't care that it's been replaced and then i look through the diff i do a little local review in my local git gui of choice fork which i would recommend very nice little git gui and then i'm basically like which of these do i want to keep which ways do i want to delete right so i stage it i commit the stuff that i want to keep and then i maybe get rid of the changes i don't want to keep and then after that i can then run brew bundle cleanup which will then use that brew file and then uninstall everything that is not present in that brew file so then i can get myself from a world into a world of chaos into a world of order and serene package management calm i like this quite a bit yeah honestly it's going through and like uh doing the dump on this okay i've got a whole lot of lines to delete in this like rust when the hell am i going to need rust well the next time i grab something opinionated off of github but until then i can enjoy not having to build a conference talk as a prerequisite for writing code you know basic stuff in life i've also seen homebrew itself over the years has changed significantly where just even the process behind it it auto updates now which i think is great your analytics i think have been handled in the most user respectable way possible the the fact itself updates only intermittently not every time you do stuff that's phenomenal it seems to have parallelized itself a lot better than it once did as far as downloads and installs go like someone has put some thought into this there's an entire there clearly is some sort of dag involved yes there definitely is the occasional thought that happens uh that results in a change uh several of the changes you mentioned are things that people still besmirch my name across the internet for for ramming home again against the interests of the users but the problem is with things like open source right is homebrew has we guesstimate about 10 million users from like analytics analysis stuff where like we don't have like we have opt-in uh sorry opt-out analytics not opt-in again another course of contention but you you can sort of infer that the vast majority of people opt out uh based on the download numbers from github's packages uh versus the numbers we get for analytics so that's our rough guesstimate so for those 10 million people based upon the sheer number of developers in the world most yeah maybe it may maybe that's maybe that is on the lower end but uh the number of people who essentially service their requests for those people are 30 maintainers right so when when you are dealing with that level of scale a all glory to the internet and open source for making that sort of scale even flipping possible but also you end up having to make nasty little compromises sometimes like say the auto update thing right lots of people really hate that but what it stopped was 95 of issues being this thing is broken run brew update does it still happen oh no it's fixed now right and there's only so many times you can uh respond to that and not write an auto updater before your brain just turns to pulp and my brain was starting to turn to pulp update bugs are the worst because how do you fix them well yeah that that's the other beauty yeah is when when you break the auto updater which i have done once that is a whole new world of pain as well where it's like but i i did everything you said i ran the updates uh yes but the updater is broken so you can't run the updater because the updater won't update the updates uh and neither will the auto update update the updaters to run the updates you have to run another update to update this so now whatever my mom with that her nothing was working in her browser anymore turned out it fell off the google chrome update path like four years beforehand and sadness yes and and this is why like i break out in hives anytime anyone submits a pull request changing that auto updater file because i'm just like are you sure are you sure you really want to do this do you really want to roll the dice and be the person that breaks the auto updater because i've been that person and it sucks yeah but uh suddenly on the plus side once you do that everyone knows your name one way to become famous or infamous i guess yes it's do you find that people tend to pin particular brew releases i'm sorry package releases inside of brew like oh always install this particular version of this package yes sometimes so we we have like a pin command that lets you do that but like the usability around that is kind of like meh only time i've ever used it has been in highly prescriptive here's how to install a dev environment in old school stuff before the advent of docker there's a bit of that and also like what we recommend nowadays is like there's we provide version packages for some stuff so if that's available so say like it used to just be there was just postgres right and if postgres got a new major version update and you wanted to sell an older version of postgres sucks to be you right like and then we had a slightly more middle ground now where it's like okay now we have postgres i forget the versioning scheme off the top of my head but whatever it is postgres 18 postgres at 18 postgres at 17 postgres at 16 right and you can choose to jump your way between those different packages right and for a lot of people for just installing postgres is the latest stable it depends i think postgres is a special case because we're still dealing with some issues there but in general yeah in situations where it's like i need this exact version i need postgres not 18 and not 18.1 and postgres 18.1.3 because that was the best version ever it's a particularly fine vintage that year then what we recommend in that situation is like there's a command called brew extract which then pulls uh postgres out of our repositories and then gives it in your own little github repository for a very specific version and you have ultimate control over that and you can choose what to do and then you can live in happy stable land so that that's generally what we recommend it's a little bit more work but we do provide a bunch of helper commands and whatever as you may notice again there's like a brew command to do just about everything right so like even within homebrew itself the way we run the project like we give our maintainers who are remain active 300 bucks a month uh if they are like regularly contributing to homebrew which probably contributes about as much money probably less than your average like paper boy or girl gets when they're 12 years old going around the neighborhood i think that's the going rate for open source maintainer nowadays so yeah not a lot of money but like we have to have a way of figuring out oh if someone was on away for three months like do they earn that or not so we have a command brew contributions which looks at the contributions of the various maintainers in that timestamp right so essentially almost all of our tooling by default is public right and that little tool i use to figure out who gets 300 bucks in a given month or quarter or whatever right anyone can use that and you can run that tool and in fact there was a bunch of brew i yelled at just now saying your token needs the read org scope to access this api there you go what a beautiful error message if i didn't say so myself at least tells me i don't have access to a thing which is great uh brew doctor spits out three pages of nonsense because i've had this machine for too long which tells me that if ever i need to report a bug against homebrew i've got some housekeeping to do first because everyone will blame this like unbrewed files in certain places from all the various things i've used apparently post grisqueal 14 is now deprecated huzzah some installed kegs have no formula which that's novel i don't know where those came from a bunch of casks are deprecated etc etc etc like this is what happens with five years of cruft yep effectively you've had your yearly health check and the doctor said how the hell are you still alive man your blood type is chunky yes yeah it's not going super well here it's so great it's time to wind up basically rebuilding things from scratch but that's that is the nature of the beast on some level i've also found historically that having a bunch of deprecated stuff or packages you didn't you installed then removed in some district some package managers can lead to security issues apparently for a while on one of my test boxes that i use as a dev box it used it set up a postgrisqueal user with a password postgrisqueal then i uninstalled the package the users hung out so suddenly i had a problem there nice yes yeah yeah i felt real smart after that one i've also found that you folks are quick to update where the day of a new mac os release suddenly i'll get error messages that i'm not i haven't out installed the latest version of xcode it's like well that's great it's been out for 20 minutes the mirrors themselves do not have it yet but it's already telling me that you need to update your stuff if you want to be supported it seems to have backed off from that jumping the gun mentality last few releases so someone's paying attention this episode is sponsored by my own company duck bill having trouble with your aws bill perhaps it's time to renegotiate a contract with them maybe you're just wondering how to predict what's going on in the wide world of aws well that's where duck bill comes in to help remember you can't duck the duck bill bill which i am reliably informed by my business partner is absolutely not our motto to learn more visit duckbillhq.com we try to be like aggressively chill right so because we're a bleeding edge package manager we tend to attract the users who have that so generally there's like a little almost like internal homebrew bingo about like how soon after the next mac os release gets announced and till until apple says the developer beta is coming until someone opens an issue on homebrew saying this doesn't work yet right like i think we've literally had about 20 minutes after the keynote ends someone's like yeah why is that why is this not working it's like because we haven't downloaded it yet you dummies like chill your boots like but yeah so we we tend to do a little bit of that ourselves where i guess we're maybe unlike some software where what we try and do is we're like we're gonna warn you about anything that might be a problem right and like if you're not getting any warnings from homebrew at all like you know that you have been a good little boy that day right and or have not properly installed homebrew or not properly installed homebrew indeed but yeah so like our kind of like brew doctor command i feel like we were one of the first things to do that like what we're trying to do is provide it was the first time i encountered it back then most other things called it pre-flight yeah exactly so we just try and provide a lot of pointers for like look if something's broken and someone's not particularly in the early days of homebrew it's like maybe no one's awake to help you right and you want to get this fixed in the next 12 hours so here's some stuff you can try right like i mean i used to be a uh part of the cent os project this was back when i was free node network staff irc was the way that i encountered a lot of the stuff and got support for it and there's one thing that i learned and that is people are freaking terrible at asking for help in ways that make sense so having a doctor command that will identify all the issues with it and it's almost it's close cousin to a diag uh spit out where it's like okay what version of mac os oh wow i didn't realize numbers went that low what else is going on with this system that otherwise i'd have to tease out of people over a period of hours as they start trying to figure out how their system was put together yeah it's funny so like github has homebrew is one of the first users of like the github issue templates right where you have like mandatory information you have to fill in but part of the reason i think github even has them is because when i was a github employee i whined about wanting those templates so incessantly that i feel eventually someone just gave up and was like right mike if it will make you shut up we'll build these stupid issue templates and no one's going to use them and then turns out everyone uses them but anyway so like terrific gen ai use case too uh that's exactly what i was going to say yeah like so we we found we found them great for that because so our and again our issue template was basically based off and i used to have like a text expanded shortcut literally for co-workers when people would basically ask me for help in a very unhelpful way and be like okay what did you do what did you think was going to happen what actually happened tell me what i can run to see the same thing on my machine right and if you could do those four things then like hey we've got a great bug report and also as you say like for gen ai if you could say the same thing like a lot of the time like copilot will like one shot though if it's completely 100 reproducible and it's well explained in the issue like copilot can go okay run this command got this output change some code run this command until it gets the right output and then ta-da here you go there's a pr and the code quality might be garbage but like often it it gets a decent amount of the way there if it has a good template part of that is the stuff you never see because i used to do that by hand a friend ran ask me better.com which asked those exact questions there was no real submit button on it but by the time that you wrote that out and came up with a repro case you realized you were the one that forgot a comma or something weird had happened and oh i misread the documentation like the best requests for help that i've ever written are the ones i never submitted anywhere because it solved my problem going through that process 100% and that's that's a big part of the goal as well like and ironically the people that find those flows to be overly prescriptive are often the same people who if they slow down and read the flow they might have avoided having that issue in the first place what's the security posture on this stuff look like i mean i know that at this point enough people use homebrew that if i can compromise the wget package for example suddenly everyone's going to run the code that i want them to run what are the safeguards on this i know that uh pi pi pi pi pi pi however they pronounce it i get yelled at if i say the wrong one but i can't remember which is which uh they have an entire security team that looks at this pp right yeah that's what i'm gonna go with that i'm sure that mike fiedler who runs that will not punch me in the mouth the next time yeah so like we're lucky in homebrew land in that our trust model is very different to pi pi pp whatever we call it npm ruby gems etc right so those package managers fundamentally have a trust model of we will trust people to do some verification of the people whose stuff they download right and we will not be a gatekeeper middleman whatever unless it's like gratuitously obvious that this is malware or whatever right there i'm sure some of those folks would say that's a gratuitous simplification and i'm being very mean and unfair or whatever but oh well that's that's me whereas in homebrew every single change that happens in homebrew a human homebrew maintainer has to verify that reviews the code and says this looks okay right so if you want to release a new version of your package or whatever we yes we have lots of automate update tooling or whatever that might pick that up but the process of like actually getting that out to users one of our humans is always looking at that and saying yes this looks fine right and same deal with the way we kind of build packages and things like that like we operate our ci like we were pretty early to the party of having essentially binary packages built from users pull requests on gilb and then just deployed straight out to users right with again with human intervention but like as a result of that we have built everything with a trust model that essentially you can't trust anything ever right and all of our ci workflows essentially treat even the code they're running most of the time as like untrusted input right so we generate you know for example when we generate a binary package we then generate json that describes the binary package and then later we read the json because you can't embed arbitrary executable code in the json like you can in the ruby files yeah exactly challenge accepted anyone but yeah so like that's what we try and do so like our our trust model and we are lucky enough careful enough whatever it may be to touch wood have not had any major attacker driven security vulnerabilities i guess if you go through the humbrew blog you can see we've disclosed things in the past i think our worst one was based on a jenkins misconfiguration which was it called jenkins yeah well so that's one of the reasons why we don't use jenkins anymore because jenkins misconfiguration was uh rather easy to achieve i would say but yeah like generally we i think we've had a fairly good track record on this stuff and obviously as i think homebrew may have been the first project to create the curl to bash pattern right so people are going to hate us forever for that but i think in terms of actually user experience security problems as opposed to just people in the security community shouting at us and calling us morons security problems i think we're doing all right i do want to ask uh before we call this an episode about your approach to open source i mean the triggering event that's oh yeah i should really talk to you about this uh was a linkedin shit post that i did uh somewhat recently about the experience i had when i did a brew install terraform and it's a great this is an old version because the new versions are not open source licensed sspl is not open source or busl whatever the hell they're using and i thought that was a terrific position to take some people are whiny about it and i honestly don't care about them because if why don't you do volunteer work for an ibm subsidiary is one of the dumbest things i can think of to ask you yeah so i mean our our view on this is so what we say in homebrew is we have homebrew core which was our kind of original package manager like open source stuff we did and at some point we're like okay we say we only package open source stuff in here what do we actually mean when we say that the nicest definition we came across was the debian free software guidelines right and they are not as it might sound like if you're not someone deeply versed with open source or free software whatever essentially everything within their description is open source and it's a nice clear definition of things right and there we have a body called the osi who we also look to for the advice who were the one essentially the body that came up with the term open source back in the day and i have the controversial viewpoint that words mean things and it's a good idea to make words continue to mean things such as don't say literally when you don't mean literally and i will die on that figuratively is the word you're grasping for and exactly yes so with open source we have rules on this stuff and when various companies lately have decided to i guess hatchet corpse projects as example one maybe redis maybe elastic search maybe mongodb when they as vc-backed businesses decide that their business model is not well suited by their current open source license that they have just happened to rely on to get a enormous amount of adoption over the last decade right and they decide that they're going to change that and relicense everyone's contributions over that period because they were foresighted enough to require everyone to sign over their copyright which allows them to do that instantly homebrew various other projects do not do that then what that means is that they can do as you described in that linkedin post a rug pull and everyone's left going well wait a minute is this open source anymore and the companies much to my chagrin will say yeah oh yes yes this is this is totally so we're just it's just open source but uh if you want to make any money then you need to give us all your all of your money but i mean other than that it's completely open source right like it's fine but again as i say when words mean things it's like well in open source you don't get to do that right and i had a lovely conversation i will not volunteer for your for-profit enterprise because i won't let people volunteer for mine uh when i contribute to open source it is open source to which i am contributing honestly sometimes to that project's detriment because i'm terrible at it but you know i it's not for lack of caring and it's not for lack of philosophical purity it's there's a there's a sense that there are things i will volunteer my time and energy for and there are things i will do with a hope of making money out of it and i try not to cross those streams yep and i i think that's very wise right like i i was on a podcast recently with friend justin searls and i was kind of cross posted to the changelog in which i said like open source is not a career right like open source is not a business model open source is also not a career right and i think we have seen a bunch of people conflate these ideas that you need to pay all open source maintainers a market rate tomorrow otherwise it will not be sustainable and similarly with companies a company should be able to just release open source software not charge anyone any money forever and then like when they get upset that that is not a viable business model they can change their license and point at the big cloud vendors and say like wow they're they're stealing our stuff and it's like well they're stealing your stuff because you said it could be taken that's what that's what your license says back when there's a new york times article about amazon strip mining open source like that that's not accurate to my mind they are doing nothing wrong you can talk about whether they should be contributing back but that's one of those uh appealing to our better angels that is not one of those if they have an obligation to do so now i mean amazon does not do philanthropy let's be honest with ourselves they're amazon they don't know what that word means but so okay the problem that these companies made is early on and i i have some sympathy for it was in 2010 or so well we wrote the code clearly we'll be the best ones to run it as a service that didn't pan out now you have people starting open source based companies and they want all the benefits of open source without any of the drawbacks like oh should never have launched that project with an open source license yeah but no one would have used it if you hadn't so what's the story and the way i like to deal with this instead right is again blog post i wrote a long time ago a lot of people don't like me for it but a bunch of open source maintainers do so worth it uh that i titled open source maintainers owe you nothing and if you read any open source license it essentially says hey look if you use my open source and it breaks your computer on purpose then sorry you've agreed in using it that you waive me of all responsibility for that so tough luck right and to me the way if you say you know say amazon right amazon's strip money on my own source they're using this stuff well what you can do is just if anyone who's an amazon employee ever submits an issue in your project you can go close and say i don't want to fix that your company has lots of resources they can do what they want with their open source project i'm not going to help them right you can choose to not accept issues you can choose to not accept pull requests you can choose to not respond to anyone from amazon on your issue tracker ever again if that's what you want to do and you as an open source maintainer have the right to do whatever the hell you want and that's this is the beauty of it right and i think this is the problem job i've got to take the other side of it where most of the stuff i write these days i used to open source all of it because why wouldn't i i'm sorry but this way to wind up running a command simultaneously on 15 nodes at once uh in every aws region that's not a competitive differentiator that's just something i want to exist so other people can use it these days i'll write quick one-offs and i just i'll keep it in a private repo rather than open sourcing it just because i don't want to hear it from people yeah yeah because the level of entitlement is often crazy and this is a yolo coded thing in half an hour or so i just want it to work great i know that you have other use cases for it go with god have fun but i don't want to hear about it i don't care vibe code it yourself yeah and my code should mostly be told it's a cautionary tale the thing is as well as often the people are the most entitled about it ironically are often the people who are the most reliant on your free gift for them to do their job i remember one time we upgraded a version of ffmpeg or changed the codec or something in homebrew right and someone said like i'm running my entire business off this and you people have just broken my entire business like have you no shame and i was basically like sir have you no staging environment like you have learned a lesson today about relying on other people's software given freely if you're literally running brew update and brew upgrade and that hoses your entire company this is what we call a you problem sir and not a me problem i didn't tell you to do that you decided to do that and now your stuff's broken like right if you're running latest or any other bleeding edge package manager in production it's just a matter of time yeah and in some ways again this this comes back to what you're saying about the you know well we built it we should be the best to run it in production it's like well no like you've demonstrated your ability of being very good at running a database open source project you did not demonstrate your ability to provide a multi-region multi-culture like massively scalable cloud provider right which is essentially what if you're offering a hosted database provider in 2025 that's what you're doing right and chances are aws is probably quite good at that they probably have quite a lot of people who are quite good at that and again like sorry folks this is capitalism i don't feel bad that you as a company trying to make lots of money picked a fight with another company who are also trying to make lots of money and you didn't win like you don't get more sympathy because your code happens to be open source right oh for me it's there's a reason this entire conversation for the last half hour has been about what we do on developer workstations i have asked you none of the normal questions i would if you were building a package manager aimed at you know production environments because i have a whole different laundry list of this the closest i run into this is as i mentioned earlier well the next developer we hire is going to have slightly different versions of everything in their environment theoretically i really do hope that the people are updating their packages on a consistent basis which brings me to my last question for you here have you ever given thought to having brew auto update on a schedule both itself as well as the packages that have been installed from it yeah so there's actually again a nice little external command for this which was briefly in the humbrew ecosystem and then we decided it operated better independently elsewhere uh by then it's not your problem sort of yeah by a lovely chap called dom who used to be a homebrew maintainer and it's called homebrew auto update if you search for that and yeah you could basically have that as a cron job that basically every night just in the background will just bulk upgrade everything on your machine right and if that's how you want to do it then that's how you can do it right again another happy middle ground on there which i quite liked is if you say using something like brew bundle uh like i mentioned before then you can have brew bundle by default will upgrade all your packages so if you have a project say with your co-workers at work right say you are relying on mysql and rust and javascript being installed in this like particular project right you can have a brew file in your repo root that has those packages in them and then if someone runs it then it'll upgrade everything and then okay you might have someone else on the team who's in an inconsistent state but then they they can just run the same command and they will get to the same state so that the state is based on time rather than by based on a lock file but you can still get some degree of consistency there and also what you could do which is what i tend to do in those situations if you want to be like a step ahead say people are not running upgrade relatively often or you're you have an onboarding flow or whatever and you don't want it to break you can set up a github actions job with a mac os runner that just runs that every night and then when it fails it opens an issue or sends someone an email or whatever and then you know oh like something in homebrew got upgraded and now we need to go fix that right and you can deal with that when you choose to rather than just like being like oh some particular developer ran a particular thing at a particular time no like come on people like we we have ways of solving these types of problems with reproducible environments which you can do with github actions ta-da problem solved it's it's a fantastic tool i want to thank you for spending as much time as you do on getting it to work if people want to learn more where's the best place for them to go uh more about homebrew you can go to brew.sh um our lovely domain if you are interested in the code or contributing then that will also take you to the homebrew github repo which tells you all about getting involved if people want to see more about me and my ramblings on open source and other things then they can go to my website at mike mcquade.com which links out to all my other internet presences and we will of course put links to all of this in the show notes thank you so much for taking the time to speak with me i appreciate it thank you for having me cory a delight mike mcquade project leader at homebrew i'm cloud economist cory quinn and this is screaming in the cloud if you've enjoyed this podcast please leave a five-star review on your podcast platform of choice whereas if you hated this podcast episode please leave a five-star review on your podcast platform of choice along with an entitled whiny comment that we'll never see because that platform wound up having their entire stuff go down because someone ran a brew install without any idea of pinning or the fact that this is not how one should run production as a responsible grown-up
24 January 2026
Minimum Viable Management
David Yee, VP of Engineering at The New York Times and head of its new AI platforms and products mission, joins Mike McQuaid and Neha Batra for a candid, behind-the-scenes conversation about why institutions are built to resist change and what to do about it. They dig into hidden norms, choosing the right battles, translating “how things really work” and creating stability for teams while you deliberately destabilize the system just enough to move it forward.
Hello, everyone. Welcome back. Hello, Neha. How are you today? I'm good. How are you? Very good. Thank you. We have another special guest with us today. Neha, would you like to introduce our special guest, David? Yes. Yes. This is David Yee. He's a VP of Engineering at New York Times. I'll let him say his title. But David and I got to know each other through the lead dev circuit. And because we're both kind of involved on speaking and stuff, but really, it's more of a meeting of minds. I'm really excited to have him here because we're going to transparently lay out some of the conversations we've been having behind the scenes. We tend to joke that some of our conversations are like stuff that you usually don't necessarily want to say on stage, but it's like about how to get things done, actually. So anyway, it's really nice to have someone else out there who is willing to just drop all the formalities and the, you know, the quips and whatever and just talk about how to actually get things done. And so that's why I'm really excited to have David. Do you want to introduce yourself with your former title or whatever on at New York Times? Yeah. Hi, I'm David. I'm also super psyched to be here. My title recently changed. I'm still VP of Engineering at the New York Times. I am now the head of engineering for the new AI platforms and products mission. It's a mission that's sort of coming into coming into existence recently at the New York Times. And we're building products that are sort of user-facing, reader-facing, that use large language models and the platforms to make it easier for engineers to build them. Yeah, this is going to be fun. It's the sort of transition from quiet conversations to sort of like thinking out loud about the kinds of stuff you can't say on stage. So I'm mostly just excited to be here. Yeah, I feel like my favorite stuff that we talk about is like how to get shit done. And I remember recently when we were talking, we were talking about how to get shit done. When and like, why is that so hard? And why is that a full-time job? And one of the things that you were starting to talk about was that, well, to be clear, like when you are trying to change something at an institution, right? It's job is to not change. And so like you're basically rolling a ball uphill or what is it? A boulder, a boulder uphill. And of course, it's going to be hard. And of course, it's like not natural because you're trying to introduce something unnatural to the environment. So I was curious if you've had any more thoughts around that since like we kind of went really deep into it. And I feel like that's something that a lot of people need to hear about is just like, OK, this is the fact of the matter. Like, of course, it's not easy because of these reasons. Yeah. So I think so. I've been at the New York just for some broader context. Like I've been at the New York Times for almost eight years. I've worked in startups. I've worked in sort of smaller media organizations. But and so just for some context, in terms of New York Times, it's roughly 500 engineer space. So it's smaller than some, bigger than others. But just like from the perspective of size, that's sort of one place to place it. But it is also like this year, 175 years old as a as a institution since. Yeah, that's an institution. Yeah. And it's and it's what we would call its most recent incarnation. Right. Like, so that's like the New York Times preexisted, preexisted that. But like at the time of Adolf Fox bought it and turned it into the newspaper that, you know, that everybody in New York reads and everybody in the world reads, you know, that institution has been around for a really long time. And so, yeah, I think when you and I have talked about it and I think the context that I that I give a lot of people who are starting out at the New York Times is based on essentially a reflection on the first two or three years I was at the Times when I was constantly like, you brought me here. Like with this sort of sort of quasi narcissistic, maybe typically narcissistic engineer view of like what it's like to join an organization and say, well, you brought me here to you wanted me to make more me's. You want me to change this organization. Why are you making it so hard? And I think and I think maybe it's only in the last year or two that I've come to really understand that like actually the whole point to what you said, the whole point is that it's hard, that there are a few different ways you can change the organization. But expectations, being honest about expectations with an institution is like that's my whole new thing. That's like when I talk to engineering managers joining the organization, when I talk to senior leaders joining the organization is this idea that says like you really are going to have to pick your fight. Because you don't you don't get to you don't get to like run roughshod over the whole thing. I feel like what's really interesting is, OK, cool, that makes sense for like a large institution, something that's been around for a long time. But like what happens with a small company? Because like I've recently started a new company, Motif, and so that's a small company. And Mike is also at a small company. Right. And like something, you know, there is something about like there may not be an institution, but you're inheriting some sort of culture and some sort of like a natural way of going. And it probably is based on the leaders of the company. Right. And for both Mike and I, we enter into a company and then therefore change the dynamic because we are potentially changing the institution itself. Because now I guess like there is the leaders of the company before, then you enter in and you become part of leadership. And then now from now on, you are influencing the leadership as well. So I was curious, Mike, like, have you experienced that feeling of an institution and then feeling about how it changed and, you know, people pinning their hopes on you and also you feeling like how much influence you could have over this institution? Yeah, I feel it's like in some ways a blessing and a curse, right? Being the new person to come in, like particularly if you're kind of coming in as a leader, right? Like the classic one I always think about as an engineer is like the onboarding docs or process where lots of people, I mean, generally, almost every engineer I know who's coming at almost every time. There's been something in the onboarding process that makes you go like, oh, why are we doing it that way? Right. And then give it a week, a month, six months, a year. And then you're the person being like, no, actually, there's a really good reason for that. And if you change it, then everything will fall over. Right. And I think that's, that's the thing that I find really fun, but also really hard, like knowing that my gut's going to have that adverse reaction to perhaps almost everything and almost being like, well, which are the ones that actually stick with me? The team seems to agree and seems to actually have a basis or maybe we like tweak it and things get a little bit better versus we tweak it and everything falls over and everyone starts crying. So, yeah, like, I guess that's, that's been my experience. I feel like what's interesting is that like, so David and Mike, both of you kind of talked about like the journey of like getting familiar with the company. Right. And so it's like, starts with like, I know everything. And then it's like, wait a minute, I know nothing. Right. And then it's like, okay, can I do something about it? And like, what can I do? And then you start to experiment around, you start to like, you know, knock on the different Jenga blocks and figure out what you can pull out. And then you're like, okay, I know what it takes to get it done. And then, you know, and then you like become matrix informed and you're like, okay, I see the whole matrix. I see how things are interrelated. I can do anything, but what should I do and at what cost? Right. And so I feel like if you've done it enough times, you know, that you're about to go through that journey. I think every step of that journey is important. You can't skip a step. And I also think that that first part where you're like, wait, why is this the way it is? I think it's a very precious and important step. Like, I don't think we should all impose all of our opinions on other people, but I feel like hearing that if you don't have like fresh people coming in who are questioning the way things are, then like essentially you're like stuck with every single inherited constraint so far and like you don't notice whether constraints have changed. And so I think it's a precious step to like be like question all constraints without ruining the institution and also like increasing unhappiness about constraints that you can't change. So anyway, that's like kind of I was like observing both of you are talking about your journeys and it's like it's a necessary part of being familiar with a company. So as you were talking, I was kind of thinking and like I don't know that I feel super comfortable with this analogy, but it feels a lot like dating. And so I think there's like, oh, can I change? Like, I don't really like is that how they brush their teeth? Like, you know, is there any way I could change that or like, you know, how much do I care about it? It does annoy me. Yeah. Exactly. Is this a fight that I want is a battle I want to fight? And as I thought of that, I was like, I don't think that people I don't think that most workers try to think about institutions as individual people as much as they should. Like, this is this is I think like what people often think about is like it's the CEO or it's like the CTO or this particular leader or that particular leader is just messing me up. And like you come in like certainly like I totally know exactly like how you think about it, Mike, when you walk into an organization, you're like, I don't like this. Whose idea was this? And like they are misguided. It's like it's like these this person, these people, but different to what I think people expect at a startup. And I'm really curious what you all think about smaller companies since you're both at much smaller companies, presumably than I am now. But like what I've come to learn about institutions working at a larger company is like it is very much like what they it's very much like the positioning that like the British royal family makes, which is it's not the queen. It's the crown and like an institution is an entity. It is an entity that has behaviors and flaws and preferences. And it is as as one of the people you're going to date in your lifetime. You know, the longer that they've been alive, the more hidebound they are about changing. And so, yeah, like I think if there was anything I wish I had known eight or 10 years ago, whatever, it would be that to actually really consider the personality of an organization as a real thing, like not as an imagined contract, but as a real thing because it is. Yeah, I think that's a helpful way of framing it. I like that. I like that approach because I feel like I've seen stuff with coworkers past and present. I'm sure I'll see it in the future as well, where people behave at work in a completely different way to how they do anywhere else in their life. Because that's how the organization and the culture or whatever has taught them to do. And I mean, sometimes you even forget there's like a particular name for this. But like sometimes I feel like you sometimes see this psychological thing where literally everyone is behaving in a way that no one really likes. But everyone thinks that everyone else will freak out if they don't behave that way because that's what the culture is and that's what the stage is, right? And the place I'm at right now is really interesting because it's been around for like 10 plus years and it's got a very high average tenure, but it's still a pretty small organization, you know, like 40, 50 people. And I find it kind of fascinating because everywhere I've been before has been either this size or smaller, but much like a much newer organization or a much bigger and older organization. So I feel like it's taught me a lot in that respect about kind of culture and maybe like inertia and also like what you can do as the outsider when you come in and those moments where you do notice that like I feel like maybe no one wants to do this and everyone's just doing it because they think they have to. And then you can give them permission to be like, look, let's all try not doing this for a week. If it all falls over, that's my fault. Like the CEO will tell me off and then we try it and then it doesn't fall over and then everyone's happy and you're like, great, right? And then sometimes you do it and it's a disaster and everyone's unhappy, you know, it's I wish I could predict in advance 100% accuracy which one would be which, but try and ever, I guess. I think what you mentioned about like people being a little bit different than like what they normally are like, right? And maybe not even liking who they've become, it's like must be some sort of average between the institution and the individual, right? Or like some sort of compromise between the two and the longer that you've been there, you have to adopt some sort of compromises to be different from who you are in order to stay there and to sustain and to essentially like find an identity. And, you know, if our job is to bring in change and our job is to push us forward or our job is to help the company adapt to new conditions, then like, first of all, that's easiest when you're new, right? You're new, you can kind of like take the blame and you can take a few hits. And also you don't have that established reputation at the institution and like that sort of brand that people expect from you. And so you can kind of jump out of that. But if you're not that, then, you know, you still have a responsibility as a leader to introduce that change and to find a way to break the mold and to give people a space and some place of comfortability to try something new. And I think that that comes back to what you were saying, Mike, which is like taking on the risk for the team. So, OK, cool. We have to change something. Everyone else is very used to the way things are done, especially at a 10-year-old company, a 20-year-old company. People who have been at the company for 10 years, 20 years, et cetera, right? They're stuck in a certain way. Everyone wants to change. You have to be the one to kind of take on that risk and give people permission and find a way to introduce something different, right? Yeah, like, I guess a question for David, like, well, I mean, it's kind of wild when you think of an organization that's like hundreds of years old. And obviously, the engineering organization is, I would imagine, not yet hundreds of years old. I mean, have you got examples of any cultural things that you have that maybe have gone way, way farther back than what you might have expected or anticipated? It's so old that it's hard to tell. I think there's probably, there's a ton, right? And like, some of them are just, some of them are just, they make a ton of sense when you actually look at what the organization does and what the institute, not even the organization, the institution, right? The 175-year institution values. And then you try to imagine overlaying the culture of, you know, the Silicon Valley company over that. And you're like, there's some things that are just like directly opposed. So, so the two things I can think about that are really interesting. And like, I sometimes say that, so the job I had before this, which was now years ago, was at Vox Media. And the New York Times is different from Vox Media because Vox Media was effectively, it started essentially as a sports blog company, right? So all of SB Nation was where Vox Media started. And so SB Nation and Vox Media were essentially like a digital product organization. Like they built a CMS called Chorus, which, you know, 10 years ago was like famous in the media and journalism industry for being this amazing content management system that everybody wanted to have and everybody wanted to know what it was. And so they built these newsrooms, they built The Verge, they built Vox.com, like all of the sort of companies, all the brands that Vox Media has or had were built on top of a product organization. So you had a bunch of journalists who essentially worked for a digital product organization. The New York Times is exactly the opposite. New York Times is a newsroom that is 175 years old, that has all of the history, all of the mistakes, all of the pattern matching of that organization. And everybody in the world knows that newsroom and it has a digital product organization built on top of it. And for years, like there was this question about, if you think about just content management systems, so digital content management system, there was this question of does the digital report chase the print report or does the print report chase the digital report? And there was a moment at which the literally the content management system of record became the digital one and not the one that was generating the print report because they've used computers and content management for the print report for a long time. And so there are a couple of moments like that where where you've actually had to watch the organization say the thing that moves fast, the thing that is more unpredictable, the thing that is read by people by different people to the people who subscribe to the newspaper is now the paper of record. And that was that was that was a huge shift. But the Times is deliberate, right? So when every year they have they announced the Pulitzer Prize, this is a really big thing at the New York Times and not to toot the New York Times's horn, but we do frequently win Pulitzer Prizes. And so like everybody piles into the middle of the newsroom, which is a sort of big open atrium, this two floor atrium and the executive editor, Joe Kahn, stands on the stairs in that atrium and announces all of the whoever has won a Pulitzer Prize. And then there's a whole litany of people who come up and talk about it, including the person who's done the writing or the photography or the editing, you know, all of and there's frequently dozens of people attached to any given prize. And it is not uncommon to be in that room and hear the person receiving the prize say this was this was a piece of work that was seven years in the making. Imagine if you took seven years to deliver a meaningful software product, right? No, it would never happen. Like it would never 18 months. Like we ran out of money. It's not going to happen. But like at the New York Times, they are willing to take the time to do two things. To be right on the facts and to do impactful reporting, sometimes on the order of years. What does that mean for, again, for the digital product organization? It means that sometimes, like even though in journalism companies, there's a split between the newsroom and the business that's really important to maintain, where one side really doesn't talk to the other by design to make sure that the reporting stays clear. Every once in a while, a cultural precept crosses that boundary. And so you can find yourself frequently debating small truths about a software product or about a product that you're going to deliver to your users. An engineer who's come in and worked at a faster moving place, as indeed I was when I first got there, can sometimes say, why are we talking about this? But it is because the institution has that behavior and culture. So like Mike, when you're talking about it, it's like you see people behaving differently. Like you can actually track how somebody's decision-making process changes as they become more adapted to and malleable to the practices of this organization in that way. And it's not bad, per se. It really isn't. It's just it's different to what we expect if we are engineers coming out of, you know, fast-moving startups. And there are reasons for it that you can question all day long, but ain't going to change. Well, this kind of comes into like constraints, right? So it's like there's like real-life constraints about like how humans work, about like how technology works, about how the news works. Then there's like company constraints, right? And then if you want to prevent yourself from burning out, you need to be realistic about like what constraints there are and then like where the chances are for opportunity for change, right? And also potentially at a place that's like so polar opposite in terms of rate of change, right? You almost have to like stay tuned into like what the rate of change is in the software world when you're like going, when you are trying to complement an institution that's like used to a lower rate of change and you have to like stay in tune on your own in order to drive that pace and to adhere to that pace. So like how do you know which constraints to like listen to and which not to and how do you identify opportunities for change if like an institution is used to going slower but still kind of demands you to go faster and doesn't know how to reconcile that without you? It's like the I got into a conversation with a colleague of mine earlier this week about norms because I said look we're spinning up this whole new mission so it's great like you know you know forming storming norming performing right so like what are we going to do like well let's just start with norming and I was like I was like you can do that but like you know if you're going to do it you have to be real honest about where we're starting right? Right and the my one of my favorite trips is like to look at an organization stated norms and be like okay what two are missing from this because it's like and that's actually the most important the most important norms are missing I feel like from the written norms or they're or they're the they're the flip side of a norm right? So it's like we are agile um we're like and this is I'm just imagining a norm for a company this is we're agile right you flip it it's like okay we're reckless right um or we're deliberate we're slow right and and it's not like one is true and one's not true it's just there's two different interpretations of that so the first I don't know I'm really curious what the two of you think because like for my for my part I think most most organizations and certainly institutions go way out of their way not to tell you and not to signal which things are movable and which things are immovable because like if everybody just knew the things that could be moved the rate like there's a limited taste even for that and so I'm curious like what you two have seen when you've thought about how to determine what things can be changed and what things can't be changed yeah Mike you want to go first yeah I was gonna say I can definitely relate to that sense that like both the norms that are missing and also the kind of I always love that saying that essentially I'm gonna paraphrase terribly but like you know your biggest strength is generally your biggest weakness right and that applies for like teams and cultures and organizations as well and also just I think the nice thing that we have in engineering right is we have a culture of trade-offs where so many almost maybe every choice is like look there's not a right or wrong answer here there's just if you do this this is the variables that are going to be good if you do this these are the variables that are going to be good and I guess like something I've kind of liked to do with the norms is when I see a problem or whatever and I see the cultural norms or whatever is I will try and do it the way the organization states that it's meant to be done and assume that all the stated norms are correct and maybe the unstated norms are not or whatever and then when that doesn't work then sometimes I'm just like well either I give up or I sort of like just try a different approach right so like you know for example I'm trying to think of a good one that I can actually say for example like a company that says like we like to do all our communication in the public right but then in the public people just don't say things because they don't feel comfortable doing in the public and then so you then you create a private space and then people say things and it's like well the stated norm perhaps or the value was like we believe in public communication but then the unstated one was like and if you can't say it publicly don't say it at all right whereas that's there's maybe like a higher one there where it's like well actually like we would rather you said it in public but if you can't it's better that you say it privately and we resolve the problems and whatever whatever and again like I feel like sometimes when you can those unstated ones that you made the point David but like when you can say them out loud and stuff it's like well which is more important that we don't use private slack channels or we deliver value to our customers right and that's like basically obvious in every company right unless it was organization would not put it that way but like often that's not the way people think about it or frame it or whatever and it sometimes does take an outsider to frame it like that for people to be like yeah like that when you put it like that when you put it like that it's kind of obvious the choice we're making and it's obvious maybe things need to change or whatever and then I guess my final point like Neha saw me doing this a bunch at github is like sometimes I'll just be like oh the organization says not to do this and I have no consensus or agreement I'm just going to do it and see what happens I'm prepared for like the entire organization to jump on me and say no Mike don't do it that way and then I'm like cool I learned the norm like I will undo we will return return to you know a state of calm and then sometimes it's the other way around where people like are like oh well we were just waiting for someone to kind of take the first step but yeah what about you Neha like what's your I mean I think what's interesting about what you're saying is like if you are coming in and you're on a new team you're establishing a new culture or you're just trying to learn the way of the ropes and there are established norms or stated norms the test balloon is just trusting it and then seeing how far you get to what you're actually optimizing for which is progress or delivering value to the customer or whatever and when you don't deliver value to the customer then you start to debug and then you start to learn about like what is actually missing and people will kind of come out of the woodwork and be like okay well if you actually want to get things done then this is what you do now as a manager as you're bringing in new people if you want to help your individuals your peers your manager get things done you then attempt to help them understand okay we write this norm but like if you want to get things done you can get them done faster this way and you are the cultural translator of those norms but all of that goes into reinforcing the norm when it comes to changing the norm right like you have a few options you can like this is why especially for leaders organizational design is so important understanding understanding what you're trying to understand what you're trying to understand what you're trying to do and then understanding what is the natural gravitational pull for the people that you're working with which is essentially the institution of like what your team is right and understanding what the difference is if you need to change it one of your options is to change around the people AI is like AI is changing one of the things that we're used to which is the rate of change of information and also how like we don't have a lot of clarity as to like what we want the outcome to be because of the rate of change of technology so you need people who are comfortable with ambiguity and energized by the rate of change right progress needs to be something that like they get energized by like they get energized by and stability needs to be something that they're they rely on less and so by changing those uh you know by introducing new people introducing fresh blood or finding the people who are most energized by that you might have a chance to make a little bit more progress against the institution in order to accomplish the goal and then the other piece that i've been i just started thinking about especially at my current organization is if you need to introduce change as a mandate from above or if you need to introduce change change as a mandate from above or as because of the needs of the business or their customer chances are you're changing a norm that is going to be uncomfortable for people and that is a destabilization for engineers whose job it is to stabilize a system a lot of engineers who create stability crave stability if you are going to and have to destabilize then you need to provide a different avenue for stability so that they have something as you destabilize the thing that they used to derive stability from and understanding what people derive stability from and how much they need in order to make the progress that you need to make progress on gives you the new world of like what you could try to stabilize you don't know necessarily the right answer but you have options now and you have you can see the world a little bit more clearly behind the like the current set of things and what people say and more about the norms and more about the norms and the institution and all those layers behind which is like what we spent this entire podcast talking about is all of those layers and how they like pile on top of each other so anyway that's like what you all made me think about today um and like what this conversation kind of like understanding how do you make change happen if like the gravitational pull of an institution is to stay the way it is right I was thinking this week about like the job of a manager versus the job of a director or a manager of managers is being like the most wonderful and difficult thing about being a line manager is that you have expressed in four to ten people the boundary line between the boundary line between the abstraction that is the business and the reality that is people and uh and so exactly exactly what you're talking about in terms of like the destabilization of folks on the ground is like you're giving that to the people who have the least like in general the least experience in the business and and you're asking them to hold that right that they're the bonds they're the bonds between sort of like two dodge chargers that are like pulling in opposite directions you know in fifth gear right so i think that the the the thing that i so i am very lucky in that like for a little while i get to manage engineers like for a very little while i get to manage engineers and i and i love it it's like it's like candy canes for me it's like it's perfect because i get to say the thing that i never say which is on an engineering team every new person you add to that team creates an entire new team right it is a completely new team i can't do that with like 125 person engineering organization my cto can't do it with a 500 person engineering organization you can't say yeah we hired somebody in such and such a team so it's going to revisit all of the engineering norms but you can do it on a team and like you and you can hold enough direct not even transitive but direct trust with your engineers to be able to be their stability and say the thing that isn't changing is is like our relationship my relationship to you as an individual human being so you bring somebody else in it's like oh they're like a senior engineer and they worked at google and whatever like what they like you know or or like this person comes from a different culture and like i don't know how i feel about that it's going to be weird it's like that's cool it's supposed to be weird it's a new it's a new team like you know that's the whole that's the whole point which has all sorts of implications for like more flexible staffing models to your point but like i think that there's such a wonderful thing about being able to express the change that we're talking about like i don't think most engineering managers i certainly as an engineering manager didn't think about the institution as a whole except in the ways it was indirectly its decisions were indirectly passed down to me like that abstraction again felt like people but it is the institution the only people who understand the institution directly are the people who are closest to the outside of it right or to the core of it depending on how you talk about it which is us right the people who have some authority and enough authority to look at it and be like that norm that norm that every the reason everybody is acting this way like you i have the context on that and it's just like somebody made a mistake seven years ago and like dropped the production inventory database and now like there's an audit committee for every change every migration that comes in like and we've been doing it for seven years and like everyone just forgot but that's the institution got hurt and so there's on this giant this giant entity that is your your company there's this little boo-boo on the on the on the forearm and you're like you're like it's okay it's okay we can let's let's you know let's add a column it's gonna be okay well on a positive note of it's gonna be okay david thank you for joining us neha thank you for being here and everyone thank you for listening and we'll see you next time thank you thanks bye bye
16 January 2026
Interviewed by freeCodeCamp Podcast
Mike McQuaid joins Quincy Larson to discuss career lessons and the software engineering skills worth prioritizing next.
Welcome back to the FreeCodeCamp podcast. I'm Quincy Larson, teacher and founder of FreeCodeCamp.org, and today I'm interviewing Mike McQuaid, the maintainer of the Homebrew Package Manager tool used by tens of millions of developers. First, let's jump to some community news. FreeCodeCamp just published a book, a full-length book, that will teach you the math that powers most AI systems. Even if you haven't touched math since high school, you may find this book helpful in expanding your understanding of the layers of abstraction underpinning these emerging tools. You'll learn key concepts in statistics, linear algebra, calculus, and optimization theory. You'll also get a healthy dose of mathematical history. It's a full-length book. Link is in the description. And if you're finding a sudden surge in AI tools to be overwhelming, FreeCodeCamp publish this practical guide to using them effectively. Finally, this tutorial will separate the utility from the hype, and you'll learn how to minimize hallucinations with context management. You'll learn about agentic tools and in-editor assistance. It even has tips for how to prevent your own developer skills from atrophying, so you can adopt these tools without becoming overly dependent on them. Very important. 35-minute read. Link is in the description. And FreeCodeCamp this week published a course on React optimization. You'll learn key React design patterns to achieve screaming-fast front-ends. This course covers memoization, derived states, throttling, debalancing, concurrency, visualization, virtualization, and more. It's a two-hour course on YouTube. And did you know you can learn music production on FreeCodeCamp? You can. We just published a course on the popular Fruity Loop Studio, FL Studio, digital audio workstation. This course will teach you sound design fundamentals, mixing, filters, drum sequencing, bass lines, synth melodies, and even advanced concepts like kick drum ducking. You'll play along at home, and by the end of the course, you'll have your own bass house track that you can share with your friends. It's a three-hour course on the FreeCodeCamp YouTube channel. Speaking of music, this week's song of the week is 2022 song Ditto by Korean pop group New Jeans. I like the song because it feels so slow and relaxed, even though the BPM is actually like 130. It's really fast tempo, but you don't necessarily feel it. It's got this weird kind of dynamic. It has really minimalist production. It's mainly just AOA drums and vocals, like heavily processed girl group vocals. And this is perfect late-night listening. And support for this podcast comes from a grant from AlgoMonster. AlgoMonster is a platform that teaches data structure and algorithm patterns in a structured sequence so you can approach technical interview questions more systematically. Their curriculum covers patterns like sliding window, two-pointers, graph search, and dynamic programming, helping you learn each pattern once and apply it to solve many problems. Start a structured interview prep routine at algo.monster.com. Support also comes from the 10,338 kind folks who donate to our charity each month. Join them and support our mission at donate.freecodecamp.org. And you can get your FreeCodeCamp t-shirt and rep the FreeCodeCamp community with pride. I'm wearing one right now. This shirt is extremely durable. I've washed it like 100 plus times. I've got like a whole closet full of them. And I wear it like five days a week. Like every work day, I'm rocking them. And they just fit really well. And I strongly encourage you to pick one up and rep the community. 20 bucks shipped anywhere in the U.S. If you're outside the U.S., just grab our assets from our assets library and you can screen print it on a shirt yourself. But if you want the really high-quality shirt, you've got to come to the stage for that. So shop.freecodecamp.org. And here is my interview with Mike McQuaid. He is a software engineer who previously worked at GitHub and now serves as lead maintainer of Homebrew, a Mac package management tool used by tens of millions of developers. He's based in Edinburgh, Scotland, and he's worked remotely as a dev for nearly two decades. We talk about what a career in open source really looks like in terms of like resources you have available, what the day-to-day is like, what skills are going to be more important going forward now that we have all these AI code gen tools. And he uses them even at his level. He finds them to be useful and he talks about how he uses them and then how big open source infrastructure really gets ridden and really gets maintained. Mike McQuaid, welcome to the Free Code Camp podcast. Yeah, thanks for having me, man. Well, congratulations on the release of Homebrew 5.0. Millions of developers rely on Homebrew as a package manager. And I have to ask, what does it feel like to hit publish on a major release like that and have that immediately go out and be used by so many devs? Yeah, I think it's exciting. It's a little bit scary. Like you hope you've dot your I's and crossed your T's and not broken too many people's things. But yeah, I think the main part of, yeah, exciting would be probably the main word. Yeah. And maybe you can talk a little bit about some of the big improvements to Homebrew. We're going to dig into a lot of your worldview, a lot of your approach, how you use LLM tools and don't use them, a lot of your taste. But real quick, for people who are not familiar with Homebrew, what does it do? So the way I like to describe it to, I guess, less technical folks is it's like a package manager. Sorry, it's like an app store, but for open source software, right? And if people know what a terminal is, then I would describe it as being, you know, a package manager for that as well, right? So if you're a dev, if you're working on software, if you may be used to using NPM or something like that to install your JavaScript or PyPy or PIP to install your Python code or whatever it may be, and if you want to install all of the stuff that doesn't come from one of those language-based package managers, if you're on a Mac and increasingly numbers of people on a Linux, you're probably going to install that through Homebrew instead. Yeah. And you have been maintaining this project for many, many years at this point. How long? 16 years. I guess now that we're in 2026, I guess it would be, yeah, 17 this year, later this year. I mean, it's, you're one of the most veteran open source maintainers I've ever had on the Free Code Camp podcast in 200 plus episodes. And you're not just doing this. You're also working full time. You were working at GitHub for a long time as a dev. How do you balance maintaining an open source project on top of full-time work? Yeah, it's a weird one because I get asked this a lot. And I guess the short answer is I sort of don't really know because I don't feel like I'm doing anything especially different. But I guess if people looked at my calendar and how I spend my week, I think the main thing is I just don't really do very much stuff that I don't think is important, right? That's both on homebrew itself, right? There's a lot of people who spend a lot more time on homebrew than I do, probably on a given week. But also, like in life, right? Like I remember maybe dating myself a little bit when I was in college. There was the line about, you know, like work hard, party hard or whatever. And I think I still have a little bit of that ethos. Not so much the party hard in terms of like, you know, partying in a way that's hard on your body. But like when I relax, I want to take that seriously, right? Like I don't spend a lot of time doom scrolling or whatever, right? Like the things I'm doing in my life, basically everything feels either important or enjoyable or ideally both. Yeah. Okay. So it's more about what you don't do than what you do. Like the negative space of, okay, I've got work. I've got sleep. I've got family. Like what else can I fit in here? That is actually important. And as you said, doom scrolling, which is something I also do not do, is something that you don't have to do. People feel compelled to do perhaps because apps want to draw you in and like waste your time and stuff like that. Everybody's just trying to get time on site, time in app. But you've somehow figured out a way to prioritize around that. And just, you have the same 168 hours a week as everybody else, but you figured out how to use that in an optimal way where you can work as a dev and you can maintain a project. What advice would you give to somebody who is feeling like not everything they're doing all the time is important or necessary in terms of like restructuring? If you didn't know a lot about them other than they were spending like, I don't know, 15, 20 hours a week on stuff that they wouldn't consider particularly important that they could swap out for something that is important. How would you recommend the contract? Ironically, I think it's like, it's both the, like pushing yourself in both extremes in some ways, right? So I actually also play a bunch of computer games, which is maybe surprising, like not huge amounts of my time, but like enough because I find like in 15, 20 minutes of playing a computer game, I can get really relaxed really quickly, particularly if it's some game that I really love and have played a lot of. So, and sometimes I feel like your brain needs that stuff, right? Like I, I found myself during COVID, like binge reading, like relationship advice for other people and read it just because my brain like needed to just have some sort of like junk food for the brain, right? So I find like maybe some of it is like figuring out like, look, we don't, you know, there's a lot of productivity culture out there, right? We don't need to be all working 24, seven, three, six, five, right? You need to have downtime. And actually I think that helps you work better and more effectively. And I think figuring out what those things are and what those compliments are, like another thing for me, I remember when my kids were super young, right? Like when you've got, I know you've got kids as well, Quincy, like when you've got kids who are like sub a year old, right? Like they require a lot of attention to just keep them safe, but not a lot of like intelligence and thought, right? So like really fixating on keeping this little creature alive, but at the same time, like you can feel your IQ dropping by the minute. Yeah. Like that for me, it was a really nice country. I remember one time my wife, I finished work and was like doing some stuff with kids or whatever. And she was like, are you not tired from work? And I'm like, no, because these are exercising exactly the opposite parts of my brain, right? Like I've had a lot of like, use the brain very hard, but like not having to concentrate maybe as closely or, you know, think, thinking really hard, but not moving my body to being like, I have to really move my body. I have to really concentrate. But intellectually, what I'm doing is like, have they got food? Have they got nappy that's clean? Like, you know, that's, that's it. So I think having that sort of approach to your life might be helpful about being like, well, what are your goals? Like maybe just picking one of those goals and being like, I'm going to work on this, this many hours a day or week or whatever. Right. And then outside of that, I'm going to chill really hard. I'm going to find a show I really like on Netflix. I'm going to watch all of it. I'm going to find some game I really love. I'm going to hang out with my best friend, whatever it may be. And I think that kind of like being on or off is what's really helpful. And that's sort of like middle mushy ground of like, I'm sort of working, sort of not sort of relaxing, sort of not like that. That is where I feel like the lack of productivity lives. And there's kind of phantom productivity, which is illusory. It seems like you're being productive because you're responding to some like email just in time as you're getting it or some notification pops up. And you're like getting pulled out of your relaxation time into productivity mode where you're probably in a very mediocre way interacting and trying to nail down that task that needs to be done because you just aren't warmed up. You don't have the focus or anything like that. You don't necessarily have the context. You're just trying to get it done so you can have that. I'm inbox zero right now. You know that vibe. But I would imagine you're the kind of person that doesn't have a whole lot of notifications on on their phone. Yeah. A hundred percent. So I don't, when I was, well, I don't have generally, unless I'm on a work trip, like company Slack on my phone. I don't have company email on my phone. I have calendars just because it's a bit more useful unless, you know, no one's doing me scrolling their own calendar, I would hope. I don't have any social media apps on my phone. I, yeah. So basically my phone, I try to make it as boring as possible. Another hack I found is like the screen time feature that's kind of mainly designed for parental controls. I have limits on certain apps that I use to like waste my time on websites, like Hacker News. Really like Hacker News, but I can spend too much time there. And when my time is up, I don't have the passcode. My wife has the passcode. So I have to ask my wife, can I have more time on Hacker News, please? And she would say yes, but like that's humiliating. So I don't do it, right? Like, and yeah, there's various other little apps you can get that do things like that. They just kind of break that like habit forming dopamine boosting thing. And as a result, my phone is mainly for little distractions or doing work or like just reading a book, right? That's my main, almost like if I have 30 minutes to just relax and spend time on my phone, I've got post-COVID really into just like reading long form science fiction books again. And I love it. Yeah. I'm in the same boat. Like I basically don't have anything on my phone other than like podcast player. I've got the YouTube app because I do watch a lot of good YouTube video essays on like, you know, information security and stuff like that. And also just on history and I'm big into music and stuff like that. So I'll watch about like the history of like some musical piece coming together or something But, um, yeah, like just like you, you, you're really into power lifting, which we'll talk about in a little bit. And you're also very accomplished with it. Uh, and of course, power lifting Instagram, I think is like the main place that people share that sort of content. And, uh, my understanding is you'll install Instagram, fresh install. You'll sign in, you'll go watch your power lifting related videos, and then you delete the app completely after you're done at the end of every session. Pretty much like, yeah, if I'm going on and posting stuff, reviewing stuff, that's generally how I do it. Or I'm, I stay logged in on my desktop computer because it's just, there's something about like, well, I'd say desktop, you know, laptop, but like there's something about not being on the phone that just makes it like a little bit less addictive. And it's just that little like dopamine thing of like, you just pull it out your pocket and you're like, give me something, come on, just give me something good. Like the, I, I just, I have no self-control with that. And I, I will just sit and like all of the kind of anti-doom scrolling stuff. Cause like, I, it's not that I think I have more self-control than most of the listeners here. It's because I know that I don't, it's because I know that I, I am really incapable of using my personal, like mental ability in the moment to stop myself wasting hours on this stuff. Like, that's why I'm like, I just can't have it. Cause like, even, you know, I used to do this with like junk foods where I'm like, I don't prohibit myself from having junk food. I just try not to have it in my house. There's a nice shop I can walk to that's five minutes away that has loads of nice junk food. But I, then I'm pitting, like, I want junk food versus I'm lazy and I want to walk to So like they sort of cancel each other out. And I feel it's the same thing with some of the kind of screen time stuff and phone stuff and whatever is, it's just making it easier for yourself. Like just being like, I give up, I can't handle it. I'm going to just not have this. Yeah. So essentially just putting natural barriers and, and kind of like inventing mechanisms to, to not necessarily forbid you from doing things, but make it inconvenient to do those things that the, the type of behaviors that you want to limit essentially, and not cut out completely, but limit. Yeah. It's like, I, I can't remember who I heard kind of came up with this concept originally, but it's, there's this kind of almost like psychological concept that like, like now you and future, you are almost like two separate people. So like one that came up the other day, like we have cheesy Christmas lights in our house that are battery powered. And they take the same number of batteries. And I always have a gift every year where I take all the batteries out. And then the first thing I do is I go on Amazon and I order exactly the right number Again, I put it in with the packaging and then I forget. And then in Christmas time, I take them all out and I'm like, Oh, I have to buy like 17 batteries. And I'm like, Oh, I have them here already. You give the gift to yourself. Exactly. So I feel like some of this stuff around boundaries is the same type of thing where it's like, I guess maybe it's, you know, Daniel Kahneman's thinking fast and slow or whatever it may be, but it's like short-term me, like when I'm thinking in the scope of like seconds and minutes and I just want to be entertained and I'm a bit bored or whatever. It's like, I don't make good choices. Whereas long-term, what do I want to do in 2026? Like planning my life me? Like, I feel like that person makes relatively good choices. So what I want to try and do is have as many systems and processes and setups to kind of nudge like short-term me into the constrained way of thinking about the world that kind of Right. So like, even like, you know, if I, I mean, you probably can't see, but if I hold up my So my home screen, I have nothing. I removed everything. It's all in the app library. And at the bottom, I just have messages to talk to my wife and my friends, music, to listen to music, podcasts for obvious reasons and books because I'm allowed to read books. And that's like, even that little thing is just like, that's what I've decided. Those are my four most important things. Right. So you want to like, make the stuff you want to do easy and then make the stuff that you don't want yourself to do. Not maybe impossible, depending on your willpower or just even like harder, right? Like if it's, and if it's harder, then quickly you find you will do more of the stuff you want to do and less the stuff you don't want to do. Wow. So that was really cool. For anybody who's listening and not watching the video version, I mean, that was literally like a perfectly empty iPhone with just the four apps in the dock. And that was it. Uh, well, I don't think I've ever seen that before. I also use a lot of tricks like that, but you, you've taken it to the extreme, which I absolutely respect. One question I have for you is, so you're working as a dev, you've got this skillset, uh, that you've been applying to provide for your family and yourself, uh, for, you know, the past couple of decades. And at the same time, you could just go home. You could relax, you could play more video games, you could spend more time with your kids. You could do more of everything you're, that you enjoy doing, but you're instead doing this, like probably compensated in some way, but like largely, you know, volunteer role of helping maintain a major open source project along with a lot of other contributors around the world. Um, why, why spend your time in this way? Yeah. I think that's a good question. Uh, and again, it's one of those ones where like, I don't think about it much until I'm, I'm asked, but I mean, I guess like maybe some of my, my history, right? So I got involved, I grew up in Scotland. I got involved with tech basically just because I was like, I like computers, right? My, the first time my dad brought a computer home, I was just fascinated with this thing. Like he found any boring task he could get me to do for him as long as it involved the Right. And then when it came time to go off to university and all that type of stuff, then I was just like, I just want to do computers. And at this point, and particularly maybe for some of the younger listeners, this might be kind of hard to believe, but at this point, particularly in Scotland, like being a software engineer was not a particularly, you know, affluent or prosperous thing. Right. Like I grew up in an environment where it's like, be a lawyer, be a doctor. Those are like real jobs that like pay well and all this type of stuff. Right. And I sort of rebelled against that. Cause I was like, I don't know, man, I just like computers. Um, and then, yeah, like, I guess I fell into an industry probably at the lucky inflection point time when a lot of these jobs became a lot better compensated and more important. And, and the internet was taking off more and all this type of stuff. Um, so for me, I guess like that, that's kind of the same reason why I do a lot of it is that I just, I just love it. Like I, I, I still enjoy doing what I do. Like there's a certain amount with homebrew specifically where I'm like, you know, I might kind of grumble about certain things sometimes or not want to do this very specific thing And I'm like, yeah, but lots of people use this, right? Like, and it's a, it's a kind of useful, like contribution that I find anywhere between neutral to actively enjoyable and it benefits a bunch of other people. Um, so yeah, I guess that's, that's kind of why I do it. Um, and even, even the how, right. So like I have slightly more kind of blurred lines, right. Where I've worked from home exclusively since 2009. Uh, so for me, like 16 years, 17 years now. So I was doing it before COVID kind of made it cool, I guess, but like, as a part of that, like a lot of stuff that, you know, was, I, again, most of that time was for companies in different time zones or whatever. So as a result, like the whole, like you clock in at nine o'clock, you clock out at 5. PM, right. Like it's, that's not really been my life or way of working for that. So I don't have as strictly regimented, like this is, you know, work time and open source time for relaxing and whatever it may be. So these lines get like a little bit more blurry on that. Um, and I think also partly because I think this stuff kind of cross pollinates a bit as well. So, um, I think the work I, you know, everywhere I've worked pretty much like a reasonable number of my coworkers have used homebrew. Right. So it's like, well, I'm, I know that work isn't telling me to like release this fix, but I know my coworkers are going to need it. So, um, that seems worthwhile. Right. Like, and, uh, and again, maybe there's a little bit of career advice in there and that like a lot of the stuff I've done, like I'm a lot of my life and maybe balance or whatever is less about doing like, Hey, what does my boss really want me to be doing all of the time and more about like, well, you know, it's a balance between what do I want to be doing? What's my boss wanting me to be doing? What's the company want me to be doing? What do I think is best? Right. And we'll try and find some like blurred version in which everyone is like reasonably happy, but like maybe not. I used to joke with some much higher achieving coworkers than me at my, uh, at a previous company that like they should aim to get worse performance reviews because actually like they are, you know, doing exceptionally well, making everyone really happy. But in terms of like what that actually means in terms of their take home pay or compensation or impact on users or whatever, like they're like working 20% more and they're having 1% Whereas I guess I'm maybe just like a deeply lazy person or something, but like my thing is always like, what's the point at which me putting in another hour on this task delivers dramatically diminishing returns. And I just try and just not do that. Like all over my life. And that's again, maybe how and why I've found more space that other people might find difficult. So you've cultivated this instinct of, okay, this is declining marginal value, essentially like, like the average, you know, minute put into this task, the, the output is dropping and you, you developed kind of an intuition for when you should just log off essentially. Um, it sounds like that is a really cool, uh, skill that you've developed and, uh, your, your advice aimed to get worse performance reviews. Uh, because obviously the company just wants you to stamp out as many widgets as you can Right. Uh, that's, that's how managers are evaluated generally. What's the productivity of your team? How is that measured? All that stuff. And what you're saying is like, like there comes a point where you really do need to just, um, go do something else. And it's, it's not necessarily worth your time contributing even more to this manager's objective. Yeah. I, I mean, I think that's sometimes the case. And also just sometimes like, you know, the number of hours you put into something, like you can distribute them differently and get a similar result. Like something that sprung to mind was like, I wrote a book about Git a very long time ago. Um, and I was encouraged to almost be like, as a first time author, like, you know, do a little bit every day, slow and steady. And I would have two week check-ins with my publisher. But what I would do is the check-in was on a Monday. On Saturday, I would just sit at a keyboard and just write until I hit the page count. I wouldn't even read it back. I just write and write and write. And then I hit like, you know, I was trying to do 20 pages or whatever. I hit the end of page 20 and I would just stop and log off and be like, right, done. And then on Sunday, I then come with like fresh eyes and I'm like, I don't have to write I've done the writing. And then I would just read through it all and be like, this is trash, this is trash, this is typo, move this around, blah, blah, blah, whatever. And again, like that approach, I think if I, it would have been perfectly possible to do it in one sitting, I think, but it would take way longer and the output would have been worse. But instead you almost like carve the task in half and you rely on the fact that some things just do better for you coming and looking at them the next day. Right. Like, and, and that, like, it's, yeah, those types of like little weird approaches and ways of looking at things. And I think that kind of comes on with like, say like at work, right. Like where, when I was at GitHub, there was, people would talk about like, oh, I, I want to see, you know, my boss or the manager or CEO, I want to see a shitty first draft of Right. My version of shitty first draft would be like, I do no research. I just like type, I don't even read it back. And then I would send it to my manager. Like, and sometimes that would be perfect because she would say like, okay, like this is interesting, but like this full typo is like, you know, clean this up and we'll send it on to someone. And sometimes she, that would be enough for her to read it and be like, yeah, we're not Okay, cool. And if that, and if that was the case, right. If I put another hour of time in, if I, if I spend an hour instead of five minutes, then it's like that 55 minutes, which is completely wasted. But to go back to what you said before, that was work. I was working. I could have been working for another 55 minutes. I could have stayed later. I could have not done something else, whatever it may have been, but that would have just been like lost to the ether. Like, and it's, it's hard because I also feel like maybe it's like a, without getting too philosophical, like an education system stuff. Where we, we grew up and often like, if you're like, if you do well in school or high school or college or whatever, it's like, do all the things to your maximum ability, try and get Like, and then if you do that, then you will be like happy and successful in life. And it's like, sometimes for some people, sure. Like, but for me, like I was, you know, in school, my teachers hated that attitude of like, I'm going to do the minimum required effort to get an A right. Like they really did not like it, but like, actually in the workplace, like your boss might not say that, but like, sometimes like, how can I get to a good result as quickly as possible in many contexts, that's the most valuable thing you could possibly do. Right. And actually like delivering something like 1.5 times as good in twice as much time is not what anyone wants. But they might not ever tell you that that's, it's a hard, and your manager may not actually consciously realize that like, Hey, you just saved an hour of time because, uh, like you gave them what they wanted and they were able to evaluate it and make their decision that you didn't have any power in any way, uh, as to whether this is a go, no go situation. And then you went and spent that extra hour doing other work that is getting things done that the company wants to get done. Uh, so you kind of like help them manage you in a way. Yeah. And, and the, this is one of the things that like, not to get too organizational philosophical, you have a podcast where you just talk about organizational behavior, open source maintenance philosophy of being a manager, all this stuff, which is really cool because you were an IC for like so long and individual contributor. And then you got into management like much later in your career. So you have a lot of context from both sides. But, uh, one of the things that I think is really interesting is if you just give people a lot of trust and you give them a whole lot of slack, they can prioritize things for you and they can put the right amount of time into things for you. Like our staff at free code campus is 29 devs, uh, many of whom have teaching backgrounds And essentially I just like tell them like, go do what you think is the most important, get other people to help you with it. If you think it's so important and then let's just see how that goes and just check in and tell me what you're doing. And then I'll kind of give you a feel for like whether I think that is sufficiently important to do right now. Cause in a perfect world you do everything, but there's that time trade off. Everything has a marginal cost associated with it. And so by pushing the decision making down as close to the person actually using their hands to execute that work, you are making the organization way more, uh, efficient because you're not abstracting that up and giving, you know, those decisions to somebody who's several layers of abstraction removed from the work being done. Yeah, I, I definitely think like there's so much wisdom in what you were describing, right? Like high trust cultures are so helpful. Like everyone likes being in them, uh, but they are sometimes hard to build. And also sometimes part of like building that culture, at least in my case is like doing the work on yourself, right? You might not naturally be someone who's very good at trusting or delegating or whatever. And that's also a skill that you can work on, right? That requires you to admit like, Hey, maybe I'm not as great about this thing as I thought. Yeah, absolutely. Well, I want to talk about that and we'll talk about management a little bit more, but I'm more interested in talking about being managed and the day-to-day experience, uh, cause you have worked at well-funded tech companies like GitHub, for example. Uh, and then you've worked at scrappy open source projects where you're trying to do more with less essentially, or, or even get by with like fumes essentially. Uh, what can you compare and contrast the, the experience, uh, your day job as a dev working at a well-funded tech company or even like a moderately well-funded startup versus open source? So, I mean, they each have their pros and cons, I think is the interesting thing. Cause like, if, you know, if, if I never had to work again, like financially, like I would likely still do open source forever, but I don't know what types of, uh, professional work I would do or not do forever. And some of the reasons for that are, you know, like often when we're building open source, we're building something in a problem space that we as an individual deeply care about to the point that we don't have to be given any financial incentive on top of that. Whereas when we're working in a job, right? Like a job is a job, right? Even if you love your job, like for most people, if you were like, will you keep doing this indefinitely They would say, ah, no, I have, I have things I would rather do for free. Thank you very much. But also again, like pros and cons of that, like jobs and places like GitHub, like I joined, uh, in like 2013 when they had 200 and something people I left in 2023 when they had like just under 4,000 and, you know, you see a lot of change and structure and growth and process and bureaucracy and product managers and project managers and technical project managers and hierarchy and all this type of stuff, which, you know, sometimes at the time as slightly rebellious, icy type, open source type, I'm like, ah, this is all unnecessary. And then you realize like, actually, it's really helpful and it's really nice. And sometimes it's just much quicker to be able to say, hey, I'm your boss. We've had a good chat about this and now you have to do it. Whereas in, in open source land and even, I guess the difference between being a manager and being an individual contributor, right, you can't do that. Like in some ways, manager, individual contributor, like open source contributor or open source leader or whatever, like in some ways they're kind of a spectrum because when you're an IC, like there's someone in the middle, like when I was a principal engineer at GitHub, right? Like I was, you know, important fancy principal engineer, blah, blah, blah. Like I've been there a while, but I don't have any direct reports who I get to tell what they work on, right? I don't have any budget. I don't have a team. So I have to just convince people that things are a good idea. And that's much the same in open source, right? If you want to be an open source leader and you want to get volunteers who are being either unpaid or paid, I guess, in homebrew's case, like incredibly below market rate for like what, what work they might be doing, you have to convince them like, Hey, this is a good Let, let me like almost like plant the flag and, you know, lead the rallying call for like why we should care about this thing and why you should come and get involved with me. Right. Um, on this project or whatever. And yeah, that's, that's tricky. And it is harder to do that than it is to just be like, I'm your boss. You have to write. Yeah. But at the same time, like the, I'm your boss. You have to, that high trust environment you described before, like there's only so many times you can do that before you kill that, but people, people want to feel particularly as you progress in your career, particularly when you're doing stuff, not for money and in your spare time, you want to feel like you have like the ability to decide what you work on and how you work on it and what the output is. And you don't want someone to just be like, I don't know, like, I guess we've both got guitars in the background, right? I'm a bass player, right? And the worst, uh, microaggression a guitar player could do to a bass player. It's just being like, yeah, man, I want you to play like, like this. And then just like play plucking on the bottom string, exactly what they want you to play as if it being like, ideally we would just clone me, the guitar player and give me a bass and I would do it. But unfortunately we have you here. So I have to tell you what I would do instead of me just doing it. And, and sometimes in the workplace, it could feel the same way. Like if someone is just being like, I would ideally do everything myself, but I can't. So you have to do it my way. That doesn't feel nearly as good as someone who's like, Hey, I think you're better at this Like, here's a problem. Do we agree? This is a problem. Great. You go off and figure out how to solve that problem because like, you're going to figure this out better than I will. Right. Like that feels great to be on both sides of that. Yeah. So be like Slash. Don't be like Billy Corgan who insisted on recording all the guitar and bass parts himself and didn't pass his musicians on the other musicians on the band to record good takes. Yeah. And not pulling rank. Very important. Lesson for that. You can only pull rank so many times before people just start talking behind your back, making fun of you for being some guy with the stick of their butt, you know, like who doesn't necessarily have the merit who was just given the power over you. When you're in an open source community where, as you said, like everybody's doing this mostly because they care about the mission and things like that. There is that very fragile kind of like motivational purpose, like the sense of purpose that people And you don't want to disrupt that. And I want to talk a little bit about how homebrew is administered. I know that you've been elected repeatedly as homebrew's project leader by the community. And there is infrastructure that like essentially gives you power. And that power could be given to somebody else or it could be taken away from you if people disagree with what you're doing. What is it like running a major open source project day to day? Yeah. So, I mean, I think the day to day side is, again, much like, you know, any good or healthy team, like there's not a lot of kind of intervention required, right? Like everyone's just like buzzing away doing their own things. But I think the kind of tricky part of the leadership side is the, I guess, you know, dealing with crises, right? Deciding how and where and what needs to be done. And sometimes like being the person to kind of resolve some gridlock or push through maybe a slightly unpopular decision, right? So, it's funny because if you read Hacker News, which I do sometimes, when Homebrew comes up, like there's a lot of people on Hacker News that don't like me specifically and some of the stuff I've done with like leadership and whatever around Homebrew because some of the stuff I've done has been maybe forcing through some of the most controversial changes. But that's not because I unilaterally was the only person who thought that should be done. It's because I felt able to do that and to lead the charge. Yeah, you have to be the face of the changes and bear in the front. Yeah, for sure. And also, sometimes it's like, you know, when you don't know how the sausage is necessarily made, it's like there's things where, sure, would it be nice if Homebrew could do this feature or support this workflow or whatever in perpetuity? Like, yeah, sure. But like, we're a bunch of volunteers scattered around the world. We're not really paid. Like, so with that in mind, like we have to, it comes, I guess, back almost philosophically to what we were saying near the beginning, right? It's saying no to things and being like, well, what can we do and what can we not do? And I think one of the things, it's a bit more questionable now, but I liked with being in the Apple ecosystem, right? Like, ironically, the first Mac I bought was six months before I became a Homebrew maintainer and, you know, have worked on it ever since, right? But something that always influenced me about Apple's approach to software development, maybe a little bit more back then, is it's like their goal was not to give you all of the functionality that every other alternative would provide. Their goal was to be like, the functionality we provide will work well. It's not about just like ticking a box and being like, you can share, but it's a bit janky and it's a bit buggy. It's going to fail 15% of the time. As I say, unfortunately, some of this is maybe crept into the Apple ecosystem now, but it was about like, what can you actually do that's going to deliver a good experience for the vast majority of people, the vast majority of the time, right? And some of the controversial stuff that has been removed or changed to one of our Homebrew was because we could not deliver a great experience to most people most of the time. And if you're one of the kind of, you know, power user types, then that can be very frustrating because essentially we're taking a very powerful tool and we're making it less powerful because some people can't file issues correctly or whatever it may be, right? But like, that is the way the world is, right? And the problem is, and this is maybe another philosophical thing, but the problem is, is that the people, you have to have an open source. You have to let the people who are bearing the brunt of the pain of these decisions be the ones who make the decisions, right? Like there's been a lot of talk about like community involvement and users in open source and in Homebrew among all open source projects, pretty much like we do listen to users and we do take feedback or whatever, but we're not, it's not a democracy, right? Like we are the ones doing the work. If we, the maintainers stop doing the work, the project no longer exists, right? So as a result, we have to have something that allows us to work sustainably and indefinitely on the project. And if that means that we do something in a direction that you don't like anymore, then Mac ports is another package manager for Mac OS. And people, when I say that, they think I may be being like, you know, telling them to piss off or whatever, but it's like genuinely, I'm like genuinely this other tool may be a better fit for you now. And this Homebrew maybe was the best tool. And then maybe Homebrew is not the best tool for you anymore. And that for me is not, it's not a sad or an emotional thing. If someone decides another tool is better for them, right? That's a good thing. And in a weird way, I probably thought maybe long before today, right? Like at some point, Homebrew will not be the best tool for anyone anymore. And people will just stop working on it because everyone's moved to something else. And to me, that's not sad. That's just how technology evolves and computers work and whatever. Right. And every individual that kind of makes that move, I think is like part of that transition in that process. And we just need to be like, understand how that is. And it's a very different proposition to when, if someone is a customer of a company and if all the customers go away, the company no longer exists and no one gets paid and it gets shut down and whatever, like Homebrew, Homebrew's code will always be there forever. Right. Like it would be on the internet and our users are not customers. Our users are people who use the software and maybe they contribute, maybe they maintain it for however amount of time, but like it's, it's very different. It's more like a, you know, a co-op or a free food stall than it is a business. Yeah. And free code camp is similar in the sense that, uh, regardless of what happens, like a free code camp ever just ceases development. Hey, it's open source fork it and you can run with it. Um, and I think it's important that there's that release valve, uh, Apple's philosophy of just doing a few things, but doing them really well. And here's the functionality here are the different API calls you can use in Xcode and But like, these will all work pretty reliably. Uh, I, I, that I'm not like a huge Apple fanboy like you. I switched to Apple from like Linux cause I was working at a shop, uh, that, uh, when I say shop, like, like it was a rail shop. We were using Ruby on rails and they said, Hey, everybody works on Mac. It'd be a lot simpler if you're on Mac instead of, you know, Debbie and I can't remember which distribution I was on at the time. Uh, and, and that's how I got into it. And, and then as I used it more, I did come to respect a lot of the opinionated decisions, you know, the convention over configuration essentially of like, here's how we're doing things. If you don't like it, there are ways to like go and do your own thing, but like, it's not And it sounds like that is part of your philosophy as well, at least as how you steward the open One of the things you've mentioned that I thought was really interesting in the past is if somebody opens like a feature request or an issue and you're not going to do it, you don't give You just immediately kind of shut that and you're like, Hey, that's not what we're going Uh, is it hard to just constantly put down people's feature ideas and people's bugs? Yeah, it is in some ways. Um, I think that, I mean, you get, you get a thick skin off to doing it for a while. Cause like most people accept that, right? Like, and I just, there's a lot of things in life and in our industry. And whatever, where I think you make the choice between short-term or long-term kind Right. Like, and I've always been in lots of areas of life. Like I favor the kind of like short-term pain, long-term gain sort of thing. Again, back to the metaphor with kids, right? The, it's the times you catch yourself saying, well, only this once. And you're like, yeah, that's, that's not going to be a good idea. Cause my kids are not going to accept that this is a thing that happens once. They're going to want to do this again, again, again, again. Right. So like, maybe this makes my life easier right now to do this, but I'm again, current Mike and future Mike, like I'm, I'm like taking out like debt for future Mike and current Mike is benefiting that. So let's not do that. And I think people understand when you do that with their issues and stuff as well. Because, you know, I'm not going to name any names, but there's plenty of projects out there that have a hundred thousand open issues. And realistically, the vast majority of them are never going to get done ever. Right. And, but yet on a bunch of them, if someone went and closed it and said, we're not going to do this, then a bunch of people will be like, ah, but it's like, but like literally the natural state right now, again, maybe too much philosophy in me, but like the natural state is this thing is not do, is not done. You are proposing thing be done. And the current situation is it's not being done. So in the absence of someone doing it, it will not be done forever. And I think in a homebrew, but because again, we, we get a reasonable sense of like, sometimes when issues come in, whether it's like, okay, anyone could fix this pretty easily. Right. Or only someone a little bit more seasoned could fix this. Or like in sometimes cases in homebrew, there's some probably bits that it's like, okay, probably only two or three people have enough context or understanding to like fix this. And if something comes in that affects a tiny number of people that only two or three people can fix and those people are not interested in doing so, then it's like, well, let's not pretend. Right. Let's not lie to ourselves and be like, yeah, we're going to do your thing when we're not Right. And that actually, I think works reasonably well. And like, in real life in some ways as well. Like in, you know, if we've got friends who are treating us badly or, or even just like, you know, I remember in the early days of Twitter, I had a good friend who I would happily spend hours chatting with in the pub. And his Twitter, I followed him on Twitter and then I unfollowed him on Twitter. And he was like, oh, why did you unfollow me? And I'm like, cause you're not very interesting on Twitter. Like I will go to you and sit with you in the pub for two hours and listen to you talk about Cause you're fascinating. But on Twitter, like that it's not helping either of us like me following you on Twitter. And some people would look at that and be like, you know, you're excessively blunt or whatever it is, various other unkind adjectives. But, um, I guess I've just, you know, maybe it's my life, but I I've reached the age now where most people around me kind of accept that and actually value and appreciate that. Cause the nice thing of knowing someone like me is if I say like, you did a really good job on that. I'm not saying that to make you feel better. I'm saying that cause I actually think it right. Like, so people do tend to appreciate it when they, they learn that you're someone who is not just going to blow smoke up their arse and pretend that everything's going to be Um, but yeah, but it does sometimes take an adjustment and that's why, again, you know, if you look on Hacker News, like people will pick out like individual comments I made and they're like, that was very unkind or Mike's a dick or whatever it may be. And it's like, yeah, but I made 10,000 of these last year. Like, of course you will be able to find a bunch of places in which my communication was Right. But we're not talking like Linus Torvald ripping into a contributor or anything like that. We're just talking about you bluntly saying, sorry, we're not going to do that. Yeah. But I mean, even, even folks like Linus Torvald's right. Like, I think when, when you've been doing this for a while, you definitely, I wouldn't criticize how he runs his project because like, I know that it's hard. And I think it's not just that it's hard, but it's like, it's like, when you're an open source maintainer, it's like, okay, imagine you're a manager in a company, but every performance review you do, you have to do in a stadium with a hundred thousand people watching you. It's like, when are you not going to say the wrong thing sometimes that people aren't going to like, right? Or like, look at like, in some ways, like reality TV, right? Like we all watch reality TV and we're like, oh, well, no, maybe we don't. You watch this drug from reality TV. But like some of us watch reality TV sometimes. And it's like, you look at people and you're like, oh, they're so terrible or whatever. And it's like, yeah. Like, you know, they're just a person. They're just a horrible human being. They combed through like hundreds of hours of footage to find that moment where that person was in, you know, a moment of weakness, right? And yeah, you know, to credit to Linus Torvald, whom I have an incredible amount of respect for him, Torvald, he has sought anger management and he's acknowledged that he should not be behaving this way, but it's not like he's going to completely mellow out. Exactly. At the point, like there's a saying about kids will say, you're mean, but what the really saying is you mean what you say. Like when they talk to the parents, right? And I think that's like, it's kind of like a parental philosophy. Like, oh, if I entertain the notion that soon, you know, homebrew is going to have unicorns and stuff like that, uh, leprechauns and stuff like that. Like that, that's, that's ridiculous. Like, like we're never going to do this and I'm just going to nip this in the bud, so to speak, uh, before people's expectations start to get out of whack. Uh, that's kind of like how you, how you shut those down. And also like, I try and like, I guess much like the, the parenting example, right? Like the other thing I try and do is be like, you know, I'm not always right. And I'm willing to change my mind. And, and even in times when I'm not willing to change my mind, if someone's like, Hey man, like sure you closed the issue, but you were a bit mean about it. Then I try and make sure I'm like, I'm sorry, but like, it's not, it's, it's easy to say And again, you know, maybe kids, family, whatever, like advice is like a willingness to kind of admit when you're wrong and say, sorry. But the problem is again, the, like the performance review in the stadium analogy, like often it's the people who are most annoyed with me, we're not even part of that conversation. Like they're, and I, I don't feel like I owe them an apology based on something I said to someone else who isn't upset by it. Like that's, I don't know why it's, but again, it's kind of weird. Cause like we, we just don't, I don't think our brains as humans are very good at processing how to do this stuff. So I think like I met with someone who's, you know, very involved with a bunch of open source maintainers and she said like, yeah, I, I think it, you probably just all get a very thick skin and that makes you a different sort of person. And I, I think that's true. Right. Like I, I have to like remind people at work who criticize my work or whatever and are worried that I'm going to get really upset. I'm like, look, like whatever you, even if you tried to say the most horrible thing you can imagine, like people have probably said worse in my inbox over the years. So don't, don't worry about it. Right. I can tell the difference between it coming from a good place and a bad place. And again, maybe that's part of it as well. Like another thing you, you, you learn in open source pretty quickly, right. Is if someone is, you know, like now that we've got code of conducts and all that stuff, if someone's indulging in bad behavior in really any, again, be it the workplace, be it open source, be it a friend. If you can just say to them relatively calm and collected, like, Hey, that's not cool. Like you've upset my feelings or you're not doing that or whatever. Like for me, there's that pivotal moment where even if they give you the worst apology ever, cause they've never learned how to apologize properly where they're like, I'm sorry that your feelings are hurt because blah, blah, blah. Like if, if you are like, that seems to be actually coming from a genuine place, then you Right. But if that person, when you point out like, Hey, not that great, like their response is to double down and be like, fuck you. Then it might be like, it's just never worth putting a lot of energy into that because it never, it never works. You're never going to, as, as much as I have tried and will probably still continue to try, like you can't shout at people on the internet to a point where the two of you will just all get along, right? Like you can't reach everybody. I mean, some people are just, they, they need something else in their life to, to happen, to be a catalyst for change. And it's not going to be you talking to them. You're just, you're just in the way, right? You're collateral damage as they storm through their day. And that's something else I always keep in mind. Like the person I'm talking to on the other side of this comment or this email or this GitHub comment, you know, like this is a human being. They're just trying to make it through their day. Who knows what kind of horrible stuff has already happened to them today? You know, like, cool, whatever. But like, I don't have to interact with them any further. I'm just going to politely disengage or block them if I have the means to do that so that they don't do this to other people. And we're, we're going to move on and hopefully, you know, they're going to, uh, find serenity and, and find the impetus to change and not be a dick. But, but that's the thing. It's, it's, it's hard, right? Like it's, it's hard to do that. And it's hard to get like, I, I, my partner and a bunch of family members work in healthcare, right? Like, and generally people who work in healthcare are really good at that because like, why are they doing what they're doing? Like most of the time it's because they want to help people. Why am I doing what I do? Right. Like, so at the end of the day, like if, if I could somehow do homebrew in a way that involved me never talking to another human and just talking to the computers forever, I'd Like that's, that's, that sounds way better to me. That's not how the world works though. You do actually have to talk to other humans. You do. You do. Um, but, but that's the thing. Like, so I'd be the first to say like, you know, my, my people skills on this stuff and particularly that skill you mentioned right there. And I do think it's a skill that you can get better at, of being able to be in that situation where someone is, you know, on the internet screaming in your face and think to yourself like, wow, they're having a bad day, right? Like they're, yeah. Like what's happening in their life right now that is making them feel so intensely about Right. Like, and I think that's a valuable thing when you can do that. And I guess maybe pivoting back to work stuff, like, again, like that's an incredibly valuable thing to be able to do at work. And I think the more senior you become, like if, you know, the company I'm in right now, I'm like the CTPO. So I'm like the most senior technical person in the company. Right. Like, and to me, that means part of what that pay and title, whatever comes with is it's like, I need to take a lot more stuff on the chin than the, the person who just graduated And they're just, you know, new into the industry. Like as you rise through the ranks and you, you get that stuff, it's your job to like figure out how to be able to like emotionally regulate yourself, how to be able to be sympathetic and empathetic to the people you work with and your customers and your coworkers, something Right. And that's, I think like part of what it is, but the beautiful thing about that, right. Is if, if you get better than that, you're probably going to also be a better, like, like husband, wife, dad, mom, like friend. Like, yeah, it's, it's, it's a skill that works in all directions. Right. And it's so useful. Like the other, like I drive really slowly, especially when I have my kids in my car, like I'll drive like five minutes, five miles per hour below the speed limit. And in Texas, that's like, that is not cool. Like people get really pissy. They honk at me, they drive around, they flip me off, they whip around me in a very dangerous fashion to, in some sort of weird, uh, you know, machismo, uh, display, but it's cool. Like, like they're having a bad day or they're in a hurry to get to their job or something Like I, I don't take it personally when people, you know, do that. I'm fine with driving like a proverbial grandparent, you know? Um, and it actually helps me boost my temperance because I'm, you know, dealing with more hostility throughout the day. Uh, and, and that is one thing that I consider myself really good at is not losing my cool and trying to like absorb that energy without bouncing it back. Right. And it sounds like you've gotten good at that. Uh, and I think this like, we're going to get back into open source software development and stuff like this, but this is a great time to talk about like your habits because you are very much a creature of habit. My understanding is you have these recurring things that you do like every week and it's years, years and years. How long have you lived in Edinburgh, Scotland? Yeah. So I've been here, I was born here, uh, I guess I'm 41. So like on and off, I've been here the majority of my life, probably at least 30 of my 40 years I've been in the same city. Um, and you know, there's a lot of nice things about that. Right. I have my best friend from, uh, like high school, my oldest friend really, uh, we come around, he comes around like once a week. We watch sci-fi together that my wife doesn't want to watch. Um, and yeah, like it's, there's lots of nice things from just having that continuity. And similarly, I guess with like habits and stuff, right. You, you get good at things by just doing them lots and lots and lots, right. Like, and trying and repeating and whatever. And I think I've got like become a reasonable software developer, like, and various other things in my life by just doing it lots and regularly. Like, and I think there's a lot of these things where it's interesting. Like there's a famous, uh, Scottish cyclist, a guy called Chris Hoy, who's at one point, I think had more Olympic gold medals than any other person. Um, and I remember hearing him speak one time and he was saying, he was like, if you were asked in my school, like who, who was going to like win a gold medal in the Olympics, like you wouldn't have probably put me in the top 10 people. But the difference with me compared to everyone else is I just was just very consistent over a long period of time. Like I just had my training and he just trained hard, train hard, train hard, train hard, train hard, train hard, train hard, and did that. And, you know, I'm not going to put false hope in people's heads and say that like anyone can, you know, if only you just are consistent, you too can win more Olympic gold medals than Right. But there will probably be some stuff where you can go from being like average to being great, right. Just by being consistent and putting the time and effort in. Right. And that's a perfect point for us to address the fact that you are currently the Scottish champion for the M1 division of, I think it's like 81 kilogram body weight powerlifting. Is that correct? Yeah. So I guess a fun parallel between powerlifting and open source is like every time you do a powerlifting competition anywhere in the world, that's like a sort of officially sanctioned one, there's a site open powerlifting.org and they have all this open data on GitLab. And so as a GitHub employee, that was the first thing that got me to sign up for a GitLab account actually. And they have the site that's updated once a day that just has all the results for everyone. Right. So you can go and look and if you hear someone does powerlifting, you can like look them up and see what they've done or whatever. Yeah. So yeah, so like in, it's not small country, not huge amounts of competition, but yeah, like in my age and weight class or whatever, like I've won it the last kind of couple of years and hope to win it again this year. And yeah, and that, that's a classic example again of what you've said of like, it's just going to the gym a bunch of times, doing the same things a bunch of times, creature habit and slowly but surely you kind of progress. And it's fits and spurts and whatever. And cause it's very numerical, you can like literally see and be like, okay, it went up and then it stayed still for a while and then went up for a bit and stayed still, whatever it may be, you know? Yeah. And I don't know a whole lot about powerlifting. Like I, I got kind of freaked out when I was doing some heavy squats. Like, am I going to damage my spine? Like, am I going to be permanently injured? So I, I, I like, uh, but I never actually formally like competed or did power, but I did all the powerlifting exercises as part of my weight training regimen. And, uh, and, and my understanding is there's the three main exercises, uh, and correct me if I'm wrong, but just for anybody who's not familiar with powerlifting, so you can understand what we're talking about, you're squatting heavy amounts of weight, you're benching heavy amounts of weight and you're, um, what's the term for deadlifting, deadlifting. Thank you. Uh, and essentially those are the three main powerlifting exercises. And then you take the total amount of weight and you add them together and that's your like number essentially. So it's a very quantitative, uh, area of athleticism. Can you talk about like what your training range regime is regimen? Um, and like, uh, how you go about just like when you go to the gym, how frequently you go to the gym, like all that stuff. Just give us a very high level overview of sure. How you've managed to remain the champion for several years in a row and, uh, how you approach this in such a kind of like disciplined routine oriented way, as opposed to just like cramming essentially. Well, so the funny thing is try to do that too. Yeah. So the first year that I became the champion, uh, I was the champion essentially by default because no one else qualified in my age and weight class, right? Such that it, I was the one person who competed, but I still did it and did legal lifts and whatever. So sort of still counts, but like, it's, you know, just to deflate, uh, my ego somewhat. But I think the thing I get to jump back to something that you said that made me feel, uh, it's kind of interesting. It's like that, that fear, right? Like I, that's another thing, I guess there's maybe a running theme in this podcast of like cross cutting things, right? Well, so for me, that fear, like if I've got like, for me, the squats, the scariest one, like when I've got a heavy squat on my back and I need to go do it, that feeling is almost identical to the feeling of like when I've done a bungee jump. And it's also almost identical to the feeling before I go on stage and do a talk or amongst a big crowd or when I've been in a pay negotiation and I like say a number that I feel like a little bit uncomfortable with, or I'm in a job interview or whatever. And it's, it does, it feels like all of these things are kind of training, right? Like in forcing yourself to do things that are maybe uncomfortable to you. And that crossover is kind of useful, right? Um, I guess to your specific question, like I go to the gym, like sort of depends like anywhere between kind of three and five days a week. And I have like a coach, um, shout out if anyone, you will do online programming for His name's Keir White. He's based in Scotland. You can look him up on Instagram. Um, if you're interested, but yeah, he's, he's been great. I've known him before. He was my coach. I've had a few coaches in the past and yeah. And you basically just like go to the gym, lift the weights with the numbers, record a video, send it to your coach, tell him like what you think you did well or badly. He tells you what he think you did well or badly repeats for many years. Right. I guess I've been doing it for like essentially that pattern in some form on and off for like eight or nine years. Um, and I probably have gone, you know, probably coming up to eight or nine years of doing like at least one sort of squat bench or deadlift in a given week for probably that whole time. And yeah, it all sort of adds up. And I think that's the other thing that's sort of nice about it, like about sort of strength training stuff is there's no, there's no like easy fixes, right? You can't go from having never been in the gym to the strongest in the world in a year. Like that's, it's just impossible. Right. Um, and there's also like a lot of things in life, there's shortcuts, right? There's, um, different approaches and different ways of doing things and compromises and And there's things like risky, like, uh, training regimens that are more rigorous, but could increase the likelihood of injury. Or like, I guess like performance and hunting drugs. So like, uh, various sports, including powerlifting have, like in some sports they're banned, right? But in some sports, it's like, you have people who use them, who have their own division over here and people who don't use them, they have their own division over here. And the people who use them are generally much stronger. They look much better, but there are particularly sometimes long-term health consequences of these things. So, and I'm not going to tell anyone what the should or shouldn't be doing, but like, for me, that's like the priority is my health. So I'm not going to go down that route. Um, and yeah, and I think that sort of applies maybe again, tenuous metaphor, but like a little bit back to work in the workplace again, right? Where there's, there are shortcuts to get ahead, right? There are ways of like burning bridges and using people and stomping on other people and lying and being deceptive or exaggerating things or whatever. But again, all of those things feel like if you're really in this stuff for the long game, like that stuff catches up with you. Right. And the amount of people I've worked with where they treat their coworkers appallingly or whatever. And it's like, and then five or 10 years later in their career, they find things are a little bit harder than they used to be. And that's because maybe no one's written anything on the internet about it. Maybe no one works at the same company, but people talk, right? And if you're someone who consistently treats people badly, the tech industry is a surprisingly small place and people hear about it. Right. And the other way as well, right? If you're someone who I've had a bunch of coworkers, I'm sure you have as well, Quincy, where it's like, they're just a saint. And like every interaction I've had with them is amazing. And when I get the chance to like, one of my favorite things in this industry is when one of those people is like, will you give me like a reference for a job? Right. And I'm like, yes. And I can just go on and just be like, let me tell you why this person is absolutely incredible and really amazing. And like, it feels great. Like, it feels great to reward their good behavior with being able to like tell someone else, particularly with what I said before about me being the type of person who doesn't If I actually think they're terrible, then I don't give those references. So, yeah. So one way to look at it is like the wheels of justice turn slowly, but they do turn in the sense of there's like kind of a karma. There is a reputation that may be unspoken in many ways, but like at the end of the day, would you recommend this person for the role? No, I wouldn't recommend them because they're a dick. Right. They're toxic. Uh, they're, they're, they're, they're trying to be like that guy. Like I would encourage everybody to check out this movie. It's, it's not safe for kids, but, uh, I saw this movie called Nightcrawler. It's just like about the sociopath who like climbs the ranks and just, you know, he'll do anything to get ahead. And, and it's repulsive and the acting is incredible. Uh, Jake Gyllenhaal. Um, and, and like, you're going to recognize that these people are out there and, uh, they're not going to be able to sustain themselves longterm. There will be comeuppance eventually for them. And, and that is one of the things that, that gives me like when I have to interact with such a person, they, they give me a little bit of solace. It's like, they can't get away with this forever. Right. Uh, and at the same time, when you encounter somebody who's really chill, but you know, you can tell they've got great potential and they're going places and you can be a helpful in helping them go to those places. Right. You can, you can give them opportunities. You can encourage other people to try them out. Uh, you know, I think, I think that's a really cool thing about the open source. Community and software development in general, I think people are looking out for one another and they are noticing people who are really chill and really good at what they do. And they're elevating those people. Yeah. I think that's, again, something I really loved about software in general is it's right from maybe like the first work experience I ever did when I was like 14 or something, working like it support in like my dad's like office in Edinburgh. Um, just like, there's just an, an ethos of like collaboration and like, oh, you know, a That's cool. Like, let's all learn about that. And like, I, I just, I found that very, like, I, you know, I, I also did work experience. I remember when I was younger in like a law firm and like the contrast between like tech and law could not have been more stark in terms of like the, you know, like admiring and respecting kind of youth and new people coming in and new ways of doing things and new technologies and whatever. And it's in many cases, like the people who you might've expected to be most experienced and most stuck in their ways were often the people who were the most like actively embracing like youth and change and what's happening. And, and that's, I think a beautiful thing about technology, right. Is when we can, when we can try and have that attitude, right. Which doesn't always exist in other industries. And I guess it's maybe particularly rapid right now when everything's changing radically. Yeah. Well, let's talk about that change because I, no, no episode of the Free Code Camp podcast is out, is complete without a discussion of LLM tools, AI code gen, stuff like that. Um, you have been a dev for a long time. Uh, a lot of these tools didn't necessarily just explode onto your radar like they did for a lot of lay people. Like you've seen them gradually improving over time and you've seen the tools get better How do you make sense of, uh, you know, like a lot of managerial decisions and you're a manager too. So you're a perfect person to ask this question to you. Like a lot of the managers who are going out, like we're going to hire fewer developers and we're going to rely more on AI code gen. Yeah. So I don't really know where we're at with a lot of these tools right now. I think it's interesting because there's definitely a lot of people who are pushing narratives pretty hard, who, who are pushing the narratives the hardest, who are themselves like most likely to benefit. Like if you're the, the Claude code, like principal engineer, or if you're the CEO of NVIDIA, of course you're going to tell people that they should stop teaching their kids how to code. I think it's pretty much a direct quote from what he said. And I think the thing is, and I also think on the flip side, like they'll like everything, We have loads of things where like, you can go out and buy bread, right? Like very easily, but yet some people bake it at home, right? Like, why do they do that? Because they want to, they like it. They like the process. They might think it tastes better. It might taste better. Like whatever it may be. Right. And I think there's always going to be room for like an artisanal way of doing things, Like even at peak LLM, right? And I think again, like me loving open source, the beauty of open source is right. If you want to go and run your open source project in a like full speed ahead, let's do everything with LLMs, like a hundred percent all the way, all the time, you can do that. And also if you can, if you want to say, I'm not even going to allow code completion using LLMs for anyone who works on my project, you can do that. Like you, you can decide, right? I think what's more interesting and difficult and nuanced is like the industry as a whole, where does that go? And I don't know what it means long or even medium, maybe even short term for hiring and for kind of maybe more junior folks where things are a little bit difficult there. All I feel like I do know is that like, this is, this is changing things and it is going to be a big deal. And people on maybe hacker news or whatever, who are like, Oh, these tools are useless. They, they can't do anything meaningful. Like you are, if you're, if you're taking that position in, you know, early 2026, you've either not seriously tried any of these tools or you have, you know, not learned how to use them properly or something or whatever it may be, or maybe you're using them in the wrong way on the wrong code base or you are on a bad day or whatever, but there are a lot of people getting a lot of value at these tools. And I think that that's the only bit of it that I find undeniable. And I also feel like in my, you know, in my time in the industry, I guess we are, the internet, you know, coding for the internet was already established by the time I was working professionally. And then I guess the big changes were maybe like mobile or social media or crypto or whatever. Right. I feel like this is going to be bigger for actual software engineers and software engineering than any of those were in the past. Um, and I think it's going to be more like when we went from maybe a similar to, uh, writing high level program languages, um, in terms of like the impact. But I also think most of what is hard about software engineering is not writing the code, Like actually I think you could probably have had a similar conversation around the eras of like higher level programming languages. And like, well, actually, if you look at this compared to assembler, now we don't need to think about any of this stuff anymore. It just gets done for us automatically by the compiler. Right. And it's like, well, yeah, like, and also in the early days of the compiler, right? Like it was similar, right? Where in the early days of the compiler, then you should handwrite your assembler from the code that you really care about. Cause it's going to actually be like good code. Right. And over time that becomes less and less true. Um, I wrote, there's an anecdote back to Linus Torvalds of him working on, uh, if I remember correctly, like when he was working on Git and so much of the software in Git is around like the SHA one hashing function being really fast. So he was like, what's the state of the art? And there was an open SSL one, which is written in assembler for each, uh, architecture to be the fastest. And he was like, Oh, that seems really fast. But he tried his own version just written in C and based on his understanding of C and the, the way the compiler would behave or whatever it outperformed the open SSL version. Right. But that's something of like, maybe when that code was first written, the compiler version would have been trash, but these tools get better. And I think we're seeing a similar thing with LLMs where it might be that like nothing at your work right now is a good fit for LLMs. It doesn't work well with your programming language or your toolkit or your legacy code or whatever it may be. But like, if you think that that's literally going to never change, like, yeah, you, you need to reanalyze things because eventually these tools are going to come and they're going to change the way you do your job. And if you are insistent that you write every character by hand forever, I think some of those people will not have a job in the future. Let's talk about how you use it day to day. Like what tools are you using? How are you using them? To the extent that you can just give us a high level overview of how you've adopted these tools. So my main tools of choice are ChatGPT for just like a separate kind of chat interface of which I'll ask it anything, you know, program related questions, maybe small code snippets, but not like main languages, like not like multiple files or anything like that. And I like that it's kind of quite nice and separate and it's its own thing. And I can do it with my phone and my Mac and jump back and forward between the two. And then I would use opening a codex in the CLI for like my kind of like agentic kind of more vibe coding sort of stuff where I'm not looking at every line of code as it's being written, but I will review it all later, basically, unless it's a complete throwaway one time script sort of thing. And then I have my cursor is my main, like I'm coding, but with kind of AI assistance kind I used to use cursors like kind of agentic mode and questions mode or whatever a bit more, but I now mainly just use cursor because I think it has the best kind of autocomplete. And I like that way of working. So those are my main three drivers, I would say. Well, since you've got a lot of experience using these tools, I'm going to ask you a question that I've asked a lot of devs who use them a lot. Do you think that agents are the future or do you think that code completion itself is where a lot of the utility is going to remain for more senior developers like you, where you're just looking at the chunk of code and you're working directly with it and it's just helping you essentially fill it in faster? Yeah, I think it depends on what you're working on and what the code basis and the languages and whatever. So for example, on Homebrew, like I know Homebrew's code base well enough that I can read a bug report and I'm like, I know which file needs changed, right? And I could prompt an AI to change that file because I know what it is, but it's probably going to take me longer. Like literally, I think in some of those cases to use the agents would take me more keystrokes than it would be to do it manually by hand, right? Even if I gave the agent just like the issue, it's going to like turn around and do its own thing and it's probably not going to quite do it the way that I know that it needs to be done and I know some of the edge cases that maybe aren't documented or whatever. And again, I guess some people could say, maybe rightly, maybe wrongly, well, you could just add all this to your agent's MD or your documentation and over time the agent will get just as good as you. And it's like, yeah, but in this particular case, it's like I have to pull out, you know, 16 years worth of context and put it into text so the agent can understand it. Like I just don't think that's going to happen, right? But on the flip side, I now if I'm working on like a script, right? And so right now I'm doing like a, I'm working on a kind of JIRA to GitHub migration, right? And I'm doing a bunch of data analysis as part of that. And most of my data analysis now is just like, hey, OpenAI Codex, write some code that gives me this output based on the data, right? And I don't even tell it the structure of the data. It goes and looks for it, right? And so far I haven't read any of the code, right? And some people might say, but how do you know it's correct? And it's like by looking at the output, right? And this is code that's not going to be shared or used by anyone else. And once I've got the data crunched how I want it to be crunched, I'm going to throw away the script and never look at it again. And that's definitely something where probably even a year ago, like A, I don't think I would have got the output I was looking for as quickly and B, I think I would have had much more of a sense of like, I must read the code or I'm somehow being irresponsible. But given the sandboxing progressions and stuff that we've had as well, I'm just like, it's I don't need to read this. It feels weird even saying that. Yeah. But I mean, again, if it's software with an audience of one and it's just doing a task and you just care about the quality of the output, if there's some sanity checks, if you can just get a feel for like, oh, it went completely out. This value is an order of magnitude different than it should be. Then that is kind of like the canary in the coal mine that might inspire you to actually go scrutinize the code more. But a lot of this stuff is so routine. It's been done so many times that you don't need to go and reinvent the wheel. But yet there may not be like some package or some ready-made script that you can use. So you just create one. And I think that's one of the big use cases for agents and for like air quotes vibe coding. Everybody gets pissed when they use that term. But essentially, that's what you're doing in the definition of Karpathy is you're not even looking at the code. And you wouldn't do that for production-grade code, of course. But in this use case, it's perfectly serviceable. Yeah. But I mean, but increasingly, there's some cases where even if I was to make that production-grade code, like I would, again, probably a year, year and a half ago, I would have very much operated from the principle of like, I need to be reading this as I go along. Whereas now, I would basically like, I'd basically get it working without ever looking at the And then I will read the code from top to bottom, right? Like, and check every line, tweak certain things in, put it into maybe my house style. Partly, it's just almost like a learning and understanding thing as much as a, actually, I know ultimately it doesn't matter in Ruby if I use, if not, or unless, right? Like, whatever, like, but I prefer one and not the other. And I feel like that's sometimes my way of like, understanding the code is going through and like, fiddling with it, slightly rewriting it and whatever. And I think, I think that's the interesting thing is that I think even then these tools are getting better and they're getting more powerful such that it's closer to what I would have written like much more quickly and more readily, right? Particularly once you kind of learn like a few, like little catchphrases that you can spit in to your agent's MD file or whatever. And I think that that's the thing. It's that question, I guess, like what we talked about before of like, what, what is good enough, right? Like, and I think these tools are very good at getting to good enough exceptionally quickly, I think where things go a bit more is when like, you don't spend the time or effort reading it and you just almost like generate the code and throw it over the wall. And then it's someone else's problem to make sure that that's good enough. Like that's happening certainly a lot in open source. I don't think it's happening as much in the workplace, although I hear stories, but like, I think that's going to be the thing that we're going to be like, nope, like can't do that. If the AI generated it and you did the prompt, then you own that output, right? And you need to get good at understanding that code. And I think my maybe scary prediction for the next couple of years, I think we're probably going to see some very bad things happen at some point where people have just YOLO'd it a bit too hard and whoops, turns out there was no encryption on our database. Whoops, turns out it was publicly accessible. Whoops, everyone's stuff got stolen and someone will go, oh, well, that was ChatsyPT's fault, It's like, well, nope, that's not, that's not how it works. Sorry. Yeah. I mean, same thing with any tools. You are the person wielding those tools. And it's ridiculous to say that, oh, we know how these tools work. There's just token predictors, right? But they're very useful, as you pointed out. So I want to remind everybody that this is an unedited podcast interview. I have no idea how Mike McQuaid is going to answer. And it could be completely in contradiction of my own personal opinion. But I respect his opinion as a dev who's worked for decades at this point, who has worked at the highest levels of the field as an IC, worked as a manager, who's worked as a maintainer of one of the biggest open source projects, certainly in the Mac space. Mike, like, in light of how the field is changing, how would you advise somebody who's getting into the field now, like, what would you recommend they do, uh, that maybe be different from what they would do five years ago? Yeah, it's hard. I've been asked this question a lot and I never feel like I give a great answer. Um, I think the main thing I would probably do is get really good at reading code and reviewing other people's code. Like, so I wrote a blog post along these lines, which is why I think open source maintainers are good at that is because, um, you know, some people, you know, every PR you do at work, it just looks good to me. Right. And you don't really engage and grapple with other people's code and that you can do that and get away with that. And most cultures in many workplaces, no one's going to come back at you and be like, Hey, someone else wrote this code, but you didn't spot the bug. So I'm the site went down. Right. Like ideally that would be, ideally we would have a culture where it's like it's equal responsibility of the person who reviewed it and the person who created it to make sure that that code is correct. But I don't think that's the majority culture. We can change the culture though. We can, we can, but I think that's, that's in some ways where we need to be going because you need to be able to do that for your AI generated code. You're going to need to generate code probably with AI, but you need to be able to read that and understand that and analyze that and catch bugs in that by yourself without another human doing it for you or with you. And how exactly you learn that skill. I don't really know beyond being an open source maintainer, right? Like, and doing a bunch of open source and maybe reviewing other people's code and seeing how other people will do it. But I do think it's maybe a little bit of, if I can be very harsh, intellectual laziness that crept into our discipline that we got away with for a long amount of time that it's like, it's okay that you don't really read or understand anyone else's code and anyone else's code is basically legacy code as far as you're concerned. And you would ideally just rewrite it into your own style. I think that's the big thing that we can't, you can't do that anymore, right? Like you're going to have to use these tools and you're going to have to be able to understand them and catch them when they're doing the wrong thing. And that's a completely different skill to just like be able to write it all from scratch by yourself. And arguably that's gone from, you know, maybe the third, fourth, fifth, most important skill for a software engineer. That's maybe going to be the most important skill. So that's, that's the thing I would get people to focus on. That makes a lot of sense. I mean, yeah, get really good at reading code. That's I think the direct quote of what you said there. And I think that's profound. And that might, I might make the video headline because I think it's, it's, it is a change. Right. And I agree with like the intellectual laziness point that you, that you mentioned. I think laziness on a whole across many different fields is going to be on the upswing as people just want to get through their day so they can get back into TikTok or wherever, you know, Skinnerbox they want to put themselves into. But this is a new year. It's 2026. The year is filled with possibilities. What are you going to do with this year? Yeah. I mean, I guess maybe touching a little bit of each of the topics we've touched upon. I guess I want to make homebrew is like great. It's mostly feature complete, but like, I think the, the main area I care about is trying to make it more performant, right? Just trying to make it do things, the same things faster than it previously does. Right. So that's my focus. It was my focus last year. It's my focus this year as well. Like improve her homes and homebrew. Um, I guess like at work, I'm like a CTPO. I want to like grow my teams, like happiness at work, trust at work, output at work, like all of that stuff combined. And then, you know, I guess we talked about powerlifting. I want to win some medals this year. Um, and then just try and be a better dad, husband, friend, human, like hopefully get to And I'm a nicer person than I was at the beginning of it. Mike McQuaid, it's been such a privilege to talk with you and learn more, uh, with your perspectives that you shared. Uh, thanks again for coming on the show. Thanks for having me, Quincy. Yeah. And then everybody tuning in until next week. Happy coding. See you then.
13 January 2026
Like many people who now work with computers, I was told as a child I spent “too much time on screens” and then built a career out of it.
09 January 2026
Minimum Viable Management
Performance reviews have a reputation for being stressful, confusing and often disconnected from reality. Too often they surface feedback that should have been shared months earlier or reduce a year of work into a single rating. In this episode, Mike and Neha unpack why reviews fail and how managers can turn them into a useful summary instead of a shock.
They explore what companies expect from performance reviews, what managers struggle with and what employees actually want to hear. The conversation covers documenting early signals, balancing positive and critical feedback, avoiding ruinous empathy and ensuring no one walks into a review surprised by the outcome. They also discuss practical ways to give feedback throughout the life of a project, align on growth goals and handle mismatches between perception and reality. A grounded, experience-based discussion for anyone responsible for giving or receiving feedback.
hello neha how are you today i'm good how are you yeah wonderful thank you so in some companies and places new year's spring performance review season everyone's favorite time of year um so we're going to talk a little bit about that today i guess starting from that like you obviously did an awful lot of that i get help like what is it that companies want from their managers generally in performance review season okay well yeah there's like what companies want there's what i want and there's what like my reports want i think companies honestly i think they want to check the box i think in terms of just like making sure that there has been at least a point where like feedback is given and if anything has been held back and like held on to it's like a prompt for you to be like okay cool have i been holding on to feedback a little bit too long and i should be providing it i also think that if someone is not doing well and you might be getting to a point where you're like okay cool i don't know if this person is the right fit for the company then you need to have a track record of feedback given that is documented in some way and it needs to go into that performance review well the performance review is a natural regular form that is accepted as evidence that someone is like maybe not performing and i think what's easy or hard about that as a manager especially if you're new or you're just getting to know someone is you might be recognizing a few yellow flags that you don't know if they're red flags yet but if you wait until the second or third data point to be like oh shit we have like a trend you you're going to kick yourself for not documenting it the first time around but that also means that like if you are documenting feedback on someone and it's like temporary thing and it's going to get fixed it feels like risky in a way and you might be like worried about like oh do i really put this on someone's record forever if it's just a temporary thing the right way to do that is you should be documenting if you're recognizing some things and then like explicitly saying hey this is just i've only noticed this once it might go away and then when it goes away you just documented that i went away right and then you can clear the you can clear the track record but you're going to kick yourself if you like because usually what happens is you find out especially when i was early on and i like wasn't as experienced as a manager i'd like be like oh shit this has been going on for nine months and like this is not good anymore and we need to do something about it and then hr i'll come back and they'll say great oh we need to see a track record of three consistent points of feedback with time in between and you're like i can't wait another six months for this to happen with the team so anyway that's like one reason why the company might want it and also like in general the company expects you to be working with them on how they progress the last thing that you want is someone who's doing well that has like no career path and then they leave to go somewhere else because they feel like that's the only prospect they have in growing right and so this is an opportunity for you to check in on that career path make sure that this is what they want give them an opportunity to say what they want and so on what i want is i want to make sure that how a person is thinking about themselves and how others are thinking and how i'm thinking are somewhat aligned i often get very high performers who are so critical of themselves that they will be honing in on the wrong things and they'll be like oh i should have done this i should have done this i should have done this and i'm like none of that matters actually this thing mattered let's like refocus it or let's talk about why that wasn't on your radar and i think it's just like a great opportunity for a really good conversation if done right i think what reports want i think they want more feedback i think like generally they want to know if they're doing well they want to know like and i think that what is under appreciated and they don't always get from their manager is it's always focused on the negative it's always focused on what you could have done but like oh my god you had an incredible year did you know that you grew you grew in these areas did you know that you have this secret talent that you didn't know about and people can actually learn a lot about themselves through both the negative and the positive but only focusing on the positive is a great way to piss off a high performer because they're going to say okay cool you're just flattering me and i don't know if i believe any of it so you have to like find the balance even if you think the world of someone and you think that they should just keep on going you have to like dig deeper you have to think about like their future self so anyway that's a very long monologue from your perspective what have you observed as like what resonates with people and also like what do you wish you would gotten more in this and what do you feel like people don't tell you about what companies want yeah i feel like what i wish i got more of like maybe focusing on like my experiences when i was being managed because that's been the majority of my career i guess one piece you touched on before where it's like you know i'm not gonna self label myself as a high performer but i never got fired i guess um when i was at github at least so i was doing something all right and i guess i remember having a great manager there and i came to performance review time and i github the i still don't understand why really there was the performance process towards the end was you got a rating between zero and 200 and like 100 was like good anything below 100 was not good anything above 100 was like very good or whatever i remember getting like i don't know it was a 120 or 140 or whatever and my manager being like yeah like you've done a great job and i was like what could i do to you know like what could have been better and they're like nothing really and i was like well you didn't give me a 200 so unless you give me a 200 there was something right there's something yeah and you could tell like they were the type of person where they were like you did a good job i don't want to like be negative but as you said like i'm the type person where i want to improve i want to get better at my job and my craft whatever it is and as a result like if someone gives me nothing to go with i'm like well you know like i should be ceo then right like it come on like give me something right even if it's we talked in the past about like unfair feedback like stuff which only in hindsight even that is kind of more helpful than nothing else yeah like this happened i don't know if there's anything we would have known ahead of time to make it different but because it didn't have the impact that we wanted i can't give you more right yeah the other experience i had i guess on the other end of the scale with um not good manager was when i thought i was doing great right this was back when we had people not only do self-review at gethub but like literally give yourself a rating it was either exceeding expectations meeting expectations of not meeting expectations and it's the only time at gethub i got not meeting expectations and i had rated myself as exceeding expectations and i i felt like i felt terrible right like when i got that review right and you know who knows we might be able to talk about this later like i think in hindsight there may have been a bit of thumb being put on the scale where they thought i was doing a good job and their manager thought i wasn't so the manager overruled the review or whatever but like still i think the the thing i took away from that that i've kind of taken into being a manager is that your review should not be a surprise right if someone is either exceeding or not meeting in particular like they should not be going into their yearly review and reading that or that meeting or however it's running your company being like oh i wonder how i'm going to do it should be very obvious if you're not doing well because it's like you've been getting that feedback like again and again and again and it's just not getting addressed right but then the flip side equally like you know some okay some people are high performers and anxious and whatever and we can't you know you can't fix that but you should be trying your best to be like you are doing a good job well done like week after week in your one-on-ones right i mean i think that like that kind of expands or where i want to go with this conversation is expands it to like when should you be giving feedback right so it's like that mid-year or end of year i like for it to be a summary i like for it to i like to also i like to over exceed so it's like i uh i'll go above and beyond try to say like okay cool we've talked about all these data points here it's like a different way to think about it that like maybe we haven't considered before same data points known feedback different way of thinking and like that's where i like to like use my creativity instead of like being like hey there's new feedback that you never heard before you should be giving regular feedback but what does regular feedback mean i think that like obviously if every single conversation every single one-on-one on a weekly basis we're focusing half of it on feedback that's like going to be exhausting as well so what i like to do is like two things one is that after every project we talk about it and we say like what how did it go what went well how's it going right as i get feedback intermittently from other people i want to relay that um and that's like as it's going and essentially like if you think about it and you expand that that's like the life cycle of a project you your reports are working on projects at the beginning you set some goals you set some like okay cool like what's the thing that you're going to push yourself on that you haven't pushed yourself on before what's the thing that you're afraid of what's the thing that you definitely want me to give you feedback on as i like hear it what's something you want me to proactively collect on right that should be a dialogue at the beginning web project and we should have check-ins as we go for milestones and say like okay cool here's this milestone here's how i think we're doing here's how i think we're not doing here's what i'm hearing from other people do you want me to collect anything else and then by the end it's like how did it go and like depending on how senior an engineer is right like a junior engineer might have three or four projects within a six month period and so they should have like three or four at least unique points where we're like okay let's talk about how it went let's talk about what could be better so that the end at that mid-year end of your review it's a summary i also like to do another thing so i started doing this when i was managing managers which is so now i can't control all the feedback they're getting i can control the feedback my managers are getting but now the reports need to get feedback too and the problem is that like we're as engineering managers engineering directors etc you're just like always working you're working on the project you're thinking about how the project is going um you're thinking about company politics you're planning a year ahead of time it's so hard to sometimes take a step back on each individual career um and so i like to do like a perf review gut check like at a halfway point or at a quarter point so like every quarter between like a review period i will use my team meeting to be like okay cool write down all of your reports write down the rating that you think that they are on track for and then write down on a scale of one to five how surprised you think they'll be to hear that and if they're taking this exercise seriously it is statistically likely that at least two or three people would be like oh they might be surprised to hear this right and that's because you haven't gotten around to it or you plan on getting to it or like you just haven't gotten a second to think about it my job as someone who's managing managers is to create space for things that don't happen right and so like if they haven't had the wherewithal or the time to think about like how these individuals are doing or like feedback that might be held on to i want to create time and some sort of format to get people to think about it and then act on it right yeah so i guess one of the immediate follow-up questions for me on the managing manager stuff is and this is something it's not an experience i've had myself yet um but i've seen it a bunch and it seems really hard right so i'm hoping i don't get it there but like how do you handle when there's a big mismatch between if you're managing someone and then they think this person on their team is doing a great job and you're like they are not doing a great job right like i love this a lot yeah i'm sure let's assume like for the sake of this argument that like you're right because like you've had a bunch of feedback from a bunch of other teams and blah blah or an objective measurement whatever like how how do you go about handling those types of conversations yeah so it's like essentially what's happening is i'm talking to my report my report saying they're doing excellent work and i'm hearing otherwise and i'm like you've got this information i've got this information we need to reconcile it and you cannot ignore the fact that i'm hearing otherwise right you are not allowed to ignore the fact that i'm hearing otherwise so either everyone is wrong besides you or there's something to hear and sometimes that fits into one one-on-one sometimes it doesn't and sometimes there has to be multiple sessions where i'm like okay look this is what i'm hearing if they're like that's not possible that's not true i will go and i'll say i'll go find people to be like cool would you be willing for this manager to talk to you and hear from you directly and almost prep some people because they're like unwilling to give feedback directly and they'll only give it to me and be like well it's not an option at this point you need to go say something and so getting the manager to talk to those people so um i have an example in mind and i'm trying to think of how much i can redact this or not but yeah i had like i had a report who really thought that their report was doing well i'd heard otherwise i heard a lot of cases otherwise that person was just like oh those are like i heard about that but i don't think it's a big deal and i was like well i do now you have to talk to them all and so i made this person talk to them all they still came back and they're like i heard each individual case and if you pick apart every case there's flaws in each one and i'm like doesn't matter the collective impression is that more people don't want to work with this person anymore and you are now accountable for that impact and you need regardless of whether you think that's true or not these things have happened and people need to work with this person and people need to be excited about working with this person so either you can agree with the feedback or you have to figure out how you're going to change this right so i try to almost shift it from like i think some people get really protective over individuals and they're more defensive because it's a feedback against a person and so i try to shift the problem to a person to like a tangible problem that's like more objective that you can talk about which is like okay cool well do we all agree that people need to be excited to work with this person okay well that's not true so now you've just solved that problem right yeah and then ultimately if they're not giving feedback and i'm seeing that there is a disconnect then there's a problem with my manager yep yeah and i think that's that's the trickiest time and i think feel like that's the one that i've seen on various sides a bunch of times right is when you have someone in management where they have maybe it's ruinous empathy maybe it's conflict avoidance whatever it may be and they they sort of know there's a problem there but like they're like oh but this person's gonna be really upset or really disappointed or i guess like sometimes there's a bit of a friendship there and they're like oh i don't want to do that to my friend or or also i guess the flip side right where it can sometimes be i was just you know this person's my senior peer i just became their manager like they've been in this industry a lot longer than i am like who am i to tell them what to do like i think there's all sorts of reasons that can happen but yeah i just think it's it's just so important to give that feedback and get it out there like a little experiment i've kind of been doing is whenever i get a new report i basically try and set expectations literally in our first one-on-one i'm like look what we're gonna do is because it's neither of us are gonna like this particularly but like i'm gonna try and say something critical every single one-on-one just so we'd get in the practice of like knowing what it is and usually the first one-on-one is just like the a safe go-to i have is like you know more about some of the stuff than i do and you you rarely contradict me when i'm wrong please start contradicting me when i'm wrong because you know more than i do right so it can be almost like a sort of backhanded critique when it's like i'm criticizing myself as much as them right but yeah i think just like getting in that pattern of behavior is really helpful because i think that's maybe sometimes where it comes from is if like critical feedback is this you know great class in case of emergency thing that you only ever do on rare occasion then it's like the first time you're going to do it it's going to be terrifying in every relationship but if you just get used to doing it a little bit all the time then it's like you can have that conversation well i mean i think it's because if people are just get really used to the like the first time that they hear negative feedback there's a consequence associated with it right away and like their job might be on the line right so it's like if you normalize hey i'm going to give you constructive feedback and you can do something about it and then you actually your career gets better because you did something about it because we had time and we're talking about it frequently then they can have a positive association with negative feedback right or constructive feedback i also think that like you know sometimes people build up that conversation in their head and there's just like a lot of prompts you can use to help you kind of phrase it and even think about it to be like hey something i'm concerned about is or uh something i feel like i've been waiting for more data on is so it's like okay cool it's not a concern yet right like this is not like negative feedback i'm just like i saw two data points here and like i want a third one before i say it's like a thing you can still tell someone right like hey it's just a first data point so if it's a trend it's not a good thing if it's like something that's just like a one-time thing it's not a big deal right you can start talking about those things more regularly so i think as a manager you it's helpful to sometimes have those prompts and then have a way to phrase it so that you don't have to build up the conversation in your head right yep yeah and my experience has been with high performers often as well like you only need to tell them once right like but so if you wait till you've like amassed this portfolio of like oh you've been doing this thing every one-on-one for the last year and i didn't like it right then it's like well you wasted like 11 and a half months where for a lot of people right away exactly you could just say something exactly right and i think that's the other part of as well i think you're totally right to like suggest that you know there's prompts and ways of doing it and optimum communication styles but i still think with some of this stuff it's like look if if you can't think of a good way to say it you probably still are better to say something even if you have to you know apologize for how you phrased it or whatever afterwards then not say anything at all right because it's just that when that builds and you also see in some again i've not really seen this directly while i have been a manager but being friends with enough managers you see that resentment start to build as well where sometimes they're like getting really pissed off with someone on their team and that person doesn't even know that they're pissed off yeah yeah right like and it's like well you need to get that release out there and like start communicating with that person because it's not fair for them for you to be kind of like building up all this frustration that they don't even know about and you're not dealing with just because you aren't sure how or don't feel ready or able or whatever it may be i think uh it's like the most annoying phrase to receive and like my favorite phrase to provide um knowing it's going to annoy them but like you know when someone's complaining about someone your report your peer you're like have you told them why are you telling me it's okay to tell me if you're like using it as a way to process what you want to say and you're like looking for validation as to like whether that's something that is worth mentioning the answer is like almost always yes unless like i don't know you're kind of coming out of left field and you're not thinking about things correctly but it's like okay cool well i go tell them then like go it's it's been with me long enough i want this release for my plate like go tell them and as an individual you can catch yourself if you if you're ranting about someone and then any peer any ic also gets this right you get someone who's like ranting to you about someone else and like the question should be have you told them or if you want to be more open what have you told them so far right how is it going when you give him this feedback oh i haven't said anything hmm sounds like we should do something about that right um yeah i remember another funny github interaction is you know perhaps being like british and dealing with americans or whatever um like i remember one time saying like getting someone to read some message and say um you know do i seem too mad in this message and they read it and they said you don't seem mad at all and you clearly are very mad so like you should probably make your message maybe sound a bit more mad because this person is gonna read this and think that like there's absolutely no problem here and there is clearly a problem here because you you're very upset right like yeah i think that's the part of as well and i i think you know it's maybe it could almost be its entire own podcast about ranting or venting or whatever and i think being on either side of that i think it's tricky because there's definitely times where you need to catch yourself or help catch the other person and be like look is this how is this helping are you making a plan right now or are you just speaking to someone about this who is not going to push back because they agree and that makes you feel like you've sort of dealt with the problem you have you haven't you're just you know preaching to the choir and they already agree with you and you actually probably need to like suck it up a little and go and have the difficult conversation with the person who's not going to receive it like me being like oh yeah i hate them too yeah like and by all means get your friends or peers or manager or whoever or people you respect or people mentoring you to help you figure out how to have that conversation but like that's not a replacement for having the conversation yeah a hundred percent and i think like i i've also seen leaders get upset that people are talking about things in private channels or in secluded spaces i want to differentiate between like people need safe spaces to process feelings um the ownership is that on an individual basis you if you're going to distract everyone with your feelings you now have the responsibility of helping people get back to their jobs after they had to listen to you rant about something right so what is the you just said this right like what's the point is the point that you're like trying to get validation to see whether this is like worth saying something about is the purpose that you are still trying to articulate why you're feeling and you you're someone who processes out loud or are you just interested in distracting everyone with your feelings right like if if that if you if it's not one of the first two or i'm sure there's a few other reasons that i can't think of then it's like it's distracting and then on the other side as a friend who's listening to someone rant like no one wants to solve right away right rude right like you have to be like that sucks but then if you have someone who's consistently not doing anything about it you're just stuck in that position forever and like uh maybe you're okay with that but like that person needs to go do something about it and like if you're a real friend then you're going to be like okay cool ready for you as you process these emotions out loud but i want to make sure you're doing something about it and you gotta help them out of their comfort zone right yep yeah and i think that's the thing and sometimes the situations where either they can't do anything about it or they've they've done it they've delivered the feedback to the person that person's on a pip or that person's getting an aggregate performance view in three months or whatever right and then sometimes it's helping the other person or yourself and sometimes like you know it could be a report as well in those times being like i i'm here for your this is very frustrating situation but us talking about it for 30 minutes every week is making you feel worse it's not making you feel better it's sort of just you're picking the scab like every week and maybe you need to just move on and wait for the next step and put this on pause for three months until there's something we can actually do about it and then we can like revisit but for now you're just upsetting yourself right and as you say often upsetting other people the team you're whoever you're talking to right yeah and like there's exceptions to every rule and like these are all just we're speaking from experience that we've been in these situations before i'm probably on both sides right and so it's like there are cases where this is totally true um something else i was thinking about when it comes to doing reviews like why do we even do reviews in the first place right like for me i don't necessarily you know sometimes these reviews have like eight to 15 questions that you have to answer and like i ain't about that every company has their own process and they have like a way that they like to do things but i really like to boil it down to just a few things which is like what are three things that you did in the last period that you're really proud of that like maybe you didn't think you could do and you did and like tell me about those things right not three things that went well because some of those things are in your wheelhouse and like love that for you but like what about pushing yourself what are three things that you thought were going to go fine and didn't go and like you want to own that and you want to begin a conversation around it and then like what do you want to push yourself on and like that i think i want to hear that for my reports and i think that my reports owe it to me to hear what i was surprised by positively surprised not positively surprised negatively surprised right and like where i want them to push themselves right and be like hey months every two months every three months every six months you should be doing something risky and you should be trying something and if we agree on what you try on then i can help mitigate that risk for you and i can make it a safe space for you to try that and then we can agree on something and then you're growing and you're trying something and as our manager if i'm actually thinking about where you could grow into and how you could be there's like a thousand paths so i want to make sure that out of my box and out of your box we pick one that like is mutual and we're like okay cool we agree on this one this is both something that we want we both like see the potential of this let's like try it out together and i feel like that's that's so much better of a conversation than like well you did this and it didn't go well like i kind of want to skip past some of that and talk about what was surprising and i really do want to hear about people like what comes to mind when you think oh i could have done this better right and like some of those things as i said earlier in the conversation are not a big deal and i like want them to focus on the things that matter right yep 100 i think that's a nice summary to finish well thank you neha like i feel like i've imparted a huge amount of euros than this time but yeah and good luck to everyone else who's working on reviews an arduous process we didn't even talk about collecting feedback and the importance of that but like good luck and uh you know the next period will come again so you always get another chance oh yeah to that see you again soon bye
29 December 2025
Minimum Viable Management
In this episode, Mike and Neha are joined by Denise, an engineering leader and former colleague from GitHub and Pivotal, to unpack the reality of workplace politics and why ignoring them is not a neutral choice. Drawing on Denise’s LeadDev talk and hard-earned lessons from management and senior IC roles, the conversation explores political capital, information asymmetry, allyship and the idea of “table flips” as a finite currency.
Together they discuss when to spend influence, when to hold it back and how privilege shapes who gets heard. From advocating for promotions to using power responsibly on the way out of an organisation, this is a practical and candid look at how to navigate work under capitalism without burning out or selling yourself short.
Hello, everyone. We are back. Neha and I have mostly recovered from plagues, I think. And we decided, instead of you just listening to us cough for a full 30 minutes again, that we could maybe bring on a guest who's appearing so far not to be coughing. So, Neha, do you want to introduce our guest we've got today? Yes, this is Denise. Denise has worked with me and Mike at GitHub. But I first saw Denise do a talk, I think, with RightSpeakCode a long time ago, and I was captivated. Denise and I, I don't know, at the same time or not, we both worked at Pivotal as well. So, we've had some shared understanding and we got to work on the same team. I got to manage Denise for her first time as a manager, which was, I think, a new experience for both of us, actually. I was just new to managing managers as well. And since then, she's gone off to do amazing things everywhere. And most recently, I had the pleasure of watching Denise do a talk at Lead Dev that I felt like struck such a strong chord with me because it was stuff that we talked about a lot and stuff that Mike and I have talked about a lot. And it's about like politics in the workplace. So, if you watch any one talk on the Lead Dev website, her talk is called Leading Sustainably When Everything is on Fire. And I'll give my own summary if you want, and then I'll let Denise kind of talk about herself and highlight any other points you wanted to make. What resonated with me was that, you know, as managers, we navigate information asymmetry on our team. And as you can see, she's used every word very carefully. You don't let everything through. You don't prevent everything. You navigate it. You figure out what to let through. And that asymmetry and acknowledging that that asymmetry exists is a very big part of being a manager. She introduced this like currency called table flips. So, it's like a way to quantify political capital in terms of like how you could spend it. And usually you think about like accruing it instead of spending it. And so, Denise really flips the table on how to talk about it. And then I think there was another quote that I wrote down because I loved it so much. And it was about making, especially when you're trying to think about what to move and what not to move, you can't move every boulder. And so, she said, it's about making good tactical decisions around the deployment around political capital. And so, I just feel like I love talking to Denise about these things because every word she selected is like very careful and very intentional. And she really thinks about the agency of choice and the level of responsibility we have when it comes to these things. And so, that's why I'm really excited to have Denise on the podcast. Denise, do you want to add anything and share anything else that you thought about when you were making that talk? Yeah. Thanks so much to Nehan Mike for having me on the podcast. Very excited to be here. It's been a hot second since I've done any podcast, actually. So, this is super fun. Yeah, I was asked by LeadDev to do the talk back in January, February. So, the worst thing that you can do to me is ask me to do a talk like nine months in advance because I will just be spiraling about what I'm going to talk about for nine months. And so, I think I landed on the topic of basically wanting to talk about politics at work, which is obviously a huge topic. And I'm still relatively new to management. I haven't been doing management for decades. I've been doing it for a couple of years now. So, I didn't feel like I was positioned to give the, you know, like, here's the end-all guide to navigating politics in the workplace. I didn't feel comfortable coming at it from that angle. So, it was extremely, the whole talk was extremely informed by my personal experiences of making mistakes in this area. And then learning from those mistakes and applying what I learned to my management practice to try to help others avoid the same kind of mistakes that I made early career about not understanding, not understanding the basic premise that everything you do at work involves political capital. And I know that is an uncomfortable thing to think about for a lot of us, especially a lot of us who come from very technical backgrounds. We think that things should be meritocratic. We think that things, we should be judged on the fruits of our effort. It's our, you know, objective, measured, measurable outcomes, that kind of thing. But my experience over the last, you know, decade plus of being in the tech industry has shown that repeatedly, that's not true. Repeatedly, it's unfortunately not good enough to just do a really, really good job at work every day. As you get into the higher ends of the career ladder or want to go into the leadership track, building an understanding about workplace politics is actually a pretty critical survival tactic, I think both for yourself and eventually for the team that you will be responsible for. You know, what this makes me think about is like when I first met Mike at GitHub, he immediately was looking for a way to add value because I like, I'm suspicious to anyone who's nice to me, which is due to childhood trauma that we are not going to talk about right now. I was like, what is Mike up to? And I actually think that Mike's really good at building political capital. He kind of understands the game, especially when new people come in. And I'm kind of curious, Mike, from like, inside your head, how do you think about that? Yeah, I guess like, it's funny, because the way you were talking about kind of table flips and stuff earlier, like, the word I've always used internally is like karma, not that I believe in kind of like, philosophical karma, or whatever, on a real religious sense. But I definitely like see in the workplace, right? Where if, if you're someone who just like takes, takes, takes all the time, then generally people stop wanting to help you. And if you're someone who gives a lot, then you kind of build up or political capital or ability to table flip or whatever you want to call it. Right. And I guess I, I realized in GitHub, as GitHub kind of grew, I guess, in my case, for context, for anyone listening, I joined when it was about 200 people, I left when it was like, just under 4000. Seeing like, as the company gets bigger, you, as Denise said earlier, like, you can't just do a great job and hope that everyone notices or whatever, like, you have to, like, be a bit more strategic about how I'm going to get things done. And who's, who do I need to make happy to get this over the line or whatever it may be. And also just sometimes being like, okay, I'm just going to do this and maybe break some rules. And it's going to piss people off. But do I have enough karma in the bank that this is going to stop me getting fired? Right. Because again, for me, like that was the other part of the currency is that like, on one side is success, influence, getting what I want done. And then the other side is, everyone hates me, I get fired, whatever it may be, right? Yeah, I think so. And I think that like, you're good at sussing out someone who's new and kind of figuring out how they fit into the big picture. That's like, also a really critical part about being able to navigate a company is like, figuring out what they are, like, Denise had this like, diagram of like, okay, cool, you might have political capital, but does your manager have political capital? And what about like, their peers? And like, it's not enough for you to do it yourself, you have to figure out how everyone fits into the puzzle. So Denise, I was kind of curious, if you had any like, major realizations around political capital and leadership, either recently, or like one that's like, stuck with you for a really long time? My current manager uses the phrase, I am cloaked in political capital all the time as in kind of a healthy way. He recognizes that as a white guy, you know, in management, there are a lot of things that he can get away with. And that was having this kind of conversation with my manager over and over again, this past year has been one of the sort of like, you know, inputs into the talk, I spend quite a lot of time pondering how, you know, white guys specifically do have more ability to, you know, kind of do what they I also realized I didn't do this on purpose, the mug that I have right now. The just like, it's a cartoon of a cat saying, I do what I want, putting like middle fingers up, which I completely just grabbed by accident this morning. That's the goal. That's the goal in life. Yeah, exactly. This is what we all aspire for in a perfect world where we all have a perfect symmetry of political capital access. That's what we can all do. But one thing I have been thinking about more recently is if you just have political capital and nothing else, then like, what is your responsibility? So I'll give like, try to make that a little more concrete. I've seen people get to the end of their journey with an organization where they sort of realize, all right, I've, you know, I've learned all I can here. I've done the work that I want to do here. Maybe it's time for me to move on. But sometimes when you get to that stage, you still have a lot of political capital left in the bank, actually. And so one of my peers recently left the company, also a white man who really like leaned into this. And I thought that was so cool. So he, first of all, he's, he's in the EU where they have super, super long notice periods. So he was like, he had a three month notice period, and he absolutely just lit things to fire on the way out. And I thought that was so great. It's kind of like it can sometimes the fact that the company knows you're leaving can sometimes dilute the impact of you doing this, because they just sort of write you off as like, oh, he's out the door anyway. He doesn't really care. So maybe let's not like, you know, really deeply engage with the question he's asking. But I did think it was really cool how on the way out, he would just turn up to AMAs and be like, hey, remember when six months ago, you said this was going to happen? What's the timeline on that? And still, you know, diplomatic courtesy of like, you know, not not directly calling people out, but I'm still asking pointed questions and trying to create some accountability. So I don't know, like I, it's an interesting time, I think with like, the industry is is obviously changing a lot. I think a lot of the rules are being rewritten in an age when every company is getting on the AI bandwagon and the standards for, you know, like what constitutes good performance are changing a lot. I don't know that I necessarily want to get deeply into AI. But I think it's one thing that I've been thinking about since the talk is, yeah, just sort of this theme of like, if you have political capital and nothing else, if you don't have motivation, if you don't have a reason to engage with a long term vision of your team or your company, then what are some useful things you can still do? Yeah, I also think that's maybe where politics kind of gets a bad name, right? Is because people like the, I guess, the case study example of what people don't like about politics is when people exercise political capital purely for personal, like, let's say monetary game, right? So I'm just trying to get promoted and a pay rise and a bonus and more headcount purely so I can like build my empire. And like, I think that understandably makes people feel gross if it's done in a way that only benefits you, right? Whereas, even while you were talking, Denise, it's like, I, I'm too much of a kind of scaredy cat to light things on fire too much on my way out of places, but like something I, I remember I did do when I knew I was kind of getting to the end of GitHub is I basically had a list of people who I felt were like in my org who should have a promotion and I'm like, I'm going to go and dedicate a ridiculous amount of my time to trying to get those people promoted on the way out. I was able to get a bunch of them promoted and that felt really good, right? And again, like, that's the type of thing where it's like, you know, if you go from advocating for one promotion to 10 in a six month period, that kind of like burns some bridges in some ways, but also in other ways, obviously like builds bridges and you're left with kind of a sense that like, Hey, this is good. And also it's, it looks less naked. It doesn't look like I'm trying to almost like put all my pawns in the right places or whatever. When you're doing that on your way out, it looks like you're just trying to build people up. And I, I guess I would say to people who might be listening, who are like, I don't know, not unsure about getting involved with politics or whatever. If, if you're still unconvinced that you have to, then another way of looking at it is like, well, if you're like trying to be a good person and trying to help people at work, then you can't do that without political capital. Right. And if, if you almost like see a bunch of people who are playing politics and winning in a way that you don't like, it's like, well, maybe you got to play the game. If you want to like, let your team win. Right. I just wanted to respond to Mike's point and say that it's so interesting hearing Mike talk about advocating for other people to get promoted because at GitHub, you were never a manager. You were a staff engineer and then later principal engineer at GitHub. And that's so cool because the talk that I did at LeadDev was mostly pitched at engineering managers, but definitely like a huge part of it is that people at the senior plus level also have political capital. Everybody has a little bit, but I wouldn't really expect junior and mid-level engineers that, you know, you, you put your own oxygen mask on at that stage, but at the senior plus levels, everyone does have a role to play in thinking about how you spend your political capital. And you absolutely, this is one of the, the ways, like when we talk about leading from the back of the room or leading without proper, without, you know, formal authority, like this is one of those things. Yeah. And I think like also going back to what Mike said around why should I engage in politics if it's so icky, it is like, there's a natural equilibrium and there's like a natural way that like things will fall into place. And if you don't like it, then you have to get into the ring. Right. And let's be real. It is not going to be the natural equilibrium of a company is not going to be in a way that like benefits the employees the most because that's like not, you know, uh, that's not how capitalistic societies work. Um, and so obviously it's going to be a way that benefits the business or something else. And so if you want to like as a manager, or as you grow in the leadership chain, you want to put your thumb on the scale on something. Now you can't put your thumb on the scale on everything. And it, because if you put your thumb on the scale and everything, one, it's diluted to, you spend it all at once. And three, you're going to be putting your thumb on the scale on things that don't move. And that if you keep on doing that and you expend energy on something that doesn't change, you will burn out. And so you have to know, like, you know, one is understand accruing political capital level one level two is like spending political capital. And then level three is like knowing when to spend political capital. So you don't burn out as part of it. Right. I think like when you were talking, Denise, I was like, okay, so as a non white man, I may not have the same political capital as someone else does. And I want to motivate them to use political capital in a certain way. Like how do you motivate someone else to use political capital? And like, how do you assess it and then like understand and motivate someone else to use it? Mike, my question for you, which is like, not fully spicy, but a little spicy. Have you ever felt like someone was approaching you and like asking you to like blatantly spend your political capital on something? And like, when have you been like, no? And when have you been like, yes, yes, I have. Often that person was called Neha. I was, I was going to joke about that earlier. Neha and I would sometimes have these like little strategies in our one-on-one where it's like, look, is this going to come best from like a principal engineer, an open source maintainer, like the best manager GitHub's ever seen, the best director GitHub's ever seen. Almost like part when we had the same goals in mind, almost like which of us going in first is going to have a better impact there. Yeah. And like, obviously, you know, like I, as a white man, I'm not aware of the, the level of privilege I have in certain ways. I don't know what it's like to not be me, but you know, there was a certain amount of that in our discussions as well, right? Where you, you know, people in the organization who are like, look, like if it's coming from a woman of color or a white man, they're going to react the same. And then, you know, the people in the organization who it's like, yeah, that person's going to instinctively have their backup for people coming in who don't look and sound like them. So maybe someone else goes in first and that, you know, I think that's the thing. Like for me, it's all about trying to be pragmatic, right? Like I think, uh, Denise and I were talking a little bit before we got started actually about how, so GitHub staff engineer, apologies. I'm going to butcher his name, Sean Godek. I think something like that. And he works, yeah, I think he works on a team with a mutual friend of the podcast, human long nowadays. Um, but he had a post recently where he was saying software engineers should be a little bit cynical in which one of the things that kind of made me think reading about it was like about how often like I see software engineers can be so incredibly idealistic about like, that's, we'll have the code and the tech and the architecture can all be beautiful and pure and whatever. But then like, Oh, politics and like maybe even like making people like me at work, like, Oh, that stuff's kind of icky and messy. And like, I'm going to be sort of cynical about that. And just his idea of being like, you know, it makes a bit, you know, you should be aware of the politics and how that all works in an organization. And you do need to be like, not a hundred percent cynical about it, but if you're like a hundred percent idealistic about it, you're going to, I guess, as you said earlier, Neha, like burn out. And to your metaphor about table flips, Denise, like, that's what I really like about that. Right. It reminded me that metaphor as well. Like I'm sure all of us had a wide variety of teachers in our schooling experience. Right. Like, and the difference between the teachers who like lost their shit regularly and you would just tune it out because it was just happening so often the teacher, the teacher who like you were taught by them for five years and only once did they properly lose their shit. And when that happens, you're like, shit. Oh dear. Like this is actually serious. Yeah. Yeah. And I feel like that's the same thing with like table flips at work. Right. Like if you're the type of person, like even aside from political capital, like even almost like the persona you present to your coworkers, if you're just the type of person who just like flies off the handle and it's like, this is unacceptable. This is going to destroy the company about like every single thing. Then people just stop listening to you. Right. But if you can like pick your battles and when you have the political capital, when you've got the right people in place, when people don't think you're just doing it out of self-interest, then I feel like that's when you really get stuff done and can have an impact on the stuff you care about. Right. Yeah. It was really clear. I think to build on, you know, echo everything Mike is saying to build on that. I think I've heard a lot of people talk in the past year about how it's important to bring my whole self to work or I want to engage authentically with work. I want to live my work life in a way that feels true to me. The term table flippers, Neha, do you know where table flippers came from? Do you remember the channel at Pivotal? It might've been after my time. Oh, okay. Okay. So a brief history. Anyway, tell me. Yeah. Table flippers. Like I didn't just make that up actually. That was like the most inside of inside baseball for any people, any women and non-binary people who were at Pivotal R&D, mostly R&D, I think from like 2016 to maybe 2017, 2018. That was the name of a back channel that we had for all female and non-binary employees that there were like hundreds of people in there. This was like the most active back channel that I've ever seen at any workplace, but it was a place to vent and for people to find safety and security in, you know, numbers and shared identity. And one of the most common themes of discussion that came up in that channel were, hey, I had a really great interaction with this, with my white male colleagues. Sometimes it would be negative stories as well, but a lot of it was positive. A lot of it was like, here's a story about allyship. Here's a story about a time that someone on my team really got my back. And so through that back channel, all the women and the non-binary folks in the company kind of learned who are the safe men, who are the safe people we can go to. Yeah. To sort of engage for, like we didn't, we never thought about it as political capital back at that time. But essentially that was what it was. It was like a whisper network of the safe people that you can go to, to ask for political capital and help and that sort of thing. So that's, again, like another one of those, like, here's my very, very personal experience shaped into that, woven into this like larger commentary about, you know, basically like how to, how to survive at work, how to survive under capitalism. I actually edited out a thing in the talk. I wanted to go on this like four minute rant about capitalism, but then I was like, I'm already at 27 minutes, but 25 minute time slot, I need to cut this. But I, I think a lot of like bringing for, for people who, you know, if, if you hear the phrase, I want to bring my whole self to work and I want to live authentically at work, then maybe one way to do that is to figure out how you can send that signal to people who have less privilege than you and figure out like, you know, allyship obviously is a word that we've had for a very, very long time. And I think this is, this is basically an extension of that, right? It almost feels like oversimplifying to just say like, be a good ally. But I think like that is still pretty relevant. I don't know, even in 2025. So I think that's, that's a big part of it. I think I've been pretty lucky in my career so far to never have to directly ask anyone for that help, but to have people come out of the woodwork over and over again, or to just, just show through repeated behavior and repeated action that, you know, like by, by putting messages, a really good example, actually, of a way to indicate this is if you do AMAs, if, if company has like question section with our, come ask our leadership, anything, you're a woman of color, might not be totally safe to ask question like, Hey, what about those RSCs that you promised everyone? But maybe safer for, for someone who does have a little more privilege to say like, Hey, I've heard from a number of my peers that, you know, we're worried about this RSC, you know, whatever sort of frame it that way. Yeah. I mean, I've definitely done that before. Well, I think there's a few interesting layers to it. So now when I'm trying to identify if someone like has like ally potential or like ally interest, right? Like even when you do all of these trainings, these DINB trainings, if you're doing them in a group or in person, right? Like at the end, they'll always be like, Oh, what's your commitment? Right. And like, most people will be like, I want to be more aware of it. And so those people in the trash, like clearly you don't want to change anything, but if someone's like, okay, cool. I want to try one or two things. I think I'm going to try this. I'm like, okay, cool. This person thinks they want to try it. Let's like give them a taste. Right. And so I have like this small list of people in my head that I'm like, okay, cool. Next time I want to ask a question in an MA, I'm going to approach them and I'm going to ask them if they would ask on my behalf. Now, at most of the companies that I've been with, I've accrued political capital pretty quickly and I don't necessarily need someone else to ask a question for me, but that's not why I'm doing it. I'm doing it to see if, Hey, is this person an ally and willing to do it? And if they do, then I will go back to my table flippers channel and I will be like, Hey, I asked this person if they would ask a question for me, they did. Right. Like action, completion, check mark, right? Like we've got one check mark or maybe I'll wait until like three check marks before I like go back and tell the people. But like, I've had also people come to me, you know, we got to work in a team, which was very unique at some point because it was like 45% women and non-binary and it was like 40% people of color. And so finally, once we started bringing in some white men into the group, like cis white men, they would be like, Oh my God, this feels weird because I feel like I'm taking someone's spot. And like, this is all also kind of like shit you can't fully say on stage, but you know, fuck it. Um, uh, I would tell them you have a very important role. Like if you think that there's no place for you on the team, there absolutely is. Because if I like, I mean, it would be kind of great to just have like all women of color on a team, but like at some point you were going to have to connect with the rest of reality, which is like something you talk about in your talk, Denise, like you can't be in a bubble. You need to be in like a porous time-based bubble. And if we're going to re-engage with the world and they're not going to be at the same level of awareness and thinking and practice around, uh, weighing opinions equally, we're going to need some help. And so those people who say like, I don't know if this is like, is it okay that I'm on this team? I'm like, yes, we're going to ask you for help and you're going to do it. And if you're ready and you're committed and you're interested in experiencing something that you might not be able to experience before, because the composition is so fundamentally different with people with different backgrounds, you can have this privilege if you're willing to put in the work. And I absolutely would put everyone to the test. Now it's not like, Oh, cool. I've like marked them for like three tests or whatever, but those things just come up naturally because capitalism. Right. And so my favorite one that always happens is that, I mean, as you go higher and higher up, your manager changes all the time. So it's like every single time I got a new manager, they would look at the team and they'd be like, this is different. I can't tell what it is, but it feels different. Is that bad? And I'd be like, army of white men go. Right. And so like, Mike and others have like a very important responsibility, which was to take those questions and to answer with the late laden with privilege that they naturally had without even thinking or doing anything. I'm just like, Mike, can you just answer the questions and just say truthful things? And all of a sudden, you know, the eye of Sauron would move on. Right. So I don't know if you realized the full extent to, I mean, I was pretty transparent with you, Mike. I'd be like, Mike, you're a white guy. Like, can you do something for me? I don't recommend doing that all the time. But if you get to know someone pretty well, you can be a little bit more transparent about it. I think I was somewhat aware. I think like jumping back to something you talked about earlier, Denise, like, is like the whole, those of us who've been through employee surveys and it's like, you know, do you feel you bring your whole self to work? Like, it's funny because I used to kind of get grumpy about those for lots of reasons. And I've decided now, I think there's like a sweet spot in there, right? Where like 0% bring yourself full self to work is bad, but also in some ways, a hundred percent is also bad. And I think often like people who are, yeah, like people like me grew up as, you know, engineers do the computer science degree, like, you know, like just have a very stereotypical background into tech. It's like, to me, bringing a hundred percent of my full self to work is like, I get to monologue for 30 minutes about code quality. I get to interrupt people whenever I feel like it. Cause I like doing that. You know, it's like all of these things where it's like, well, maybe bring your whole self to work is not doing some of those things. And maybe like being like, I feel like I can bring 75% of myself to work, but actually that's a better version of me than my personal preferences. Like that feels like it sort of loops in with both of what you were saying. And also like this, like kind of like, oh, politics is icky. Like, I feel like I'm compromising myself by doing this. I feel like I'm compromising myself by like asking the question that I don't really care about, but Neha cares about. It's like, well, you know, you're compromising yourself all sorts of ways, right? Maybe this could be a way that you could do so that would actually be good and help people build a better organization and build a better team and all of this kind of good stuff. And maybe like shave off some of your round edges, which, you know, you may or may not have learned in therapy is probably a good idea everywhere in your life, not just in the workplace. So. Yeah. I've learned over the years that I have a better time at work if I'm intentional about what percentage of myself I do bring to work and what percentage I sort of leave at the, you know, at the door. Well, work from home, so not really. But yeah, like one exercise that I used to have, I still sort of do, I still have like my, you know, direct reports do is, especially if you're unsure about what you want to get out of work or if you're feeling lost or confused or you're like, I think I want to leave this company, but I don't know what I want to do next. It's like, sit down and literally make some lists, right? Make one list that says, what are the experiences, skills and relationships that you want to get right now? And make another list that represents what can this job, this like current team, current job with no changes, like what can this situation offer you? And figure out what's in the intersection between those two lists. And that was just like something that I had people do to have them start to think a little bit more intentionally about work and make them realize that you actually do have a little more in your control than you might realize. And the more that you can kind of strategize about how you're going to relate to this job, the less you will find yourself losing to, you know, like hopefully we slow the roll of burnout, A, like that's sort of my interest as a manager, but B, like I want you to, you know, like accept that capitalism is just going to extract from us, right? That's something that none of us have control over. But what you do have control over is like, what do you actually want to extract from your current situation? And then tell me, tell me so that as your manager, I can position you to help you gain those skills and experiences and relationships. And I really try to emphasize relationships because, you know, like look at us three sitting here, like we don't all work in the same place anymore, but relationships are such a huge part of what you should aim to take out of every single job. Because there will be a couple of good people that you work with that you might want to work with again in the future. It's not just, you know, like learn Golang, learn test-driven development, whatever that stuff, like you will eventually learn those things. And I think that when it comes to, you know, like the higher, when you're at the senior, like management level and you're like, everyone goes through the same thing again, we're like, oh God, I don't know what I want to do next. Like, I don't know. I'm not getting, I'm not learning anymore. I'm not growing. What, what, what should I be doing? So probably do the same exercise again, right? Like, but, but think about what are the things that you're currently bringing? So what, what is a hundred percent of yourself? And then like, what is the strategic 75% of yourself that you can afford to still give to the job? And maybe what's the 25% that you need to find and you need to express it in other ways in your life? Like, you know, go, go join, I don't know, improv comedy or something. I haven't done that, but go, go, go do something in your personal life that enriches you and ticks those boxes because it might be, um, unstrategic or it might be dangerous to do some of those things at work. Yeah. I think that, I mean, personally, I feel like I'm never going to bring a hundred percent of myself to work because y'all don't deserve it. Um, like I'll give you a piece of it, um, but not everything, right? Some things can be left to myself. I think what I really liked about what you said, Denise, is that it is really critical to be intentional about what you're doing this for, what you're getting out of it, what you're getting out of these experiences and every single job or every single place you go to is a CN box. And so I even feel like high school was a CN box. College was a CN box, right? Every job is a CN box. And if you feel like you're not growing anymore, test the limits. And if you've never been involved in politics anymore, if you have enough capital to be wrong once or twice, then you can test something out and try something new. And like, understand that the first out of the first three times, two of them are going to be failures. Maybe you get beginner's luck, but you may not necessarily have that continued streak. And if you do have a continued streak of being right every single time, you're not trying hard enough. Like there is no reward if you don't take risk. And it is important to be strategic about how you go about doing that. And when you start to have a purpose and you have something that you're experimenting with, things get fun again and you like can get into the flow. Yeah. That's kind of like a lot of different lessons that you can learn, especially if you might be on your way out and you have some political capital to spend, you can start experimenting a little bit and learn something about yourself on your way out too. Thank you both. That was an amazing conversation. Went a bit differently to how I thought, but this is the beauty of having a guest on who you don't know quite as well as Neha, who I know too well at this point. Thank you so much for joining us, Denise. Thank you, Neha, for being here as ever. And thank you everyone for listening and catch you next time.
19 December 2025
Minimum Viable Management
Product, design and engineering rarely agree and that’s a good thing. In this episode, Mike McQuaid and Neha Batra break down what healthy tension actually looks like, why alignment is overrated and how leaders can turn disagreement into better outcomes.
Hello Neha and hello to everyone listening. Apologies, it's been a wee while since our last podcast. Neha and I both seems to have some form of the plague. If you could hear us discussing before this podcast, it was basically the exorcist going on. We will try to avoid any disgusting noises during this podcast, but if any leak out, then our apologies. The AI editing tool has failed us. How are you today, Neha? A lot better than I was for the last 10 days. Being sick. So I'm just glad we can kind of resume this. It's been a while. So it's good to see you. Yeah, good to see you too. So yeah, do you want to talk about our topic today? Yeah. So Sid Shunker gave us a question in our repo. So we've got a repo, you can file issues. And so we got a really like a plethora of questions and they kind of all revolve around EMs and directors and how they can collaborate with product and design folks. So this is like going beyond engineering and how we collaborate better and like what it looks like when it's good and when it's not. And so I was thinking about how to start. And originally I was like, oh, what does good look like? But no one cares about what good looks like, right? Let's talk about the bad stuff. So I think we should talk about like what healthy tension looks like with product and design. So I'm curious to see here what your thoughts are first. Yeah. So like, I guess my take, like a lot of things is that the, when people have an idea of, I don't know what you would call it, toxic positivity or like, oh, if we're all just sufficiently aligned, then we'll all agree all the time. Like to me, that kind of misrepresents the likely relationship between engineering and product and design. And in some ways, like, you know, there's the old stereotype about like sales and engineers, right? And I think that's a more healthy, maybe extreme example to look at where essentially what makes a salesperson's life really easy is to just promise the customer whatever you need to, to make the deal happen and then sign the deal and then go to engineering and be like, hey, here's all the stuff you have to build. Right. And engineering hates that. But also like what makes engineering life easy and sales life hard is for engineers to just say, hey, we've decided the room out for the next five years. It doesn't matter the size of the sale of the customer. We're not building anything that we don't already think is a good idea. Sorry. Like, right. And I think almost like acknowledging the stereotype is helpful, even if it's not true, because it's, it represents that like probably engineering are going to pull in that direction. Probably sales are going to pull in that direction and that you have to have some sort of healthy, constructive disagreement and meet in the middle. Right. And it's less the case, I think, but with like engineering and product and design, there's often the same sort of healthy tension, right? Like engineering are often thinking about things like tech debt. How can the code be smooth? How can we all be like developing things faster and better? And how can I have a really elegant solution that like the code is beautiful and everyone weeps with joy when they sees it? Like products are again, you know, best case scenario products are thinking directly from the user's perspective and like, well, you know, this has to be kind of a bit kludgy or require a lot of codes or not paying down tech debt, as long as the user gets what they want, then it's great. And then design again, depending on what your designer's background are, that could be anything from, you know, as long as it works great for the user and their experience is great, or I guess not naming any companies, but there's been companies who were criticized recently for as long as it looks really pretty and like marketing copy, like there might even be printed marks and copy, then great. It doesn't matter if it's like a unusable mess that's buggy and whatever, right? So I guess that's the extreme version of each position, right? But like, where, where's the reality? Where's like, what do you actually see happening day to I think I want to break it down also because it becomes a lot easier if you think about the tension of the different personas that we're trying to optimize for. So you mentioned two of them. Well, actually you mentioned all three indirectly. So one is the user and like the user is the easiest one to think about, right? And so, you know, the user kind of makes the requests. We do like, uh, you know, usability testing and stuff. And so that kind of comes back into our, um, backlog and, you know, a user does feast with their eyes first. So it does need to look good, right? To a certain extent, but then it also needs to work. So that's like the first one. And that would be great if we just did what the user wanted, but like we also still have to like stay afloat as a business and we have to make money. And that is a business. So the business is a persona number two. And that's like what you were saying around like customer needs and like what actually drives revenue. And like a lot of times that comes in from sales. The third persona that like, I remember when I worked at Pivotal, uh, I was working with someone named Eric and he was helping me realize that the third persona is the technology, right? Um, when, if you really had to split it between like design product and engineering, which is like not how you're supposed to do it, but if you had to, and everyone was backed into a corner and they had to rep one persona design would represent the user product would represent the business. And then engineering would represent the technology. And I do not believe in siloed roles, but I do believe in making sure that all three of those personas are represented in a conversation. So I remember when, um, I was working with like a startup that was trying to build their MVP and they were like, okay, cool. So like, we're going to have it so that you can type any question in and then it's going to like give a response. Um, and I'm like, okay, well you need to map that on the other, other side, especially since we don't have AI technology. This was like literally 10 years ago. Um, you know, and so it'd probably be easier if you already know what the mappings are to use like a dropdown and they're like, no, no, no, I don't want to use a dropdown. I want to use like radio buttons or maybe it was vice versa or something. You're like, that's literally the same thing on the underside, right? Like I literally, that's how you map it and like how you choose to display it. It doesn't matter. And that's like an engineering perspective, right? You're thinking about the technology, you're thinking about how it's going to grow. And then you're trying to make sure that when you're building it, it's going to build in a way that's going to grow with the business. So you need to be curious about the business. You need to be curious about what the user needs are. And then you have to figure out how to like build this weird machine in a way that's like extensible. The other part is that like, just like you said, Mike, if any one of those sides representing the user, the business or the technology goes too wild, you fall over, right? Like we've seen it so many times. Well, I mean, like, obviously as engineers, we have like our chips on our shoulder and we're like, okay, well, we've seen it so many times where people are like, I don't care. Just build it. Right. And you're like, I can build it. Like I can build it. Now it's going to fall over afterwards. If you exceed this many users, if you try to optimize for this many things, then it doesn't work anymore because we have to like architect it differently and it takes longer. And we're always just talking about like cost and cycle or like scope and time to build. Right. And you have to have that healthy tension. Right. Because as an engineer, I've over optimized for wanting to represent the technology. And I need someone to argue back and be like, no, we still like have a business to run. And you're like, but I want to do this refactor right now. And they're like, can it wait like two weeks and eventually you should come with up with some sort of compromise. So tension, good. Arguments, good. But like any one side going too crazy or not being able to resolve those arguments and then that causing a delay in starting to build something bad. Right. And so I feel like that's kind of like what I think around tension. And I feel like the biggest telltale phrase that like drives me nuts is like when someone asks us right as engineers, can't you just X, Y, Z? And then actually to like come down on the engineering side, our instinct at this point, because we've had this conversation so many times and we haven't seen it resolved well, is we just say no. And like you can't just say no. No is like not a rich conversation. That's not a way to resolve tension. And like we need to be better about like saying no. And like Mike, you and I have had this conversation before. So like what can you say instead of no? Right. If someone's like, can't you just right. And how do you have that conversation? Yeah. I remember we talked about this when we've started working together. And I think it's obviously come up a few times on this podcast. I'm like very good at saying no, but you know, people don't like to hear it. And also like, I think the important thing is it may be because you're saying no, because you have assumed that like all of these things are the case, or you're like based on the current program roadmap or whatever it may be. So yeah, I guess assumptions are in your head, right? Exactly. So like getting them out there, like even if the no is there, it's no, but because ABCD, whatever. Right. But also sometimes I guess you coach me on this of saying like, well, we could do this if we did this or when we do this or unless we do this or whatever. Right. So like right now, kind of, you know, I'm the person who maybe owns the roadmap the most of the organization I'm at and product and engineering reporting to me. And like generally the way I have those conversations now is like, okay, like we have for our roadmap items, we have customers attached, ARR attached, date attached, right? Like the dates, the ordering, everything like that is flexible. But if you're saying, okay, we need this for a 1k ARR customer, right? And it needs to happen tomorrow and it's going to take a month and that's delaying work that we need in a couple of weeks for like a 300k like ARR customer, then it's like, it makes it very easy once you almost can just spell it out. And it's kind of obvious to anyone in the conversation, like why you would do one thing and not the other or whatever. Right. And so I think that's part of it. It's just like getting more information out there and discussing it. I also think sometimes it's the power dynamics involved are interesting because like, I think I remember saying a lot, you know, various previous jobs is to engineers is when they were like, well, the product engineer, sorry, product manager told me to do that. And I'd say, well, okay, you look in the org chart between you and the CEO and tell me where the product engineer is in there. They're not right. So that means that they are not your boss. They do not get to tell you what to do. It means that you, they are a peer who you are collaborating with. Right. And even if they're quite a lot more senior in the product organization than you are in the engineering organization, that's fine. Like bring it to a more senior engineering leader and it's their job to kind of help you figure that stuff out. And I think, you know, that can go in both directions, right. Where I, you sometimes can get a bit of learned helplessness from product or engineering or design, right. where they're just like, well, this side owns this persona or tech debt or whatever. And I can't possibly make them do what they don't want to do. So I'm not going to try. Right. Whereas it works way better if you can just be like, okay, I'm going to state some assumptions. I'm going to try and make some convincing arguments. I might even kind of escalate or, you know, to use a dirty word, play politics or whatever to try and get us some movement or navigation on this. Right. Because again, ideally there is going to be that healthy tension. But if one side just completely capitulates, then you're actually not doing the best thing probably by the business or the customer or whatever. If you're not, if either you're a hundred percent advocating for them without enough information or zero percent advocating for them because like, you know, engineering holds all the keys or whatever it may be. Yeah. I mean, like I get this, the form that it comes to me as is like product or, um, engineering. And I, I keep on saying product, I think like design, I'm kind of like including in the umbrella a little bit, honestly, like we don't, I've, I have not experienced a lot of tension between engineering and design historically. So usually it's between product and engineering, hence us using them so much as the example. Um, I usually get it as product saying engineering is being unreasonable. They're saying no to everything. And they're saying that's impossible. And they're not giving me anything to work with or vice versa. Engineering is saying product is not listening to me. I'm saying no. And like, they say build it anyway. And so as a leader, just like you said, Mike, right? Like they need to bring it to someone that's us, the managers. And so like, first I have to verify, like, okay, is what engineering is saying, is it true? Are they, is it actually impossible to do what they need to do? And then I need to look at the levers, right? The levers are always scope, time, and staffing and quality, right? So it's like, what can we compromise on? And like, my job is to figure out how to quantify that or phrase that in a way that would get product to consider if it's true, if the claim is true. Sometimes engineering is padding the numbers. Sometimes engineering is just like not revealing an assumption that needs to be like brought to surface. And sometimes engineering has a quality level that they're like, well, the last time we did this, we had 200 customers on board immediately. And it fell over. I'm going to say no, right? And you're like, okay, cool. Well, I'm going to go work with product and say, let's only roll on 10 customers in the first two months, and then we can roll on another hundred, right? And so then we can grow with the product, right? And you're trying to just like stage things in a way that would work in a, in a, in like a logical progression so that like engineering building time matches like what the demand is. And so my job is to figure out what the levers are. And just like, as you said, the words are, if, when, unless, right? These are the conditional words that you use. And then you try to see what like product would be willing to accept. And ultimately, um, a lot of time, our job is to go back to engineering and say, I know you hate this. This is where we've landed as a decision. And they're like, but we're building it wrong. Right. And you're like, well, and I think, um, uh, I don't know if Derek will like me calling him out, but he uses this phrase. That's what the money is for. And I've kind of like adapted that and saying like, we'll pay you to build it wrong and then we'll pay you to build it right. Right. So it's like either way, like ultimately the decision is not in your hands. You've given input into a decision. And now your job is given the decision that's come without compromising your work hours and without compromising, like what you're responsible for, because you report to engineering and the org chart, like build it to the best that you can. And if it doesn't work, it doesn't work. Right. Like one of the phrases that pivotal was like, you know, the goal is to build it quickly. Right. So it's like, well, if you're going to do it right, build it quickly, but also like, sometimes it's better to just go and do it wrong as quickly as possible and then get the results and then be able to talk about those results and do something about it afterwards. So I think that like knowing what your levers are, which are scope, time, staffing, which is like the biggest one that I feel like is generally negotiable to be like, like we could build it faster if we got this engineer or we could build it faster if like we increase headcount by a little bit, even just temporarily for two weeks or we reduce and then we go back and then we go back up and then finally quality. Right. And even quality can be like fewer customers at a time. Right. Let's like do a beta and then let's do an alpha. Right. And that's where I've seen like the most leeway where product is like, okay, cool. I don't like it, but we can announce it as a wait list and we can delay by one week to let people off the wait list. And let's just like communicate it that way. And it's all about that, like that back and forth and helping them understand the why and making sure it's fucking believable. Because if you don't do your own research and you don't actually understand what the numbers are, you're going to look real stupid when you like just take engineering at their word. And then later you find out that actually it was fine after all that argument. So, yeah. And then you want to do it as quickly as possible. I think the part of like taking people at their word or whatever is like all of the best part people, design people, engineering people, and this might be most controversial for engineering people, are like at least a bit multifaceted. Right. Like for me, the best of all of those people could, you know, push come to shove, do at least one, if not maybe two of the other roles to some degree if they had to. Right. Because, you know, I think to go back to the design example, I guess I feel like a design engineering dispute, which isn't super common now, but like particularly when back in the era of when, or in some organizations where designers worked primarily in like Photoshop instead of Figma. Right. And it was like, okay, this UI needs to look exactly pixel perfect how the Photoshop looks. Right. And then, you know, you would sometimes get engineers like carving up images and embedding them because that's the only way they could get it to make it look the same. Right. Like that was the type of thing where I feel like it's, you know, we've moved past that a little bit. Right. But like, I think the other thing with being multifaceted is, you know, that word, I always get like a little bit triggered when an engineer says something is impossible because unless you're talking about like building a perpetual motion machine, right. Or solving time travel. Yeah. And MP problem, whatever. Yeah, exactly. Like there are some examples, but it's like most of the time, most of the stuff you're going to be asked to do in a software company is not impossible. It might be, as you say, impossible given team size constraints, roadmap, whatever you want to call it. Right. But if you say that it's your, you know, I haven't read it, but there's like a famous kind of negotiation book that I've heard widely recommended called like getting to yes. Right. And it should be the idea of like, how can we get to a yes here? If I assume that that person is not an idiot and they're not asking this for a completely stupid reason. Right. Then like, let's figure out how we can get them what they want. Right. And the other part of this, sometimes it's like with engineers, like you don't need to get permission for every single little thing. Right. So if, you know, I guess I might mention this before on, on the podcast, but like I had a boss in the past, CEO of a consultant's company and he had a great attitude where it was like here. And this was like, you know, early C++ days or not early C++, but like, you know, earlier C++ days. So like automated testing wasn't quite so massively widespread as it might be now. But his view was like, we write automated tests here. Right. And you do not need the customer's permission to write an automated test. And if the customer tells you to rush something out the door, like he was like, I literally gave you permission to lie to the customer and tell them they are not going to do tests because they perceive that it's going to be quicker. And then just write the tests anyway, because actually we're here to do what's best for the customer and not here to just do what the customer tells us. Right. And I think there's a similar attitude with like engineering and product and design, whatever, sometimes where like, it may be the product manager is like, no, no, just build this in a hacky, filthy way, accumulate. We don't have time to pay down tech debt. We don't have time to write tests, whatever. But again, a good product manager who's worked as an engineer, or maybe even has, you know, done a bit of coding in the past will know that that's a bad idea. I'd probably won't say that, but it might be that they're, it might even be that they just don't acknowledge all the tech debt. And then the engineer reads that as, oh, therefore I can't fix the tech debt. It's like, well, actually you probably can go and improve things as you go along. Right. And there's, there's often a happy middle ground on this stuff. And, you know, I'm sure you and I have also both worked with engineers where if you let them do whatever they wanted, they would just spend the next five years paying down tech debt in a way that to the customer seems to have made absolutely no difference. No, no. All the engineers who would look at it would be like, oh my goodness, this is so, everything's so beautiful here. It's yeah, beautiful code, gorgeous. Gets rewritten the next year. Exactly. Exactly. Like gorgeous code for five minutes and then it's becomes legacy and everyone hates it again. But like, I think that's the important part of this stuff is it's like, look, you know, if you go and if you're told to just work on a feature and you spend 99% of your time working on tech debt, okay, like you're gonna get busted and you should get busted because like that's not really fair or respectful to your coworkers. But if you're like, okay, I want a new feature in the reports like feature or whatever, right? We need new functionality there. If you go in there and the code's a complete dumpster fire, then it's like, by all means, make it a little bit better as you go along as you build a new feature, right? And no one is gonna slap you on the wrists for that. But no, like, I think that I love the term pre factor. So there's like a refactor that's at the end, right? That like usually doesn't go over very well. You build the thing and then you like clean it up after. And then like that, those two weeks that you had reserved to like clean it up, that always gets cut off because you have to move on to the next thing. But if you do the pre factor, which is like, okay, I'm going into this area. In order to make this area of code more usable, we need to pre factor a little bit and like clean it up. So it's like easy to build and then kind of like put those in as you go along. I feel like no one's going to argue with like one or two tickets of like pre factor code as you build it out, right? And like, that's your job as an engineer is to be slick with it, right? Like your job is to take care of the code and your job is to deliver that value, right? Like you're the executor. So you got to figure out how you're going to get that done in a way that like stays under the radar. And like stays under the radar sounds sneaky, but like stays under the radar is a threshold. So you're just trying not to trigger the threshold, which is like, we're not building stuff for our customers and we're not like building value for the company. Um, you mentioned earlier, um, a little bit about like how, um, every, like when you've worked with really good designers and really good product managers, they've been like multifaceted. And I was like curious if you could kind of like paint a picture of like some of the best product managers or designers that you've worked with who were multifaceted and what that looks like. Yeah. I think it varies because I think the multi fat, it has to be almost like multifaceted and that has to be a level of humility there as well. Like I think maybe more product managers, but like product managers who are very recently ex engineers, particularly if they were very senior engineers and essentially sometimes say rarely say, but often like it comes across sometimes when they're saying like, look, if you just let me build this, it would just be easier because I can do this better than you. Right. Like that, that never builds trust or respect or whatever. Right. But at the same time, I think particularly with all the AI tooling we have today, I would question a product manager or designer in a software as a service company who had literally never written a line of code in their life. Right. Like I, you know, even directly you can now. Yeah. Yeah. Yeah, exactly. Like, I mean, even product managers, I know who would describe themselves as like non-technical or whatever. Right. Like, I don't think I know any of those who would write, feel like they could never literally write a code of a line of code ever. Right. Or say like, if there's some HTML, like, and there's a typo, like go in there and submit a pull request to edit that. Right. So like, I think there's a sort of minimum standard there beyond which it's like, look, like you're, what you said earlier, right? Is you need to be able to basically call people's bullshit sometimes, right? When someone says something that's impossible and you need to have enough knowledge to be like, look, we both know it's not actually impossible here. Right. Like we both know that we could do this. Like, let's, I know, I, I sometimes think as well about, I don't know if anyone saw the, there's like the infamous Krizam video on YouTube talking about microservices and that he just, yeah, I'll need to link this to you often, which they have, I'll try and stick it in the show notes or whatever. Basically just like an engineer explaining to a product manager why they can't build something due to microservices. And then, you know, in the end he breaks down and he's like product manager, you stupid little product manager, you know, nothing of my pain. Um, and there's like, it's, it's, I feel like it's something that product managers and engineers can both enjoy. Cause I feel like most of the time they've been on one or both sides of that conversation. And I think that's the thing. It's like, yeah, you need to, even that little line, like, you know, nothing of my pain. Right. It helps if both sides know something of the other side's pain. And again, in the best product management, like relationships, I, again, like maybe a spicy take for a podcast like this, but I can't do it. Like if you're a product manager, who's literally never talked to any customers ever. Right. You're probably not very good at your job. Right. And I think that's one of the things about if you just see it as like, I divinely know what is better and I will tell the engineer what to do and the engineer could probably figure out themselves, but I just have better taste than them. Like you're probably pretty crap at being a product manager. Whereas if you're able to say to the engineers, it's like, Hey, look, I spent 20 hours last week talking to customers on zoom calls, painstakingly write down everything that they like and don't like about given features. Like, do you want to do that? And my experience is most engineers are like, hell no. And it's like, well, cool. Like we, we each have our roles and we can figure out this stuff and you know, whatever. And same deal with designers, right? Like when a good engineer is working with a great designer, right? Like then generally the designer is like, Hey, look, I can make this software really easy to use and I can make it look really nice. And I can tell you like, again, with the state of figment and stuff like that, like often I can just like literally tell you the components to use and the places to do it. And you know, some of the CSS to copy and paste and whatever it may be like, and you can have this thing that you built that looks amazing and is really easy to use and whatever, right? Do you want that? And again, most engineers are like, hell yeah. Like that's a problem that I don't care passionately about that I've been able to have solved for me. Yeah. And that's, I think like that's when this stuff works the best, right? When, when you've got mutual respect, but also a certain amount of like a big part of that person's job, which they're good at is something I really don't want to do. Right. Yeah. I mean, like, I feel like this is where we need to put some respect on their name, right? Like a product manager probably has to interface with leadership. They have to like get all of the incoming requests and believe me, like as someone who somehow sometimes had to step in for product managers, it's messages from the CEO and the CTO and the CPO of all of these new ideas, or like the latest tweets about the project. Right. And then it's the users and the user, you know, usability tests and the user interviews. And it's like also from sales and all of these things saying like, why can't I do this? Do you understand that now that this has been delayed by two weeks that like, we might lose this deal? I don't want to have those conversations. Oh, I do now. Like once you get to a VP level, like you kind of don't get to be fully protected from all of these conversations. Do I want to have these conversations? Absolutely not. Right. They are doing that for you. That's like a hired role. And so of course they have a lot of attention. And when they're coming to you and they're saying like, Hey, is there anything you can do here? Of course, our reaction is going to be that we're annoyed. And we're like, no, I told you no twice. You have to understand that they're taking care of a bunch of stuff that you never want to do. And same thing with designers, right? They've got a design system that they're like trying to stay in accordance with. They're trying to coordinate across the board. They want to make sure that the experience is consistent across the board and they have a lot of considerations and experience and things that we've never done before. So our job is to represent the engineering side and the technology. And then those conversations come together. Right. So I feel like it works really well when we respect each other's side and when we can kind of like pinch hit for each other and understand that at the end of the day, as long as we can make sure that our team knows what's going on, that they can do their best work every single day, that they're like not burning out. Right. In terms of like business needs and that like people have like clarity around what's possible, like live another day and we keep moving forward. Yeah. I think that's it. I think you summed it up pretty well there. Well, yeah, thanks for the question, Sid. It's been nice to be able to have a more or less a whole session on this. And yeah, I feel like we've got a reasonable understanding of what the good and the bad look like for this. But yeah. So thanks everyone for listening. And we'll be with you again, hopefully a little bit sooner next time, assuming we're not plagued. Yeah, probably in the new year. But yeah, we'll see you then. Yep. Have a great time, everyone. Bye. Bye.
18 December 2025
I’ve been following what Justin Searls has been doing with his blog for some time. He’s been leaning into the “POSSE” (Publish on your Own Site, Syndicate Elsewhere) philosophy more and more. In practice, this looks like building your own version of a single-serving social network on your own site and exposing RSS/Atom feeds to other services to consume. Justin recently released POSSE Party which makes this easier by cross-posting to various social networks. I’ve complained for a while about (anti)social networking so I’m always up for new ways to use social networking less.
09 December 2025
The process of software estimation is frustrating for software engineers and those who consume their estimates. Consumers often ask “why can these software engineers not just tell me when it will be done?”.
14 November 2025
Minimum Viable Management
Mike and Neha explore how leaders can recognise when things are going wrong, why admitting mistakes builds trust, how to spot low psychological safety, and the value of written plans, accountability and steady course correction when guiding teams through tough moments.
Hey, Neha, how are you? I'm good. Hey, Mike, how are you? Yeah, good, thanks. Trying to have, for anyone on video, we tried to somewhat equalize our height today so I'm not just like a massive floating head. I probably have a literal and metaphorical bigger head than Neha in real life, but no reason to make a big deal of that. I think that's true. Yeah, no arguments from me. Yeah, awesome. So today we thought we might talk about what you do when things go wrong as a leader. So I guess starting off with maybe like definitions, like Nick, how would you define when things are going wrong or how do you know when things are going wrong? Yeah, I think there's kind of like two forks to the road about when things go wrong. There's like things that like, if you enter into a brand new situation, you are going to like reassess and you're going to try to figure out what, you know, what the vibe is and how people are doing. And so things could be going wrong, not due to your fault. And then if you stay in the road long enough and you get the pleasure, you get to mess things up yourself and then you will inevitably make things go wrong yourself, right? And I think that second, the first bucket is difficult in some ways, but the second bucket of like you actually messing up and things going wrong or things going wrong under your watch are the hard ones because then you have to have that like self-awareness and evaluation to be like, oh man, I messed up. I have to do something. When do things like, what are the signs? I think easiest one is to ask people how things are going. Don't ask if you don't want the answer to be somewhat hurtful. But like I think other signs, right? If you are, if you just see that things aren't getting done, if you see that like, you know, when I took on the VP role for like my last role, I did some AMAs and the questions I got were like harsh and like hurtful and like really intense. And actually, aside from my first role, which were like a bunch of lovely three individuals, in the director role and in the VP role that I entered into where I didn't know the whole team, but I had like somewhat of a reputation for people to feel like they could ask me anything because I always have like an open policy. You can ask me anything as long as it starts from curiosity. I got questions that did not start from curiosity and I took it and I like went with the questions here's what I think you mean and here's what I think we should do about it. But that was a sign for me that like it was almost as if they lacked so much psychological safety or they had been asking questions for so long and hadn't gotten answers that they did not care whether or not they were approaching with curiosity anymore and they like wanted answers and they just wanted someone to come to them. And of course what I did was I answered those questions and then later in writing, well, let's have a little chat. These questions did not approach with curiosity. I'm going to show you how you can transform these questions into curiosity. Like, and now we're going to have you pre-submit some questions so that I can form these with curiosity and not affect everyone. But that was like a big sign to me is just like how people are asking questions, how people are approaching each other and if there's like how much animosity there is. And then like also like honestly asking people how things are going that they wish would change, etc. When people are pointing fingers at each other a lot, right? And they almost have like gotten past the point of accepting fault. I know that things are going well, right? And like I need to start unraveling it and I know it's not going to be some simple thing where I can just say engineering manager, It like it's bubbled to something higher, you know? Yeah. I mean like you're now talking and even at GitHub you swooped into various teams. Sometimes I remember like we were trying to make some of our products more successful and we knew that they weren't working for GitHub. all right, Mike McQuade, can you just like go in and figure out what's going on and why people aren't using this tool? And you did it twice. So like you've swooped into different teams, you've swooped into different areas and then now you're swooping into different companies. What are like your telltale signs where you're like, all right, something's up. I sniff a trail and I need to do something about it. Yeah. I think the first and I guess worst sign is, I guess you sort of talked about in some ways a middle way where you try and give people the space for questions and you just get like sort of animosity back, right? I feel like the step I've seen sometimes is like people have been conditioned to like don't even ask the questions, right? Like just be completely silent and you might do like AMAs or whatever and then people are just- Oh yeah, that's even worse. No one asks you a question at all. No one's saying anything. And in situations like that, sometimes like I've longed for the awful questions that made me look like a dick. Yeah, exactly. Because it's like, at least that's something. And I think, I guess for me, like what I try and do is particularly if people seem really upset or not working is be like, everything after this point is information, right? Even if it's like literally people just like insulting me or not trusting me like it tells me something. And I guess the other thing I like is if I can model the behavior So if I can, again, like we talked previously about screwing up if I can do that and if I could admit fault and people can learn like even the maybe more senior people or can do that and there's not negative consequences for doing so and that makes us all feel nice, then they might do Because again, like I think we've talked but in my mind, in any situation, the person who is convinced that they are 100% right is definitely at least, like essentially the people, I've known a bunch of people that they're not completely in the right, who sometimes are, but I've never met someone who thinks they are completely in the right, completely in the right. So yeah, I just look for is just try and, extract as much information from everyone, anyone who will talk and give as much and then what I might at the time, depending again of psychological safety is that like often, particularly when I deal with engineers, people jump straight to this is the problem and this is what right? Or maybe not even solutioning right away. So trying to almost like tease out like what's the problem and then sometimes you can only figure that out by you speak to three people and then you figure out, underneath all of them is this one problem, right? And let's try and do something about that. and I mean, really valuable here, which is that not all, especially from engineers, you're not necessarily going to get the problem. So just instead of and being like, let's not solutionize, maybe you just let them talk for a bit the problem based on the commonalities of what you're hearing. like actually a really cool pro tip. Yeah. I think that's, I've found that works in lots of areas I guess in open source and stuff like that, where I'm like doing product managerial sort of things. you get the same thing right, where like, I guess my product saying has been like users are like babies in that they are good at crying and signaling that something is wrong, but rarely good at articulating like how the problem should be fixed. Yeah. And I think sometimes like people can sometimes not voice questions or whatever. Like one of it comes from like almost I'm going to get slapped down. psychological safety. there's also kind of maybe the slightly like whether it's, if it's true, like the kind of, well, right. And there's no point because it's a waste And sometimes if it's not true, even the perception of like the, or learned helplessness like we've tried to fix this a bunch can't fix this. So like, there's no point in talking about this or whatever. We'll just accept this is how it is. So the interesting thing here that I'm realizing is that, you know, we both will look at the team to see what the team is internalized to be like, Something's wrong. I like need to unravel this like thread, but there's also like root causes, So it's like, you mentioned apathy, right? leadership apathy, you, you know, as like in positions of leadership can test that right away, So it's like the team perceives apathy be true. And like, mostly it's usually true, To a certain extent. And so just like asking leadership what they think about things the problem is, right? I never see them fully line up, but I do feel like I can get data. like you said, and Laura Hogan's always said this phrase, information is data, which I always love. And so it's like on what's going on. So it's like leadership is ignoring you, look at the roadmap are we shipping? Are we like ever on time for any Those are quantitative, more closer to quantitative or like closer of like, cool. I've found a cent. Now can I validate it understand, okay, are things actually wrong or is it a perception You can fix perception issues pretty quickly. But when things are like, if trust is lost that there is apathy, then you've got a bigger job and you can kind of gauge what you need to do from there, Well, speaking of things from there, you mentioned, one of the most obvious ones, if you're building software, like if the shipping velocity is way down, like most, software engineers want to actually ship things. I guess that would be a starting point, like getting the team people are probably doing that. But yeah, are some other like next steps? you've figured out, you've got a reasonable idea of what the problems are. You've got a reasonable idea of, you know, maybe some next steps that can at least Like what do you do next to actually move things forward? Yeah. So I think that this, this step skip the most is vocalizing that something's And like as a your job is to call like things are not going well and say something. And I think that people say anything because they're to demoralize people and to suck if like they that I admit are wrong. But I think there's an art And usually like your engineers are smarter And they already came They're waiting for you as a leader to tell them figured it So the minute you can be hey, this happened, I'm sorry, we need to do something about it and I'm going to lead the People will oh, fucking finally, leaders figured They see what And that's like a middle of the road, scenario. There's also I think the other part skipped is you come situation, your fault. So you're have to say do this. And it's you're a leader, right? the money is for. you need It does whose fault is not okay to say like, I just problem. The status, come in, that's under And so you apologize for And so you cool. This is Here are that I see. I'm sorry. Here's the it's had on you in order feel validated and here's my feedback on and C. I'm not feedback yet, but give weeks and come back right? And people feel like with a plan intention and a place to give So like, other part skipped is you have a plan and when they So then right away be like, I know that what and they so I'm especially if psychological It's okay want opinions Give them that when put it and ensure there is a retrospective open call that they know that that the something place. So I that's the step is validating validating wrong. And I other path is what is wrong wrong. So you go talk okay, you're Here's what I'm seeing and reconcile you. some time Here's going to Here's that I Give of I think That's really people there's problems unacknowledged. I guess said is step we it. timescale attached here's forward not like in three we might about about something really let's away. I think sometimes with tend action iteration is sometimes across okay plan it's stone to right get feedback Mike's already sorry whatever so need to often being is like change a adopted sometimes looking week like saying saying like is we're we we and we and let's and no because sense we that changed and being then like we've and that iterating and improving tweaking but defaulting I rather we seeking stuff you're solving problems for I if try first is a way make and even sometimes the and least like doing right movement yeah you can change turn changing into a if you communicate which you gave and here's and we're we're you win I back know penchant which prefers actions words immediately when you're a plan action so why don't have and and you plan then you action think people over but observed when you team the say good they anything have just things does action lost like three helping feel like that's and your might confuse as to they realize because that that so tell action the also asterisk you plan a so should consult everyone and I I credit not to plan and they course people that she didn't she people some know what to because consulted that's specifically on both at the down people yeah and often the sometimes delivering plan a any is than an or message Notion whatever that's fine put it somewhere I mean not often you know of I've leaders where plan even for share or of all head is know need 3 12 months what have everyone and head because plan if down at people and to if when happening and you know hit and change similarly that you plan plan written updated information the way so yeah if already you write but question this like particularly of we're anymore the whose that still working how you a make like you over suck and undoing you first all love surprise like be before a I'm people this ask understands going so that ask to person poorly particularly me or is way pissed this so like probably what okay do ask if no I've found that Michaela authored can person but I them hey I'm a the they be someone react whether it's leader or who on someone might neurodivergent and the going heads I've this I know going well let's it let me through logic how and part and learned like a I to do college like young the fun the loudest and over one thinks the but like right and so them I miraculously children happens with well I will I is I by will and they because if taking they a and fit feel and them important the from and you team you me people and and have to ask what what I'm decision but agency fit in yeah think great like a bunch that I doing and think a big is and like I advanced stuff you trying across are and the and like know not primarily exists being and a little and why I what when with effective when retrospectives or I post the people across like in happened particularly infrastructure or there an site vulnerability and you and maybe ask whys framework you leave unturned if properly if have safety that uncover stuff like how first pressed right and bad culture then will oh Mike first shit therefore Mike to not time let's all game bell being streets like in what is through Mike then what and why button that breaks when you should to button fair like position yeah in that needs this because the don't the do and Mike in analogy able of maybe admit right that's work consequence guess that like in I relatively experience I like graduated this of Code to months project some support KD like mail Outlook application so email three where we've and essentially I'm work is okay right nice up I yeah so software my great know work like say to 20 years you right chances are literally wrote deleted being for people you like there's inherent to stuff a that's think be happiness hey I right and these today two five years maybe four it we're like I based on four then it's and we obviously that you provide an which people like all last now but you job right or for didn't customers not you had bet market and changed job and that's hard can it when get fulfillment beautiful everyone most and that's right lose pegs and further because upset or turn positive rebuilding quite for think easy points trust telling people going to leaders we individual and good do telling plan those it's one jar it's huge those up that to which one we're not from marbles can and miss free of news team towards culmination action being louder and better that's piece okay right to to attention celebrate and and decisions sometimes people those or a re-correct yeah I think to some before important this again it's if we're right don't then that's but like we're and that's right I'm primary plan hopefully from and given we're the if allow to change dramatically feedback also being I with and go and my or like you like be you Sarah do it's this decided and your back my matter we've like consensus we've an of move we many but going for that like not I but maybe do me I'm up I'm like right just like about modeling and trying you like yourself you other well tuning any this if email either like mikemcquade.com YouTube or media social your and for listening everyone and see you next time all right thank you bye
31 October 2025
Minimum Viable Management
Mike McQuaid and Neha Batra break down how leaders spark momentum and keep it steady. They start with clarity of mission, ruthless scope cuts, and visible wins in weeks not years. They cover simple not easy systems that reduce drag, like milestone slices, anti-goals, handoffs that follow the sun, and temporary process as guardrails you later remove. They show why constraints breed creativity, how to automate recurring pain, and why teams should target low volatility over peak velocity. They close with saying no, letting the right fires burn, and building a candid culture through trust and social capital.
Hello, Neha. What's new in your world? Not much. I've been enjoying relaxing in between things, and I've been looking forward to this podcast today. What about you? I bought a new car, which is why we are doing this podcast later, because when I was managed by Neha, her only flaw was being laid to my one-on-ones, and now I was, I guess, two days late for a podcast, so I've sort of paid it back. Yeah, you've like all of the, like, I can get back at you cred that you've accumulated is back to zero, except I was late today, anyway, so we're back to our tallies. Yep, back in action. Well, today, we were thinking we might talk about creating and keeping momentum on a team. So, Neha, you've been really good at this. Like, what, if you're coming into a team and say the team is kind of lacking in momentum right now, and you're like, we need to kind of create it, get it started, like, what's your go-to methods for that? Yeah, I mean, I think it's like, I need to diagnose what the issue is, right? But the first thing that I'm always going to take a look at is, like, what the mission is, and does everyone know what they need to do? So, do they know the work ahead of them? Do they know how to fit into that picture? And, like, do they have any immediate concerns that they're bringing up? So, I'll listen to them first, and I always want to take a look at that mission. I want to look at, like, okay, cool, how they're breaking it down, and is realistic and achievable. I feel like you've seen that a lot, especially as you're going to different companies, to see, like, do you feel like every single time you go in that people do have, like, a real, like, what's the percentage of, like, places that have a realistic goal versus, like, needs to, like, shave down and cut scope? Yeah, I think cutting scope, that's the big piece, right? Where it's like, sometimes the goals can be realistic, but if they can't fit in your head, then people can just get a little bit confused or demotivated or whatever it may be, right? So, the classic thing, and they always frame this towards, this is being really important for juniors, but I feel like it's really important for everyone at any level, is, like, if you have an effort and you're like, okay, in a year, we want X, right? Just go away in a hole and work on this for a year, then most people, even, exactly, and red flag for, like, lots of reasons, I feel like. So, one of them is, okay, so what happens over the course of that year? Do you care or not care, right? Like, if you want to get to that destination, and something I thought I was really good at, at GitHub, right, sometimes, as a result of the culture of, if you had, like, a year-long project, if you didn't demonstrate anything that was visible to customers and usable by customers, within generally, like, three months, then your project might just be killed, right? And then none of it gets visible. Yeah, yeah. Real consequences to, like, not being able to do so. Yeah. So, as a result, like, often a nice way of building that mission was, like, okay, what's the smallest possible thing that we can get out to people that they will like and find useful, and even if it's not everyone, even if it's internal beta testers or external beta testers or whatever it may be, and then just avoid getting bogged down in that and just try and ship something small, iterate, improve, whatever, and then you can still decide that you don't actually release anything to anyone for a year, but then, like, along the way, if someone's, like, what the hell have you people been doing for the last three months? And you can be like, wow, look, you can see all this nice stuff and have all these nice demos, and if you want people to use this tomorrow, we can release it tomorrow. Yeah, I mean, like, actually, if I take a step back, what this is making me realize is that, like, okay, cool, easy litmus test is to go to, like, three or four people on the team, ask them, like, what the goal is, what's next, and how will they know that they're successful, right? And so, as a leader coming in, right, like, you want to create momentum, but you can't create momentum unless there's clarity first. So you have to create clarity, and then you want to create the momentum, and so it's, like, we're trying to get that fundamental base layer, and as a leader, if I can just get everyone to say the goal the same way and say what's next to the same way and, like, know and internalize to the point that they can, like, rephrase it back to me about, like, how they'll know they'll be successful, we've, like, achieved step zero, and, like, then we can start building momentum, right? And sometimes that is literally as simple as repeating it over and over, except, like, you know, I think also it's important that, like, I feel like a lot of people are, like, oh, I've told them 30 times, why don't they get it? At some point, it's you, and you, like, need to phrase it in a different way, and you need to try something differently, right? Like, placing the blame on the entire audience when you're, like, a single person, right? Like, you have to get more creative, and you have to, like, actually get curious as to, like, why people aren't repeating the same thing. Yeah, and I think on the repeating thing, it's sometimes, again, kind of, like, the cutting scope about being, how can you make the statement or goal, whatever, as short as possible, and if there's multiple goals, how can you have as few as possible, right? Like, the thing I always think about is, like, you know, I, people who know me, who may list to this, know that I spend a bunch of time in the gym, and, like, one of the classic things, if, like, you're teaching someone to, I don't want to squat, say, it's, like, if you say, like, oh, you're doing these 86 things wrong, then they can't improve that, because they can't think about 86 things at a time. So, like, what you notice with, like, good coaches around any sport is, like, okay, or anything, really, is, like, they're, like, okay, here are the one, two, maybe three things, if they're spaced out enough, that are important to focus on right now, and then when they've nailed those, then you can be, like, let's move forward, and it may well be that you, as the manager, or leader, or coach, or whatever, have a list of 86 things, and every time you, like, get through three, you're, like, right, we're on to the next three. Okay, cool, we've graduated to the next one, let's, like, keep going, yeah. Like, the one I always think about, I remember when I was one of, maybe my favorite software team ever, when I worked on GitHub sponsors, and me and three other engineers, PM and EM, a designer, basically, like, the thing that was so great about that is the kind of north star of the plan, that, like, we all knew, we had a date, we were targeting, I think, GitHub sat, like, like, GitHub's, like, European event, I can't remember what month of the year it was, or whatever, but we were, like, maybe, like, three, four months out, right, and everyone on the team knew the high-level goal was, we're going to release this for individuals by that stage, right, and I also, I think the other nice thing about the north star is the north star, like, it was obvious what it was, but it was also, we were very attuned to what it was not, right, so, yeah, we were, like, anti-gall, exactly, pick back in GitHub's billing system to begin with, or it got spun out into its own billing system eventually, but, like, to begin with, it was, like, everything's going through GitHub billing, everything's just individual to individual, we're not doing individual to organization, organization to individual, like, and I feel like you could have probably got me three months away from that deadline, put me in a cave, not let me talk to the team at all, and I could have been productive for three months, right, I may not have built exactly the right thing, but I probably would have got, like, 50 to 75 percent of the way there, and, like, to me, like, that's the sign when you have that level of, like, it's very obvious what needs to be built, and everyone has that complete understanding, then things just work so much better. I mean, like, also, okay, so let's point out something, like, pretty, like, best practice, right, so, like, you had a scenario which was fixed timeline variable scope, right, or you get into a scenario where you have fixed scope variable timeline, but, like, the reality of a lot of these teams is that they are being pressured to have a fixed scope, fixed timeline, right, or, and, like, actually, technically, there's, like, four elements, I would say. There's scope, timeline, staffing, and expertise, right? You could add more people to it, you could swap the people with other people who are better suited to do so if you have a fixed scope and a fixed timeline, but when you get constrained on all of them, there's no hiring, you can't change the team around, everyone else is, like, occupied on something else, something has to give, and, like, as a leader, your job is to get the uppers to realize what has to give and figure out what it is so that you don't break the team, because I guess the last element, the fifth element is a fixed number of hours in a week, and I don't want to touch Yeah. Well, I feel like, yeah, yeah, the part of that as well that's kind of interesting is, like, in my experience, the projects and bits of software or features or teams or whatever that I've worked on that have been the best have been the ones with usually, often the most rigid of constraints, right? The ones where I did a talk slash blog post about this a few years ago where I called it, like, the best project where I sort of, like, joked about, again, was thinking about a particular project at GitHub, which I won't name, that basically had infinite, like, it was a really important top-level priority, had infinite resources, buy-in, or whatever, and as a result, it got really badly fucked up multiple times because there was not that, like, tight, okay, we've only got four people, we've only got six months, what can we do? Instead, it was this, like, multi-year project involving very, very many people, and it's just very easy, I think, to sleepwalk into disaster when you do that because you don't have that sense of, like, well, we have to say no to, like, lots of these things, right? Yeah. Constraints create creativity, right? And I generally feel like for most projects, starting small is, like, imperative, right? And so I've been in many scenarios where a leader has told me, hey, I'll give you the whole kitchen sink tomorrow, what do you need? And, like, I've had to push back and say, what we need is two people, and we need to start small, we need to discover, because I'm not wasting everyone's time, and especially getting bogged down in, like, coordination. We need to start small, we need to understand what we're doing, and then we'll go from there, right? Yeah, yeah. So that's, like, the fundamental pillar, but then, like, I think the next one is, like, okay, cool, how do you actually build that momentum? And, like, for me, I think that having really good milestones, very clear of what everyone's going to do, and it's not that, like, everyone has perfect lanes, right? In fact, something that could be clarifying is, hey, we have a backlog, and everyone just picks up the next thing the next morning. Or I think you did this once with someone where it was, like, because you're in a different time zone, you were, like, following the sun, and so you would hand off to someone, and someone else would pick up. It's okay to blur the lines. It's about being clear about where we're blurring the lines and where we're not, right? So that people aren't, like, I've just seen it so many times where everyone is picking up the same issues, or people just, like, aren't coordinating. Those are just easy things. Sorry. Simple things. Maybe not easy to fix, right? Yeah, I think that's a big part of it. Like, I think, as you say, a lot of these things are simple and not easy, right? Yeah, yeah, yeah. Often, like, there's a, again, a quote I think I used in that talk. I can't remember the name of the guy. It was some French engineer or whatever who said that the word engineer or designer, I can't remember which. But basically, like, a design is perfect not when there's nothing to add, but when there's nothing to take away, right? And that's, like, I think, like, that's often the thing sometimes where teams are, like, well, why are we not able to kind of get momentum or speed or velocity or, like, get people doing And the solution is, like, well, one more stand-up, one more goal, one more, like, field on a Jira issue, whatever. And it's, like, actually, most of the time, it's, like, the other way around. It's, like, what is, like, I guess I would encourage people, particularly on kind of little skunks work projects sometimes, to be, like, what is the actual minimum amount of progress, status reporting, coordination, everything you can do. And then as you encounter problems, add them on bit by bit, right? Yes, yes, yes. Rather than starting from a position of, like, well, let's do all of these things. I think, like, also when I'm thinking about introducing process, right, I feel like process is a guardrail. It's a gap, like, filler between, like, where we are and where we need to be. So, like, if there is something that needs to happen in order to graduate the team to the next stage, and it's not happening because humans can only human so much, you, like, put in a process to kind of, like, bridge them and help them. And my goal is to deprecate that bridge. I do, I want us to graduate, get to the other side where that becomes either autonomous in terms of, like, the software taking care of it or autonomous in terms of, like, this is a learned behavior by our humans. And therefore, we don't need to put this process in place because it's, like, being done. And so we can graduate out of this, and then we can go to the next one. I think, like, what we miss is we keep on adding on more and more processes, and we don't take Or we put in the wrong process, and so it's not something that we can accomplish and get past. But, like, yeah, 100%. Like, you were saying this before, like, I think sometimes a leader's job is to think about, like, the 40 things that are wrong and to be like, okay, cool. Some of these actually might go away on their own. Some of these, like, are actually underpinning and, like, fundamental ones that we need to And, like, out of the four that we need to fix, this one's, like, going to be received the Let's do that one first. Let's see what change is out of my list of 40. And let's, like, go from there. And you just have to, like, tackle one at a time, one at a time, one at a time. And, like, sometimes people are ready and sometimes people aren't. So, like, I'm an example for, like, one of the projects that I was managing. I would ask product, engineering, and design who they were blocked on. And they're all pointing to each other. Now, everyone can't be blocked on everyone. Someone's blocking someone, right? And the reality was that people were not communicating to each other on what they were blocked on. And so I was, like, oh, I, like, hate to do this to you all. But, like, it's time for a Gantt chart. And they were, like, fuck you. You are not making me input this information into a spreadsheet. We don't need it. And I was, like, bet. Okay. Let's give it two weeks. I will do nothing. Here's my prediction. I didn't even give it two weeks. I think I gave it one week. I didn't have the appetite for two weeks. But let's give it one week. Let's see what happens. This is my prediction. And if it doesn't, if it goes the way that I think it's going to go, then we try it my way for two weeks. And if I can show you that I can improve this in two weeks, we can do it. And people hated me. Our momentum went up. We started shipping more. People fucking hated the Gantt chart. And every single time they brought it up with me, I was, like, would love to replace it with anything that you want. You make me a proposal. I will do anything that you want for two weeks. And if you can show me the same results, we'll move to it. Silence. Right? They didn't like it, but it was working. And, like, we eventually stopped using it. Right? Like, we didn't need to use it eventually. And I've told them, the minute that, like, we can hit this milestone, I'll deprecate this and we don't have to use it anymore. I feel like that's a really, I mean, you were talking about it, about a spreadsheet, Gantt chart, whatever, but I feel like that's a really critical thing with keeping momentum, creating momentum or whatever is. I think we talked about this a little bit before, but, like, there's, you know, this idea in open source land of, like, the person who does the work has to make the decision. And I think, again, similarly with what you've said there, in my mind, it's also applicable to if there's, if people can't reach consensus on what a plan is that we're going forward, like, something is always favorable to nothing. Right? And I always try and be the one to be, you know, sometimes it's me, sometimes I just pick another person's idea. Like, in fact, I had a friend who was, had a great hack for this for those of us who've been to, like, tech conferences or whatever, where you have, like, a crew of, like, 20 people roaming the street looking for somewhere to eat. And you're all just hungry and no one can agree or whatever. So his hack to this was he very, very strongly argues for everyone going to McDonald's, right? And no one wants to go to McDonald's. To give people something to react to. Exactly. So then, so then everyone reacts against McDonald's and it's like, I don't want to go to McDonald's. And then he finds that, like, you can get that alignment by forcing a decision in the other way. And I found myself doing that a bunch as well of just being like, look, we need to move forwards. I think we should do X, right? And then people may or may not agree, but then at least we have a starting point or something to go forward with or something to anchor off or whatever. Yeah, just, like, being willing to be the one that sounds stupid, the one that, like, just kind of drives a decision and be hated a little bit. But then, like, you can fix it, right? So I feel like, you know, having a clear scope, cutting scope and being laser focused on it, and then also just, like, figuring out your next blockers and, like, getting at it and, like, knocking them down one by one to try to get the team to do, maximize their potential without getting them to overwork, right? I think is part of it. And then, and we talked about, like, timing and sequencing. So I feel like then we switch into, like, okay, maybe we have momentum. How do you keep it, right? So do you have any, like, tips or tricks or is there anything that, like, is your go-to for that? Yeah, I guess I'm one of those people where, I guess, when we're, if we zero right in on engineering, where I'm just, like, very aggressively trying to automate things and at least, like, automate things that I have to do more than once. Like, if I have to do something more than once and it's annoying or error prone or I see a bunch of other people do it or struggle with it, then I guess I'm just, like, right, well, I'm going to automate that, right, so that we don't hit this speed bump in future. Because, again, I guess, like, with open source land, I was, I guess, on some other podcast recently and I was talking about, like, the inputs to open source, right? And you could say, well, the input is maintainer's time is the most constrained resource. And I thought about it a bit more and I was like, actually, the real constraint is maintainer's motivation, right? Because even the time they have is flexible, right? And, you know, this doesn't map quite as well to those of us who were on, like, oh, my contract says I work 40 hours a week or whatever. But even within that, I think everyone knows, like, there's times where you feel more effective and times when you feel less effective and times where you're procrastinating a little bit or staring at a wall or being like, oh, I don't want to do this. And, like, for me, like, I try and be really sensitive when I'm working as an engineer on an engineering team to, like, those feelings and moments and be like, well, other people are probably going to hit this too. Like, if we have a flaky test that means that what should have been a 15-minute job now has become a 30-minute job, right? Then if we just – if every time you hit that you go, uh, and then, like, look out the window for 15 minutes, then, like, that sucks. And if when you hit that, you're like, well, we're going to deal with that so the next person is not going to hit that and they can kind of maintain their full momentum. And as I say, I don't even think it's necessarily about saving time. It's about saving that, like, uh, feeling that, like, this has kind of ruined my day or flow or whatever. And you can do the same thing with meetings and stuff as well, like, so something I always tried to do at GitHub and it was easier for time zones is to, like, you know, I didn't particularly enjoy having back-to-back meetings, but I was like, well, I would rather have four hours uninterrupted coding time than four hours back-to-back meetings than have, you know, 30 minutes meeting, 30 minutes coding, 30 minutes meeting, 30 minutes coding. And it's just a different way of carving up your day. And, like, again, arguably the kind of back-to-back meetings probably suffered from it, but, like, there's absolutely no way you'd get the same productivity if you were kind of interspersing it. Even if your day maybe felt a little bit better, like, it's just paying attention to that stuff and being like, how can I move faster? And then sharing that with other people and being like, maybe you can do this and maybe you'll move fast this way as well. Yeah, I think, like, motivation is a key piece of it all because we were co-located, we were in person at the same time. We had this, like, concept, which I don't think, I don't know who invented it, right? It's called a pain snake. And, like, if you remember, those of you who are older who are viewing the game Snake, right, where you, like, go and you eat the little food and then, like, you get longer and longer. The pain snake is for something that, like, annoys you, that, like, comes up on the team, every single time someone encounters that, they put a sticky note next to that line and then the snake grows, right? And so, like, we always had a threshold, whether it was, like, three sticky notes or five sticky notes, that at Retro on Fridays, we would, like, go and look at the pain snakes. And then if something exceeded a certain threshold, then that became a ticket in the backlog to go address, right? And so, it's, like, you can't address everything. Otherwise, we'll be in tech debt central and we'll just be refactoring our refactors, right? But at some point, if it's affecting motivation, then it's going to affect momentum, right? And so, it's, like, okay, cool. If two people encounter this, if three people encounter this, then, like, go fix it. Now, you are someone who's, like, I literally could probably fix this in two minutes and, like, it won't make a dent in my day. And so, for those, obviously, we want people to just, like, go and fix it, right? But if it's, like, something that's a little bit more arduous, right, having that pain snake as, like, a way to say, is this just painful for me? Is this painful for everyone? How do we collect that information? And, like, give power back to the engineers to be, like, I hate this. And it's, like, well, four people hated this. Let's go do something about it, right? I like to use that as a signal to figure out what to tackle next. And I think, also, everyone, not every dip in motivation needs to be addressed. I think that projects have ebbs and flows. If you demand 120% energy every single step of the way, you will burn people out. And, like, I'm not looking for maximum velocity. I'm looking for minimum volatility. I'm looking for predictability. And volatility being the change in velocity over time, right? I want it so that we're hitting 95% every single week. And I'd rather have that than 180% zero, 180% zero, right? Because that actually, that up and down, that rollercoaster affects people more. And so, if we've demanded a 120% week, you should expect an 80% week. And you can't push people for the 80% week unless that 120% happened, not out of necessity, unnecessarily, right? So, sometimes, I'll be like, okay, why is everyone going so hard? And they're like, well, you know, we saw that the CEO had mentioned this. And they're like, stand up. And so, like, we feel a lot of pressure. And I'm like, no. Like, we have our milestone. We have our fixed date. We're doing fine. Like, if you are extremely motivated and you're the type of personality that you want to keep going and it'll make you unhappy to step away, fine. Like, do you. But otherwise, like, how do we address this, like, stimuli that's increased the energy that's going to decrease the energy over time, right? And every team is different. So, you have to, like, observe. You have to understand who the steady people are, who the peaky people are. And then you have to figure out, okay, cool. Is this different motivation bad? And is this a bad sign? Or is this going to bounce back next week, right? I think motivation is such a kind of fascinating piece of all this because it's so individual and so team-based. And, like, it's, yeah, it's not something you can kind of magically do. But, again, I think going back to the principles you were saying earlier, I think you have to do all these little mini experiments on individuals and teams and be like, well, we're going to try to change this one thing and then see what happens. See if this improves things or makes it worse. And if it makes it worse, then roll it back. And, yeah, I guess the other thing I think about, and I'm probably going to use the wrong words, but there's also something about, like, for Max. And if it's a minimum velocity of a team, then you don't want to aim for, like, 100% efficiency. You don't want to get all the slack out of the system. There was, you know, not to, during, it was interesting, like, during COVID, you saw, like, different countries in the world where there was, you know, I can't speak about specifics. But I know certainly in the UK that, you know, the NHS was, had been on a big, like, productivity drive for a fair few years. And as a result, it was running very, very, like, high in terms of efficiency of, like, no one's time is being wasted. Like, everything is being used at capacity. And then you have, like, an unknown addition to the system, like COVID, and then things went a bit off the rails. Whereas in some other countries where they kept things like, you know, we don't want the hospital beds more than, like, 80% full, right? Rather than, like, we want them at, like, 99.9% full or 100% full. Then these shocks to the system happen, and actually the overall throughput of the system is better because of that. And I feel it's the same with, like, with engineers. It's, like, I guess, like, Google had that infamous ages ago, like, 20% time and whatever. And that is sort of somewhat, like, a relic of history at this point. But I feel like good, I mean, not even just engineering coaches. I would imagine pretty much any job, basically. You want to give people a certain amount of time for, like, self-improvement and, like, improving things for themselves and the team and whatever. And if you literally just never give anyone any of that, then you're probably just going to turn into unproductive sludge. And even though everyone's working really, really hard, then people feel like they're just not making progress. And I think that's the hardest thing to get around people is that, particularly sometimes if you've got a team that has, you know, never had momentum for a while, it's just, like, you can come in and they can think that you're saying, hey, everyone needs to work harder. And it's like, no, no, you might need to literally do less work. There might be stuff you're doing right now that I just want you to stop, and that will make you go faster. And that's really counterintuitive, right? And I think, like, that side of things, I guess I've talked a lot in the past, and I guess I was known for, I get help for being, like, bad cop and saying no to things all the time. But, like, I always felt like... Yes, you literally have a blog post on it, yeah. And, yeah, like, I always felt like that's a really big part of this stuff, is that, like, you have to, both as a leader, like, an aspiring leader or an actual leader, you need to be willing to say no to things and enforce your boundaries and things. Otherwise, you just get deluged with, like, well, I've said that I'm going to do these 100 things by the end of the week. And then sometimes you can get literally nothing done because you're just so overwhelmed with having 100 things, right? Whereas if you say no to, like, 97 of them and you get three of them done, maybe you even get five of them done by the end of the week. You get more done and you can go back to the person and say, hey, I said I wouldn't do this, but I've actually been able to do that. But, yeah, I think you were really good at that as well, about, like, boundaries and saying no and stuff like that. Like, what's, what was your approach to that with teams? Okay, well, I didn't phrase it necessarily as, like, I wanted to say no to everything. I think, like, what... So, one, as I get to know a team, I'm talking to them individually. And, like, I got this from Laura Hogan. She had me ask this question to one of my reports because I think she realized that we were so different and I didn't understand why they weren't motivated by the things that I was motivated by. And I talked to everyone individually and I asked them what gives you energy and what takes energy away from you, right? And if I can get to know everyone individually, sometimes it's, like, milestone. Sometimes it's, like, hearing from customers or whatever it is, right? Now I have this bank in my head of, like, what's going to drive motivation and what's going to kill motivation. So then I get my external requests in, right? And those are the things that I want to say no to. As a leader, I think it's really important to understand which fires to let burn. And a very simple example, right? Companies are always going to be trying to do new things top-down. And as they come top-down, if you were the first one to adopt the new system, you are going to discover all the kinks in the system. And your folks are going to inherit more work than the next one. So it's really important for me to pick when I'm going to be an early adopter to a brand-new process and when I'm going to be the last one to complete it, right? And what I'm going to be looking at is, how is a team doing? What's their velocity like? How likely are they going to be bogged down or, like, lose motivation if this goes wrong? And, like, which fires do I let burn? And so saying no sometimes means not yet. And I don't know the right answer. Just like you said, I'm running experiments all the time. I am trying to figure out, okay, cool, we've got 86% week over week. I want to hit 87% without risking it going to zero. So what do I want to try? What do I feel comfortable with? What am I willing to take a risk on? And, like, no risk, no gain. So, okay, cool. I've been asked to do this. I'm going to go ask for a one-week extension. And just see how critical this deadline is, right? Oh, it's not critical at all? Actually, you gave two months lead time? I'm going to go take that one-week extension. Sometimes I'll take it a step further and say everyone in engineering should get a one-week extension because I know that reviews are hitting at the same time as the big conference is hitting at the same time as training is hitting. And so now this fourth thing is going to, like, do us under. I'll go advocate for an extension. Or sometimes I'm, like, we've gotten extensions the last three times and, like, it's time for us to do it. I'm going to go explain to the team. Hey, I know you hate this. Here's why I didn't get an extension for you. Here's why you need to, like, swallow your medicine. Let's, like, go do it together. Let me figure out how to make this fun for you. Who wants to do a Zoom? Who wants to, like, live tweet this training? And, like, we can all make jokes together. Let's, like, do a live show, right? Like, how do I keep the momentum, the motivation up for things that we don't like to do? And how do I shove some things aside? There are other people who I've worked with who have much higher thresholds for fires than I do. I've learned a lot from them. If you're going to be really laser-focused on your top three goals, there is going to be stuff that you let burn that is going to cause drama. And you really have to weigh the two. How good are the benefits of getting your top three versus the drama that you incur? And the social capital you are consciously choosing to burn in order to get the top three done. And, like, every CEO is doing this all the time, right? Like, as an individual, you'll look up to the CEO or a CTO or a VP, and you'll say, how could you not see this as a problem? And, like, sometimes if they feel like being authentic, they will be like, yeah, it's a problem. And what, right? Like, it's not my top three. And you can feel resentment for it, but you have clarity. And other times, you know, they'll be actually doing the things that, like, align with your top three. And it's just never always going to be aligned. It's about, like, letting the right fires burn. I think, like, I like the fact you said authentic, because there's a nice segue on that, actually. We were asked on YouTube by Brandy Phelps. Brandon. Oh, yeah, Brandon. Yeah, I read it as Brandy N. Phelps. There you go. Lowercase usernames. We've been asked a question by someone who's not called Justin, which is great. Nothing against, no shade on Justin's. I'm going to paraphrase it slightly just for brevity. So they said, you both have reputations for being authentic and candid. How did you do that? How do you promote that culture and avoid the downsides? Yeah, I think you first. Yeah, okay. Sorry, aggressive. You first, go. Yeah, so, I mean, for me, it's, I think the earliest part of it is maybe the fear side. I know that's maybe a strange thing to say, but I think the things that make people not authentic or not candid are often fear of consequences, right? And what will happen to me. And, like, sometimes those fears can be justified if you're in a really precarious financial situation. You have a job where it's like the last 10 people who spoke out got fired. Then, yeah, okay, you probably, you don't have an environment or a culture there. Yeah, read the room. But, yeah, but, I mean, thankfully, I've been in most of my career either cultures that value that or situations where I'm like, if they don't value that, I'll go elsewhere and find someone that does. And so, I guess for me, the starting point is just be like, okay, like, let's be honest, right? Like, let's try and speak the truth to people in power, people in my team who ask me, like, people who ask me when they think something's going to be done. But then, I guess we talked about the piece before in a previous podcast where I think, for me, the important part is always being like, okay, well, how can I be as honest as possible, but yet also as kind as possible, right? And I think the two go hand in hand, because sometimes as well, like, being dishonest is actually really unkind, even if phrased in very nice language. But basically, so I'm like, how can I communicate the thing that needs to be communicated? And then, given I'm going to do that, how can I avoid hurting people's feelings as much as possible? And it gets to the second part of the question, like, how do you promote that culture? I think, like, as, like, a member of a team, I guess I try and encourage that in other people. I try and encourage people to ask those questions. And I guess, well, I guess it's probably the same as a leader, where, like, asking people those things, trying to tease that authenticity or candidness out of them, and then praising and rewarding them when they do that. Or even just being like, well, maybe they'll feel more comfortable doing that privately, one-on-one, or in text to begin with, or on their pet topic to begin with, or whatever, before they want to do it in a group or in all hands, or whatever. And then, I guess, the final point of, like, avoiding the downsides, like, I actually, ironically, think there's many more downsides of not being authentic or candid than there is, like, upsides. But, yeah, I guess, for me, it's that thing of just being, again, we talked about this before, if you're willing to be, like, humble and apologetic and be honest when you screw things up. Because, yeah, again, part of being authentic and candid is there's going to be times where you're like, ah, this person can probably take some tough feedback. And it turns out they're having a really bad day or week or month or whatever. They couldn't take that. You've made them really upset. And in that situation, being like, hey, I'm really sorry. Like, it wasn't my intention to be upset. I fucked up. Like, I'll do better next time. And I think if you're willing to do that, and if you're willing to genuinely try to build worship with people, say thank you, say sorry, then you can probably figure out all this stuff. What do you think, Naomi? Yeah, I mean, like, you know my mantra, which is sorry's and thank you's are free. So I feel like that's, like, a very big part of it. I think if we, like, wanted to drill down, I still don't know the answer to this. I think, like, I keep being told that I'm authentic and candid and I don't 100% know. I only know how to be myself and I keep on getting encouraged for what I'm doing, so I keep on doing it. I'm still trying to break that down, but I do think that a very big part of me being authentic is literally taking a step back and understanding how I think about something and, like, thinking two levels deeper. Knowing actually how you feel and actually why things are the way they are and spending those extra brain cycles around it. So it's, you know, I'll get a question that's like, hey, why does product keep on ignoring us when we say that we can't do this, right? And instead, I could say, well, that's stupid, like, product should just get on board. Or I could, like, really think deeply about the question and I could say there's a lot of pressure top down, number one. And so, like, I think we should actually learn what the pressure is coming from. And, like, number two, I think that they don't fully understand what's going on on this project, right? Let me give you a few examples. So, like, really trying to, like, get a good answer. And especially in writing, I try to use as plain language as possible. I'm very wordy, I'm very verbose, I'm very prosaic. And so I do a second pass and a third pass specifically for plainer language so that I'm more approachable, especially for language barriers. It's important to do that. So those are, like, some tactical things. But then how do I promote that culture? So very similar to you. One, role modeling. Two, responding well to other people being authentic. And I, like, want to draw a difference between, like, some people are like, okay, cool, I, like, want to bring my whole self to work. And that means, like, in a Slack channel, I can, like, complain about my personal life for, like, 15 minutes and, like, get everyone involved. There's authenticity to it, but it's inappropriate for work, right? And so there's different versions of authenticity that really work. I think, like, being transparent about what you see and, like, showing curiosity and, like, wanting to drive to better solutions. That is what I want to award. And I want people to hear from me. Thank you for contributing. Thank you for challenging me in a very good way, in a curious way. Thank you for asking this good question, right? All of those are positive reinforcements to, like, a good authentic culture. But authentic culture still needs to drive towards, like, a positive top right because, especially in remote settings, in meetings, in Slack channels, you are putting words out there that affect everyone who's reading. And you have to be responsible with that. I reward good, responsible communication. And then what about the downsides? You kind of, like, hinted around this. And then I'm going to point out one thing that you do that maybe you didn't mention. I think you know that you do it, but I think it's, like, a very important piece of it. So, number one, you can't avoid all the downsides. It's about walking into it and taking that hit and saying this is worth it, right? You said the downsides of not having authentic culture are worse than some of the downsides of saying something, right? And that's, like, taking the hit and saying this is worth it. You have to make a calculated risk. Maybe it's not the right time. Maybe, and this is the part that I wanted to bring up, you don't have a social capital for it. One thing that you do, Mike, every single time, and I remember you doing this to me, and I was like, why is this man kissing my ass right now? Like, for what reason? You, when there's a new leader, you get to know them. You try to understand their motivating factors, and you build social capital. You try to figure out a way to solve a problem for them. You are building social capital proactively so that you can be authentic when you need to be authentic. And maybe it's conscious. Maybe it's unconscious. But understanding that if someone hears from you the first time ever, and it's a no, and it's, like, something challenging, is not going to go well. And, like, you need to find a way to say yes first. And if you don't have a relationship with that person yet, you need to create one, and you need to find an opportunity to say yes first. And if that means doing something, solving a problem for them, and, like, making something better, you have the yes first so that later when you say no or you challenge something, they understand the range of your personality and the range of your willingness. So you have to proactively build that social capital, and you have to gauge your social capital if you're going to take a stance. And I know that no one wants to think about that. But, like, politics exists at work. Denise, you did a wonderful talk at Lead Dev. Hopefully it's up right now. That really talks about, gets into the depth of it and, like, makes that argument. I 100% agree, right? Like, politics and social capital allow you to be authentic. So either you play the game or you are in the backseat of someone else who's driving that. Love it. Yeah, I totally agree. That's a really great question. Thank you, Brandon. That resulted in a great nice conversation for us. Yeah, we're going to go and do what we've done in the previous few and update the Minimal Viable Management GitHub repository based on what we've been talking about. Using our AI bot that does these things for us. But, yeah, thank you for listening. And, yeah, we'll see you next time.
24 October 2025
In tech, 3 years is often considered a “long tenure”. We maintain open-source projects for 2 years, then burn out. We start habits, lose momentum and quit.
09 October 2025
gem.coop was announced on Monday. As part of that announcement it was mentioned that I was helping gem.coop set up a governance process, continuing the work I’d first started helping with on RubyGems.