Asbjørn Brandt

Good intentions, tangled systems

Wed, 10 Dec 2025 00:00:00 +0000

I've been reading Team Topologies and The Unicorn Project. Both explore how interactions between teams can create complexity and friction - even when every local decision is well-intentioned.

In engineering, we all learn not to couple systems at the database level. When it happens, changes require coordination, scheduling, and backwards compatibility. Everything slows down. But we often build organizations that same way.

Want to ship a feature? Wait for:

data changes owned by one team
platform support from another
frontend work from a third
sometimes additional shared components, security reviews, or compliance sign-offs.

Each step introduces prioritization and coordination in teams with different incentives and timelines.

All of this typically emerges for good reasons:

to build things once and reuse them
to concentrate deep expertise

Over time, though, managing these dependencies leads to more process. And seeking predictability leads to planning cycles. And slowly, without deliberate intent, the system becomes tangled.

Team Topologies and The Unicorn Project both remind us: Progress doesn't come from optimizing each subsystem in isolation. It comes from simplifying the flow of value - reducing handoffs and designing teams around that flow.

Voluntary Code Reviews

Fri, 19 Sep 2025 00:00:00 +0000

I'm all for code reviews; but I prefer them to be voluntary.

Reviews can be great for:

Sharing knowledge and context
Improving design through another perspective
Occasionally catching bugs early

But not every change needs one. A dependency bump or a quick readme update? Maybe not. And some feedback is best sought before you even open a merge request: during design discussions, pairing, or quick ad-hoc conversations.

I think this is somewhat linked to Douglas McGregor's Theory X and Theory Y. Theory X assumes people dislike work and must be monitored. Theory Y assumes people enjoy work, seek responsibility, and can be trusted to self-direct. Mandatory reviews feel like a Theory X tool: a guardrail for people you don't trust. Voluntary reviews feel like Theory Y: trusting professionals to know when another set of eyes will help, and when it's safe to move forward.

Theory X cultures can deliver. But so can Theory Y cultures — and they make the work fun and rewarding too.

Estimates and mental debt

Mon, 15 Sep 2025 00:00:00 +0000

I'm reading the excellent Peopleware and one thing that stood out is their survey data on estimates: just the act of estimating a software project drops productivity by ~20-50%! This sounds bonkers - why would simply estimating change productivity? It is easy to write it off as a sloppy experiment (survey, self reported data, correlation ≠ causality).

I also recently viewed Kathy Sierra's keynote on Making Badass Developers. In it she references the well known experiment: one group memorizes a 2-digit number, another a 7-digit number. Afterward, they're offered fruit or cake. The 7-digit group overwhelmingly chooses cake. The experiment has been done in many variations and the thesis is that mental resources are easily depleted so subsequent decision making is poorer for it.

I think this ties in nicely. Having that estimate or deadline hanging over your head zaps some of your cognitive resources. It shouldn't mean that much but remember that just memorizing 7 numbers had an effect on decisions. Add to that all the small tasks that tend to follow once you estimate: delivering status updates, answering stakeholder questions, keeping Jira and OKR tickets up to date… it all adds up, eating into both uninterrupted time and mental energy.

I also read a thought provoking blogpost Seeing like a software company by Sean Godecke recently (a riff on "Seeing like a state"). In an aside he mentions how managers think estimates are given based on desired quality, but in practice the quality ends up driven by the estimate. If time pressure arises quality is cut to hit estimates and over time this lower quality means more mental resource drain on developers that operate this code. Tech debt becomes mental debt.

The evidence here isn't perfect, but I think the connections make sense, and it fits my experience. If we take it seriously the implications are big. As managers we must:

Move away from estimates where possible. If teams are working on "the most important thing" does estimates give us much? Especially given how fallible they are.
We must protect our teams mental resources by removing interruptions and letting them build in quality.
We must prioritize learning so engineers can move more skills into the effortless zone where they cost less cognitive energy.

I know this is all a tradeoff - sacrificing legibility at the altar of productivity. But I think it is one we should make where we can, not just for productivity but also for the joy that comes from delivering quality products.

Further reading: Fruit salad, chocolate cake, cognitive control, and poverty - a deeper dive into the cognitive load research and its broader implications.

Let's Stop Hoarding Code Like Dragons

Tue, 01 Jul 2025 00:00:00 +0000

For years, companies have treated their code like treasure: jealously guarded, locked away, rarely seen by outsiders. It’s understandable: skilled engineers spent years crafting it, so it must be valuable.

And it is, but mostly to you. In your systems, your workflows, with all the context and infrastructure that shaped it, with engineers that understand it, can maintain it and expand it. Outside that bubble, it’s far less useful. Code doesn’t travel well.

So why the obsession with locking it down?

One of the louder objections to using LLMs for software development is the fear of code leakage. But let’s be honest: if a model picked up fragments of your code, would that really arm a competitor with anything meaningful? Compared to the risk of a disgruntled engineer emailing a zip file to themselves on their last day, it’s barely a blip.

And more importantly: what are we missing out on while we worry?

The bottleneck in most teams isn’t clever algorithms or top-secret business logic. It’s velocity. We’re drowning in valuable work we never get to. Integrating new data sources, building features users have been begging for, fixing bugs that we keep bumping down the backlog.

If tools like LLMs and agentic coding can help us move faster - like markedly faster - that’s a huge win. If we can go from two weeks to two days for a new major feature that’s not just speed. That’s competitive advantage.

And this brings us to another opportunity if we do away with the code-as-a-secret stance: open sourcing more of our code.

Not because we expect strangers to flood in and fix our bugs or add features for us. But because working in public attracts the kind of engineers we want: those who enjoy learning in the open, who share their thinking, who give and receive feedback, and who care about clarity and improvement more than cleverness. It invites curiosity, collaboration and transparency.

In a world where anyone can write code, it’s how we choose what to build, and how we work together, that really sets us apart.

Speaking here as an individual, not on behalf of my employer. Just sharing some thoughts I’ve been reflecting on as the tech landscape shifts.

Something feels different now

Sun, 15 Jun 2025 00:00:00 +0000

I’ve used ChatGPT and Claude since they came out, including a fair bit for coding. Helpful, sometimes surprisingly so. Useful, but not transformative.

This week I tried the new agentic tools: Claude Code (and to a lesser extent OpenAI’s Codex). It feels like a completely new gear.

Not a new UI. Not a marginal gain. More like instructing clones of yourself that can draft, refine, explain its reasoning, and work with you iteratively. It’s still just a tool, but suddenly a much more capable one.

I haven’t been one to jump on the LinkedIn CEO/Founder/AI Salesman hype, but some thoughts are forming:

This increases output significantly. 2–10× for many tasks feels within reach. In 2 hours yesterday, I did what would have taken me 1–2 days last week.
Engineers are still responsible for every line. Maybe even more so, because it’s so tempting to just accept a good-looking draft.
It doesn’t replace skill. The quality of the output matched the quality of my instructions, corrections, and review.
It shifts the effort: less time typing, more time designing, testing, documenting.

One interesting side effect is that it probably makes small internal tools worth building like:

A tool to verify that critical data landed in the data platform for specific time slices
A quick dashboard to debug a rare heisenbug
A one-off HTTP proxy to rewrite legacy API responses
A CLI to inspect Redis cache usage across workloads
A GitHub Action tailored to one quirky project

You haven’t missed the train if you're not using these yet. Whether you adopt it now or in a month won’t decide who wins. But it does feel inevitable.

I’ll be arguing for using Claude Code at work. I think our backlog throughput will prove the business case on its own.

I don't care for hype, but it might be a real shift in how we work as engineers.

A thought on pay

Fri, 13 Jun 2025 00:00:00 +0000

I had a thought today: I hear much discussion on how much engineers get paid. Sometimes with a tone of “those greedy devs.”

But what does a low salary actually say about the company?

Maybe it is a signal that they don’t really know how to leverage engineers well which might be a frustrating experience too:

Your time goes to endless backlog grooming, status meetings, or process theater.
You won’t get the tools you need. A $20 license becomes a fight - never mind proper observability or a conference ticket.
They can’t figure out what delivers value, so you spend three years polishing an intranet portal while the world moves on.

And that mentor you hoped to learn from? If the company underpays, they’re probably already working at the competitor.

Sure, money isn’t everything. But following it can be a decent proxy for places where your work matters, where people are sharp, and where engineering is seen as leverage, not overhead.

Sometimes, low pay isn’t just about the salary. It’s a symptom.

(Of course, this is just a thought, and a generalization. I don’t know if the same pattern applies outside of tech, but I wouldn’t be surprised.)

LinkedIn vs internal comms

Wed, 15 Jan 2025 00:00:00 +0000

Had an interesting realization today: I feel safer sharing some thoughts about work on LinkedIn than in our internal company Teams channels.

For example, I might openly share thoughts on Jira or Scrum here but hesitate to do so internally. Anything contrary to majority opinion or company standards might be unwelcome - or that could just be in my head. It’s curious how my LinkedIn posts often spark real-life conversations at work (colleagues mention them in the coffee queue!).

It really shouldn’t be that way. Organizations benefit from challenging the status quo and hearing diverse opinions from people on the floor. Perhaps it’s about finding the right format for company commentary as an IC - almost like an editorial. Or maybe personal platforms like a blog or LinkedIn are simply better suited for that if you're not in management.

Does anyone else experience this? How can we create spaces - internal or external - that encourage open, constructive dialogue about how we work?

Bottom-up or top-down?

Thu, 09 Jan 2025 00:00:00 +0000

How much authority does your software team have? Are you required to use Jira and estimate stories, or does your team determine the best workflow? Can you choose your own IDE, language, and toolchain, or is that decided by the company? And when it comes to professional development, are you learning what excites you, or is it driven by your manager’s priorities?

In small businesses and startups, team and individual autonomy are often a given - there are fewer rules. But as companies grow, they often strive for standards and alignment, thinking it will bring efficiency.

Instead, we could encourage and celebrate individual initiative. We could inspire people to create their own tools, to develop templates, to teach others what they know. If a developer does a small lunch and learn on containers, hosts a code kata or demonstrates TDD through pairing and others see it celebrated imagine what this does to the company culture. I believe this can lead to teams that are not only efficient but also inspired and motivated to excel.

Contrast this with a scenario where a single team, an ivory tower architect, or a scrum master dictates web frameworks, branching strategies, or (often unnecessary) processes and artifacts for all teams. Does an architect know better than the people on the ground which tools suit their workflows? And what does this do to the culture? Will people feel empowered to share their ideas and experiment? Will anyone hack away at night on a cool new way to load data, improve service discovery, or go talk to users to discover what would really move the needle? Or do we risk that developers will simply do what they’re told?

What are your thoughts? How does your company navigate these decisions, and what has worked best for you? How big can a company grow while still emphasizing team autonomy over top-down decisions? Is this all too black and white?

I'm curious and don't have the answers but in 2025 I'll aim to be a better role model for individual initiative and act as a counterbalance to the ever-present push for more top-down decisions.

Why I Don’t Want to Manage (At Least for Now)

Sat, 12 Oct 2024 00:00:00 +0000

Have you ever turned down a management role to stay focused on tech? I’ve been approached a few times during my career about moving into management, and while I always reflect on it, I ultimately decide it’s not for me.

Here’s why:

I run towards tech problems and away from people problems 😅 That’s a big sign by itself. The idea of spending my time in one-on-ones, salary reviews, and development conversations doesn’t fill me with excitement - quite the opposite!
Looking at the calendars of people in leadership... I’m very happy with the space I have in mine 😄 One fixed meeting on Mondays from 9:30-9:45. Not many meetings added on top of that. This is more time for deep work.
Traditional career ladders (junior → senior → manager) are so 90's. We’re at a point where some companies are starting to recognize that experienced tech people can sometimes have as much impact as managers.
I still have sooooooo much to learn, try, build, and share - and I’m really excited to do just that.

There are, of course, benefits to management - like focusing on higher-level technical problems without needing to dive into every detail. I also find that hiring is interesting and probably one of the highest leverage activities in small tech teams. Good managers are fantastic for a team but promoting top software engineers to managers can easily hurt both engineering and leadership functions by losing great engineers and gaining ineffective leaders. It is just not for me right now.

What about you? Have you ever turned down management to stay on the IC path? How did it turn out for you? I’d love to hear your thoughts on this.

(A great cartoon by Kendra Allenby has the line: "At this point in your career, your only possible promotion is to management, where you will stop doing the work you love and use a skill set you don’t have and we don’t teach." which puts a facet of this beautifully into a single sentence)

On Jira

Tue, 10 Sep 2024 00:00:00 +0000

Recent discussions at work made me reflect over Jira and more generally team processes. Potentially hot take 🌶️ I've used Jira for over eight years now. I have yet to see significant benefit using it for anything other than a backlog of things we really intend to do, can't do right now, and that are more than just ideas (ideas are cheap — we'll have better ones next month). That list is fairly short.

I'm sure it has great use cases like coordinating with external stakeholders or managing work in teams spread across different offices or even timezones.

But what really unlocked a new mental model for me and clarified my discomfort with Jira and similar tools was Tim Ottinger's (well, I heard it from him) framing of "Solo Ticket Processing." Jira is often used to split work into small tasks, which can then be spread across a team. The idea is to parallelize and thus improve velocity, but software engineers don't really work like that. Un-teaming a group of developers and assigning them solo tickets for parallel execution isn’t a silver bullet for unlocking extra potential—more often, it has the opposite effect.

I could keep going on this, but I think you're better off checking out some of Tim's blog posts like this one: Individual Work Assignments: Neither Agile Nor Team