Pawel Brodzinski on Leadership in Technology

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

Tag: communication

  • Respect (and How It Makes or Breaks Culture)

    Respect (and How It Makes or Breaks Culture)

    It seems my Milk Kanban article has made a stir. I kinda expected some backlash along the “it’s not really Kanban” lines. However, when the post hit Hacker News, I got a swath of remarks attacking it from a different angle.

    The problem is, as the comments go, that someone’s job is outsourced to random colleagues. In this case, it would be Kasia (our office manager) outsourcing her job (ensuring that the office is supplied with milk) to macchiato drinkers who can’t be bothered because they have more important stuff to do.

    Oh boy, where do I start?

    Get Out of Your Cave

    It took me quite a while to grasp that some commenters perceived managing the milk supply as a priority job for an office manager.

    Yes, I know our context so much better; we’re a small company, and everyone wears multiple hats. But even in big organizations, I’d be shocked if such a matter was anyone’s top priority.

    For Kasia, it’s like the 100th thing on the list of stuff she takes care of.

    But again, even if we consider a generic example, it would be so easy to figure out how many things, big and small, an office manager takes care of. Then, there’s probably twice as much of stuff that’s not visible on the surface.

    I mean, any developer, whose primary task is working with code that’s inherently invisible, should grok that concept.

    Effectiveness versus Efficiency

    However, then things only get more interesting. Even when people considered doing something to help, they’d instantly play the efficiency card.

    “I can’t be bothered to let someone know that we’re running out of milk because I’m doing this important work, and me being a 10x developer requires absolute focus.”

    Weird that they have time for a coffee break then, but what would I know?

    But yes, having someone do 30 seconds of work, which may save someone else 10 minutes, is a sensible tradeoff. Even if the latter is paid less. Even if that half a minute wouldn’t be efficient.

    That’s the most basic effectiveness versus efficiency consideration. I can be efficient as hell, but unless we, as the whole team, can reliably deliver value, it doesn’t matter.

    It’s the equivalent of a developer whose coding pace would be fabulous, except there would be no one to code review or test their features. They may feel like they were being productive. The team, however, would be so.

    In fact, the amount of work in progress they’d introduce would make the team less efficient. It would introduce more multitasking, more rework, and more context loss.

    One has to wonder whether people showing such a lack of understanding of how the whole organization delivers value should really be valued as highly.

    A narrow focus on efficiency, especially in an isolated context, is typically detrimental to the effectiveness of the whole process.

    Respect

    However, if anything in that discussion makes me sad, it’s the lack of respect.

    “If checking the milk reserves once a day is too much of a pain for a person hired as an office manager, the person should self-reflect on his/her choice to take the job.”

    And that comes from developers, a group that is notoriously crappy at filling time tracking data, even when companies rely on that data to bill clients.

    However, my beef here is with a lack of respect for another job. Yes, this job is not paid as well. But I’m sure as hell that as much as an average office manager would fail miserably if they were to do software engineering, an average developer wouldn’t fare better in an office manager’s shoes.

    In our case, just as an example, we’re yet to have a single foreigner who wouldn’t be deeply grateful to Kasia for help with all the formal stuff related to employment papers, work permits, etc.

    In fact, it would be easier for us to lose a couple of our best engineers than to lose Kasia.

    The point is, though, that it doesn’t even matter whether we really understand someone else’s job. It matters whether we respect it as a part of the bigger whole.

    If not, it’s easy to boil it down to “I want my goddamn coffee to have milk, and someone better make sure I have it.” It’s easy to subordinate everyone else’s work only to whatever I might need of them. Then, of course, people won’t be willing to spend half a minute helping anyone with anything. Even if that someone makes sure that the milk is in the cupboard.

    I understand that in many companies, this is the norm. People are not respected, and, in turn, they don’t respect others. They won’t be willing to help with anything that’s not explicitly their assignment.

    It’s not a Milk Kanban problem. It’s a (lack of) respect problem.

    Now, establishing respect as a part of organizational culture is so much harder than making the milk supply work effectively.

    Wrap Up

    I understand the specific context of these comments. The software industry made us, in a significant part, spoiled kids. It’s still easy to sustain a lucrative career by focusing only on one’s technical skills, individual tasks, and not much more.

    I’m not necessarily surprised by how the comments disregarded the work of others, the broader context, and common goals. The sentiments, though, are not unique to software developers. I see a lot of similar attitudes in management.

    And the ways of dealing with the issue will be similar. Understand others’ roles and jobs. Understand the difference between group effectiveness and individual efficiency. Most importantly, respect others and their contributions.

    Milk Kanban or not, it’s easy to get enough milk in a cupboard. Building a culture of respect, on the other hand, is damn hard.

    And it starts with the very people who have disproportional leverage on the organization. Yes, the same folks who tend to earn more and fill the most prestigious roles.

  • Can One Be Too Respectful?

    Some time ago, during our weekly Lean Coffee at Lunar Logic, which is the only all hands meeting at the company, I made a disrespectful comment. It was a topic which I have a strong opinion about. A particular example that was brought to support one argument triggered a visceral reaction on my side. I said more, and more emotionally, than I should have.

    A day after I asked people for feedback to understand better what had happened and how I could avoid crossing the line in future. The recurring theme was that the way I expressed myself, both the words and the form of my remark, was disrespectful to some.

    That triggered another discussion some time later, and in a smaller group. It was about the meaning of being respectful and its implication of our behaviors in all sorts of situations.

    We started with an assumption that being respectful means acting in a way that doesn’t hurt others intentionally. But hey, there’s the whole unintentional spectrum of effects. Luckily, we are pretty good at sharing feedback and being transparent in front of each other. This means that when someone unintentionally crosses the line it is likely that they will hear a comment referring to that behavior being disrespectful.

    Going forward, with such stuff a natural desire is to be on a safe side. In other words, if I have doubts whether saying something would be disrespectful to someone I should not say that. It’s a safe choice.

    And that’s exactly where we started questioning ourselves. Doesn’t our aspiration to be respectful affect how we act in less obvious situations? Doesn’t it mean that we restrain critique, harsh words, or confrontation even when we believe that they would otherwise be justified? Doesn’t we restrain ourselves from being authentic?

    As a matter of fact, there can be two different sources of such a restraint. First, someone may be worried that criticism or confrontation itself would be received as disrespectful. After all, we are subjective; we may have opposite points of view and we can only control how we express our thoughts, not how they are received by the other party. We may do as much as we can to talk and behave in a respectful way but ultimately we can’t control how our attitude and behavior will be interpreted.

    Second, and more importantly, most of us has neither enough skill nor practice to be able to react in such a respectful way contextually. Even if we could succeed given that we prepare, e.g. when sharing difficult feedback, we would fail to act similarly when caught off guard, e.g. in an unexpected discussion about a topic we have a strong opinion about. And I don’t use it as an excuse. I make a simple observation in the spirit of starting with what we have.

    Now, if being respectful is our guiding principle we may choose not to speak up, rather than risk hurting someone. That would mean that we suppress conflict, feedback and idea cross-pollination. That would mean that we suppress our development both as individuals and as an organization.

    The question we were staring at was: can we be too respectful?

    Can we bring respect to the level when it is not justifiable anymore? Can being respectful yield unwanted outcome?

    Intuitively my answer was negative. And yet I couldn’t discard the argument as a whole since I’ve experienced the dilemma myself.

    The thing is that respect is a nuanced thing. The same behavior may be perceived as respectful by one person and as disrespectful by someone else. The same behavior may be perceived either as respectful or as disrespectful by the same person depending on whose behavior we put under scrutiny. The context matters. The group setup matters. The mood matters. And the list goes on and on.

    In a way, we can’t design a set of behavior that would be universally respectful. Well, not unless we are really,really far on the safe side. This, as we already established, would have some unwanted outcomes.

    And yet one of these catchy phrases I picked from Stephen Parry kept my mind working.

    Showing respect for people does not mean you have to like them, agree with their views, or fail to challenge any half-baked reasoning they may have.

    My thoughts were that we might have been using “respect” in overly broad way, like a wall shield rather than a buckler. However, I couldn’t wrap my head around something that would provide some guidance where the line should be. After all, Stephen’s remark focuses on what respect is not and not on what it is.

    Then I came across the following passage from Ray Dalio:

    Make sure people give more consideration to others than they demand for themselves.

    It is more inconsiderate to prevent people from exercising their rights because you are offended by them than it is for them to do whatever it is what offends you. That said, it is inconsiderate not to weigh the impact of one’s actions on others, so we expect people to use sensible judgment and not doing obviously offensive things.

    This principle, in a neat way, connects the dots in both directions and through that it addresses the risk of being “overly respectful” through suppressing oneself. It creates responsibility on each party involved in an interaction.

    A party that is about to do something that may potentially be disrespectful is bound to use sensible judgement and assess whether such a behavior can be commonly perceived as offensive.

    The other party, on the other hand, takes responsibility of using “the respect shield” sparingly, as if it was a buckler protecting the most sensitive areas and not a wall shield covering from literally everything.

    This way we create some sort of a middle ground when it comes to respect. We don’t call out all behaviors that can potentially be perceived as disrespectful. We don’t even call out some that touch us personally, assuming good intentions and acknowledging that people have different standards. What we gain thanks to that is an environment where there is a space for more contributions from everyone.

    There’s another consequence. Such a notion of respect, which accepts more behaviors, means that when someone calls “disrespectful” it is a strong signal that the line has been crossed. After all we may assume that such a call was considerate and took into account that suppressing someone else without a good reason is disrespectful too.

    Of course, maintaining the balance doesn’t come for free. It requires consideration. On one hand there’s a risk of extending that middle ground of consent too far. It would happen when we start accepting behaviors that are hurtful. On the other hand there’s a risk of shrinking that space too much. It would happen when we give less and less slack to others when they act out.

    The principle, however, provides us with a pretty good reference point: give others more consideration that you expect for yourself. That’s how we can avoid being both disrespectful as well as suppressing ourselves in a fear of being overly respectful.

    Should I know this principle I wouldn’t have said as much in the situation that kicked off this whole thinking process. Yet still I would still make my point strongly, even at the risk of other party feeling attacked by the strong statement. And that would probably have been the best possible outcome.

  • On Feedback (Again)

    I’ve heard that question quite a few times after I shared my feedback with somebody: “What am I supposed to do with such feedback?”

    The question may imply that feedback e.g. wasn’t “actionable” or something. Anyway, I have an answer for that. It goes:

    “Whatever the hell you want.”

    Yup. Exactly that. In fact this is precisely what I’d love you to do.

    As the opposite to: getting defensive, explaining yourself, finding excuses, bringing other interpretations, and so on and so forth.

    Feedback is not an attack. You don’t need to defend yourself. It isn’t an interrogation either. You don’t need to explain yourself. And most of all it isn’t a goddamn appraisal. You don’t need to maximize the score.

    It is feedback. I’m sharing some observations and opinions that somehow relate to your work, actions, behaviors, attitude, etc.

    I don’t intend to change you. I want to provide you with more information so that your decisions about your further course of action are informed better. You can disagree with the part or the whole of the message you get. You can interpret it in a vastly different way. You can confront that with other feedback that is contrary to mine. That is all just perfect. You can ignore it altogether and I’m still fine with that.

    Remember? Whatever the hell you want.

    The reason is I know it is subjective. No matter how much I try to make it factual it is always about interpreting facts. And I don’t try to make it purely factual. In fact, the system in knowledge work is built of people and interactions between these people. How objective can “facts” about interpersonal relationships be? Is there even an objective truth there? Or is it rather a combination of interpretations that can be more or less aligned one with the other?

    So no, I’m not trying to convince you that my point is even valid. It’s how I perceive specific situation and how I feel. Oh, it isn’t factual, someone would say. Well, the fact is that I perceive and I feel so and so. Do you want to discuss with such a fact? Didn’t think so.

    I am well aware that my perceptions and my feelings aren’t universal truths. That’s why it is you who decide what to do with the feedback or whether to do anything at all.

    There is the other part of the story. I sometimes receive feedback and I’m like “Thank you. I’m not going to change that.” What I see as a reaction is that someone is either discouraged or even pissed off with my reaction.

    I mean, they did expect me to comply with what they shared with me. I don’t differentiate here feedback on work I do from feedback on my behaviors. It’s just, for whatever reasons, I decide that I don’t want to change that specific thing.

    That doesn’t make me any less grateful for feedback I got by the way.

    It’s just that now we turned the tables. Now it’s: Whatever the hell I want.

    If you want to make me compliant with whatever just make it explicit. At least we’ll have common understanding.

    Feedback’s role, the way I perceive it, is not compliance. It is providing information about one’s behaviors, actions and attitudes and their impact. It is, as its name suggests, about feeding one back with information, not about changing one or making them doing what somebody else want them to do.

    If you give me feedback with a clear intention to change me or even worse to make me do what you want you are likely to end up being disappointed.

    It will happen despite the fact that I treat that feedback as factual and fair. It is factual since fact is that you think and feel whatever you think and feel. It is fair for the very same reason.

    At the same time it is subjective. Objective feedback, as long as it touches interactions between people, is a mirage. Or an oxymoron. Stop pursuing objectivity. To make it clear: it doesn’t make such feedback any less valuable.

    Once we understand that it enables the whole new level of discussing feedback both ways.

    Ultimately it’s: “I share that with you. Do whatever the hell you want with this.”

    And: “Thank you for sharing. I will do whatever the hell I want with this, indeed.”

    Only then it truly is valuable feedback.

  • Personal Ritual Dissent

    If I got a dollar each time I heard someone mentioning that they’d like to get more feedback I would be filthy rich by now. Heck, if I got a dollar each time I personally said that I would still got a decent sum. Most of us do want and like to get feedback. Most of us would love to get more of that.

    There’s obviously one thing to consider, which is what kind of feedback and received in what context is most useful for us. I’ve heard a lot of theories on that. One example is that we should always focus on positive or supportive feedback as people would improve their weaknesses subconsciously while they’re working on their strengths. Another is infamous feedback sandwich, which tells that each critical bit should but in the middle of two supportive ones. There are dozens of these.

    On one hand there’s a bit of truth in each. On the other I call bullshit.

    I don’t believe there’s a single, universal way of delivering and / or receiving feedback that works in majority of cases. Personally, while I like to hear positive feedback as it makes me feel good, I really learn when I get critical feedback. In fact, it doesn’t even have to be very constructive or factual feedback; I typically can make much sense out of non-constructive opinions too. And I don’t give a damn whether you add a sandwich to the mix.

    There are better ways of delivering feedback when we think about an individual context, but there is a universal answer in a general case. This means that the most useful feedback should be adjusted to the person who receives it. A nice thing is that we can tweak the situation so we get what works for us.

    If you learn from feedback in a similar way that I do, meaning that critical feedback is what makes you change, the following part is for you.

    I learned about the idea of ritual dissent some time ago. Back then I didn’t even know that it is Dave Snowden who should be attributed for creating it. Anyway, the basic idea is to create a situation where a group tears an idea apart looking for all the potential risks or holes. After a spokesperson presents an idea while everyone else remains silent, there’s a part when everyone dissents the idea while a spokesperson remains silent.

    There may be two goals in doing that. One is obviously improving the idea itself by making it risk-proof. The other part is that ritual dissent can be treated as a listening exercise. It’s not that easy to remain silent when someone tears your idea apart. At the same time this is what differentiates it from a futile discussion full of personal opinions.

    So here’s an idea: if you look for critical feedback you can use the same pattern in a personal context.

    No, it’s not a theoretical idea. I’ve done that.

    It hurt. A freaking lot.

    And I got more of what I wanted in half an hour than over the course of past year.

    And it was awesome. Once emotions wore out, that is.

    The thing is that adopting ritual dissent in personal context is, well, very personal. I was asking to be criticized. In fact, not-critical feedback was forbidden. No matter how much I learn from critical feedback it was nothing pleasant.

    I would even consider that idea as “don’t try that at home” one unless one has self-awareness in terms of how they’re going to react for such critique. Having a psychologist around when doing that wouldn’t be a bad idea.

    There are a couple things that make it work but two are essential. One is trust. I don’t say that everyone needs to fully trust a person being dissed. What is full trust anyway? However, there has be a decent level of trust so that anything that gets said won’t be used again anyone in any way. It may make the whole thing a bit tricky especially for managers or leaders where some sort of power relationship is involved.

    At the same time there’s a lot of followership. Once a few people who feel safe start dissenting others join. Especially when they see that a dissented person doesn’t break the rules and keeps the mouth shut.

    Another thing that makes personal ritual dissent work is listening, which is an inherent part of the exercise. It is a double-edged sword. On one hand the dissed person remains silent so the whole thing doesn’t turn into futile discussion. On the other the silence creates the pressure on the group. Someone eventually has to speak up even if it means going out of their comfort zone.

    An interesting thing is that it’s nothing pleasant on either end. The exercise, which we run mid-day, was basically a killjoy. At the same time it spurred a lot of spin-off discussions afterwards, which is a reason why I wouldn’t do it at the very end of a day.

    The best part is that getting critical feedback is not the ultimate value of the exercise. Since it creates a lot of tension and moves people out of the comfort zones it breaks some mental barriers that people had, thus makes sharing feedback later way easier.

    After all sharing one critical opinion is nowhere close to dissing someone collectively for half an hour in a row.

    Finally, some of feedback won’t be really addressed to the person who asked for a personal ritual dissent. It may be formulated in a way as it was so, but the real addressee would be somewhere else in a room and hopefully they’d get it too.

    So if feeling like shit for (at least) a few hours is a price you’re willing to pay for a ton of valuable feedback, this is an idea for you. Would you dare?

  • Better Standups

    I never fancied the standard standup schema. I mean I see value in sharing what the team did yesterday what the team is going to do today and what are the problems the team has.

    Except these questions aren’t answered on a typical standup.

    The first problem is that we answer what specific individuals have done and will do. In any but smallest teams it’s the wrong focus to have. I mean if there are two or three of us it’s very likely that such updates are meaningful. With a couple more people we gradually lose track, and eventually interest, in what exactly is happening in the rest of the team.

    At the same we should be focusing on what is important for the team which may be something no one mentions because for example the biggest pain point is on a plate of someone who is absent or overwhelmed with other stuff that just doesn’t allow them to focus on the real problem.

    The second problem is that very rarely someone really answers to anything by first two questions, namely the issues part is often omitted. I like tweaking the third question, for example to something that Liz Keogh proposes: ”what I would rather be doing.” It helps only a little bit though as it’s almost as easy to avoid this question as the original one.

    The third problem is that with a bigger team a standup becomes just long and boring, and whenever a couple of people exchange a few sentences about any specific bit of work it shuts down almost all the rest of the team instantly.

    A very typical change I introduce is a standup around a board, be it a task board, a Kanban board or what have you.

    Then the discussion is mostly around important stuff that is happening right now and is visualized on the board. A typical pattern is: blockers first, expedite items second, stalled items third and then all the rest. I covered more elaborate version of this approach some time ago.

    Such an approach means that not everyone, every single day speaks up. But whenever anyone has a problem or is just trying to solve an issue too long there’s definitely an update from them on the way.

    Then, there’s always a call for action regarding important stuff, even if it just so happens that a default person for that item is unavailable.

    This means that standups around a board encourage collective ownership of work.

    In fact, there are way more call for action situations as this form of standup basically focuses on solving issues. This often means helping each other, taking over bits of work from others, etc. Whenever someone has hard time coping with all the stuff that waits for them they usually get an instant help.

    This kind of a standup is also shorter than a classic one. After all you don’t mention all the boring stuff that just goes as planned – everyone can see that on the board, so what’s the point anyway?

    It also is an occasion to catch all the inconsistencies on the board so it serves another purpose too. You don’t get that from a classic standup.

    I would also point that this approach does very good job in terms of keeping work in progress low. It simply changes the dynamics of the discussion toward everything that is in progress from a team perspective instead of work started by individuals. The latter doesn’t take into account all the waiting queues.

    Finally, it scales up pretty well. You can run such a standup with a dozen or more people and it still fits nicely 15 minute slot. It’s not rare when you need only one third of that even with such a big team.

    The impact of changing the standup pattern is almost instant. All in all, it makes standups more valuable for the team. Try this approach, especially when you struggle with the current one right now.

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