Culture Debt
Every organization carries culture debt. The healthy ones pay attention to it. The unhealthy ones discover it only when the cost becomes too great to ignore.
The online whiteboard of Kristofer Palmvik
Every organization carries culture debt. The healthy ones pay attention to it. The unhealthy ones discover it only when the cost becomes too great to ignore.
A collection of small, simple, single-task tools, mostly designed to help neurodivergent people with tasks they find overwhelming or difficult.
Boring AI features are reliable AI features that feel invisible to users - they just work. Read only what you need. Constrain with clear rules. Act with structured outputs and safe tools. Explain what happened. Start with the smallest useful feature. Use the patterns that fit your use case. Monitor everything. Improve based on real user behavior, not theoretical performance metrics. The goal isn’t to build impressive AI demos. It’s to ship features that users depend on every day.
Sarcasm can be hard to convey in writing but I hope you get the point of this article. Personally, I will not try to fix Apple’s bad design decisions in the websites I build. I will not follow any of the “advice” I just gave. Apple themselves are not following it either. I actually think the talented folks at Apple did their job as well as they could given the constraints of Liquid Glass™. So much thought went into it. It’s just a terrible idea for a design language in the first place.
With stacking we’re introducing a lot of processes and tools. These obfuscate problems that we can solve at the level of people and how they work together. These can be harder to address, but the value in doing so is incomparably larger. Trunk based development doesn’t have all the answers, but the questions it gets us to ask are the right ones. And in my book, when it comes to software engineering, a good question trumps a complex answer every day.
When team members are safe, can learn and adapt, share a common purpose, understand and support each other, and stay accountable to one another, you’ve got a healthy team. But a team only becomes high-performing as they create and maintain virtuous cycles that continuously improve health, allowing everyone to grow.
If I had to prioritise which ones to start with, I’d go with the start: Start at agreement and Give options. Both are really easy to do and are ‘quick wins’ so to speak. I’d then recommend to start experimenting with some of the techniques I shared in the cognitive dissonance section like reframing things as questions.
Top of the list, invariably, is communication skills. The best developers work to understand and be understood clearly and effectively. So much of what goes wrong in software development can be traced back to poor (or no) communication. Written, verbal, aural. They have good comprehension, they can articulate complex ideas simply to different audiences, and – most importantly – they actually communicate.
Don’t wait until you have another offer to communicate what’s not working. Don’t wait until your last week to document what you know. Don’t wait until you’re burned out to manage your energy strategically.
Every name you choose shapes how easy or hard the future will be for yourself and your team. When tempted to accept vague or confusing names, remember: that choice echoes through dozens of files and months of development. Name it like your future self’s sanity depends on it. Because it does.
In my experience, when people are given accountability but not the reins to drive change, they disengage. Why pour your soul into something when your best ideas get vetoed by someone who isn’t even in the room? I’ve felt this sting myself early in my career. After six months of pushing boulders uphill, I stopped feeling responsible. The failures weren’t mine. They were the system’s.
A computer can never be held accountable. That’s your job as the human in the loop. Almost anyone can prompt an LLM to generate a thousand-line patch and submit it for code review. That’s no longer valuable. What’s valuable is contributing code that is proven to work.
The fundamental thread through all these roles is strategy. I believe strategic thinking will be the new constraint with AI. Strategy is not goals or vision statements. It is a clear path to achieve those goals. And it is always best done in a group with diverse perspectives.
I have a lot to say about this, but we are packing it up into something a bit more digestible, so I’ll just leave you with a few core beliefs that I think will be increasingly important in the age of AI.
Lambros distinguishes between two kinds of “brilliant jerks.” The first type is difficult but ultimately valuable: highly capable people who may be abrasive or “spiky” yet can be managed productively with the right structure. Then there is the second type, whose brilliance comes at the expense of others and who damages teams and relationships wherever they go.
The most important teams in a B2B software company are engineering and sales. Full stop, no exceptions, no further questions. You’re either building the product or selling the product, and everything else is secondary at most.