Pawel Brodzinski on Leadership in Technology

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

Tag: collaboration

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
Why We Want Women in Teams

One of the messages that I frequently share is that we need more women in our teams. By now I’ve faced the whole spectrum of reactions to this message, from calling me a feminist to furious attacks pointing how I discriminate women. If nothing else people are opinionated on that topic and there’s a lot of shallow, and unfair, buzz when it comes to role of women in IT.

Personally, I am guilty too. I’ve been caught off guard a few times when I simply shared the short message – “we need more women in our teams” – and didn’t properly explained the long story behind.

Collective Intelligence

The first part of the story is the one about collective intelligence. We can define the core of our jobs as solving complex problems and accomplishing complex tasks. We do that by writing code, testing it, designing it, deploying it, but the outcome is that we solved a problem for our customer. In fact, I frequently say that often the best solution doesn’t mean building something or writing code.

If we agree on problem solving frame a perfect proxy for how well we’re dealing with it is collective intelligence. Well, at least as long as we are talking about collaborative work.

Anita Woolley’s research pointed factors responsible for high collective intelligence: high empathy, evenness of communication in a group and diversity of cognitive styles. These are not things that we, as the industry, pay attention to during hiring. Another conclusion of the research is that women are typically stronger in these aspects and thus the more women in a team the higher collective intelligence.

Role of Collaboration

There are two follow up threads to that. One is that the research focused only on one aspect of work, which can be translated to collaboration. That’s not all that counts. We can have a team that collaborates perfectly yet doesn’t have the basic skills to accomplish a goal. Of course all the relevant factors should be balanced.

This is why at Lunar Logic, during hiring process, we verify technical competences first. This way we know that a candidate won’t be a burden for a team when they join. Once we know that somebody’s technical skills are above the bar, we focus on the more important aspects, but the first filter is: “can you do the job?”

The decision making factors are those related to the company culture and to collaboration.

Correlation and Causation

Another thread is that “more women” message is a follow up to an observation that women tend to do much better in terms of collective intelligence. I occasionally get flak for mentioning that women are more empathetic. It would typically be a story about a very empathetic man or a woman who was a real bitch and ruined the whole collaboration in a team.

My answer to that is I don’t want to hire women. I want to hire people who excel at collaboration. If I ended up choosing between empathetic man and a cold-blooded female killer it would be a no-brainer to me. I’d go with the former.

What is important though is that statistically speaking women are better if we take into consideration aforementioned aspects. It’s not like: every woman would be better than any man. It’s like: if we’ve been hiring for these traits we’d be hiring more women than men.

And that’s where a discussion often gets dense. People would imply that I say that women are genetically better in, say, collaboration. Or pretty much the opposite, they’d say that in our societies we raise women in a way that their role boils down to “good collaborators” and not “achievers.”

My answer to that is: correlation doesn’t mean causation. I never said that being a women is a cause of being empathetic and generally functioning better in a group. What I say is that there is simply correlation between the two.

The first Kanban principle says “start with what you have” and I do start with what I have. I’m not an expert in genetics and I just accept the situation we have right now and start from there.

The Best Candidate

A valid challenge for “hire more women” argument is that it may end up with positive discrimination. My point in the whole discussion is not really hire women over men. In fact, the ultimate guidance for hiring remains the same: hire the best candidate you can.

It just so happens that, once you start thinking about different contexts, the definition of “the best candidate” evolves. A set of traits and virtues of a perfect candidate would be different than what we are used to.

And suddenly we will be hiring more women. Not because they are women. Simply, because they are the best available candidates.

Such a change is not going to happen overnight. Even now at Lunar I think we are still too much biased toward technical skills. And yet our awareness and sensitivity toward what constitutes a perfect candidate is very different than it was a few years ago. That’s probably why we end up hiring fairly high percentage of women, and yet we’re not slaves to “hire women” attitude.

Finally, I’d like to thank Janice Linden-Reed for inspiration to write this post. Our chats and her challenges to my messages are exactly the kind of conversations we need to be having in this context. And Janice, being a CEO herself and working extensively with IT industry, is the perfect person to speak up on this topic.

May 12, 2015
Minimal Indispensable Feature Set

Minimal Viable Product (MVP) is such a nice idea. Let’s build something that is as small as possible and at the same time viable, which translates to “provides value and thus make sense to build it.” Two adjectives in a mix where one counterbalances the other and vice versa.

Since I currently run a web software house I hear the term MVP very frequently. Or to be precise I hear the term MVP being abused very frequently. On some occasion the viable part would be ignored. Much more frequently though the way people understand MVP has virtually nothing to do with the minimal part.

During the early discussions about products our potential clients want to build I would typically ask about a business case behind a project or an app. It’s not about what it is that someone wants to build. It’s about why it is worth building that thing in the first place.

Note, I’m not judgmental. We contributed to better or worse ideas but I don’t reserve the right to know what’s worth building and what’s not. In fact, my questions have a very different purpose. What I want to achieve is to learn the value behind the app so that we can have a meaningful discussion about stuff in a backlog.

Now, this is the part where typically I’d really like to have people read Lean Startup before they are even allowed to talk to any software shop about building their product. And then, read it once again to understand what they are reading in depth.

The reason is that most of the time I can instantly come up with a batch of work that is one third, one fifth or one tenth of what was labelled an Minimal Viable Product by a potential client and it would still validate a business hypothesis behind a product. It likely means that with a bit of effort and better understanding of the context our clients would be able to cut it down way further than that. It may mean that they’d be even able to validate the basic idea without writing any software at all.

These so called “MVPs” wouldn’t recognize a real Minimal Viable Product even if it kicked them in the butt.

A sad part is that most of the time discussion around what really is minimal is futile. While I can provide my insight and encourage to learn more about the topic an argument often boils down to “we really need to build it all because, well, we don’t believe anything short of that would work.”

The long story short, I believe that MVP is in the top 5 most abused terms in our industry. By now referring to MVP is mostly meaningless unless you ask a series of questions to understand what one means by that. We could have skipped he MVP part, have the same discussion and we’d save a little bit of time.

That’s why I believe we need another frame for discussing what the initial increment of a product is.

What I caught myself on a number of times was proposing our clients a different constraint. Let’s step aside from discussing what is minimal and what is viable. Let’s figure out which features will be the part of the product in every single, even most crazy, scenario that we can think of. And I really mean every single one of them.

What I try to achieve with this discussion is to find the set of features that is a common denominator for all the options of building the product. There’s always something like that. A core process that the app support. A basic idea that the app is built upon. An ultimate issue that the app attempts to solve.

What I don’t expect is to see the full solution, even the most basic one. It would be an MVP on its own and we’d be back to the square one. What I expect is just a bunch of bits and pieces that are required to eventually build the app.

It is neither minimal nor viable.

It is indispensable though.

There are a couple of reasons to do that. The first one is that it reframes how both parties, the client and us, think of a product. We don’t try to settle on what is viable and what is minimal. We simply go with something that we know will be useful.

The other one is that it addresses the huge challenge of building a relationship. In fact this part goes really deep. It typically starts with a question how much building something would take. Some sort of an estimate. Well, it’s another thread. I’m not fundamentally against the estimates and see value in understanding generally how much something would take. At the same time I acknowledge that humans are simply not well equipped to estimate as we can’t learn to assess stuff in abstract measures. At the end of the day though, the smaller the batch size of work the smaller the potential risk and the smaller the estimation mistake.

In other words the smaller the initial batch of work the easier it is to start working.

It is true from another perspective as well. The most important modifiers of the cost of building a product in a client-vendor scenario isn’t anything related to the product itself. It is the quality of collaboration. It’s about both parties feeling like they’re the part of the same team. It’s about short feedback loops. It’s about working together toward the goal.

Unless it is about lack of transparency, distrust, and exploiting the other party.

The tricky part here is that you don’t know where at this spectrum you are until you start working. Building the smallest possible batch of work together pretty much gives you all the knowledge you needed. Seriously, you don’t need more than just few weeks to get a good feeling where collaboration part is going.

That’s why this the idea of Minimal Indispensable Feature Set is so useful whenever more than a single party is involved in building a product.

Minimal Indispensable Feature Set is perfectly aligned with building an MVP. In fact it is a subset of an MVP. At the same time it addresses the part of the setup that goes way beyond simply defining of what product is.

We live in a world where more and more frequently the building part is outsourced to another party. Getting the collaboration right at least as critical as getting the product idea right.

December 29, 2014
Collaborative Spirit of Kanban

Sometimes Twitter is a mine where you can dig thought-provoking gems. A couple of days ago Alan Shalloway said, as a part of a heated discussion, that:

People who say Kanban isn’t about collaboration forget that one of the core practices is improve collaboratively (using models/scientific methods).

I both agree and disagree.

I mean, yes, this is true – collaborative improvements are one of Kanban principles. And yes, the word “collaboratively” is there for a reason. And triple yes, whenever you are setting up the process or improving it you work collaboratively.

At the same time I can’t agree with boiling collaboration in Kanban down to “improve collaboratively” only.

One of most canonical examples of improvement introduced by Kanban is on-demand swarming. When either a feature is blocked or we just have bottleneck resulting with full work-queue people swarm over it to get the flow, well, flowing again. I know Kanban doesn’t tell you that you should collaborate in such situations but actually introducing limited WIP results in many similar behaviors. People are helping each other. Last time I checked it counted as collaboration, but well, maybe we use different definition of collaboration.

Another, pretty typical, situation I see in Kanban teams is a result of visualization – when team members see that one of their colleagues, for whatever reasons, is coping with multiple work items, they tend to help instead of just starting another feature from backlog. Sounds like collaboration, isn’t it?

Then we have complexity of processes we try to cover with Kanban. Despite simple Kanban board we see here and there software development is usually pretty complex process. At the same time we are advised to start simple with Kanban. It means that we often come up with a board which is pretty simplified model of what we are doing. For example, usually testing/quality control stage covers both testing and bug fixing, meaning that most likely at least a couple of people work on a feature at the same time. Collaboratively. With no formal hand-offs.

And when we are at hand-offs, with Kanban we make them visible on Kanban board. We also have incentives to optimize hand-offs, both in terms of a number of them and in terms of time features spend waiting to be picked up by the next person. Fewer hand-offs mean improved collaboration as people need to cover removed formalisms (hand-offs) somehow. And believe me, they do.

We also work collaboratively whenever we are changing the process. I’m yet to meet a team which had this part of Kanban setup just enforced by someone. I’m sure there are such teams out there but, at least now, it is total minority. What more, usually these discussions are launched be team members, e.g. when they don’t know where to put an index card, which basically means that the process might need some improvements. This collective decision making process can be called collaboration I guess.

I could probably go further but, by this time, you get the point. Despite Kanban doesn’t say collaboration over processes or something alike, thanks to its rules, it really fosters everyday collaboration. Usually it is all about small things: swarming over this blocked feature, quick feedback loops with that one being tested, launching a discussion about adding a column here or changing a limit there.

Collaboration in Kanban isn’t about big words and big ideas. It is about tiny everyday actions. But please, don’t tell me that Kanban isn’t about collaboration. That’s just bullshit.

November 25, 2011