Pawel Brodzinski on Leadership in Technology

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

Tag: great team

  • Empathy and Respect: What Makes Teams Great

    I’ve been known to bring up research on collective intelligence in many situations, e.g. here, here, or here. In my personal case, the research findings heavily influenced my perception of how to build teams and design organizations. The crucial lesson was that social perceptiveness and having everyone being heard in discussions were key to achieve high collective intelligence. This, in turn, translates to high effectiveness of a team in pretty much any flavor of knowledge work.

    Since the original work was published, the research has been repeated and findings were confirmed. Nevertheless, in software industry we tend to think we are special (even though we are not) and thus I often hear an argument that trading technical skills for social perceptiveness is not worth it. The reasoning is that technical skills easily translate to better effectiveness in what is our bread and butter—building software. At the same time fuzzy things, like e.g. empathy, do not.

    The research, indeed, was run on people from all walks of life. At the same time every niche has some specific prerequisites that enable any productivity. I don’t deny that there is specific set of technical skills that is required to get someone contributing to work a team tires to accomplish. That’s likely true in an industry and software development is no different.

    As a matter of fact, enough fluency with engineering is something we validate first when we hire at Lunar Logic. The way we define it, though, is “good enough”. We want to make sure that a new team member won’t hamper a team they join. Beyond that, we don’t care too much. It resonates with a simple realization that it is much easier to learn how to code than it is to develop empathy or social perceptiveness in general.

    The whole approach is based on an assumption that findings on collective intelligence hold true in our context. Now, do they?

    Google is known to be on their quest to find what’s the perfect team for years. Some time ago they shared what they learned in a few year-long research that involved 180 Google teams. It seems they confirmed pretty much everything that has been in the original Anita Woolley’s team work.

    It’s not the technical excellence that lands teams in the group of accomplishers. By the way, neither is management style—it was orthogonal to how well teams were doing. The patterns that were vividly seen were caring about other team members and equal access to discussion time.

    What’s more, the teams which did well against one goal seemed to do well against other goals as well. Conversely, teams that were below average seemed to be so in a consistent manner. The secret sauce seemed to work fairly universally against different challenges.

    What a surprise! After all, we are not as special as we tend to think we are.

    I could leave it here, as one of those “You see? I was right all that time!” kind of posts. There is more to learn from the Google story, though. Aspects that are mentioned often in the research are norms, either explicit or implicit. This refers to specific behaviors that are allowed and supported and, as a result, to organizational culture.

    When we are talking about teams, we talk about culture pockets as teams, especially in a big organization, may differ quite a bit one from another.

    It seems that even slight changes, such as attitude in group discussions, can boost collective effectiveness significantly. If we look deeper at what drives such behaviors we’ll find two keywords.

    Empathy and respect.

    Empathy is the enabler of social perceptiveness. It is this magic powder that makes people see and care for others. It pays off because empathic person would likely make everyone around better. Note: I’m using a very broad definition of empathy here, as there is a whole discussion how empathy is defined and decomposed.

    Then, we have respect that results in psychological safety, as people are neither embarrassed nor rejected for sharing their thoughts. This, in turn, means that everyone has equal access to ongoing conversations and they are heard. Simply put, everyone contributes. Interestingly enough, it is often perceived as a nice-to-have trait in organizations but rarely as the core capability, which every team needs to demonstrate.

    Corollary to that is an observation that both respect and care for others are deep down in the iceberg model of organizational culture. It means that we can roughly sense what are capabilities of an organization when it comes to collective intelligence. It’s enough to look at the execs and most senior managers. How much are they caring for others? How respectful are they? Since the organizational culture spreads very much in a top-down manner it is a good organizational climate metric.

    I would risk a bold hypothesis that, statistically speaking, successful organizations have leaders who act in respectful and empathic way. I have no proof to support the claim, and of course there’s anecdotal evidence how disrespectful Steve Jobs or Bill Gates were. That’s why I add “statistically speaking” to this hypothesis. Does anyone have a relevant research on that?

    Finally, there is something that I reluctantly admit since I’m not a believer in “fake it till you make it approach”. It seems that some rules and rituals can actually drive collective intelligence up. There are techniques to take turns in discussions. On one hand it creates equal access to conversation time. On the other if fakes respect in this context. It challenges ego-driven extroverts and, eventually, may trigger emergence of true respect.

    Similarly, we can learn to focus on perception of others so that we see better how they may feel. It fakes empathy but, yet again, it may trigger the right reactions and, eventually, help to develop the actual trait.

    In other words we are not doomed to fail even if so far we paid attention to technical skills only and we ended up with an environment that is far too nerdy.

    However, we’d be so much better off if we built our teams bearing in mind that empathy and respect for others are the most important traits for candidates. Yes, for software developers too.

  • The Fallacy of the Ideal Team Size

    An argument over the best team size is as active as ever. As long as we are in broadly understood context of agile the starting point usually is 7 plus or minus 2 people, which was widely popularized along with Scrum. This, by the way, leaves pretty wide margin for the optimal team size. You can find more precise answers though.

    It may be 6.

    My rule of thumb is that no work team should have membership in the double digits (and my preferred size is six), since our research has shown that the number of performance problems a team encounters increases exponentially as team size increases.

    J. Richard Hackman

    Or maybe it is 4.6. By the way, does it mean that we need part-timers to chase the ideal? Oh well…

    For the contrast Larry Maccherone reported at Lean Kanban North America 2013 that his quantitative research on data from nearly 10,000 teams showed that there’s no difference in productivity and quality in teams of 5-9 people and those of 10-12 people.

    Yet another argument to the discussion: Anita Woolley’s research shows that collective intelligence, which I find a key ingredient of team effectiveness, raises along with a team size. It flattens out between 10 and 11 people.

    But wait, didn’t Fred Brooks in his classic Mythical Man Month taught us that along with team size growth a number of communication paths grows exponentially? That would mean that for a team size the bigger means the worse.

    This is confusing, isn’t it?

    We are talking about the range between 4 and 12 already. I guess it wouldn’t take much of research to find sources that would broaden that range even more.

    The tricky part, and one that often go unnoticed, is that when discussing the perfect team size we don’t ask the question: perfect for what?

    Each of aforementioned sources focuses on a different angle. Be it performance issues, decision making, quality, productivity, problem solving or communication. Would optimizing any single one of these make a perfect team? I doubt it. Is it possible to optimize all of them at the same time? Well, it seems pretty unlikely. The numbers are just too far one from the other.

    That’s not the fallacy of the perfect team size though. I know I’ve just introduced a complex equation with many variables to solve the ideal size problem. However, knowing our specific context we can use different weights for different parameters and solve the puzzle. Oh yes, it would be super-contextual and probably would be very hard to copy even for another team within the same organization. It doesn’t really matter though as the effort would be futile.

    It doesn’t matter because the whole discussion is flawed unless we understand how our teams operate. While we typically assume that structural or hierarchical borders are what constitute a team it is a huge oversimplification.

    An interesting thing happens when we observe organizations without fixed teams. One example may be Lunar Logic where people are assigned to ephemeral project teams and when a project is finished they move on to a next challenge. Another example may be Valve where someone who has an idea looks for others who are willing to develop the idea with them. These teams are even more unstructured as, at least in theory, people can come and go as they want.

    Now, let’s think for a while how people work in such environments. Do they function only within a team they are currently a part of? To some point. As long as a discussion is related strictly to the matter of a project they likely keep it within a project team. However, given that the borders aren’t that strict it’s much easier to go beyond a team to look for new ideas or solutions when an issue is more general.

    In other words people function in at least two different teams depending on a context. In Lunar, if I have 3 people in a project team this would be one entity they are part of. Another one would be 7 people who sit in the same room. Yet another one would be everyone within a range of a shout which is pretty much everyone in the company (yes, I know it’s easier with a small organization).

    Depending on a specific situation people would organize themselves to optimize a key parameter to accomplish a task. When they are discussing the scope of new batch of work they would go to an empty room to optimize communication and focus. When they are solving issues they would have an open discussion and likely invite people from other projects to improve creativity and collective intelligence. When they want to make sure the quality stays high, they’d look for another pair (or pairs) of eyeballs to look at the code as very small teams seem to have worse quality than bigger ones.

    Now, a big question: what team size we are talking about here actually?

    Well, I told you. Three people. Except, when you look at a broader context, it isn’t much of answer, is it?

    By the way in the context of Lunar Logic whenever I’m talking of teams I like to think of two layers of teams. One is a project team which typically is small. Two or three people per team aren’t a rare situation. Another layer is the company as a whole. In many cases we act as one big team. No hierarchy whatsoever of course helps a lot but that’s a different story. It means that we flexibly operate in 2-25 range in terms of a team size. I bet the ideal size, whatever it might be, is within this range.

    Of course, an unstructured environment makes it easier to break the hierarchical borders. However, even in pretty structured organizations I know I see the same behaviors, except they are not that intensive.

    The fallacy of ideal team size is that there is no such thing as the ideal team size. Instead of organizing people according to some sort of a magic number we should rather think of how to create an environment where people can easily adjust that size by themselves depending on the context.

    Then the whole discussion of what’s the best size will simply be irrelevant.

  • Teams

    What is a team? A group of people sitting in the same room? No. Folks having the same boss? Um, really? Those who work on the same project? Again, negative. No matter how badly we’d like one of above to be true, it isn’t.

    OK, maybe we should start somewhere else. What are crucial ingredients to call a group of people a team? Why we call a bunch of telecommuters distributed all over the world a team and we’d be reluctant to use the name to label handful of specialists sitting in the same room and working on the same project?

    What Constitutes a Team?

    Things which come to mind are about how these people cooperate, whether they are helping each other or how they make others better than they would be otherwise. However, it is time to ask the next why. Why one team shines when it comes to cooperation and collaboration and another sucks at it badly?

    The answer is a common purpose. As long as a group of people shares the same goal, and the goal is explicit for everyone in the group it makes a game completely different. If I’m pursuing my promotion I’ll optimize my actions toward this goal and not, say, project success. We’re no longer a team even if organizational hierarchy says otherwise. That is, unless we all are working on my promotion, which may be true in elections, to use the most obvious example.

    So the team should have a common purpose. Is that all? Well, get a bunch of random people find a goal they share and ask yourself whether they’re a team already. No, not really. It takes time for a team to form. Tuckman’s Group Development Model, sometimes known as Forming, Storming, Norming, Performing, tells us that we need to go through, sometime painful, stages before our performance hits the decent levels. You can find similar evidence in other areas of our lives as well. In military, it isn’t without a reason that veteran units are valued so highly. You will see exactly the same thing in team sports. Rebuilding a team is always treated as a huge risk and worse performance is usually expected over the course of the process.

    Why Teams Anyway?

    One assumption I make here is that, in general, team performance is better than a sum of performance of all individuals that the team is built of. On one hand it may be treated as an oversimplification, as there are tasks which are more effectively or successfully pursued by individuals than groups. On the other hand, the research run by Anita Woolley shows that teams beat the crap out of individuals in terms of intelligence. Put simply, individual intelligence is amplified in a team.

    Anyway, even if the opposite was true we’d still need teams as there is only limited range of goals that can be achieved by a single person. Ask even the best player to win a football match single-handedly.

    Stability of Teams

    Given that we need teams and it takes time for a team to grow, does it mean that we should keep them unchanged so they can evolve toward performing stage? Again, it would be too simple. It would also be somehow contradictory to Lean experimentation mindset, but you definitely wouldn’t like to change teams for this sole purpose. What’s the reason then?

    There are two actually. First, freshmen naturally help to change status quo. Every person joining the team brings fresh blood. It is an occasion to use experience, knowledge and perspective of a newcomer to challenge the way things are done. It doesn’t mean every team will exploit each of such occasions but at least they have a chance to do so. This is a reason why you should to add new people to a team from time to time. But before your rush to flood your great teams with truckload of newcomers remember that if you water the team down too much you will be back to the square one. You could disband the team immediately and form it again either way.

    Second reason to experiment with teams’ lineups is all about other teams, those which aren’t performing that well. It is a natural thing that being a part of a great team helps you to grow as an individual. You see how this machine works from the inside. Chances are good you can apply some of this knowledge in another environment if you have a chance.

    From a high-level organizational perspective, in short term it would be worth protecting your top-class team. However, in a long term it would be a way better choice to spread this culture over to other teams. But again, before you rush to disband your rock-star team and spread people all over the organization, remember that it isn’t magic which change teams immediately but more a catalyst which may, but may not, help spreading best practices and healthy culture across the company. Apply it in small doses or profits won’t be worth the cost.

    Teams as a Learning Tool

    One thing I’ve already mentioned here is that being a part of a great team helps its members to grow rapidly. The mechanism of it is pretty simple. Given that we share the same purpose, we all gain from sharing our knowledge and experience with others as it increases team’s pace in our pursuit toward the goal. In has one, very nice, consequence. Learning curve of such a team is very steep. Knowledge and experiences are exchanged extensively. Any stuff learned by any team member is quickly propagated among everyone.

    It means that it isn’t that important what all team members know on the day one. In the long run they will outrun groups which were more knowledgeable and more experienced because their learning pace is much higher. In other words: don’t focus on tools and technologies, focus on learning pace of your people. These days, especially in IT, learning new technologies becomes easier and easier. Starting a journey with programming from assemblers, back then in 70s, required understanding how processor and memory worked. Writing “hello world” in one of modern high-level programming languages hardly requires anything but ability to read and operate search engine.

    It would be unfair to say that it’s easier to be a rock-star programmer now than it was in 30 years ago, but definitely it is way easier to be a decent one. This is another reason why we should focus so much on teams as, unlike with technical skills, achieving decent team performance is still pretty darn hard.

    Why Teams Are Important?

    Now, let’s take a short break and look at this from a perspective of the whole organization. What is it all about? We’re talking about improving performance, spreading healthy organizational culture all over the company and learning. These all sound nice but why we should value these few things over different virtues which we know that can bring us success here and now?

    Well, we’re the part of the business which is changing very rapidly. Agile was launched about ten years ago. Lean was popularized in IT even later. Technologies are changing faster than ever. And most of all, our business environment is evolving at crazy pace. What software were you building 15 years ago? For what platform? In which technology? And what the heck was this whole internet thing back then?

    We need to adapt and learn faster than ever and yet we still need to deliver. It isn’t important what we know now, it is important how fast we can evolve when situation changes. And this is something great teams are very good at.

    And this is why teams are single most valuable asset of your organization.

  • Hire the Best

    I took a part in a panel discussion at GeeCON about presence of women in IT industry. One of my arguments on why we should hire more women sprung an interesting comment:

    I can’t agree with ‘hire woman even if she is a worse candidate’

    Pawel Wrzeszcz

    In fact, I’d agree with such a statement. I would as I wasn’t proposing hiring worse candidates. What I was pointing out was that I would hire less skilled or less intelligent woman over man. Why? Simply because she would be a better candidate.

    Now, you may be confused so let me point two things. A typical hiring process is about individual traits. How much a candidate knows, what skills or traits he or she possesses, etc. Then, once we hire them, we put them on a team where key things are how one acts as a part of the team and how they help the team to get better. A very different thing.

    If something I need to make my team more effective is more empathy and a different cognitive style I’d do the right thing focusing on these characteristics (which, by the way, promotes women over men). What almost all hiring managers would do instead they’d hire the best possible coder (which typically promotes men over women). Was he the best candidate?

    On some accounts, I guess…

    Let me rephrase: was he the best candidate in that specific context?

    Definitely not.

    He might have been most skilled and most intelligent candidate, which doesn’t make him the best. Not even close.

    If sport teams had the same hiring strategy as we do in IT industry they would be hiring only people for one position, possibly only stars. Can you imagine a football team (proper football, not American one) with 11 world class forwards?

    Yes, this is a dream of many hiring managers in IT.

    We forget that building software in vast majority of cases is a team sport, not an individual effort. And we don’t get points for having the most awesome person on the team but for what the whole team has achieved.

    So my challenge here is to rethink what “the best candidate” really means. We should be thinking more in terms of improving our teams, which is was more than simply hiring the most skilled person at hand.

    Hire the best still stands true, but we should first answer the question: the best for what?

  • What Makes Teams Better

    I’ve heard these experience reports a number of times: when a woman joins a team the whole team dynamic changes. Usually there is sense of improvement in team performance too. Unfortunately, most teams I know couldn’t report measured improvement as they didn’t have reliable measures in place. Anyway, the experience is very consistent.

    It is, unless we talk about a pure-male team that simply rejects any woman who joins. And does that a few time in a row. I know such teams too but I consider them dysfunctional.

    Anyway, let’s put dysfunctional groups aside. My own experience is purely positive too. I mean anytime that a team gained a new female member it was an improvement. At least that’s how I felt.

    Interestingly enough, it’s not about having a woman in a team. It’s about having as many of them as possible. The research done by Anita Woolley shows that the more females in a team the better collective intelligence of this team is.

    At the same time, the same research shows that collective intelligence beats the crap out of individual intelligence. Even more so if our goal is finding solutions of complex problems. And I dare say that software development is exactly that – solving complex issues – so we should be focusing on collective intelligence, and not individual traits.

    Collective intelligence was much more predictive in terms of succeeding in complex tasks than average individual intelligence or maximal individual intelligence

    Anita Woolley

    This changes my perception of recruitment. I was always saying that given two candidates who are on par I’d hire a woman, not a man. Taking only individual perspective into account, that’s just about right. However, when we think about teams the equation is different.

    In this equation women beat men easily.

    The big question is what are you going to do with this?

    Personally, I know what experiment I’m going to run next. And yes, it has a lot to do with hiring. I wouldn’t use the word “parity” but it wouldn’t be improper either. We need (even) more women on bard.

    I do want my teams to kick butts. How about you?