{"@attributes":{"version":"2.0"},"channel":{"title":"Josh Hornby","link":"https:\/\/joshhornby.com","description":"Recent content on Josh Hornby's blog","language":"en-gb","lastBuildDate":"Sun, 26 Jul 2026 09:56:28 +0000","generator":"Jekyll","image":{"url":"https:\/\/joshhornby.com\/assets\/images\/headshot.jpg","title":"Josh Hornby","link":"https:\/\/joshhornby.com"},"item":[{"title":"The Tech Lead Trap","description":"
\n

This post is part of my Tech Lead Series<\/a>, a collection of practical advice for engineers stepping into leadership roles.<\/p>\n<\/blockquote>\n\n

A former colleague spent eight years as a tech lead. Same level, different teams. He was good at the job: respected by his teams, trusted by stakeholders, reliable. But when he started looking for his next role, he found that his skills hadn\u2019t grown much in five years. He\u2019d become very good at a job that no longer challenged him.<\/p>\n\n

He\u2019d fallen into the tech lead trap.<\/p>\n\n

The trap is subtle. The role is comfortable. You\u2019re competent. People appreciate your work. There\u2019s no obvious crisis forcing change. But beneath the surface, you\u2019ve stopped growing. The job that once stretched you now fits too well.<\/p>\n\n

How the trap works<\/h2>\n\n

The tech lead role has a natural ceiling. Once you\u2019ve mastered the basics, the work becomes routine. You know how to run 1:1s<\/a>. You know how to push back on scope<\/a>. You know how to balance coding and leading<\/a>. The challenges that used to require growth now just require execution.<\/p>\n\n

This happens for several reasons.<\/p>\n\n

Your influence is locally bounded. It extends to your team and maybe some adjacent ones. Problems that require broader influence don\u2019t come to you. You solve the same scale of problems year after year.<\/p>\n\n

A well-running team doesn\u2019t need heroics. When things are going well, there\u2019s less pressure to change anything. The reward for doing the job well is doing the same job again.<\/p>\n\n

And when work is comfortable, you stop seeking discomfort. But growth happens at the edge of your abilities, not in the middle.<\/p>\n\n

The stagnation is invisible too. Your manager sees a reliable performer. Your team sees a steady leader. From the outside, everything looks fine. Sometimes you\u2019re the last person to notice.<\/p>\n\n

Signs you\u2019re trapped<\/h2>\n\n

Some signals that suggest you\u2019ve stopped growing:<\/p>\n\n

When did you last struggle with something new? If every problem feels like a variation on something you\u2019ve solved before, you\u2019re not being challenged.<\/p>\n\n

You can do the job on autopilot. Meetings, decisions, and reviews all run on muscle memory. You\u2019re executing, not thinking.<\/p>\n\n

You\u2019ve stopped being curious about new technologies, about how other teams work, about problems outside your domain. Curiosity fades when everything feels familiar.<\/p>\n\n

Your conversations haven\u2019t changed. The same stakeholder issues, the same team dynamics, the same technical debates. Nothing new enters the picture.<\/p>\n\n

Ask yourself: what have I learned this year that I didn\u2019t know last year? If you can\u2019t answer, you probably haven\u2019t grown.<\/p>\n\n

And if you\u2019re waiting for something to change, hoping for a promotion or a new project or a different manager, that\u2019s a sign you\u2019ve given up on creating change yourself.<\/p>\n\n

Getting out<\/h2>\n\n

Escaping the trap requires intentional action. Comfort is self-reinforcing, and you won\u2019t drift out of it.<\/p>\n\n

Volunteer for initiatives outside your usual scope. Cross-functional projects, new domains, problems nobody owns. Unfamiliar territory is where the learning happens.<\/p>\n\n

Start contributing beyond your team. Help other tech leads, mentor engineers in other groups, take on org-wide technical initiatives. The skills you\u2019ve built have broader applications than you think.<\/p>\n\n

Write about what you\u2019re learning. Present to your team or company. Teaching forces you to deepen your understanding and exposes gaps in your knowledge.<\/p>\n\n

Figure out what you\u2019re avoiding because it\u2019s uncomfortable. Public speaking? System design? Strategic thinking? Go toward it.<\/p>\n\n

Ask people you trust where your blind spots are. What should you be better at? What\u2019s holding you back from the next level? Listen to the answers.<\/p>\n\n

And sometimes the trap is the role itself. If you\u2019ve genuinely maxed out growth opportunities where you are, moving to a new team, new company, or new role might be the right answer.<\/p>\n\n

The fork in the road<\/h2>\n\n

Most tech leads eventually face a choice: engineering management or the technical track.<\/p>\n\n

Engineering management means moving toward people leadership. Less code, more 1:1s, more organisational thinking. You become responsible for teams, not systems. The tech lead role is partial preparation, but management requires new skills: hiring, performance management, navigating organisational politics.<\/p>\n\n

The technical track means moving toward Staff or Principal engineer roles<\/a>. Deeper technical influence, broader architectural scope, less direct people responsibility. You\u2019re still leading, but through technical contribution rather than team management.<\/p>\n\n

Both are valid paths. Neither is a promotion from tech lead; they\u2019re different jobs. The trap often comes from not choosing either, staying in the middle ground where you\u2019re doing some of both but not progressing in either.<\/p>\n\n

Think honestly about which path fits you. Some tech leads love the people side and should go toward management. Some love the technical side and should grow into Staff roles. Some discover they want something else entirely.<\/p>\n\n

Staying sharp in the role<\/h2>\n\n

Maybe you\u2019re not ready to leave. Maybe you like being a tech lead and want to stay. You can still avoid the trap.<\/p>\n\n

Different teams have different challenges. Rotating to a new team resets your learning curve and exposes you to new problems.<\/p>\n\n

Volunteer for the struggling team, the complex domain, the critical project. Comfort comes from predictability, and the hardest teams teach you the most.<\/p>\n\n

Identify something you want to get better at and pursue it with intent. Take courses, find mentors, put in deliberate practice.<\/p>\n\n

Set growth goals alongside your delivery goals. What skill will you have in a year that you don\u2019t have now? What will you understand that you don\u2019t understand today?<\/p>\n\n

Don\u2019t wait for performance reviews to get feedback. Ask colleagues what you could do better. Seek out honest assessments of your work.<\/p>\n\n

The honest question<\/h2>\n\n

The question to ask yourself: am I still growing?<\/p>\n\n

Performance can continue long after growth stops. Comfort can coexist with stagnation. So the question isn\u2019t whether you\u2019re still good at your job. It\u2019s whether you\u2019re still getting better.<\/p>\n\n

Are you learning? Are you being challenged? Are you better this year than last year? Will you be better next year than this year?<\/p>\n\n

If the answer is no, you\u2019re in the trap. And the only way out is to acknowledge it and do something different.<\/p>\n\n

My colleague who spent eight years at the same level eventually moved to a Staff engineer role at a different company. The transition was hard. He\u2019d atrophied in ways he hadn\u2019t noticed. But within a year, he was learning again, challenged again, growing again.<\/p>\n\n

The trap isn\u2019t permanent. But escaping it requires you to notice you\u2019re in it.<\/p>\n","pubDate":"Tue, 03 Mar 2026 08:00:00 +0000","link":"https:\/\/joshhornby.com\/the-tech-lead-trap","guid":"https:\/\/joshhornby.com\/the-tech-lead-trap"},{"title":"Inheriting a Struggling Team","description":"

\n

This post is part of my Tech Lead Series<\/a>, a collection of practical advice for engineers stepping into leadership roles.<\/p>\n<\/blockquote>\n\n

Inheriting a struggling team is one of the hardest things a tech lead can face. The problems run deep and the trust is gone. But it\u2019s also an opportunity. Teams in crisis have nowhere to go but up.<\/p>\n\n

Understanding what you\u2019ve inherited<\/h2>\n\n

Before you can fix anything, you need to understand what\u2019s actually broken. The symptoms are visible; the causes are usually hidden.<\/p>\n\n

Talk to everyone. Schedule 1:1s with every team member in your first week. Ask open questions: What\u2019s working? What\u2019s not? What would they change? What do they wish leadership understood? Listen more than you talk. This is the same advice from your first 90 days<\/a>, but compressed.<\/p>\n\n

Read the history. Old retrospectives, incident reports, architecture documents, Slack history. What patterns emerge? What keeps going wrong? What decisions led to this point?<\/p>\n\n

Understand the departures. If people left, find out why. Exit interviews if they exist, informal conversations if you can manage them. People leave struggling teams for reasons, and those reasons tell you what\u2019s wrong.<\/p>\n\n

Identify the real problems. The obvious problems are rarely the root problems. Technical debt is often a symptom of unclear priorities. Low morale is often a symptom of feeling unheard. Dig until you find causes, not just effects.<\/p>\n\n

Find the bright spots. Even struggling teams have things that work. People who still care, processes that function, code that\u2019s actually solid. Build on these rather than only focusing on what\u2019s broken.<\/p>\n\n

Quick wins matter<\/h2>\n\n

Struggling teams have often been promised turnarounds before. They\u2019ve heard the speeches about change. They\u2019re sceptical, and they should be.<\/p>\n\n

Words alone won\u2019t change their minds. Only action builds credibility.<\/p>\n\n

Find something you can fix in the first two weeks. Something visible, something the team cares about. It doesn\u2019t have to be big. Cancel a useless meeting. Fix the flaky test that everyone hates. Push back on an unreasonable demand from stakeholders.<\/p>\n\n

The specific fix matters less than what it signals: things can change, and raising problems with you leads to action.<\/p>\n\n

Building trust<\/h2>\n\n

Trust is usually the deepest wound. The team has learned that leadership doesn\u2019t deliver and that feedback goes nowhere.<\/p>\n\n

You rebuild trust through consistent, small actions over time.<\/p>\n\n

Do what you say. Every commitment you make matters. If you say you\u2019ll follow up on something, follow up. If you say you\u2019ll look into a problem, look into it. Dropped promises confirm that nothing has changed.<\/p>\n\n

Be honest about what you can\u2019t do. Don\u2019t promise changes you can\u2019t deliver. \u201cI can\u2019t fix the technical debt in a month, but I can protect time for us to address some of it\u201d is honest. \u201cI\u2019ll fix everything\u201d is a lie.<\/p>\n\n

Admit what you don\u2019t know. You\u2019re new. You don\u2019t understand everything. Pretending otherwise insults your team\u2019s intelligence. \u201cI\u2019m still learning how this system works\u201d builds more trust than pretending expertise.<\/p>\n\n

Protect them. When unreasonable demands come from outside, push back. Let the team see you doing it. Nothing builds trust faster than watching your lead fight for you.<\/p>\n\n

Follow through on feedback. When someone raises a concern, act on it or explain why you can\u2019t. The worst thing is asking for feedback and then ignoring it.<\/p>\n\n

Addressing performance issues<\/h2>\n\n

Struggling teams sometimes have performance issues that were never addressed. The previous lead was too busy firefighting or too conflict-averse to have hard conversations.<\/p>\n\n

You need to address these, but carefully.<\/p>\n\n

Don\u2019t rush to judgment. People underperform in struggling teams because the environment enables it. Before concluding someone is a poor performer, give them a functioning team to perform in.<\/p>\n\n

Separate environment from individual. Is this person struggling because they\u2019re not capable, or because the context makes success impossible? Fix the context before judging the person.<\/p>\n\n

But don\u2019t avoid the hard calls. Sometimes performance issues are real and persistent. When you\u2019ve given someone a fair chance and clear feedback<\/a> and they still don\u2019t improve, you have to act. Keeping non-performers hurts everyone else.<\/p>\n\n

Be fair. The team is watching how you handle this. If you\u2019re arbitrary or cruel, trust collapses. If you\u2019re fair and clear, even difficult decisions can build credibility.<\/p>\n\n

Fixing the technical mess<\/h2>\n\n

Struggling teams usually have struggling codebases. Tech debt, architectural rot, unclear ownership. This can\u2019t be fixed quickly, but it can be managed.<\/p>\n\n

Stop the bleeding. Before improving anything, stop making it worse. Establish minimum quality standards. No more shortcuts that create debt.<\/p>\n\n

Make debt visible. Track it. Name it. Talk about it in planning. When the team understands the cost of debt, they\u2019re more motivated to address it. I\u2019ve written about reconsidering how we talk about tech debt<\/a> elsewhere.<\/p>\n\n

Carve out time. Protect some percentage of each sprint for debt reduction. It doesn\u2019t have to be a lot. Even 10% adds up.<\/p>\n\n

Celebrate progress. When a gnarly piece of code gets cleaned up, acknowledge it. Progress on debt is real work, even if stakeholders don\u2019t see it.<\/p>\n\n

Be patient. Technical messes take time to create and time to fix. Rushing leads to new messes. Steady, sustainable progress beats heroic sprints.<\/p>\n\n

Communicating with stakeholders<\/h2>\n\n

Stakeholders have learned not to trust this team. They\u2019ve been burned by missed deadlines and broken features. Your job is to reset that relationship.<\/p>\n\n

Be honest about where things stand. Don\u2019t hide the mess. \u201cWe have significant technical debt that\u2019s slowing us down and causing quality issues\u201d is better than pretending everything is fine.<\/p>\n\n

Set realistic expectations. Don\u2019t promise a quick turnaround to look good. Set timelines you can actually meet. Rebuilt trust comes from kept promises, not optimistic forecasts.<\/p>\n\n

Show progress. Regular updates on what\u2019s improving. Delivered features, but also fewer incidents and better velocity. Make the recovery visible.<\/p>\n\n

Ask for what you need. If the team needs time, resources, or protection from demands, advocate for it. Stakeholders can be reasonable when they understand the situation.<\/p>\n\n

The long game<\/h2>\n\n

Turning around a struggling team takes time. Not weeks, but months. Probably six months before things feel genuinely different. A year before the turnaround is clearly sustained.<\/p>\n\n

The early period is the hardest. You\u2019re fixing problems that aren\u2019t your fault and cleaning up messes you didn\u2019t make. It feels thankless.<\/p>\n\n

But teams that come through hard times together get strong. The engineers who stay through a turnaround are committed, and they don\u2019t take things for granted.<\/p>\n\n

The way up is hard, but it\u2019s rewarding in ways that leading a comfortable team never is.<\/p>\n","pubDate":"Fri, 27 Feb 2026 08:00:00 +0000","link":"https:\/\/joshhornby.com\/inheriting-a-struggling-team","guid":"https:\/\/joshhornby.com\/inheriting-a-struggling-team"},{"title":"Giving Hard Feedback","description":"

\n

This post is part of my Tech Lead Series<\/a>, a collection of practical advice for engineers stepping into leadership roles.<\/p>\n<\/blockquote>\n\n

Giving hard feedback is uncomfortable. That\u2019s why most people avoid it. But avoiding it doesn\u2019t make the problem go away. It just delays the conversation until it\u2019s worse for everyone.<\/p>\n\n

Why hard feedback matters<\/h2>\n\n

People can\u2019t fix what they don\u2019t know is broken. When you see a performance issue, an attitude problem, or a skill gap and don\u2019t address it, you\u2019re denying that person the chance to improve.<\/p>\n\n

You\u2019re also being unfair to your team. If an engineer consistently ships late, everyone\u2019s velocity drops. Dismissive behaviour in code reviews stops people from contributing. When you don\u2019t address these problems, you\u2019re choosing the comfort of avoiding one conversation over the wellbeing of the whole team.<\/p>\n\n

Hard feedback is a form of respect. You\u2019re treating someone as capable of hearing the truth and acting on it. The alternative, staying quiet, assumes they can\u2019t handle it. As Camille Fournier notes in The Manager\u2019s Path<\/a>, \u201cwhen they believe that their manager sees the good things they do, they\u2019ll be more open to hearing about the areas where they might improve.\u201d<\/p>\n\n

Principles<\/h2>\n\n

Some ideas that guide how to approach these conversations.<\/p>\n\n

Sooner is better. Small issues addressed early are minor corrections. The same issues left for months become serious problems. If you notice something in week two, address it in week three, not month six.<\/p>\n\n

Specific is better than vague. \u201cYour work has been slipping\u201d is hard to act on. \u201cThe last three PRs had bugs that made it to production, and you\u2019ve missed two sprint commitments\u201d is specific and something they can act on.<\/p>\n\n

Behaviour, not character. You\u2019re addressing what someone did, not who they are. \u201cYou interrupted colleagues in the last three meetings\u201d is about behaviour. \u201cYou\u2019re rude\u201d is about character. One can be changed; the other feels like an attack.<\/p>\n\n

Private, not public. Hard feedback happens in 1:1s<\/a>, not in team meetings. Public criticism shames; private conversations allow for honest discussion.<\/p>\n\n

Direct, not cruel. You can be clear without being harsh. \u201cI need to see improvement in the next month\u201d is direct. \u201cYou\u2019re the worst performer on the team\u201d is cruel and useless.<\/p>\n\n

The conversation<\/h2>\n\n

A structure that I have found to work is:<\/p>\n\n

State the purpose. Don\u2019t hide what the conversation is about. \u201cI want to talk about some concerns I\u2019ve had with recent work.\u201d Let them know this is serious.<\/p>\n\n

Share what you\u2019ve seen. Describe it with specific examples. Facts, not judgments. \u201cIn the last sprint, two of your stories weren\u2019t completed, and the one that shipped had a bug that caused an hour of downtime.\u201d<\/p>\n\n

Explain why it matters. \u201cWhen stories don\u2019t get completed, the team has to pick up the slack. When bugs ship, we lose customer trust and spend time on firefighting.\u201d<\/p>\n\n

Ask for their view. You might not have the full picture. \u201cWhat\u2019s your take on this? Is there context I\u2019m missing?\u201d Sometimes there are good reasons. Sometimes you learn about blockers you can remove.<\/p>\n\n

Set clear expectations. Be specific about what needs to change. \u201cGoing forward, I need you to complete your committed stories and test more before marking things done.\u201d<\/p>\n\n

Agree on next steps. What happens now? A plan to fix the issues? More check-ins? Specific support you\u2019ll provide? Make it real.<\/p>\n\n

Write it down. Write up what was discussed and share it. This creates accountability and protects both of you if things escalate.<\/p>\n\n

Handling reactions<\/h2>\n\n

Hard feedback often triggers emotional reactions. Some common ones and how to handle them.<\/p>\n\n

Defensiveness. They explain why each example isn\u2019t really their fault. Acknowledge their view without backing off. \u201cI hear that there were constraints, and those are worth discussing. But the pattern concerns me regardless of the reasons.\u201d<\/p>\n\n

Deflection. They point to other people\u2019s problems instead. Redirect. \u201cWe\u2019re talking about your situation right now. Other issues are separate conversations.\u201d<\/p>\n\n

Silence. They shut down and won\u2019t engage. Give them space. \u201cI know this is a lot to process. You don\u2019t have to respond now, but I\u2019d like to check in again tomorrow.\u201d<\/p>\n\n

Anger. They get upset or hostile. Stay calm. \u201cI can see this is frustrating. I\u2019m not trying to attack you; I\u2019m trying to help us find a way forward.\u201d<\/p>\n\n

Tears. Emotional reactions happen. Don\u2019t panic or rush to end the conversation. Pause, offer a tissue, give them a moment. The feedback still needs to be heard.<\/p>\n\n

Your job is to deliver the message clearly and kindly, not to manage their emotional response. Let them react, acknowledge their feelings, but don\u2019t let the reaction derail the conversation.<\/p>\n\n

Following up<\/h2>\n\n

The conversation is only the beginning.<\/p>\n\n

Check in often. Don\u2019t wait months to see if things improved. Weekly or fortnightly, ask how things are going, note progress, address continued concerns.<\/p>\n\n

Name improvement. When things get better, say so. \u201cI\u2019ve noticed the last two sprints have gone much better. Nice work.\u201d Positive feedback matters.<\/p>\n\n

Escalate if needed. If things don\u2019t improve despite clear feedback and support, you need to escalate. This means involving HR, starting formal processes, or having honest conversations about whether this role is the right fit.<\/p>\n\n

Keep records. Document your conversations, the expectations you set, and whether they were met. This protects both of you and makes sure nothing gets forgotten.<\/p>\n\n

Common mistakes<\/h2>\n\n

Sandwiching. Hiding criticism between compliments waters down the message. The person hears the praise and misses the point. Be direct about what needs to change.<\/p>\n\n

Waiting too long. The longer you wait, the worse it gets. Address issues early.<\/p>\n\n

Being vague. Fuzzy feedback is useless. \u201cDo better\u201d doesn\u2019t tell anyone what to do differently. Be specific.<\/p>\n\n

Making it personal. Attacking someone\u2019s character guarantees defensiveness. Stick to behaviour and impact.<\/p>\n\n

Not following up. Feedback without follow-up is pointless. The conversation is step one, not the whole process.<\/p>\n\n

Avoiding it entirely. The most common mistake. Hoping that problems will go away on their own.<\/p>\n\n

When it doesn\u2019t work<\/h2>\n\n

Sometimes, despite clear feedback and genuine support, things don\u2019t improve. This is hard but important to accept.<\/p>\n\n

Not everyone can do every job. Some people are in the wrong role, or have problems that feedback can\u2019t reach, or hear the feedback and choose to ignore it.<\/p>\n\n

When you\u2019ve been clear and supportive and improvement still doesn\u2019t happen, it\u2019s time for a different conversation. That might mean a performance improvement plan, a role change, or an exit.<\/p>\n\n

You gave them information and opportunity. What they do with it is their choice.<\/p>\n\n

The hardest part<\/h2>\n\n

The hardest part isn\u2019t the conversation itself. It\u2019s the days before, when you\u2019re dreading it. The anxiety, the script-writing in your head, the temptation to postpone.<\/p>\n\n

The anticipation is always worse than the reality. Once you\u2019re in the conversation, you\u2019re problem-solving, not suffering. And afterward, regardless of how it went, you\u2019ve done your job. You\u2019ve given someone the information they need to get better.<\/p>\n","pubDate":"Tue, 24 Feb 2026 08:00:00 +0000","link":"https:\/\/joshhornby.com\/giving-hard-feedback","guid":"https:\/\/joshhornby.com\/giving-hard-feedback"},{"title":"Making Technical Decisions Stick","description":"

\n

This post is part of my Tech Lead Series<\/a>, a collection of practical advice for engineers stepping into leadership roles.<\/p>\n<\/blockquote>\n\n

Decisions that aren\u2019t documented don\u2019t exist. They live in the memories of people who were in the room, until those people leave or forget. A decision made in a Slack thread that scrolled past last month might as well never have happened.<\/p>\n\n

Making technical decisions is one part of the job. Making them stick is another.<\/p>\n\n

Why decisions don\u2019t stick<\/h2>\n\n

Even good decisions fade without reinforcement.<\/p>\n\n

They\u2019re not written down. Verbal agreements in meetings evaporate. Six months later, nobody remembers what was decided or why.<\/p>\n\n

They\u2019re written but not findable. The decision exists in a Confluence page nobody visits, a Slack message nobody searches for, a Google Doc with no clear owner.<\/p>\n\n

The context isn\u2019t captured. Even when the decision is documented, the reasoning isn\u2019t. A year later, someone asks \u201cwhy do we do it this way?\u201d and nobody can answer.<\/p>\n\n

People weren\u2019t involved. Decisions made by a small group don\u2019t feel binding to people who weren\u2019t asked. They\u2019ll revisit the decision because, from their view, it was never really made.<\/p>\n\n

There\u2019s no follow-up. A decision without follow-through is just a suggestion. If nobody checks whether the decision is being followed, it won\u2019t be.<\/p>\n\n

Match documentation to the decision\u2019s weight<\/h2>\n\n

Not every decision needs the same treatment.<\/p>\n\n

Verbal agreement works for small, reversible decisions that affect only your team. \u201cLet\u2019s use this library for parsing.\u201d These can live in team memory, but expect to explain them again.<\/p>\n\n

Written summary works for decisions that affect multiple people or span time. A Slack message that captures what was decided and why. A brief note in your team\u2019s docs. Easy to write, easy to find later.<\/p>\n\n

Architecture Decision Records (ADRs) work for decisions that limit future work. An ADR is a short document that captures the context, the decision, the options you rejected, and the results. It becomes part of your project\u2019s permanent record.<\/p>\n\n

Request for Comments (RFCs) work for decisions that need input from many people or have high stakes. An RFC is a proposal that invites feedback before the decision is final. It documents both the decision and the discussion that led to it.<\/p>\n\n

Most decisions need only verbal agreement or written summary. Save ADRs and RFCs for decisions that matter: technology choices, architectural patterns, interfaces between systems.<\/p>\n\n

ADRs work because they\u2019re simple<\/h2>\n\n

A good ADR has six sections and fits on one page:<\/p>\n\n

# ADR-001: Use PostgreSQL for user service data<\/span>\n\n## Status<\/span>\nAccepted\n\n## Context<\/span>\nWe need a database for the new user service. The team has\nexperience with PostgreSQL and MongoDB. We expect relational\nqueries across user profiles, permissions, and audit logs.\n\n## Decision<\/span>\nUse PostgreSQL for the user service.\n\n## Results<\/span>\nRelational queries are straightforward. We lose MongoDB's\nflexible schema, which means migrations for schema changes.\n\n## Options rejected<\/span>\n-<\/span> **MongoDB**<\/span>: Better schema flexibility, but our query\n  patterns are relational and the team knows PostgreSQL better.\n-<\/span> **MySQL**<\/span>: Similar fit, but less team experience and weaker\n  JSON support.\n<\/code><\/pre><\/div><\/div>\n\n
Keep it short. If writing an ADR feels like a chore, it\u2019s too long.<\/p>\n\n
RFCs fail when they\u2019re theatre<\/h2>\n\n
RFCs work when they\u2019re real invitations for input, not rubber stamps.<\/p>\n\n
Share early. An RFC shared before you\u2019ve made up your mind gets real feedback. An RFC shared when you\u2019ve already decided just annoys people.<\/p>\n\n
Set clear timelines. \u201cComments by Friday\u201d creates urgency. Open-ended feedback periods drag on forever.<\/p>\n\n
Ask for feedback directly. Don\u2019t just post and wait. Ask specific people for input. Reach out to experts, to people affected, to the usual critics.<\/p>\n\n
Respond to feedback. Every comment deserves a response, even if it\u2019s \u201cthanks, but we\u2019re going in a different direction for these reasons.\u201d Ignored feedback teaches people not to bother.<\/p>\n\n
Make the decision. An RFC that never ends is worse than no RFC. Set a deadline, weigh the feedback, make a call, and write it down.<\/p>\n\n
Involvement determines whether decisions stick<\/h2>\n\n
The decision-making process matters as much as the decision itself.<\/p>\n\n
Involve the right people. Not everyone, but not no one. People affected by a decision should have a chance to weigh in. Decisions made without asking get reopened.<\/p>\n\n
Be explicit about the process. Are we deciding today? Taking input for a week then deciding? Who makes the final call? Vagueness about the process creates vagueness about the outcome.<\/p>\n\n
Disagree and commit. Once a decision is made, everyone should support it, even those who disagreed. If you can\u2019t get to agreement, be clear that you\u2019re making a call despite disagreement and expect people to follow through.<\/p>\n\n
Don\u2019t revisit without new information. Every decision can be debated forever. Establish that decisions stay made unless new facts arise. \u201cWe already decided this\u201d should end conversations, not start them.<\/p>\n\n
Decisions need visible attention, not rules<\/h2>\n\n
Follow-through doesn\u2019t mean a heavy process. It means someone is paying attention.<\/p>\n\n
Check in code reviews. When you see code that goes against a decision, ask about it. Sometimes there\u2019s a good reason; sometimes someone didn\u2019t know. Either way, it\u2019s a conversation.<\/p>\n\n
Point to decisions in discussions. When someone proposes something that clashes with a prior decision, point to the docs. \u201cWe decided X for these reasons. Has something changed?\u201d<\/p>\n\n
Update decisions when needed. Things change. If a decision no longer makes sense, update it explicitly. Don\u2019t let it fade away; mark it replaced and write down why.<\/p>\n\n
Model it yourself. Your own code should follow the decisions. If you ignore the standards, so will everyone else.<\/p>\n\n
Keep decisions close to the code<\/h2>\n\n
ADRs belong in a \/docs\/adr<\/code> folder in the repo. Decisions about this system live with this system. They\u2019re versioned, searchable, and visible in pull requests.<\/p>\n\n
Use a consistent numbering system. ADR-001, ADR-002. Numbers make decisions easy to reference. \u201cThis implements ADR-015\u201d in a commit message links decisions to outcomes.<\/p>\n\n
Review active ADRs once a quarter. Are they still relevant? Are they being followed? Are any ready to be replaced?<\/p>\n\n
If your team has never used ADRs, don\u2019t mandate them for everything. Write one ADR for one decision and see if it helps. Build the habit bit by bit.<\/p>\n\n
Shared understanding, not bureaucracy<\/h2>\n\n
Technical decisions shape how your systems evolve. When they\u2019re undocumented, they get forgotten. When they\u2019re made in isolation, they get ignored. When nobody follows up, they become suggestions.<\/p>\n\n
The goal isn\u2019t a process for its own sake. It\u2019s building a shared record of how things work and why. New team members can understand the system\u2019s history. Future decisions build on past ones. And the PostgreSQL you decided on three months ago is still what gets used.<\/p>\n","pubDate":"Fri, 20 Feb 2026 08:00:00 +0000","link":"https:\/\/joshhornby.com\/making-technical-decisions-stick","guid":"https:\/\/joshhornby.com\/making-technical-decisions-stick"},{"title":"Scope Creep and How to Fight It","description":"
\n  
This post is part of my Tech Lead Series<\/a>, a collection of practical advice for engineers stepping into leadership roles.<\/p>\n<\/blockquote>\n\n
Scope creep doesn\u2019t announce itself. It arrives as reasonable requests. Each addition seems small. Each conversation is \u201cwhile we\u2019re building this anyway.\u201d Nobody makes a bad decision. You just make a lot of small decisions that add up to a bad outcome.<\/p>\n\n
Recognising the pattern<\/h2>\n\n
\u201cWhile you\u2019re in there\u2026\u201d The logic seems sound. You\u2019re already working on the payment system, so why not also add refund handling? Because refund handling is a week of work you didn\u2019t plan for.<\/p>\n\n
\u201cThis would only take a few hours.\u201d People who don\u2019t build software underestimate how long things take. A few hours becomes a few days. And even if it really is a few hours, a dozen \u201cfew hours\u201d changes add up to weeks.<\/p>\n\n
\u201cThe customer really needs this.\u201d Urgent requests from customers feel impossible to refuse. But customers will always want more. The question is whether this specific addition is worth delaying everything else.<\/p>\n\n
\u201cWe forgot to include\u2026\u201d Discovered requirements feel like corrections to an incomplete plan, not additions. But they\u2019re still additions. The plan was complete for what it covered; this is new scope.<\/p>\n\n
\u201cJust a small tweak.\u201d Small is relative. Small compared to the original feature can still be real work. And small things ship with testing, documentation, edge cases.<\/p>\n\n
The common thread: each individual addition seems fair. The problem is the pile-up.<\/p>\n\n
Why it happens<\/h2>\n\n
Scope creep has a few common causes.<\/p>\n\n
When the initial scope isn\u2019t well-defined, people fill in the gaps with guesses. Those guesses get turned into requirements as work moves forward.<\/p>\n\n
Different stakeholders have different expectations. Without clear agreement on what\u2019s in and what\u2019s out, each stakeholder adds their own version. This is why working closely with your PM<\/a> on scope definition matters so much.<\/p>\n\n
PMs want to please stakeholders. Tech leads want to please PMs. Engineers want to solve problems. Everyone\u2019s drive is to say yes. Nobody\u2019s drive is to protect the timeline. Learning when to say no<\/a> is one of the most important skills for a tech lead.<\/p>\n\n
\u201cWe\u2019ve already built most of it, we might as well add this too.\u201d The logic feels right but ignores that adding more makes it even later.<\/p>\n\n
When the goal is vague (\u201cmake a good dashboard\u201d), scope expands to fill available time. When the goal is specific (\u201cshow four metrics, ship in two weeks\u201d), additions are clearly out of scope.<\/p>\n\n
Fighting it early<\/h2>\n\n
The best time to fight scope creep is before work starts.<\/p>\n\n
Define scope explicitly. Write down what\u2019s included and what\u2019s not. \u201cThe dashboard will show revenue, users, conversion, and churn. It will not include filtering, export, or alerts.\u201d The explicit exclusions matter as much as the inclusions.<\/p>\n\n
Get sign-off on boundaries. Make sure everyone with influence agrees on the scope before work begins. When additions arise, you can point back to the agreement.<\/p>\n\n
Size the work with buffers. Things take longer than estimated. If you estimate two weeks and commit to two weeks, any addition blows the timeline. Build in slack so small adjustments don\u2019t become crises. Good estimation<\/a> is about reducing surprises, not hitting perfect numbers.<\/p>\n\n
Separate must-have from nice-to-have. Prioritise hard upfront. When pressure mounts, you know what can be cut.<\/p>\n\n
Having the conversation<\/h2>\n\n
Once creep starts, you need to address it directly. Hoping it stops on its own doesn\u2019t work.<\/p>\n\n
Name what\u2019s happening. \u201cI\u2019ve noticed we\u2019ve added six features since we started. Our two-week timeline is now impossible.\u201d Make the pile-up visible.<\/p>\n\n
Quantify the impact. \u201cEach of these additions adds roughly two days. We\u2019re now looking at five weeks instead of two.\u201d Numbers make the problem concrete.<\/p>\n\n
Present the trade-offs. \u201cWe can add this feature, but it means either pushing the deadline or cutting something else. Which would you prefer?\u201d Force a decision rather than absorbing the cost silently.<\/p>\n\n
If the team committed to a deadline, additions should require clear trade-offs. Don\u2019t let creep quietly extend timelines. Make it a choice. And keep your manager informed<\/a> as scope shifts. They\u2019ll need to manage expectations upward too.<\/p>\n\n
When scope changes, record what changed and why. This creates accountability and helps prevent further creep.<\/p>\n\n
Structural approaches<\/h2>\n\n
Beyond conversations, some structural approaches help.<\/p>\n\n
Timebox hard. \u201cWe have two weeks. What can we build in two weeks?\u201d Start from the constraint and work backward. This frames additions as taking away from something else.<\/p>\n\n
Keep a backlog of good ideas that aren\u2019t in scope for this release. People feel heard without adding to current work. Review the list for the next iteration.<\/p>\n\n
Smaller releases mean less chance for creep. A two-week feature ships before scope can expand much. A six-month project piles up changes for six months.<\/p>\n\n
Some teams require formal change requests for scope additions. The process itself discourages casual additions.<\/p>\n\n
Burn-down charts, task boards, regular demos. When everyone can see how much work remains, it\u2019s harder to pretend additions are free. Hill charts<\/a> are useful here because they show uncertainty, not just completion.<\/p>\n\n
When to accept changes<\/h2>\n\n
Not all scope additions are creep. Sometimes requirements genuinely change. Sometimes you learn something that makes the original plan wrong.<\/p>\n\n
Changes driven by new information are legitimate: user research reveals the original approach won\u2019t work, a dependency changes, business conditions shift, or you discover a technical constraint that forces redesign.<\/p>\n\n
The difference is whether the change is driven by new information or by wishful thinking. \u201cWe learned customers don\u2019t use this feature that way\u201d is new information. \u201cThe VP would also like it to do this\u201d is wishful thinking.<\/p>\n\n
Accept legitimate changes. Push back on scope creep. The skill is knowing which is which.<\/p>\n\n
The uncomfortable truth<\/h2>\n\n
You cannot eliminate scope creep entirely. Some additions will get through. Some projects will expand beyond their original bounds. This is normal.<\/p>\n\n
What you can do is make creep visible, make trade-offs explicit, and protect the team\u2019s ability to deliver. Every time you let an addition slip in without discussion, you teach stakeholders that additions are free. Every time you name the creep and force a decision, you build a culture that respects constraints.<\/p>\n","pubDate":"Tue, 17 Feb 2026 08:00:00 +0000","link":"https:\/\/joshhornby.com\/scope-creep-and-how-to-fight-it","guid":"https:\/\/joshhornby.com\/scope-creep-and-how-to-fight-it"},{"title":"Sentry AI Tracing with Laravel's AI SDK","description":"
In my previous post<\/a>, I showed how to manually wrap OpenAI calls with Sentry spans to get LLM monitoring in PHP. It worked, but every AI call needed to pass through a tracing method. You had to remember to use it.<\/p>\n\n
Laravel now ships an official AI SDK<\/a> (laravel\/ai<\/code>) that changes this. The SDK fires events for every agent interaction, which means tracing becomes a listener. Write it once, and every AI call in your app gets traced automatically.<\/p>\n\n
What changed<\/h2>\n\n
The old approach required wrapping each call:<\/p>\n\n
$response<\/span> =<\/span> $this<\/span>-><\/span>traceOpenAIRequest<\/span>(<\/span>\n    operation<\/span>:<\/span> 'chat_completions'<\/span>,<\/span>\n    model<\/span>:<\/span> $model<\/span>,<\/span>\n    messages<\/span>:<\/span> $messages<\/span>,<\/span>\n    apiCall<\/span>:<\/span> fn<\/span> ()<\/span> =><\/span> $this<\/span>-><\/span>client<\/span>-><\/span>chat<\/span>()<\/span>-><\/span>create<\/span>(<\/span>$params<\/span>)<\/span>\n);<\/span>\n<\/code><\/pre><\/div><\/div>\n\n
The new SDK has agents as first-class objects. You define an agent class with instructions, tools, and a schema, then call prompt()<\/code>:<\/p>\n\n
$response<\/span> =<\/span> (<\/span>new<\/span> SalesCoach<\/span>)<\/span>-><\/span>prompt<\/span>(<\/span>'Analyse this sales transcript...'<\/span>);<\/span>\n<\/code><\/pre><\/div><\/div>\n\n
The SDK fires events at each stage. Six are useful for tracing:<\/p>\n\n