Pawel Brodzinski on Leadership in Technology

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

Category: team management

  • Closing Leadership Gap

    A theme that pops up every now and then is a leadership gap. An organization or its part finds itself in a situation where they need more leaders that there potentially are available. They might outgrow the old model and the existing leaders just don’t scale up. They might be facing challenges when someone had left the organization. It might be a simple consequence of evolving how the organization works. A list of potential reasons is long.

    A list of potential solutions is surprisingly short though. Typically it’s either hiring some people or promoting a bunch of folks to leadership positions. The former often means a lot of uncertainty. We don’t know whether a candidate would fit existing culture and pretty frequently we don’t even know how to verify that they have the right traits and skills.

    The latter, while it seems safer, is commonly a root cause of having the wrong people in leadership or management positions.

    What is a leader anyway?

    The problem of a leadership gap is actually deeper than we think. A part of it is how we constrain our understanding of leadership. In vast majority of situations when I hear about leadership debt a story is about leadership positions.

    You know, it’s about a position of a technical leader, line manager or something along these lines. This will never scale well.

    Even if scaling wasn’t an issue a situation when a team relies on a single leader is a huge risk itself. I would simply question that any single person is competent to make all the leadership calls you can think of. For example, on any given team I’m likely one of the last folks you want to enlist to lead with a technical issue.

    My answer to leadership gap starts with defining leadership as a contextual role and not position. This means that depending on circumstances anyone can act as a leader. It doesn’t matter what position they are in, what their tenure is or how much formal power they have. The only thing that matters is that within a given context they are the right ones to lead a team.

    Suddenly leadership gap doesn’t exist anymore as basically everyone is a leader and acts as one in appropriate moments.

    Where Leaders Thrive

    Obviously it’s not that easy. The magic won’t happen without a right environment. There are two critical bits to make it happen.

    The first is empowerment. Everyone has to know that they are supposed to be leaders whenever they feel like it. It starts with formal leaders, people in leadership positions, ceasing to execute their power. It’s not dodging the responsibility. Pretty much the opposite. It’s taking responsibility for decisions made by someone else. That’s quite a challenge for most of us.

    The best summary of such attitude are Grace Hopper’s famous words:

    “It’s easier to ask forgiveness than it is to get permission.”

    If your people believe in that and act accordingly, they truly are empowered. It also means that from time to time they will make you willing to yell at them: “Why the hell hadn’t you asked before you did something so utterly dumb?” What you should do instead is shut up. Don’t ruin that.

    The second bit is trust. If you don’t trust your team you will always be struggling with a leadership gap. Without trust the empowerment part would be meaningless empty words. No one would attempt to play a role of a leader and even if they do it once there wouldn’t be a second attempt.

    This is difficult because it means giving up control. But wait, we want more leaders so we are talking exactly about this – giving up control. How is anyone supposed to lead if their every action is double-checked by someone else?

    Closing Leadership Gap

    I have an idea for you. Instead of asking how to close a leadership gap think whether your people feel empowered or rather carefully managed. Ask yourself how you react when they screw something up and how it affects their future actions. Finally, be brutally honest with yourself: do you trust your people?

    The leadership gap problem is never solved by getting more leaders. The solution is creating an environment where leadership thrives.

    In other words the key to this puzzle is not outside the system but within it – in a way existing leaders act. And obviously the more senior the leaders the more they influence the situation. If you are complaining that you lack leaders in your team it’s likely your fault.

  • Why Bonus Systems Don’t Work

    The last time I shared my advice on how to fix a bonus system it was something along the lines “get rid of that crap altogether; it is beyond any repair.” The system I’ve just mentioned wasn’t extraordinarily flawed – an incentive money system in the company next door can work exactly like that one.

    Still, get rid of that crap.

    It may even be way above average bonus system.

    Get rid of it.

    It doesn’t work. It can’t.

    OK, let me start with a confession. Throughout my career I designed a couple of bonus systems. For quite a lot of time I was a firm believer that this is the way to go. The simple observation that every single bonus system I’d seen was flawed big time was more a motivation to finally get it right than a source for doubts that we may be trying to do the wrong thing righter.

    Eventually I started questioning the role of money as a motivational mechanism. Dan Pink’s TED talk is a classic on this subject.

    OK, I get the message already. Money doesn’t motivate. It doesn’t mean that it doesn’t yield positive outcome. I mean, it makes people happier, doesn’t it?

    Well, sort of.

    I think we should start with how people perceive the money they get. Is $100 worth the same for everyone in a team? I guess we all sense that this isn’t the case.

    “People’s choices are based not on dollar values but on the psychological values of outcomes, their utilities.”

    ~Daniel Kahneman

    In other words everyone may translate $100 to something different. In fact, I might have been happy with such a bonus last year but now, since my salary is higher, I’d need to get higher bonus to be equally happy.

    It basically means that we just can’t get the incentive money distribution right. Depending on who performed best, a different amount of money would be needed to make people feel equally happy. At the same time it means that people who performed equally well should get different bonuses because they have different concepts of utility. That just doesn’t feel right.

    By the way this is exactly why we typically speak about money in terms of percentages, not the absolute values. “I got 10% raise,” not “I got $100 raise.” The former gives at least some insight how much I value the raise.

    That’s not all though.

    “For financial outcomes, the usual reference point is the status quo, but it can also be the outcome that you expect, or perhaps the outcome to which you feel entitled, for example, the raise or bonus that your colleagues receive.”

    ~Daniel Kahneman

    Even bigger problem is with the reference point we use. Not only is it about how much I value $100 but also how much I expect I deserve. In other words, in a normal situation I might have been totally happy with $100 but I know that everyone around is getting $500. This means that it is suddenly only $100 and I’m going to feel miserably.

    There are many drivers to what we consider the reference point. One very interesting thing is that after a couple of situations when I got bonus money it becomes the new normal. I expect to get it again. I doesn’t matter that my performance in the next project wasn’t that stellar anymore. My reference point evolved.

    Believing that, in this case, incentive money is still completely optional and the default situation is that I don’t get any is just fooling oneself. In fact, every fat bonus I get simply makes me adjust my reference point. It isn’t something managers would like to see I guess.

    Unfortunately, it’s even worse than that.

    My reference point may change the utility of a bonus I get to negative values. I would consider outcomes that are better than the reference point as gains. Those that are worse than the reference point are loses. In other words if my status quo is set at $500 and I got only $100 I feel like I’ve lost $400. Someone paid me money just to make me feel miserable. Congratulations!

    “The happiness (people) experience is determined by the recent change in their wealth”

    ~Daniel Kahneman

    Considering the fact that change in the wealth isn’t measured in absolute numbers but against the reference point I see two ways to keep people happy. One would be to pay them more and more every single time, because then we don’t need to care about their raising expectations. Another one would be to set expectations on a constant level and focus on all the other happiness drivers that are available.

    I don’t think I need to mention how much “brilliance” is in the former idea. The latter means no bonus system at all.

    We can’t make bonus system right. The best we can do is damage control. The obvious follow-up question would be: so why the hell are we spending money to make people unhappy and harm our organization?

    One common answer I hear is that getting rid of bonus system would make people unhappy too. Oh yes, it will. I mean you’ve set that expectance that people would get bonuses. You’ve changed their reference point. Yet still the choice you have is between keeping (most) people unhappy in the long run (and continuously paying for that) and getting rid of the dysfunctional mechanism. The latter may be painful in a short term but at least that’s one-time change.

    So yes, this is my advice: get rid of that crap altogether.

    When you think how people perceive money you understand that no matter how hard you try you’re not going to make it work.

  • Multitasking Teams

    There’s one question I ask pretty frequently during my presentations or trainings: do you think that context switching comes for free? I’m yet to see a single hand up after the question.

    Not that I believe that this is universally accepted point of view. In fact, there is a follow-up question which is: who has a boss who thinks that context switching comes for free? I do get positives for the latter.

    I’d also assume that some people, even if they believe in free context switching simply wouldn’t raise their hands. Peer pressure, you know.

    I’m happy with the assumption that awareness of costliness of context switching isn’t ubiquitous and definitely there are different assessments of how costly it is exactly. Still, I’d say that basic understanding that we pay a context switching tax is pretty common.

    Context Switching Cost

    After all, it oh so obvious to predict how texting on the mobile while walking through a crowded street is going to end. Or playing Angry Birds while driving. Or driving, having a call, lighting a cigarette, overtaking another car and shifting gears, all at the same time (a true story; I’m glad that the passengers made it alive).

    It gets a bit less obvious when it comes to our workplaces. On occasions you’d hear things like “do it in the meantime” or “can’t you work on both of these things concurrently?” (Sure, I can. As long as you want both of them to be late, that is.)

    The real fun starts on yet another level though. Concurrent projects. When we aren’t discussing individuals but teams and not atomic tasks but projects, suddenly the assumptions that concurrent work on them doesn’t hurt becomes surprisingly common.

    The reasoning is that one team member will be working on one project and another team member on the other project. I’m always astonished that this thinking pattern is there even when there are more projects than team members… Anyway, let’s assume the situation is not that dramatically bad.

    There is still a problem of multitasking on a few different levels. First, there’s planning and coordination. Who should do what for how long? Even if team members typically do have comfort of being able to focus on a single thing there are people on the team who constantly switch context between all the projects that are run.

    Then, there’s regular communication. Typically ad-hoc communication can be a distraction. We willing pay the price for the distractions because we get value of those discussions. They are relevant for people because they touch the matter of the project they run. Well, as long as it is about the project they run. That isn’t necessarily true if a team run a few projects.

    Finally, there are situations when people would change the context of the project even if we don’t plan they would. What happens when someone is stuck? They’d ask for help. Whom? The person who is likely to help them. Does it mean only people from the same project? Not really.

    Obviously we’d get some of that even if a team works on a single endeavor, but such cross-team interactions are usually way less frequent, thus way less costly, than those within the team.

    This is sort of a gray area that is often forgotten even in organizations that are aware of the cost of multitasking. This is one of the reasons why visualization of project portfolio is so important. Each case where a team is coping with a few different projects or products at the same time should at least spring a discussion, as this is an obvious inefficiency.

    Multitasking on a team level is no less painful than on any other.

  • Hiring for Cultural Fit

    I definitely don’t keep the count but I believe that throughout my career I run more than a thousand interviews and hired way more than a hundred people. I have a confession to make: vast majority of these interviews were run poorly and many of those hires, even the right ones, were made on wrong premises.

    I started hiring when I worked in a 150+ big company. Not much later we were absorbed by our big brother – a 3000 big organization. The hiring model I’ve seen there is something that you would have easily guessed. A set of questions aimed to verify technical skills, occasionally augmented by a couple of puzzles to show how the candidate thinks. That’s exactly the pattern I followed when I started running interviews myself.

    I think it took me a couple of completely wrong hiring decisions till I started paying much more attention to non-technical traits. I mean, stuff like communication skills seem obvious. The question is how much weight you attach to the fact that a candidate is a good or a poor communicator. And of course communication is only one of a numerous so called soft skills.

    Experimentation with the interview process made me focusing on tech skills less and less over time. I could still name hires, who eventually didn’t fit.

    It took more than ten years and a bunch of people who I considered good fit in one organization but not in another to realize one crucial thing. There is such a thing as fit between an individual and an organization. The easier part of this equation is the former. We all can be described by our traits. At the same time, which is less intuitive, a company can be described in a similar manner. So what would we get it we written down all the company traits?

    A company culture.

    If there’s a mismatch between individual’s traits and a company culture there will be friction. You can tell that verifying past hiring decisions. You can tell that looking at people already functioning within the company as well.

    OK, so again, what are we typically focusing on when recruiting? Technical skills. Does it help to figure out whether a candidate would cohabit well with the rest of a team / a company? Would “very little if at all” be a good guess?

    It may be easier with a couple of examples. Imagine a small company where people are pretty open in front of others, rather outgoing, ready to help each other on the slightest signal that such help is needed. Imagine that an extremely skilled developer joins such a group. The guy is closed, not very sociable and feels that his contributions are best when he’s left to work alone without interruptions. Is the company well-suited to leverage the guy’s technical skills?

    Imagine a team working on a kind of a death march project. No matter how miserable the future looks like the whole team feels they are in it together. They work after hours to save as much of the project as possible. Well, almost. There’s one guy who isn’t that much into this whole engagement thing and basically just punches his clock every day. He may even be the most skilled person in the team. Would he be valued by other team members? Would his contributions be really worth that much as his skills would suggest?

    If we looked for a root cause of the problems in either case we wouldn’t discuss the guys’ technical skills. It’s the fact they’re misfits. What makes them misfits though? It isn’t a comparison to any single person. It is about how the whole group behaves, what values they share and how they interact with each other. It is about how the guys are perceived on this background.

    These are parts you should focus on if you care about how the whole group performs. In fact there’s more into this. Hiring a misfit cripples performance of both the misfit and the group.

    Unsurprisingly hiring for technical skills and technical skills only is a good way to hire a misfit.

    My challenge for you here is to answer the question how you actually verify traits that go beyond technical skills. Feel free to share them in a comment.

    There’s one thing I hear very frequently when I talk on this subject. It goes along the line: yeah, sure, go hire people who fit your company culture and know nothing about coding whatsoever and good luck with that. Of course I don’t advice hiring lumberjacks as software developers because of a simple fact of a cultural fit. I simply point how much we overestimate value of pure technical skills.

    Most of the time there is some sort of a base technical skill set that makes a candidate acceptable. I also believe that the bar is significantly lower than we think. In other words there is a good enough level beyond which a hiring decision should be made basing on very different premises.

    I don’t try to discredit tech skills here. Actually, I value them highly. I simply believe that it is way easier to develop one’s programming skills that to change their attitude. That’s why the latter is so important during recruitment.

    That’s why I see so much value in hiring for cultural fit.

    An interesting side discussion is how the existing culture influences individual’s behavior and attitude and how the individual affects the culture. This is something company leaders can use to steer (to some point) culture changes or to form (to some point) new hires. It works though only as far as the mismatch isn’t too big. Anyway, it’s a side discussion worth its own post.

  • 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.

  • Manager-Free Organization

    One of frequently mentioned management ideas these days is that we don’t need management. If I got a free beer every time I’ve heard the examples of W.L. Gore, Valve or GitHub and how we should act as they do I could stay drunk for weeks without needing to buy any alcohol. A common message is that if they can everyone can.

    I don’t subscribe to that idea.

    Well, being a manager myself that’s not really a surprise, isn’t it?

    I mean I’m really impressed with what these companies do, especially W.L. Gore given its size. It doesn’t mean that I automatically think that it is the new management model that masses should adopt. I simply don’t treat is as the true north of management or leadership if you will.

    First, such an approach is very contextual. You have to have a lot of right bits and pieces in place before it works. For the start it will fail miserably unless you have the right people on board and, let’s face it, most companies have way too many bad apples to make it work.

    Second, scaling up a manager-free organization is a huge pain in the neck. This is why I respect so much W.L. Gore work.

    Being a fan of evolution I also try to imagine how to become such an organization evolutionary. I guess I must be too dumb but in vast majority of companies it is beyond my imagination. Revolutions, on the other hand, have surprisingly crappy success rate so that’s not a feasible solution either.

    So far you might have considered me as a skeptic.

    Well, not really.

    While I don’t think that the managerless approach is, or will be, for everyone there is a specific context where it is surprisingly easy to implement. If you run a small company, let’s say smaller than 30 people, there’s not that much of managerial work anyway. Unless you introduce tons of that crap, that is.

    It just so happens that Lunar Logic is such a small company. When you think about small and stable size you can forget about scaling issue. It is much easier to find the right people too because you simply need fewer of them. While Valve needs few hundreds of them we’re perfectly fine with twenty-something. Besides, smaller teams generally tend to have fewer bad apples as everything, naturally, is more transparent. Everyone knows everyone else, sees others’ work, etc. There’s no place to hide.

    Suddenly, the manager-free approach doesn’t seem so scary, does it?

    It may be a hit for managers’ ego though.

    I can hardly remember when I wasn’t a manager. Obviously there were countless occasions when I used my formal power to do what I believed was right. So yes, it took courage to intentionally strip myself off of power and just put myself in a row with everyone else. Not that I’m already done with that; it’s a gradual process. A nice thing is that it can be done in evolutionary fashion though.

    While I still make salary and some other financial decisions, that’s basically it. The good part is that I’m forced to wear my manager’s hat very, very rarely. I spend the rest of my time fulfilling all the other roles I have which hopefully can be summarized as me helping others.

    You know, all the fun stuff, like setting up daily conference calls with the clients, writing longish boring emails, keeping task boards up to date, solving mundane problems, etc. Typically, just being there and looking for ways to help the rest of the team doing their best. An interesting thing is it does feel damn good even if the tasks sound less-than-exciting. I help people to do their awesome job. What else could you ask for as a leader?

    That’s why I can’t be happier when I witness others treating me just as a regular team member. It means we are closer to being a manager-free organization.

    So while you shouldn’t expect me proposing the managerless office to everyone I definitely thing that this is something small, knowledge-based companies could try.

    Would it work that easily if we were twice as big? I have no freaking idea. I mean we definitely aren’t yet where GitHub or Valve is. I don’t even know if we want to be there. If the company’s growth is a threat for the culture we grow and cultivate here, so much the worse for the growth.

    And this basically summarizes why I think that the manager-free approach isn’t for majority. I think pretty few businesses would prefer to sacrifice growth just for the sake of preserving the culture.

    By the way, do expect more on the subject soon.

  • 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?

  • It’s the People, Not the System

    When I first learned about the D. Edwards Deming’s idea that 95% of performance should be addressed to the system and only 5% to the people it seemed totally counter-intuitive to me. Not even the idea itself, but its consequences. I mean a simple thought that you can basically stop working individually with the people on their performance as it just doesn’t make any sense. The impact of suboptimal system improvements should be tenfold or better than the best possible people-related changes.

    Then, after researching the subject a bit, I swayed to the other side. The examples shared by Deming or Eli Goldratt are undeniable. I can also find a lot of examples from my own experience how the system was impacting performance heavily. Not that I had the numbers, but it resonated well with me.

    Now, finally, you know what I think? Both approaches are crap.

    Yeah, I’ve just tried to piss of both: guys who strongly believe in Deming’s work and those who totally disagree with him with a single attempt.

    What Deming Really Said

    I guess this story started when I was looking for precise Deming’s quote on one occasion. It seems that the meaning people attach to his words wasn’t there initially. The original 95/5 thingy was not about performance literally but about variability in performance.

    Let me use a sport analogy to explain that. Let’s take a basketball player. If he scores anything between 5 and 30 points a game, and neither of extremes is an extraordinarily good or an extraordinarily bad game for him (meaning: it happens on occasions) variability of his performance is high. As a comparison we can have another guy, a second-tier player, who regularly scores anything between 0 and 5 points. Variability of his performance is significantly lower, even though his average performance is significantly worse.

    Now, it’s not a surprise that the system governs variability. I mean, the more repeatable the situation the less variability you can expect. If the team plays are consequently set to create situations for one player his performances will be sort of repeatable. He won’t be suddenly disappearing from the game. At the same the system also governs variability of performances of a role-player who joins the game only under special circumstances, e.g. when the team needs more three-pointers or maybe when one of important players is injured. Variability of performances of such a player will be significantly bigger.

    Of course, to some point, the system also governs performance itself. Think what happens when the star sits on the bench throughout the whole game or when a guy who is typically a sub plays the whole game. It doesn’t mean, however, that you tell a third-tier player to substitute a team leader and expect them to score 30 points a game. It’s not going to happen in a consistent manner. (For basketball fans: yes, I know Jeremy Lin’s story, but that’s an exception.)

    What Deming was talking about was basically that the system governance is responsible for creating a stable and repetitive environment so people performances are controllable. Again, it’s not about how exactly people perform, but how their performance varies from day to day.

    In fact, the above statement is mostly an interpretation too. Deming was talking about the system being, or not being, in statistical control which isn’t exactly performance variability, but for the sake of this argument let’s leave it as it is and not complicate things even further.

    Anyway, Deming Is Still Wrong

    So far I made an attempt to convince you that: first, Deming was basically talking about performance variability and second, the impact of the system on performance itself, while existent, isn’t anywhere close to 95%.

    However, we shouldn’t forget Deming’s background, which is a factory floor. In other words it’s a place where workers are supposed to produce same things in a repeatable manner. I could exploit the basketball analogy further pointing that every game, heck, every play is different, but I guess in software development we simply don’t need that analogy anymore. It’s enough to ask: how many times have you built exactly the same feature?

    And for all three of you who accidentally had this chance: how many times have you built the feature second time in exactly the same way you did the first?

    I bring this argument to show that in knowledge work, or sports, we naturally have significantly higher variability to deal with. And, unlike on a shop floor, that is good. What’s more, there is a different value attached to every single thing we develop. In fact, it’s even worse than that. Very often we don’t know exactly what value is attached to a work item we’re going to build.

    This means that in such a situation we should use a very different statistic mechanism than Deming based on. We need to take into account both expected cost and expected payoff. The latter, naturally, isn’t taken into consideration on a shop floor as in this situation payoff for each part is well known. In knowledge work, on the other hand, payoff function is extremely important and never flat.

    Coming back to the basketball analogy: if you wanted to bet which player is going to score 30+ points during the next game would you rather choose this reliable guy who averages 15.0 and who always scores double-figure but rarely, if ever, exceeds 20.0 or rather that crazy shooter who (surprise, surprise) averages 15.0 as well but, depending on a day, can score either nothing or 40+ points? Bravo! You’ve just chosen higher variability, which is totally against what Deming taught us.

    This is because you’ve taken the payoff into account. In the former case any payoff is almost impossible as, because of low variability, it’s highly unlikely that the guy is going to score 30+ points. The other case is a different story though.

    Now, especially when we think about product development we are in a betting business. We bet that this or that feature will bring a ton of new users or a truckload of money. We can’t ignore the payoff function. We can’t assume the payoff function is flat. In either case we’d be throwing the baby out with the bathwater.

    By the way, if you want to dig deeper around this one I strongly recommend watching this Don Reinertsen’s session. Twice. Seriously.

    Besides, Who Does Create the System?

    I’m not done yet. I don’t challenge the idea that the system affects performance. I simply challenge the so-called 95/5 rule or, to be more precise, I challenge the way some people interpret the so-called 95/5 rule.

    The question we should be asking is who (co-)creates the system. If we start with Deming he points shaping the system as a management responsibility. This is probably very true on a factory floor. We are not at a factory floor though.

    Let’s stay for a moment within software development perspective and think what exactly an equivalent of a production line is.

    Obviously, one part would be organizational culture. What are general ways things are done in the organization? Does the org use a lean / agile or rather a heavy-weight, formalized approach? How do your clients act? These general rules will be difficult to change.

    However, when we consider a lower level it’s a different game. Let’s try to translate low-level manufacturing process to software development. Production line would likely be a sort of a process: analysis, coding, testing, deployment, etc. What’s interesting though is what is happening on each of these stations. How exactly the work is done? Who makes decisions how the work is done?

    Take coding for example. Who decides whether unit tests are there or not? How many of them? What kind of tests? Who decides on a specific coding style? A manager? Um, no, not really. Most, or even every, of those decisions are made by a coder – a worker.

    Now, the important question: do such decisions define the system which a developer operates in? Obviously! Just think what is going to be the outcome of work of a cowboy coder and what happens when a worker is an eXtreme Programming fan. These are different systems indeed.

    The conclusion of this story is that in our world workers can influence the system heavily, thus completely change the Deming’s equation.

    One might point that leaving people freedom and empowering them is still the part of the system design which is still the management job. I’d disagree. One thing is that adopting a technique or a practice isn’t comparable to moving the machines on a factory floor. I can perfectly start writing unit tests and it doesn’t instantly require everyone else to change the way they work.

    Another thing is that it’s way easier to be a Grace Hopper follower in our industry. We can easily change the part of the system that goes through our desks, no matter whether we are empowered to do so or not. Eventually, if anyone notices (which isn’t that obvious by the way) we should have enough information to have meaningful discussion about the impact of how we’ve done our work.

    All in all, in knowledge work there’s no clear line that separates the system from the people, thus the whole notion of addressing specific part of influence to one or the other is flawed.

    It’s the People, Stupid!

    The last piece of this puzzle is a story. Not that long ago I’ve joined the organization that is exceptional when compared to its surroundings. I’m far from saying that it is a perfect system already, but it’s definitely the most mature company that I’ve ever been working with.

    In fact, it’s not only maturity of software development process we have but also this touchy-feely stuff we call the atmosphere. Not a dream job (yet) but pretty damn close to it when compared to everything else I’ve had a chance to experience.

    Let’s try to translate this to a system definition then. It would be pretty effective. It would be delivering high-quality stuff. It would be a great environment to work at. It would help everyone to grow. How could one possibly not like it?

    The only problem is that I’ve lost one third of technical stuff over the course of few months. The system? No, the people! Their individual needs, frustrations and dreams. Their unique contributions to what the system is, or has been.

    Because at the end of the day, in our world, the system is not machinery with replaceable humanoid parts; it is inseparably connected with the people who operate within the system. Change a single person and the whole system is different. Suddenly the rules of the game have changed and everyone else operates in a very different system. And the only thing that has changed is a single person has left.

    Summary

    My message in all that is that we should first understand our work, how it gets done and what kind of system we operate in. Because when we think about that it becomes obvious that there’s no simple way of separating the people from the system in knowledge work domain, especially when we’re talking about a small scale, e.g. dozens of people, not thousands of them.

    At the same time I’m challenging the common notion of Deming’s rule because it’s nothing close to what Deming really said and it is simply flawed in our domain anyway.

    At the end of the day you should understand the system (obviously!) but focus on the people too if you want a significant change.

  • Why I Don’t Limit WIP (On Occasions)

    As much as I love visualization as a technique that gives pretty much any team handful of quick wins, I do consider limiting work in progress the bit that makes or breaks team’s long-term ability to improve. Introducing, fine tuning and maintaining WIP limits is arguably the most difficult part of Kanban implementation, yet the one that pays of big time in a longer run.

    Shouldn’t limiting WIP be a no-brainer then?

    No, not really.

    Introducing work in progress limits is an investment. A long-term one. If a team isn’t ready to make long-term commitment to limit WIP it may not be their time yet. I mean, would you expect that a pretty much chaotic team would understand their process, let alone shape the process using WIP limits? They have quite a few prerequisite steps to make so let them start with that.

    OK, but this is the case of teams I often dub immature. But then there are teams that I’m working with and that most definitely are mature enough and we still don’t introduce WIP limits.

    Why?

    Introducing work in progress limits is an investment. A long-term one. Have I already said that? Oh… Anyway, if we are talking about sort of temporary team working on short-term arrangements investment into making WIP limits work may not be worthwhile.

    Let me give you an example. One of my recent project lasted 7 weeks, including first couple of weeks to get things running. Over the course of the project team setup has changed twice. Our environment was far from stability.

    Instead of setting up explicit WIP limits we just paid attention to what was happening on the board and were reacting whenever needed, using a couple rules of thumbs:

    • Whatever is closer to completion (further down the flow) it has priority over stuff that is on earlier stages.
    • We finish what we’ve started before moving on to another task, unless we encounter a blocker.

    Thanks to that we naturally limited work in progress and context switching despite lack of work in progress limits. Probably it wasn’t that strict and aggressive as it would be with explicit WIP limits, but I still think we’ve done decent job.

    The interesting thing is that I doubt we’d be able to fine-tune the WIP limits before the end of the project, even knowing everything we know once we are done. The situation was evolving very rapidly; bottlenecks were in 4 different places throughout these few weeks. We’ve made a couple of gut calls deciding who should do what, like developers helping with testing or design. In fact, we didn’t need explicit WIP limits to make these calls, although definitely understanding how the work was done was a crucial bit.

    If the project was supposed to last a few more weeks we would already have WIP limits on our board. But now the situation has changed; people are working in different setup, so limiting work in progress has to start from scratch.

    There are two lessons in the story. One is about WIP limits – they are a long-term investment and every team adopting WIP limits should understand that before they start. Another one is that even if you don’t have explicit WIP limits understanding how the work is done and reducing how much work is started helps. In some way it is limiting work in progress too.

    You don’t have to use fancy techniques to limit WIP. As I often repeat: read the board from right to left and start with the stuff that is more to the right. To be precise, this should be: read the board from where the flow ends to where the flow starts, as there are many non-standard board designs, but the idea is basically the same.

    You don’t have to work hard to start more stuff – it happens almost without any conscious effort. You have to work hard to finish more stuff. And this is what WIP limits help you with.