Pawel Brodzinski on Leadership in Technology

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

Tag: problem solving

  • Why Collective Intelligence Beats Individual Intelligence

    As long-term readers likely know I am a big fan of the idea of collective intelligence and big proponent of optimizing teams toward high collective intelligence.

    First, what is collective intelligence? The easiest way of explaining that is through the comparison to individual intelligence (IQ). While IQ tests differ in type the pattern is similar: we ask an individual to solve a set of complex problems; the better they perform the higher their IQ is.

    By the same token, we can measure intelligence of teams through measuring how well a group solves a series of complex problems.

    There are a few very interesting findings in the original research on collective intelligence. It all starts with an observation that collective intelligence beats the crap out of individual intelligence. In highly collectively intelligent teams’ solutions provided by a group were systematically significantly better than solutions offered by any individual, including the smartest person in the room. However, even in teams with low collective intelligence the group solutions were on par with the best option provided by an individual.

    It totally makes sense when we think of it. No matter how smart the solution provided by an individual is it most likely can be improved through clues and suggestions provided by others. Either directly or indirectly. And it doesn’t matter whether the others are even smarter. The thing that matters is that they think differently.

    This theme is portrayed well in some pop-cultural productions. In Sherlock series the protagonist surprisingly frequently refers to his sidekick—John Watson—as not too clever or even dumb. On even more occasions Sherlock stresses that he needs Dr. Watson to inspire his superior mind. It’s not that Watson is smarter than Holmes. It’s that together they are smarter than Holmes alone, even given his prodigious mind.

    The same pattern has been exploited in House M.D. series, where the team’s effort was consistently beating individual effort. It was so even if the final solution was facilitated mostly through the brilliance of the main character.

    As a matter of fact, collective intelligence in play is one of those things that you can’t unsee once you’ve seen it. Like the other day, when I was sharing the idea of a workshop with one of my colleagues and I mentioned one feature I’d love to add to the app I was going to use during the workshop. The problem was that we explored an idea to add that feature before and, because of some old architectural decisions, adding the feature was no easy feat. Thus, we gave up. My colleague listened to my complaints and asked why we wouldn’t just add a simple and dirty hack just for the sake of the workshop. I was so immersed with the whole context of how hard it was to do it properly that the idea wouldn’t even cross my mind, no matter how obvious it might sound in retrospect.

    And it wasn’t even a context of a persistent team; merely an ad-hoc discussion in a random group. Think, how much more we contribute in a more permanent setup—in a team which shares the same context on a daily basis.

    The interesting follow-up to the observation that collective intelligence is supreme is that collective intelligence doesn’t depend on individual intelligence. As a matter of fact, there’s no correlation between the two. In other words, hiring all the smartasses doesn’t mean they’d constitute a team of high collective intelligence.

    It is likely better to support a brilliant mind with folks who aren’t nearly as eloquent but provide another, diverse, point of view that to get more of the brilliance. What’s more a team built out of people of average intelligence can be better off than a bunch of smart folks gathered together.

    It is because collective intelligence—the brilliance of a group—isn’t fueled by smarts but by collaboration. Two critical factors for high collective intelligence is social perceptiveness and evenness of communication. The former is awareness of others, empathy, and unselfish willingness to act for the good of others. The latter is creating a space for everyone to speak up and facilitating the discussions so that all are involved roughly equally. Neither of these attributes directly taps into individual intelligence.

    That’s, by the way, where pop-cultural references fall short. Neither Holmes nor House care about the collaborative aspect of work of their teams and both make a virtue out their utter lack of empathy. It means that their teams are of low collective intelligence. I can’t help but thinking how much they could have achieved had they been optimized more toward collective intelligence.

    Most of our industry fall in the very same trap when hiring. Tremendous part of our recruitment processes is optimized toward validating individual skills following a subconscious belief that this is what’s going to make teams successful.

    As Dan Kahneman observes in his classic Thinking Fast and Slow, if our brain can’t easily answer to a difficult question it subconsciously substitutes the question with a similar one which is easy to and treats the answer to the latter as if it was the answer to the former. In this context we may be substituting a difficult question about how a candidate would perform in a team with much simpler one about how they would perform individually. The problem is that the assessment of a candidate may be very different depending on which question we answered.

    If we truly want to optimize our teams for good collaboration we need to focus on the aspects that drive collective intelligence. We need to focus on character traits that are not that easy to observe, and yet they prove to be critical for teams’ long-term success, such as perceptiveness, awareness, empathy, compassion and respect. Ironically, such a team will outsmart one built around smarts and wits.

  • Pitfalls of Kanban Series: Abusing WIP Limits

    This is another problem that comes in different colors. It’s either simple acceptation of WIP limits violation, no matter how commonly it happens, or setting WIP limits so high that a team never gets even close.

    Now, I don’t say that violating WIP limits should be forbidden at all. Pretty far from that. I just say that if it is a common thing it basically means that you have no limits at all. The same is with too loose WIP limits – it means no limits at all. It’s always a matter of balance: when and why you accept to violate WIP limits.

    I point this issue high on my list as basically not using WIP limits means that you voluntarily resign from the biggest gain you can get out of introducing Kanban – the rate of improvements and changes you introduce in the team is way slower. It is so because WIP limits are a mechanism that incentivize people to change their behavior (they would normally do one thing but they can’t as it would mean violating WIP limit so they do another). Without changing behaviors most changes are quickly rolled back to what people know and feel comfortable with.

    When you start thinking about the issue it may be a very complex one and as such may be approached from different directions. One thing which is pretty obvious: make abusing WIP limits painful. I don’t mean here physically painful of course, but add enough hassle that people would think twice before doing it.

    A neat trick I used was that every time someone wanted to violate WIP limit they had to organize a meeting with a team and tell everyone why they’re doing so. First, organizing a meeting, even an ad-hoc one, takes some time which you may use to rethink whether this is really needed. Second, you want to have pretty damn good reason to share as everyone will like to know why you’re breaking the rule. Actually, if you could come up with good argument you probably had a point in violating a limit anyway. You can use other similar methods as well, but basically the goal would be the same – to make abusing limits reasonably uncomfortable.

    Different approach will be needed to deal with unreasonably high WIP limits. A thing that may come handy in such case is measuring WIP over a period of time. It is an interesting observation but some teams believe that they actually have more WIP than they really do. In such case once you’ve measured your work in progress you shouldn’t be scared of limits. Even more, your initial decisions on WIP limits will be informed.

    Another idea is to reduce WIP limits periodically to see what will happen. Eventually the team would find their sweet spots, where limits are tight enough so that they’re incentivized to improve but loose enough that the inconvenience of having WIP limits is acceptable. It is like playing ball flow game, but on the real work done in a real team.

    Check the other pitfalls of Kanban as well.

    Advertisement: Infragistics® NetAdvantage® for Windows Forms provides developers with flexible, advanced controls to rapidly build high-fidelity Windows Forms application user interfaces “IN” style with the look and feel of Microsoft® Office® 2010 and Windows® 7. It Features every control developers need to deliver superior user experiences with stability, performance and robustness.

     

  • Pitfalls of Kanban Series: Kanban Board Not Up To Date

    This is something I see very often and at least in a couple of flavors. The problem can be a team member who haven’t really bought the whole thing and see little value in updating all these stickies on the board every time something changes. It can be more a whole team’s thing – Kanban implementation has its leader, or a champion, and when they have a day off suddenly the board starts to deteriorate as people don’t feel pushed or obligated to update anything.

    On a side note: I would put it on the same shelf in my mind as when Scrum teams don’t do daily stand-ups when a leader is out.

    This issue is tricky as it doesn’t seem to be much harmful but, if tolerated, it basically renders the whole Kanban implementation useless. The first step we do with Kanban is we visualize all the work. Basing on that we make informed project decisions every single day (with help of WIP limits, explicit policies etc.)

    Now, if the board isn’t up to date these decisions are made on a basis which doesn’t reflect the reality. We may violate the limits or cease to help a colleague with a critical issue not even knowing about that. This way, not only do we make suboptimal everyday decisions but we also cripple the biggest power of Kanban – its improvement mechanism.

    Potential solutions of this problem depend on what flavor of the problem you face. If it is a single person you can work with them to convince them there is value in updated board for them too. You can also ask them to give everyone in the team a credit of trust and give a method a try for a few weeks or a couple of months. It usually is enough to turn them back into the light side of the force.

    However, in the worst case scenario you last resort may be setting up a proxy who updates the board instead of a problematic person. It will be a hit on team’s morale (“we have someone who is treated differently”) but it’s a tradeoff some teams are willing to make. Especially that, eventually such person either changes their behavior or leaves a team.

    If we think of a whole group not updating the board it is a signal that there’s little or no buy-in for the idea. Unless this can be changed most likely the Kanban implementation is doomed.

    The way of getting team’s buy-in will of course depend on people. However, I find it pretty successful to ask the group to give the method a try. Of course considering there is a problem I believe Kanban can help to fix quickly. Thanks to simplicity of Kanban it doesn’t cost much hassle to “try it” and pretty often first results are rather quick as almost always teams have some low-hanging fruits in terms of improvements they can make – quick wins they just aren’t aware of.

    Read the whole Pitfalls of Kanban series.

  • Pitfalls of Kanban Series

    One of tricks I sometimes use when coaching teams that are starting with Kanban is I tell them why they shouldn’t adopt it. Challenging the team in such way helps me to indicate whether there is buy in as this is crucial thing to deal with issues the team will face.

    I do that knowing that, thanks to its flexibility, Kanban is pretty vulnerable and even a single team member may cripple Kanban implementation, thus vastly reducing value the whole team gets from adopting the method. Besides getting buy in having knowledge of these potential vulnerabilities can be a game-changer as then the team can avoid them.

    This was the idea which stood behind my session titled Kanban weak spots which I presented at Lean Kanban Central Europe last year.

    Recently David Anderson started an email discussion that inspired me to write a follow-up on the subject. As I was typing an answer to David’s questions I realized that it would be worthwhile to discuss each and every pitfall in details, covering reasons why it may appear and tools that can be used to deal with it.

    And this is how the idea of this series was born. You can expect a number of posts covering just a single Kanban weak spot. The whole list will be gathered here:

  • We Are Unique Syndrome

    That Scrum thing sound fine but, you know, the way we work here is quite specific so it won’t really fit our organization. And yes, unit testing is such a great idea but we have pretty unique work environment and I see no way to implement this practice. Oh, I’ve heard about this new web framework, which we might use, but I believe it would be better just to build the stuff in-house. And by the way, that issue we were discussing yesterday – just apply some hacks, I don’t think anyone could have had this problem before.

    You’ve definitely seen that. The canonical example is NIH syndrome often seen in programming. We hate tools built by others because, well, they aren’t built by us. We are so damn unique that there’s virtually no other organization similar to ours in the whole damn universe.

    The same principle applies to other areas as well. Cross-functional teams work in other organizations but here, in this unique, extraordinary and special company they would not, no way. Empowering (damn, I used the word) people results in better motivation and higher retention but it won’t be like that in our organization because we are different.

    Well, yes you are. Everyone’s special. But somehow huge numbers of companies face the same problems. And the funny thing is it seems that usually common solutions help majority of those organizations. Strange, isn’t it?

    While you can pretty easily convince me that your company is special in this or that area (I don’t know your company as well as you, so it’s not that hard) I just don’t believe you’re so freaking different that none of recipes known to the world works in your case.

    If you come to me with unsolvable issue with integrating web services written in Java and .NET I call bullshit. I don’t know the solution but I find it hard to believe that hundreds thousands of web services written in one technology can’t talk with hundreds thousands of web services written in another. Either I miss something here or this was kind of principle for guys who were standardizing this web service gizmo.

    Someone had that problem before (like hundreds or thousands people). You ain’t that special.

    Now go look for solution using this hi-tech tool called Google search. Or you’re so unique that you won’t use such a plebeian tool, eh?

    The same applies to project management issues. Ditto organizational and people problems. Pretty few people in the world can say they worked in truly unique environments on ground-breaking ideas and they had to solve issues no one had had ever before. Yet we all tend to play like we were working on Apollo program and it was sixties.

    Now, I’m not trying to tell you that silver bullet exists. I’d be a hypocrite, wouldn’t I? What I’m trying to say is that your issues have (likely) been solved by others and they (likely) described solutions in details.

    If you deliberately want to keep the way you work unchanged I’m fine with that. Just don’t tell me it’s either the best or the only way unless you have checked. And if you’d checked you (likely) wouldn’t have been selling me that bullshit about your uniqueness.