Scaling Your Tech & Teams with Just Enough Process [+ AI]

[04:53] Welcome and Introduction to the Livestream

Andrew Murphy: Good morning. If it's morning where you are, good afternoon, if it's afternoon where you are. Welcome to another Tech Leaders Launchpad livestream. If this is your first, I'm Andrew Murphy and this is a livestream where we talk about everything to do with technology leadership. And I share the people that I learn from, the people in the community that give me insights that I don't have in order to be a better technology leader. This is a journey I've been on for the past few years now, but it all started 15 years ago when I became a tech leader for the first time. Nobody was giving me help and support back then. I had to learn everything the hard way. And so now I try and make sure you don't have to learn things the hard way. And with me today is Macklin. Say hello to the folks at home. Macklin. Oh, you're muted.

Macklin Hartley: Hello, everyone. Hi.

Andrew Murphy: Hey. And I like to kick these off with a little bit of an icebreaker where I ask you the question, what's your favorite technology gadget that isn't your phone or your computer?

[05:58] Icebreaker: Favorite Tech Gadget (besides phone/computer)

Macklin Hartley: Yeah, for me at the moment it's probably my e-bike, my electronic bike. I don't know if I've got any people coming from Perth at the moment, but for me, I ride around the river all the time. I commute to work, I ride on the weekends. I'm kind of obsessed with it. It's sort of changed my perspective on a lot of things as well. Interesting. Yeah.

Andrew Murphy: In what way?

Macklin Hartley: I'd be the sort of person who, you know, take a car on trips. I sort of didn't see myself being able to kind of do a trip on a bike that's 30, 40ks, which you can do on this sort of thing. And yeah, just the... I could see myself coming home on the bike and I'm able to unwind, whereas if I'm taking the bus or public transport or a car, I'm still in the zone and I don't have the separation or anything like that.

Andrew Murphy: That's interesting. Do you reckon that's the isolation or the activity or a little bit of both? Like, what about the bike kind of is different to a car or public transportation?

Macklin Hartley: I think it's just being outside. There's some studies that say the presence of being outside and seeing green and seeing trees does stuff to your brain. So I make an effort to ride through the parks and all of that stuff around Perth. And I think it does positive stuff to your brain.

Andrew Murphy: Yeah, I definitely find that I unwind better in nature than in human constructed environments. If I'm ever feeling stressed or whatever, just going out and being in nature really helps me unwind in a much better way than anything else does. My favorite tech gadget—I mentioned this last time, but I didn't have it to show—this time I'm going to actually show it. So these are the glasses that I talked about last time, which have a display inside where they basically work as a USB-C display. Then I can wear them on the plane and connect to my iPad or my laptop or my phone, and watch media without having to crane my neck down and look at an iPad in front of me, or look at the 480p display in the back of the seat in front of me. If you do a lot of traveling on a plane, these are a really, really good investment.

Macklin Hartley: Yeah, that's—

Andrew Murphy: Yeah. As always, this is a live stream. We do these live for a reason, which is that you can share things, ask us questions. For example, Daryl here is just saying hi, but this is a great example. If you want to ask us a question, please feel free to do so and we will answer as many as we can. So please don't just watch us passively—get engaged in the conversation, ask questions.

[09:15] Macklin’s Background & Importance of Process

Andrew Murphy: This is a good time, Macklin, while we're here. The title of this live stream is "Scaling your tech and teams with just enough process." Can you use that as an example, and just give us a little bit of your background—who you are—and why this topic in particular is important to you?

Macklin Hartley: Yeah. So I've been working in tech in Perth for probably about 13 years—I haven't checked, but I think it's about 13 years now. But I've been playing with computers and coding for a lot longer than that. My first experience with coding and programming was making game mods for Warcraft 3, making Flash games. That's where I developed a passion for it. Professionally, I've worked at a couple of places of various sizes, from really big organizations to, more recently, a couple of startups based in Perth that have seen some success.

The job before my current one was a startup that, when I joined, was smallish and scaling up. I spent about five years there and got to see all the pain points you experience as you go along the way from scaling to hundreds of engineers. Now, more recently, I'm in a much smaller startup—weMoney. I'm hoping to bring all that I've learned and that experience of seeing an organization scale up, knowing all of those points along the way where adding the right process, because you've doubled the size of your team, can be really effective.

[10:40] Risks and Challenges When Scaling Teams

Andrew Murphy: There's a whole heap of risk associated with this rapid scaling environment. You might have been a startup six months ago where you could all get around a table or all get into a Zoom call and discuss something. When you get to the point of scaling teams and having multiple teams and maybe teams of teams, there's a whole heap of stuff you've got to solve. You can use the systems and processes you were using historically, but you also don't want to look at what Google is doing with its tens of thousands of people and go, "that's the way we should do things." There's probably something in the middle—closer to what you're doing than what Google's doing, especially early in your journey.

Macklin Hartley: Yeah, absolutely. Google didn't start with the process they have now straight away. That's definitely true. Particularly with startups, one of the most dangerous things that can happen with not having the right amount of process—like having too little or too much—is existential, often, to be honest. I've heard stories and spoken to people who've worked at startups that didn't work out. I've asked them what they were working on at those startups, and often they'll say they spent their time rewriting everything in Rust and writing their own logging frameworks—which all seems like, not a waste, but a misallocation of resources.

Obviously, I don't know the internals of what happened—maybe there was a good reason to rewrite everything in Rust—but when I hear that, I picture a startup that grows too quickly, hires strong engineering talent, but doesn't give them enough direction. It's quite easy for them to get carried away.

[12:41] Consequences of Too Much vs. Too Little Process

Macklin Hartley: So yeah, for that case, a better process would have helped them align their outputs to what the business goals were.

Andrew Murphy: Let's go into that a bit deeper. What are some of the negative things that can happen in a startup if you add too much process? And what are some of the negative things if you don't add enough process?

Macklin Hartley: Not enough process—you can have people running off in different directions, creating a whole bunch of technical debt. Technical debt isn't always the worst thing in the world, it's always a tradeoff. But running in a direction that doesn't really help a startup... Everything you should be doing, you should be seeking maximum efficiency for those resources, because those resources are really limited.

On the other side, too much process—slowing things down, making things unnecessarily complicated. You're not able to affect change and have an impact. You can see the thing that you need to do in front of you, but there are a lot of hurdles in the way.

The other thing with too much process: you start to observe people bypassing those processes. It's the idea of the desire path—you've got a pathway in a park, and then you've got a worn-down shortcut where people actually walk because it's faster. There might be a really good reason why that process is there, but people are bypassing it because they just want to get work done and have an impact. Sometimes, that hurts the business.

Andrew Murphy: That's a really good metaphor for something to look out for as a tech leader—that worn-down path in the grass exists for a reason. As a leader, we've got to work out why it exists and what we can do about it. Do we need to call them off the grass and enforce the pathway, or do we need to look more deeply at what people are trying to solve?

[14:44] Process as an Existential Question for Startups

Andrew Murphy: I want to touch on something you said a minute ago, but we kind of breezed past. You talked about this often being existential for startups and scaleups. I think that's a really important point. We're often talking about companies that are post-revenue but pre-profitability. They may be venture backed, have runway associated with where they are—they're not making enough money to have infinite runway, or they're trying to invest and scale and deliberately putting profits into growth. So if we put too much process in place and we don't enable teams to work quickly and get things out the door, we'll run out of runway before we see the value from those development efforts. Is that something you've observed—mistakes people have made in that space?

Macklin Hartley: Yeah, absolutely. I've seen both sides. You've got the startup that's maybe post-revenue and turning a profit, with more breathing room and can afford to have more process and spend more time delivering stuff. But then, on the other side, the more extreme case—everything you work on is connected to the existential nature of your startup, like whether you're going to exist in a month's time. Keeping that in the back of your mind, you're constantly augmenting what you're doing, how much time you're spending on building something, and the process associated with that—looking for where you're not spending that time efficiently.

[17:33] Views on Process from IC vs. Manager & How Perspective Changes

Andrew Murphy: You've had a career where you've gone through both the people leadership and principal/staff engineer pathways. Do you think about process differently with those two hats on? How does that shape the way you think about process?

Macklin Hartley: Absolutely. If I think about how my perspective has changed—I started as a developer, then engineering manager, now back to being an individual contributor. Early on, as an IC, I used to bemoan all process. My previous managers—if they see this, I'm sorry—would say I was hard to manage because of that. I was the person in scrum or planning sessions who looked like it was all a waste of time.

Now, I’m completely on the other side. I fully understand that software is a team sport. In rugby or netball, for example, everyone has a specialized role, and all those roles come together to deliver the product. Most software—even the tiniest change—is handled by a lot of people before it goes out the door. The moment that happens, the moment multiple people need to handle something, you see a return on investment for some sort of process. It might feel like it’s slowing you down, but the benefit is there.

I've seen, as an engineering manager, when I assign a large piece of work to two strong contributors, if I don’t have a strong plan for how they'll communicate and work together, they often run off in different directions. You don't see it until you're in a more senior position. The piece of work ends up with multiple competing directions and quickly becomes a disaster.

Andrew Murphy: It could be different ways to the way you thought—so you've now got three different ideas on how to build the thing, two of which are being implemented. I think a lot of people think process is filling forms, but sometimes it can be as simple as getting in a room and having a chat about how you'll do something. It doesn't need to be complicated.

Macklin Hartley: Absolutely. I used to feel that way—forms or stuff in Jira, so frustrating. But yeah, process can be as simple as having a chat and aligning before you start your work.

[23:22] How Process Helps Junior Engineers—Asking the Right Questions

Andrew Murphy: Those forms also serve as a documented record of decisions and force you to ask good questions, which has value. Early in a company's lifecycle, you can ask those questions in a Zoom call or Slack thread, instead of a form.

Macklin Hartley: Absolutely. In my position, it's about knowing the right questions to ask. Junior engineers might get together and think they have a plan, but have they considered security, authentication, deployment? Sometimes, as a less experienced engineer, you just see "I’ll make this as a React app!"—but there’s so much else to consider.

[24:01] Behavioral Signs You Need More (or Less) Process

Andrew Murphy: Let's talk a little bit about the warning signs. What should an engineering leader look for to notice they need to start adding more process, or maybe they've implemented too much? What behaviors give those indications?

Macklin Hartley: For me, mindful observation of the team is huge. In a startup, it's hard—I have to code too—but I'm always watching what's working and what’s not. Some say you need certain processes at a certain team size, but it's more about observing your team specifically.

For example, at WeMoney a couple of years ago, there were lots of reliability issues. If the whole app went down, we'd notice quickly, but if a single feature broke, it could take days. We’d fix things reactively, but had no process to prevent repeating the mistakes. So I introduced a post-incident process—similar to what I'd used before. The post-incident review was key: discussing what happened, what went wrong, the "five whys." The impact was immediate—after every incident, we discovered and acted on issues to prevent repeats.

Another benefit: the post-incident process is a bit painful, so you subconsciously try to avoid triggering it by being more careful in the first place.

Andrew Murphy: That's interesting. I like to think about process in those early days as risk mitigation, to avoid wasting more time/money later. What is this process meant to save me from, and what's the cost? What's the cost of a process versus the cost of the thing it's trying to mitigate against? I hadn't thought about the side effect of it discouraging sloppiness, too.

Macklin Hartley: Maybe it's subconscious—just the idea that if we break something, we've got to sit through an hour-long review. That makes you double check your changes.

[29:45] Signs of Too Much Process

Andrew Murphy: Earlier you mentioned the desire path shortcut as a sign you’ve added too much process. Are there other signs that process has become excessive?

Macklin Hartley: Anytime you add process, you’re adding overhead. It's about balancing that with results. Like you said, if an incident costs you $10,000 a month and your process costs $5,000 of effort, it's worth it.

A colleague used to say you should cut process until it hurts. If something is overly cumbersome, just skip it for a while—unless it's there for compliance. For example, why batch releases every two weeks and deal with merge conflicts? Why not just release changes right away and see what happens? Sometimes, removing process shows you either there's a good reason for it, or that you no longer need it.

Andrew Murphy: There's risk—removing process might reveal an unanticipated issue and you realize why it was needed. But at least everyone then knows why that overhead is worthwhile.

[33:30] Reducing Overhead—Case Study: Release Trains

Macklin Hartley: We had this experience with release trains at WeMoney. We used to release once a week or even less often. We just asked, "What's stopping us from releasing every day?" There were pain points—getting a mobile app onto the store is slow. But when we tried, the turnaround for app store reviews actually got faster. Maybe it's just smaller deltas to review, but whatever the reason, releasing more often reduced our pain.

Andrew Murphy: I wonder if that's for technical or human reasons—smaller reviews, higher trust. Fascinating either way.

[37:12] Core Processes to Enable Faster Delivery

Andrew Murphy: Very few people now fight the conclusion that it's better to deploy more often than less often—it reduces risk. But if we're moving to weekly or daily releases, which processes become critical? What should we focus on, instead of just cranking up all the processes?

Macklin Hartley: The simple list: Lean into automated testing at every level of the pyramid. Also, event modeling—getting engineers, designers, and stakeholders together to model how a change will work is a game changer. Everyone can see the technical flow and the user experience—helps avoid miscommunications.

Technical review and handover is key, especially as the team grows. You need a way to explain changes to those who weren't involved. That way, someone else can make changes in the future. Too often in startups, no one invests in this, then code becomes mysterious as people leave.

Architecture decision records prevent confusion later. For example, at WeMoney we ended up with both MongoDB and Postgres. There wasn't a clear record explaining why. It made it hard to know what to do, because no one could justify the choice anymore. A simple decision log helps future engineers understand past tradeoffs. You can always change direction, but at least the rationale is clear.

[42:09] AI and the Future of Process & Documentation

Andrew Murphy: Good segue—I've heard people say you don't need ADRs (architecture decision records) anymore, because AI can tell you why the code is the way it is. There's some truth; AI is great for understanding how code works. But the really big value is in understanding "why" decisions were made—what context, what options. AI can infer "what" and "how," but not the full human reasoning.

Macklin Hartley: Yeah, absolutely. In startups especially, joining a team where past decisions weren't documented, you end up repeating all the vendor selection and due diligence efforts. If you'd just written it down, you’d avoid re-litigating old decisions—you could just understand the reasoning and move forward faster.

Andrew Murphy: Sometimes those decisions aren't even technical—a better-priced CDN loses out because of a reputation issue. Two years later, new people might not know why you picked the more expensive one unless it's documented!

Macklin Hartley: Exactly. You won't see that in the code—you only see it if you document and codify those decisions for the next person.

[46:55] How AI Changes Team & Process Success Factors

Andrew Murphy: Anything we haven't touched on that you wanted to cover?

Macklin Hartley: I just want to circle back on AI. Success with AI is going to be monopolized by people who can actually do things. It's going to weed out a lot of "fraud" and pretenders. The big differentiator will be people who can do good technical reviews—who can ask and answer the right questions.

A big part of technical review is just describing what you're going to do—explain plans, do good diagrams and communication. That's your prompt for AI! If you can prompt AI clearly and with reasons, you get much better results. So if you're a junior engineer, get good at technical review—even if there's no standard format yet. It will amplify your effectiveness with AI and leave a clear trail of your decisions and impact.

[49:45] Prompting AI Effectively and Retaining Human Judgment

Andrew Murphy: I use AI a lot, and I've found out that when I engage AI and how radically changes the value I get. If I use it too early before I've thought things through myself, the results aren't as good. The best approach for me is: think it through myself first, then ask the AI to challenge and question my decisions—not just give me a solution from scratch. That leads to more effective decision making.

Macklin Hartley: Same. Though a caveat—AI is super agreeable. It'll often tell you “absolutely, you’re right!” So tell it to grill your solutions—to critique or roast them—so you get better answers.

Andrew Murphy: I actually get irritated by how appeasing Claude is. But you can always ignore its advice—you’re still responsible for the decisions you make. Code generated by AI is still your code if you commit it, and as a leader, you can’t say, “Claude told me to do it!” You’re accountable for the outcome.

Macklin Hartley: Same principle as copying from Stack Overflow—it’s your code.

Andrew Murphy: Exactly.

[54:04] Reflections on Being an "Expert" & The Value of Practitioners

Andrew Murphy: Thanks, Macklin, for talking about this topic. It's been fascinating talking about finding that balance between too much process and not enough process.

Macklin Hartley: Thanks for having me. It's been fun to chat about this. I definitely don't see myself as an expert in process—I don't think many people can confidently say they are—but it's nice to share thoughts and have a chat.

Andrew Murphy: I think anyone calling themselves an expert here is probably a consultant who's not had the real lived experience in many years. It's better to talk to people actively practicing and making these decisions.

Macklin Hartley: Absolutely.

[57:22] What's Next, Events & Closing

Andrew Murphy: Next up on the Tech Leaders Launchpad livestreams is Inga Flammer—talking about scaling up without slowing down, exploring how to add people to your teams without losing speed. We'll cover what it really means to scale and to slow down, and I'm sure we'll mention “The Mythical Man-Month.” That's at the end of October, usual timeslot.

If you’re new here and want to stay up to date, I have a newsletter with upcoming livestreams and resources for tech leaders. I’m also running some in-person training workshops—mostly in Melbourne. If you're interested, details are in the newsletter. If you're a company sending a few people, I offer group discounts.

Macklin, where can people find more about you?

Macklin Hartley: Just find me on LinkedIn—I'm the only Macklin Hartley, pretty easy to find. Connect and say hi!

Andrew Murphy: Having a unique name is great—I'm Andrew Murphy, one of many, so I'm always Andrew Murphy 27 or something! Do you have to spell your name a lot?

Macklin Hartley: Every time. Or I get Matt, Mark, etc.

Andrew Murphy: Some people just use a “Starbucks name”—like Chris, just for easier coffee orders.

Macklin Hartley: Part of the fun is seeing what they come back with.

Andrew Murphy: Awesome. Thanks again, Macklin, and thank you everyone for joining. See you next time on Tech Leaders Launchpad! Goodbye!