# Mark Darling: full content > Mark Darling's published writing, as plain markdown. He is a technical entrepreneur and engineering leader (Gymshark's mobile app to unicorn scale, twenty years shipping software) writing about practical AI for health, wealth, business and life, tested on himself, with live data at https://www.markdarling.com/now. Thesis: AI supports, it doesn't lead. # Posts ## The Score Doesn't Cancel the Session Source: https://www.markdarling.com/blog/the-score-doesnt-cancel-the-session Published: 08 SEPT 2026 · Category: health The workout is not optional. We still show up. Recovery and sleep already know yesterday. A yellow number, a short night, a diary that ran over. Useful. None of that gets to cancel the session. It changes how, and when. Not whether. I don't want an assistant that reads the score and gives me a reason to skip. I already know how to talk myself out of it. The useful one pushes me to do more than I would on my own, then fits that work around the day I actually have. Grok Bot, Hermes, OpenClaw. That class of thing, the kind that [keeps working after I've closed the laptop](/blog/if-it-stops-when-i-close-the-laptop-im-done-with-it). Not a review of any of them, and I'm not claiming any of them already do this cleanly. The pattern is the point. Something that can see [the recovery, the sleep](/now), the last few sessions, and the calendar, and come back with today's version of the work. Not a lecture. A session that still happens. ## How and when, not whether If the day fills up with meetings and those meetings overrun, the jiu-jitsu session gets moved. The lifting session gets adjusted. Shorter warm-up, same intent, later slot. It does not get deleted because the afternoon collapsed. If there's an early morning the next day, the week moves around that. The hard session shifts. The late one doesn't. I still turn up. That's the import. Recovery, sleep, recent workouts, calendar. The programme written on Sunday doesn't know any of it. I do, but I'm also the person who will use a full calendar as an excuse. The assistant should already be looking, and the proposal should already be the version that keeps the week intact. Heavier if the last few were easy and the day is clear. Same work, different clock, if the only problem is the meeting that ran long. A different shape if the last three sessions were the same shape and I was about to repeat them because that's what the plan said. Not a lighter week because the score was yellow. ## I still say yes. To the session. The assistant proposes the moved one, or the harder one. I say yes. The yes is to doing it, not to a rest day dressed up as being sensible. If it offers me a skip, I'm out. If it only narrates the score I already have, I'm out. A programme that cancels itself is just a diary of the week I was going to have if nothing got in the way. The useful bit is an assistant that can see yesterday, see today, and still put a session in front of me. Moved if it has to be. Harder than I would have written. I still show up. --- ## Most AI Money Tools Still Need You at the Keyboard Source: https://www.markdarling.com/blog/most-ai-money-tools-still-need-you-at-the-keyboard Published: 01 SEPT 2026 · Category: wealth Last week I wrote that [if a tool stops when I close the laptop, I'm done with it](/blog/if-it-stops-when-i-close-the-laptop-im-done-with-it). Same filter, different pile of software: money. Categorising spend is solved. Plenty of apps will tell you where it went. The new claim is a tool that actually does something. Renegotiate the bill. Cancel the subscription. Move the cash. After you've stopped watching. I don't live in this AI-finance world. I'm not reviewing a product I've used for six months. I'm looking at what they're now saying they can do, and putting it through the same test. ## It still waits for you On 25 August, [Rocket Money launched Rowan](https://www.prnewswire.com/news-releases/rocket-moneys-rowan-rewrites-what-ai-can-do-in-personal-finance-302859522.html), an Anthropic-powered agent on a new Premium Plus tier. The pitch is not another dashboard. It watches spending, texts you when it spots a way to save, and after you reply in plain language it can renegotiate recurring bills, cancel subscriptions, and set up savings transfers. That's a real step on from "here's what you spent". It's also not unsupervised. Rowan texts you. You reply. Then it acts. You've swapped the keyboard for the phone. The work still waits for you. Cleo has been pushing the same shift since February. [Autopilot](https://web.meetcleo.com/blog/introducing-autopilot) was framed as moving from analysis to action, inside guardrails you set. Their own write-up still splits it: today it recommends, tomorrow it executes. The launch actions they list (move money to savings, cash advances against overdrafts, merchant spending limits) still need your consent. So the category is interesting. The unsupervised version is mostly still a press release. ## The lid test, for money Same three questions, just pointed at cash. Does this thing keep working when I'm not looking at it? Can it finish a job without my cursor in the window? If I walk away for an hour, did anything actually happen? A spending chart fails that test. You close the app, nothing moves. A forgotten free trial that gets cancelled after you type "cancel" is closer. A transfer that runs because you already said yes to the rule is closer still. What I would not let run unsupervised is anything I can't reverse in five minutes. A large payment. An investment. Changing a regular that actually matters. Saying yes to "cancel this trial I never used" is one kind of trust. Saying yes to "just handle my money" is a different one. I've spent enough years as the person in the middle of systems that do not talk to each other. I'm not looking to become the person who finds out on Friday that an agent moved savings I needed on Monday. ## What I'm actually willing to try I'm not ripping out the money stack. I'm also not adding another app that needs me in the chair to be useful. If a tool can watch, ping me, and then do the boring half after I say yes, that's useful. If the useful bit still needs me tapping through a dashboard, I'm out. If the claim is that it will just get on with it, I want to know exactly which actions it can take without asking, and I want that list to be short. I still make the decisions. I still say yes before anything with real money attached goes live. The machine can do the rest, including the rest that happens after I've closed the laptop. That's the filter. I'm sticking to it, including on this. --- ## If It Stops When I Close the Laptop, I'm Done With It Source: https://www.markdarling.com/blog/if-it-stops-when-i-close-the-laptop-im-done-with-it Published: 27 AUG 2026 · Category: business If a tool stops when I close the laptop, I'm done with it. For years I picked tools the other way. Does it work while I'm looking at it? Can I click around, see the thing update, feel in control? That's the wrong test now. The useful ones keep going after the lid is down. Notes that other systems can read without me exporting a file. A bot with its own computer, still working after I've left the room. ## The old stack needed me in the chair Most of the software I used to run my life was built around a session. Open the app, do the work, close the app. The knowledge lived in that session. Next morning I had to open it again and remember where I was. Obsidian was already closer than most of it. Plain markdown files, on disk, not locked in somebody else's database. I can read them in twenty years. I can search them. I can hand them to something else. What changed is where those files live. They still start in Obsidian. That's the editor. That's where I write. Then they sync to GitHub, so every client that needs them can read the same files. An agent on a different machine. A script that runs overnight. Me, later, on another device. Nobody is waiting for me to export a zip. This is not a notes-on-GitHub product. The notes are the files. Obsidian is just the nicest way to write them. That sounds small. It isn't. It's the difference between [a second brain](/products) that only works at my desk, and a set of files that anything I own can use. ## The lid test I started putting everything else through the same filter. Does this thing keep state when I'm not here? Can something else pick up the work, or does it need my cursor in the window? If I walk away for an hour, is progress still happening? An assistant that only works while the tab is open fails that test. You leave, the work stops. A bot with its own computer passes. It still looks like a chat window, but the chat is just how you talk to it. The machine behind it stays on. The logins are still there. You only get pulled in when something actually needs you. That's why Grok Bot is interesting, and why I'm not going to write a review of it. It's also why I want [one pointed at my training](/blog/the-score-doesnt-cancel-the-session). Persistent computer, not a longer chat. Whether the beta is tidy this week is a different question. The category is the point. Same test, different tool. Markdown in Obsidian, synced to GitHub, passes. Notes locked inside an app that nothing else of mine can read fail. A weekly job that runs while I'm out of the room passes. [Most money apps fail it](/blog/most-ai-money-tools-still-need-you-at-the-keyboard). ## What I'm actually changing I'm not ripping the whole stack out. I'm just not adding anything that needs me in the chair to be useful. New tool, same three questions. Where do the files live? Can something else read them without me? Does the work continue when the lid is closed? If the answers are "in the app", "no", and "no", I'm out. I've spent enough years as the integration layer between systems that don't talk to each other. That used to be a job. Now it's a design smell. AI is part of this, obviously. The useful bit isn't a cleverer prompt, though. It's a system that can see the same files I see, do the boring half, and wait for me on the bit that needs a decision. I still write the opinions. I still say yes before anything goes live. The machine does the rest, including the rest that happens after I've closed the laptop. That's the filter. I'm sticking to it. --- ## If AI Does the Junior Work, Where Do Senior Engineers Come From? Source: https://www.markdarling.com/blog/if-ai-does-the-junior-work-where-do-senior-engineers-come-from Published: 17 AUG 2026 · Category: business AI can now do a useful first pass at a lot of the work we used to give people early in their career. Small bugs, tests, tracing how existing code works. It gets through that sort of thing quickly, although somebody still needs to give it the right context and check what comes back. So why hire as many juniors? From a business point of view that looks like an easy efficiency right now. The problem is nobody starts out with the judgement we now say matters most. I've spent more than twenty years in software, a lot of that time [leading engineers](/blog/technical-leadership-lessons). People get good by [doing the work](/blog/stop-calling-it-imposter-syndrome), having it reviewed, getting things wrong, fixing them, and seeing what happens when software meets real users. Seniority is not a function of time. It comes from having seen enough decisions play out. If AI takes some of the work that used to give people those experiences, we need another deliberate way for them to build judgement. I'm not sure enough companies are thinking about that yet. ## The early warning is already there On 12 August, the [Stanford Digital Economy Lab published updated research](https://digitaleconomy.stanford.edu/news/canariesaug26/) using payroll data from ADP. It found that employment among 22 to 25-year-olds in highly AI-exposed occupations was about 19% below where it would have been if it had kept pace with employment among similarly aged workers in less-exposed occupations. The change appeared to be coming mainly from lower hiring rather than more people leaving those jobs. That doesn't prove AI caused it. The researchers are clear about that, and the figures cover more than software development. But it does match the thing I'm worried about. Companies don't need to make a big announcement that they are replacing junior developers with AI. They can just stop opening as many junior roles because the immediate need feels less obvious. That decision makes sense one company at a time. Across the industry, it creates a problem. We still need experienced engineers. People who understand systems, can challenge a requirement, and will take responsibility when something goes live. People who can spot when an answer looks convincing and is still wrong. Those skills come from practice. AI can support that practice. It cannot give somebody the experience of being accountable for a real decision. ## The junior role has to change I don't think the answer is keeping pointless work around so juniors have something to do. If AI can take the repetitive stuff, we should use it. The junior role has to change, but it cannot become sitting there reviewing AI output. People still need to design, change, debug and operate real software. A first pass from AI is fine. The developer should still be able to explain what it does, why it fits the system, what could go wrong, and how they tested it. Give them small but real pieces of work, then increase the responsibility as their judgement improves. Let them use AI. Don't let the tool own the decision. They need to see production problems, hear why requirements change, and understand what happens after a feature has shipped. This takes time from senior people. There is no clever way around that. If every senior engineer is measured only on how much they deliver this month, mentoring somebody will always look inefficient. [Tech debt grows the same way](/blog/tech-debt-leadership-problem). That time has to be planned rather than squeezed in around delivery. The benefit arrives later, when that person can handle harder work without everything being passed upwards. I don't have a finished answer yet. I do think hiring fewer junior developers and hoping the senior market sorts itself out is too easy. We still need to give people a way in, let them do real work, and spend time reviewing it. That is slower than asking AI. It is also how people get good. --- ## If AI Makes Software Faster, Should Clients Pay Less? Source: https://www.markdarling.com/blog/if-ai-makes-software-faster-should-clients-pay-less Published: 03 AUG 2026 · Category: business I've been using AI heavily in software development for a while. Now that I run a software agency, one question keeps coming back. If something used to take a developer five days and now takes two, what should the client pay? My first instinct is less. If the effort has genuinely fallen, it feels difficult to argue that the client should never see any of the saving. But the more I've thought about it, the less I think faster code gives us the whole answer. How the work was sold matters. On time and materials, it is fairly obvious. If something takes two days, the client pays for two days. Fixed-price work is different. The agency agreed to deliver an outcome and took the risk that it might take longer than expected. If it finds a better way and finishes early, I think it is reasonable for the agency to keep some of that benefit. What doesn't really work is knowing the job now takes eight days and continuing to quote twenty next time. ## AI is fast. That doesn't mean the work is finished I use these tools myself. They can explore an unfamiliar codebase, trace how something works, produce a decent first pass and write tests without starting from a blank screen. The difference is real. The thing is, someone still has to decide whether the answer is any good. Does it solve the right problem? Does it fit the rest of the system? Has it copied a pattern that looks right but is wrong here? What happens when it meets real production data? [Sonar's 2026 State of Code survey](https://www.sonarsource.com/state-of-code-developer-survey-report.pdf) asked more than 1,100 developers about their use of AI. They estimated an average personal productivity gain of 35%, but only 4% said they completely trusted AI-generated code to be functionally correct. That feels about right to me. AI can produce a convincing answer very quickly. Sometimes it has genuinely removed hours of work. Other times it has moved the work into checking, testing and correcting what it produced. At this point in my career, I spend less time typing code and more time judging it. That judgement is [the thing juniors don't have yet](/blog/if-ai-does-the-junior-work-where-do-senior-engineers-come-from), and AI can't hand it to them. Twenty years of experience is more useful when I'm deciding whether an approach makes sense than when I'm writing another controller by hand. That judgement still takes time. More importantly, somebody still owns what happens when the software goes live. ## So where should the saving go? I don't think there is one neat pricing model that suddenly fixes this. If the work is clear and repeatable, fixed pricing makes sense. The agency can improve how it delivers, the client knows what it will pay and the agency keeps some of the upside if it performs well. Product work is often less tidy. Sometimes neither side knows what will be uncovered until the work starts. Charging for a team or an agreed amount of time can still be the honest answer because the uncertainty is real. Either way, clients should benefit when AI makes delivery faster. That could be a lower price, an earlier launch, more useful work within the same budget or more time spent testing the thing properly. I also think the agency needs to benefit. Using AI well involves more than buying a licence. [Teams have to change how they work](/blog/ai-consultants-bullshitting), review more carefully and know when not to trust the answer. The agency is still responsible if it gets that wrong. My view at the moment is that clients should not expect every AI-assisted project to cost half as much. Faster code is not the same as cheaper software. But agencies cannot pretend nothing has changed either. If we know something that used to take twenty days now takes eight, we should not keep quoting twenty. That part seems fairly obvious. --- ## Tech Debt Isn't a Coding Problem. It's a Leadership Problem. Source: https://www.markdarling.com/blog/tech-debt-leadership-problem Published: 20 JAN 2026 · Category: business Every engineering team I've worked with has complained about tech debt. The codebase is a mess. There's no time to fix it. We're always firefighting. And almost every time, when you dig in, the debt isn't really a coding problem. It's a leadership problem. ## What tech debt actually is Tech debt gets thrown around loosely. But at its core, it's simple: it's the gap between how your code is and how it should be. Sometimes that gap is intentional. You shipped fast to hit a deadline, knowing you'd clean up later. That's a trade-off. Reasonable. But most tech debt isn't that. Most tech debt is the accumulation of small decisions over time. Shortcuts that were never meant to be permanent. Patterns that made sense once but don't anymore. Code nobody fully understands because the person who wrote it left two years ago. And here's the thing: almost none of that happens because engineers don't care. It happens because the environment makes it inevitable. ## How leadership creates debt ### Never saying no Every feature request that gets a yes adds to the surface area of your codebase. More code means more to maintain. More edge cases. More things that can break. Good leaders protect the backlog. They push back on scope. They ask "do we really need this?" before it becomes someone else's problem to build and maintain. When everything is a priority, nothing is. And the codebase pays the price. ### Rewarding speed over sustainability What gets measured gets managed. If you only celebrate features shipped, that's what you'll get. Fast features, fragile foundations. Teams respond to incentives. If cleaning up tech debt is invisible work that never gets acknowledged, don't be surprised when it never gets done. The same incentive is [quietly killing junior hiring](/blog/if-ai-does-the-junior-work-where-do-senior-engineers-come-from). ### Ignoring the warnings Engineers usually know where the problems are. They'll flag it in retros. Mention it in one-on-ones. Put it on the roadmap that never gets prioritised. If leadership consistently ignores these signals, or worse, treats them as whining, the problems compound. And by the time they're impossible to ignore, they're much harder to fix. ### No time for the boring work Refactoring isn't sexy. Upgrading dependencies isn't a feature launch. Writing tests for legacy code doesn't make the demo reel. But this is the work that keeps systems healthy. If there's never time for it, if it always gets bumped for "real work", debt grows. Quietly, then suddenly. ## The symptoms show up late Tech debt is sneaky. The codebase doesn't collapse overnight. It degrades slowly. ![How debt arrives. By the time the lines cross, the team has been living with it for months.](/images/posts/tech-debt-curve.svg) First, things take a bit longer than they should. Then bugs start appearing in unexpected places. Then new features become painful to ship because everything's tangled together. By the time leadership notices (usually when a big initiative is behind schedule) the debt is already significant. And the team has been living with it for months. ## What good leadership looks like ### Make space for maintenance Build time for tech health into every sprint. Not as a "if we have time" bonus. As a non-negotiable. [At Gymshark](/blog/technical-leadership-lessons), we eventually landed on dedicating real capacity to platform work. Not a hack day. Consistent, protected time. ### Celebrate the invisible work When someone refactors a gnarly piece of code, that's worth recognising. When a team pays down debt that's been slowing them down, that's a win. > What you celebrate shapes what people prioritise. Make the boring work visible. ### Listen to the engineers They know where the bodies are buried. If your senior engineers are consistently raising the same concerns, pay attention. They're not complaining. They're trying to help. ### Own the trade-offs Sometimes you do need to ship fast and accept some debt. That's fine. But own it. Acknowledge it. And have a plan to pay it back. The worst thing you can do is pretend the debt doesn't exist, or expect the team to magically fix it without changing anything else. ## The honest conversation Tech debt is a leadership problem because leaders control the environment. The priorities. The incentives. The pace. You can hire the best engineers in the world. Give them unlimited time. All the tools. But if the system they're working in rewards short-term speed over long-term health, debt will accumulate. That's not a coding problem. That's a culture problem. And culture starts at the top. ## Wrapping up Next time your team says the codebase is a mess, resist the urge to blame the code. Or the engineers. Ask instead: what decisions led here? What priorities shaped this? What are we going to change so it doesn't happen again? Tech debt is real. But it's usually a symptom, not a cause. Fix the system, and the code will follow. --- ## Stop Calling It Imposter Syndrome. You're Just Learning. Source: https://www.markdarling.com/blog/stop-calling-it-imposter-syndrome Published: 06 JAN 2026 · Category: life Somewhere along the way, we decided that feeling uncertain about your abilities was a syndrome. A condition. Something to diagnose and overcome. I think we've got it backwards. ## The overused label Every time someone steps into a new role, takes on a bigger challenge, or finds themselves surrounded by people who seem to know more, we call it imposter syndrome. New job? Imposter syndrome. Speaking at a conference? Imposter syndrome. Leading a team for the first time? Definitely imposter syndrome. But here's the thing: sometimes you feel out of your depth because you *are* out of your depth. That's not a syndrome. That's just... learning. ## What imposter syndrome actually is Real imposter syndrome is persistent. It's when you've been doing something for years, you're objectively good at it, and you still believe you're a fraud who's about to be found out. That's worth addressing. That's a pattern of thinking that holds people back. But feeling nervous in your first board meeting? Feeling like everyone else knows more in a room full of specialists? That's not imposter syndrome. That's called being new. ## Why the distinction matters When we label every moment of uncertainty as imposter syndrome, we do two things: **1. We pathologise normal growth** Learning is uncomfortable. Stepping into new territory is supposed to feel uncertain. If you're never feeling out of your depth, you're probably not stretching yourself. Calling it a syndrome makes it sound like something's wrong with you. Nothing's wrong. You're just growing. **2. We reach for the wrong solutions** The advice for imposter syndrome is usually about mindset shifts. Reminding yourself of your achievements, challenging negative self-talk, building confidence. But if you're actually just new at something, you don't need a mindset shift. You need reps. You need practice. You need time. The solution isn't to convince yourself you already know enough. It's to accept that you don't, and get on with learning. ## A more useful frame Next time you feel uncertain, ask yourself: **Am I actually new at this?** If yes, congratulations. You're learning. The discomfort is temporary. Keep going. **Have I been doing this for years and still feel like a fraud?** That's different. That's worth unpacking. Maybe with a coach, a mentor, or a good therapist. Most of the time, it's the first one. ## The comfort of competence Here's something nobody tells you: that feeling of ease and confidence you're chasing? It comes *after* the awkward phase. Not instead of it. > Every expert was once a beginner who felt like they didn't belong. The difference is they stuck around long enough for the feeling to pass. I've felt out of my depth more times than I can count. First engineering role. [First leadership role](/blog/technical-leadership-lessons). First time managing managers. First time [consulting on AI](/blog/ai-consultants-bullshitting) after years of mobile engineering. Every time, there was a voice saying "you don't know what you're doing." And every time, it was partly right. I didn't fully know what I was doing. *Yet.* ## The dangerous flip side There's an opposite problem that doesn't get talked about enough: people who never feel like imposters when they probably should. We've all met them. Confident beyond their competence. Happy to weigh in on things they don't understand. Never doubting, always certain. A little self-doubt isn't weakness. It's self-awareness. It keeps you learning, keeps you humble, keeps you asking questions. I'd rather work with someone who sometimes wonders if they're good enough than someone who never questions themselves at all. ## Wrapping up Feel uncertain about something new? Good. That's what growth feels like. Feel uncertain about something you've been doing for a decade? That might be worth looking at. --- But let's stop calling every moment of discomfort a syndrome. Sometimes you're not an imposter. You're just a beginner. And that's exactly where you're supposed to be. --- ## Most AI Consultants Are Bullshitting You. Here's How to Spot Them. Source: https://www.markdarling.com/blog/ai-consultants-bullshitting Published: 23 DEC 2025 · Category: business There's a gold rush happening in AI consulting right now. Everyone's an expert. Everyone's got a framework. Everyone's promising transformation. Most of it is noise. I say this as someone who now does AI consulting. I've sat in enough meetings to know when someone's actually done the work versus when they're regurgitating ChatGPT's output back at you with a confident smile. Here's how to spot the difference. ## The red flags ### They can't explain it simply Real expertise means you can explain complex things in plain English. If someone's drowning you in jargon ("agentic workflows", "multimodal pipelines", "retrieval-augmented generation") without ever grounding it in your actual problem, they're probably hiding behind the words. Ask them to explain it like you're a smart 12-year-old. Watch what happens. ### They promise transformation in weeks AI adoption done well is slow. It's messy. It involves changing how people work, not just plugging in a new tool. Anyone promising you'll "transform your business with AI in 6 weeks" is either lying or selling you something so shallow it won't stick. ### They've never built anything This is a big one. Ask what they've actually shipped. Not advised on. Not consulted for. *Built.* Lots of AI consultants have read the docs, watched the YouTube videos, maybe done a weekend course. Very few have wrestled with [the reality of putting AI into production](/blog/if-ai-makes-software-faster-should-clients-pay-less). The edge cases, the failures, the "why is it saying that?" moments at 2am. ### Their case studies are suspiciously vague "We helped a Fortune 500 company improve efficiency by 40%." Cool. How? What did you *actually* do? What went wrong? What would you do differently? Vague case studies are a sign someone's either exaggerating or wasn't close enough to the work to know the details. ### They lead with the technology Good consultants start with your problem. Bad ones start with the solution they're selling. If someone's pitching you "an AI strategy" before they've understood your business, your customers, and where you're actually struggling? Run. ## The green flags ### They ask uncomfortable questions The best consultants I've worked with made me think. They asked why we were doing things. They challenged assumptions. They weren't just there to agree with us. > If someone's nodding along to everything, they're not consulting. They're flattering. ### They've failed publicly Sounds counterintuitive, but I trust people who can talk openly about what went wrong. AI projects fail all the time. Anyone pretending otherwise hasn't done enough of them. ### They're specific about limitations AI isn't magic. It's good at some things and terrible at others. Someone who's honest about where AI won't help you is someone worth listening to. ### They focus on the people, not just the tech The hardest part of AI adoption isn't the models. It's getting people to actually use them. It's changing workflows. It's building trust. Good consultants know this. They'll spend as much time talking about change management as they do about prompts and fine-tuning. ## What to ask before you hire Here's my shortlist: 1. **What have you actually built with AI?** Not advised on. [Built](/products). 2. **What's a project that failed? What did you learn?** 3. **How do you measure success?** If it's just "engagement" or "adoption", push harder. 4. **What shouldn't we use AI for?** If they can't answer this, they don't know the tech well enough. 5. **What's your honest timeline?** Then double it. That's probably closer to reality. ## The uncomfortable truth Some of the best AI work happening right now is being done by people inside companies, not consultants. People who understand the domain, have access to the data, and can iterate quickly. External help can accelerate things. But it can't replace internal capability. If a consultant's plan doesn't include building your team's skills and eventually making themselves redundant, they're not setting you up for success. They're setting up a retainer. --- The AI hype is real. So is the opportunity. But there's a lot of money being wasted on consultants who are better at selling than delivering. Do your homework. Ask hard questions. And remember: the best people in this space are usually too busy doing the work to be on LinkedIn every day telling you about it. --- ## What Scaling Mobile Teams Taught Me About Technical Leadership Source: https://www.markdarling.com/blog/technical-leadership-lessons Published: 22 JUN 2025 · Category: business Leading a mobile team through rapid growth is hard. It’s not just about code. It’s people, process, and figuring out how to stay sane when everything’s moving fast. I’ve been through it at Gymshark and with a bunch of scale-ups. Here’s what’s stuck with me. ## How technical leadership evolves Leading two developers isn’t the same as steering multiple squads. You’ve got to shift how you lead as your team grows. Here’s how I think about the different stages. ### Still in the code (2–5 people) You’re writing code every day. You lead by doing, and mentoring happens naturally. **What matters most:** - Writing solid code and shaping the architecture - Pairing and [mentoring junior devs](/blog/if-ai-does-the-junior-work-where-do-senior-engineers-come-from) - Setting the tone for how the team works - Building early habits for comms and culture ### Keeping the wheels turning (5–15 people) You’re not coding as much. Now it’s about keeping things aligned and moving. **What matters most:** - Making sure teams talk to each other - Agreeing how decisions get made - Smoothing out process and tooling - Helping people grow in their roles ### Big picture thinking (15+ people) Now you’re thinking strategy, not sprint tickets. Your job is to make the whole system work. **What matters most:** - Owning the tech vision and roadmap - Structuring teams to scale well - Hiring great people and helping them grow - Keeping stakeholders aligned without bullshitting ## What Gymshark taught me Gymshark grew fast. Really fast. It forced us to rethink how we led tech teams. These were some of the biggest lessons. ### 1. Comms don’t scale like code What worked in a small team broke down when we got bigger. We needed structure to replace hallway chats. **What helped:** - Writing down key decisions clearly - Regular cross-team tech demos - Clear, consistent code review habits - Known paths for escalating tricky problems ### 2. Autonomy needs guardrails Autonomy isn’t chaos. It’s about setting boundaries so teams can run fast without stepping on each other. **What we put in place:** - Shared principles for how we build - Clear interfaces between teams - Agreed tooling and infrastructure - Regular check-ins to stay aligned ### 3. Tech debt is a leadership issue It’s not just messy code. It’s what you’ve chosen not to prioritise. Good leaders treat debt like any other business trade-off. [I’ve written that one up properly](/blog/tech-debt-leadership-problem). ## How to build a great mobile team ### Hire for potential Tech changes fast. I’d rather hire someone sharp and curious than someone with the “right” stack on their CV. ### Make space to learn The best mobile devs I’ve worked with are always learning. Give them room to experiment and grow. ### Deliver, don’t just polish Great code matters. But what you ship is what counts. Don’t lose sight of impact. ## Common traps to avoid ### Perfection paralysis Trying to make every call perfect slows everything down. Sometimes “good enough” really is. ### Too hands-off If you step too far back, you lose sight of quality and direction. Stay close enough to spot trouble early. ### Hero mode If you’re solving every problem, you’re the bottleneck. Let your team take the wheel. ## A few frameworks I’ve found useful ### 1. Technical decision matrix Not every decision is life-or-death. Rate them by impact and reversibility. Treat them accordingly. ### 2. Growth conversations One-on-ones that focus on where someone’s going, not just what they’re doing now. ### 3. Technical vision Don’t just talk about the future. Write it down. Tie it to the business. Get buy-in early. ## Wrapping up > Good technical leadership isn’t about being the smartest in the room. It’s about setting others up to do great work. The best bit? Watching your team grow. That, and seeing what a well-led team can actually deliver.