Pawel Brodzinski on Leadership in Technology

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

Tag: team management

  • Happiness Index as Team Sustainability Metric

    One of the discussions that happened during Don Reinertsen’s product development workshop was the one about absorbing turbulence. Absorbing turbulence is a metaphor for how well a team deals with unplanned variability of the process. These would be situations like arrival of a bigger batch of features to build, or especially complex work items, etc.

    Normally, every team is suitable to absorb some turbulence. Beyond that point this capability will not be sufficient and the situation would quickly escalate. A good example may be that the team would gracefully deal with some additional features but above certain threshold we’ll quickly the situation escalating to a high queue state. This would result in long lead times, long feedback loops and generally decreased responsiveness of a team.

    These all result in lower efficiency too.

    If such a situation persists over longer period of time it can take a heavy toll on people as we are running at risk of burning people out.

    I really like the analogy that Don uses in his work: when a human body is losing blood, interestingly enough, blood pressure doesn’t go down. What our body is designed for is to pump enough blood to the brain so it can operate normally.

    To compensate for losing blood the heart rate keeps going up. It goes up to the point where this mechanism is no longer sufficient and the organism crashes over a very short period of time.

    A similar thing happens when we overload our teams. For some time they deal with the overload just fine introducing their own coping mechanism. They’d likely work overtime, introduce additional multitasking, etc. A problem is that, similarly to the situation when a human body loses blood, there’s a price to be paid for that.

    Eventually people end up burned out and leave an organization. From that perspective a good question would be: what kind of early signals we get so that we can address the problem early.

    One answer would be careful monitoring of work. How much work in progress we have. How our queues in backlog change. This kind of stuff. While obviously that would provide us some signal, that wouldn’t really be a proxy measure if we want to consider people first, not the process first.

    What strikes me is that we at Lunar Logic already use a nice signaling mechanism that would give us an early warning. The mechanism is a happiness chart. Despite the fact that a happiness chart is a super simple, super low-tech tool it works on a few levels.

    On one level we have individuals. When I see a deviation from the norm in the chart of one person it likely means that something’s going wrong. It may be related to the work, it may be related to a personal life. Whatever the case is it does affect the work.

    If the case is individual it will unlikely be related to the whole project.

    Another context is the one of the whole company. If things were going generally wrong I’d expect to see a strong signal across the whole board. “Generally wrong” may mean either mediocre business results, or a cultural problem, or a strong source of frustration, or a bunch of different things.

    In such situation the signal would be broader than just a single project or product team.

    There’s another scenario, which would be a bunch of people recording worse than typical mood and the correlation would be around a common project. Process-related parameters of that project may look OK: a backlog queue wouldn’t grow, throughput would go up, etc. Is there anything wrong then?

    In this case happiness chart would serve as blood pressure – it would be a countermeasure pointing that something is going not exactly OK and if we keep doing that we may end up crashing.

    The rule for our happiness chart is that the color translates to the mood. Green means happy, blue means so-so, and red means not happy. Once the chart for a project team gets more bluish or even reddish that’s a very strong indicator that we are not absorbing turbulence in that team gracefully.

    The interesting part is that a happiness chart would provide such an information no matter whether a root cause is overloading a team with tasks, interpersonal conflicts that affect collaboration or anything else. The alarm would go off in either case. That’s actually perfect as we want to react to dangerous turbulence early in any situation.

    From that perspective the outcome of happiness chart isn’t a leading indicator per se – when the change is triggered it means that there’s already something happening. It isn’t a lagging one either. We can correlate it with other parameters or even check with people to figure out what is happening. We would know that we’re not coping with turbulence well enough much earlier than when we are on the verge of crashing.

    The reason why I think this strategy is so valuable is because it allows to merge the data from two different universes. On one hand we have all the process metrics that tell us how we are doing from efficiency perspective. On the other we get a social metric that tell a lot whether the current state is sustainable.

    It is exactly like a combination of a blood pressure and a heart rate. The former translate to efficient work of our steering center – the brain. The latter tells a little bit how sustainable current conditions are.

  • Two Rules of Autonomy

    One thing that we are doing at Lunar Logic is we evolve toward no management model of leadership. This means a lot of small changes that all happen with the same attitude at heart: to distribute more and more decision-making power across the whole company. This by the way also means systematically stripping down the management from that power.

    The latter is easy in our case as the management is limited to me and I kind of launched the whole process. I would have to be either a hypocrite or a schizophrenic to resist the changes. Luckily enough I believe I’m neither. (Unless that other me has something else to say, that is.)

    I don’t say it’s easy. One challenge in each step toward participatory leadership is that we, humans, don’t like to give up on power. I’m no different. I like that warm feeling that I can make a call and it shall be as I say. It’s not only that. Sometimes I simply know which option is good and the temptation to intervene and tell people what’s the best choice is strong. It would mean, however, taking a step back on a path toward democratizing leadership. So I keep my mouth shut.

    On other occasions I just feel like we are going too far from my comfort zone and I slow down the process.

    Giving up on power is a prerequisite to go further. While I don’t say it will go as easy in every case it isn’t enough to get that part working. In fact, despite being vocal how much I don’t want to make all sorts of decisions and how much I appreciate autonomy I still get loads of the questions that start with “Can I…”

    If I’m lucky enough to suppress my System 1 reaction that would be either of: yes, yes but, no, no but answers I’d reply with “Can you?” The ball is back in your court and as long as you take responsibility for the call you make I’m OK with that.

    The interesting thing is why these questions are popping up over and over again though. Despite the fact that on a conscious level we promote autonomy our natural behaviors means retreating back to the old pattern of asking for permission.

    We simply don’t claim autonomy even if it slaps us in the face.

    Besides years of programming our brains by education and work system that make it hard to act differently there’s another reason for that. Most of us want to be good citizens and we don’t want to use our autonomy to do stuff other wouldn’t like or even would be against. So we back up to the ultimate decision-making authority who is supposed to know what everyone in an organization likes or approves or more likely who doesn’t give a damn what anyone thinks – a manager.

    The interesting thing is that the fear sometimes is well-grounded. We have different sensitivity toward different things. Behaviors that we consider positive or neutral may have negative connotation for others. If I’m a manager and I use my ultimate decision-making power and I don’t give a damn then, well, I don’t give a damn. But what if I’m just a team member who cares?

    The idea we came up with is a set of two very simple rules.

    1. The Nike Way
    If you want to do something just do it.

    2. Speak Up
    If you don’t like what someone else is doing speak up.

    Yes, that’s it. There’s one underlying principle, which is mutual respect. We don’t need to love each other. We need to respect our autonomy and our right to have different views on stuff.

    The nice thing about this setup is that it is a self-balancing mechanism. It takes only one person try something new. It doesn’t require permission or even extensive up-front discussion. Pretty much the opposite, as a default we assume that every initiative would be awesome and everyone would love it or at least have nothing against.

    The Nike Way is verbalizing the attitude described by famous Grace Hopper’s words: It’s easier to ask forgiveness than it is to get permission.

    What we do know is that despite best intentions it won’t be true all the time. Occasionally, OK more often than occasionally, someone would do something that somebody else is not OK with. Then we have Speak Up rule that triggers a conscious and meaningful discussion (sometimes dubbed a shit storm) that provides additional insight for both sides and most likely some sort of consensus.

    Speak Up rule was designed with a positive scenario in mind, i.e. someone unintentionally stepped on someone else’s toe. It works however in malicious cases as well. When someone intentionally crosses the line or pulls an organization in an unwanted direction someone else will speak up too.

    The best part is that the same way it takes only one person to just do it, you need only one person to speak up.

    One might point that there’s a risk that it would end up in indecisiveness. So far I don’t see that happening. First, speaking up doesn’t mean the ultimate veto power. It simply triggers a discussion. Second, the respect bit that is a hard prerequisite keeps the discussion civilized.

    There’s a little more sophistication to balance that. Naturally extroverts would have an upper hand in unstructured discussion. That’s where empathy plays its role as helps to facilitate these weaker signals. On a basic level there are just these two simple rules: The Nike Way and Speak Up rule.

  • There Is No Shortage of Leaders

    I like the way Jerry Weinberg defines leadership.

    Leadership is a process of creating an environment where people become empowered.

    Empowerment

    I don’t really like the word empowerment as it is frequently used in the context of making people empowered. The way I understand empowerment such thing can’t even be done. You can’t empower me to do something.

    What you can do is give me enough positional power and possibly encourage me to do something. I can still cease to do it because of a number of reasons. I may not see value or sense in doing that. It may move me too far outside of my comfort zone. I may be afraid of peer reaction. Finally, potential consequences of failure may drive my decision.

    The way I think of empowerment is that it is intrinsic. I can feel empowered to do something. What others can do is they can create conditions that would enable that. It means anything from creating experiments that are safe to fail to shaping the environment so it supports and not discourages me to act.

    Only such way of interpreting empowerment makes Jerry Weinberg’s definition of leadership reasonable.

    Process

    What Jerry Weinberg talks about is a process. That’s unusual as typically when we think about leadership we think about individual context. How to become a leader or how to become a better leader.

    What “a process of creating an environment” communicates is that a discussion about leadership should happen in a different context. Instead of wondering how to help an individual to become a better leader we should discuss how to build an environment, or a system if you will, that supports emergence of new leaders and further development of existing ones.

    This inevitably brings to a context of system thinking.

    If we consider an organization a system there are many of its properties that influence whether, how and when people can lead.

    One of the most obvious ones would be a formal hierarchy. How rigid it is and how many levels it is built of. A hierarchy is important as it often linearly translates to power distribution. Most often it would be managers who make most decisions and influence environment around in extent.

    Then we have all the rules that people are supposed to follow. What is allowed and what is not. What stuff I have to comply to before I can do things I want. And most importantly whether everything is allowed unless rules state otherwise or the opposite: nothing is allowed unless rules state otherwise.

    Thinking of an organization as of a system from a perspective of enabling leadership is important because the system defines constraints. Normally, one can’t go beyond these constraints without risking dire consequences.

    In other words structures and rules define how much potentially is possible in terms of catalyzing leadership. It doesn’t automatically mean that fairly flat hierarchy and few rules is enough to see emergence of leadership throughout a company.

    Environment

    The bit that enables fulfilling potential created by rules and structures is organizational culture. We define organizational culture as a sum of behaviors of people being part of an organization. It’s not only abut behaviors though. It’s also about what drives them: values, principles, norms, beliefs, etc.

    Organizational culture constitutes what is an environment we work in. This is what steers how far we would go within existing structures and rules. In fact, it may even let us break the rules. It may be perfectly acceptable to for an organization to go against the existing constraints as long as it means doing the right things and is aligned with organization’s values and principles.

    What’s more, for companies that aim for good leadership distribution across the board will likely encourage such behaviors as it is a crucial condition for evolving the system and the culture.

    The hard part about organization culture is that we can’t mandate its change the same way as we can mandate for example rules change. We can’t do it as the culture is a derivative of behaviors of many people.

    What’s more we can’t mandate the change of behaviors in a sustainable manner either. We can introduce a policeman who would make sure people behave the way we want them to, but the moment the policeman is gone people would retreat back to the old status quo.

    So what can we do with the culture? We can work on constraints. This is in fact aligned with a system thinking view of an organization.

    A Process of Creating an Environment

    The bottom line of this is that most of the time when I hear complaints about not enough good leaders it is because environment is designed in a way that doesn’t let them emerge, let alone thrive.

    A litmus test that I use to quickly asses what climate there is for potential leaders would be bringing up famous Grace Hopper’s words:

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

    The question to ask is how much of that attitude is present in an organization. An interesting observation is that the more people exercise that attitude the less they actually need to ask forgiveness.

    The core of it though is empowerment. On one hand it translates to taking the rules into account and then doing the right thing even it means going beyond the rules occasionally. On the other it means that an organization accepts and supports such behaviors. It requires involvement of both parties.

    It requires continuous effort to adjust rules and structures and evolve an organizational culture to reach such stage. It requires a lot of discipline across management on all levels not to break such attitude once it is present as it is fragile.

    That’s why it’s a process and not a thing. Good news is that the better you do that the more leaders would get involved and the more self-sustaining the process will become.

    At the end of the day, there’s no shortage of leaders, only a shortage of companies that let leadership emerge.

  • (Don’t) Change Your Job

    Few of us have comfort not to worry, or think, of changing a job ever again. If you’re not one of those few, this post is for you.

    I have easily gone through way more than a hundred of exit interviews. No, it doesn’t mean that I changed job that many times. This means that so many people left my teams. Nothing to brag about, I guess. Anyway, if there’s a reason for leaving one’s job I’ve heard it. And I’ve heard it from a person who I knew and worked with for quite a while.

    Obviously, more often than not I tried hard to keep people around and missed those who decided to leave. This wouldn’t make me an objective adviser at a time. However, from a perspective of time, once what had been about to happen already happened, I believe I can go beyond emotions and biases and be pretty objective.

    There’s one thing that I noticed in my attitude when I talk to people about leaving. I feel and act differently when I try to keep on board someone who I believe may be making a good decision than in cases when I’m pretty sure they are making a mistake. While I don’t think any of you would find my feelings even mildly amusing, what is interesting is that my compass seems to be working surprisingly well.

    So how the hell do I sense whether changing a job is a good idea or not?

    It’s pretty much one thing. What’s more it sounds obvious. Surprisingly enough people very rarely follow the hunch.

    It’s all about how values of an organization one is about to join are aligned with their own values.

    Yup, that’s it.

    I mean, seriously. Ask people what they value. It’s an individual thing so they’d come up with all sorts of stuff, like respect, safety, trust, transparency, challenges, health, happiness, authenticity, quality, learning, perspectives and whatnot. Interestingly, very, very few people I know would say “more money” and in such cases they’d likely have pretty good reason for that (which is fair enough too).

    A nice thing is we can get pretty good hints whether these values are respected and embraced at our workplaces-to-be.

    “You can’t know” one would say. Well, you can. It’s enough to realize one thing. Every publicly or semi-publicly known action of a company is emanation of how it operates inside. In other words if you want to know what is valued in any given org just pay attention to how that company acts publicly.

    Are they worth of trust as a business partner? Why should they be as an employer? Do they care about well-being of their clients? Why should they care about yours? Do they respect any partner they work with? If not, why would you assume their respect would be extended to employees?

    I don’t say that without a reason. It’s not a rare occasion when there’s a value match or at least there’s nothing that would indicate the opposite. At the same time I’ve seen way too many bad decisions ignoring the obvious hints. As you may guess it didn’t work very well.

    So here’s my advice: ask yourself what is important for you. If an employer-to-be shares the key values with you then go for it. And yes, I do understand that I actually may be encouraging some of my people to look for alternatives. I don’t mind. After all, if I consider myself a leader I should care about well-being of my team, shouldn’t I?

    At the same time if your employer-to-be doesn’t seem to share your values this is a single most powerful signal to take into consideration. It means that the whole setup would suck eventually.

    And yes, it’s enough to look at, or ask about, relationships with partners or clients.

    It’s all about values and you can’t lie about values. If you are fair to your partners you’re going to be fair to your employees. And vice versa.

    Few people would take consider it when thinking about changing a job. Don’t be one of them.

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

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