Pawel Brodzinski on Leadership in Technology

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

Category: team management

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

  • Don’t Ask For Permission

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

    ~ Grace Hopper

    As a leader of more than a hundred people I often get asked questions that I don’t really know how to answer. Well, I probably could answer pretty easily, although I don’t think “who, the hell, even asks such questions” or “maybe I could come up with some random piece of advice if you really need one” are really the type of answers they are looking for.

    On such occasions my default answer is Grace Hopper’s famous quotation.

    Don’t get me wrong, I’m not a fan of total anarchy. I do appreciate some order and asking for permission is an integral part of most of orders I know, if not all of them. However, when in doubt just take the advice from Grace Hopper.

    You may wonder whether this approach backfires on me sometimes. Oh yes, it does. I guarantee you this. Not very often, but pretty regularly. On such occasions, for a brief moment I wish that guy had asked what to do and had not simply done as he liked. But then I realize how much of a bottleneck I’d be with this attitude.

    Heck, not only would I be a bottleneck but also I’d restrain many of the great initiatives my teams pursue. I would tell them over and over again how much they’re begging for failure. Or even better – I’d keep them from failing. Except, eventually, they don’t fail. Damn those guys, they just don’t want to fail even though I predicted that.

    Actually, even when they fail, it is still better. After all, a failure is the best teacher and, as a bonus, I can use my clairvoyant hat: “Told you, but you wouldn’t listen.”

    When you think about it, the worst thing which can happen is that you might need to explain to a few very important guys why your team did what they did. And believe me, it doesn’t happen very often. It’s a pretty low price for all the great initiatives people pursue, the results they achieve, and the culture you all help to create.

    On a side note: when we are on the subject of culture, it probably is a cultural thing, but I find it interesting that we actually need to encourage people to go beyond hierarchies, procedures and rules. Otherwise many of them are naturally inclined to preserve the status quo.

    Status quo is likely nothing you’d like to preserve.

    So next time you have any doubts, just do the goddamn thing and ask for forgiveness. If you even need to do this after the fact, that is.

    Yes, I am well aware that quite a bunch of people from my team are going to read it.

    Yes, I know that some of them will take the advice to heart.

    Yes, I am pretty sure that they will use it in a way that (on occasions) will kick me in my butt. Hard.

    And yes, I am still happy with that. This is a tiny price for what I get in exchange.

    After all, if your butt isn’t kicked at all, you’re likely failing as a leader.

  • Local Optimizations Aren’t (Always) Evil

    A message that we hear over and over again is that we should optimize the whole and not the parts as local optimizations often (arguably always) result in making the whole operate less efficiently.

    I don’t want to bring up such stupid examples as counting lines of code (Want some? Here it goes!) or counting bugs (Whoa! On this screen there are several glitches. Why don’t I submit dozen tickets?). Listen to John Seddon’s stories for some less obvious examples.

    So let’s assume that we should focus on optimizing the whole.

    Now, tell this to this line manager who works for a couple thousand-employee organization. How the heck can this poor guy leading five people optimize the whole? Most likely he can’t. Well, of course he may, and should, fight his way up there to make his managers aware of problems he sees and help them to convince their managers, who need to get through to their managers, etc. A couple years later someone, finally, tells the CEO that she has a problem, so she makes the right decisions to optimize the whole.

    Except it doesn’t work this way. Most likely the message is ignored on one level or another. It’s actually pretty common that it doesn’t get through past the first level of a hierarchy. So we’re back to square one: our poor leader can’t optimize the whole. He neither has the visibility nor the power to do so.

    Should he fall back and sit silent?

    Hell no!

    He should make a goddamn paradise out of his tiny slice of the organization. He should optimize locally to the point where his team is the most effective team on the planet Earth.

    And yes, I am pretty much aware that many of these optimizations mean suboptimizing the whole. Actually, that’s perfect. Yup, I’ve just said it: that’s perfect. It means the guy’s manager needs to act. Set some boundaries or constraints. Point out how the manager harms the rest of the org. Otherwise the boss is just accepting the fact that the overall performance of his teams will drop. Of course he will still have this rock star team, but I guess you don’t get much praise for having a star player and, at the same time, seeing your team relegated to a lower league.

    There’s another nice side effect of the situation. These local optimizations, as long as they’re reasonable, are likely to virally spread throughout the organization. It means that the change starts affecting more than just a single team or even a division. It starts changing the whole org. For better or for worse. The role of senior managers is to funnel these changes into the right direction.

    After all, when our line manager changes the part of the organization which he can comprehend isn’t it optimizing the whole from his perspective?

    So roll up your sleeves and make your part of the company the best freaking team/division/what have you in the freaking world. Make your boss think how to set you constraints in a way that it doesn’t result in suboptimization of the whole.

  • On Feedback

    I’m not a native English speaker, which basically means my English is far from perfect. Not a surprise, eh? Anyway, it happens sometimes when one of natives I’m talking with corrects me or specifically points one of mistakes I keep making.

    And I’m really thankful for that.

    I’m thankful most of the time such feedback happens instantly so I can refer to the mistake and at least try to correct it somehow.

    This is what happened recently when one of my friends pointed one of pronunciation mistakes I keep making. It worked. It did because feedback loop was short. It worked even better because it was critical feedback. I didn’t get support for all the words I pronounce correctly. It was just a short message: “you’re doing this wrong.”

    Of course it is my thing to decide whether I want to do something about this. Nevertheless I can hardly think of positive feedback I could receive that would be that helpful.

    When you think about this, it is contradictory to what we often hear about delivering feedback. It isn’t uncommon that we are thought how we should focus on positives because this is how we “build” people and not “destroy” them. Even more, delivering positive feedback is way more pleasant and for most people easier as well. It is tempting to avoid the critical part.

    When we are on feedback loops I have one obvious association. Agile in its core is about feedback loops, and short ones. We have iterations so we deliver working software fast and receive feedback from clients. Or even better, we have steady flow so we don’t wait till the end of sprint to get this knowledge about the very next feature we complete. We build (and possibly deploy too) continuously so we know whether what we’ve build is even working. And of course we have unit tests that tell us how our code works against predefined criteria.

    It is all about feedback loops, right?

    Of course we expect to learn that whatever we’ve built is the thing clients wanted, our code hasn’t broken the build and all the tests are green. However, on occasion, something will be less than perfect. A feature will work not exactly the way a client expected, a build will explode, a bunch of tests will go red or pronunciation of a word will be creepy.

    Are we offended by this feedback?

    Didn’t think so. What more, it helps us improve. It is timely, specific and… critical. So why, oh why are we that reluctant to share critical feedback?

    It would be way more harmful strategy to wait long before closing a feedback loop, no matter what the feedback is. Would it really tell you something if I pointed you this two-line change in code you did 4 months ago, that broke a couple of unit tests? Meaningless, isn’t it? By the way: this is why I don’t fancy performance reviews, even though I see the point of doing them in specific environments.

    Whenever you think of sharing feedback with people think about feedback you get from your build process or tests – it doesn’t matter that much whether it is positive or critical; what makes the difference is the fact it is quick and factual.

    You can hardly go wrong with timely and factual feedback, no matter whether it is supportive or not.

  • Instant Feedback Culture

    There is said a lot about feedback. We continuously learn how important it is and how to deliver it in constructive way. Yet still, for many of us, me included, delivering feedback is difficult.

    I already hear you nodding your heads and saying “yes, especially critical feedback is a hard part.”

    Well, no. Not at all.

    I mean when it comes to critical feedback we happen to fail to do it constructively, but at least we do it. Positive (supportive or however you want to call it) is a different animal though. It’s easier to do it constructively. The problem is every now and then we forget to do it at all.

    But I have a solution. Yay!

    It is totally simple. That’s a good part. Unfortunately there’s also bad news for you. Prerequisites are difficult to achieve.

    OK, the method. I call it instant feedback culture. Why culture? Well, it is the part of organizational culture. The rest is pretty self-explanatory – you deliver feedback instantly. Has someone just said or done something you want to comment on in either a positive or a negative way? Use the Nike way: just do it. Do it instantly or almost instantly. Why “almost?” Um, not all the feedback you want to deliver publicly and the situation or behavior you have feedback on might have happened in a big group.

    You don’t keep it for later, for dreadful performance appraisal or something. You don’t wait until you forget it, which is by far the most common thing to happen. In some way you just get it out of the chest.

    Simple enough, isn’t it?

    Now the hard part. Prerequisites.

    First, trust. Unless you all trust each other it won’t happen. OK, it may happen partially, between people who trust each other, even if you can’t say that virtually everyone trusts anyone else. However, bear in mind that it’s like with number communication paths: between two people, there is one, between three there are there, with four people you have 6, etc. It doesn’t scale up linearly but exponentially. And the more people you get on trust side the more value they get out of instant feedback culture.

    Second, openness. It works both ways: one has to be ready to honestly share what they think and on the other side they need to accept an incoming message. I don’t have to to agree uncritically with it, let alone doing something about it, but I should accept and appreciate someone cared enough to share it.

    Doesn’t look difficult? Believe me, it is. Actually if you asked me what is a single biggest challenge in leading teams I will point building trust as it is totally intangible, yet crucial to get this entity called “a team” working.

    Anyway, considering you’re doing great and these prerequisites aren’t an issue for you, introducing instant feedback culture should be a piece of cake. Just remember to share every little bit of feedback instantly. Don’t wait until it fades away to oblivion. Don’t wait till there is an occasion because by this time it can be totally irrelevant or meaningless. Start sharing your feedback instantly and do it consistently.

    Others will follow. After all we like to receive feedback, especially a pleasant part of it. This way we get relevant feedback and get it quickly so it actually is easy to do something about the thing which is under discussion. Either do more of it (if a feedback is supportive) or change it (it it’s not).

    Soon you will see feedback flying all around in different directions and people, armed with new knowledge, will be improving much faster.

    So go, try introducing instant feedback culture. Considering that your team is ready for it, that is.

  • Learn. Adapt. Experiment. Repeat.

    One of recurring themes in my discussions on different methods and practices we use in our professional lives is: understand why and how the thing works so you can safely adjust it or substitute it with something else and get the same effect.

    A common example is stand-ups. Why are stand-ups limited to short time (15 minutes)? Why were they intended to be done with people standing and not sitting? Why do we answer three standard questions? And finally, how does it help us?

    Can you answer these questions from the top of your head?

    I know, it isn’t rocket science whatsoever. Yet I know many leaders, and even more teams, that would struggle to answer them reasonably.

    Such understanding of tools we use isn’t crucial only because it means you can go beyond by-the-book approach with methods and practices you adopt. It also is a signal that you know and use learn-adapt-experiment-repeat pattern. And this is a game-changer in terms of improving the way you and your team works.

    Let me share a story. I had a management retreat today, which was basically dedicated to discussion over handful of topics that are important for us. During the retreat’s summary a bit of feedback I received a couple of times was about the method of finishing discussions we used.

    Basically we had a Kanban board to organize subjects to discuss and at any given moment we had 1 (if any) subject that was “ongoing.” Now, if anyone out of 14 people in a room felt that discussion wasn’t adding value anymore or was meandering toward something totally different, they put a small sticky on subject’s index card. Once we had 3 stickies the discussion was over and could go further later, meaning during a break or after the retreat, in a group of people interested.

    My goal was simply not to see a dozen people bored to death only because there still are 2 folks who are willing to continue discussing something deadly important to them. At the same time I didn’t want to cut the discussion in half only because a timeslot dedicated for it was over, thus no timeslots whatsoever.

    Although no one taught me the method directly I’d lie if I said that I came up with the idea. Actually a few days ago I read Benjamin Mitchell’s post about two hands rule – a method one can use to cut irrelevant discussions during stand-ups.

    What I learned from Benjamin’s post wasn’t a stand-up-related technique. I learned the mechanism and understood how it worked. I didn’t dismiss the idea only because I don’t regularly attend any stand-up these days.

    Eventually, just after a few days, it came up handy. It required some changes in details as forcing people to keep their hands up for 20 minutes could be considered mobbing, but in its heart it is exactly the same tool.

    What happened here is I learned something new, adapted it as needed and experimented (I didn’t know how it would go). Finally, I learned something new. It seems I’m already at the beginning of the next iteration of the pattern. And I have a new tool in my toolbox. One which comes handy with things I regularly do.

    I’m two steps ahead. How about you? Are you there too or you still are following the book?