Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Performance Reviews Are Dead, Long Live Performance Reviews

    Recent NPR story about (lack of) value in performance reviews caused a stir. Esther Derby reminded her long-time hate relationship with performance appraisals pointing that not only employees but also a lot of managers hate them. What more reviews are tied to merit pay which is also evil.

    Well, I think it is oversimplification. We think performance review and we see corporate environment with multiple levels of management, constant fight for budgets, tough negotiations about rises and likely yearly appraisals which are so outdated that hardly bear any value for employers. If we discuss this kind of reviews, then agreed, they suck. They should be banned and people enforcing them should be forbidden to manage teams for at least 5 years.

    Now, tell me I’m lucky but I had probably just a couple of these crappy appraisals. And hopefully I have performed none of those by myself. By the way if I did it to you, feel free to kick my butt if spot me somewhere.

    Actually I tend to agree more with Scott Berkun who says that it is better not to do performance reviews at all if, and only if, they are done badly. It basically means most of the time we shouldn’t run performance appraisals but I boldly state I can to do better.

    So this is the time I should answer simple question: “How the hell do you do this damned thing?”

    Don’t make it all about money

    To some point I agree with Esther. If performance appraisal is reduced to a discussion about merit bonus or raise it is fruitless at best. Money-related negotiations always suck and this isn’t an exception. If you follow some formalized process you likely have to talk about money too, but then make it as short as possible. It is no fun for both of you so make it quick and move on to more pleasant parts of the ceremony.

    It is your goddamn duty to listen

    I am a chatty guy so this one I should tattoo this on my forehead to remind it to myself every morning when I look into the mirror. Performance review is one of the best occasions to listen what your team mate has to say. Let me guess, you, as a manager, don’t have a lot of one-on-ones with folks from your team. And even if you have, there are people down there who are always omitted. By accident of course. When you run performance reviews you suddenly have to meet every single one of them, so don’t miss this chance. Learn what they want to tell you. Let them talk. Listen. Not everyone will be open but at least give them opportunity to talk.

    Make it more a chit chat than a formal meeting

    One thing I learned during my early years as a manager is that when people are stressed they won’t tell you much. Yeah, that’s an epiphany, isn’t it? The most valuable things I learned about people, about teams and about me as a leader I heard during informal chit chat which I often turn my performance appraisals into. When we have the hard part (money-related) done we can talk more openly. Actually we may discuss your last holidays for an hour if you like. If nothing else I will know that you love hiking next time we meet in the kitchen. But we may also discuss situations when I screwed up as a boss or new technologies you’d like to learn.

    Let them set the rules

    You have different people in the team. There are those who don’t really care. Performance review is something you both have to get through but they don’t give a damn. The money doesn’t matter. Your opinion doesn’t matter. A discussion doesn’t matter either. What then? Don’t waste time of both of you. Say what you have to say and get back to work. But there are also people who want to talk. Let them talk. Listen. Learn. There are people who need a discussion about different things. Be a partner in this discussion. There are people who look for information. Share it. Besides the small part you have to go through, it’s not you who should write the agenda.

    Be open, be transparent

    If you are about to say a bit more than on weekly team meeting would there be a better chance than during one-on-one? If you are about to show your human face would there a better time? If you are about to discuss your motives standing behind tough decisions would you wait for another occasion? Yes, we managers are scared to shit when we share our secrets (or things we think are our secrets). But believe me; we should do it more often. As one of the best game strategies of all time says, if you play fair you will get the same in return. Be honest, be open and you will get exactly the same from your team. Isn’t that a fair deal?

    With these few simple rules I believe I’m able to run performance reviews which people don’t hate. Actually the last performance appraisal I’ve run I’ve started saying “As you already know no bonus money this time, so we can skip the formal part. Now, let’s talk.”

    I think it was pretty good appraisal. And yes, I’ve learned a lot. I’ve learned a lot despite I know the guy pretty long time already.

  • The Kanban Story: When and Why We Abuse Limits

    We have limits on our Kanban board. This isn’t really a news. Sometimes we abuse them. Since Kanban doesn’t force you to stick to the limits always-and-by-all-means it shouldn’t surprise you much either. However the interesting thing is when, why, how and how often we do it.

    I think I should start with stating that our limits are rather loose. It is technically possible to have as many as 15 MMFs in progress across the board. It never happened and it won’t ever happen, but still it is technically feasible. That’s crazy huge workload for 5-person team.

    But we happen to have limits like that and it’s not without a reason. If you recall our pseudo-iterations triggered by VCS issues you know we ship our software in packages of few (typically 2 or 3, sometimes 4) features. This means we sometimes move a group of 4 features across the board. For example it happens after deployment when we move features from testing complete to live stage. OK, enough of introduction about our limits.

    When do we abuse limits?

    It sometimes happens we change content of our deployment package on the fly. For example we have a package of 4 features in testing (either ongoing or completed) and then our crazy product owner (aka me) comes with an idea to add another tiny but super-important and super-urgent feature. Of course we could wait till another pseudo-iteration is deployed but sometimes it just makes more sense to add it to the old package instead of waiting another 13 days for another deployment package.

    We also had a painful MMF blocked for long weeks by our subcontractor. This practically reduced our limit in development by 1 for a longer time. It happened once that we decided to break this reduced limit acknowledging the fact we can do nothing more about blocked feature.

    Why do we abuse limits?

    Two words: common sense. If it is more reasonable to break the limit than to adjust whole work to our board we don’t try to perform some artificial actions just to be compliant with the process.

    We aren’t here for the board. The board is here for us.

    How do we abuse limits?

    First we all discuss the decision. Breaking the limit shouldn’t be treated as a normal thing. It is an extraordinary situation. So we collectively decide whether in this very situation breaking the limit is a better solution or we should rather stick to our constraints.

    This serves two purposes: one, we make this decision very consciously and two, we stress that it isn’t a typical and easy-to-accept situation.

    It happened once when I found the board with a broken limit with no discussion whatsoever about the fact. I fired two third of the team and burned whole office… Well, maybe not really, but man, I wasn’t happy. I wasn’t happy at all.

    How often do we abuse limits?

    This is the question you were waiting for, weren’t you? Pretty rarely I’d say – thrice a year. Well, describing it as an average result is a bit of abuse itself since it was our first year with Kanban. But you can see this is an extraordinary situation.

    To summarize, limits on our Kanban board aren’t a sacred cow. We break them if it does make sense and we decide it is a better solution than sticking to them at all cost. On the other hand we try to make breaking the limit an uncomfortable situation (you know, all this discussion, talking with each other… yikes) so we aren’t tempted to do this very often.

    So far it works pretty well.

    Read the rest of the Kanban Story.

  • Why I Prefer to Hire Women

    I have a news for you: IT industry is dominated by men.

    – Pawel, why don’t you tell us something we don’t know?

    There should be more women in the industry.

    Which part of “something we don’t know” you haven’t understood?

    Fine, you get the message. I just wonder why you don’t hire more women.

    I confess in my current team there is round number of women. Zero. I worked with a few teams like this. And every time one of my goals was to bring a few women to the team. Why? There are a few reasons. I will generalize here and I’m going to do it on purpose. After an hour or so of interview you can’t really say what kind of personality you deal with, so you have to go with your biases and prejudices anyway.

    • Women bring different soft skills to team talent pool. They’re usually more open and emotional than men. Do a simple test and recall your last retrospective or check the record from it. Can you see how different arguments were pointed by women than by men?
    • Women bring more culture. Pure-men groups tend to change into something like herd of hogs. Bringing a woman on board magically improves everyone’s manners and language. I mean hogs are nice but I wouldn’t like to work with them.
    • Women are more responsible. This may be one of my prejudices but I find women more responsible than men. I can hardly recall any woman who came to work having heavy hangover while I have no problems to name a long list on men who did.
    • Women are more accountable. It is connected with the previous point. Women tend to treat their duties very seriously. Even when it is something they didn’t personally commit to but rather something their boss expects from them their commitment is usually stronger. And I think here about these unrealistic expectations many poor managers set against their teams too.
    • After all, there aren’t many women in the industry so don’t make it even worse.

    Having said that, I’m not going to hire woman over man just because of sex. If there’s a significant difference between two candidates I will always choose a better one, however I understand “better” at the time. But at the same time every woman entering an interview with me has a small plus for free at the beginning. I guess I could put it as one of recruitment tips but changing your sex isn’t a great tip, is it?

    On the other hand I’ve seen enough prejudices working against women to throw my two cents. And I have a question for you: having two similar candidates which one would you choose?

  • Don’t Promote Best Engineers to Management Positions

    I remember one of first post ideas for this blog back then, 4 years ago. It was about choosing people to promote them to management roles. I’ve never published the post and I’m glad about that. A few years ago I didn’t know about hiring and promoting managers more than typical decision maker in IT companies now.

    I knew nothing.

    During these few years I’ve met a number of managers who should never be promoted to any position which touches leading people whatsoever. I mean they were great engineers once. But engineering, and software development isn’t an exception, and management are two different things. They don’t even rhyme with each other. So why the hell do we keep promoting our best engineers to management positions?

    Vast majority of best developers I’ve met were crappy candidates for managers. They were thinking in terms of code, not in terms of people. And a manager isn’t the go-to-guy when you have a technical problem. (The guy is called Google by the way.) A manager should work with people, not with code, architecture or build server. Yes, the transition is possible. Hey, if someone is willing to pay me real money for managing people it is some kind of proof. But the switch is painful and time consuming. And unfortunately most of the time it just doesn’t happen.

    We end up with a lot of people around who are still good-to-great engineers but crappy managers. And we let them lead. Then, when we need to promote someone even higher we have basically no good choice. And we end up with a bunch of managers-by-accident all over the organization. As a side effect you lose your best brains when it comes to engineering.

    Skills required to be technical leader and people manager are so different it is highly unlikely that your best engineer is also your best candidate for a manager. You can safely assume your engineers aren’t different. Why should they?

    If you want to offer your best engineer management position, rethink it. Twice. Is it possible you do it because it is exactly how things were done around for years? Is it possible you’re going to lose great developer and gain crappy manager instead? Is it possible to find a better candidate within the team or outside?

    If the answer is triple yes, and surprisingly often it is so, you’re doing wrong thing. I would even say that sometimes it’s better to let your great engineer go than to make him a manager. Of course if he is a crappy candidate for management position.

  • Choose Your Battles

    Organizational changes are hard. The bigger the company is the stronger it defends its status quo. Humans wearing their employee hats aren’t so much different from those wearing their user hats – they like what they know, thus they don’t like changes. But there’s often someone who isn’t happy with current state.

    So you are the one. You aren’t happy with the way your company works. You know what to change. You are even willing to spend significant amount of time and effort to implement The Change. You visualize the new, better, version 2.0 of your organization which will be there once you’re done. And then you rush to convince everyone to subscribe to your vision and fight with those who reject to follow you.

    Stop.

    That’s an easy way to lose, become frustrated, get fired, struggle to find another job and die in misery. Oh, I might have exaggerated with the last one a bit.

    Every organization, even a small one, has its status quo defenders. If you want The Change you, along with your supporters, are likely outnumbered. Trying to fight every single battle will make your group non-existent, which I guess isn’t the best tactic under the sun.

    I’m not saying you should sit there silently waiting for the miracle to come. Try to drop few ideas and observe how people react. It doesn’t take much of perception skills to notice who can support your ideas, who will fight you to the last breath and who doesn’t give a damn.

    You will quickly notice that tiny group of your supporters and crowd of opponents. But then you at least know your situation. And you are able to choose your battles in a way which maximizes your outcome. You quickly learn which discussion can be ignored since they aren’t important. You become aware when discussion turns into flame war and it doesn’t make any sense to continue it. And finally you become sensitive to those small signals of support from people whose opinions you care about.

    You learn to choose your battles.

    If you choose them wisely you win more often. Way more often. And somehow people tend to care about those with a good track record.

    Does it mean you should start a discussion only if chances are good for you to win? No. Sometimes you enter battleground being aware you’ll likely lose. But don’t make it a rule. If there are poker players, who never let it go, they are broke. But at the same time they play, and lose, crappy hands from time to time. That’s just cost of learning.

    If you followed the article you will enter the battlefield at least knowing who you will have to face. You will be prepared. Folks on the other side probably will not. Oh, unless they read that too, but it is unlikely. Why? Because people don’t listen, don’t read and don’t learn, remember?

  • You Can Manage Your Boss

    I often hear this excuse: “I don’t have power to change this.” Hell, I use it by myself way too often. It is a convenient excuse. Since you aren’t in position to do something the easy way you take a step back and do nothing.

    And this is wrong.

    Let’s take a typical situation: your boss sucks. If I got 10 bucks every time I heard that someone’s boss sucks I would be crazy rich. But let’s face it, I have poor opinion about managers in general and I think most managers suck anyway so I’m going to agree willingly.

    So what do you do when your manager sucks? Wait, let me guess… You do nothing. Hey, you don’t have the power, do you? You just can’t change the situation so it’s better just to accept it, right?

    Wrong.

    People are simple beasts. We all have our goals, private agendas, drivers and motivators. We also have tools which helps us to achieve these goals. Some of us have power. (And yes, I’m lucky enough I have power long enough to get used to it.) Some of us have skills. And some of us have instinct or cleverness.

    It’s not always the guy with power who wins. Actually if that was so, most of companies would work perfectly well, since every reasonable rule would be enforced and widely accepted. But somehow we see organizations which are completely sick and filled with frustration even though their leaders have mouths full of wise advices.

    It’s just they’re losing the battle with those who don’t have power but are more knowledgeable and smart.

    The trick is, to some point, you can manage everyone around. It doesn’t matter if he is your subordinate, your colleague or your boss. You can. Yes, you can. Yes, you… If I know what is important for you, what drives you and how you act in different situations I can trick you or I can build incentives for you to act like I want. Even if I’m your subordinate.

    A couple of examples. Megan had a boss who was pretty much frustrated with surrounding situation. Things were going bad. But he, as a manager, was supposed to play devils’ advocate. Megan, who knew the boss for quite a long time, felt that frustration hidden behind the mask of official optimism and decided to break it talking with the boss privately. She could do nothing, since she had no power to change boss’ attitude and then a new cool business wouldn’t emerge when they both left the company to start it.

    John had a manager who loved bells and whistles. He knew most of project decisions were made basing on what the manager personally likes, not on reasonable business analysis. When recession came and every team looked for projects John brought a bunch of cool, but basically useless, ideas to the manager. John expected the manager would personally like a couple of them and he was right. The team got the budget for these projects. Business-wise projects were useless but John played his agenda and got what he wanted.

    We all base on a lot of assumptions. Especially managers. We just can’t know every fact so we do what our gut feelings say. And finally we are biased. This means we make our decisions basing on a set of arguments which is far from being complete or even reasonable. That’s why it is not the power which is the most important since almost every power bearer can be blinded easily.

    So don’t give me excuses you just can’t change anything since you have no power. At least try. Then try again. Unless you fail a couple of times I don’t believe you can’t do it.

  • We Know Nothing about Our Teams

    I am a chatty guy. Catch me while I’m not overworked and I will gladly jump into discussion. If you happen to be my colleague, it may be a discussion about our company. That’s perfectly fine for me.

    I believe in transparency so I won’t keep all information as they were top secret. This means I’m likely to tell you more than your manager. Not because I don’t know how to keep a secret but because vast majority of managers talk with their teams way too little.

    With this approach I usually know a lot of gossips told in companies I work for. Since I also happen to fulfill rather senior roles I have another perspective too. I know what is discussed on top management meetings.

    This is sort of schizophrenic experience for me because almost always I have two different pictures of the same thing. I see senior managers praising people who are disrespected by their teams. I see folks who get credited for the work they didn’t do. I see line workers being completely frustrated while their managers are saying these guys are highly motivated. I see managers completely surprised when people suddenly leave while almost everyone saw that coming for past half a year.

    I see it and I don’t get it. All these managers do very little, if anything, to learn a bit about their people but they claim they know everything. I may be wrong but I believe I do much more to learn about my team, yet I still consider I know nothing.

    If one of you guys is reading that, yes, I’m stressed that you might leave. I’m stressed when you get out of the room to pick the phone since definitely it is a headhunter who’s calling. I can’t sleep when you take a single day off since, and I know it for sure, you have an interview. OK, I might have exaggerated a bit. Anyway in terms of my knowledge about my team I know that I know nothing.

    And you know what? If you are a manager you are no better. Because generally speaking we know nothing about our teams. Even if we are friends with our subordinates our professional relationship is much of unknown. With strangers we usually work with it is much, much harder.

    Stop expecting you know oh so much about your people and at least try to talk with them. If you’re lucky you may find a couple of folks who actually are willing to talk with you. Remember though, if you ignore them once or twice they aren’t coming back to you.

    It looks like I have a pretty poor opinion about quality of people management in general. Well, I must admit I do. I would be a hypocrite if I deny it regarding my recent posts on subject:

  • When Kanban is the Best Choice

    Kanban, as any other methodology, isn’t a silver bullet. There are situations and teams when it shows its full potential but there are others where its impact will be limited. Where Kanban suits best then?

    Micro-sized teams

    It is said Scrum works best with teams of 7 or close to this size. Sometimes we deal with smaller groups. 3 people working on a project isn’t something very uncommon. For such micro-sized teams Scrum is often too formalized. You can limit a number of rules you follow and still keep good quality. And you have a bit more time to do the real work.

    Frequent priority changes

    “Walking on water and developing software from specifications are easy if both are frozen.” Unfortunately we deal with a lot of changes as we build software. There are new features; importance of tasks changes, new top priority bugs requires instant attention. Our response is moving to more flexible approaches. We try to avoid BDUF projects. We switch to agile methods employing short iterations. We even make iterations shorter and shorter. It allows us to change priorities frequently. Once every couple of weeks if we take typical Scrum implementation.

    The problem is when priorities happen to change even more frequently. Once every few days. Or even every single day. And yes, there are such projects. Kanban is a great answer for them. Feel free to change priorities every day. As long as it is well-grounded it shouldn’t ruin your project.

    Maintenance projects

    A typical maintenance project routine looks like this:

    1. Whenever high-priority bug is submitted fix it as soon as possible
    2. Low-priority bugs becomes high-priority ones when resolution deadline approaches; then see above
    3. Whenever a client orders change request (CR) and there’s no high-priority bugs – try to do it as soon as possible
    4. If there are more than single concurrent CR ask project manager about priorities
    5. If there are no bugs or CRs do some refactoring or other improvement job

    Sounds like ideal Kanban playground, doesn’t it? That’s typical case of event-driven development (not event-driven programming) where you don’t actually have a roadmap or something but you do whatever new day brings. After all you don’t expect to have a bug submitted tomorrow, or do you?

    Multiple small projects

    Working on several rather small projects or sub-projects with the same team at the same time is pretty difficult. Resources (what a nice name for your people) are usually insufficient since it is harder to synchronize stream of small orders to keep it at the same level all the time and bringing more people just-in-case isn’t the best business strategy around. This ends up with (surprise, surprise) a lot of priority changes and trade-off games. “We can complete this additional project on time but we’d fail to meet a deadline here or there.”

    With standard structured project management approaches coordinating different threads with ever-changing priorities becomes pretty much a hell. What Kanban does is it organizes workflow so the main, well almost the only, thing you should care about is setting priorities at the beginning of workflow.

    Common part

    The common part for all of environments above is they don’t require many constraints to work. Few simple rules which come with Kanban should be enough to get things done. Another common thing is mid- and long-term planning is hard or even close to impossible, which is another problem hardly resolvable with more structured approaches. These two things are the most specific for environments where Kanban shows its full potential.

    This isn’t really a post which is a part of the Kanban Story but if you found it interesting you should like the story as well.

  • The Kanban Story: Swarming

    If you’re into Kanban you probably have heard the term swarming. Actually chances are good you’ve heard the term despite your lack of interest in Kanban.

    What is swarming?

    In short swarming is all about getting more people to do the task than you’d get otherwise, in normal situation. An example: you have a bug which normally would be fixed by a single developer, but for some reason you have the whole team working on it. And you already have another question…

    Why, oh why?

    Why would you want people to swarm around a small task? Typically teams do this when they face either a blocker, which hampers whole team, or a very difficult problem, which is hardly solvable by a single person. Either way you get more people to move things further, which would be impossible or at least very difficult otherwise.

    Swarming in Kanban, part 1

    Up to this point swarming is something teams do intuitively at times. The reason why the term is mentioned so often in the context of Kanban is one of Kanban rules: limiting work in progress. Because in Kanban we want to have as few ongoing tasks as possible, yet as much as it still does make sense, we have limits for different stages of our process. And it when we hit the limit we treat it as a problem which we want to solve and we want to solve it fast. That’s why we swarm.

    Swarming in Kanban, part 2

    There is another thing which you may read about, which I call everyday swarming. Everyday swarming is done by teams which swarm by default, when no emergency situation happens. The reason standing behind this behavior is trying to make cycle time and/or lead time as short as possible thus flow of tasks very rapid and smooth. Oh, and you have fewer ongoing tasks then too, which means you have less work in progress, which means you have less waste, which means you are oh so lean.

    Our story

    I must admit I don’t really like the idea of everyday swarming. I mean cycle time is definitely shorter but I’m so sure about throughput. Flow is smoother but you kick in a lot of micro-switches when a few people need to integrate their work into one piece of code since they all have worked on a single feature. You also may invite some issues with version control this way since you’ll be working on the same chunks of code. For me the net weight of swarming by default is negative.

    Basically that’s why we avoid swarming whenever possible. When there is some serious problem to solve and standard approach is not enough we naturally help each other. One person after another joins the rescue team and this basically ends as swarming. But other than that we prefer to have only one person working on the task at the same time. Well, of course there are exceptions like discussing design or testing and bug-seeking/bug-fixing but these all are pretty natural things for any software development team. After all it would be pretty schizophrenic to discuss the design with oneself.

    It looks like we swarm as David Anderson initially proposed, despite ignoring David’s teachings when it comes to lead time. I think this is the most natural way of swarming. But of course you remember the rule to experiment like crazy, so you may want to try something different in your team.

    Read the rest of Kanban Story as well.

    http://blog.brodzinski.com/2009/10/kanban-story.html

  • The Kanban Story: Coarse-Grained Estimation

    Recently I told you what a screwed way we chose to measure lead time in our team. Unfortunately I’ve also promised to share some insight how we use lead times to get some (hopefully reliable) estimates. So here it goes.

    Simplifying things a bit (but only a bit) we measure development and deployment time and call it lead time (and don’t feel bad at all about that). So how do I answer to our customers when they ask me when something will be ready?

    That’s pretty easy. If we talk about a single feature and there is no other absolutely top priority task, I take a look at the board to track down a developer who will be first to complete his current task and discuss with him when he expects to finish it. Then I know when we can start working on the new, super-important feature ordered by the client. Then it’s enough to add two weeks (which is our average lead time) and make some effort to look oh, so tired as I’ve just completed such a difficult task of estimation. Oh, I need to tell the customer when they’re going to get the darn feature too, of course.

    This however happens pretty rarely. We try to keep our MMFs (Minimal Marketable Features) stick to their name which means they are usually small. This also means that described situations, when client wants just one feature from us, are pretty much non-existent. That’s why you might have noticed I didn’t take into consideration a size of a feature in described scenario. In the real life we usually talk about bigger pieces of functionality. What we do then is we split the scope into small MMFs and then use two magic parameters to get our result.

    One of parameters you already know – it is an average lead time. However there’s one more needed. It takes 13 days for the feature to get from the left to the right side of the board, but how many features are on the board at the same time? I took a crystal orb and it told me that on average we have 4,5 MMFs on the board. OK, I actually did a simple analysis of a longer period of time checking our completed MMFs and I got this result, but doesn’t a crystal orb sound so much better?

    Now, the trick I call math. On average we can do 4,5 MMFs in 13 days. Since I have, let’s say, 10 features on my plate I have to queue them. If I worked with iterations it would take 2,2 iterations (10/4,5) which basically means 3 iterations. But since we don’t use time-boxing I can use 2,2 and multiply it by 13 days of my lead time and get something about 30 days. Now I don’t start with empty board so I have to add some time to allow my team to finish current tasks. On average it would be half of lead time so we should be ready in, say, 37 days.

    And yes, this is rough estimate so I’d probably go with 40 days to avoid being blamed for delivering estimate which looked precise (37 looks very precise) but was just coarse-grained estimate.

    That’s basically what I went through before telling my CEO we’re going to complete management site for the product we work on in 3 months. Well, actually I didn’t told him yet, but 3 months there are. No less, no more.

    Although this post may look as it was loosely coupled with the Kanban Story it is definitely belongs there. So go, read the whole story.