Pawel Brodzinski on Leadership in Technology

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

Category: communication

  • Feedback Culture

    This is a rant. I’m sorry.

    We have our mouths full of feedback. We are eager to get feedback on our work. We consider sharing feedback as a crucial part of the work of any leader. Feedback this. Feedback that.

    Yeah, that’s all true. Except we’re missing one part.

    When it comes to leaving our comfort zones, we instantly start sucking at sharing feedback. We suck big time. You don’t like how our folks from PR team dealt with a recent initiative, right? After all you are just telling me that. So why won’t you just go and tell them? Brilliant, isn’t it?

    It’s pretty easy, you know. You use your mouth to construct these things called words and you build sentences out of words. And then the magic happens – you can transmit the message using sentences. Voila!

    That’s easy. Really. Just remember to be honest. Share the message in a straightforward way. Don’t judge. You will manage. I believe in you.

    Don’t get me wrong. I’m not freaking out over a single situation. I see this as a pattern. Actually, whenever I see any questions regarding feedback my default answer is “honest and straightforward.” The problem is this answer doesn’t seem to very popular. Actually beating around the bush or simply “don’t tell anything” types of answers seems to be the standard behavior for many.

    So why, oh why, are you surprised that you don’t get much quality feedback? After all you too are contributing to building this sick organization that is just afraid to share any. It’s simple – if no one shares feedback no one receives it either. It doesn’t populate like freaking lemmings or something.

    And while we are on this topic, well, it’s not only how you (don’t) share feedback; it’s also how you receive it. Next time someone wants to share something critical about you or your work, try this: STFU and listen. The other person has just moved their butt out of their comfort zone to tell you something they think is important. The least you shall do is to let them do their part. But you should do better – listen and try to learn something from it. A simple “thank you” seems proper too.

    You may even disagree with the merits of the feedback but it isn’t some kind of odd negotiation or something. No one is trying to win this discussion with you. No one is attacking you. So spare me the drama and don’t get all defensive. It neither helps you nor the other guy.

    Most of all, it definitely does nothing good to the feedback culture you may try to introduce into your organization. Not to mention building trust.

    If you really want to build an open feedback culture in your company, start sharing and stop being a jerk, I mean defensive, when you receive feedback. If your organization doesn’t appreciate this, think again whether it is the right organization to be with.

    Now that you asked, yes, such an attitude means that you become vulnerable in front of your superiors, peers and colleagues. And yes, it is a crucial part of building trust. I don’t know how it is in your case but I wouldn’t like to work for an organization that is incapable of building trust. Would you?

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

  • Better Conferences or Better Learning?

    Bob Marshall recently published his ideas how to improve conferences. Pretty radical ideas I’d say. Basically what Bob proposes is to move from traditional one-way communication to bi- or multi-directional conversations with expertise available on demand (read the whole post – it’s worth it). By the way similar points were shared by Jurgen Appelo in his writing as well.

    I’m no conference animal, even though I helped a bit to organize a few of such events and attended a few more. I went through different formats, from whole day long workshops, through few hour long tutorials, through anything between 90 and 30 minute long sessions, open spaces, TED-like no-more-than-18 minute-long performances, lightning talks, pecha kuchas and whatnot.

    While I understand Bob’s desire to change knowledge consumption from push model to pull model I find it hard to buy his ideas uncritically.

    There is one reason. The conference isn’t better because this or that format is generally better, but because the very set of people attending the very event learned much. In other words, thinking about an event we should think how this specific set of attendees is going to learn, which is a function of how they expect to learn and how they are prepared to learn.

    One of the best events I ever attended was Kanban Leadership Retreat. It was an unconference. It exploited many of ideas Bob shares. From a perspective of attendee, who was willing to learn even though they brought significant knowledge on the subject, it was great. The learning process was very multi-directional and pretty much everyone was both: a teacher and a student.

    At the same time on occasions I speak at events where such format would fall flat on its face. It would, as people who attend generally expect knowledge to be pushed to their heads. You may laugh but actually even such approach is sometimes expected in a whole spectrum of behaviors. On one end there’s mindless zombie who was sent to the event by the company (yet still they can learn something). On another there’s TED, where you know close to nothing on vast majority of subjects being discussed and actually expect expertise from people on the stage. Note: we’re still in “Dear speaker, I know nothing of whatever you’re talking about” land. I know there is another dimension where you move from one-way learning to everyone’s a teacher attitude.

    So basically my thought on the subject is: first, understand what the effective method of learning is for this very group you’re sharing your knowledge with. And yes, I’m talking here about majority, or average, if you excuse me such vast oversimplifications. I’m saying so because we don’t measure success of event by happiness of most demanding person in the room. Even more, probably the most demanding person in the room shouldn’t be happy with the event, because arguably it would usually come at a price of having many others not catching up with the content.

    Having said that I believe that generally speaking conferences should head the way Bob describes as our focus is still on pushing knowledge, not pulling it. I wouldn’t be so quick to revolutionary change all the events though – I would rather look for opportunity to broaden variety of methods attendees can use to learn.

    This is what a better learning is all about. And better learning is something better conferences should be all about.

  • Naming Issue

    There is something I see over and over again whenever people are discussing different methods. I go here with very generic “method” label on purpose as I don’t want to limit this to agile and lean world only. People pay much attention to the choice of words when they describe their ideas.

    Let me give you an example. Recent Al Shalloway’s post discussing MMFs starts with a distinction between MVP (Minimal Viable Product), MVF (Minimal Viable Feature), MMR (Minimal Marketable Release) and MMF (Minimal Marketable Feature). I don’t want to go into this discussion, but the simple fact people use all these different definitions proves that they really care about wording.

    I’ve made similar observation listening to David Anderson describing why he chose specific terms to describe his concepts and what changes he’s going to make in his next publications.

    I see this pattern even when people appreciate a specific choice of words someone used to share their message.

    And I don’t get it.

    OK, that’s not that simple. I understand why people pay so much attention to naming. They try to communicate their thoughts as precisely as possible. They try to describe their message in a detailed and clear way so everyone gets it. Cool. That’s perfect.

    Yet still, I don’t get it.

    Here’s why. I’m not a native speaker. I can communicate in English (or so I hope) and have even advanced discussions on subjects I’m interested in. At the same I don’t understand all the nuances of the language, something which likely comes totally effortlessly for natives. It basically means that, despite the effort of our thought leaders, I sometime just miss the point they addressed with putting so much attention to naming. It’s just lost in translation.

    When we are on translation, well, the problem is even worse. Whenever I speak publicly or train in Polish (my native language) not only do I struggle with my (lack of) understanding of nuances of English language used in sources but also with translating the message precisely enough. Unfortunately vast majority of these nuances is hardly translatable which makes the situation pretty bad.

    Of course I can’t say for every other language in the world but I wouldn’t say Polish language is that special, so my wild-ass guess would be that many others non-native English speakers face similar issue.

    In such cases my solution is to use any name which seems sort of suitable but add a longer explanation. The name itself isn’t that important. What is important is the meaning people attach to it, which by the way, we have only that much control over.

    And that is why I don’t really get this striving for perfection in naming.

    I see the right explanation of whichever words we choose to use as way more important challenge. I can say capability, or throughput, or thingamajig. As long as people know what hides under the name it’s going to be fine.

    This is by the way something I realized a couple of years ago on a session dedicated to translating Agile Manifesto to Polish. Even though probably we all understood the same values we found it really hard to put it into words of our native language in a way that was satisfactory to all involved.

    My realization was: “Whatever. As long as people understand the values wording doesn’t matter that much.”

    My appeal to thought leaders: whenever you are fine tuning the naming, remember that there are many people who just won’t get the difference. Good explanation is way better than good naming.

    And we still suck at explaining even basic concepts.

    You guys may think this whole translation thing is a non-issue and maybe for you that is correct. Remember though there are big parts of the world where English is neither the only nor the first language people use. It’s worth to remind about that from time to time. So I do.

  • Effective Standups around Kanban Board

    You can hear here and there that Kanban scales up pretty well. Actually one of Scrum issues, and I believe one that isn’t addressed neatly, is what to do in projects that take more people than a single Scrum team can accommodate. Definitely one thing which is surfaced pretty soon as Scrum team grows is standup meetings.

    As you go with three standard questions through growing team it naturally takes more and more time. Soon it can be a problem to fit into short time-box you have for such meetings.

    When team are adopting Kanban they usually leave standup unchanged. However it means that, at some point, they face the same issue as Scrum teams do – 15 minutes is not enough anymore.

    Recently Jorn Hunskaar shared such story on his blog. It prompted me to combine a bunch of ideas into a single answer that can be a guide how to improve standups organized around Kanban board. I left a lengthy comment on Jorn’s blog although I believe it is worth to share the idea here as well.

    Instead of running typical round-the-table with answers about what happened yesterday, what is going to happen today and what issues are there you may try to redesign the pattern you follow on standup.

    • First, go through all the blockers (if there are any). These are definitely your pain points at any given moment. It means that you definitely want to invest precious standup time on blockers. This is no-brainer.
    • Second, discuss expedite or emergency items (again, if there are any). This is top priority work from the perspective of the whole team. This is something you really need to get done even at cost of delaying other work. Again, something which is worth investing scarce resource into.
    • Third, go through items that hasn’t moved since last standup. These are items which may be risky. Maybe they weren’t supposed to move but in this case it would be a quickie – not much discussion needed. Otherwise it is worth to have a brief analysis what happened that prevented moving cards forward. By the way, it means that you should have some kind of mechanism to mark index cards which aren’t moving, which is usually tricky.
    • Fourth, go through everything else. One more guidance you can have is discussing items of one class of service after another in order of priorities. In other words you start with highest priority class of service (bugs, critical features or what have you) and discuss all items of this class of service. Then you move to another one. Well, at least this can work considering that you can tell which class of service is more important than other.

    One more rule would definitely be reasonable: within each of these groups you start from the right side of the board and go to the left. This shows that the closer an item is to being done the more you want to discuss it as you are closer to complete it, thus bring value to your users, clients and stakeholders.

    Now, up to this point there is little difference – you still go through every single work item which is on the board. There is different focus on issues and you may skip discussing obvious pieces of completed work but still, a lot of stuff to go through.

    However, given that you’ve just sorted topics to discuss by priority you can just use a simple trick and just finish discussion when the time of the meeting has elapsed, no matter if you were able to finish all the things. It likely means that you’ve covered all the items from first three groups, and definitely all of them from first two, and whatever leftovers you have are items which require least discussion or no discussion at all.

    It also means that on a good day you can cover all things, or more things than on worse day, but that’s perfectly OK. What you basically need is to ensure that most important stuff doesn’t go unmentioned.
    Going a step further means that you can skip a discussion over a specific groups or sub-groups of items, e.g. a specific class of service, when you see it doesn’t really add any value. If you aren’t sure try to cover it during standups and see what outcome you get. Then you can start experimenting with the plan of the meeting.

    Ideally, after some time, you will end up discussing only important stuff, say, blockers, expedited and stalled items and maybe others which are brought by any team member for an important reason and just skip regular work which needs no more attention than a silent confirmation that everything is perfectly fine.

  • Visual Management

    When I’m speaking at different events I usually keep evangelizing Kanban. Well, it’s sort of easy when you speak to an audience which is aware of this whole Kanbanish thingamajig. They may be even wrong when it comes to answer what Kanban really is but we still have a common starting point.

    The challenge starts when you try to ignite with the idea people, who not necessarily are aware of agile, lean, craftsmanship, whatsoever. Oh, maybe they even know something on the subject but they aren’t that much into it.

    Let me explain myself a bit more. If you go to a conference like Lean Kanban Central Europe (and you definitely should) you can safely assume people know the basics. On the other hand, when you go to a regular software development, let’s say Java, conference where you face folks who came there to see, well, Java stuff you can’t assume they’re all crazy about software craftsmanship, agile, lean or whatever is hot these days.

    So the question is: how do you reach these people with the stuff you believe in?

    In my case I work in the context of Kanban, so I started thinking what a gateway drug to Kanban is. My answer for this issue is…

    Visual Management

    I once wrote that visualization is my favorite part of Kanban. I also confessed that I started consciously using visualization apart from Kanban as a separate tool.

    And I want you to follow me on this path. I don’t set any pre-requisites. You may be a regular attendee on agile and lean conferences and know Kanban by heart. You can also be ignorant in terms of all that stuff and visual management should appeal to you as well.

    This is what you’ll see me advocating on occasions. OK, what is visual management? If you go with Wikipedia definition you will learn that…

    Visual control is a technique employed in many places where information is communicated by using visual signals instead of texts or other written instructions. The design is deliberate in allowing quick recognition of the information being communicated, in order to increase efficiency and clarity. These signals can be of many forms, from different colored clothing for different teams, to focusing measures upon the size of the problem and not the size of the activity, to kanban and heijunka boxes and many other diverse examples.

    In other words we use simple “visual signals,” which may be sticky notes, color pins or magnets, graphics, etc to share information among a group of people. How?

    I could have been describing how one can apply visual management in their team but let me do it in more visual way. Yesterday I had a session at ABB Dev Day, which was a very nice event addressed to developers. When I say “addressed to developers” I think that I have no freaking idea what I was doing there as my last code check-in is dated to 2003 or something. What more, my session was probably the only one which didn’t show or mention the code in any way. Now you understand the challenge I chose to face.

    This is how I tackled the challenge

    Visual Management

    By the way: If you happened to be at ABB Dev Day please rate my session and/or leave feedback.

    I owe you a few words about the event itself. First of all, kudos for hosts for organizing high-quality free event. It reminds me good old times when local branch of Microsoft was organizing such events twice a year spreading the word about their technologies.

    Despite no one paid to be there the room was full until the very end. To be honest, it doesn’t come as a surprise really as sessions were interesting, even though they touched a surprisingly wide range of subjects. One thing I could complain about is networking, which didn’t work that well, but it’s always tricky on 1-day conference where there’s no evening event and everybody is in rush to come back home.

    From a perspective of a speaker I can’t say anything but I’m totally happy with how I was handled by hosts. In other words, if you have a chance to speak at the next ABB Dev Day, don’t hesitate even for a minute.

    And if you want to hear me speaking on visual management, and sharing my passion for putting everything on the wall in your office, and spreading my love to whiteboards and sticky notes, just let me know – we’ll work something out. As I’ve already told you there are no pre-requisites – it is a tool for both beginners and vets.

    As my last slide says: Try it! You won’t regret.

    Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • Communication: Quality versus Quantity

    I believe in transparency and openness. I believe a manager should share almost as much information as possible with their teams. I believe the manager should always explain their motives and drivers of decisions they make.

    In short I believe in much talking.

    Sometimes when a meeting is finished I don’t feel as if I convinced my interlocutor to a decision I make. That’s fair. That’s fair as long as I tried. This basically means a lot of talking.

    However, I learned a lesson today about talking much. After my lengthy tirade which I wanted to explain myself with I heard a response:

    “You should have said: ‘trust me’ in the first place instead of all that.”

    Ouch. That hurt. I mean why haven’t I thought about that? Yes, it is a simple message but a powerful one. The message which makes or breaks the relationship. After that you either live up to expectations or there’s no chance of building trust whatsoever. Yet, as long as you actually plan to do the former, it will yield better results.

    My lesson is: yes, transparency and openness are important but it doesn’t necessarily mean more words. At the end of the day it’s about communication quality, not quantity (if you can’t go with quality go with quantity though).

    And this is the lesson I’m thankful for.

    By the way: we often follow our emotions instead of facts. I don’t say it’s bad. It’s just something to remember when dealing with people.

  • Visualization: Don’t Get Attached to a Specific Tool

    If we are in Kanban world when we think visualization we see a Kanban board. We see a process mapped into columns with limits attached to them. We see sticky notes, which represent minimal marketable features. We see additional visuals which help to show priorities, blockers, people who are responsible for a task etc.

    We mentally substitute visualization with the Kanban board.

    To some point it works great. Well, after all it’s not without the reason that a Kanban board, or more generally a task board, became a tool of choice of so many teams.

    However, it was never written that one of few Kanban rules is using Kanban board. Please point me to such advice if I’m wrong. Anyway, the rule is about visualization and Kanban board is only one of possible means to this end.

    One of great lessons from Kanban Leadership Retreat was how many different approaches are possible in terms of visualizing work. Actually typical Kanban board looked kind of boring among that bunch of great folks as basically everyone had at least a couple of ideas how it can be done differently, depending on a specific situation of course.

    The message is: it doesn’t really matter how you visualize your work as long as you are successful at that. Task board or Kanban board is fine, and it usually is very intuitive to use by a team, but quite often there are better ways to do it.

    Consider a situation where you deal with a lot of small tasks. Do you really need to put each and every 5-minute-long tasks onto a post-it? Maybe there are more efficient ways to deal with them?

    On the other hand, what about tasks which last long months? As I’m playing with project portfolio level Kanban it is a very timely question for me.

    A classic form of the board, which I currently use, isn’t likely the best possible approach. I have at least a couple of ideas how to change it. And yes, now that you asked, I was totally inspired on Iceland event to improve my project portfolio Kanban board.

    Probably it won’t be a Kanban board as we know it any more. I will still use stickies and whiteboard but it’s not going to look like any other board I’ve had so far. And that’s the real lesson I got on Kanban Leadership Retreat.

    Don’t get attached to a specific tool. Kanban board is just a tool. Visualization is way, way more than that.

    It’s kind of funny to realize how we learn to treat some things as obvious, like having Kanban board as a part of introducing Kanban. Fortunately, at some point of time we just realize it’s only a tool and we should use it as long as it is useful. If it’s not it’s better to use another one.

    Advertisement: Want to have such nice Kanban boards in your presentations as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • Give Honesty a Try

    I use to say that you can’t lose being honest with me. There is no potential downside – only upside. I have no problems with critical opinions on me, others or the organization we’re part of. I don’t necessarily have to agree with these opinions but I want, and need, to know them. After all, if I don’t know you don’t like something odds are I won’t do anything to change it.

    I know there are different managers out there and openness and honesty don’t have to work equally well in each case. However, if you have to hide your opinions and play someone else to survive in a decent health in the organization then, well, I wouldn’t like to be a part of such company in the first place.

    For the sake of this argument consider you really can openly talk with your bosses about your problems and frustrations, if you have any. Will you just be honest like you’d be when describing the situation to your friend over a pint of beer?

    From my experience: many people are not.

    I don’t get it. Let’s say my decision pissed you off or you felt my opinion was unfair. We can sit down and discuss it through. I make mistakes. Everyone does. I change my mind when I face reasonable arguments. So please, challenge me. Challenge my opinions and my decisions.

    When your only reaction is venting in front of your colleagues then you do no good to me, to the company and, most importantly, to yourself. What are you trying to achieve that way? Is that what you believe works in the long run? I mean, really?

    If you choose being honest, be honest consequently. Being so only to some point is um… quite the opposite of being honest.

    I have one more advice: even if you don’t trust your manager give them a try. Maybe they won’t appreciate your open and straightforward attitude. In such case your situation will suck anyway so you don’t lose much. Fortunately, there are many managers who don’t work that way and you just can’t lose being honest with them.

    Like me, for example.