Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • The Worst Management Task Ever

    If you asked me to point a single thing, which I hate most in senior management role, I wouldn’t have any problems with the answer. It would be firing people. On my personal hate scale there’s firing, then huge, huge void and only then other unpleasant things and tasks to do.

    Each time I fire someone I feel like a complete jerk. It doesn’t matter that the decision is well-grounded. It doesn’t even matter when I’m proven, after some time, it was the right choice. It isn’t any easier.

    And the next time you do it doesn’t become any easier either. I mean if executing such decisions is easy for you and you feel comfortable firing people there must be something seriously wrong with you.

    Yet I still think firing people is extremely important part of pretty much any management job. If you’re a senior manager you likely have power and authority to make such decisions. If you’re a team manager dealing just with your team of six or something and you don’t have that much of power, you still can convince your superior to make a tough move. Sometimes the latter is even worse as you have to do all the talking as it is you, who started the whole thing.

    OK, why is it so important then? Because this is one of methods of building great teams. As harsh as it sounds: sometimes you don’t have enough resources (meaning: time, patience, money) to make a person act on acceptable level and the best thing you can do is to split your ways.

    Don’t get me wrong, my advice still is: do everything you reasonably can to fix an underperformer. I know way too many people who started shining when given a second chance to say otherwise. But then remember that it’s a manager who is responsible for building the high-quality team, so if you just accept the underperformer in the team you basically harm the team on many different levels.

    What more, sometimes we’re out of luck and we don’t have all the time and money of the world to try virtually every possible thing one could think of. Sometimes our fixing options would be limited. Sometimes constant resistance of the underperformer will make us lose faith faster. Shit happens. We don’t live in ideal world. And then it’s time…

    Well, for many managers I know then it’s time just to accept the fact someone is underperforming. And you know what? I understand them. I understand them because firing people is so damn hard and so freaking unpleasant that I can think of thousands of reasons why I shouldn’t do that. At all. So yes, I can perfectly understand them.

    But I don’t agree with them. We are paid to do our jobs even when the jobs suck on occasions. When we make our developers write boring documentation which just has to be done it works similarly. The only difference is in level of responsibility. But we still expect our developers would deal with crappy tasks, don’t we?

    Having balls to fire people isn’t something which makes a manager. In fact, with a bit of luck we won’t need to fire anyone for years and will be able play the role of guru manager neatly. However, when time comes you better be ready to deal with the worst management task ever. Otherwise your whole team will be constantly taking big hits on morale and you no longer will be considered a rock star manager.

    If you’ve just lived through such situation for the first time I have two messages for you. First, it’s one of the most valuable experiences as a manager you can possibly have so good for you. Second, yes, I know how crappy you feel now and it’s not going to become easier next time you do this, sorry.

  • Kanban: When It Is Hard to Map a Process to a Kanban Board

    I was asked for an advice the other day:

    “We have a problem with mapping testing stage into our Kanban board. In ideal world we would test a feature once it is developed, and deploy it on client’s testing environment if and only if every bug we find in the feature is fixed and verified. Unfortunately the reality isn’t that nice – pretty often we deploy a feature even though testing isn’t finished or some bugs aren’t fixed. Sometimes the feature passes user acceptance tests (UAT) even though there are known, sometimes even major, bugs on our side. It introduces a mess into the Kanban board as we have features shown as under testing even though they are already deployed so basing on the board it is hard to say what exactly is happening with a specific feature.”

    One of answers could be: fix your damn development process and bagger off. However I don’t count it as a good answer really. I mean yes, it is broken process which generates mess so we should work on that as well although it’s a longish discussion and it’s definitely not my point here.

    My point basically is: if your process doesn’t suit your Kanban board, adjust the board otherwise every time you look at the board trying to make a decision you will stare at fiction. You don’t want to make decisions basing on fiction, do you?

    OK, in this case a starting point looked something like that:

    The basic problem was that in reality testing was done throughout testing, deployment and UAT phases. Even worse, given that it’s a client who says the feature passed UAT, meaning the exit criteria is acceptance from the client, it was possible that testing was still ongoing while the feature formally was at the right edge of the board (UAT done).

    In short: when looking at the board it was impossible to say which features have been tested, which are being tested and which are yet to be tested.

    A question: how to map such situation into linear process, which we usually have on Kanban board? Well, you basically can’t do it. Fortunately, and correct me if I’m wrong, we were never told that we need to map everything into a linear process. Actually we weren’t even told we need a Kanban board. We were just told to visualize workflow.

    Coming back to the point, we ended up with a conclusion that in this case testing is an ongoing activity happening concurrently during a big part of the whole process. Digging deeper we decided that basically there are only two types of bugs related to any feature: these which would block us to use the application in production and those which wouldn’t. It doesn’t really matter whether a bug is minor but the client insist on fixing it or an issue wasn’t found by the client but from our perspective it is a major problem – we just wouldn’t push the application with this feature into production.

    What struck us at that point was that such information can be easily attached to a feature: we potentially could use a feature safely or not. It’s not a stage of the process – it is a status of a feature. Why shouldn’t we show it as a feature status though? Say, a small red sticky note attached to a feature when it isn’t good to go and a green one when it is.

    To be perfectly compliant with Kanban rules we should make the policies explicit – what does it mean that a feature is or is not good to go? At this point, it was pretty easy. A feature isn’t good to go either when its testing wasn’t completed or we have at least one unfixed blocking bug submitted to this feature. In such situation we should have a small red sticky attached to the feature. On the other hand, a feature is good to go when its testing was completed and there are no open blocking bugs. In this case we attach a small green sticky to the feature.

    One more tweak which was pretty obvious: as we want to distinguish features which we’ve started testing from those we haven’t, we attach small red sticky exactly at the moment when testing starts.

    The board after changes looks like that:

    Looking at the board you can tell that feature C went through internal tests and there are no known blocking bugs. On the other hand, feature D which is at the same stage of the process (UAT) isn’t good to go, for whatever reasons. We also have a situation where feature B, which passed user acceptance tests (UAT) have a red sticky attached to it, which means there is still something wrong with it – most likely a bug found internally but the one which is important enough that it has to be fixed before we consider a feature done-done.

    We can also easily distinguish features which are being tested from those which aren’t. Features F and H are of the former group and features E and G are of the latter. Note that feature E is on the later stage of the process than feature H and yet is wasn’t touched by a quality engineer even though the feature H was. By the way: it may be perfectly reasonable decision when you have to make constant tradeoffs what is more important and goes first and what is less important and waits for its turn.

    To summarize: what we basically did was we came back to roots. When teams start playing with Kanban one of the first things they do is mapping their current process into a Kanban board. It seems this activity isn’t exclusive for the first day only. On occasions we notice that our Kanban boards don’t precisely describe the process we follow and this is exactly the moment to review and improve the board.

    Another lesson here is that you shouldn’t try to adjust your process to simple constraints the basic board sets. If your approach is: the reality should suit my board and if it doesn’t so much the worse for reality, your board will quickly become irrelevant and you will get no value from it whatsoever. If the most basic methods can’t help to map your process into the board look for methods which work, even if it takes some more effort and creativity. The board itself is as flexible as it is physically possible. Given that you use the physical board that is. Use this power.

    And then, once you solved your own problem, don’t forget to improve constantly. In this case I have at least a couple of ideas for improvements but there’s no point in applying all the new ideas unless you validate the older ones. With the right mindset there will be a lot of occasions to try out new concepts with no doubt.

    If you liked the article check out The Kanban Story – a documentary of discovery and implementation of Kanban in one team.

    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.

     

  • On Making Difficult Decisions

    Occasionally I receive some flak because of one of decisions I make. Almost always it is one of those decisions which changes status quo.

    Let’s take an example: an employee has an offer from a competitor. You care about her so you try to keep her offering different things, e.g. transition to a better project, raise, etc. However you keep your offer rather reasonable. Basically you don’t try to do more than you would if there were no offer from the competitor. Unfortunately eventually the employee leaves.

    A question pops up: have you done everything you could to make her stay?

    Well, basically no. You could have paid premium or let her be prima donna or whatever but you decided you want to be fair with everyone in the team and not just make her stay at all cost.

    Now it’s time to receive criticism. Hey, you could have fight for keeping status quo. Forget everyone else, now she will leave and the whole world will stop. Aargh, we’re doomed!

    Um no, not exactly. The sole fact that you can do something doesn’t automatically means you have to, or even should, do it. Making a fair decision, even if it is difficult, usually pays off in the long run. In this case you play fair with the whole team even if it means losing one good employee. On the plus side, you mitigate a risk of frustration among many people in the team. Besides, let’s face it: shit happens, sometimes people leave. Unless you work in damn cool startup, that is.

    Anyway, every time you make such decision think about longer perspective and the whole team and not about tomorrow and a single person. It will help you to make the right choice.

    Chances are good you won’t be understood in the first place. I can almost guarantee you that you won’t be considered a hero. It is way more likely you’ll be dubbed as the one who doesn’t give a damn, even though that you actually do. After all you changed status quo.

    And this is why these decisions are difficult. Otherwise they would be easy and obvious.

  • Trainers, SMART Goals and Context

    Every time I’m on some kind of management training I have this vague feeling of disconnection. I mean I do assume a trainer is a competent person who saw way more different work environments than I ever would. They also are trained trainers meaning they know all the tricks how work with a group, what are effective learning techniques, how to make training entertaining etc. That’s what I expect after all.

    And yet, I can’t help thinking their knowledge is somehow shallow.

    To take the first example – for me it’s now time of performance appraisals. I spend long hours (days actually) talking with, and about, managers from my team. One of parts of such appraisals should be goal setting. Now, ask any of those trainers teaching you how to run a good performance appraisal and they would tell you that goals should be SMART.

    Great. The problem is pretty few of goals I set are really SMART. Does mean I’m a crappy manager?

    Well, many of those goals are hardly measurable. Let me give you an example. I, as a senior manager, care much about building trust relationships with managers in my team because I strongly believe it is a crucial factor of success for the whole organization. How should I, or my boss, set a SMART goal for me in this area? “Gain trust of n managers by the end of the year.” As if it was kind of badge or something. Darn trust isn’t measurable! And even if it was setting such goal would be just dumb. Is getting trust of more people better than getting trust of right people? And how do you define “right people,” huh?

    This is exactly the problem of many trainers. They have their recipes. They know how to sell them. The question is: do they care to come down to learn a specific situation, understand a real problem and adjust their tool to a context?

    Most likely they don’t.

    Thus my vague feeling of disconnection and difficulties whenever I try to apply trainers’ recipes in real-life situations. Well, I don’t really do that but I like to imagine I do and I point every single hole I see in them.

    It is a problem of reality. It is so painfully specific. It’s never general. It can’t be described with a set of rules which are always true. Yet I’m being told over and over again there are such rules. Rules, which just work. I would even believe in that but, unfortunately, every time I try to apply them they seem so irrelevant.

    What is my lesson today? Understand a context. Many rules may sound reasonable during training but unless you apply the context you can’t judge their real value. And few people are willing to sell you a difficult truth: it’s never about recipes; it’s always about people who use them.

    Advertisement: Atlantic Global – provider of Project Management software.

     

  • The Kanban Story: Skipping Part of Process

    The more complex your process, and your Kanban board, becomes the more likely it is you’re familiar with the following situation: you work on a task which doesn’t go through each and every stage of the process so you’d like to skip one of two of them.

    Consider a very simple board.

    What happens when we build a feature (feature E) where there’s nothing to be documented? What to do with a sticky note on the board? Should the process be changed?

    What happens when we have research task (feature H), which we don’t know outcome of, and we want to put it on the board? What if after research (development) we decide that it’s not going anywhere to a product? I mean we’re done with development but we don’t plan to do anything more about the task: neither testing, nor documentation, nor deployment.

    Before we go further I have another question: does this specific situation happen frequently? If not then don’t even bother. If it is an exception then treat it like exception. You don’t get points for following the process religiously.

    However, if it happens at least from time to time you should probably stop and think. One idea is redesigning the board in a way which incorporates such situation. Except you’ll likely end with conclusion that you have two different processes out there: one for regular development and another for research (or no-documentation development). So we come back to a question what to do with that?

    Well, you can split tasks into two boards but this way you either loosen your limits, e.g. additional limit for one research task, or you lose some flexibility, e.g. splitting your current limits among two boards. Either way I’m not a fan of the approach.

    What we ended up with in such situations was just skipping parts of the process which were irrelevant. No documentation? The sticky note goes directly to documentation done column instead of testing done. No follow-up after research whatsoever? Um, seems like we’re done done with this one so we should probably put the sticky note in the last column.

    Again, we don’t get points for being ideally adjusted to the process. The board should reflect the way we really work and it shouldn’t constrain us too much. If this is how things really look like why shouldn’t we just show it?

    Skipping parts of the process on the board for specific tasks is an option to consider. One advice though: as with any other movement happening on the board, make transition criteria explicit. If something goes directly from development to done column everyone in the team should be able to tell precisely what it means. And of course the answer should be basically the same each time.

    If you liked this story make sure you check the whole Kanban Story series.

    Advertisement: Want to have such nice Kanban boards in your presentations 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.

  • Kanban Leadership Retreat

    I spent last few days at Kanban Leadership Retreat. An original David Anderson’s idea was to gather in one place thought-leaders working on Kanban and provide them a platform to exchange experience, ideas and thoughts. I must say it kinda scratched my ego in its back to be invited.

    Anyway I’m still impressed how great the event went. I mean, I know that gathering some great minds in one place and giving them free beer (one evening only, but still) is a sure-shot recipe for a stunning success. To be honest, I did have high expectations. Basically all of them were exceeded.

    As the retreat worked as unconference vast majority of sessions ended up as discussions. There was little-to-none pre-prepared content which was both good and bad. It was good because it really enabled a lot of good discussions and thought exchange but there were moments when I’d appreciate a bit of structure, which is naturally brought by standard presentations.

    Personally I’d also prefer to see sessions a bit more focused on real-life stories than on meta-level but I guess expectations on this one differed.

    Anyway, volume of mind-blowing ideas I’m still trying to think through was astonishingly high. After all, what could you have expected after inviting all those though-leaders, and I take the word “leader” very seriously here, to the same place? By the way: you can definitely expect some of those ideas shared here in near future.

    Actually I went to the retreat with a goal to discuss a few of them: portfolio-level Kanban, Kanban failures and methods of selling Kanban to teams and organizations. Lucky me, each of them have made it to the event program. And basically each of the sessions looked totally different than I’d projected. This basically means I got a new, and unexpected, perspective on ideas I’d already had which, by the way, might make attending my future sessions on Kanban way more valuable, if you excuse this shameful plug.

    But all in all it wasn’t the content which was the most valuable for me. People were. I always say that networking is the most important part of any event but this time it was totally on steroids. The format of unconference, the choice of people and never-ending Icelandic days made it the ultimate networking event. If, by any chance, I looked as a child in chocolate factory please forgive me – I had damn good reasons to look so.

    I should probably mention all great folks I was talking to, which would be kind of boring for people who weren’t there, so I’ll refrain (BTW: if somebody is curious please check people I recently followed on Twitter). But if you are the one of them I’d like to genuinely thank you for all the stuff I learned from you.

    Huge thanks for organizing the whole thing goes to David Anderson and his staff along with Hillel Glazer, who facilitated the event.

    Personally I will be there next year. That’s no-brainer for me. If any of you, by any chance, is invited you shouldn’t hesitate whether it is a good idea to go even for a second.

  • Challenge your Rules

    This is the old lesson, but the one we need to learn over and over again. As managers we’re all about rules. We work like this and not like that. We do things in such and such way. We expect people to act like this. We forbid other behaviors.

    Nice. We can do it even worse trying to formalize all these rules.

    We need the rules not without a reason. If I want to be fair for more than a hundred people in my team I just can’t make every decision on the fly. Otherwise people would feel they’re treated randomly and the outcome of our discussion depends mainly on my humor or on the weather or whatever. If I want my judgment to be consistent over time I need to develop a set of rules, either formal or informal ones, so I can refer to them each time.

    The problem starts when we set these rules and never question them. Actually every time we trigger any rule-based decision we should take at least a few seconds to ask ourselves whether the rule is still reasonable or it is already good time to adjust it.

    Over past few months I could share a number of examples when I challenged and eventually changed my rules. Either because it appeared the rule didn’t work well or it had unplanned side-effects or there was a lot of resistance.

    And this is exactly how it should work. Our training policy was considered too harsh? Fair enough, we’ve just changed it. Recruitment process was considered sub-optimal? It doesn’t work that way anymore. We had a clash with managers regarding sharing specific information among them? Well, I won’t fight with everyone, so forget about this issue.

    The lesson here is: challenge your rules. Leading people isn’t about setting and following rules. It’s about adjusting to the situation.