Pawel Brodzinski on Leadership in Technology

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

Tag: software business

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

  • No Estimates Middle Ground

    The idea of no estimates (or #NoEstimates) is all hot these days. People would choose different parties and fight a hell of fight just to prove their arguments are valid, they are right and the other party got it all wrong. I’d occasionally get into the crossfire by leaving a general comment on a thread on estimation in general, i.e. not steering a discussion for or against #NoEstimates.

    And that’s totally not my intention. I mean, who likes to get into crossfire?

    What No Estimates Mean

    A major problem of no estimates is that everyone seems to have their own freaking idea what that is. Seriously. If you follow the discussions on the subject you will find pretty much anything you want. There are crusaders willing to ban all the estimates forever as they clearly are the source of all evil in the software world. There also are folks who find it a useful tool to track or monitor health of projects throughout their lifecycles. You definitely can find people who bring to the table statistical methods that are supposed to substitute more commonly used approaches to estimation.

    And, of course, anything in between.

    So which kind of #NoEstimates you support, or diss for that matter? Because there are many of them, it seems.

    Once we know this I have another question: what is your context? You know, it is sort of important whether you work on multimillion dollar worth endeavor, an MVP for a startup or an increment of established application.

    My wild-ass guess is this: if every party getting involved in #NoEstimates discussions answered above questions they’d easily find that they’re talking about different things. Less drama. More value. Less cluttered twitter stream (yeah, I’m just being selfish here).

    Is this post supposed to be a rant against discussion on no estimates?

    No, not really. One thing is that, despite all the drama, I believe that the discussion is valuable and helps to pull our industry forward. In fact, I see the value in the act of discussing as I don’t expect absolute answers.

    Another thing is that I think there is #NoEstimates middle ground, which seems to be cozy and nice place. At least for me.

    Why Estimating Sucks

    Let me start with a confession: I hate estimating. Whoa, that’s quite a confession, isn’t it? I guess it is easily true for more than 90% of population. Anyway, as long as I can get out avoiding estimation I’d totally go for that.

    I have good reasons. In vast majority of cases estimates I’ve seen were so crappy that a drunken monkey could have come up with something on par or only slightly worse. And last time I checked we were paying drunken monkeys way less than we do developers and project managers. Oh, and it was in peanuts, not dollars.

    It’s not only that. Given that kind of quality of the estimates the time spent on them was basically waste, right?

    It’s even worse. It was common when these estimates were used against the team. “You promised that it will be ready by the end of the month. It isn’t. It’s your fault.” Do I sense a blame game? Oh, well…

    And don’t even get me started with all the cases when a team was under pressure to give “better” estimates as the original ones weren’t good enough.

    Why We Estimate Then

    At the same time, working closely with clients for years I perfectly understand why they need estimates. In the case of a fixed-price contract we have to come up with the price somehow. That’s where estimates come handy, don’t they? There also is a million dollar question: so how much will I spend on this thingamajig? I guess sometimes it is a million dollar question literally…

    So as much as I would prefer not to estimate at all I don’t hide in a hole and pretend that I’m not there when I’m asked for an estimate.

    All Sorts of Estimates

    Another story is how I approach the estimation process when I do it.

    I would always use a range. Most of the time pretty broad one, e.g. the worst case scenario may mean twice the cost / time than the best case scenario. And that’s still only an estimate meaning that odds are that we would end beyond the range.

    Whenever appropriate I’d use historical data to come up with an estimate. In fact, I would even use historical data from a different setup, e.g. different team, different project. Yes, I am aware that it may be tricky. Tricky as in “it may bite you in the butt pretty badly.” Anyway, if, basing on our judgment, team setup and feature sizing is roughly similar I would use the data. This approach requires much of understanding the dynamics of different teams and can be difficult to scale up. In my case though, it seems to work pretty fine.

    I’m a huge fan of Troy Magennis and his work. By the way, despite the fact that Troy goes under #NoEstimates banner, he couldn’t possibly be farther from folks advising just to build the stuff with no estimation whatsoever. One of most valuable lessons we can get from Troy is how to use simulations to improve the quality of estimates, especially in a case where little data is available.

    Finally, I’m also fine with good old guesstimation. I would use it on a rather general level and wouldn’t invest much time into it. Nevertheless, it works for me as a nice calibration mechanism. If the historical data or a simulation shows something very different than an expert guess we are likely missing something.

    Interestingly enough, with such an approach having more details in specifications doesn’t really help, but that’s another story.

    On the top of that, whenever it is relevant, I would track how we’re doing against initial estimates. This way I get early warnings whenever we’re going out of track. I guess this is where you think “who, on planet Earth, wouldn’t do that?” The trick is that you need to have quite a few things in place to be able to do this in a meaningful way.

    A continuous flow of work gives us a steady outcome of delivered features. An end-to-end value stream means that what is done is really done. At the same time without continuous delivery and a fully operational staging environment end-to-end value stream is simply wishful thinking. Limiting work in progress helps to improve lead time, shortens feedback loops and helps to build up pace early on. And of course good set of engineering practices allows us to build the whole thing feature by feature without breaking it.

    Quite a lot of stuff just to make tracking progress sensible, isn’t it? Luckily they help with other stuff too.

    Nevertheless, I still hate estimation.

    And I’m lucky enough to be able to avoid it pretty frequently. It’s not a rare case when we have incremental funding and budgets so the only thing we need is keeping our pace rather steady. And I’m not talking here about particularly small projects only. Another context where estimation is not that important is when money burn-out rate is so slow (relatively) that we can afford learning what the real pace is instead of investing a significant effort into estimating what it might have been.

    No Estimates Middle Ground

    To summarize the whole post I guess my message is rather straightforward. There’s value in different approaches to estimation so instead of barking one at another we might as well learn how others approach this complex subject. For some reasons it works for them pretty well. If we understand their context, even if ours is different, we might be able to adapt and adopt these methods to improve our estimation process.

    That’s why I think the discussion is valuable. However, in terms of learning and improving our estimation toolbox #NoEstimates notion doesn’t seem to be very helpful. I guess I’ll stay aside in the middle ground for the time being.

    By the way, if we are able to improve our cooperation with the clients on the estimation I couldn’t care less whether we call it no estimates or something different.

  • Kanban Leadership Retreat: Portfolio Kanban

    This year’s Kanban Leadership Retreat (KLRAT), as always, was awesome. In fact, despite sharing some critical feedback during retro session at the very end of the event, I still consider it the best event of the year, hands down. This year I’ve come back home with the biggest homework ever: experiments to try out, ideas to play with, concepts to write down, etc. It means that coming back next year is a no-brainer to me.

    One area that you’ll hear a lot about here is Portfolio Kanban. And this was also the subject of my session at the retreat.

    The Goal

    One of my goals for KLRAT this year was pushing forward the discussion on Portfolio Kanban. Answering questions like: what are the boundaries of the method? What are the gaps we still need to cover to make Portfolio Kanban thorough? How the implementations on portfolio level are aligned with the method as we know it?

    During the session I wanted to talk about all these things. My expectation wasn’t to rule out all the doubts. I assumed that the outcome would include some answers as well as some new questions but overall would bring us to better understanding what Portfolio Kanban is.

    The Hypothesis

    I hypothesized that Kanban method with its principles and practices define well the approach we can use on portfolio level. In other words that we don’t need any other definition for Portfolio Kanban than the one we already have for Kanban. This is where we started.

    The Process

    I didn’t want to start with the Kanban definition and look for its possible applications (we would find those, wouldn’t we?). I asked participants for a brain dump practices, actions and techniques that we use manage portfolio. Then we sorted them into six buckets of Kanban practices. For example portfolio overview would be covered by visualization so it went to the visualize bucket, limiting number of ongoing projects would obviously go to the limit WIP bucket, etc.

    Of course there were odd balls too. These went to the side as another group. Actually, this one was the most interesting one for me as they pointed us to possible gaps.

    Everyone had a chance to briefly explain what they put on the wall and why it went to a specific bucket. Then we used the remaining time to discuss the challenges we see – which questions weren’t addressed and need further work.

    The Outcomes

    There are a few lessons learned from the exercise. I think the most important bit is that the hypothesis was confirmed. I am convinced that using constraints of Kanban method we can neatly define Portfolio Kanban.

    Of course the specific techniques will be different. Interpretation of practices will vary too. But the same is true with team level Kanban applications in different contexts.

    Things get more interesting once we go deeper into the details. Let’s look at the wall which is the documentation of the session (click for a larger version).

    KLRAT Portfolio KanbanKLRAT Portfolio KanbanKLRAT Portfolio Kanban

    After a glimpse you can see that one bucket is almost empty. Surprisingly enough is the improvement / evolution bucket. Does it mean that we don’t see a match between Kanban method and portfolio management in this aspect? Personally, I think that it would be too quick to draw such conclusions.

    An observation made by Klaus Leopold was that quite a bunch of the stickies on the wall that could be placed not only in their original place but also in the improvement / evolution bucket. That’s obviously true. But then I can’t help but thinking that if we were doing the very same exercise with Kanban on team or service level the end result would look different.

    I think that the answer is that evolution on a portfolio level involves different behaviors and different tools than on a team level. How exactly? Well, this is one of these loose strings we have after the session, so I don’t have an answer for this. Yet.

    Finally, pretty obvious outcome of the session is the list of the challenges we will have to address (or explicitly leave unaddressed) to finalize definition of Portfolio Kanban

    KLRAT Portfolio Kanban Challenges

    Although we aren’t there yet in terms of defining what Portfolio Kanban is going to be, we made a big step forward. And this was exactly what I wanted to achieve. I didn’t want more divergence as I believe we’ve had enough of that so far. I didn’t expect more convergence either. Not just yet. Also I think that the time at KLRAT is just too scarce to spend it discussing the exact definition.

    And that is how the end result of our work looked like.

    KLRAT Portfolio Kanban

    All in all there are going to be follow-up steps – those that will bring convergence. If you are interested in further work on the subject stay tuned.

  • Manager-Free Organization

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

    I don’t subscribe to that idea.

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

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

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

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

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

    So far you might have considered me as a skeptic.

    Well, not really.

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

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

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

    It may be a hit for managers’ ego though.

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

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

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

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

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

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

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

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

  • MVP Thinking

    One of the most valuable goals achieved by Eric Ries’ Lean Startup is popularizing the term Minimal Viable Product (MVP). Of course the concept isn’t novel. We were using the Minimal Marketable Feature (MMF) idea back in the early days of Kanban and it was coined based on the same way of thinking. There are more of such concepts too.

    The basic premise is that we should build the smallest possible thing or run the smallest possible experiment that is still reasonable and adds value. Depending on the context the value may be something that helps users, but may as well be just knowledge discovery or verification a hypothesis.

    One thing I’ve realized recently is how widely I apply this thinking. Initially, it was simply the way of breaking the scope down. I wanted my teams to build possibly small, but still valuable, chunks of software so a client can verify them and feed us back with useful information. Then, after Lean Startup, it was about running a product. What we want to build something new that kicks butts. What is the smallest feature that can prove or disprove the hypothesis that it would work at all?

    Somehow I now use the same way of thinking, MVP thinking if you will, to discuss marketing ideas, define actionable items during retrospectives, etc. Often it is difficult to define a product per se, but there always is some kind of an expected outcome and definable minimal effort allowing the get that outcome.

    So how would I define MVP thinking?

    1. Define the next smallest valuable goal you want to achieve.
    2. Define minimal effort that allows you to achieve that goal.
    3. Execute.
    4. Analyze the outcomes and learn.
    5. Repeat.

    A potentially tricky part here is defining the goal because it is totally contextual. It is also something that really appeals to me as I don’t like recipes. In fact, if there is anything new here it is basically extremely broad application of the pattern as the idea itself is anything but new. I mean, we usually close our context to working with the scope of a project, driving a product, running a business, etc. Then, we absolutely coin a new term and if it works we make our careers as overpriced consultants.

    That’s totally not my goal. I’m just trying to broaden an applicable context of ideas we already know as I’ve personally found it helpful.

    So if my problem is a roof leaking near a roof window my next minimal goal may be verifying whether the leakage has anything to do with an external window blind. Such a goal is nice because minimal effort may mean simply waiting for the next rain with the blind either opened or closed. I definitely don’t rush to repair the roof.

    Talking about marketing? Let’s set a general goal that, say, TechCrunch will cover us. What would be the smallest valuable experiment that can bring us closer to achieving this kind of a goal? I guess reaching out and networking may be a very reasonable first step. It doesn’t even require having an idea, let alone a product, that we want to have covered.

    How about a product? Well, this one was covered virtually everywhere. Building minimal functionality, possibly even fake, that allows verifying that the idea for the product makes sense.

    Retrospectives? What is a single, smallest possible, change that will have a positive impact on the team? Try it. Verify it. Repeat.

    Heck, I even buy my sailing gear this way. What is the smallest possible set that allows reasonable survival? Then I use the outcome and iterate, e.g. next time I need new gloves, long johns and waterproof case for a phone.

    When you think about that it is basically Kaizen – systematically running small improvement experiments everywhere. So yes, it’s nothing new. It’s just the specific idea of Minimal Viable Product that spoke to me personally and gave me a nice constraint that can be used in different areas of my life.

    By the way, despite it very open definition I also find Kaizen usually applied in a very limited context. So no matter which idea works for you, just remember you can use it in broader context.

  • It’s the People, Not the System

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

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

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

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

    What Deming Really Said

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

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

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

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

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

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

    Anyway, Deming Is Still Wrong

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

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

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

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

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

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

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

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

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

    Besides, Who Does Create the System?

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

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

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

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

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

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

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

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

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

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

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

    It’s the People, Stupid!

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

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

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

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

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

    Summary

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

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

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

  • Gemba Walk Is Not Enough

    I’ve always had a love-hate relationship with Gemba walk. On one hand I just love the idea to go and see. In fact, whenever I have an issue to solve or a question to ask I prefer to move my butt and go meet someone instead of writing an email, chatting on IM or calling. I just use any pretext I have to meet people face to face.

    On the other hand, the idea of the Gemba walk, in its roots, goes way beyond simply solving issues. Just think about all those stories where leaders had their epiphanies when they randomly walked through a factory floor. Gemba walk isn’t just supposed to be an issue solving tool. Its main function is issue discovery, whatever an issue might mean.

    And this is where the hate part of my love-hate relationship starts. My previous professional life was leading 150 people. It meant that most of the time I was alienated. In a situation like that, you just don’t go into a team’s room as if nothing happened as almost certainly the observer effect kicks in and you experience something more like a play than reality.

    Not to mention that if you happen to be an introvert the whole activity can be insanely difficult for you.

    Obviously, it may be a very different experience if the organizational culture of a company is open and people generally trust each other. One, it isn’t that painful. Two, there is less acting and more honest and open discussions.

    It is still only halfway through though. As long as someone is willing to become vulnerable and open themselves you will learn something new. There is, however, the whole black mass of issues no one is really aware of so chances that you learn about them during a discussion are non-existent.

    In a plant you might spot something just by watching how stuff is arranged on a factory floor. In software development you don’t get even that. And, by the way, even if you brought your Gemba to the level of looking at things, e.g. code review, you still miss the point.

    No matter what the problem is, it’s always a people problem.

    ~Gerald M. Weinberg

    Following this advice, you shouldn’t look at things; you should look at people, their characters, behaviors and interactions. That’s where Gemba walk fails.

    You can’t make meaningful observations in the meantime, while you walk around and ask about everyone’s wellbeing spending just a while here before going there and then coming back to your own stuff. You can’t make meaningful observations of team dynamics during a chat with everyone.

    You have to be there. You have to breath the same air, share the same stories and see the same everyday routine. You have to become familiar and friendly enough that they stop playing. Or be there long enough so they get tired playing and become real.

    It doesn’t happen in fifteen minutes. It takes days. Weeks maybe. On the other hand you may expect a few low hanging fruits, which you spot pretty quickly, e.g. the way people address themselves in a discussion. Either way it doesn’t happen when Mr. Leader enters a room for his whatever-he-calls-it thing. It happens when a leader becomes almost invisible, sitting there in a corner, minding their own business and using those occasional bursts of action to learn something about their team.

    And this is why Gemba walk isn’t enough. It’s just scratching the surface hoping for luck.

  • Price versus Quality

    “Price has no meaning without a measure of the quality being purchased.”

    ~W. Edwards Deming

    It always fascinated me how price was the main axis of the game of closing software development deals. Unfortunately, in the vast majority of cases, pricing is used in total isolation from any other criteria, especially quality.

    It was like this when I worked on off-the-shelf ERP software. In this case it was, to some point, understandable. You can’t universally define functionality-to-price and quality-to-price factors if you sell the same product to thousands customers. It will be different in many cases.

    In such a case the question is what you deliver for the price you put on the tag attached to your product. Is it of high quality? And more importantly: do you keep, or even improve, the quality consistently?

    As a matter of fact, we didn’t. We didn’t think in such terms. It was more of a chase for more functionality to satisfy new customers than a conscious effort to keep the quality of software stable. You may guess how that affected the quality. Let me just say I’m not proud of the end result.

    It was still much better than what I experienced later, which was building custom projects for big clients. As a leader of software development and project management divisions I was often involved in the sales process. I was always asked how much time and people we need to build a thing. I was often asked about features the thing had or was going to have. I was never, ever, asked about the quality of the product or the tools we’d had in place to ensure this quality. Ever. Not a single time.

    It isn’t an industry-specific observation. I went through a few industries, including banking, insurance and telecommunications, and it was always the same.

    I’m compassionate for these poor chaps that were the decision makers. They followed their fears represented by the “nobody ever got fired for buying IBM” attitude. They just played it safe. In fact, I blame the system.

    I blame the system that disconnects the price from the quality of purchased goods or services. In such a case price is almost meaningless, yet it is almost always used as a deciding factor.

    The question I often wanted to ask the decision makers was: if they were buying the product with their own money would they be choosing the same? Obviously not. In fact, when we refer to our everyday lives, which I like doing, we never forget the relationship between quality and price.

    When I buy sticky notes to use on whiteboards I choose 3M even though they are pretty expensive when compared to alternatives. Actually, given a choice, I take 3M Super Stickies, which are even more expensive. It’s just the quality I need and I’m willing to pay for.

    When you think about the slow food movement being more and more popular over the course of the past 20 years, it follows the same pattern. Most of the premium products exploit the same behavior. Heck, how many of you, my dear readers, bought one of those overpriced smartphones or tablets? Apple fans, anyone? What is it if not paying for quality? And how do you choose a new car I wonder? By price tag only?

    So why, the hell, do you become Mr. Hydes when you return to your workplace and you choose a vendor? Oh, the system, I forgot.

    The system is, in fact, bigger than just an organization choosing a vendor. It spreads across most, if not all, of the vendors, too. A good picture of this would be a story my friend told me about the tender process in Romania in which he was involved as a representative of one of the bidders.

    When all the offers were formally submitted, the client organized a meeting with all the potential vendors, announced what the lowest bid was and asked everyone to reconsider their offers giving them half an hour to resubmit proposals with new pricing.

    When they had all the discounted bids re-submitted they did it again.

    It’s just spreading a sick behavior throughout the whole ecosystem. Optimizing solely for price means cutting corners on quality. Heavy price optimizations mean painful quality tradeoffs.

    And we know that low quality means a lot of rework and, as a result, higher overall cost.

    Now, that I’ve changed jobs, I’m more directly involved in the sales process. And I couldn’t be happier to learn that we don’t take part in this game. We are (relatively) expensive. Don’t expect the lowest bid from us. We understand what it takes to build high quality software and are ready to walk away if someone expects us to drive the price down to the point when we compromise the quality.

    Because, at the end of the day, low price is costly for both: a client and a vendor.

    You just can’t consider price in isolation from quality.