Pawel Brodzinski on Leadership in Technology

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

Tag: team management

  • Manager-Free Organization

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

    I don’t subscribe to that idea.

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

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

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

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

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

    So far you might have considered me as a skeptic.

    Well, not really.

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

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

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

    It may be a hit for managers’ ego though.

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

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

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

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

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

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

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

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

  • Hire the Best

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

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

    Pawel Wrzeszcz

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

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

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

    On some accounts, I guess…

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

    Definitely not.

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

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

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

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

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

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

  • What Makes Teams Better

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

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

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

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

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

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

    Anita Woolley

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

    In this equation women beat men easily.

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

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

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

  • It’s the People, Not the System

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

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

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

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

    What Deming Really Said

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

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

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

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

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

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

    Anyway, Deming Is Still Wrong

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

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

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

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

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

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

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

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

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

    Besides, Who Does Create the System?

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

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

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

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

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

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

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

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

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

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

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

    It’s the People, Stupid!

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

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

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

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

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

    Summary

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

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

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

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

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

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

    No, not really.

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

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

    Why?

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

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

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

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

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

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

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

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

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

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

  • No Authenticity, No Leadership

    There’s one thing about me that virtually every boss I’ve had so far has tried to correct. If you look at me all my emotions are painted on my face. You just can’t fail guessing whether I’m happy, worried, tired, excited, etc. I’ve heard so many times that I should do something about that since having people see my negative emotions definitely isn’t a good thing.

    You know, they see you worried so they instantly start worrying too and you don’t want to have worried people.

    I think I’ve even tried to change that. Fortunately, I’ve failed. Not that I don’t see how leader’s emotions can influence team’s behaviors. I do. And I know that sometimes I’m not helping, sorry for that.

    On the other hand, I’m honest and transparent this way. I’m all for honesty. I believe that transparency is a crucial ingredient for building a healthy team or a strong organization. In the worst case this attitude is a mixed blessing.

    But that’s not why I won’t try to change the behavior any more. I won’t do it because it’s who I am.

    One doesn’t have to like it. Such attitude doesn’t fit every organizational culture (and I learned it the hard way). But you aren’t a leader if you aren’t authentic.

    I was reminded that recently by Gwyn Teatro with her story about what leadership is. One bit I really loved:

    The man was successful because he did not pretend to be anyone else. His communication style included fun, laughter and humility. It worked for him simply because it is who he is.

    More than about anything else it’s about authenticity. People catch false tones sooner than you think. Then, they start guessing what really happens under the mask. It’s likely that their guesses are worse than the truth that one tries to hide. After all we are a creative bunch, aren’t we? It soon becomes worse: they don’t listen to the truth, even when it bites their butts. They just know better thanks to the gossips and far-fetched hunches. Their “leader” hasn’t been authentic so what’s the point of trusting him?

    So no, I’m not trading my authenticity for anything. Not worth it.

  • Emergent Explicit Policies

    One of Kanban practices is introducing explicit policies. It is the policy that probably gets least publicity. I mean I could talk hours about visualization and don’t even let me started with WIP limits thing. Managing flow gives me a great starting point for the whole debate on measuring work and using the data to learn how the work is done. Finally, continuous improvement is the axis that the whole thing spins around and a link place to all sorts of beyond Kanban discussions.

    Note; I put introducing feedback loops aside for the sake of this discussion as it is still new kid on the block and thus it isn’t covered that well in different sources.

    On this background explicit policies look like a poor relative of the other Kanban practices. Seriously, I sometimes wonder why David Anderson put it on the original list back then when he was defining what Kanban method is. Not that explicit policies are unimportant, but their power is somewhat obscure.

    After all what does it mean that we have explicit policies? What does it take to have such a thing? When I’m training or coaching I like to use this example: if I take any member of the team ask what random things on Kanban board mean they should all answer the same. I ask about things like, what exactly is represented by a sticky in a specific place of the board or what the meaning of a specific visual signal is, e.g. pins, magnets, different marks on stickies etc.

    I don’t subscribe to a common advice that you have to write policies down and stick them to the board to make them explicit. I mean, this usually helps but it is hardly enough to start. Explicit policies are all about common understanding of how the work is done.

    And this is where real fun starts. If we are talking about common understanding we should rather talk about discovery process and not compliancy enforcement. If it is about discovery process we may safely assume two things:

    1. It has to be a common effort of the whole team. One person, a leader or not, just won’t know everything, as it is about how everyone works.
    2. It’s not one time effort. As the team approaches new situations they are essentially introducing new behaviors and new rules.

    This is a real challenge with explicit policies. Unless you get the whole team involved and make it a continuous process you’re doing suboptimal job with policies.

    What you aim for is to have emergent explicit policies. Any time that a team encounters a new situation that calls for a new rule you can add it to the list of policies you follow.

    By the way, this is where having policies written down proves useful. I would, however, argue that printed sheet rather discourages people to add something, while a set of handwritten sticky notes or a hand writing on a whiteboard does the opposite. This is why you may want to use more sketchy method of storing the list of explicit policies.

    Another thing is what should make it to the list. As a rule of thumb: the fewer, the better. I mean, who would read, and remember, a wall of text. Personally I would put there things which either prove to be repeatedly problematic or those that are especially important for the team.

    After all, your policies are emergent so if you missed something the team would add it soon, right? In fact, this is another thing to remember. The last thing a leader might want is to be considered the only person who is allowed to change the list of policies. Personally, I couldn’t be happier when I saw a new policy on the board that was scribbled there by someone else. It is a signal that people understand the whole thing. Not only do they understand, but they do give a damn too.

    Without this your policies are going to be like all those corporate rules, like a mission statement or a company vision or a quality policy. You know, all that meaningless crap introduced by company leaders, that has no impact whatsoever on how people really work.

    You wouldn’t like this to happen in your team, would you?

  • Flying Office

    I’ve been working as a manager for the vast majority of my career. Teams I led consisted between a couple to 150 people, most of them being bigger than 20. Throughout that time I’ve had my own office once. And I don’t think it’s been a good idea.

    I decided to move to the office as I didn’t really see any reasonable setup that would work with a team spread across 40 rooms. It was then, when I first thought about the idea of sitting with one team for a week or two before moving to another office to join another team. I didn’t decide to pursue the idea though.

    The thing that kept me from doing that was the organizational culture. I was a parachute boss for everyone and the division hadn’t existed before as a single entity, thus there was very little to no trust to me, or between teams.

    If I’d popped one day in a random office stating that I’d been planning to sit in for a couple of weeks it would have been interpreted as spying on the team (or some other, more sophisticated form of repression).

    Fortunately, this time the situation is different. The organizational culture in Lunar Logic is way more open. No one assumes that the boss has bad intentions. In fact, I’ve had first discussions with people being concerned about my actions just a couple of weeks after I joined.

    It takes courage to go to your new boss and interrogate them about their plans and intentions. Such an attitude means that people voluntarily become vulnerable. It also sets up a completely different environment a leader acts in.

    So this time I’m not going to have a private office, not a chance. After just a few weeks spent in a neutral place I fetched myself a flying office. What’s that? A bean bag, a laptop table and a cardboard box.

    Flying office

    A bean bag works extremely well as a sitting device. It is extra-comfortable for short periods of time. On the other hand it would be painful, and unhealthy, to sit there for 8 hours. The latter reminds me that leader’s place isn’t on their butt but on their feet – running around, removing obstacles and solving problems.

    A laptop table solves a problem with keeping a laptop on, well, you lap, which, despite its name, isn’t the most convenient way of working.

    And I use a recycled cardboard box to store all my office belongings, which is simply a handful of sticky notes and a couple of pens and markers.

    This way I can grab my flying office to my hands and move it to the place where I’m needed or I feel like I can be helpful. I need just a bit of space in a corner or by the wall and done – a new office set up.

    Surprisingly, sitting in the corner and almost on the floor has a few unexpected advantages . First, you need very little physical space, which means you will fit to almost any room (unless it is already packed beyond any healthy limits). Second, this way you become almost invisible, which definitely helps if your goal is to understand how the team functions, and not just scratch the surface.

    Third, and arguably most importantly, you strip yourself from status symbols. Instead of a huge desk dubbed by your colleagues as the airstrip, a leather armchair and a locker just the simplest set that does the job.

    All in all, you’re way more accessible and much less intimidating. Isn’t that something every single leader should strive for?

    The flying office isn’t only very mobile; it also renders quite a few barriers that leaders often face irrelevant. Bringing oneself to a floor level is a challenge for ego though, but I’d say it is a good thing too.

    All you need to start it is just a bit of trust.

    Honestly, I regret I didn’t try it, despite the odds, when the only other option was a private office. I can hardly think of a different setup now, that I potentially have half a dozen more common solutions.

    How about you? Given that your team doesn’t work in a single room, are you courageous enough to try?

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

  • Leadership, Fellowship, Citizenship

    There was a point in my career when I realized how different the concepts of management and leadership were, and that to be a good manager one had to be a good leader. Since then the idea of leadership, as I understand it, has worked for me very well. I even like to consider my role in organizations I work for as a leader, not a manager.

    Perceptions of leadership shift these days. Bob Marshall proposes the concept of fellowship. The idea is based on the famous Fellowship of the Ring and builds on how the group operated and what values were shared among its members, so that they eventually could achieve their goal.

    A common denominator here is that everyone is equal; there’s no single “leader” who is superior to everyone else. At different points in time different people take over the role of leader in a way that is the best for the group.

    As Bob points, leadership doesn’t really help to move beyond an analytical organization (see: The Marshall Model). This means the concept of leadership is insufficient to deal with further challenges our companies face on a road of continuous improvement. We need something different to deal with our teams, thus fellowship.

    Another, somehow related, concept comes from Tobias Mayer, who points us to the idea of citizenship. Tobias builds the concept on a balance between rights and responsibilities. It’s not that we, as citizens, are forced or told to keep our neighborhood clean – it’s that we feel responsible for it. This mechanism can be transferred to our workplaces and it would be an improvement, right?

    I like both concepts. Actually, I even see how one can transit to the other, back and forth, depending on which level of an organization you are. On a team level, fellowship neatly describes desired behaviors and group dynamics. As you go up the ladder, citizenship is a nice model to describe representation of a group among higher ranks. It also is a great way to show that we should be responsible for and to the people we work with, e.g. different teams, and the organization as a whole.

    Using ideas introduced by Tobias and Bob we can improve how our teams and organizations operate, that’s for sure.

    Yet, I don’t get one thing here. Why fellowship and citizenship concepts are built in opposition to leadership?

    OK, maybe my understanding of leadership is flawed and there is The Ultimate Leadership Definition written in the stone somewhere, only I don’t know it. Maybe fellowship and citizenship violate one of The Holy Rules of Leadership and I’m just not aware of them. Because, for me, both ideas are perfectly aligned with leadership.

    Leadership is about making a team operate better. If it takes to be in the first line, fine. When someone needs to do the dirty work no one else is willing to do, I’m good with that as well. I’m even happier when others can take over the leader’s role whenever it does make sense. And what about taking responsibility for what we do, people around and an organization around? Well, count me in, no matter what hat I wear at the moment.

    When I read Bob and Tobias I’m all: “hell, yeah!” Except the part with labels. Because I still call it leadership. This is exactly what leadership is for me. Personally, I don’t need another name for what I do.

    I don’t say that we should avoid coining new terms. Actually, both citizenship and fellowship are very neat names. I just don’t see the point of building the opposition to ideas we already know. The more so as citizenship and fellowship are models, which are useful for many leaders.

    I don’t buy an argument that we need a completely new idea as people are misusing concepts we already have. Well, of course they are. There are all kinds of flawed flavors of leadership, same as there will be flawed flavors of fellowship and citizenship when they become popular.

    I don’t agree that leadership encourages wrong behaviors, e.g. learned helplessness. Conversely, the role of a leader is to help a team operate better, thus help eliminate such behaviors. A good leader doesn’t build followership; they build new leaders.

    That’s why I prefer to treat citizenship and fellowship as enhancements of leadership, not substitutions of it.