Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: communication

Conway’s Law Teaches a Grim Lesson About AI in Product Development
When I first stumbled upon Conway’s Law, it was anything but intuitive to me.

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Melvin E. Conway

Why would an organizational structure of a company have anything to do with software architecture? After all, there are whole bodies of knowledge covering high- and low-level concepts of software development. Aren’t these things properly planned and executed?

I mean, sure, in the details, there will always be a mess. However, in a grand scheme of things, the high-level design should be far more controllable than the law suggests.

In retrospect, Conway’s Law is one of those things that, once you’ve seen it, you can’t unsee it.

Conway’s Law and Spotify Model

Whenever Conway’s Law emerges in a discussion, my favorite example is Spotify. I’m a user since the beta. I know several people who worked there in leadership positions. Most of all, Spotify, at some point, was very vocal about their organizational approach, the so-called Spotify Model. It’s like I have enough data to connect the dots.

As popular as it was at the time, if you look at the Spotify Model, it’s hard not to see it as a glorified matrix organization. Yes, there’s more autonomy across the board, but the communication paths? They all scream “Matrix!”

What should we expect from their product design if Conway’s Law is true? My best guess is a set of features interconnected in non-obvious ways, with a common issue of lack of alignment, and a lot of local optimizations. And that’s precisely what we get.

Spotify UX

While Spotify’s codebase is not open, its UX is quite telling. By now, it’s a clutterball of misaligned ideas fighting for your attention.

Playlist sidebar, announcements, recently played, made for me, music video, related music videos, now playing… Welcome to the Spotify home screen.

From a user perspective, it’s fascinating, although not in a good way, how I struggle to find the same options that I use regularly (like, multiple times a week, for years). Managing playlists? Oh, boy. Search? Every other time, it’s in the wrong context. Inconsistencies between mobile and web? Don’t get me started.

But maybe it’s just grumpy me. Fine. I’ve just literally googled “who loves spotify ux?” and among the top results are:
Doesn’t sound like a love wave, really. It’s either one: Google reads my mind, or the UX is problematic.

All that comes from a product praised (and copied) for some product innovations, such as Discovery Weekly or Spotify Wrapped. Most definitely, not everything is wrong here. It’s just a matrix of somewhat misaligned ideas, good and bad. That isn’t really a recipe for customer delight.

By the way, did you know that Spotify has a custom seek bar for Star Wars songs that looks like a lightsaber? And you can change the looks of the specific lightsabers, no less. There could hardly be a better illustration of “a matrix of somewhat misaligned ideas, good and bad.”

Communication, Alignment, Autonomy

If you consider Conway’s Law, it’s hard not to see how Spotify UX is a precise map for the Spotify Model. Wherever communication between teams (squads, guilds, chapters, or whatever the hell they call them) was messy and faced multiple conflicting goals, so did the interconnections between features.

To make things harder, Spotify sprinkled high autonomy over their feature teams. So the matrix organization made alignment a challenge, yet decision-making was pushed down the hierarchy nonetheless.

A high-autonomy-limited-alignment setup is not a recipe for effective work. And I say that from experience. At Lunar, we walked that path. The lesson? As much as I’m a huge fan of distributed autonomy, I’d always consider alignment first.

In the late 2010s, Spotify had a few dozen relatively independent feature teams responsible for specific parts of the product. Small wonder that the “mobile playlist” team had different ideas from the “web playlist” team. Communication paths that might have fixed that were watered down by an overly complex organizational model.

By now, the engineering headcount is already in the thousands, and the team count is thus in the hundreds. Just imagine the product mess that the Spotify Model would create. No wonder they largely abandoned it.

OK, but what does it have to do with AI?

AI Product Management

Product people are encouraged almost as strongly as developers to use AI extensively. It comes as a mixed blessing. Early intensive prototyping is a viable path, and it opens up whole new avenues for validating product desirability.

LLMs make it just so easy to create extensive specifications. We can attach all the existing product descriptions as context, let AI do its own research, analyze the codebase, and more. It will produce a nice, detailed description, and the engineers will nail it.

Except we misinterpret the ease of creation for the value of the output.

A sidenote: It’s the same aspiration we had when we tried to model systems with UML diagrams, and it didn’t work either. It’s not about the tools. It’s about the iterative exploratory nature of designing software.

Still, AI can create the same illusion we followed many times before—that we can specify software upfront in detail from the outset. The output looks good. Better than ever, even. And we get it effortlessly. It’s the AI model that does the heavy lifting.

It takes some time to realize that product development doesn’t work like this. It never has. And it has nothing to do with the tools we use to create specs.

AI Kills Communication

In the past, product specifications were brief. Save maybe for some Business Analysts, no one fancied writing long forms describing all the feature details. We relied on just enough context and communication between engineers and product people.

However, now, generating detailed specifications with AI is easy and cheap. Initially, we might even verify whether the output is correct. Eventually, we’ll give up. One, often they’d be good enough. Two, LLMs are great at creating outputs that sound sensible. Three, honestly, read a 4-pager with a feature description and tell me you understood everything.

At some point, and sooner rather than later, a product manager will stop carefully verifying AI output. Soon, the developers will follow. That is, given they read the extensive specs at all in the first place. It quickly evolves into the “you give me the specs, I’ll get them built, no questions asked” kind of scenario.

The key part here is: “no questions asked.” It’s like going all the way back to the 90s, way before Agile happened. We build up to the specs, whether it makes sense or not. The only difference is that we deal with the development so much faster. Does it matter, though, when we build the wrong thing?

Conway’s Law Meets AI Product Management

The most important change happened in between the lines, though. A one-sentence-long feature description was, by definition, full of holes and required the team to discuss. A detailed specification creates the illusion that a feature has been thought through from all angles.

The former invites communication. The latter discourages it.

As we close down communication paths, Conway’s Law kicks in. We’re bound to design architectures that copy organizational communication structures.

Less peer-to-peer communication and less collaborative exploration mean a more fragmented and less coherent architecture. As each individual is treated more and more as an isolated island, so will be the code that individual develops.

The effect will affect both a technical level (think code architecture) and a product level (think UX). Give such a way of working a couple of years, and we’ll start praising Spotify for its exceptional product design in comparison.

AI Is on a Collision Course with Conway’s Law

Dev: The last feature is on staging.
PM [checks the feature out]: It doesn’t work as specified! Here’s what should be different.
Dev [checks the code, checks the specs, 2 hours have passed]: Well, actually, it works as specified. Here are the specific parts that prove my point.
PM: Oh, my Claude must have hallucinated that part.

That’s an actual conversation that I heard that inspired this article. When I consider the impact of AI on communication, the paths connecting product and engineering are most affected. Yet, similar effects emerge across the board.
- A single developer may produce more code with AI tools, so they are more independent and, even under time pressure, they don’t need to collaborate with other engineers as often. We reduce the need for communication.
- Coding agents running independently step on each other’s toes way more carelessly, creating merge conflicts and triggering rework (the worst kind of rework, actually). Operators of said agents are thus better off when they isolate their active work areas. Which means less coordination and less communication.
- The asynchronous nature of working with AI agents incentivizes the “throw over the fence” hand-offs. My agent’s output may be ready when I’m already off, but let that not stop you from doing whatever you need to do with it. Again, less human-to-human communication.
- The sheer amount of documentation we can generate on different levels automates away collaborative activities (or parts of them). Code review? Let an agent handle that. Even less communication, perchance?
If Conway’s Law holds, we may be up for a rude awakening. As an industry, we are hyped about all sorts of “my agent talks to your agent” scenarios. It’s easy to see the upside—automating away the mundane, tedious, and routine. It’s hard to see the long-term cost of deteriorating communication paths.

So, we either learn to navigate the new realities of collaboration better, or we accept that the products we use will increasingly be crap. Which one will it be?

These posts are not generated. 웃 https://okhuman.com/nf1GGg
April 29, 2026
Trust Networks as Antidote to AI Slop

This week, AWS went down, along with a quarter of the internet. It’s funny how much we rely on cloud infrastructure even for services that should natively work offline.

That is, “funny” as long as you’re not a customer of said services trying to do something important to you. I know how frustrating it was when Grammarly stopped correcting my writing during the outage, even if it’s anything but a critical service to me.

While AWS engineers were busy trying to get the services back online, the internet was busy mocking Amazon. Elon Musk’s tweet got turbo-popular, quickly getting several million pageviews and sparking buzz from Reddit to serious pundits.

Admittedly, it was spot on. No wonder it spread like wildfire. I got it as a meme, like an hour later, from a colleague. It would fit well with some of my snarky comments about AI, wouldn’t it?

However, before joining the mocking crowd, I tried to look up the source.

Don’t Trust Random Tweets

Finding the article used as a screenshot was easy enough. It was a CNBC piece on Matt Garman. Except the title didn’t say anything about how much AI-generated code AWS pushes to production.

Fair enough. Media are known to A/B test their titles to see which gets the most clicks. So I read the article, hoping to find a relevant reference. Nope. Nothing. Nil.

The article, as the title clearly suggests, is about something completely different.

I tried to google up the exact phrase. It returned only a Redit/X trail of the original “You don’t say” retort. Googling exact quotes from the CNBC article did return several links that republished the piece, but all used the original title, not the one from the smartass comment. It didn’t seem CNBC had been A/B testing the headline.

By that point, I was like, compare these two pictures. Find five differences (the bottom one is the legitimate screenshot).

Top picture from the tweet Elon Musk shared. Bottom from the actual CNBC article.

So yes, jokes on you, jokers.

Except no one cares, really. Everyone laughed, and few, if anyone, cared to check the source. Few, if anyone, cared to utter “sorry.”

Trustworthiness as the New Currency

I received Musk’s tweet as a meme from my colleagues. It went through at least two of them before landing in my Slack channel. They passed it with good intent. I mean, why would you double-check a screenshot from an article?

It’s a friggin’ screenshot, after all.

Except it’s not.

This story showcases the challenge we’re facing in the AI era. We have to raise our guard regarding what we trust. We increasingly have to assume that whatever we receive is not genuine.

It may be a meme, and we’ll have a laugh and move on. Whatever. It won’t hurt Matt Garman’s bonus. It won’t have a dent in Elon Musk’s trustworthiness (even if there were such a thing).

It may be a resume, though. A business offer. A networking invitation, recommendation, technical article, website, etc. It’s just so easy to generate any of these.

What’s more, a randomly chosen bit on the internet is already more likely to be AI-generated than created by a human. Statistically speaking, there’s a flip-of-a-coin chance that this article has been generated by an LLM.

It wasn’t, no worries. Trust me.

Well, if you know me, I probably didn’t need to ask you for a leap of faith in the originality of my writing. The reason is trustworthiness. That’s the currency we exchange here. You trust I wouldn’t throw AI slop at you.

If you landed here from a random place on the internet, well, you can’t know. That is, unless you got here via a share from someone whom you trust (at least a bit) and you extend the courtesy.

Trust in Business Dealings

The same pattern works in any professional situation. And, sadly, it is as much affected by the AI-generated flood as blogs/newsletters/articles.

When a company receives an application for an open position, it can’t know whether a candidate even applied for the job. It might have been an AI agent working on behalf of someone mass-applying to thousands of companies.

While we’re still beating a dead horse of resume-based recruitment, it’s beyond recovery. Hiring wasn’t healthy to start with, but with AI, we utterly broke it.

A way out? If someone you know (or someone known by someone you know) applies, you kinda trust it’s genuine. You will trust not only the act of applying but, most likely, extend it to the candidate’s self-assessment.

Trust is a universal hack to work around the flood of AI slop.

Outreach in a professional context? Same story. Cold outreach was broken before LLMs, but now we almost have to assume that it’s all AI agents hunting for gullible. But if someone you know made the connection, you’d listen.

Networking? Same thing. You can’t know whether a comment, post, or networking request was written by a human or a bot. OK, sometimes it’s almost obvious, but there’s a huge gray zone. In someone you trust does the intro, though? A different game.

The pattern is the same. Trust is like an antidote to all those things broken by AI slop.

Don’t We Care About Quality?

Let me get back to the stuff we read online for a moment. One argument that pops up in this context is that all we should care about is quality. It’s either good enough or not. If it is, why should we care who or what wrote it?

Fair enough. As long as consuming a bit of content is all we care about.

If I consider interacting with content in any way, it’s a different game.

With AI capabilities, we can generate almost infinitely more writing, art, music, etc. than what humans create. Some of it will be good enough, sure. I mean, ultimately, most of what humans create is mediocre, too. The bar is not that high.

There’s only one problem. We might have more stuff to consume, but we don’t have any more attention than we had.

Now, the big question. Would you rather interact with a human or a bot? If the former, then you may want to optimize the choice of what you consume accordingly.

Engageability of our creations will be an increasingly important factor. And it won’t be only a function of what kind of call to action a consumer feels after reading a piece, but also whether they trust there’s a human being on the other side.

It’s trust, again.

Trust Networks as the New Operating System

Relying solely on what we personally trust would be impractical. There are only so many people I have met and learned to trust to a reasonable degree.

Limiting my options to hiring only among them, reading only what they create, doing business only with them, etc., would be plain stupid. So how do we balance our necessarily limited trust circle with the realities of untrustworthiness boosted by AI capabilities?

Elementary. Trust networks.

If I trust Jose, and Jose trusts Martin, then I extend my trust to Martin. If our connection works and I learn that Martin trusts James, then I trust James, too. And then I extend that to James’ acquaintances, as well. And yes, that’s an actual trust chain that worked for me.

By the same token, if you trust me with my writing, you can assume that I don’t link shit in my posts. Sure, I won’t guarantee that I have never ever linked anything AI-generated. Yet I check the links and definitely don’t share AI slop intentionally.

If such a thing happened, it would have been like Musk’s “you don’t say” meme I received—passed by my colleagues with good intent.

The degree to which such a trust network spans depends on how reliably a node has worked so far. A strong connection would reinforce its subnetwork, while a failing (no longer trustworthy) node would weaken its connections.

Strong nodes would allow further connections, while weak ones would atrophy. It is essentially a case of a fitness landscape.

New Solutions Will Rely on Trust Networks

The changes we’ve made to our landscape with AI are irreversible. In one discussion I’ve had, someone suggested a no-AI subinternet.

It’s not feasible. Even if there were a way to reliably validate an internet user as a human (there isn’t), nothing would stop evil actors from copypasting AI slop semi-manually anyway.

In other words, we will have to navigate this information dumpster for the time being. To do that, we will rely on our trust networks.

Whatever new recruitment solution eventually emerges, it will employ extended trust networks. That’s what small business owners in a physical world already do. They reach out to their staff and acquaintances and ask whether they know anyone suitable for an open position.

Content creation and consumption are already evolving toward increasingly closed connections (paywalled content, Substacks, etc.), where we consciously choose what we read and from whom. Oh, and of course, the publishing platforms actively push recommendation engines.

Business connections? Same story. We will evolve to care even more about warm intros and in-person meetings.

Eventually, large parts of the internet will be an irradiated area where bots create for bots, while we will be building shelters of trustworthiness, where genuine human connection will be the currency.

Like hunters-gatherers. Like we did for millennia.

October 22, 2025
AI Has Broken Hiring
Late in 2023, at Lunar, we were preparing a recruitment process for software development internships (yup, we somehow hadn’t jumped on the “you don’t need inexperienced developers anymore” bandwagon). However, ChatGPT-generated job applications were already a concern.

Historically, we asked for small code samples as part of job applications. The goal was to filter those who knew the basics from those who just aspired to become developers eventually. Granted, it wasn’t cheat-proof, but that wasn’t the goal.

It was enough to tell the basics:
- Was it more toward a naive solution or more toward the optimal end of scale?
- Were there tests, and if so, what kind of them?
- What about readability?
Sure, you could ask a developer friend to write it down for you, but you’d eventually show a lack of competence at the later stages. Heck, we even had a candidate asking for a solution at a discussion group. But these were fairly rare cases.

Recruitment in the AI Era

So it’s late 2023, and we know the trick won’t work anymore. ChatGPT can generate a reasonable answer to any such challenge. Eventually, we decide against any coding task and simply ask to share a public GitHub repo. Little do we know, we’re way deeper in hiring in the AI era rabbit hole than we could have ever dreamed.

Sure, we understand that people will feed ChatGPT with our job ad and have it generate output. After all, as always, we provide a great deal of context about what we want to see in the applications. That makes LLM’s job easier.

We state explicitly that we seek genuine answers, and we’ll discard those blatantly generated with ChatGPT. Also, no LLM is an expert in who the candidate is, right? No LLM is an expert in me.

We’re a small company. Till that point, our record was around 90 applications for the internships. Typically, it was maybe half of that. This time, we receive almost 600.

Despite all our communication, most of them were generated by ChatGPT.

AI as the First Filter

OK, it’s no surprise. Instead of creating thoughtful and thorough answers to 4-5 questions, each taking at least a couple of paragraphs, now we can just feed an AI model of our choice, and it will produce as much text as anyone needs.

Companies response? Let’s use the same models to tell which resumes we should even read. Otherwise, it’s just too many of them.

And yes, in our case, I read each and every one of those 600 applications. Well, at least the parts. If the first paragraph has “AI-generated” painted all over it, and the question literally asked you not to generate your answers, then my job was done. I didn’t need to continue.

By the way, the next time I will do the same. However, we are oddballs. It’s now the norm for the first filter to be an AI model that decides whether to pass an application on to a human being.

In other words, the candidates generate applications with AI to pass through an AI filter.

Do you see the irony?

Just wait till someone starts putting hidden prompts in their resumes. Oh, wait, someone has definitely tried that already. I mean, if the researchers do that in a much more serious context, applicants trying their luck is an obvious bet.

Hiring Noise

Now, extrapolate that and ask: What does the endgame look like? More and more noise.

Let’s just wait till we have AI agents that automatically apply to jobs on our behalf with no human action needed whatsoever. Oh, who am I fooling? There already are plenty of startups pursuing this path.

The promise is that you will be able to send hundreds of applications in one click. That’s great! You increase your chances! Or do you?

Even if you do, it will only work for a very short time. Then everyone else will start doing the same, and suddenly every hiring company is flooded with tons upon tons of applications.

What will they do? Yup, you guessed it. They’ll pay another AI startup to automate this job away. Most likely, they already have.

We can easily increase the number of CVs flying over the internet by a factor of 10x or 100x. We still have only 1x of attention from hiring managers.

The AI Era Hiring Game

The early stages of recruitment will increasingly be like two AI models playing chess (while neither having an actual model of what a chess game is). One will try to outplay the other.

An agent playing on a candidate’s behalf will try to write an application that will pass the filters of a hiring company’s agent. The latter, in turn, will attempt to filter out as many applications as possible while still keeping a few relevant ones.

Funnily enough, I’m guessing that what will make you pass through the AI filter will not necessarily be the same things that would make you pass when a human being reads your resume.

LLMs optimize for the most likely output. So “standing out” isn’t necessarily the optimal strategy.

I remember when an applicant drew a comic book for us as their application. It sure caught our attention. I bet an AI model would dismiss it. Oh, and yes, she ended up being a fabulous candidate, and we hired her.

Which doesn’t mean drawing a comic book guarantees you a job at Lunar, of course.

If we were to believe startups operating in the recruitment niche, these days, hiring is just a game of volume. Send and/or process more resumes, and you’ll find your perfect match.

What Is a Perfect Match?

I’ve been recruiting for more than two decades. I’ve made my share of great hires. I’ve made a lot of mistakes, too. Most importantly, though, I’ve made oh, so many good enough hires who have ultimately turned out to be excellent later on.

It doesn’t matter how extensive your hiring procedures are. After a week of close collaboration, you will know about the new hire more than you could have learned throughout the whole recruitment process.

Applying for a job is like submitting an abstract for a conference’s call for proposals. A great talk description doesn’t mean that the session itself will be great. It just means it is a good abstract. And that the person who submitted it is probably good at writing abstracts. It tells little about what kind of speaker they are.

By the same token, a great resume is just that. A great resume.

What we’re doing in recruitment with AI is we set almost the whole limelight on the applications. It becomes a game of writing and analyzing CVs.

Last time I checked, no company was trying to find a person who was great at writing resumes (or more precisely: getting an AI model to generate a resume that another AI model would like).

Renaissance of Good Old Coding Interviews

It’s no surprise that physical coding interviews are gaining popularity again. Increasingly, using the AI tooling of choice will be allowed and encouraged during those. Ultimately, that’s how developers work every day.

After all, these interactions were never about knowing the answer. OK, they should never have been about the answer. They should have been about how a candidate thinks, iterates their way to a better solution, and when they deem it good enough. They should have been about working together with another professional. About all those intangibles that we don’t see unless we have an actual experience of working together.

We will see more of those. And there will be more of those happening on-site, not remotely. As a hiring person, I want to understand what part of someone’s train of thought is their creativity and what came as copypasta from ChatGPT (or Claude Code, or whatever).

There’s no shortage of code-generation capabilities. We still don’t have a substitute for judgment, though.

Why Is Hiring Broken?

So far, so good, you could say. We return to proven tools and focus on what really matters.

Yup. That is as long as we’ve cut through the noise. Next time we open internships at Lunar (and we will), I expect more than a thousand applications. Sure, many will be crap, but there will be plenty of work to figure out which will not. The effort needed to navigate the noise grows exponentially.

Under the banner of “we are improving recruitment,” we actually did a disservice to both parties that play the hiring game. Candidates complain that they send lots and lots of resumes, and they don’t even get any responses anymore. Hiring companies have to deal with a snowballing wave of applications, which means that finding a great match is nearly impossible.

That much for good intentions and improvements.

All it took was to remove the effort required to prepare an individual job application. The marginal cost of thinking of and typing those five answers in a form is gone, and thus we can spray our resumes everywhere with one click of a mouse.

Thank you, AI, for breaking the hiring for us.

(And yes, I know it’s all us, not AI.)
August 28, 2025
Radical Candor Is an Unreliable Feedback Model
Sharing good-quality feedback is one of those never-ending topics that we simply can’t get right, no matter how hard we try. We’d try things, exchange best practices, and… have the same discussion again, 2 years down the line.

I remember rolling my eyes at a trainer two decades back when they tried to teach us the feedback sandwich. In the early 2010s, Nonviolent Communication (NVC) was all over the place. Then there was a range of methods inspired by active listening. Finally, Radical Candor has arrived as a new take. A wave of fresh air was that it didn’t focus so much on the form, but more on what’s behind.

I wish I could refer to a single method, tell you “do this,” and call it a day. In fact, when challenged to share what is a better option, I don’t have a universal answer. Not much, at least, that goes beyond “it depends on the context.”

If there’s something that I found (almost) universally applicable, it is to share any feedback in a just-in-time manner. The shorter the feedback loop, the better.

Yet, of course, there is a caveat to that as well. Both parties need to have mental capabilities to be there. Sometimes, especially when hard things happen, we aren’t in a state when this is true, and we’d better defer a feedback session to a later point.

Also, it doesn’t say a thing about the form.

Radical Candor

Kim Scott’s Radical Candor is continuously one of the most frequent references when we discuss feedback. Its radicalness stems from the fact that it abandons being nice as a desired behavior and advises direct confrontation.

In short, as a person delivering feedback, we want to be in a place where we personally care about the other person and we challenge them directly. No beating around the bush, sweet words, or avoiding hard truths.

Caring personally is the key, as it builds this shared platform where we can exchange even harsh observations and they will be received openly. After all, the other person cares.

The other part—challenging directly—is more straightforward. We want to get the message through, leaving little space for misinterpretation, especially when feedback is critical.

Do We Personally Care?

Out of the two dimensions, the directness of a challenge is the easier one to manage. We can pre-prepare feedback so that it goes straight to where we want it to land. This way, we avoid ruinous empathy territory.

The caring part, though? How do we figure out whether we care enough that our message will be radical candor and not obnoxious aggression? How do we know that we are here and not there?

I’m tempted to say that we should know the answer instantly. After all, it’s our care. Who’s there to understand it better than ourselves? I’m teasing you, though.

Figuring it out in front of the mirror will often be difficult. More so in environments where care is not a critical part of organizational culture, and thus, does not come up easily.

Then, it’s not just about whether we care or not. It’s as much about whether we are able to show it.

A simple advice would be to show as much care as we reasonably can. We bring that dot up as much as we can, and things should be good, right? Oh, if only it were that simple.

Feedback: Radical Candor or Obnoxious Aggression

Some time ago, I was talking to one of our developers, who was complaining about another person. The other person had asked questions/challenging the developer about relatively sensitive matters.

Then, it struck me.

“OK, I remember myself making exactly the same remarks and asking exactly the same questions. Does it mean that I have offended you, too?” I asked, upon realizing that at least in one case, my behavior was a carbon copy of the other person’s.

From the response, I learned that I was OK. The other person was not. Why? “Because you care and [the other person] does not.”

In other words, I was in a safe space of radical candor, and the other person was way down in the obnoxious aggression territory. Except we were precisely in the same spot (same behaviors, same remarks).

The whole situation was all about how the said developer interpreted specific situations and how much goodwill and leeway they gave me and the other person.

Where Are the Lines?

The story clearly shows that we can’t fix the lines in place in the Radical Candor model. It’s not a simple chart with four quadrants, where we necessarily want to aim for the upper right corner.

The borders between the domains in the model will move. They will be blurry at times. And, by no means, will they be straight lines. If we tried to sketch a model for an actual person, it would look way messier.

There will be areas where we’re more open to a direct confrontation, and those that are way more sensitive.

Take me as an example. I tend to consider myself a person who’s open to critique (and I’ve done some radical experiments on myself on that account).

I’m fine if you question my skills, judgment, or the outcomes of my actions. Not that it’s easy, but I’m fine. But question my care? That’s a vulnerable place for me, and you’d better be less direct if that’s what you’re about to do.

To make things worse, the picture will be different depending on who is on the other side. For a person I deeply trust and respect, the green area will dominate the chart. For another, where neither trust nor respect is there, the green space may be just in a tiny upper right corner.

And if that wasn’t enough, it changes over time. We have better days and worse days. We have all other stuff to deal with, stress, personal issues, and all those things conspire to mess with the Radical Candor clean chart even more.

“Fuck off” Coming From a Place of Love

During my first weeks at Lunar Lugic, one of the youngest developers at the company told me, in front of a big group, that “I acted like a dick.” It was his reflex response to something I did, which I can’t even remember now. Nor can he.

The next day, he came to the office with a cardboard box to pack his things, ready to be fired for offending the newly hired CEO. Little did he know that:
- I was grateful for his timely remark
- I appreciated his courage
- I couldn’t care less about the form
Even if none of the common advice would suggest that, for me, it was indeed a quality bit of feedback. And the developer? He stayed with us for more than a decade. And he definitely didn’t need that cardboard box.

His challenge was direct and blunt. Did he care about me personally, though? No. Did it change anything for me? No, not really. For me, the remark has still landed well in the radical candor territory.

As a metaphor, I have some people in my life whom I can tell to fuck off. Or vice versa. And that “fuck off” would come from a place of love. The form, while harsh, is something that bothers neither me nor them. After the shots have been fired, we will laugh and hug.

I bet you have such people in your life, too. Those who have seen the best and the worst of you and decided to stick with you, nevertheless. People you trust and who trust you. You respect them, and they return the favor.

Send the same “fuck off” to a random colleague and you’re neck-deep in obnoxious aggression, no safety guardrails whatsoever. Although, in this case, it should instead be called obnoxious violence. No amount of personal care can fix this.

Radical Candor Is an Unreliable Feedback Frame

As a theoretical model, Radical Candor is neat. I really like a cross-section of personal care and direct challenge as a navigation tool in communication.

However, it creates an illusion of precision while pushing us more toward unfiltered, well, candor. This combination is harmful more frequently than just occasionally.

We can figure out (roughly, at least) where our message is on the diagram. The big problem is that we’re mostly clueless about where the lines are.

In fact, we have good insight into the borders between the domains only after we have established a pretty good relationship. Which is precisely when we need the least awareness about the exact line position.

In a typical case, we’d be shooting in the dark. Even if we understand the form and the content of feedback we share, it may lead us to a very different place than we expect. Many of the reasons why are beyond our sphere of control.

Feedback Instruction Manual

I’d be reluctant to adopt Radical Candor as my go-to feedback frame. However, if someone comes to me and says that’s what they expect, I’m happy to oblige.

That’s a good trick, by the way. As a person who wants to receive more feedback (don’t we all?), tell people how to do it in your case.

For example, I prefer criticism to praise. The latter sure feels good, but it does little in helping me improve. I’d rather feel awful for a while and get better afterwards than the reverse.

I appreciate challenges. Which doesn’t mean that I’m quick to admit I was wrong. I need time to rethink my position. So, if you want such an outcome, give me that time.

And I could go on. But this is my instruction manual. I don’t expect it to work for anyone else automatically.

The same is true when you are on the sharing end. Be explicit about your intentions. I routinely start or finish (or start and finish) giving feedback with the following remark:

The first rule of feedback applies: Do whatever the hell you want with it.

Save for some edge cases, I never have any explicit expectations for a change. When I share, it’s just this—sharing.

Being explicit about your intent will do way more than following any fancy model.

This post has been inspired by the conversation with Lynoure Braakman on Bluesky. Thank you, Lynoure, for the insightful remarks and the inspiration.
August 21, 2025
The Most Underestimated Factor in Estimation
We were preparing yet another estimate. It was a greenfield product, nothing too fancy. We used our default approach, grouped work into epic stories, and used historical data to produce a coarse-grained time estimate per epic.

We ended up with a 12-20 week bracket. Unsurprisingly, our initial hip shot would probably be close to that.

The whole process took maybe half an hour. Maybe less.

Then we fell into an AI rabbit hole. Should our estimate be lower since we will generate a good part of the code?

AI in Early-Stage Product Development

We could discuss the actual impact of AI tools in established and complex code bases. Even more interestingly, we could discuss our perceptions.

Yet, for a greenfield project and not-very-complex functionality, generating swaths of code should be easy enough.

After all, it seems that’s what cutting-edge startups do these days (emphasis mine):

The ability for AI to subsidize an otherwise heavy workload has allowed these companies to build with fewer people. For about a quarter of the current YC startups, 95% of their code was written by AI, Tan said.

Garry Tan is the CEO of Y Combinator, so most definitely a highly influential figure in the startup world. And probably quite knowledgeable of what YC startups do, let me add.

If that’s what the best do, we should follow suit, right? That’s why we got back to our initial estimate and tried to assess how much we can shave off of it, thanks to the technology.

It’s Not About Coding Speed

A lot of the early-stage work we do at Lunar Logic has already shifted to the new paradigm. The code is generated. Developers’ jobs have evolved. It’s code-review-heavy and typing-light. That is, unless you count prompting.

Yet, it’s possible to generate entire features, heck, entire apps with AI tools. So we should be faster, right? Right?

One good discussion later, we decided to stick with the original estimate nonetheless. The gist of it? It was never about coding pace.

Yes, you can generate a lot of code with a single prompt, and with enough preparations, you can make its quality decent. But AI is not doing the discovery part for you. It does not validate whether what you’re building works.

It won’t take care of the whole back-and-forth with the client whose vision is most definitely somewhat different from what they’re going to get. And even if they were able to scope their dream precisely, the First Rule of Product Development applies.

It’s a completely different experience to imagine a product and to actually interact with it. No wonder people change their minds once they roll up their sleeves and start using the thing.

The Core Cost of Product Development

After building (partially or entirely) some 200 software products at Lunar, we have enough reference points to see patterns. Here’s one.

What’s the number one reason for the increased effort needed to complete the work? Communication.

Communication and its quality.
- Insufficient clarity before starting a task triggers rework down the line.
- Waiting for feedback increases context switching and thus makes the team inefficient.
- Inadequate knowledge of the business context results in building the wrong thing.
- Lack of focus in communication is a direct waste of everyone’s time.
Should I go on? Because I totally could.

In practice, I’ve seen efforts where poor communication added as much as 100% to the workload. It went down to all the rework and inefficiencies triggered by a lack of clarity.

When such a thing happens, we might have been wrong about the actual number of features or the size of some of them, and it wouldn’t have mattered. At all. Any such mistake would be covered many times by the bad communication overhead. And then some.

AI Does Nothing to the Quality of Communication

Before we move further, a disclaimer: I understand that there are many AI tools designed around human-to-human communication.

A “helpful” Slack AI conversation summary

While there’s still work to catch up with regular technical conversations between developers, things like meeting summaries can be useful. Although I’d love to see usage data, how many of these summaries are read? Like, ever.

The communication I write about is a different beast, though. It’s not notetaking. It’s attentive listening, creative friction, and collective intelligence. It’s experience cross-pollination.

With that, AI is of little to no use. And yet, this is the critical aspect of any effective software project.

What’s more, there’s little you can know about the quality of communication before the collaboration starts. Sure, you get early signs. But you know what it really is once you start working together.

Start Small

One of the reasons why I’m a huge fan of starting collaboration with something small—like a couple of weeks kind of small—is that we learn what communication will look like.

It’s a small risk for our clients, too. After all, how much can you spend on a couple of people working for two weeks?

Once we’re past that initial rite of passage, we know how to treat any later estimates. Should we assume there’s going to be a significant communication tax? Or rather, we could shave some time here and there because we all will be rowing in the same direction.

One of our most recent clients is a case in point. Throughout the early commitment, he actively managed stakeholders on his end to avoid adding new ideas to the initial scope. He helped us keep things simple and defer improvements till we get more feedback from the actual use.

The result? Our estimate turned out to be wrong. We wrapped up the originally planned work when we were around 75% of the budget mark.

Communication quality (or lack thereof), as much as it can add a lot of work, can remove some, too. That’s why it’s the most underestimated factor in estimation (pun intended).

A post on estimation is always a chance to share our evergreen: no bullshit estimation cards. After a dozen years, I still hear how they get appreciated by teams.

If you like what you read and you’d like to keep track of new stuff, you can subscribe on the main page.
I’m also active on Bluesky and LinkedIn too, with shorter updates.
I also run the Pre-Pre-Seed Substack, where I focus on early-stage product development (and, inevitably, AI).
August 1, 2025
Respect (and How It Makes or Breaks Culture)

It seems my Milk Kanban article has made a stir. I kinda expected some backlash along the “it’s not really Kanban” lines. However, when the post hit Hacker News, I got a swath of remarks attacking it from a different angle.

The problem is, as the comments go, that someone’s job is outsourced to random colleagues. In this case, it would be Kasia (our office manager) outsourcing her job (ensuring that the office is supplied with milk) to macchiato drinkers who can’t be bothered because they have more important stuff to do.

Oh boy, where do I start?

Get Out of Your Cave

It took me quite a while to grasp that some commenters perceived managing the milk supply as a priority job for an office manager.

Yes, I know our context so much better; we’re a small company, and everyone wears multiple hats. But even in big organizations, I’d be shocked if such a matter was anyone’s top priority.

For Kasia, it’s like the 100th thing on the list of stuff she takes care of.

But again, even if we consider a generic example, it would be so easy to figure out how many things, big and small, an office manager takes care of. Then, there’s probably twice as much of stuff that’s not visible on the surface.

I mean, any developer, whose primary task is working with code that’s inherently invisible, should grok that concept.

Effectiveness versus Efficiency

However, then things only get more interesting. Even when people considered doing something to help, they’d instantly play the efficiency card.

“I can’t be bothered to let someone know that we’re running out of milk because I’m doing this important work, and me being a 10x developer requires absolute focus.”

Weird that they have time for a coffee break then, but what would I know?

But yes, having someone do 30 seconds of work, which may save someone else 10 minutes, is a sensible tradeoff. Even if the latter is paid less. Even if that half a minute wouldn’t be efficient.

That’s the most basic effectiveness versus efficiency consideration. I can be efficient as hell, but unless we, as the whole team, can reliably deliver value, it doesn’t matter.

It’s the equivalent of a developer whose coding pace would be fabulous, except there would be no one to code review or test their features. They may feel like they were being productive. The team, however, would be so.

In fact, the amount of work in progress they’d introduce would make the team less efficient. It would introduce more multitasking, more rework, and more context loss.

One has to wonder whether people showing such a lack of understanding of how the whole organization delivers value should really be valued as highly.

A narrow focus on efficiency, especially in an isolated context, is typically detrimental to the effectiveness of the whole process.

Respect

However, if anything in that discussion makes me sad, it’s the lack of respect.

“If checking the milk reserves once a day is too much of a pain for a person hired as an office manager, the person should self-reflect on his/her choice to take the job.”

And that comes from developers, a group that is notoriously crappy at filling time tracking data, even when companies rely on that data to bill clients.

However, my beef here is with a lack of respect for another job. Yes, this job is not paid as well. But I’m sure as hell that as much as an average office manager would fail miserably if they were to do software engineering, an average developer wouldn’t fare better in an office manager’s shoes.

In our case, just as an example, we’re yet to have a single foreigner who wouldn’t be deeply grateful to Kasia for help with all the formal stuff related to employment papers, work permits, etc.

In fact, it would be easier for us to lose a couple of our best engineers than to lose Kasia.

The point is, though, that it doesn’t even matter whether we really understand someone else’s job. It matters whether we respect it as a part of the bigger whole.

If not, it’s easy to boil it down to “I want my goddamn coffee to have milk, and someone better make sure I have it.” It’s easy to subordinate everyone else’s work only to whatever I might need of them. Then, of course, people won’t be willing to spend half a minute helping anyone with anything. Even if that someone makes sure that the milk is in the cupboard.

I understand that in many companies, this is the norm. People are not respected, and, in turn, they don’t respect others. They won’t be willing to help with anything that’s not explicitly their assignment.

It’s not a Milk Kanban problem. It’s a (lack of) respect problem.

Now, establishing respect as a part of organizational culture is so much harder than making the milk supply work effectively.

Wrap Up

I understand the specific context of these comments. The software industry made us, in a significant part, spoiled kids. It’s still easy to sustain a lucrative career by focusing only on one’s technical skills, individual tasks, and not much more.

I’m not necessarily surprised by how the comments disregarded the work of others, the broader context, and common goals. The sentiments, though, are not unique to software developers. I see a lot of similar attitudes in management.

And the ways of dealing with the issue will be similar. Understand others’ roles and jobs. Understand the difference between group effectiveness and individual efficiency. Most importantly, respect others and their contributions.

Milk Kanban or not, it’s easy to get enough milk in a cupboard. Building a culture of respect, on the other hand, is damn hard.

And it starts with the very people who have disproportional leverage on the organization. Yes, the same folks who tend to earn more and fill the most prestigious roles.

March 17, 2025
Can One Be Too Respectful?

Some time ago, during our weekly Lean Coffee at Lunar Logic, which is the only all hands meeting at the company, I made a disrespectful comment. It was a topic which I have a strong opinion about. A particular example that was brought to support one argument triggered a visceral reaction on my side. I said more, and more emotionally, than I should have.

A day after I asked people for feedback to understand better what had happened and how I could avoid crossing the line in future. The recurring theme was that the way I expressed myself, both the words and the form of my remark, was disrespectful to some.

That triggered another discussion some time later, and in a smaller group. It was about the meaning of being respectful and its implication of our behaviors in all sorts of situations.

We started with an assumption that being respectful means acting in a way that doesn’t hurt others intentionally. But hey, there’s the whole unintentional spectrum of effects. Luckily, we are pretty good at sharing feedback and being transparent in front of each other. This means that when someone unintentionally crosses the line it is likely that they will hear a comment referring to that behavior being disrespectful.

Going forward, with such stuff a natural desire is to be on a safe side. In other words, if I have doubts whether saying something would be disrespectful to someone I should not say that. It’s a safe choice.

And that’s exactly where we started questioning ourselves. Doesn’t our aspiration to be respectful affect how we act in less obvious situations? Doesn’t it mean that we restrain critique, harsh words, or confrontation even when we believe that they would otherwise be justified? Doesn’t we restrain ourselves from being authentic?

As a matter of fact, there can be two different sources of such a restraint. First, someone may be worried that criticism or confrontation itself would be received as disrespectful. After all, we are subjective; we may have opposite points of view and we can only control how we express our thoughts, not how they are received by the other party. We may do as much as we can to talk and behave in a respectful way but ultimately we can’t control how our attitude and behavior will be interpreted.

Second, and more importantly, most of us has neither enough skill nor practice to be able to react in such a respectful way contextually. Even if we could succeed given that we prepare, e.g. when sharing difficult feedback, we would fail to act similarly when caught off guard, e.g. in an unexpected discussion about a topic we have a strong opinion about. And I don’t use it as an excuse. I make a simple observation in the spirit of starting with what we have.

Now, if being respectful is our guiding principle we may choose not to speak up, rather than risk hurting someone. That would mean that we suppress conflict, feedback and idea cross-pollination. That would mean that we suppress our development both as individuals and as an organization.

The question we were staring at was: can we be too respectful?

Can we bring respect to the level when it is not justifiable anymore? Can being respectful yield unwanted outcome?

Intuitively my answer was negative. And yet I couldn’t discard the argument as a whole since I’ve experienced the dilemma myself.

The thing is that respect is a nuanced thing. The same behavior may be perceived as respectful by one person and as disrespectful by someone else. The same behavior may be perceived either as respectful or as disrespectful by the same person depending on whose behavior we put under scrutiny. The context matters. The group setup matters. The mood matters. And the list goes on and on.

In a way, we can’t design a set of behavior that would be universally respectful. Well, not unless we are really,really far on the safe side. This, as we already established, would have some unwanted outcomes.

And yet one of these catchy phrases I picked from Stephen Parry kept my mind working.

Showing respect for people does not mean you have to like them, agree with their views, or fail to challenge any half-baked reasoning they may have.

My thoughts were that we might have been using “respect” in overly broad way, like a wall shield rather than a buckler. However, I couldn’t wrap my head around something that would provide some guidance where the line should be. After all, Stephen’s remark focuses on what respect is not and not on what it is.

Then I came across the following passage from Ray Dalio:

Make sure people give more consideration to others than they demand for themselves.

It is more inconsiderate to prevent people from exercising their rights because you are offended by them than it is for them to do whatever it is what offends you. That said, it is inconsiderate not to weigh the impact of one’s actions on others, so we expect people to use sensible judgment and not doing obviously offensive things.

This principle, in a neat way, connects the dots in both directions and through that it addresses the risk of being “overly respectful” through suppressing oneself. It creates responsibility on each party involved in an interaction.

A party that is about to do something that may potentially be disrespectful is bound to use sensible judgement and assess whether such a behavior can be commonly perceived as offensive.

The other party, on the other hand, takes responsibility of using “the respect shield” sparingly, as if it was a buckler protecting the most sensitive areas and not a wall shield covering from literally everything.

This way we create some sort of a middle ground when it comes to respect. We don’t call out all behaviors that can potentially be perceived as disrespectful. We don’t even call out some that touch us personally, assuming good intentions and acknowledging that people have different standards. What we gain thanks to that is an environment where there is a space for more contributions from everyone.

There’s another consequence. Such a notion of respect, which accepts more behaviors, means that when someone calls “disrespectful” it is a strong signal that the line has been crossed. After all we may assume that such a call was considerate and took into account that suppressing someone else without a good reason is disrespectful too.

Of course, maintaining the balance doesn’t come for free. It requires consideration. On one hand there’s a risk of extending that middle ground of consent too far. It would happen when we start accepting behaviors that are hurtful. On the other hand there’s a risk of shrinking that space too much. It would happen when we give less and less slack to others when they act out.

The principle, however, provides us with a pretty good reference point: give others more consideration that you expect for yourself. That’s how we can avoid being both disrespectful as well as suppressing ourselves in a fear of being overly respectful.

Should I know this principle I wouldn’t have said as much in the situation that kicked off this whole thinking process. Yet still I would still make my point strongly, even at the risk of other party feeling attacked by the strong statement. And that would probably have been the best possible outcome.

June 14, 2018
On Feedback (Again)

I’ve heard that question quite a few times after I shared my feedback with somebody: “What am I supposed to do with such feedback?”

The question may imply that feedback e.g. wasn’t “actionable” or something. Anyway, I have an answer for that. It goes:

“Whatever the hell you want.”

Yup. Exactly that. In fact this is precisely what I’d love you to do.

As the opposite to: getting defensive, explaining yourself, finding excuses, bringing other interpretations, and so on and so forth.

Feedback is not an attack. You don’t need to defend yourself. It isn’t an interrogation either. You don’t need to explain yourself. And most of all it isn’t a goddamn appraisal. You don’t need to maximize the score.

It is feedback. I’m sharing some observations and opinions that somehow relate to your work, actions, behaviors, attitude, etc.

I don’t intend to change you. I want to provide you with more information so that your decisions about your further course of action are informed better. You can disagree with the part or the whole of the message you get. You can interpret it in a vastly different way. You can confront that with other feedback that is contrary to mine. That is all just perfect. You can ignore it altogether and I’m still fine with that.

Remember? Whatever the hell you want.

The reason is I know it is subjective. No matter how much I try to make it factual it is always about interpreting facts. And I don’t try to make it purely factual. In fact, the system in knowledge work is built of people and interactions between these people. How objective can “facts” about interpersonal relationships be? Is there even an objective truth there? Or is it rather a combination of interpretations that can be more or less aligned one with the other?

So no, I’m not trying to convince you that my point is even valid. It’s how I perceive specific situation and how I feel. Oh, it isn’t factual, someone would say. Well, the fact is that I perceive and I feel so and so. Do you want to discuss with such a fact? Didn’t think so.

I am well aware that my perceptions and my feelings aren’t universal truths. That’s why it is you who decide what to do with the feedback or whether to do anything at all.

There is the other part of the story. I sometimes receive feedback and I’m like “Thank you. I’m not going to change that.” What I see as a reaction is that someone is either discouraged or even pissed off with my reaction.

I mean, they did expect me to comply with what they shared with me. I don’t differentiate here feedback on work I do from feedback on my behaviors. It’s just, for whatever reasons, I decide that I don’t want to change that specific thing.

That doesn’t make me any less grateful for feedback I got by the way.

It’s just that now we turned the tables. Now it’s: Whatever the hell I want.

If you want to make me compliant with whatever just make it explicit. At least we’ll have common understanding.

Feedback’s role, the way I perceive it, is not compliance. It is providing information about one’s behaviors, actions and attitudes and their impact. It is, as its name suggests, about feeding one back with information, not about changing one or making them doing what somebody else want them to do.

If you give me feedback with a clear intention to change me or even worse to make me do what you want you are likely to end up being disappointed.

It will happen despite the fact that I treat that feedback as factual and fair. It is factual since fact is that you think and feel whatever you think and feel. It is fair for the very same reason.

At the same time it is subjective. Objective feedback, as long as it touches interactions between people, is a mirage. Or an oxymoron. Stop pursuing objectivity. To make it clear: it doesn’t make such feedback any less valuable.

Once we understand that it enables the whole new level of discussing feedback both ways.

Ultimately it’s: “I share that with you. Do whatever the hell you want with this.”

And: “Thank you for sharing. I will do whatever the hell I want with this, indeed.”

Only then it truly is valuable feedback.

January 26, 2015
Personal Ritual Dissent

If I got a dollar each time I heard someone mentioning that they’d like to get more feedback I would be filthy rich by now. Heck, if I got a dollar each time I personally said that I would still got a decent sum. Most of us do want and like to get feedback. Most of us would love to get more of that.

There’s obviously one thing to consider, which is what kind of feedback and received in what context is most useful for us. I’ve heard a lot of theories on that. One example is that we should always focus on positive or supportive feedback as people would improve their weaknesses subconsciously while they’re working on their strengths. Another is infamous feedback sandwich, which tells that each critical bit should but in the middle of two supportive ones. There are dozens of these.

On one hand there’s a bit of truth in each. On the other I call bullshit.

I don’t believe there’s a single, universal way of delivering and / or receiving feedback that works in majority of cases. Personally, while I like to hear positive feedback as it makes me feel good, I really learn when I get critical feedback. In fact, it doesn’t even have to be very constructive or factual feedback; I typically can make much sense out of non-constructive opinions too. And I don’t give a damn whether you add a sandwich to the mix.

There are better ways of delivering feedback when we think about an individual context, but there is a universal answer in a general case. This means that the most useful feedback should be adjusted to the person who receives it. A nice thing is that we can tweak the situation so we get what works for us.

If you learn from feedback in a similar way that I do, meaning that critical feedback is what makes you change, the following part is for you.

I learned about the idea of ritual dissent some time ago. Back then I didn’t even know that it is Dave Snowden who should be attributed for creating it. Anyway, the basic idea is to create a situation where a group tears an idea apart looking for all the potential risks or holes. After a spokesperson presents an idea while everyone else remains silent, there’s a part when everyone dissents the idea while a spokesperson remains silent.

There may be two goals in doing that. One is obviously improving the idea itself by making it risk-proof. The other part is that ritual dissent can be treated as a listening exercise. It’s not that easy to remain silent when someone tears your idea apart. At the same time this is what differentiates it from a futile discussion full of personal opinions.

So here’s an idea: if you look for critical feedback you can use the same pattern in a personal context.

No, it’s not a theoretical idea. I’ve done that.

It hurt. A freaking lot.

And I got more of what I wanted in half an hour than over the course of past year.

And it was awesome. Once emotions wore out, that is.

The thing is that adopting ritual dissent in personal context is, well, very personal. I was asking to be criticized. In fact, not-critical feedback was forbidden. No matter how much I learn from critical feedback it was nothing pleasant.

I would even consider that idea as “don’t try that at home” one unless one has self-awareness in terms of how they’re going to react for such critique. Having a psychologist around when doing that wouldn’t be a bad idea.

There are a couple things that make it work but two are essential. One is trust. I don’t say that everyone needs to fully trust a person being dissed. What is full trust anyway? However, there has be a decent level of trust so that anything that gets said won’t be used again anyone in any way. It may make the whole thing a bit tricky especially for managers or leaders where some sort of power relationship is involved.

At the same time there’s a lot of followership. Once a few people who feel safe start dissenting others join. Especially when they see that a dissented person doesn’t break the rules and keeps the mouth shut.

Another thing that makes personal ritual dissent work is listening, which is an inherent part of the exercise. It is a double-edged sword. On one hand the dissed person remains silent so the whole thing doesn’t turn into futile discussion. On the other the silence creates the pressure on the group. Someone eventually has to speak up even if it means going out of their comfort zone.

An interesting thing is that it’s nothing pleasant on either end. The exercise, which we run mid-day, was basically a killjoy. At the same time it spurred a lot of spin-off discussions afterwards, which is a reason why I wouldn’t do it at the very end of a day.

The best part is that getting critical feedback is not the ultimate value of the exercise. Since it creates a lot of tension and moves people out of the comfort zones it breaks some mental barriers that people had, thus makes sharing feedback later way easier.

After all sharing one critical opinion is nowhere close to dissing someone collectively for half an hour in a row.

Finally, some of feedback won’t be really addressed to the person who asked for a personal ritual dissent. It may be formulated in a way as it was so, but the real addressee would be somewhere else in a room and hopefully they’d get it too.

So if feeling like shit for (at least) a few hours is a price you’re willing to pay for a ton of valuable feedback, this is an idea for you. Would you dare?

April 9, 2014
Better Standups

I never fancied the standard standup schema. I mean I see value in sharing what the team did yesterday what the team is going to do today and what are the problems the team has.

Except these questions aren’t answered on a typical standup.

The first problem is that we answer what specific individuals have done and will do. In any but smallest teams it’s the wrong focus to have. I mean if there are two or three of us it’s very likely that such updates are meaningful. With a couple more people we gradually lose track, and eventually interest, in what exactly is happening in the rest of the team.

At the same we should be focusing on what is important for the team which may be something no one mentions because for example the biggest pain point is on a plate of someone who is absent or overwhelmed with other stuff that just doesn’t allow them to focus on the real problem.

The second problem is that very rarely someone really answers to anything by first two questions, namely the issues part is often omitted. I like tweaking the third question, for example to something that Liz Keogh proposes: ”what I would rather be doing.” It helps only a little bit though as it’s almost as easy to avoid this question as the original one.

The third problem is that with a bigger team a standup becomes just long and boring, and whenever a couple of people exchange a few sentences about any specific bit of work it shuts down almost all the rest of the team instantly.

A very typical change I introduce is a standup around a board, be it a task board, a Kanban board or what have you.

Then the discussion is mostly around important stuff that is happening right now and is visualized on the board. A typical pattern is: blockers first, expedite items second, stalled items third and then all the rest. I covered more elaborate version of this approach some time ago.

Such an approach means that not everyone, every single day speaks up. But whenever anyone has a problem or is just trying to solve an issue too long there’s definitely an update from them on the way.

Then, there’s always a call for action regarding important stuff, even if it just so happens that a default person for that item is unavailable.

This means that standups around a board encourage collective ownership of work.

In fact, there are way more call for action situations as this form of standup basically focuses on solving issues. This often means helping each other, taking over bits of work from others, etc. Whenever someone has hard time coping with all the stuff that waits for them they usually get an instant help.

This kind of a standup is also shorter than a classic one. After all you don’t mention all the boring stuff that just goes as planned – everyone can see that on the board, so what’s the point anyway?

It also is an occasion to catch all the inconsistencies on the board so it serves another purpose too. You don’t get that from a classic standup.

I would also point that this approach does very good job in terms of keeping work in progress low. It simply changes the dynamics of the discussion toward everything that is in progress from a team perspective instead of work started by individuals. The latter doesn’t take into account all the waiting queues.

Finally, it scales up pretty well. You can run such a standup with a dozen or more people and it still fits nicely 15 minute slot. It’s not rare when you need only one third of that even with such a big team.

The impact of changing the standup pattern is almost instant. All in all, it makes standups more valuable for the team. Try this approach, especially when you struggle with the current one right now.

April 20, 2013