And yet, nothing much has changed. The same manual processes. The same forgotten follow-ups. The same Friday afternoon spent copying data between systems.

The problem is not a lack of tools. It is not knowing where to start.

After five years of building automation workflows, roughly over 200 for my businesses and clients, with my own n8n instance alone running around 30,000 executions weekly, I have noticed something interesting. The businesses that actually benefit from automation do not start with a huge transformation project. They start with one workflow. Then another. And somewhere along the way, something shifts.

They start asking, “why is this not automated yet?” That mindset shift is worth more than any individual workflow. And it usually starts with something small.

Like any transformation, the big bang rarely works. Small incremental improvements will bring results and feedback early and help to keep the motivation for further investments high.

Why these five?

The processes I am about to describe share a few things:

• They happen frequently, daily or weekly, not once a quarter

• They follow clear rules, no judgment calls required

• The benefit is obvious, you will feel the difference within a week

• They are low risk, if something breaks, nothing catastrophic happens

This last point matters more than people think. Starting with something critical and complex is a recipe for frustration. Starting with something simple and repetitive builds confidence. It gives you time to learn the tooling, make mistakes, and improve safely.

With that in mind, here are the five I recommend starting with.

1. Lead response

Typical setup time: a few hours

I have lost count of how many times I have heard this story: a potential client fills out a contact form. The submission lands in a shared inbox. Maybe someone sees it that day, maybe not. By the time anyone responds, the person has already talked to two competitors.

The fix is almost embarrassingly simple. Form submission comes in, contact gets created in the CRM, a confirmation email goes out within a minute, and the right person gets a Slack message or email with all the details.

That is it. A few hours to build. No more leads slipping through because someone was in a meeting.

One client saw their lead-to-call rate jump from 40% to 65% just by responding within minutes instead of hours. Speed signals professionalism, and it compounds over time.

2. Invoicing

Typical setup time: half a day

This one I see constantly, especially in smaller companies. A deal closes, everyone celebrates, and then someone has to remember to actually send the invoice. They open the invoicing tool, manually copy the client data from the CRM, hopefully get the address right, and send it off. A week later, nobody remembers whether the payment reminder went out or not.

The automation connects your CRM to your invoicing tool, whether that is Lexoffice, sevDesk, or whatever you use. Deal marked as won? Invoice generated and sent. Payment not received after seven days? Reminder. After fourteen? Another one. You get an alert when something is overdue.

Half a day to set up. Invoices go out the same day the deal closes. One client reduced their average payment time from 18 days to 9 simply by sending invoices same-day and automating the reminders.

3. Client onboarding

Typical setup time: 1-2 days

New client signed. Now what?

In most companies I have worked with, this is where things get chaotic. Did someone send the welcome email? Who is creating the project folder? Does the client have access to the tools they need? Is the kickoff call scheduled? Everyone assumes someone else is handling it.

One agency I worked with was spending over 10 hours per new client just on this coordination. Collecting information via email, entering it into different systems, creating folders, setting up access, scheduling calls. After we built an onboarding workflow, that dropped to about 30 minutes. One trigger, new client in the system, and everything else happens automatically.

The client gets a professional, consistent experience. The team focuses on the actual work instead of the logistics.

4. Meeting follow-ups

Typical setup time: half a day

This is one of those things that sounds minor but adds up. Productive meeting. Plenty of ideas. Everyone agrees on next steps. Then people go back to their inboxes and nothing happens. Two weeks later someone asks “did we not decide to do something about X?”

The workflow does not have to be fancy. The meeting ends, notes get pulled from Notion or Google Docs or wherever you keep them or are pushed by AI tools like Krisp, action items become tasks assigned to the right people, and everyone gets a summary email.

In most companies, people spend a significant amount of their time in meetings. Without tangible results and forgotten follow-ups, that is just time wasted. Automations can help to keep things moving after the meeting.

5. Weekly reporting

Typical setup time: 1 day

Monday morning. Leadership wants to know how last week went. Someone, usually the same someone every week, spends two hours logging into five different tools, exporting CSVs, copying numbers into a slide deck, and hoping they did not miss anything.

The automation pulls data from your sources, formats it consistently, and delivers a summary by email or Slack every Monday at 7am. The report is ready before anyone has finished their coffee.

The data is more reliable because a workflow does not get tired or skip a source because it is Friday afternoon.

One founder told me the real value was not the two hours saved. It was that she actually looked at the numbers every week now, instead of skipping it when things got busy.

You do not need AI for this

Before we go further, let me say something that might be unpopular, especially at the beginning of 2026 where everybody is building agents and chatbots just because it is possible: most automations that will save you real time and money do not need artificial intelligence.

AI is useful when you require advanced reasoning. Understanding messy text, making judgments, handling ambiguity. But for the majority of business processes, you need rules, not AI. If this, then that. When X happens, do Y. It sounds boring, but boring means stable, fast, and reliable.

Adding AI to a straightforward workflow makes it slower, more fragile, and pricier. A simple rule-based automation runs in milliseconds, costs almost nothing, and will not hallucinate your client’s invoice address.

Save AI for where it actually helps. Start with the boring stuff.

Common mistakes

When people try to automate on their own, I see two patterns that cause most of the pain.

Only thinking about the happy path. The workflow runs perfectly in testing. Then an API times out. Or a field is empty that is usually filled. Or someone enters data in an unexpected format. The workflow fails silently. Nobody notices for weeks. Meanwhile, leads are not being captured or invoices are not going out.

Always add error handling. Send yourself a notification when something fails. Assume things will break because they will. N8n provides Error Workflows and Error Triggers to achieve exactly this. Furthermore, if you are self-hosting n8n, it is a good practice to add some monitoring or uptime checks to catch if the instance is down for whatever reason.

One giant workflow that does everything. I have seen workflows with 50+ nodes trying to handle an entire business process from start to finish. When something breaks, nobody knows where. When requirements change, the whole thing needs surgery. And nobody wants to touch it because they are afraid of breaking something else.

Better to build many small workflows that each do one thing well. Easier to understand, easier to fix, easier to hand off to someone else. Bonus benefit: Small, independent workflows are not just more maintainable. They can also be connected to an agent node later, if you ever decide to build an AI agent for your business.

These are the same mistakes I made in software engineering 20 years ago. Over time, we learned to break down big problems into small composable solutions. We learned how to think about edge cases, how to test them and how to build for them. The principles have not changed, just the tools have.

The shift

Here is what I have seen happen, again and again. A business starts with one small automation. Maybe a calendar booking that automatically creates a contact in the CRM. Nothing fancy. Took an afternoon to build.

But once they see it working, silently, reliably, without anyone lifting a finger, something clicks. They start noticing other processes that could work the same way. They start asking questions. They start building.

One client began with that simple calendar automation. Within months, we had built entire accounting and outreach workflows together. Now, for every process that takes their time, they ask: can this be automated? How?

The big win does not come from any individual workflow. It comes from a shift in thinking. And it comes from having the tools ready to actually automate things.

Automate what annoys you.

If you are not sure where to start, or you want someone to look at your processes and identify the opportunities with real, measurable ROI, book a free 30-minute automation audit. We will find the quick wins and map out what is possible.

This is wonderful. But, it also leads to plenty of questions and thoughts of how the world will change, and I believe that this depends entirely on us. Now, I am not the first person to write about this, I also will not be the last and this article can and will not be complete by any means. This article is more a random collection of thoughts than anything else. Writing it helps me to think, but I also hope it sparks more thinking and conversations around those thoughts. I hope you enjoy reading it.

We should be able to work less

I am not sure when we saw such a dramatic productivity gain in the past. Maybe during the industrialization. Perhaps even during the raise of the internet.

It will depend on your context, your work, and how you use modern tools, but let’s say AI only gives you a 25% productivity boost. – That would mean you could work one day less a week and still produce as much as before. And for me, I find my productivity gains to be more in the 5x - 20x range (sometimes possibly more).

Excluding the overwhelming science behind the benefits of a four-day-workweek for knowledge workers, this alone means that we should be able to work less without an impact on the productivity.

I would bet that we could now work 3-day work weeks and be more productive than 5 years ago.

Of course, history shows that productivity gains rarely benefitted workers as much as their employers and without an intervention, you will likely find yourself working 5 days a week for a slightly increased salary. – Therefore, I believe we should think about how much do we actually want to work and how our productivity is changing as our tools become better.

We should be able to earn more

Directly connected to my first thought is the question, what a fair salary, hourly rate, or compensation is.

I was always at odds with hourly-rate-based compensation (and salary mostly is a different form of it), as time-based compensation always means that someone doing the job faster and (maybe) even better, earns less money. This payment scheme incentivizes people to go slow, create extra work and do unnecessary things. It might be that is why we have so many meetings and so few automated tests and automated processes.

In our industry, we find people who will do things at an incredibly cheap hourly rate. Some of them are excellent, but many are “cheap” because of lacking experience. People who look cheap on paper sometimes are the most expensive ones—they create complicated, fragile code without clear architecture and quality assurance measures. Hiring the more expensive freelancer often is the more economical option, but I find it difficult to prove upfront how much faster or better I will be in any given context.

With the rise of decent AI tools, people with good software craft principles will find that their ability to create good and working software will be leveraged by a factor of 5x to 20x (again depending on the context, and it might be even more).

I have not tried to ask for an hourly rate of €800 yet, but my feeling is, that it wouldn’t sell as well. Maybe it is worth a try. Based on my experience, I would estimate that an €800 hourly rate today will result in a far cheaper price for a project compared to a €100 hourly rate 5 years ago. It would be a 8x gain for the worker and potentially another 8x for the company hiring them.

Again, you likely won’t see such an increase on your paycheck, but I believe these are the conversations we need to have now, as society, if we really want to benefit from AI.

I will stop doing hourly rate projects

For my existing clients, I won’t change a thing, as I try to keep things stable and “unsurprising”. But, I decided that for new clients, I will not make any hourly-rate-based offers anymore for the aforementioned reasons.

Instead, I want to have conversations about the desired outcomes and the value attributed to them. And then, if I believe I can make an offer that is well below that value, I will just do it. In the end, I do not want people to pay me for hours, but for results, and I think this is the fairest model I can imagine. I am aware that this means taking on the risk that things take longer than I have expected, but I am happy to carry this risk. I believe that there is no value in having huge unforeseeable projects with unclear duration and budget. If something is as big as that, the most value we can create is by slicing it down and identifying the first, most valuable increment and delivering just that. And this has always been a huge part of my work, anyway.

How will work change?

For me, personally

As a coach and consultant, I still work with teams and teach them how to develop software on-the-job. As a freelancer and as a solopreneur, I often find myself writing code alone. The only difference now is that my “writing code alone” feels more like a pair-programming session with Claude Code. From brainstorming the design over creating an implementation-plan to TDD-ing it into existence, Claude Code has become a reliable buddy.

This is great for me because I enjoy pair programming, but it always meant the need for synchronous time with others as well as the need to have others on my team (not the case as a solopreneur). Furthermore, not all developers enjoy pair-programming, and it also means we all need to have time at the same time (sometimes challenging when we are in very different timezones). Now I can get some of the benefits I got from pair-programming from the work with Claude and feel the need for real pair- or team-programming less often.

There is something bittersweet about this. I genuinely enjoy working with other humans—the unexpected ideas, the debates, the shared “aha” moments. AI doesn’t replace that. But it does scratch an itch when human pairing isn’t available, and I’d be lying if I said I don’t sometimes prefer the convenience.

For teams

If you are working in a team, I still believe real pair- or team-programming sessions are absolutely crucial. Mainly for knowledge sharing, teaching/learning, alignment, and team dynamics. I still find it much more valuable to code together the beginnings of a new feature or project than spending hours on upfront-planning. The code we write is part of the feedback loop to our understanding of the project or feature.

Currently, a working mode that I truly enjoy is to gather for a couple of team programming sessions at the start of a new feature, project, or product. Together, we set the foundations, guidelines and create a shared understanding of the goal and how we want to achieve it. We also identify areas where we can work alone without conflict. And then we spread out and code “alone”/with AI. We would then share updates / new interfaces / achievements asynchronously and come back together when we sense that something is not obvious. For me, this feels like a good balance between software teaming all-the-time and going full-solo-mode.

Team sizes will shrink

As we change how we work with AI and can create more things in shorter time and therefore also with fewer people, I would expect teams to become a lot smaller. Larger parts of our product can be maintained and evolved by fewer people. Today, a team of 3 can likely achieve what a team of 7-10 could achieve 5 years ago, just with way less communication lines.

Therefore, it became even more important, that we build teams around value streams and enable them to work independently. The worst thing that can happen is to have a team of 10 engineers working on entirely different things but having to communicate all the time for some artificial reason (dailies, status updates, someone’s need to feel important)

In smaller teams, having great team dynamics and knowing each other well usually becomes easier, and so does coordination and communication. I expect many challenges bigger teams face today to go away naturally, as team size shrinks.

This means, we will need and see less coaching on the team level, but potentially more on the organizational level, as organizations have to change, too.

Hierarchical organizations will fall behind (even more)

Traditional org design with hierarchies, management layers, organizing by function, and so on was always at odds with agile software development and business agility.

Many companies failed to become agile because they failed to let go of their strictly hierarchical structure.

To me, the goal of agile was to develop the right thing faster, by learning faster and reacting to that learning faster. In a nutshell, it was about faster feedback loops and continuous improvement. As (software) development accelerates, we require much faster feedback loops. We need to make better decisions as we work.

Top-down decision-making is very ill-suited for this. Companies where information needs to travel up the chain-of-command and decisions have to travel down the chain-of-command will not be able to keep up with the speed of innovation by companies working more in a self-organized, network, “flat” way.

We therefore shall see fewer managers in the future and inspirational leadership based on communicating vision, mission, and values will become even more important. Workers must be able to make good decisions quickly and get feedback from others or support in decision-making fast and on-demand.

Organizational structures must change faster as products will evolve faster, and new value streams might form more often, due to productivity increases.

Just having your quarterly OKR planning or monthly all-hands to communicate direction, might not cut it anymore.

The demand for good software engineers will NOT decrease

There is a lot of fear that we will lose our jobs or might be out of work. Of course, I don’t know the future, but what we see today is, that AI tools are great, but they are only tools. Different people have vastly different experience with AI. From my observation, great software craftspeople get consistently good results while using those tools. Others get mediocre results at best and have an overall frustrating experience.

It is less about the tools, but more about how we use them. Are we taking the time to learn how to use them? Do we have practices in place that allow us to use them well? Do we know what good looks like? Do we have high standards and principles, that we won’t compromise on?

Good software craftspeople will answer those questions with “Yes” and it will show in their output.

AI accelerates your ability to produce code. But at least today, end of 2025, it will not produce incredibly high-quality, maintainable code just because you ask it to do so. The gap between good software craftspeople and “just coders” will therefore become bigger as the first group is producing more high-quality code while the latter group is producing more technical debt, untested, and hard-to-maintain legacy code.

In conclusion, good engineers will be more in demand. To create high-quality products faster and to clean up the mess produced by those who did not know better.

Furthermore, I have yet to meet a team that doesn’t have a backlog nor a plan of what could be worked on next. There is plenty of work and an infinite number of ideas we could work on.

Economics has changed. We will work on different things.

I now find myself frequently working on ideas that I would not have touched a couple of years ago because the investment seemed too high for the anticipated return. Now, the economics has changed. If I can build something in hours that would have costed me days or weeks before, it is cheaper to try out things. And every so often we are surprised that those things are actually way more valuable than we have thought before we started.

Apart from the fact that AI itself is an interesting field where we see thousands of new startups and product ideas every day, AI augmented coding made it feasible to build products for niches that were economically uninteresting before.

If you have that product idea that you were afraid to build because it seemed too much work, just to try out if it will work, maybe now is the time to give it a shot.

Conclusion

I started this article by saying it’s a random collection of thoughts. And it is. But writing it down helped me see what connects them: AI is changing the economics of our work in ways we haven’t fully grasped yet. And if we don’t think about it intentionally, the benefits will flow to the usual places – not to us, our teams, or our lives.

We could work less. We could earn more. We could build smaller, more effective teams. We could finally move past organizational structures that never made sense for knowledge work in the first place. We could try out ideas that seemed too expensive to explore before.

But none of this will happen automatically. It requires us to have conversations – with our clients, our employers, our teams, and ourselves – about what we actually want from our work and how we value it.

I don’t have all the answers. I’m figuring this out as I go, just like everyone else. But I believe the worst thing we can do is to keep working the way we always have, just faster. That would be a waste of an incredible opportunity.

So, what do you think? How is AI changing your work? And more importantly – what do you want to do with that change?

I’d love to hear your thoughts.

— Tobi

It looks simple by design: fast to load, easy to navigate, and reliable even when other parts of the system are busy. Below is how it works and why we built it this way.

What the map does

The map shows three categories:

• Dive centers

• Coliving spaces

• Coworking spaces

Users can filter with a free-text search – by name, label, country, or city – and toggle categories. A tap or click on a pin opens a small popover with the essentials: partner name, website, and the benefits for our members.

On the public view, we keep it minimal for speed. The membership area shows more detail where it’s useful.

We already have 200+ partners on the map, and it stays snappy even on slow connections.

Why a fully static app

I didn’t want a heavy backend or a “live” API for something that mostly displays public data. So the map is a fully client-side Nuxt.js app that reads from a few static JSON files.

• Framework: Nuxt.js (because we already use it elsewhere, and it keeps the frontend simple)

• Map library: Leaflet (open source, lightweight, battle-tested)

• Tiles: OpenStreetMap and other providers supported by Leaflet – we’re not locked into one ecosystem and can adjust the look easily

The result: no server round-trips to fetch data, no database reads at page load – the browser pulls small JSON files and renders the map immediately.

The read model – generated, not queried

All partner entries live primarily in NocoDB. From there, n8n compiles a public read model every hour:

1. Pull current partners from NocoDB (dive centers, colivings, coworkings)

2. Normalize fields and strip anything not meant for the public

3. Write one JSON file for all places, one for statistics, and one for logos which we automatically show on the website

Those JSON files contain only public data and no secrets, which is why the static approach works well here. If NocoDB has downtime, the map still works – it reads the last generated files.

• Hosting (files + app): Hetzner Web Hosting

• Delivery: CloudFront CDN in front of it

• Cache: After a rebuild, the automation invalidates the CDN paths, so new versions roll out quickly

• Deployment: The app is deployed with simple GitHub actions that take less than a minute to run.

We can also trigger the rebuild manually with one click if we want an immediate update.

• Freedom in tiles: I can use OpenStreetMap or other free/paid providers and switch styles without changing the app structure.

• Small surface area: For what we need – markers, popovers, categories, search – Leaflet stays out of the way and keeps bundle size low.

The combination of Nuxt.js + Leaflet + static JSON is simple, predictable, and easy to maintain.

Membership area specifics

Some partners use online booking systems with discount fields. We do notexpose discount codes publicly.

In the membership area, a member can request a code:

• The member clicks “Request discount code”

• n8n checks membership status in NocoDB

• If active, the code is sent via email (Brevo)

This keeps partners comfortable and members happy. It also avoids inventing permissions or token logic inside the map – the map stays a reader of public data, nothing more.

Performance and practical trade-offs

Currently, the JSON files are small – we’re well under any threshold where performance becomes an issue. If we pass 1,000+ partners, I’ll consider:

• basic minification of the JSON

• splitting the data into region-based files

• simple client-side pagination / lazy loading

None of this is urgent today. The static approach already gives us 95% of the win: instant loads, minimal moving parts, and very low hosting costs.

How it stays up to date

• Schedule: The read model rebuilds hourly

• Manual trigger: If needed, I run it on demand

• Webhook option: We could re-generate on each status change in NocoDB, but we don’t need near-real-time updates – hourly is enough for this use case

The important bit: the map isn’t coupled to the database. It’s a published snapshot. That separation makes everything calmer to operate.

Stack at a glance

• Frontend: Nuxt.js

• Maps: Leaflet

• Source of truth: NocoDB

• Automation: n8n

• Email: Brevo

• Static hosting: Hetzner Web Hosting

• CDN: CloudFront

• Deployment model: fully static – app + JSON files

Small design details that helped

• Public vs. member detail: Keeping the public popover lean makes the first impression fast. Deeper details belong where context exists – the membership area.

• Consistent field names: Normalizing fields in the n8n step avoids front-end conditionals. The app can stay dumb – exactly how I like UIs.

Where the map data comes from (briefly)

This map sits on top of the earlier work:

• Dive centers: collected and contacted automatically; once confirmed, they’re added to partners

• Coliving / coworking: discovered via Google Maps API, scored, de-noised, and enriched (email scraping), then queued for outreach

When any of these become partners, they are automatically put into a different NocoDB table for active partners, and the next read-model build puts them on the map.

Closing

This map is intentionally boring in its architecture – and that’s the point. Static files, a CDN, and a small Vue app are more than enough here.

The payoff: it’s fast, robust, and cheap to run. And if another part of the system has a bad day, the map still shows people where to dive, live, and work – which is the job.

All of this could be built in less than a day as we had all the foundations in place (n8n, NocoDB, static web-hosting, Brevo setup, …). And of course, we also have automated tests for the few bits of logic in the map.

If you’re curious about the specifics or want to adopt a similar pattern, happy to chat and support you in getting your idea off the ground. You are welcome to schedule a quick 30-min call to bounce ideas back and forth.

We’re doing this in public, sharing our journey so other founders can see how a lean, automation-first approach can work in practice. Our hope: inspire other early-stage builders to skip the over-engineering and focus on delivering value early.

Why Coliving and Coworking Matter

For our community, the magic is in finding places where you can dive by day and still have a productive, supportive place to work in between dives.

That’s why we’re expanding our partner network beyond dive centers to include coliving and coworking spaces. This way, our members can plan entire trips — from where they’ll sleep and work, to where they’ll dive — in one place.

Step 1: From Dive Center to Coliving Discovery

We already have an automated outreach engine for dive centers (see Article #1 for details). So the question was: How can we apply a similar approach to coliving and coworking spaces?

Our answer:
Whenever we onboard a dive center in a new location, we flag that location for coliving/coworking partner discovery. Every night, an n8n workflow runs:

1. Uses the Google Maps API to find coliving and coworking spaces nearby

2. Adds them to our NocoDB tables

3. Prepares them for quality filtering

Not every Google Maps result is actually relevant. We get hotels, guesthouses, and sometimes random businesses.

So we added an OpenAI-powered rating step that checks each result against criteria like:

• Community vibe

• Workspace quality

• Amenities (e.g., kitchen access, strong Wi-Fi)

• Proximity to dive centers

The AI-generated rating is stored in NocoDB so we can filter out low-quality candidates before outreach.

Google Maps won’t hand you an email address. That’s where the next workflow comes in:

• Visits the location’s website (if listed)

• Looks for “Contact” or “About” pages

• Extracts and stores the best contact email in NocoDB

Only once we have a valid email address and a good rating do we move the space into our outreach queue.

Step 4: Outreach — Automated but Selective

From there, the process is almost identical to our dive center outreach:

1. n8n sends emails via Brevo to roughly 30 spaces per day

2. Webhooks track delivery, opens, and bounces, feeding updates back into NocoDB

3. Follow-up emails go out automatically after 7 days if there’s no reply

Filtering in NocoDB makes it easy for my (non-technical) partner to exclude certain cities or countries if needed.

Step 5: Keeping the Human Connection

Could we automate replies using AI? Absolutely.
Will we? No.

We want to personally connect with every space that replies, understand their vibe, and ensure they’re a good fit for our community. That’s why n8n stops automation the moment a reply is detected.

Step 6: The Kanban Flow

Just like with dive centers, NocoDB’s Kanban view helps us track partner status:

• New lead → In Contact → Confirmed

When a space becomes a partner, n8n moves their data to the partner list and removes them from future outreach.

Setup time: 15–30 minutes per workflow
Ongoing manual effort: Almost none — except for the conversations that matter.

The Tech Stack

Here’s the mix of tools powering all this:

• Automations are handled by n8n, which we host on our Kubernetes cluster at Hetzner.

• Database & UI are powered by NocoDB, also running on K8S (Hetzner).

• Email Delivery is managed through the Brevo SaaS platform.

• Data Enrichment relies on the OpenAI API.

Our Kubernetes cluster — consisting of 6 nodes, S3 object storage, Traefik load balancing, and n8n with multiple workers — costs around €50/month and hosts all of our self-managed services.

Wrapping It Up: A Fully Automated Partner Pipeline

The result is a fully automated pipeline that continuously brings us high-quality partner leads — without drowning us in manual work.

We get to focus our human energy where it matters: building relationships, curating our network, and delivering value to members.

This allowed us to build a partner network of 120+ qualified partners within the last month with just two people doing this on the side.

Why This Is relevant for Tech Leaders

Even if you’re not building a diving community, the takeaway is universal:

• Use automation to handle the repetitive, scalable work

• Keep the human touch for the moments that require trust and nuance

• Empower non-technical team members to own and adapt key workflows

• Don’t over-engineer before you’ve validated the process

What’s Next

With both dive center and coliving/coworking outreach running in parallel, the next step is to bring it all together for members — in an interactive, searchable map. Also, as we have officially launched a week ago (🥳), I can soon also share how we run the membership platform and community.

That will probably become Article #3 (and maybe #4) in this series.

Want to learn more about the details? Just drop me a message. Happy to share more.

— Tobi

What is “Diving Nomads”?

Diving Nomads is a community-driven platform for location-independent professionals who love to dive.

Our vision:

Help remote workers and digital nomads discover incredible dive destinations that are also remote-work friendly and connect them with trusted dive centers and like-minded people.

We're starting small: verified partner dive centers and a membership pass. But the long-term goal is a vibrant global network of divers, coworking spots, coliving places, and underwater adventures.

Why Should You Care (Especially if You Work in Tech)?

This article isn't just about scuba diving; it's about how to build something valuable, fast, and cheap without drowning in code from day one.

We're using a mix of self-hosted and cloud tools like NocoDB, n8n, Vercel, APITemplate.io, and Brevo — many of them free or close to it — and glue them together with a bit of engineering.

As a software engineer, I believe my job is not to write code. It's to solve problems. And sometimes (often), no-code/low-code tools are the best way to do that, especially early on.

Step 1: The Partner Onboarding Engine

Our first challenge was building a pipeline for onboarding dive centers.

We pulled data from various dive center directories (PADI, SSI, SDI, etc.) and built a scraper workflow in n8n that added ~6,500 dive centers to our NocoDB database, complete with email addresses.

Build time: ~2 hours.
Manual time saved: Easily 40–50 hours.

Follow-ups? Handled.
Exclusions by region or country? Easily filtered in NocoDB views.
Human touch? Once a center replies, we switch to manual email to keep things personal. We have created a public Notion page where we share with them how we work.

Step 2: From Conversation to Partner

When a dive center agrees to join, we change their status in NocoDB — and an n8n workflow, built in 10 minutes, does the rest: moves their data to our partner list and stops future outreach.

Kanban-style views make it easy for my (non-technical) partner to manage status updates with zero technical knowledge.

Step 3: Membership Passes for Our Community

We don’t have an official signup landing page yet — still work-in-progress — but we already have the backend flows ready:

• When a user becomes an active member in NocoDB, a webhook fires.

• N8n generates a digital pass with APITemplate.io.

• The pass is emailed to the user and includes a QR code.

Total build time: ~15 minutes
Time spent since then: Zero

The QR code links to a verification page built with Nuxt.js and Claude Code, deployed via Vercel. It took me about 30-40 minutes and costs us… nothing. Might move to K8S later, if needed.

Let’s Talk Infrastructure

We’re not running everything ourselves — and that’s intentional.

Here's what we’re using:

• Automations:

  Tool: n8n

  Hosted on: K8S (Hetzner)

• Database & UI:

  Tool: NocoDB

  Hosted on: K8S (Hetzner)

• Digital Passes:

  Tool: APITemplate.io

  Hosted on: SaaS (Free)

• Email Delivery:

  Tool: Brevo

  Hosted on: SaaS (Free)

• Website:

  Tool: Carrd (soon: self-hosted WordPress)

  Hosted on: SaaS (Existing Subscription)

• QR Verification Page:

  Tool: Nuxt.js + Claude Code

  Hosted on: Vercel (Free)

Side note: My Hetzner cluster (K8S with 6 nodes, load balancer, S3 object storage, etc.) costs ~50€/month and hosts my main tools self-managed. (Because I had n8n and NocoDB running for other use cases anyway, it was the obvious/trivial choice to start with them for Diving Nomads, as the additional cost is zero.)

WHY X?

Why NocoDB? Because it’s simple and beautiful, and my partner can work with it effortlessly. It also integrates super well with n8n and makes it easy to trigger workflows based on status changes or filtered views.

Why n8n? Because I have used it for years, I have it running anyway, and it saves me days or weeks compared to building everything in code. Furthermore, it is fun to use.

Why Vercel? I could have deployed the Nuxt.js applications into the K8S cluster relatively easily. However, Vercel is even easier and I wanted to try it. In the current stage, this doesn’t cost me anything. Once traffic ramps up, it would be easy to either pay for it or migrate the applications into my cluster.

Why Brevo? Brevo in the free tier allows us up to 300 emails per day. We will get a long way with it. Furthermore, it integrates nicely with n8n, and we have it for building our mailing list and newsletter anyway.

Why APITemplate.io? It nicely integrates with n8n, and the pricing is fair. It is easy to use. Up to 50 generations a month are free, and once we are at 50 new members per month, we can easily afford to pay for the next tier (or switch to another solution).

Why Carrd? I wanted to avoid going down the WordPress rabbit hole again. For our waitlist, it was a simple and cheap option. For everything beyond that, the single-page approach is too limited. Therefore, we are going back to WordPress for the main page, as one requirement is that my partner can build pages with it.

Is It a Bit Hacky? Sure. Is It Worth It? Absolutely.

We’re not writing a line of code unless we absolutely have to.
We’re not over-architecting workflows that aren’t yet validated.
We’re not building “for scale” — we’re building for now.

But everything is decoupled enough that when the time comes, we can turn n8n flows into backend code, webhook into lambda, and scale up from there. Seriously, I am very curious to see when we really will see scaling issues with the current infrastructure. This will be a nice problem to have.

What’s Next?

We’re working on onboarding coliving and coworking spaces as the next partner category. The initial approach will be very similar — and yes, it will be mostly automated.

Could we even automate replying to partner emails? Probably.
Will we? No. We want to connect personally with every partner who replies. That’s part of our DNA.

Final Thoughts

The possibilities with today's tools are endless. You don’t need a giant engineering team to build something real.

We’re proof that you can:

• Start lean,

• move fast,

• focus on value,

• automate early,

• and still keep the human connection.

If you’re building something and wondering how to move faster, cheaper, and with more joy, let’s talk.

– Tobi

The reason I joined? Curiosity. The reason I’m sharing this now? Relevance.

Most of the founders I work with hit the same wall: decision fatigue, unclear roles, and a team that relies too heavily on them. Scaling a SaaS company often means unintentionally scaling your exhaustion.

This article isn’t about copying foreign models. It’s about borrowing principles from these radically different and successful companies and translating them into real, usable insights for B2B SaaS teams.

1. Trust Isn’t a Feeling – It’s a System

Buurtzorg operates with over 15,000 nurses in the Netherlands – and no managers.

How? Not by crossing their fingers and hoping everyone gets along. But by building a system of clear roles, peer accountability, and shared expectations.

Each team of 10–12 nurses handles everything from scheduling to budgeting to hiring. No one tells them what to do – but the infrastructure expects them to step up. Teams struggling with coordination are supported by a coach, not replaced or managed. Read more about the role of coaches in my article here: Self-organizing companies don't need managers but coaches.

SaaS parallel: Most early-stage SaaS teams say they value trust. But that often means "we get along" or "we don’t micromanage."

The real question is: Does your system require trust to work – or does it bypass trust with processes and approvals?

TRY THIS:

• Let teams run their retros without founder involvement. Watch what happens.

• Assign one cross-functional team full responsibility for a user outcome – including budget and tool decisions.

• Have the team write a “user manual” for how they want to work together.

• Review quarterly.

2. Roles Are Better Than Job Titles

Viisi doesn’t use job descriptions. Instead, each person holds a handful of clearly defined roles. Some are tactical (like copywriting), some strategic (like pricing decisions), and some relational (like “meeting facilitator”).

Roles can be added, removed, or passed on. And because roles are decoupled from identity, people feel safer experimenting or stepping away.

This idea hit home for me. In SaaS teams, job titles often create unnecessary tension – “I’m Head of Product, so I must…” even if someone else is clearly better suited to a specific task. Discussions can become more about expectations towards roles than expectations toward individuals, which is good.

TRY THIS:

• Create a shared “role board” instead of job descriptions. One person can hold multiple roles – and roles can be shared.

• Make quarterly role reviews part of your team rhythm. What’s still a fit? What’s not?

• Let people propose new roles when they see a gap.

Reflection:
Instead of asking “Who’s underperforming?”, ask “Which role isn’t working?”
The difference in energy is huge. Not to focus on the person also widens the solution space and creates safety and openness.

3. Autonomy Without Support Is Just Neglect

Self-management isn’t “everyone just figures it out.” It’s structured autonomy. That means clear information, clear expectations, and – crucially – coaching when things wobble. Again: Self-organizing companies don't need managers but coaches

Buurtzorg gives each team a coach who doesn’t tell them what to do but helps them work through tension. The idea isn’t to prevent struggle. It’s to grow through it.

SaaS parallel: When a team struggles, we tend to blame the individuals or add a manager. But what if they just need a sounding board? Someone to guide reflection and keep the system healthy?

TRY THIS:

• Assign internal “coaches” (or advisors) – ideally peers – to teams during periods of growth or change.

• Create a simple reflection ritual: What’s working? What’s hard? What have we learned this week?

• Offer role-change or rotation as an initial response to tension – not escalation.

4. Transparency Isn’t a Risk – It’s a Shortcut

Every self-managing company I studied operates with radical transparency – salaries, financials, decision rights, you name it.

Viisi employees can see liquidity, revenue, customer feedback, open roles, and more – at all times. Same with Buurtzorg. When they hit a financial crisis in 2016, they told everyone. And people stepped up. Productivity increased. Nurses skipped holidays to save the company. Nobody was forced – they just cared.

SaaS takeaway:
We often hide metrics out of fear. But hiding creates confusion. Hiding creates fear and ultimately ambiguity. Clarity creates alignment. It creates opportunities. And it nurtures caring and ownership.

TRY THIS:

• Share your P&L with your team – in a simplified dashboard.

• Let everyone see user feedback, NPS, churn. Make it part of your weekly review.

• Publish salary bands internally (or externally if you’re brave). Normalize talking about money.

5. Scrap the Bonus – Keep the Energy

None of these companies use performance-based bonuses. Not Viisi. Not Panelfisa. Not Ner Group.

Instead, they offer profit-sharing, equal for all. Why? Because bonuses tied to individual metrics create silos. People optimize locally, not systemically.

You’d think this would tank motivation. But the opposite happens. People feel less manipulated and more empowered. And it shows – in retention, creativity, and problem-solving. See my article Bonuses are bad – change my mind - Tobi(as Mende)

SaaS translation:
If your bonus system creates more competition than collaboration, it’s costing you more than it pays.

TRY THIS:

• Replace individual bonuses with a team-based profit share tied to company results.

• Or try a flat annual bonus for all full-time team members – simple, fair, motivating.

• Celebrate intrinsic wins: “That feature helped 100 users do X – thank you.”

6. The Decision Model You Use Matters More Than You Think

Consensus is slow. Top-down is fragile. The best model I’ve seen? Consent.

Used by Viisi and Ner Group, consent means: “We move forward unless someone has a serious, reasoned objection.”

Not “Does everyone love this?”
Just “Is it safe enough to try?”

This simple shift removes decision gridlock and puts the power where it belongs – in the team.

Read more about self-organizing decision-making here:

• Organizational Tension Processing - Driving Change in Self-Organizing Companies

• Deciding Better: How to Make Faster, Smarter, and More Effective Decisions in Your Organization

You can also take a look at the slides of my talk about making better decisions here.

TRY THIS:

• In your next product planning session, ask: “Does anyone see a serious risk if we move forward?”

• Encourage objection, not politeness. Objections are signs of engagement.

• Document how decisions were made. That alone boosts clarity 10x.

7. Micro-Enterprises at Scale – The Haier Model

Haier blew my mind. 80,000 employees. Zero middle managers. Every team – from customer service to product – operates as a micro-enterprise, with its own P&L, hiring authority, and internal contracts.

Want to start a new team? You pitch it like a startup. Want funding? You negotiate with other micro-enterprises. It’s the closest thing to a decentralized market inside a massive org.

And it works.

SaaS lens:
You don’t need 80,000 people to borrow this. Even a 15-person startup can operate like a swarm of micro-startups.

TRY THIS:

• Let your CS team create its own playbook, budget, and metrics – and own them fully.

• Build internal SLAs between teams. Not as bureaucracy, but as clarity: “What do we promise each other?”

• Treat shared services (HR, ops, legal) like platforms. They don’t dictate – they serve. (This also relates well to how Team Topologies thinks about platform teams btw.)

8. Career Paths Beyond Climbing

Most traditional orgs rely on promotion as the only way forward. Want more money? Become a manager. Want status? Get a title.

Viisi, Buurtzorg, and Ner Group reject this.

Career growth means growing as a contributor. Becoming more capable, more wise, more trusted. Not necessarily “more important.”

And surprisingly, people stay.

SaaS takeaway:
Offer meaningful progression without pushing people into roles they don’t want – especially management.

TRY THIS:

• Create visible ladders for ICs (individual contributors) and make them as valuable as manager paths.

• Reward skill development, mentorship, and knowledge sharing – not just title changes.

• Ask your team: “Where do you want to grow into, not up to?”

Final Thoughts

Self-management isn’t about being flat. Or nice. Or chaotic.

It’s about building systems that match your values – especially trust, autonomy, and clarity.

What I took from the Corporate Rebels Masterclass wasn’t a blueprint. It was a challenge:

“How much do you actually trust your team? And what have you designed to make that trust real?”

If you’re a founder feeling stuck – overwhelmed, stretched, too essential – start here:

1. Pick one team.

2. Give them real ownership over something that matters.

3. Step back. Not forever, but enough.

4. Watch. Support. Adjust.

5. Repeat.

And if you’re wondering whether your company is ready for more autonomy, here’s the question I’ll leave you with:

What if your company could grow by trusting people more – not less?

Want to explore this in your context?

If this resonates, and you're curious how some of these ideas might look inside your team – I’d be happy to chat.

No pitch. Just a conversation.

Grab your free 30-minute call with me here: https://cal.com/tobiasmende/30min

"You don’t have a delegation problem. You have a clarity and trust problem."

I used to think I was helping my team by staying involved. Answering every question. Checking every detail. In reality, I was slowing everyone down – including myself.

If you've ever said things like …

• “People always depend on me for decisions.”

• “I can't let go of this topic or quality will suffer.”

• “My team isn't experienced enough to handle this.”

… you might be facing the same challenge.

Over the years, in my own work and with clients, I've seen why delegation fails – and how to fix it.

When Delegation Goes Wrong

A former client of mine, a CEO, once asked a team member to build a slide deck. The result? A polished presentation that completely missed the mark. What he actually needed was a simple internal document – short, simple, informative. The CEO was frustrated, felt misunderstood, and thought: "Next time, I’ll just do it myself."

Sounds familiar?

Together with the CEO, we analyzed the situation:

1. No context was shared. What’s the deck for? Who's the audience?

2. No space for ownership. He gave a task, not a problem to solve.

3. No clarity on expectations. How good is "good enough"?

4. No alignment on autonomy. Was this just execution, or was strategic input welcome?

After shifting how he delegated – by sharing more context, co-defining expectations, and trusting his people to think for themselves – he was able to step back without losing quality. Even better: His team appreciated the new autonomy and the ability to contribute on a meaningful level.

The Difference Between Assigning and Delegating

• Assigning a task = "Do this."

• Delegating responsibility = "Make sure we achieve this result."

The first is a handoff. The second is a handover.

Founders often confuse the two. They delegate without alignment and then panic when the outcome doesn’t match their mental picture. The result? Micromanagement, lost trust, and frustrated teams.

Why Delegation Fails (And What Most People Miss)

• Lack of context. People can't read your mind. If they don’t know the "why," they’ll default to their own logic.

• Unclear expectations. If you don’t define "good," it’s difficult to deliver it.

• No trust system. You say you trust your team, but check everything yourself.

• Low autonomy. Are they encouraged to challenge the project? Can they adapt the approach?

• Task-based delegation. If you're just offloading tasks, you’re not really delegating.

Delegation isn't about letting go. It's about equipping others to care and carry.

Quick Check-In: Are You the Bottleneck?

Use this list to reflect honestly. If you nod at several of these, it might be time to change how you delegate.

1. Do you regularly rewrite or redo work?

2. Are you the primary person making final decisions?

3. Are projects on hold when you're on vacation?

4. Do you often feel like it’s faster to “just do it yourself”?

5. Have you ever reversed a teammate’s decision because it wasn’t what you would have done?

6. Are projects stalled because you're not available to review or approve them?

What Effective Delegation Looks Like

Here’s what I've found helps leaders (and myself!) delegate with confidence: Use the Ladder of Delegation

Discuss with your team what level of delegation is appropriate:

1. Tell – I make the decision and announce it.

2. Sell – I make the decision but try to convince you it’s right.

3. Consult – I ask for your input before deciding.

4. Agree – We decide together by consensus.

5. Advise – You decide, but I offer suggestions or input.

6. Inquire – You decide, and I ask afterward what you did.

7. Delegate – You decide, and I don’t follow up unless you tell me.

Tool Tip: Try Delegation Poker with your team to identify and align the right levels together.

How to Facilitate Delegation Poker

How to play (remote or in-person):

1. Pick a decision area (e.g., hiring, roadmap, pricing).

2. Each person privately chooses a card (level 1–7) that reflects how they think it should be delegated.

3. Reveal all cards. Discuss the differences. Find alignment.

Why it helps: It exposes unspoken assumptions, power gaps, and control habits.

Tip: It’s normal to discover you’re delegating less than you thought.

Using a Delegation Map

A Delegation Map is a visual tool to identify responsibilities, current owners, and the desired level of delegation.

Structure:

• Area or Topic (e.g., Hiring, Product Strategy)

• Current Decision Maker

• Desired Delegation Level

• Barriers/Dependencies

Before/After Example:

• Before: “Product Strategy” is only decided by the founder.

• After: Strategy is co-created by PM and CPO, with founder in an advise-or-inquire role.

This map can also help spot where roles are ambiguous or overloaded.

Delegation Traps to Avoid

Even experienced leaders fall into these traps:

• False Delegation: You assign responsibility, but retain all approval rights.

• Silent Standards: You don’t define what “good” looks like – and penalize people for missing your invisible bar.

• Hero Syndrome: You like being the fixer or the smartest person in the room.

• Delegating Too Late: You hand things off only when you’re overwhelmed, not when it’s optimal.

• Delegating Too Early: You give away critical thinking before people have enough context.

Delegation isn’t just a skill – it’s a mirror: It shows you where trust and systems are lacking.

Templates & Tools

DELEGATION BRIEF

Use this when handing over a responsibility:

• Context: Why this matters

• Goal: What success looks like

• Constraints: Deadlines, budget, etc.

• Support: Who can help or review

• Autonomy: What level of freedom do they have?

WEEKLY DELEGATION CHECK-IN (ASYNC OR LIVE)

Ask these questions in your weeklies:

• What decisions are you waiting on me for?

• Where do you feel unclear about ownership?

• What do you need from me to move forward?

SELF-REFLECTION QUESTIONS FOR LEADERS

Use these at least once a month (i.e., in your monthly review):

• Am I trusting or double-checking?

• Do I share enough context before delegating?

• Would I feel confident delegating this again?

Try This With Your Team

STEP 1: SPOT THE BOTTLENECKS

Map your current roles and identify where you're the bottleneck.

STEP 2: DEFINE DELEGATION LEVELS

Use Delegation Poker or a Delegation Map to visualize it.

STEP 3: RUN A SAFE EXPERIMENT

Pick one project or responsibility. Apply your new approach. Reflect on it after a week or two.

Want to go further? Run a "delegation retro" with your team. Ask:

• Where are we overdependent on one person?

• Where is clarity or context missing?

• What would help us distribute ownership better?

Wrapping Up

If delegation feels hard, you're not alone. It’s a challenge many founders face – including myself. But the answer isn’t working harder or getting better at juggling. It’s about creating the clarity, context, and trust that lets others carry more of the load.

As a founder or leader, your job isn’t to be in every detail. It’s to make good decisions possible without you.

"As a leader, your job isn’t to be in every detail. It’s to make good decisions possible without you."

Getting better at delegation doesn’t happen overnight – but it starts with one honest conversation.

Want help creating your delegation map or running a delegation retro?

Let’s talk. I can help you (and your leadership team) stop being the bottleneck and start scaling with clarity.

This isn't that kind of article.

What you're about to read is raw, field-tested, and personal. These are the qualities I’ve come to value most in leadership – not because they look good on paper, but because they’re the difference between being the kind of leader people endure… and the kind they actually want to follow.

I don’t always get it right. But these ten traits are my compass. And if you’re building something meaningful and want to lead in a way that feels grounded, human, and real – I think you’ll find something here.

1. Clarity Over Chaos

Leadership starts with direction. Not perfect answers. Just enough clarity for the team to move. To breathe.

Clarity means alignment, not micromanagement. It’s giving people the confidence to move without checking in every five minutes. It means cutting through the noise, aligning people, and giving them enough structure to act with autonomy. Sometimes it means naming the tension in the room no one dares to say out loud.

Clarity also means making hard calls – even when things are still foggy. It’s less about certainty, more about honesty: "Here’s what we know, here’s what we don’t, and here’s what we’re doing right now."

2. Composure Is Contagious

Startups are messy. Fires everywhere. But your energy as a leader sets the weather in the room. If you’re panicking, everyone feels it.

This doesn’t mean suppressing feelings or pretending to be a rock. It means self-regulating. Pausing. Responding instead of reacting. The calm leader creates space for others to step up.

And composure isn’t about always being calm – it’s about coming back to center. It’s about noticing your triggers and learning not to drag the whole team into your emotional storm.

3. Listen to Learn, Not to React

One of the most powerful leadership tools is your silence. Just listen. Not to fix. Not to prove. To actually hear what’s there.

People don’t want perfect answers. They want to feel seen. And honestly, they often solve their stuff if you give them space.

Listening means creating safety. It means putting your ego in the back seat and being genuinely curious. And it’s a skill. — A skill you can and should train like a muscle.

4. Communicate Like a Human

No one needs more corporate theater. Say what you mean. Say when you don’t know. Apologize when you screw up.

Your team isn’t looking for a superhero. They’re looking for someone real enough to follow when things get hard.

Speak plainly. Tell stories. Avoid buzzwords. The more relatable you are, the more trust you’ll build. The best communication is clear, candid, and rooted in respect – not authority.

5. Trust Isn’t Earned – It’s Given First

Delegating isn’t just handing over tasks. It’s handing over ownership – and letting go of control. Ownership means someone else does it their way.

If you can’t let go, you are the bottleneck.

Trust isn’t a perk. Control kills speed. Trust multiplies it. People will surprise you in good ways if you give them space. Hover, and you’ll just shrink their confidence.

This doesn’t mean blind faith. It means setting expectations clearly, then stepping back and letting people own their outcomes – including their mistakes.

6. Lead Yourself First

Your mood, your schedule, your boundaries – they bleed into the company. You can’t lead others well if you’re a mess inside.

Everything you do ripples outward. If you’re scattered, reactive, or constantly overwhelmed, that becomes your team’s vibe too.

Your calendar is a mirror. Look at it. What does it say about your values?

Leadership starts with self-awareness. What do you value? What do you tolerate? What do you avoid? Clean your side of the street first. Self-leadership is the stuff no one sees immediately – sleep, food, fitness, reflection, doing the inner work. But it’s what separates the reactive from the intentional.

The founders who grow fastest are the ones who take their own inner work seriously.

7. Grow People, Not Just KPIs

You’re not building software. You’re building the system that builds software. And that system is human.

Leadership is gardening. Not engineering.

People thrive with feedback, purpose, trust, challenge, safety. If someone on your team grows because of you, not in spite of you, you are winning.

This means creating opportunities. Delegating stretch assignments. Coaching. Providing feedback that helps people actually grow, not just "improve performance."

8. Let Go of the Plan, Hold on to the Purpose

Rigidity is fragile. In startups, everything shifts. Plans fall apart. Strategy morphs. That’s not failure. That’s the game.

Don’t build a fortress. Learn to surf.

Good leaders are adaptive. Not flaky. They stay anchored in values, not in fixed plans.

Let go of your attachment to how. Get obsessed with why. The purpose is your compass. The path is a series of informed experiments.

9. See the System

Most problems aren’t people problems. They’re system problems showing up as people problems.

Don’t just fight fires. Redesign the fireproofing.

Zoom out. Ask why it keeps happening. Look at incentives, feedback loops, roles, culture. That’s where the real leverage lives.

If the same issue keeps cropping up across teams, it’s not a coincidence – it’s a signal. Fix the system, and you fix ten downstream headaches.

10. Stay Humble. Keep It Light.

The work is serious. You don’t have to be.

Leadership with a wink beats leadership with a wagging finger.

Admit when you’re wrong. Laugh with your team. Share your humanity. No one wants to follow a robot – even a high-performing one.

Humility isn’t weakness. It’s magnetic. Especially when paired with confidence and clarity. And humor? Humor creates connection. People do better work when they’re not afraid to smile.

Final Thoughts

This is the kind of leadership I practice, teach, and come back to when I lose my way. It’s not always easy, but it’s what works – in real companies, with real people, doing real things.

It’s not about being perfect. It’s about being consistent. Intentional. And willing to evolve.

If that’s the kind of leadership you’re trying to live too, let’s talk.

— Tobi(as Mende)
Founder @ Tech Unicorn Builders | Leadership & Ops Advisor

Decisions are the crossroads at which you have the opportunity to influence direction. In a growing software organization, there are probably tens or hundreds of decisions made every day. But are those great decisions? Are those decisions made fast? Is your company improving how decisions are made? Are decisions made at the right level by the right people?

Judging from experience, the answers to these questions range from sometimes to rarely. And that is not surprising. While people might learn at some point how to make decisions about their lives as individuals, we rarely teach people how to make great decisions in groups and within organizational constraints.

The result? Either some (self-)elected leaders who make the majority of decisions or endless discussions between peers about the right path forward (often in more and longer meetings). This leads to people being blocked by waiting for a decision or a fast decision that most people don’t understand or cannot commit to.

That doesn’t sound too promising. But there is hope. Only by reflecting on how decisions are made in the organization and why, leaders can find ways to improve decision-making. If they go a step further and learn/train tools and methods for collaborative and distributed decision-making, improvements can be seen within weeks.

But let’s start with the following question: What is a good decision?

The Anatomy of Good Decision-Making

Many people will say that decision-making is good when the outcome is good. And this is part of the problem. Because if this is how we judge decisions, we cannot be certain about the quality of our decision-making while we are making it – only in hindsight. Furthermore, we would have no means to improve our decision-making, as the quality depends on a plethora of unknown variables.

And the truth is: You can follow the best possible decision-making process, consider all the information and options you have, and still yield a bad outcome. Simply because the world is complex and there is uncertainty. If there weren’t, you wouldn’t need to decide in the first place because the best path forward would be obvious.

Therefore, if we want to judge our decision-making, we need to focus on the context in which the decision was made:

1. Was all the available information considered?

2. Were all the people involved that could have meaningful information?

3. Were all people involved that would be affected by the decision?

4. Did we really put all options on the table (even those we personally disliked)?

If we can truthfully answer yes to all these questions, the likelihood is high that we made the best possible decision. If you are not sure about one of these questions or need to answer no: Congratulations, you might have found an opportunity to improve your decision-making.

How to Collect All the Available Information and Options

A decision can only be as good as the options that were available and the information that was used to choose one of these options.

Many companies distribute information on a need-to-know basis. The main problem here is that leaders consequently fail to judge accurately what information someone might need. Therefore, default-to-open is key: Share information openly unless there is a really good reason not to. (More on this in my article Default to Open.)

Invite other people to the decision. Especially people who are different from you, have a different background, and might even have an opinion you do not like. In the end, all those different perspectives are there for a reason and will point you to bits of information you might not have considered otherwise.

WHY TRADITIONAL BRAINSTORMING FAILS

When in a group, avoid the traditional brainstorming to surface ideas. It does not work (research backs this up). People tend to censor themselves, favor safe ideas, or anchor their suggestions on the first thing said.

A better method? Secret Brainstorming + Affinity Mapping.

• In the secret brainstorming phase, participants anonymously submit ideas.

• Ideas are then grouped into themes (affinity mapping) before being reviewed collectively.

This approach removes bias, encourages creativity, and ensures ideas are evaluated based on merit rather than who proposed them.

How to Prepare for a Decision

Once you are sure that you have all the information and a sufficient number of options, it makes sense to document this:

• What is the situation in which we need to decide?

• Why now?

• What information do we have that influences the decision?

• Which options do we consider?

A difficult decision is always the choice between options that all look equally good or bad. It is always about trade-offs. Different people might make different trade-offs, and this is what makes deciding in groups hard.

Nonetheless, laying out the options, the context, and potential trade-offs creates a common ground for understanding the decision.

How to Decide Effectively as a Group

Leaders often struggle with acceptance and adoption of their decisions. And the reason is that they don’t involve the people affected by the decision – neither in figuring out the options nor in making the actual decision. People then either do not understand why a decision needs to be made in the first place, or they do not understand the option that was selected, or they disagree with it.

All of these issues can be completely avoided when you involve people in the decision-making process.

Doing this asynchronously as mentioned before is one option, but ultimately, you still make the call as a single person. There is, however, also an option to decide in a group in an efficient and effective manner.

Delegation Needs Clarity

Independent of the decision-making process or method you and your team are selecting, there is one last trap I frequently see leaders fall into: Delegation without clarity.

People need to have an understanding/feeling/sense about "how good looks like." What does the company want to achieve? What is the purpose? What is the context in which we are operating?

If that is unclear, delegation of decisions or projects will usually not lead to results that you as a leader would consider "great."

Therefore, defining a clear mission, purpose, and strategy (ideally with your team) is crucial to delegate decisions and projects successfully.

Conclusion: Better Decisions – Better Companies

Decisions shape the future – of your life, your team, and your company. Yet, in many organizations, decision-making is either too centralized, too slow, or too chaotic.

The good news? It doesn’t have to be this way.

By shifting the focus from outcomes to process, leaders can transform decision-making from a bottleneck into a strength. Collecting the right information, involving the right people, structuring decisions clearly, and using methods like systemic consensing can significantly improve the speed and quality of decisions.

Most importantly, great decision-making isn’t about finding the perfect answer – it’s about making the best possible decision with the information available, ensuring alignment, and enabling execution.

My question to you: How will you start improving decision-making in your organization today? Drop your thoughts in the comments! 👇

How to Fix Decision-Making in Your Company (for Good)

Let’s be real – decision-making is one of the biggest bottlenecks in any growing company. Either decisions take forever, or they happen too fast with little buy-in. Both lead to frustration, wasted time, and teams that feel stuck instead of moving forward.

That’s why we built a no-nonsense offer to help you and your team make better decisions, faster, and with real alignment – without endless back-and-forth or top-down guesswork.

Here’s what you get:

✅ Battle-tested decision-making methods – so you stop relying on gut feeling alone

✅ Templates & frameworks – to structure decisions clearly without reinventing the wheel

✅ Hands-on decision-making workshop – where we tackle real decisions in real time

✅ Ongoing sparring & coaching – to make sure this sticks and transforms how your team operates

If you’re tired of decision chaos and want a smarter, smoother way to run your company, let’s talk.

Book a free 30-minute call with me and let’s see if this is a good fit – no pressure, just clarity.

This leads to the following observation in our work with founders and startups: The average founder is somewhere between 35 and 55 years old and has experienced at least one company and one leadership style before. Their leadership is therefore often influenced by an even older leadership style, often based on assumptions from 20 or even 30 years ago. (Of course, exceptions exist.)

At the same time, the needs toward leadership, defined by our current times and the people we lead, have fundamentally changed. The result? Founders struggling to lead effectively, working harder and harder, doubling down on the same patterns that lead them into the dilemma. A vicious cycle.

Today, we companies need to react and evolve much faster than 30 years ago. This is impossible to achieve long-term and at scale in a top-down managed company. Furthermore, younger generations crave more autonomy, independency, impact, and purpose in their work, which is in stark contrast with taking orders. The why is more important than the what. People want inspiration, rather than management. At the same time, younger generations are also overwhelmed with a plethora of decisions they can make in the presence of absolute freedom while not prepared for this during education.

Education does not prepare people for good and effective decision-making as individuals and, even less so, as groups. To the same extent generation Z desires impact and autonomy, they struggle with making good decisions fast due to an overwhelming number of options.

Furthermore, how we evaluate decisions, is broken. Most leaders evaluate decisions based on the outcome, not on the decision-making process. Which leads to people fearing decision-making as they can't guarantee a good outcome. This leads to a decision-paralysis at the bottom, usually "solved" by someone higher up the ranks stepping in and taking the decision. This is a band-aid for broken decision-making, which increases dependency and decreases the organization’s ability to make good decisions fast.

In other words, the systemic issues in organizational decision-making are patched by doing more of what created the systemic issues in the first place. Kind of like reinstalling Windows 95 on an M4 MacBookPro. — It will likely not solve your issues.

Understanding Generational Differences

Traditional leadership is based on a top-down divide-and-conquer approach and on the mindset, that people at the bottom know less, are less informed, and are less smart than the people higher up. Decisions are mainly made at the top and passed down the chain of command.

Knowledge is shared on a need-to-know basis. Even more progressive companies often fall back on this "tried-and-tested" (aka "we always did it like this") approach, when under pressure. This is especially harmful as it teaches people that they are not trusted with the difficult decisions and in critical situations. Teams can decide whatever they want while the sun is shining, but when clouds arise, top-level orders are given.

Younger generations, but not only them, struggle with this. They want to have a say in their work, what they work on, how they work on it and with whom. They need to understand why they are doing their work. There is the myth that generation Z does not want to work or is too sensitive and not as productive as older generations. From my observation, it is more like younger generations are less okay with doing bullshit work. They are great sensors in your organization to detect unclear purpose and meaningless busy-work. Furthermore, their desire for a good "work-life-balance" is a reminder that organizations should exist to improve peoples lives and not just for profit only.

In an organization with a clear purpose, strong relationship and a good alignment between personal and organizational values, people are willing to give much more, and it will feel less like work. Everybody wins.

The opposite is equally true: The more leaders resort to traditional leadership approaches, the less effective and outright harmful their leadership becomes.

The Need for Change

Apart from the generational differences, times are also different. Technological advances happen faster than ever. The world is more globally connected and changes at the other end of the world influence us actually within seconds or days.

This is too much for an individual leader or a small leadership team to handle. The amount of data is endless. The conflicts between context and the organizational setup are also not immediately visible to founders or management. Change driven from the top usually comes too late and happens in the wrong way, leading to an organizational setup already outdated, once the company transformed.

This results in missed market-trends, lost business-opportunities, overwhelmed founders, burnt-out management, and irritated employees, and a huge number of people in the organization who do not think for the business.

To be successful in the long-term, organizations need the opposite: Effective, purpose-driven decision-making and entrepreneurial thinking in every position of the company. Clear processes, how to drive and inform change from every role and position in the company. A way to handle and influence this organic and dynamic organizational evolution that might seem like chaos to leaders who are used to more rigid structures and org charts with crystal-clear, well-defined responsibilities. Only the flexibility coming from these degrees of freedom paired with an understanding how to handle this freedom and responsibility will lead to an organization that can adapt to changing circumstances fast. Organizational resilience and adaptability at its best.

The Challenge of Freedom

The desire for freedom and autonomy among younger employees is often at odds with the necessity for accountability and responsibility. This paradox presents a unique challenge for leaders who must find a way to unleash their teams while ensuring that organizational goals are met.

THE PARADOX EXPLAINED

Younger generations, particularly Millennials and Gen Z, crave a work environment that offers flexibility, creativity, and self-direction. They seek the freedom to make choices about their work, including how and when to complete tasks. This desire for autonomy is rooted in their upbringing, where they were frequently encouraged to express themselves and take initiative. However, with this freedom comes the challenge of responsibility. Many younger employees have not had extensive experience in managing their time and decisions, leading to potential struggles with accountability. School and university do not prepare people for this adequately.

THE ROLE OF LEADERSHIP

Today, leaders need to assume more of a coaching role, than a management role. While setting clear expectations can help to give guidance and direction, being too specific and be considered controlling and harm the relationship.

Leaders can help their employees to become better at decision-making by role modeling and being transparent about their process, and by encouraging self-reflection. Furthermore, more than ever, it is important for leaders to create a safe environment where people can experiment, fail, and learn.

Offer training and support where needed. The directive should always be how to prepare people for more freedom, rather than restricting their freedom to achieve the desired results.

Observation from our work with startups: Not only younger generations, but people of all age struggle with collaborative decision-making. We usually do not learn this at school, and therefore the only tools available to most teams are:

• HIPPO – Highest-Paid Persons Opinion wins

• Loudest person wins

Train people in decision-making, give them additional tools and enable them to make decisions collaboratively and also come up with ideas collaboratively (also here, "brainstorming" is not the answer). (P.S.: We run trainings on this topic, online and in-person. ;) – Talk to me, if you would like to learn more.)

SOLUTIONS AND STRATEGIES

The solution is simple, but not easy:

As leaders, we need to shape organizations through less control and more inspiration. We need to establish processes and structures that enable self-organization and self-evolution. We must train people to thrive in these environments. And most importantly: We must trust in the good of people and the collaborative intelligence of the group. We must let go of our own power and embrace the discomfort of not knowing and not being in control.

We have to resist the urge to compensate for lacking experience of employees with more control and structure but answer this demand with more coaching and training. You can read more about this topic here.

It is probably noteworthy, that the servant leadership approach can be as harmful as it is promoted. A leader who continuously unblocks their people might not necessarily enable them to unblock themselves going forward, and thus fails to bring forward new leaders. The organization of the future needs leaders in all positions – people who feel responsible for the shared purpose and bring forward their best to contribute to achieving this shared purpose. In this environment, conflict is healthy and supports good decision-making. When everybody sees themselves as a leader and takes responsibility, the question might be: How do we coordinate change to not drown in chaos and conflicting initiatives? — A tension-based proposal process can be part of a solution. It is usually better to let friction arise and solve it then than trying to predict future issues and build systems for problems that never manifest.

Organizational culture plays a pivotal role in shaping how employees experience freedom and autonomy in the workplace. A supportive culture not only encourages self-organization but also ensures that employees feel empowered and accountable for their work. As organizations strive to adapt to the evolving needs of younger generations, it is essential for leaders to cultivate a culture that fosters this balance. Here are some actionable tips for leaders to create a supportive culture that facilitates a successful transition to greater freedom and autonomy.

1. Define and Communicate Core Values

Articulate the core values of the organization that promote autonomy, trust, and collaboration. Leaders should communicate these values consistently through various channels, including onboarding sessions, team meetings, and internal communications, and live them daily. When starting out, define the values in collaboration with your team, so everybody understands them and feels connected to them.

2. Encourage Collaboration and Teamwork

Build a culture of collaboration by creating opportunities for team members to work together on projects. Encourage cross-functional teams to leverage diverse perspectives and skills. The ultimate goal of each company should be to serve its customers in the best possible way. Everything else (think: departments, conflicting initiatives, lengthy backlogs, deadlines, politics, …) is a fluffy distraction.

3. Promote Transparency and Open Communication

Establish open lines of communication where employees feel safe sharing their thoughts, concerns, and feedback. Leaders should model transparency by sharing organizational goals, challenges, and successes. Default-to-open. This will enable people in all positions to make better decisions for the company.

4. Encourage Risk-Taking and Learning from Failure

Cultivate a culture that views mistakes as learning opportunities rather than failures. Leaders should encourage employees to take calculated risks and support them in experimenting with new approaches.

Experiments that never fail, are not experiments but “playing it safe”. Remember: You cannot judge a decision based on its outcome, but only based on the underlying decision-making-process.

5. Provide Professional Development Opportunities

Invest in training and development programs that equip employees with the skills needed to thrive in a self-organizing environment. This could include workshops on time management, decision-making, coaching, and leadership development as well as training on tools and processes you use.

6. Empower Decision-Making at All Levels

Delegate decision-making authority to employees at all levels, allowing them to take ownership of their work. Leaders should trust their teams to make decisions that align with organizational goals. When somebody wants a decision from you, you might ask them what they need to make the decision themselves. Is it information? Is it permission?

Many leaders fail at creating an environment where people can confidently make decisions. This often results in founders / top-level leads becoming the bottleneck for organizational decision-making and performance. At the worst stage of this, the founders are constantly busy, neglecting their private lives, and still not having enough hours in a day to make sure everything happens properly. See yourself in this? Let’s talk, we can solve this.

7. Solicit Feedback and Adapt

Regularly seek feedback from employees about the organizational culture and their experiences with autonomy. Use this feedback to make adjustments and improvements to policies and practices.

CONCLUSION

Leaders need to reflect on their leadership style and where it comes from. Unfortunately, a lot of leadership advice is based on past centuries and generations who already retired a while ago.

Leadership development programs regularly lack behind with their curriculum, teaching approaches to leadership that used to work in a very different environment.

The challenge for leaders today is to question this advice and contrast it with their reality, their people, and their context. Leadership requires courage. — The courage to act, think, and lead different.

Reflecting on your leadership today: What is your biggest leadership challenge? Please let me know in the comments!

This is because without formal authority, you have to lead the change right (we will get to that in a bit). With formal authority, on the other hand, you can force the change, which can lead to frustration, resignation, and damage to the organization overall. Even worse, people might not speak up against change that they do not understand or that does not make sense to them. Therefore, whenever being in a leadership position with formal power, be extra cautious about how you drive change.

In my article about organizational tension processing, I already tapped into an approach how we can initiate change in organizations without formal (hierarchical) authority. In today's article, I explore the topic of how to drive the actual change and how to ensure that it becomes a success, in greater detail.

Understanding Organizational Change

Before diving deeper, it is essential to clarify what we mean by organizational change.

Organizational change refers to the processes through which organizations alter their strategies, structures, processes, technologies, or culture to adapt to internal and external pressures.

Seeing the organization as a product from and for the people within

Every organization exists to serve a certain purpose, and it serves this purpose through the people within that organization (and their products/services, of course). An effective organization is one that enables the people in that organization to do their best work.

In a sense, the organization is a product that is built for the people in that organization. At the same time, it is a product that is built by the people in the organization.

Therefore, we can learn a lot about building great organizations from how we build great products. — With the important difference that change is much harder when it involves humans, compared to a change that involves mostly code. — "Deploying a change" therefore has to look vastly different.

Nonetheless, there are some similarities about

• how we know what to change,

• how we approach change, and

• how we measure the success of a change.

CHANGE INCREMENTALLY AND CONTINUOUSLY

One of the cornerstones of successful product development in complex environments is to make changes incrementally. We do not build products in the dark, doing a big bang release, finding out nobody needs it, or it doesn't solve the problems we wanted to solve. Modern products change and improve one deployment at a time. — Incrementally and continuously.

With organizational change, it should be the same. One reason why I love the tension-based approach so much is because it does exactly that: Changing the organization by addressing one tension at a time.

This is in stark contrast to bringing a consultant in, doing a big-bang transformation and then hoping that the new organizations magically will withstand the test of time. If you bring in consultants, make sure they help your organization to become more flexible and able to change and reinvent itself as needed. (If you consider this, let’s talk.)

FOCUS LEADS TO SPEED AND SUCCESS

It is easy to work on too many features at a time. The consequence is that everything takes longer, conflicts arise, and the changes influence each other negatively. Teams who work on too many features in parallel often do not take the time to assess if the feature actually satisfied the customers and solved their problems, as they are already busy building the next thing.

The same can happen with organizational change initiatives as the lack of focus might cause people to become confused. Furthermore, as change takes time and repetition, changing too many things at once can lead to following through until a change has really settled.

TALK TO YOUR CUSTOMERS

Before we build a product or change the product in a certain way, we should make sure to truly understand our customers, their needs, and problems. Only then we can build a product that is really useful to them.

With organizational change, the customers are the people within the organization, more specifically the people affected by the change.

I have seen a lot of damage done in organizations because formal leaders just attempted to split or merge teams without talking to the people involved. The fallout was huge. In a sense, they built the wrong product because they did not talk to their customers.

SUCCESS IS MEASURED WITH FOCUS ON CUSTOMERS

In product development, we should not focus on output as a measure of success but on outcomes achieved for customers. With organizational change, it is not different.

• Does the change help people to do their work better?

• Can they work more efficiently and effectively?

• Are they more satisfied and enjoy their job more?

If change does not yield any improvements in these dimensions, it should be considered a failure, and we should find and try another approach.

A PRODUCT OF THE PEOPLE WITHIN THE ORGANIZATION

One crucial difference to building a product like a SaaS service is, of course, that the organization is a product of the people and their relationships with each other and with the purpose of the organization.

And this is something that cannot be controlled through formal power. I have worked with organizations where leadership felt highly impactful while deploying an organizational transformation, just to find out that people in the organization kept working like before. The organization looked good on paper, but the paper had nothing to do with reality.

Therefore, effective and successful change needs buy-in and support of the people within the organization.

WHAT ABOUT THE CEO? THE FOUNDERS? THE INVESTORS?

I already can hear people arguing, that the actual customers are, in fact, the CEO, the founders, or the investors. Because, after all, they are paying for all of that. Right?

I would argue that those stakeholders are not customers to the organizational structures and processes, but only to the companies ability to fulfill its purpose. And like customers of a SaaS product should not dictate the software architecture of that product, those customers should not dictate the architecture of the organization. This, of course, does not mean that we should ignore their needs and do whatever we want. — We should establish mutual trust and transparency to make sure we are evolving an organization that fulfills its purpose in the best way.

Furthermore, while those stakeholders might pay money, they have a hard time to just walking away if they don't like the "product". Other people in the organization pay with their time, commitment, and loyalty but can walk away easily, if they don't like the "product" (the organization).

How to drive change

1. START WITH WHY

People don't buy what you do; they buy why you do it. — Simon Sinek

When we want to drive change, we first need to set the stage:

• What do we want to achieve?

• Where are we today?

• What are our tensions with the current conditions?

We need to help people to see the challenges that we are seeing. Only when people see and understand this, they can think about solutions or verify that our solution idea could work.

As leaders, we often have ideas of how the change should look. After all, we are paid for solutions, not problems. Right?

The issue with this is that we frequently neglect the different knowledge, understanding, and awareness of the people around us. They might not even have understood the problem nor do they understand why our solution is the right one (and maybe it is not)

Instead of skipping ahead to proposing the solution, we need to take a step back and explain why we see the need for change.

2. INVOLVE AFFECTED PEOPLE IN DEFINING HOW THE CHANGE NEEDS TO LOOK

I have heard people say, that other people don't like (to) change.

This does not sit right with me. People change all the time. — They get married, buy houses, move to different countries, start a new hobby, change jobs, … — All of these are massive changes.

The difference is that all of these are changes where people understand the reasons behind the change and can influence the change.

People don't resist change. They resist change done to them. — Me

The quality of solutions increases through the amount of diverse and divergent thinking that went into them. Furthermore, if we involve people into the process of finding or defining a solution, they have the opportunity to question it and to understand why the solution is, in fact, the best solution we could come up with.

Common sources of resistance include fear of the unknown, loss of control, or perceived threats to job security. To address these challenges, it’s crucial to create a safe environment where people feel comfortable expressing their concerns.

Leaders should actively listen to feedback and show empathy toward those affected by the change. Providing clear communication about the benefits of the change and how it will impact individuals positively can help reduce fears and build support.

3. REPETITIVE COMMUNICATION AND TRANSPARENCY

People are busy, and your change initiative is probably the last thing on their mind. Thus, it is important to be proactive with the communication and repeat it from time to time so that everybody can understand, how the change is progressing.

For example, when we introduced continuous deployments for 15 teams, we would frequently share where we were on that journey, what would happen next, and how people can give feedback and influence the change.

4. COLLECTING FEEDBACK AND ADJUST

Chances are, that even after discussing solutions together, we will discover obstacles and things we have not considered while implementing the solution. Maybe somebody in the organization suddenly has a tension with how the change is done or progressing. It is essential that this feedback can be surfaced and is used to adjust the change.

Therefore, when you are responsible for driving change, make clear that you want and need feedback and how people can give it.

Depending on the size of the organization, your position in the organization and the perceived psychological safety of the people in the organization, consider providing options to give anonymous feedback. Be mindful that your psychological safety as a formal leader or senior person might be vastly different from the perceived safety of people in other roles or positions.

5. PERSISTENCE AND CONTINUED SUPPORT

Lasting change takes time, especially when it involves more than a handful of people. A mistake that I did in the past was to underestimate how much time, repetitive communication and ongoing support a change requires until it could fully settle and is not perceived as a change but as the new normal.

Again, people around you might not think as much about the change as you do, as they have other topics more present on their minds. Therefore, it might take significantly longer to establish change and to make sure that everybody has understood, accepted and internalized the new normal. Nothing bad about that, it just means we need to drive the change and remind people about it longer than we might think.

Conclusion

Effective, lasting, and successful change comes from within. This is why we need to engage people with the change and help them to see the reasons for the change and understand the solution. They also have to see that the solution we choose is good enough and safe enough to be tried. Otherwise, resistance might cause our attempt for change to fail.

In such cases, leaders with official powers often get frustrated and declare change to push through this resistance. This is the easy approach, but ultimately also the more damaging approach, and it leaves people feeling powerless, overruled and like marionettes. The long-term consequences are people being unsure what they can decide and control and people who stop thinking ahead for the organization.

Therefore, especially when in a formal leadership position, we need to be cautious about how we go about driving change. After all, to lead means to inspire, not to control.

To lead means to inspire, not to control.

Is organizational change a challenging topic in your organization? I would love to learn more about it and invite you to a free 30-minute conversation on this topic.

In today’s article, I would like to explore what we can do instead to satisfy the actual needs companies and individuals might have.

How to Stop Performance Reviews?

Performance reviews frequently fail to provide meaningful insights, frequently resulting in outdated, frustrating, and irritating feedback that doesn’t reflect current performance. By eliminating them, organizations can identify underlying tensions and address them through more effective channels. By focussing on the needs, we see in organizations, we might discover better alternatives, as different needs require different approaches.

First, we need to acknowledge that performance reviews do more harm than good and therefore: Just stop them. See what your organization is really missing now and develop better alternatives collaboratively.

NEEDS, COMPANIES TRY TO MEET THROUGH PERFORMANCE REVIEWS

I see the following needs that companies try to fulfill through performance reviews:

1. Providing feedback: To achieve outstanding results and continuously improve, feedback is crucial. However, feedback during annual or quarterly performance reviews is usually too late to be helpful. In the next section, we will see how to solve the need for feedback differently.

2. Making salary decisions: Companies need to have a good way of deciding about salaries. Traditionally, performance reviews inform salary discussions. As performance cannot and should not be accurately measured, performance reviews lead to salary decisions on incomplete and false data. In the section about salary decisions we will cover better, fairer ways of distributing money to employees.

3. Promoting: In traditional hierarchical companies, promotions, and career leaders play a crucial role. In these environments, performance reviews were used to make informed decisions about promotions. However, past job performance is no guarantee for future performance. Thus, there is no point in using performance reviews for such. Furthermore, promotions assume that people can only fill exactly one role. Questioning this assumption, we will discuss how people can find their path in the organization.

4. Giving direction: Employees need to know what they should achieve, what is important, and what is not. But: Performance reviews are an inefficient way of giving direction. When we involve teams with the companies vision and mission, we do not need quarterly or annual individual events for alignment.

Let’s dive into each of these four needs and discuss how we can meet them in a better way.

1. Providing better feedback better

Feedback should be as direct and as timely as possible. Peers should give each other feedback and hold each other accountable. Regular (as in weekly/bi-weekly) 1-on-1s between team members provide a space where feedback can be requested and given or where team members can build their relationships. Having a great relationship with each other makes giving and receiving feedback easier and more effective.

We can also encourage people to host 360-degree feedback sessions. For these sessions, they invite 4–5 colleagues they think can provide relevant feedback about their work. Those people prepare two positive pieces of feedback and one negative/constructive one. Taking turns, people share their feedback. The receiver may ask clarification questions, but not justify their behavior in this call. I really like this format. It is intimidating at first, but people will give overwhelmingly positive feedback and very supportive and constructive feedback in this session, and the feedback will be way more meaningful than feedback of a single manager alone.

What matters most in team-based work such as software engineering is, that we as a team develop better ways of working and continuously help each other to become better. Therefore, having frequent and structured ways of requesting and providing feedback to peers is more important than feedback from managers.

Companies should invest in the ability of their employees to give and receive feedback, and not limit the responsibilities to provide feedback to a few chosen managers.

2. Making salary decisions

When it comes to salary decisions, organizations should focus on aligning compensation with fair market rates. This forms the foundation for everything else. If you consider hiring someone new for more money than you pay your current employees, raise their salaries. They are likely doing the job better already.

Second, think about profit sharing, company shares, and other means of getting people involved with the company success. Things are way easier when company goals and individual goals are aligned. (Be careful with bonuses, as bonuses usually only align with short-term goals, if at all. See “Bonuses are bad – change my mind”).

Make finances transparent and engage people with salary decisions. Everybody wants a fair salary, and a lot of feeling of injustices comes from intransparent salaries (or from unfair salaries). Make them transparent. Make company finances transparent. Have discussions in your organization about what a fair salary is. 

Let people request more money if they believe they need it and if they believe it is fair. You could also experiment with letting people vote on salary decisions: Who of my peers shall earn more than I do? Who of my peers shall earn less than I do? Who shall earn the same? — If you put this data in relationship, you can derive a fair distribution of money from it.

3. Promoting people

Do we actually need promotions? What for? Is it just about prestige of having a different title? About having more power? About earning more money?

Promotions are inherently flawed, but to cover this topic in detail deserves another article. We actually should stop promotions altogether as they need strictly hierarchical org structures which are conflicting with self-organization, being agile, and adapting fast to context changes.

But let’s say, for whatever reason, you like your roles and titles and want to assign those to people based on some system. An annual performance review certainly is not a good system. Better let people gradually transition into a new role or position. By receiving continuous feedback from people who rely on the role somebody is transitioning into, they can learn and adapt and slowly grow into the role.

Furthermore, people are capable of filling multiple roles and in an ideal world, people would be able to shape their roles so they fit their unique skills and interests as well as the organizational needs. This is possible in companies, but not if roles and positions are rigid and defined top-down.

Lastly, we should detach money from promotions, as money is the wrong incentive for a promotion. Furthermore, we should go away from promotions as they lead to artificially bloating roles and titles so that we can always promote someone. Let’s be honest: Nobody needs the differentiation between Junior Engineer, Engineer, Senior Engineer, Staff Engineer, and Principal Engineer, VPs, Senior VPs, and CTOs. And even worse, in two companies, those titles might mean entirely different things, so they are often misleading, too.

4. Giving direction

Giving direction and individual performance reviews are two things that do not match well. Teams should have a clear purpose that is connected to the company vision, mission, and goals. This sets the direction for entire teams.

The role of leadership is to communicate high-level direction to the team. Here it can help to develop a team charter with the team together: Why does this team exist? How does the company benefit from this team? What changes for customers because of this team? — This is best figured out with the team, not dictated. This ensures buy-in and engagement.

Within the teams, peers should rely on peer-to-peer feedback and conversations to understand better how each individual can better support the team purpose.

Key Benefits of the Alternatives

Moving away from traditional performance reviews has many benefits. Here are just five that should convince you to start the journey:

1. Timely Feedback: Regular check-ins and peer feedback provide more immediate and relevant insights, allowing for quick adjustments.

2. Increased Engagement: Employees feel more invested in their roles when they receive ongoing feedback and can co-create their roles, leading to higher levels of engagement.

3. Alignment with Organizational Goals: Continuous feedback mechanisms help ensure that everyone is working towards common objectives.

4. Improved Communication: Open lines of communication enhance relationships between managers and employees, as well as among peers.

5. Reduced Administrative Burden: Compared to the cumbersome process of annual reviews, alternative methods are often more straightforward and less time-consuming.

Conclusion

The traditional performance review model is becoming increasingly antiquated. By exploring alternatives such as continuous feedback mechanisms, regular check-ins, and peer evaluations, companies can create a more dynamic, transparent, and collaborative workplace. It’s time to create a culture that values open communication, collective growth, and ongoing development. Treat people like humans, not like workers, and you will be surprised how capable and caring they are.

How “exploring the alternatives” will look in detail differs from company to company, but focusing on open conversations, effective feedback mechanisms and financial transparency are a great start.

Do you do performance reviews? How do they work for you and what would you like to change?

Want to discuss how to move away from performance reviews in your team? Schedule a free call with me. Happy to help!

But what if all this is based on the wrong assumption? What if performance reviews are actually harmful to an organization, fostering unhealthy dynamics while failing to deliver the benefits people expect? In this article, I will outline the tensions I see with performance reviews and discuss how companies can thrive perfectly well without them.

Don't get me wrong — performance reviews worked exceptionally well for me when I was still employed. They typically came with promotions and salary increases. However, what might seem great from an individual perspective can be disastrous from a systemic viewpoint.

Performance Reviews Are Often Tied to Individual Achievements

Performance reviews frequently focus on individual goals, such as leading a specific project, achieving certain metrics, or meeting personal targets. 

This emphasis on individualism can come at the expense of team or company goals, leading to a culture where personal achievements become more important than collective success. In reality, most achievements should be a team effort, and we must foster a sense of collective ownership.

I've witnessed situations where individuals take credit for achievements that were clearly the result of teamwork. A true leader is nothing without their team; a great leader cultivates more leaders. They uplift their team, guiding them to excel even in the leader's absence.

A great senior engineer spends less time coding alone and more time collaborating with junior teammates, sharing knowledge, and fostering growth. Therefore, we cannot and should not judge performance solely on individual contributions.

Performance Reviews Are Too Infrequent

How often do typical companies conduct performance reviews? Yearly? Twice a year? — High-performing teams continuously monitor and improve their performance through regular feedback and open communication. 

Designating special yearly events for performance reviews is not only too rare, but also too late to address issues that may have arisen throughout the year. Continuous feedback fosters a culture of growth and improvement, allowing teams to adapt and thrive in real-time.

Performance Reviews Are Often Subjective

The average engineering manager may not fully understand their team's performance. This observation may sound harsh, but it reflects a common reality. 

Vocal employees are frequently perceived as higher performers than their quieter counterparts, and the dynamics of the manager-report relationship can skew perceptions of performance.

To achieve a fairer approach, we need to mitigate these human biases. One alternative could involve employees nominating peers they believe had a significant impact on performance, both positively and negatively. If individuals provide examples to support their nominations, we can aggregate this data across teams or company-wide to gain a clearer picture of performance rankings, less influenced by individual relationships. 

This method also acknowledges the contributions of individuals who may not be in the spotlight but are instrumental in supporting their colleagues.

Performance-Review-Based Promotions Are Based on Flawed Assumptions

Companies that rely on performance reviews to identify promotion opportunities operate under flawed assumptions. 

1. Assumption of Accurate Assessment: The first assumption is that we can accurately assess someone's performance in their current role. Even if we have objective metrics, they rarely tell the full story and can often be manipulated. When we fill in the gaps with subjective observations, we risk introducing our biases into the evaluation process.

2. Assumption of Predictive Performance: The second assumption is that current job performance predicts future job performance. The Peter Principle suggests that people are regularly promoted to a level of incompetence, resulting in many individuals occupying roles for which they are not suited.

3. Assumption of Achievement Importance: The third assumption is that doing well in your current job matters more for getting promoted than having a genuine interest or enjoyment in a new position. In our industry, there's a trend where the top engineers are regularly moved into management roles, which are quite unfamiliar and may not be satisfying for them. Many new leaders don't have the skills they need to succeed and need proper training and guidance.

Promoting individuals into new roles presents challenges that stem from how we structure organizations. Self-organizing companies mitigate these issues by implementing more transparent and equitable compensation models, reducing the need for traditional promotions.

Adding to this, humans are multi-faceted beings, and we should not try to confine them to rigid job descriptions or roles. Instead, we should support them in discovering how to make the most positive impact within the company, aligned with their intrinsic motivations. See also my article “Don’t motivate people” on the importance of intrinsic vs. extrinsic motivation.

Promotions play a significant role in pyramid-shaped organizations, leading many individuals at the bottom to compete for scarce positions higher up. This competition creates an unhealthy company climate, separating company goals from individual aspirations.

Conclusion

In conclusion, while performance reviews are the go-to-approach in many organizations, their effectiveness should be questioned. 

They can undermine teamwork, promote unhealthy competition, and lead to subjective assessments that do not accurately reflect an individual's contributions. 

By exploring alternative approaches — such as continuous feedback, peer evaluations, and self-organizing structures — we can foster a healthier, more collaborative workplace.

It’s time to rethink our reliance on performance reviews and embrace methods that truly support individual and collective growth. Let’s start the conversation about how we can create a more positive and productive work environment for everyone.

In my next article, I will go more into the details of what we can do instead of traditional performance reviews.

Want to have a chat about how you can move away from performance reviews in your organization? — Schedule a free call with me here.

Traditional companies typically rely on strict hierarchies to make up for missing suitable processes and structures. This usually leads to a lack of flexibility, causing the organization to become ineffective over time. In contrast, self-organizing companies have a “flat” structure, in the sense that no one person has total control over another's future. However, they still need to adjust their structures, processes, and goals quickly and effectively.

In this article, I will write about how this can be done through a tension-based proposal process, that I have seen in effect in companies in person myself. I also know that many companies following Holacracyhave established similar processes. 

The “Problem Statement”

In most organizations, we have astonishing people with diverse backgrounds, experiences, and ideas. Those people work in different areas of the organization on different topics and in relationship with different people. Everybody can provide a unique perspective and can see things others can’t.

We don’t want to miss great ideas, whether they relate to product development or improving our work methods and organization. It’s essential to find ways to share and implement these ideas, regardless of where they come from. Traditional hierarchical companies often struggle with this, as good ideas at lower levels must first climb to the C-level before they can be considered. This means many companies miss out on the valuable insights their employees have about challenges and potential solutions. Additionally, they frequently face difficulties in implementing change, as changes are usually imposed from the top without buy-in from those impacted. Good news: All of this can be solved.

In addition to struggling to bring attention to issues, companies also need to make decisions quickly to adapt to changes and new information. However, long communication routes and a fear of making decisions in many organizations hinder their ability to respond effectively to changing circumstances.

Apart from the inability of driving change quickly, we also want to avoid cargo cult (“Let’s use the Spotify model”). Every company is different, and it is highly unlikely that something working somewhere else will just work in the same way for your context (side note: Even Spotify isn’t using the Spotify Model). To solve this, we must ensure that we are not just changing for the sake of change and because others do it, but because we sense a tension with our current way of doing things.

“Tension,” as used in Holacracy, is a neutral term that simply means the feeling of a specific gap between current reality and a sensed potential – Brian J. Robertson in “Holacracy”

Tensions are beneficial because they indicate that something could be improved. They signal that change might be necessary. Unfortunately, in many organizations, people lack the tools or processes to transform these tensions into constructive actions. As a result, humans internalize these tensions, leading to frustration, apathy, or burnout.

How a Tension-based Proposal Process Solves this

First and foremost, a tension-based proposal process gives everyone a tool to express their tension around something within the organization (a process, a structure, a cultural aspect, …). This amplifies that something potentially prevents the company from functioning in the best possible way.

Second, it gives the person sensing the tension a way to propose a solution and make some risk analysis (Can the proposed change cause damage? Can the change be reversed? Is the cost of the change bigger than the cost of doing nothing? …)

Third, it allows everybody in the company to understand the tension, even if they have not experienced it. It also enables everybody to ask clarifying questions about the tension and the proposed solution.

Fourth, it allows people to object if they believe the proposed solution causes damage. Objection ≠ “I don’t like it.” — Objection = “This will harm us and here is why: …”

The point of the process is to enable continuous improvement. — One tension at a time. If done correctly, this increases people’s willingness to try a change even if they don’t think it is the best solution, as they can always raise another tensions, as soon as they experience it.

Finally, change is not always needed to resolve a tension. Just by framing and raising a tension and by sharing it with others, we might receive more information that can lead to a resolution.

An extremely nice side effect of this process is that tensions and their solutions are documented, and people later can understand why the company works the way it does.

How the Process Works

When people feel a tension, they start by writing it down. They might choose to first discuss it with a trusted person or a caring circle to better understand it and find the right change to propose. A good practice is to involve people that will be affected by the change in the caring circle. This helps to hear different ideas early on and incorporate them into a proposed solution.

Through the writing, the tension-feeling person can understand and frame their tension better. Furthermore, the written tension gives others the context needed to understand and judge the proposal. They can then write down the suggested change as a proposal. They can also think through potential risks and mitigations. A good proposal also answers the following questions:

• Could it do harm?

• Is it reversible?

• What is the cost of doing nothing? What is the cost of the change?

• What risks exist, and how can those be mitigated?

Once the proposal is ready, it is shared with the organization or group impacted by the proposal. People are given an appropriate amount of time to read the proposal and react to it. People can ask understanding questions and bring up aspects the proposer might not have considered. The proposer can then improve the proposal.

If people already raise objections, those can be discussed and integrated into the proposal. If an objection is valid, it might lead to a change of the proposal to resolve the objection.

Finally, the proposer sets a date at which the proposal will become effective (default-to-yes) unless an objection comes up. If people do not have any objections, the proposal will become effective and everybody starts working according to the proposed change.

How to Introduce the Process and Make it Stick

As with every change, it is important to help people understand the “Why” behind it. Again: What is the tension addressed by introducing this new process?

Introduce the process, show the benefits and give examples. Lead by example and use the process for organizational changes of all kind.

Avoid top-down decision-making in the traditional way, as this will confuse people about when the tension-based process can be used and which decision-making freedoms they have. Trust the process. You can always raise an objection if you see a potentially harmful change.

Make sure to read proposals and provide feedback. Ensure that only real objections prevent a proposal from going through.

Coach people with tensions. Do not solve their problems or write a proposal for them but encourage and coach them to process their tensions using the new process.

Implement a centralized digital platform (like Notion) where employees can log and process their tensions. This log should be accessible to all, allowing for transparency and collective awareness. Create a standardized template for proposals that includes sections for describing the tension, proposed solutions, risk analysis, and feedback.

Include training on the tension processing process as part of the onboarding program for new employees. This will help instill the importance of this practice from the beginning.

Define and communicate the channels through which employees can raise tensions and receive updates on proposals. Ensure that these channels are user-friendly and accessible.

Common Pitfalls (How to make this fail)

1. Seeking consensus: A frequent mistake in any change process is trying to achieve consensus. This approach can be inefficient, frustrating, and sometimes unfeasible. People don’t have to agree with the proposed change, but unless they have a valid objection, they should accept it. After all, the tension being addressed isn’t theirs. If they feel a tension after the change, they can always create a new proposal.

2. Resorting to old habits: If decisions are made using the traditional top-down approach, it will confuse people and erode their trust in the new system. It will be unclear which decisions come from the top and which follow the tension-based process. Leaders should also address their tensions through the proposal process, just like everyone else.

3. Overcomplicating the process: If the tension processing steps are too complex or bureaucratic, employees may become discouraged from participating. Ensure that the process is straightforward and user-friendly.

4. Inadequate follow-up: Failing to follow up on tensions or proposals can lead to frustration and disengagement. It’s essential to communicate outcomes and next steps clearly after a proposal is discussed.

5. Neglecting context: Failing to consider the specific context of the organization when processing tensions can lead to inappropriate or ineffective solutions. Encourage context-sensitive discussions.

Conclusion

Adopting a tension-based proposal process needs time and continuous reinforcement. But once people got used to this process, it is the most liberating, fair, and efficient approach to organizational tension processing I know.

It gives everybody a voice and the ability to drive organizational change, and thus enables every human to co-create an organization that serves its purpose in the best possible way.

If you have questions about this topic or how to implement such a process in your organization, I invite you to schedule a free call with me to discuss this further.

My answer, of course, depends on the context, but always starts with a warning: You cannot and should not motivate people.

When people think about motivating people, they usually think about external rewards: Bonuses, promotions, words of affirmation, more interesting projects, …

All of this might work short-term but will harm the relationships of your employees with their work long-term.

If you dangle a carrot in front of peoples faces, you don't motivate them to walk your way, but to reach the carrot. The problem is: once the carrot is reached, you need to dangle a tastier one in front of their face for continued progress.

And this is true even (or maybe, especially) for people who could have a high intrinsic motivation to achieve the goals, otherwise.

Extrinsic vs. Intrinsic Motivation

Intrinsic motivation refers to engaging in an activity for its own sake, driven by internal rewards such as personal satisfaction, curiosity, or a sense of accomplishment. When individuals are intrinsically motivated, they find joy in the work itself, leading to deeper engagement and creativity. For example, an employee who loves problem-solving may feel motivated to tackle a challenging project simply because it excites them and allows them to develop their skills.

Extrinsic motivation, on the other hand, involves performing an activity to earn external rewards or avoid negative consequences. This can include bonuses, promotions, recognition, or even the fear of punishment. While extrinsic motivators can be effective in the short term, they often fail to sustain long-term engagement. A classic example is an employee who works extra hours to earn a bonus; once the bonus is received, their motivation may vanish, leading to a drop in productivity.

Extrinsic motivation does not work

Bonuses, promotions and other benefits are extrinsic motivation. The issue is: Extrinsic motivation does not work. At least not long-term.

First, those extrinsic motivators are typically difficult to connect with company goals and thus motivate people to do something different from what would be good for the company. See my article “Bonuses are bad – change my mind”.

Second, humans are weird. Subconsciously, when we get rewarded for achieving a goal, we conclude that the goal itself isn’t worthy to be achieved. Otherwise, no extra motivation would be needed.

Thus, when leaders use extrinsic motivators to encourage people to achieve a goal, they harm the relationships of their people to this goal. In consequence, even more extrinsic motivation is needed. A vicious cycle.

To learn more about this dynamic, I recommend the outstanding book “Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise and Other Bribes” by Alfie Kohn.

Successful leadership connects intrinsic motivation to the job to be done

People cannot be motivated. Their motivation can be awakened. Once you manage to connect their intrinsic motivation with your goals, everybody wins. This is what leadership means: Inspire people to pursue a goal and help them understand why it is a worthy one.

This requires a strong relationship with the people around you. Talk openly about their motivators. What is important to them? What do they enjoy doing? How do they spend their free-time?

Understand what drives people and where they are intrinsically motivated. Find a connection between that and the work. Work should be the strategy to satisfy the underlying needs and interests. 

Here are some questions that you can use to get to know people better and get an idea of their intrinsic motivation:

• What do you enjoy? What are your hobbies? What excites you?

• Why does it excite you? Why do you enjoy it?

• What aspect of it excites you in particular?

• Why is this important to you?

• Which part of your work (if any), gets closest to that?

• How can we make work more like that?

Asking the questions increases the opportunity to connect work and intrinsic motivation. The connection can happen in the what, the how and the why. The more connection points we can find between a person's intrinsic motivation and the work, the better.

Occasionally, the connection can happen by telling a different story. If somebody is motivated to create a better world and the company is working on something in that direction, make that connection obvious. How will the world be better when your company achieves its vision?

Sometimes, the connection can happen by changing responsibilities. If someone enjoys riddles and tasks they really need to wrap their head around, they might shine more in debugging than in writing documentation. Somebody else might enjoy explaining complex matters in simple terms, or just have a passion for documenting things. That person might enjoy documentation more than being caught in a chaotic incident meeting trying to figure out what is wrong.

Purpose drives intrinsic motivation

In many companies, people's work is completely disconnected from the companies' purpose/mission/vision. Often the reason is that those are unclear, and you cannot be connected to a vision that isn’t clear.

This is why we usually include large parts of the employees in vision & strategy workshops. The process of co-creating those helps to understand and memorize them and also to identify with them. After all, the vision now isn’t a random statement by somebody else but something WE came up with.

With a clear purpose, it is much easier to connect everybody’s work with it. Given that the purpose is something the majority of employees supports and that is related to their ideals, purpose, or goals, the intrinsic motivation comes from alone.

Combine that with giving autonomy to pursue the goals and do everything necessary to make the vision come reality, and you will find that people are basically unstoppable. (Note: “necessary” includes “reshaping the organization” as rigid hierarchies are likely to kill intrinsic motivation again as they usually stand in the way of achieving goals efficiently)

To further support intrinsic motivation, give people space to build relationships with each other, have a sense of community and collaborate as they see fit. A strong feeling of belonging is a strong motivator for most people because of how our ancestors survived in the past by being part of clans and larger groups. Belonging brings safety, and safety is crucial for high performance.

Don’t confuse intrinsic and extrinsic motivation

Sometimes the lines between intrinsic and extrinsic motivation can become blurry, and it is common to see people use external motivators without being aware of it.

With the definitions from the beginning in mind, it should be easy to see, why bonuses, gamification, promotions, the fear of loosing a job or position and any form of recognition are extrinsic motivation.

That said, we can still recognize outstanding work, but it should be something surprising that comes after the job is done. Not as something that is promised upfront or known to exist. Acknowledgement and celebration of achievements after the work is done can have a positive effect. An “Employee of the month program”, on the other hand, can create a very unhealthy team dynamic.

Conclusion

If you are looking to motivate your team, it is important to understand that relying on external rewards like bonuses and promotions typically does more harm than good. Instead of trying to motivate your people, focus on helping them discover what inspires them from within. By building genuine relationships, taking the time to understand what excites each person, and connecting their work to a clear and meaningful purpose, you can create an environment where everyone feels engaged and driven by their passions.

Motivation is manifold. Each person is unique, and what inspires one person might not resonate with another. By asking questions and encouraging open conversations, you can uncover the intrinsic motivators that matter to your team. This approach not only increases job satisfaction but also nurtures a sense of ownership and commitment to the goals you are working toward together.

When your team members find personal meaning in their work and feel a sense of belonging, they become more than just employees chasing rewards. They transform into passionate contributors who genuinely care about the success of the organization. By prioritizing intrinsic motivation over external incentives, you can create a positive workplace culture that encourages creativity, innovation, and sustained high performance. 

Success does not come from dangling carrots, but from empowering each person to pursue their passions and connect their work to a larger purpose.

What are your thoughts on this topic? Share them in the comments. 👇

I see asynchronous code reviews as a last resort to ensure that every piece of code is reviewed by at least two team members. When code is seen by at least two people, this promotes knowledge sharing, shared ownership, and reduces the risk of mistakes. The ideal approach for immediate feedback is pair or team programming. However, when this isn't possible due to asynchronous work hours or too much work in progress, many teams rely on code reviews. When done correctly, code reviews can also be highly valuable.

Over the years, several times I got feedback from my colleagues that they really appreciated my reviews, and occasionally, they were surprised how I could catch certain issues just by reviewing the code. One colleague once admitted that they would even look into my reviews for other people because those usually provided a good learning opportunity. Thus, I thought I will write down how I approach code reviews.

The issue with asynchronous code reviews

But let’s start with a brief excursion into the reasons against asynchronous code reviews, as I would opt for a pairing session in the majority of cases. The following list is by no means complete:

1. Asynchronous code reviews slow down feedback. People often wait hours or even days for their code to be reviewed, which stops them from finishing their work and increases tasks in progress. When the review finally arrives, it interrupts their current work and requires them to switch focus again.

2. Communication in asynchronous code reviews is less effective because written messages aren't as clear as spoken conversations. This can cause reviewers to point out fewer issues, lowering the review's quality. This problem is worse when the code to be reviewed (like a pull request) is large.

3. People know the code better when they pair on it compared to when they just review it. Thus, I would argue that the knowledge sharing is more effective in a pairing session.

4. True collaboration (pairing/teaming) is the best team building and relationship building exercise that exists. None of the teams where we collaborated a lot needed artificial team building exercises or off-sites to have a strong team-bond and healthy team dynamic. You won’t get this benefit from code reviews.

How to give (better) asynchronous code reviews

If you really can’t pair/team up on writing the code and thus giving synchronous code reviews while switching roles frequently, you can only try to make your code reviews as valuable as possible. Here are some things to consider:

1. DO THEM AS TIMELY AS POSSIBLE.

Waiting for a code review halts progress and disrupts workflow. A task isn't complete until it is deployed and working in production. Small changes often wait hours or days for someone to review and merge them. Much of the lead time is spent "waiting for review," which is inefficient and lowers team performance. It is also frustrating.

I try to start code reviews as soon as I know one is open. The sooner I can give feedback, the better. (The best is still synchronous feedback during pair-programming.) The main goal for the team is to get things out to customers quickly. Being busy with many separate tasks slows this down.

2. HAVE EXPECTATIONS.

When reviewing code or reading code in general, it is beneficial to have an expectation about what the code should do and how I would do it myself. Doing so will likely trigger surprises that keep me alert, which in turn leads to learning opportunities for myself, but also makes it easier to find things the author might have missed.

Therefore, before starting a code review, I think about the desired outcome, the implementation and common pitfalls upfront.

3. CHECK TESTS FIRST.

Once I have thought about what I expect from the PR, I give attention to the tests and see if they cover my expectations or if some of my expectations are not covered by tests.

Tests shall be a good documentation of what to expect and should therefore be comparable with my expectations. If they are difficult to read, I would start suggesting ways to improve readability. If they are missing, this is a red flag or at least justifies extra caution while proceeding with the review.

4. BE CURIOUS.

Often, there is no right or wrong, and code reviews are no exception. Despite having expectations, stay open-minded to learn something new. When something surprises me in a code review, I ask for the reasoning / the intent behind it. Chances are high that the author has thought about the code they were writing before.

5. SEE CODE REVIEWS AS A LEARNING OPPORTUNITY.

When speaking with engineers about their reasons for giving code reviews, many reasons come up, but “to learn” is rarely one of them. I think, this is a missed opportunity. When we are attentive and open to alternative solutions and willing to ask questions from curiosity to better understand a solution, there is a massive opportunity to learn something while reviewing code.

6. EXPLAIN THE WHY.

When you share a different approach or criticize an approach, try to explain the why and why you think it is better. I would often share links to articles or documentation that helps the author to understand the background.

Don't be too strict on things that don't really matter. Some aspects are a matter of personal preference. It's fine to mention your preferred way, but also respect the author's style and approach. As a team, you might have established guidelines. Formatting guidelines are best enforced by an auto formatter in a pre-commit hook, not by a reviewer.

7. ALSO HIGHLIGHT POSITIVE ASPECTS.

Sometimes we are so focussed on finding mistakes and improvement opportunities that we fail to highlight also the great things and aspects that surprise us positively.

8. DON’T BLOCK PRS WITH UNCRITICAL COMMENTS.

Occasionally, you might want to point something out without requiring immediate action. Clearly communicate whether your comments are blocking or non-blocking. If you only have "FYI" remarks and the code is ready to be merged, approve the PR right away. This saves time and avoids the need for a re-review. For example, comments like "This would look nicer with a static import" pose minimal risk and aren't worth delaying the merge.

9. JUMP ON CALLS EARLY.

Sometimes, issues are more critical. A change might risk breaking the production system or violate the desired architecture (architecture tests can help here). This is a valuable learning opportunity. The author likely wrote the code in the best way they knew how. If they violated architectural guidelines, it means those guidelines were either not clearly communicated, not understood, or the author doesn't know how to achieve their goal while adhering to the architecture rules.

Especially when things are a bit more complicated or comments turn to a back-and-forth discussion, I like to jump on a call and discuss the matter in person. This provides a much more efficient space to understand each other and learn from each other. It even provides an opportunity to pair-program on the needed change to ensure that we understand each other and can even ask more questions as they come up.

I would also jump on a call when I find a PR too big to handle or believe that it is completely missing the point and would lead me to add 1000 comments. A quick call and walk-through can help me to understand the PR better and give better comments. Or we can use the call to restructure the PR so that we have multiple cohesive and smaller PRs, which again serves as a good learning opportunity.

Conclusion

While synchronous methods like pair- or team-programming offer the most immediate and effective feedback, asynchronous code reviews remain valuable when real-time collaboration isn't feasible. By addressing common pitfalls such as delayed feedback and impaired communication, and by adopting practices like timely reviews, setting clear expectations, and fostering a learning environment, asynchronous code reviews can be significantly improved.

Emphasizing positive aspects, clearly communicating the importance of feedback, and initiating direct discussions when necessary can further enhance the quality and efficiency of code reviews. Ultimately, the goal is to ensure high code quality, promote knowledge sharing, and maintain a collaborative team dynamic, even when working asynchronously.

This is, in a nutshell, how I do code reviews. How do you do them? Share your approach in the comments!

While shifting meetings and having meeting-free days are common suggestions, they are too obvious to be helpful. This article will delve into some surprising and actionable ideas to enhance focus and flow in your software organization.

Why Focus and Flow Matter

Great developer productivity stems from the ability to enter and maintain a flow state, which requires both focus (working without distractions) and flow (completing work without impediments). 

In an environment where focus is absent, distractions are plenty. Teams struggle to get anything done, and the simplest tasks span weeks or months. Often, we see engineers busy with meetings or switching tasks every hour. The reason for this is usually that they can’t work on one task from beginning to end due to dependencies on other people or teams. Consequently, value delivery takes significantly longer than it needs to. Furthermore, people are frequently stressed as they are constantly busy without finishing meaningful work.

8 Practical Steps to Improve Focus and Flow

1. COLLABORATE MORE

Team focus and team flow are the real deal.

• Team/Pair Focus: Have teams or pairs focus on one task at a time. This ensures that someone is always available to help and hold the context if someone gets distracted. When team members work together on the same task, they can immediately address any issues that arise, reducing the need for context switching.

• Minimize Distractions: Collaboration reduces the number of people who can potentially distract team members. When everyone is working together, there are fewer interruptions from outside the team, allowing for a more focused work environment.

• Avoid Async Reviews: These can cause context switches. Instead, opt for real-time collaboration to keep everyone in the same context. Team/pair programming, for example, can help catch issues early and maintain a continuous flow of work.

2. DOCUMENT WISELY

Good documentation helps the author and the reader.

• Reduce Friction: Good documentation helps find answers quickly, reducing the need to ask others and causing fewer distractions. Comprehensive documentation serves as a reliable reference, minimizing the need for frequent interruptions to seek clarifications.

• Increase Understanding: Creating documentation helps team members think things through and understand the task better. The process of documenting forces a more profound understanding of the subject, which can lead to better decision-making.

• Enable Async Communication: Good documentation allows for asynchronous communication, reducing interruptions. This means that team members can access the information they require without having to wait for someone to be available to answer their questions.

3. FORM CROSS-FUNCTIONAL VALUE-STREAM-ALIGNED TEAMS

Create self-organizing, self-sustaining and autonomous teams.

• Increase Expertise: Having a diverse set of skills within the team reduces the need to collaborate with people outside the team. The increased internal expertise allows the team to handle a wider range of tasks independently.

• Shared Goal: Ensure the team has a shared mission or purpose to work towards. This aligns everyone’s efforts and reduces conflicts. A clear team charter or mission statement can provide this focus.

• True Team Definition: A team should work together towards the same goal, not just be a group of individuals reporting to the same manager. This means fostering a sense of collective responsibility and collaboration.

• Eliminate Handovers: Align teams, so there are no handovers between understanding customer needs and shipping product increments. This reduces the need for coordination and speeds up value delivery and feedback. A seamless workflow from ideation to deployment can significantly enhance productivity.

• Immediate Feedback: Knowing where ideas come from helps in getting quick feedback, reducing delays and distractions. Direct communication with stakeholders can provide this immediate feedback.

• Customer Proximity: Bring teams closer to customers through sessions with sales reps and customers. This helps understand needs better and enhances the quality of feedback. Regular interactions with customers provide valuable insights and ensure that the team is aligned with customer needs.

4. SHIFT FEEDBACK LEFT

Fast feedback loops prevent context switching.

• Early Feedback: The earlier the team receives feedback (i.e., from the CI/CD pipeline or local builds), the quicker they can act on it, reducing distractions, context switches and making feedback feel more pleasant. Early feedback helps in identifying and resolving issues before they escalate.

• Relationship Building: If immediate feedback isn’t possible and the team needs to wait for a slow job to finish for feedback, don’t context switch to another task. — Use the waiting time for personal relationship building. This can also spark ideas on how to reduce wait times. Building strong relationships within the team can improve collaboration and feeling of belonging.

5. COMMUNICATE CLEAR AND GUIDING MISSION AND VISION

Alignment on the goal enables autonomy.

• Unified Direction: A clear mission and vision ensure everyone understands why the company and team exist, providing a common goal to guide decisions and actions. This shared understanding can align efforts and reduce conflicts.

• Reduce Conflicts: A shared North Star reduces conflicts due to contradictory goals and increases autonomy, improving decision quality. When everyone is working towards the same goal, it’s easier to resolve disagreements and make decisions that benefit the team as a whole.

6. ESTABLISH REASONABLE WIP LIMITS

Reasonable = Much lower than you think!

• Encourage Collaboration: Set work-in-progress (WIP) limits lower than the number of team members to encourage collaboration and create space for focused work. Limiting WIP ensures that team members are not overwhelmed and can concentrate on completing tasks.

• Reduce Busyness: Lower WIP limits, reduce busyness and increase focus. This helps in maintaining a steady workflow and prevents the team from getting bogged down with too many tasks at once.

• Queue Management: Make visible where value is stuck in the value stream and work to remove those queues. This can significantly reduce development times. Identifying and addressing bottlenecks can streamline the workflow and enhance productivity.

7. TREAT MEETINGS AS SIGNALS

Every meeting is a potential systemic issue screaming for help.

• Identify Inefficiencies: Meetings often indicate structural or procedural inefficiencies. Use them as signals to improve the system for better focus and flow. If meetings are frequent and lengthy, it may be a sign that there are underlying issues that need to be addressed.

• Collaborate, Don’t Inform: Use meetings for collaboration, not just information sharing. Allow attendees to decide the agenda and use of time. This ensures that meetings are productive and relevant to all participants.

• Feedback on Meetings: Collect candid feedback on the value of meetings and how they can be improved at the end. Regularly assessing the effectiveness of meetings can help in making them more efficient and valuable.

8. BATCHING MEETINGS

Yes, finally, that one obvious suggestion. ;-)

• Minimize Interruptions: Batch meetings into one afternoon or day with breaks in between. This allows the rest of the time to be dedicated to focused, productive work. Concentrating meetings into a specific time slot can help in maintaining flow during the rest of the day. Remember that every interruption robs focus for at least 23 additional minutes.

• Connect and Align: Use the batched meeting time to connect and align with team members. This isn’t the time to be productive in terms of task completion but can support overall productivity by ensuring everyone is on the same page.

Conclusion

Focus and flow are essential requirements for high-performing teams.

I have successfully implemented these approaches with teams from companies big and small across various domains. They work incredibly well. The key is to create an environment where distractions are minimized, and the team can work together seamlessly towards common goals. This enhances productivity and increases job satisfaction, team engagement, motivation, and product quality. What more do you need?

Want to improve focus, flow, and productivity in your company?

Drop me a message if you would like some guidance or someone who implements the most impactful changes with you and your teams.

Starting with Kanban, the most obvious board structure is "To Do", "In Progress", "Done". This is potentially the simplest Kanban board and one often seen in examples. Teams would typically break down larger initiatives, projects, epics, <you name it> into smaller tasks that move independently over the board. The original epic would either live in "To Do" or "In Progress" while there are still sub-task not in "Done".

The teams then measure their productivity or effectiveness utilizing Kanban metrics on the sub-task level.

This is a problem.

What do we want from Kanban?

Kanban is great to visualize the work, discover bottlenecks, optimize flow and prevent us from starting too many things by setting reasonable WIP limits. Ideally, with this overview we can measure flow metrics such as cycle time, WIP, throughput and the work item age.

The problem starts, when we measure those metrics on the individual sub-task and not on the customer-focused initiatives: We can have excellent scores in all of those metrics while starting 5 initiatives in parallel and not having significant business impact with any of them.

Tasks can flow fast from left to right for weeks without us delivering anything meaningful to customers. We feel super productive without creating actual business value.

As we all know, starting multiple initiatives in parallel sounds like the right thing to do from a utilization perspective: Keeping people busy, maximizing utilization. The cost: Delayed delivery on all initiatives.

The goal shall never be maximizing utilization. The goal shall be delivering business value fast. And these two things contradict each other.

THE TRAGEDY OF HIGH UTILIZATION (SHORT VERSION)

While it is obvious to all of us, that we do not want to have our servers run at 100% CPU load, 100% RAM usage, or 100% disk usage, people frequently make this mistake when it comes to people. The results are even more harmful than with computer resources. Not only does the delivery of business value take exponentially much longer, it also is a sure path to burnout. Developing software products is a complex endeavor full of surprise, and estimating correctly when something will be done is almost impossible. It gets even more impossible when there is more than one thing.

How do we define work?

With a task-centered perspective, a work item clearly is a single Kanban card, a sub-task, moving from left to right. Something that keeps us busy and fills our day. This is, what we are paid for. Right?

Take a step back from software and think about other areas of lean product development. What is a work item in an assembly line for cars? The seats that need to be built into the cars? The process of building the seats into the car? The wheels that need to be attached? Of course not. The work item is the car. It does not matter how fast you are attaching wheels. What matters is, how fast the car is ready to be delivered to the customer. Attaching wheels is a process step – a column on the Kanban board.

Therefore, in software product development, a work item as a product increment. A product increment starts as a customer problem/idea that will be discussed and understood. Then, we form a hypothesis how to evolve the product to solve this problem. This leads us to shaping, scoping, designing, implementing, and testing the product increment. Finally, we deliver the product increment.

So when is a product increment done? It is done earliest, when it is delivered to the customer. — Bonus points, when you visualize also the work items delivered on which you still need to collect feedback to validate your initial hypothesis.

How the Kanban board might look like

In reality, the Kanban board should often have more than three columns to visualize the process steps in the value stream. While having just three columns for those product increment initiatives gives you clarity on how many initiatives are currently ongoing, it is difficult to see if something is stuck and in which stage.

The Kanban board should reflect the stages in the value-stream in which a valuable something can be. This will look differently for a sales team in contrast to a product team. The later might something like have:

1. New 

2. Idea understood and expressed

3. Product Increment defined

4. Design / Concept

5. Under Development (Includes things like coding, reviewing, testing, …)

6. Ready for Delivery (You might not have this, if you do continuous deployments)

7. Waiting for customer feedback (Basically means: need to check data and customer feedback and see if the hypothesis was correct or if we need to iterate on the solution, which would be a new product increment based on a refined hypothesis)

8. Done

9. Discarded (you might not have this column, but just archive or delete items that you won't consider worthy of being implemented)

If you have a board with columns like this and have cards that reflect the product increments and not just busy-work, great. This shall give you a lot of transparency on where you stand with each of the initiatives. Now, what about WIP limits?

Setting reasonable WIP limits

Depending on the level on which you define WIP limits, different numbers are reasonable. In my opinion, the number of initiatives/product increments in progress should be smaller than the number of team members.

The reason is simple: We want people to collaborate and focus on the most important thing, not being busy individually. If everybody has their initiative, people will have a hard time helping each other out, as this means switching to an entirely different context and interrupting progress on whatever valuable initiative they are currently working on.

The ideal WIP limit for initiatives within a team likely is 1. While this sounds extrem, imagine how fast you could complete an initiative if everybody on the team had time to work on it. Initiatives that take weeks or months might be completed within days.

Now, you might want to set the limit to 2, when you consider what is "work in progress".

Look at the example above. Which columns are WIP? I would argue, that at least columns 3–6 count toward that limit. In these stages, someone has already invested time in this work item. If it is stuck in the pipeline, this means, someone invested time (the company's money) in this increment without it generating any customer value. Inventory is expensive. Even worse: Priorities might change and that work item is stuck in the pipeline forever, distracting people from what actually matters.

Now, a WIP limit on the level of product increments of 1-2 per team sounds extreme, and it is. Just take a moment to reflect on the alternative: People are spread thin across different initiatives, already needing time for meetings to clarify, scope, and discuss whatever comes next while simultaneously supporting peers on "their" initiatives. And then there is also unplanned work: incidents, bugs or that "quick" request from customer success. — All of that is work, too. It is work beyond the value increments, that needs to be done, regardless of how “busy” you already are.

WHAT ABOUT "TECHNICAL INITIATIVES"?

A common challenge for startups is the need to go fast. Often, this comes with cutting corners and taking on technical debt. Paying this back can take significant time. The same is true for renovation projects, such as changing from an old unmaintained framework to a new maintained one. 

I recommend tracking big maintenance/renovation projects like initiatives. They are an investment in the product/company future, and they can take significant amounts of time. Ideally, if a team realizes it has to do some big tech initiative, such as migrating from an older unmaintained framework to a new one, it focusses on this endeavor to get it done quickly. Therefore, such initiatives should count toward the previously mentioned WIP.

WIP LIMITS ON THE TASK LEVEL

An initiative can have many tasks. And for tasks, the classic layout "To Do", "In Progress", "Done" might be a great fit. Furthermore, not everything is an initiative. Some things just come up and need to be done but are more a rather small task that must not be forgotten and eventually done. Tasks can be anything from sketching out an implementation over updating a dependency to fixing an urgent bug.

For tasks, WIP limits are important, too. Ideally, the majority of tasks worked on come from initiatives creating customer value. This might look different for companies who neglected technical investments for the sake of moving fast, for too long, or for companies who do not have a certain level of automation.

For example, an operations team might have an influx of tasks for permission requests from other teams. Those tasks go away once the operations team established a tool for automated permission rollout (this would be an initiative).

On the task level, I recommend a WIP limit smaller than the team size, too. This acts as a forcing function for collaboration and facilitates knowledge exchange and learning and increases resilience.

Practical Implications

While most tools allow showing both, initiatives/projects/epics and tasks on the same board, I don't think this is the best approach in most cases. Tasks have another flow than initiatives. We need to visualize work on different levels: The day-to-day task work and the bigger-picture initiatives. The board used daily should contain all those tasks/parts of the current initiative and everything else important for the team right now. Bugs, "quick" requests, … — those things should be prioritized in the "To Do" column. 

The question should be: Is this bug or request so urgent, that we should delay the ongoing initiative? Often, the answer is "no", given that many initiatives, once they get focus, will be done in a week or two (otherwise, find smaller increments).

This board should not contain subtasks of future initiatives, as the team should refrain from working on them until the previous initiative is out of the WIP area. One reason for this is focus on the current initiative, another reason is, that priorities might change fast and all the planning and scoping work then go to waste and might sit in the backlog for years collecting dust (until I come in, and we delete your backlog ;-))

LET YOUR TO DO COLUMN RUN EMPTY

You are doing it right when the To Do column frequently runs empty. This is a sign that more work can be taken on and scoped. It is a sign of maturity, when the team can frequently decide consciously what the next things to work on, are. It helps the team to step back and think about value rather being busy moving tasks from left to right. It enables business agility: Whenever an initiative is finished, the team(s) can work on whatever is the most important thing for the business right now, instead of working on what the business thought would be most important 3 months ago.

Conversely, if the number of work items seems to increase continuously, it indicates that you either need more people/teams or need to resolve productivity and performance bottlenecks (start with the latter).

DIFFERENT BOARDS FOR DIFFERENT VIEWS

In practice, it makes sense to have different boards with different columns for different abstraction levels.

Many companies find it useful to have a board for product planning, product roadmap, ideas, or however you might want to call it. This is the place where (sometimes) abstract and unspecific ideas can come in. This board visualizes the flow from ideas to product increments, the engineering teams work on, and onward to the customer.

Not every idea might end up being worked on. Multiple ideas might be grouped and result in a single product increment. Some ideas might be split into multiple product increments. How to prioritize ideas and from which ideas to derive product increments from and which ideas to discard requires communication with all stakeholders involved. Typically, these are sales, customer success, product, and engineering.

The perspective which this group of people needs is very high level:

• Which ideas do exist?

• Which ideas are important for us? (customer value, business value, relevance in the grande picture of the product strategy and vision (you have those, RIGHT?!?))

• What do those ideas mean? (Shared understanding of use cases/problems to be solved, efforts needed to make it work, priorities)

• Which ideas have made it into a product increment?

• Where in the lifecycle is the product increment? (Examples: Scoping, Implementation, Collecting customer feedback, Done)

• Which team is currently working on this increment?

A board like this should not have all the implementation details potentially needed for the day-to-day implementation work. Once teams start working on an increment, they might want to create tasks and subtasks on their board for this initiative (see above).

I recommend that teams specify just as many tasks as they need to work on the increment, without planning everything in detail for the future. The dynamic that can be observed is: The more a team collaborates, the less specific and detailed do tasks need to be, and the less time has to be invested in upfront planning.

Whenever an increment is considered “done” on the product planning board, there should be no tasks left on the board of the engineering team. 

If there are tasks left that are not relevant enough for the increment to be considered done, this implies, that too much upfront planning was done. I recommend deleting those tasks. Otherwise, they will live in your backlog forever, and they will consume your time every time you stumble over them or discuss them with your team.

Here is a visual example:

• When things come in, they are in new. This can be a mix of ideas, problems, feature requests, …

• A group consisting of people from product, engineering, Sales and CS collaborates to ensure that the new items are understood by everyone and that the shared understanding is documented. If the idea is already considered irrelevant at this point, it goes to “Discarded”. Otherwise, the card is move to the second column.

• The relationship between product increment and ideas is not always 1-to-1. An idea might spawn multiple product increments, or multiple ideas are combined into one product increment. Once the group has found a viable product increment that they consider valuable to customers (or the business), they create the card in “Product increment defined”.

• At this point, I would consider it already as “work in progress” as it only makes sense to specify product increments, when we want to work on them. The next step involves making a technical concept and breaking the increment down into actionable tasks for the team to work on. This is also the point, when the “Up Next” column in the teams Kanban board starts to fill up (this is done by members from the product development team)

• Once the team actually starts working on the increment, it moves to “Under Development” to show stakeholders from Sales and CS that the team actively works on the increment.

• As soon as the increment is ready to be delivered, it moves to “Ready for Delivery” – Here we are talking about “making it accessible to customers”. Technically speaking, this can be when something is deployed but still behind a feature flag. This stage allows Customer Success to prepare the rollout (i.e., inform customers) and Sales to use the increment in sales demos.

• Once the product increment is rolled out to all customers, the card moves into “Waiting for customer feedback”. — This is to make sure that the increment is not forgotten as soon as it is rolled out, but that product managers and customer success take care to collect feedback (through metrics, surveys, and interviews) and monitor the adoption/usage of the increment.

Note that the team might want to deliver something earlier to internal customers or early adopters to get feedback while still in development. This reduces risk and increases the probability of a successful adoption later on.

Remark: This is an example of how the boards can look and who is involved in which stage. Depending on the process in your company and the product you are developing, your boards might look entirely different.

Conclusion

A Kanban board is a great tool for visualizing processes. What matters is that companies visualize their value streams and not just their busy work. A simple Kanban board can hold both, value increments and busy work. A more specific value-stream aligned board won’t hold busy work very well and will make you feel the tension when trying to put busy work on it. The board is not a good fit.

That said, there are of course things that are more on the side of busy work rather than on the side of product increments. Bugs, incidents, occasional requests, technical updates and refactorings. Be mindful which of them you allow bypassing the product board. All of those will reduce the flow of product increments through the value stream. They are distractions from furthering the product.

Those things need to be visualized, too. The team needs to have them on their board, and stakeholders have to understand how much distraction there is and how to improve the situation. It can help to tag cards on the team board with their origin (product initiative, bug, customer request, …) to understand, where attention and time go.

I am curious: What do your boards look like? What kinds of boards do you have? Please share how you do it in the comments below.

I invite you.

Are visualizing the work and optimizing the flow of value challenges in your organization? — Drop a comment below, and I will reach out to you to schedule a free session. Together, we will identify the root causes and define next steps to improve the situation for your teams.

I hate the state of software companies in 2024 – most of them hierarchical, most of them nonsensical, following questionable management theory from 1885.

I hate that leaders act as if we could measure productivity in knowledge work correctly.

I hate that estimates are still a thing.

I hate that we invent all kinds of pointless proxy metrics for a feeling of control and the comfort of false certainty.

I hate that leaders define RTO policies in the name of culture, when they actually mean control.

I hate that most software engineers haven’t experienced working in a great team. Leading to more leaders not knowing what good looks like.

I hate that people work mostly alone and that "team" seems to mean "group of people reporting to the same manager"

I hate that we see people as manageable and exchangeable resources.

I hate that we came to believe that an artificial balance between work and life is something to strive for, when work should be how we express ourselves in life.

I hate that a two handovers in a deployment process seem to be considered normal.

I hate that we have certifications for roles in frameworks that lead to keeping the framework around, even if there are better alternatives.

I hate that we have the arrogance to believe that the complexity of creating something new, something unique, or something disruptive, can be solved by just adding another framework (technical or organizational).

I hate that we have built companies where seniors are writing all the code, leaving no space for juniors to grow and learn.

I hate that we see hierarchical leadership as the only option and don’t see the contradiction between agile, lean and this type of organizing.

I hate that we created systems in which we needed career paths and that we created competition around scarce positions.

I hate that we have product people (whatever their title) who see their role in filling backlogs and keeping teams busy, rather than figuring out how to create actual value.

I hate that people without any clue about technology believe we can ignore all that because we have AI now. And I hate, that those people seem to ignore the drastic consequences of AI for society.

I hate, that we still have a lack of diversity in tech and that this limits how we see the world and what solutions we build.

I hate that how we give capital to startups today harms their ability to make customer-centric decisions.

I hate that we build technologies because they are possible, not because they are good for humanity.

And I hate that improving the situation "doesn’t work here."

I hate a lot of things about the state of software organizations in 2024. But here is what I love:

I love those who believe in the good in other people. Those who do their best to improve this situation.

I love those who are passionate about what they do and crave making the world a better place.

I love those who are a testament to the fact that people are good, and who help the skeptical belief in this.

I love those who improve things despite the regulations, the traditions and the "we have always done it like this."

I love those who get that discovering better ways of working might imply not sticking to the same framework but continuous evolution.

I love the possibilities that we have through technology.

I love what even small teams can achieve, when they work together.

I love that we have the education to reflect on the social impact of our work and that many of us have the freedom to decide, how we want to influence the world.

I love that we have the knowledge to build great software products in great ways.

I love that we can work from anywhere and still be connected with our colleagues.

I love that there are already a few companies working differently. Those who demonstrate, that it is possible.

I love that there is research on self-organization and the benefits of employee experience for people, businesses, and customers.

I love that courageous leaders start companies that work against common business "wisdom."

I love, that I have the privilege to be a part of this and to think about all of this.

I love that I can learn new things every day.

I love that there are others with whom I can collaborate on this and exchange ideas.

I love that there are platforms where we can share our thoughts openly.

I love that more and more people see the shortcomings of the current system, and I love that many are looking for alternatives.

I love that we have everything needed to create a better world. – But I can just hope, that we use it to create on.

Can you relate? – Let’s have a conversation about how we can drive the change toward more of what we love. ✨

The second release of “WITH TOBI” is out!

Together with Tobi Leonhardt, I am starting a small project to inspire. With our combined focus on high-performing teams & organizations and human-centric workplaces & cultures, we aim to have meaningful conversations around the topics on our minds daily. We also want to invite leaders to have those conversations with us.

In this format, we want to have short but meaningful conversations. We aim for 15 minutes per conversation and will keep them intentionally short, even though we could quickly expand for hours on each topic this series. We hope to spark AHA moments, trigger interesting thoughts and start conversations.

In this second release, we focus on growth and what this means for engineering productivity and high-performing teams.

Key Insights / Statements

A summary of the key insights and learnings we had:

• Growth does not just mean headcount: growing experience, relationships and maturity.

• Companies often grow in headcount too early. This amplifies problems. This endangers culture and effectiveness.

• A strong and visible culture is an effective filter in the hiring process.

• Energy for organizational improvement can be found in the tensions that people experience.

  • A tension is the experienced difference between how things are and how they could be.

  • Tensions are not problems. They can turn into problems, if ignored.

  • Organizations need to optimize for surfacing and processing those tensions in order to become adaptive and high-performing under changing circumstances.

Additional Resources

You find the Notion page, the Mural of this session, and more information about us and how we work here.

Continue the Conversation

• What are your thoughts on this topic?

• What do your team and your colleagues think about this topic?

→ We would love to hear your feedback! 💬👇