Pawel Brodzinski on Leadership in Technology

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

Tag: team management

  • Don’t Ask For Permission

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

    ~ Grace Hopper

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Local Optimizations Aren’t (Always) Evil

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

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

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

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

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

    Should he fall back and sit silent?

    Hell no!

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

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

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

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

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

  • On Feedback

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

    And I’m really thankful for that.

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

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

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

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

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

    It is all about feedback loops, right?

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

    Are we offended by this feedback?

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

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

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

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

  • Instant Feedback Culture

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

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

    Well, no. Not at all.

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

    But I have a solution. Yay!

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

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

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

    Simple enough, isn’t it?

    Now the hard part. Prerequisites.

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

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

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

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

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

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

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

  • Learn. Adapt. Experiment. Repeat.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Team Retreat

    I’ve just finished sorting out feedback from today’s team retreat. In my case it was more of a management retreat, as it would be pretty difficult to organize a retreat with all 140 people from my team. Anyway, we ended up having a retreat with all managers from my team, which means we’re down to less than 20 people. Still, kind a crowd, wasn’t it?

    What do I mean by a retreat? In terms of a format it was an all day long meeting which was held off-site. Sort of. I mean we went to another office, the one no one works in. We did that, because it is crucial that no one is tempted to go back to their own desk. As one of my colleagues said it: “when we’re meeting in our office my thoughts are always floating around my desk.” For the sake of this meeting I wanted to break this connection. I wanted to have all of us concentrated and focused on subjects we were discussing.

    Before I move to subjects we covered a quick disclaimer: it’s been first such meeting since I’m working with my current team. I treat it as an experiment. I know retreats should last at least two days, so we have enough time to chew through things we’ve just heard and come back to them tomorrow, once we have more insight on the subject. Hopefully we’ll come to this point, but first, let’s just make them work in a lighter format.

    OK, so this was an experiment and something which was expected to be the first event of the series if people like it. We had a theme – everyone had 20 minutes to prepare a session in a form of their choice on something they’re doing in their team, which is valuable and worth sharing and copying. We ended up discussing stuff from alternatives of meetings (no-meeting culture, anyone?), through engineering practices, to cool coding tools which improve developers’ lives. We had PowerPoint presentations, no-slide sessions and discussions. We had some fun as well.

    We run typical round-the-table to share our opinions on what had just happened, but we also had the feedback door.

    Although it would be an abuse to say that feedback was purely positive, I’d say that, in terms of feedback, supportive messages just outnumbered critical ones. Now, it doesn’t mean we got it perfect the first time. No, we have hell a lot of work to do. However, we definitely are on a right track.

    Why did it work so well then? There are a few reasons.

    First, knowledge exchange. We work in an organization big enough that we have these silos, both formal and informal ones. We know each other, but not necessarily know what each of us is doing at the moment, let alone practices we use. It was a great occasion to share some information on that.

    Second, focus. We do meet (almost) every week. Yeah, that’s true, but it’s always in the middle of something. This time we were isolated from our errands so we were paying attention to whatever was happening around.

    Third, a kick in the butt. When we are in the middle of something important, which means pretty much all the time, it’s easy just to pop up and switch into passive mode. Yup, I will hear anything you have to share, but make it quick. And please, don’t make me do anything – I have important stuff to deal with. This time everyone actually had to prepare something. Not necessarily a big thing – anything between 10 and 20 minutes worked fine.

    Fourth, integration. We spent the whole day with each other. Well, if you hate me, or any other of us, that’s not good news for you. However, if you consider us a team, a bit of integration definitely helps.

    Now, you can easily scale this format up, and you get top management off-site, which in some companies is kinda popular.

    But you can also perfectly scale this idea down to a team-level. Get your team out of their desks and discuss things which are important to them. You won’t be pushing your project further to its success at that very moment but think of it in terms of sharpening the saw. If you don’t let the event slide toward chaotic discussion on pretty much nothing important this investment will pay off pretty quickly.

    Try it. You (probably) won’t regret it.

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

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

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

  • People Are Not Our Most Valuable Resource

    I hear that one from time to time: “people are our most valuable resource.”

    Well, they are not.

    People aren’t your most valuable resource. People aren’t goddamn resource at all. People are, well, people. Individuals. Folks who somehow like to be treated as real persons and not precious pieces of junk otherwise known as servers and such.

    Every time I hear this cliché about people being most valuable resource I wonder: how the heck can you say people are most valuable when you treat them as resource? As commodity. As something which can be replaced with another identical um… resource. If you say that, you basically deny that people in your organization are important.

    And it doesn’t really matter how hard you try to avoid calling people with that name. If you believe they are (put here “most valuable” or whatever bullshit you like) resources you won’t trick them. They won’t feel respected and they won’t trust you. Why should they after all? Do servers trust project leaders? And no, that won’t make people motivated whatsoever.

    I know, this is a rant. But this makes me crazy. I mean, how could we learn such humiliating behavior? I’m just waiting until I hear “Hi resource” instead of “Hi Jane” when Mr. I’m-So-Damn-Important-Project-Manager meets one of his project team members.

    Then, I’m going to hurt somebody. And I guess it won’t be Jane.