Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

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

  • Estimation Quality

    OK, so I am on yet another agile event. I’m sitting there in the last row and a guy on the stage starts covering estimation. That’s interesting, I think, maybe I’ll learn something. After all estimation is something that bothers me these days.

    Planning poker, here it comes. Yawn. People would pull the card with their estimate, yadda, yadda, yadda, they’d discuss and agree on a story point value. Yawn. The distribution of estimates would be normal.

    Wait, now the guy has my attention.

    So apparently he knows the distribution of the estimates. Good. How about checking what the distribution of lead times for historical data is. Because, you know, there are people who have done that, like Troy Magennis, and it seems that this distribution isn’t normal (Troy proposes Weibull distribution as the closest approximation).

    In short: if your estimates have a different distribution than historical data for the tasks that the team has completed the estimates are crap.

    Back to the presentation. The guy points how estimates for big tasks are useless in his context. Well, yes, they are. All the estimates in his context are crap from what I can tell. Then he points that we should be splitting tasks to smaller ones so planning poker makes sense and produce more reasonable estimates.

    Um, sorry sir, but you got it wrong. If you are using estimates that are distributed differently than historical lead times you are overly optimistic, ignorant, or both.

    How about this: I will not poke you in the eye with my pen but you will check the distribution of the estimates and the past lead times. Then you will recall some basic stuff from statistics course and stop selling crap that we can’t possibly answer the question: “when will it be done?”

    OK, rant aside. I don’t say that coming up with the idea how long it will take to build something is easy. Far from that. I just say that there are pretty simple things that can be done to verify and improve the quality of the estimates.

    Once you got the estimates look at their distribution. If it is different than what you know of historical data (because you’ve checked historical data, haven’t you?) the estimates don’t bear much of value.

    In fact, you can do better. Once you know the distribution of historical lead times you may use that to model estimates for a new project. You don’t really need much more than simply basic work break down. You can take the worst case scenario from the past data and assume the best case scenario is 0 days and let the math do its magic. No guesswork whatsoever needed.

    The credit for this post should go to Troy Magennis, who opened my eyes to how much use we can make out of limited data we have at our hands.

  • 5-Minute Board Test

    I discuss different Kanban boards or task boards with their teams pretty often. It’s not uncommon for me to see a board of a team that I know nothing of. I like these moments. I typically challenge myself to make sense out the visualization as I stare at it.

    Some parts are rather obvious. Typically the process isn’t that difficult to figure out. Usually I can tell who is working on what at a glance too. On the other hand something that should be obvious, but often isn’t, are classes of service – what they are and which items are of which class. And then there are lots of small different artifacts like blockers, comments, subtasks and what have you. Those do require some additional explanations.

    One of common sins of teams adopting Kanban is making visualization too complex. We do say visualize everything, but obviously it means “as long as it adds value.” Boards tend to get more and more complex over time as we typically want to track more information as we understand better how the work gets done. We really don’t need to complicate things more than necessary on the day one.

    So what makes a board a good one? The board is good when it does its job as an information radiator. This happens only when it is easy to comprehend and understand for the team members.

    This is a core of my 5-minute test to verify whether the board is designed well. The test is simple.

    A random team member should describe what is happening on the board to an outsider – someone who neither is a part of the team nor works with it regularly. If the outsider has any questions about specific things in the board they should ask and get the answers from the team member. The whole activity is time boxed to 5 minutes (thus the name).

    The board passes the test if at the end of the task the outsider can tell what exactly is happening in the team: who works on what, what are the problems (if any), what is the progress of work, how the team knows what to do, etc.

    One could argue that for bigger, more complex boards 5 minutes is not enough. I don’t agree. When we are interacting with the boards we rarely have more than just a couple of minutes. Of course team members would know part of the design without any explanation. That is why I’m giving an outsider full 5 minutes.

    The more stuff there is to take into consideration when making routine, atomic, everyday project decisions the bigger the chance someone would misinterpret part of that. That’s the point where understanding the board, and the process, isn’t fully shared across the team anymore. That’s the point where people start acting differently despite identical input.

    This is exactly the problem we tried to address when introducing information radiators in the first place. If the board doesn’t solve that problem it simply doesn’t work.

    Would your Kanban or task board pass the 5-minute test?

  • What Does Project Management Mean to Me

    I was poked to answer the question on meaning of project management by Shim Marom. Since my work, and this blog, evolved away from covering what can be called traditional project management approach long ago I thought it may be a good occasion to restate the purpose of the blog as well.

    Se here it is.

    Getting the stuff done

    The simplest answer, from the top of my head, is that project management is all about making it happen. Of course it’s not a single person’s effort. It’s more orchestration of all the stuff happening around but at end of the day the discussion always starts with what got delivered.

    But wait…

    “There is nothing so useless as doing efficiently that which should not be done at all.”

    ~Peter Drucker

    Getting the right stuff done

    The discussion on the right stuff is primarily product management / product ownership thing but most definitely it’s not beyond the scope of what I consider project management. After all, if you’re doing the wrong thing there’s no credit to anyone. A project manager isn’t an exception here.

    So yes, it starts with grasping the business case, understanding how the project corresponds to it and actively working on that match.

    When we are on the right thing though, it’s inevitable that doing right thing versus doing thing right argument will pop up…

    Getting the right stuff done right

    Getting the thing right is about the quality. If there’s no quality built-in it’s going to come back to you and bite you in the butt. Painfully. While I’m as far as possible from introducing oppression tools like quality procedures and such stuff, quality doesn’t automagically happen. One needs to create environment where high quality thrives and is encouraged.

    What exactly the high quality means is obviously contextual but from my experience it’s not that difficult to describe the quality in any given context.

    If nothing else you can always make the next project better than the last one.

    Getting the right stuff done right and improving

    This brings me to one of the areas I sunk into when I started flirting with Kanban – continuous improvement. There should be no pride in doing same stuff again and again. Unless you’re a freaking genius and know it all about project management, that is.

    Personally, I couldn’t be farther from that. That’s why I have an ambition to improve. Improve the way I work but also improve the way everyone around works. It’s not that easy as it sounds though. The prerequisites are: understanding how the work gets done and learning like hell.

    Without understanding work we are like children in the fog – clueless and lost. Learning means that we broaden our horizons and go beyond that carrot and stick method our first managers were using all the time.

    Getting the right stuff done right, improving and building trust

    This one is a classic last but not least. In fact, I believe that without trust you will struggle across the board. And I mean trust here in a very broad sense. One, it is about building trust within a team. Without that people wouldn’t become vulnerable, thus would restrain to become transparent. Without that a project manager would always have limited information of what’s happening in an endeavor they’re supposed to lead.

    Second, and more importantly, it’s about building trust with a client. That’s where the real fun starts. It’s really rare when a client would take the first step and will start to be open, transparent and vulnerable. The good part is that they will likely do so once they see it on the other side. But this is fear that every project manager, and every team member, has to overcome by themselves.

    The example, as usually, should go from leaders.

    So this is it. I believe this definition works well for me right now and the stuff I deal with fits the picture neatly. It doesn’t matter whether I talk about Kanban, organizational culture or team management. It doesn’t matter whether I deal with a portfolio level, a project level or a task level. It’s all there.

    Project management is about getting the right stuff done right, improving and building trust.

  • Options, Options, Options

    I think the first time I’ve heard that we should consider that a project backlog is simply a set of (unexercised) options it’s been from Ellen Gottesdiener It took me some time though to translate this, otherwise attractive, concept to something more down-to-earth in my own context. The catalyst in this case was one of Kanban Leadership Retreat sessions that covered portfolio management.

    Let’s imagine a company working on multiple projects. The organization size may vary, but let’s make it at least a couple hundred people strong. Such a company would have a bunch of project in progress but will also continuously work on selling more work to keep the business running.

    Every now and then, one of ongoing projects will get finished. What typically happens then is the company has some free capabilities. At the same time sales department is busy closing the deals. If the organization is extremely lucky and we are living in a fairy tale the pace of project completion will be exactly equal to the pace of new project arrivals.

    I have bad news though. We don’t live in a fairly tell. It’s even worse – most of the time we are not extremely lucky either.

    What typically happens is one of two things: there either are some free capabilities and no work that can fill this gap or the opposite – there is more work that should be started than can be handled with available capabilities. In fact, the situation dynamically changes from one to the other and back again.

    I want to focus here on a scenario with more incoming work that can naturally be absorbed by the org.

    One, sadly very common, approach is taking whatever comes from sales funnel and then pushing hard to make it fit, no matter what available capabilities are. Guess what – wishful thinking that people would handle more concurrent work doesn’t work at all. Conversely it only makes the problem worse as it forces teams to multitask which never comes for free.

    We can do better, can’t we?

    The opposite approach would be taking available capabilities into account and committing only to whatever the organization can handle. In other words it means saying no to some of available projects.

    It is like treating every incoming project not as a commitment by default but as an option. Well, it seems we have options again.

    So let’s picture our portfolio backlog as a bunch of options.

    Options

    Now, what happens when we start a project? Let’s keep it consistent with the Ellen’s concept. We fill the project backlog with a number of options. Except this time the options are more fine-grained. We may build these features or those features. Well, odds are we will build them all eventually, but the order is kind of important here.

    By the way, I’m yet to see a project where the scope doesn’t change. This basically means that every time we decide to build a feature we exercise an option of building this very feature while keeping the options of building other features still open.

    The option backlog will get replenished on occasions while we discover more and more details of the project. It will live and evolve the same way as our portfolio option backlog is alive and changing.

    The interesting part here is that commitment on one level (launching a project) springs a bunch of new options on another level (features or stories).

    Options

    In fact we can take this model even further. Once we as a team commit to build a feature we generate a bunch of options to build the feature in this or that way. We have an option to write tests. We have an option to write tests before the code. We have an option to write acceptance tests. We have an option to review code and so on. At the same we also have options to implement the feature in a few different ways functionality-wise. Some of them will be mutually exclusive, some of them won’t.

    Basically, starting work on a feature springs a handful of options on yet another level of granularity.

    Options

    If you imagine that building stuff in the company is happening on a few different levels – each of them dealing with more fine-grained stuff – this model will work throughout the board. Commitment on a higher level generates options on a lower level.

    In fact, you can take the model way beyond the three levels I proposed here. For organizations that deal with product lines, programs and stuff it will be the same. There always is a commitment to more high-level stuff before we choose how to do low-level items. There simply will be more layers to take into account.

    That’s why considering backlog as a set of options seems so attractive to me. It’s not only about a project or an iteration backlog. It’s about any backlog on any organizational level.

    What’s more, having the Real Options theory at hand we may use the model to manage the stuff we build wiser. Again, it doesn’t matter whether we think about managing portfolio, prioritizing features or deciding on implementation details.

    “Don’t commit early unless you know why” may as well apply to launching a new project or getting more work in progress than we really need to have. And knowing why should include understanding of all the costs attached. The bit that is too often forgotten.

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

  • Portfolio Visualization

    I’ve been lucky enough that throughout my career I’ve had occasions to work on different levels: from personal (that’s pretty much everyone’s experience, isn’t it?), though team and project to program / PMO / portfolio level. Not only that. In most of my jobs I’ve been involved in all levels of work concurrently. This means I’m schizophrenic.

    Um, actually this means that I’ve been pursuing goals that require focusing on different granularity of work.

    Granularity of Work

    Let me give you an example from my company – Lunar Logic. If I have to complete a task to close a new deal for the company, e.g. to have a call with a potential client, that’s a personal level. It is something that has to be done by myself and it involves only my work. Most of such stuff would be rather straightforward.

    At the same time I run a project where I’m supposed to know what’s happening and for example share my estimates when the work is supposed to be finished with the client. That’s a different kind of work. I mean it’s not only me anymore – there’s a team. Also there are a lot of dependencies. Unless bugs are fixed we don’t ask a client for acceptance, this task has to be finished before the other, etc. Of course, tasks will be bigger – we don’t want to run 30-minute long tasks through our task or Kanban board. At least not as default.

    Then there is whole effort of coordinating different projects run in the company. It is about understanding which are about to be finished making people available to work on something new, how we can cover for unexpected tasks, what kind of free capabilities we have, etc. At this level a user story or a feature is meaningless. We’re talking about big stuff here, like a project here and a project there.

    Depending on what I do I may be interested in small personal tasks, user stories or whole projects.

    Actually, there may be more than just three levels of stuff. It is a pretty frequent case. Imagine an org that employs a few thousand people. They will have teams, divisions, projects, programs and product lines. On any level beyond personal there will be a few different granularities of work.

    There may be a user story as the smallest bit of work that a team gets done. It would be a part of an epic. The epic would be a part of one of these huge thingies – let’s call them saga stories. Sagas would build up a project. A set of projects would make a program. The program will be developed within a product line… Complicated, isn’t it? Well, I guess it’s still far from what Microsoft or Oracle has.

    Focus

    Now, the interesting part. On every level leaders are likely to be interested in understanding of what’s going on. They will want to visualize stuff that’s happening. Wait, what that “stuff” is exactly? I mean, haven’t I mentioned at the beginning that work items that interest me may be very different?

    Um, yes. However, in each context, and at any given moment, there’s only one granularity of work that will get my attention. When I wear a hat of a company leader I don’t give a damn about a user story in a project XYZ. I just want to know whether that project is progressing well, what are the major risks attached to it and how it can impact other projects and our available capabilities.

    When I go down to wear a hat of a project leader, I’m no longer interested in timelines of other projects. I have project tasks to be finished and this is my focus. Scope of risk management would be limited to only a single project too. This means that I will be paying attention to a different class of risks.

    Then I go even further down to wear a hat of a leader of my own desk (not even a real one) and granularity of stuff changes once more.

    Good news is that vast majority of people don’t have this switching dilemma – since they’re always working on the same class of stuff there’s always the same level of work that they pay attention to. Always a single level.

    Well, almost…

    Second Level

    One level of stuff will always be a primary focus. In many cases there will be a secondary focus as well. It will be either one level up or one level down. For example, when I was a team leader my primary focus was the features we were building. However, on occasions I was going down to development tasks and bugs to understand better the progress we were making. Not that I needed the view on all the development tasks and all the bugs all the time – it would make information cluttered and less accessible. Sometimes I needed that data though.

    Another example. In my previous job I led more than a dozen development teams. Obviously user stories or features were far beyond my focus. My primary area of interest was projects on PMO level. I was expected to juggle projects and teams so we build everything on time, on budget and on scope (yeah, right). Anyway, the atomic unit of work for me was a project. Occasionally I was going a level up though, to program management if you will. After all, we weren’t building random projects. Teams had business knowledge specialization. I had to take it all into account when planning work.

    You can think of any role out there and it’s very likely that this pattern will be true: main focus of one level of work and possibly secondary focus on work that is either happening a level up or a level down. The secondary focus is likely to be sometimes on but sometimes off as well.

    Why is this so important?

    Visualizing Work

    My work around Portfolio Kanban and discussion on the topic made me thinking of what we should be visualizing. Of course it is contextual. But then, again, in any given context there is this temptation to see more. After all, given that we visualize what’s happening with the projects, it’s not that hard to visualize the status of the epics within these projects. And of course we definitely want to see what’s happening on program level too…

    No, we don’t.

    Again, in any given role (or hat) you have only one primary area of interest. If these are projects, focus on them and not on programs or epics.

    Otherwise the important bits of data will be flooded in all the rest of information that is needed only incidentally, if ever.

    Portfolio Visualization

    For whatever reasons we get that intuitively most of the when we manage work on a team level. I rarely see task or Kanban boards that attempt to map the whole universe (and more). Maybe it is because we typically have some sort of common understanding what an atomic task on a team level is.

    At the same time we go on a project level and things get ugly. I mean, what is a project anyway? For one person it will be a Minimal Viable Product (MVP), which is smallest increment that allows verification of a product hypothesis and enables learning. For the other it would be defined by a monolithic scope that is worth 200 man months of work. And anything in between of course.

    Unless we remember the rule of focusing on only one level of work, any meaningful visualization of that work would be impossible. This is one of the reasons why visualization in Portfolio Kanban is so tricky.

    Instead of creating one huge wall of information and throw all the different bits of data there, think about your primary focus and deal only with this. And if you keep switching between different roles no one forces you to stick to a single board.

    Right now I’m using portfolio board, personal one and a bunch of different project boards. For each of them, there is just one level of work visualized. So far I never needed to combine any two of them or put stuff from one at the other. It seems that even for such a schizophrenic guy as me the single focus rule applies as well.

  • What Makes Project Attractive

    Throughout years of my professional career I’ve heard all sorts of ideas what makes a project attractive for people working on it. A favorite technology. Greenfield work with no legacy code. Scalability challenges. Number of users. Potential to change the world. A genuine idea. Big money involved. Freedom to choose any tools. Code quality. Probably a dozen different things too.

    Since I joined Lunar Logic a number of projects I’m involved in a given time period went significantly up. It is so since on the top of a couple bigger endeavors we run quite a bunch of small projects. It’s great as I have an occasion to see, and learn from, many different environments.

    This experience influenced my thinking of the factors that make a project attractive. In fact I’ve seen a project that scored really high in most of areas mentioned above, yet still everyone hated it (and vice versa).

    Why? I think we focus on the wrong thing. No matter how cool is technology, scale or the idea if people involved in a project suck big time nothing is going to save the experience.

    If you’re like “yeah, I should have thought about the team too” I’m not heading this direction really. In fact conflicts within teams are kind of rare and typically people learn how to cope with each other quickly.

    However if a client is toxic, well, that’s an extreme case of bad luck.

    I mean, extreme in terms of severity, not in terms of frequency. The fact is such clients are pretty damn common.

    This is exactly why I pay so much attention to the people on client’s site when we consider a new project. Are folks who we’re going to cooperate with on a daily basis OK? Whether collaboration is going to be smooth? If so, I don’t care that much about how cool the code, the product or the technology is.

    Even if there is legacy code with poor test coverage and the idea is boring like shit but the guys on the other side are great people would still like to work with them. Actually, it is likely that there isn’t any other side at all – we’re all in it together.

    The opposite is also true. Take the coolest thing ever and work on it with a micromanager as a client and you will hate his guts in less than a week. With reciprocity, of course. And it’s not about micromanagement. Take any flawed client: a sociopath, an “I don’t give a damn” guy, a bureaucrat, or what have you. Same thing.

    Actually when I go through all the stuff teams liked or hated to work on I see the same pattern – show me the client and I will tell you how happy the team is. In Lunar Logic this is seen even more vividly because given our extreme transparency we simply make ourselves vulnerable in front of our clients. That’s an awesome tool to build trust. At the same time it can be abused to bring misery upon us.

    Fortunately, for whatever reasons, the latter is kind of rare.