Pawel Brodzinski on Leadership in Technology

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

Category: communication

  • Visualize Everything

    One of Kanban rules is visualization. This is one I like the most since I just can’t sit at ease next the the clear whiteboard. I have that urge to grab a marker, a bunch of sticky notes and make the board a little less white.

    Anyway, visualization isn’t the concept unique for Kanban (what is after all?) and recently you probably hear about it very often. It was one of returning messages across this year’s ACE Conference and it was very similar at GOTO Copenhagen – Dave Thomas pointed it as one of key factors of successful teams. And then of course there was all-day long Kanban track which, as you may guess, was covering visualization over and over again.

    So the message is: visualize it! Show what you’re doing on the board. Make it visible for everyone in the team. Make it visible so everyone knows what’s happening. Make it visible so it’s hard to ignore that, especially when things go wrong.

    We are inevitably heading toward the question: what “it” is?

    Well, “it” is pretty much anything. Because it’s not just “visualize it” – it’s “visualize everything.”

    Stages of your process? Checked. Limits? Checked. Who does what? Checked. Blockers? Checked. Cycle time? Checked. Priority? Checked. Area or module of a project? Checked. Emergency state? Checked. And this is only the beginning. These are actually the most obvious examples. Add to your sticky notes any information a team will need. Put it on the board. Visualize it! It is a way of communication. And the one which isn’t intrusive.

    It may sound a bit counterintuitive but it works miracles. My recent playground is project portfolio level Kanban and the interesting observation I’ve made already is how the board helps me every time I need to plan new projects or make a tradeoff to respond to changing situation. It even tells me when I need more people faster than our budgeting software, which we typically use for this purpose.

    The reason is simple: visualization just works. So go, visualize everything!

    Advertisement: Want to have gorgeous Kanban boards in your PowerPoint presentations? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • Visualization Stupid!

    Kanban is a funny animal. I started my journey with Kanban treating is as a tool. Then I realized it is more of a vehicle which improves things around. Now, I extract some ideas standing behind the method and use them independently in different situations.

    Since Kanban is as easy as possible – I use to describe it as “three rules, one tool and simple mechanics” – there aren’t many ideas you could exploit, but there’s one which is especially appealing. A contest: which one am I thinking about?

    Yes, I know. I ruined everything with the title. What a dumbass I am. Anyway yes, visualization is the concept I like so much. Generally I’m known to be attracted by every whiteboard or flipchart around. If you see me sitting peacefully in a room with a completely clean whiteboard and set of markers you can bet I suffer. I’d love to write, draw, scribble and note on the board, so we all can see some reference to what we are talking about or how others may understand what we’re talking about.

    Feel free to laugh at me because of this. It doesn’t happen without a reason. I learned how much value simple visualization can bring. I’m sure there’s some psychological gibberish which shows how our brains deal better when we can refer to a huge visual brutally presenting the core of the issue, but I don’t really care.

    I use visualization because I know it helps me. It helps to me to organize presentation, like the one I’m preparing for ACE Conference. It helps me understand the problem, like learning how many quality engineers we do need at the moment. It helps me to express my thoughts, like when we’re discussing performance appraisals.

    Next time, when you have some problem, try to draw it on the whiteboard or flipchart. I mean really. No matter what the problem is or how you choose to visualize it. It would help you to understand and chances are good you’ll find a clue how to solve it.

    If you wondered why I brought two whiteboards with me to my new room, now you know.

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

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

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

  • Co-location Rules!

    A lot of interesting discussions today. During one of them we went through co-location and its influence of team productivity.

    I’m lucky enough to work with all my team in one room. I’m aware of all disadvantages of grouping people doing different things in one place but I’m still saying I’m lucky.

    • I know development requires focus. I know that grouping a bunch of people in one place generates some chit-chat which distracts people trying to focus on their tasks. I know occasional phone calls do the same. I accept the fact. Hey, have I just said I accept lower productivity of our developers? Bad, bad manager.

    • I know most people would consider a private office as a huge improvement from open-space. I wouldn’t offer that to my people even if I had a chance to make them this kind of offer. Ops, I’ve just admitted I wouldn’t make my people happier even if I could. How come?

    It just about trade-offs. While putting people together invites costly context switching because of distractions it also brings huge values in terms of team work.

    • Instant problem solving. It’s enough one person to ask another one about some issue to see insightful discussion emerging virtually instantly. You don’t need to think whether PM should join since he’s here and he joins as soon as subject appears interesting for him. Solving problems as you go is much more efficient.

    • Communication improvement. Communication issues are probably number one issue when it comes to visiting dead-ends, doing the same job twice or banging the wall hard with your head. When I think how much effort is wasted just because a couple of people didn’t talk with each other I believe every method which improves communication is worth considering and most of them are worth implementing. Co-locating people is one the most efficient choices here.

    • Reducing number of meetings. Many meetings aren’t even needed. However they’re scheduled because they’re considered as the easiest way of communication between more than two people from different rooms. Remove walls and you’ll automatically remove many meetings. People will have more time to do the real work.

    • Atmosphere building. Try to cheer up person who sit next to you. Tell a joke or something. Succeeded? Great. Now do the same with the person sitting on other floor. It takes walking and other tiring physical activities. It’s harder. You won’t do it so often.

    • Getting to know people. You’ll know better a person after sitting with her in one room for a month than after working in different locations for a year.

    And yes, I believe these compensate reduced productivity and happiness. Actually not only compensate but add more too. Net value is positive. That’s why co-location rules.

  • Is It Possible to Over-Communicate In Project?

    While explaining another thing which I thought was obvious for everyone in the team but appeared as not clearly communicated the question came back to me: is it possible to over-communicate in project? I dropped the question on Twitter and expected answers like “Hell no!” Or “Maybe it is possible but no one seen that yet.”

    Responses surprised me though. Author of Projects with People found problems of being too detailed for the audience or revealing facts too early. Well, what exactly does “too early” mean? When people already chatter on the subject at the water cooler is it too early? When managers finally become aware of chatter is it still too early? Do we have to wait until management is ready to communicate the fact (which is always too late)?

    Actually gossips are powerful and spread fast. The only way to cut them is bring official communication on the subject as soon as possible. Hopefully before gossiping is started. Which does mean early. Earlier than you’d think.

    Another thing is being too detailed. This can be considered as unnecessary or even clutter. Clutter is an issue raised by Danie Vermeulen. If something doesn’t bring added value it shouldn’t be communicated. If we kept this strict we could never post any technical message on project forum since there always would be someone who isn’t really interested which framework we’re going to use for dependency injection or how we prevent SQL injection and what the heck is the difference between these two. And how do you know what is a clutter for whom anyway.

    John Moore looks at the problem from different perspective – over-communication can be bad when it hurts morale. I must say I agree with the argument to some point. Some bad news isn’t necessarily related with people’s work (e.g. ongoing changes in business team on customer side) and can be due to change. Then keeping information for you may be a good idea. However if bad news is going to strike us either way the earlier means the better. One has to judge individually on each case.

    Although I don’t see easy way to deal with above issues they remain valid. Actually I can agree it is possible to over-communicate yet there’s no concrete border or clearly definable warning which yells “This email is too much! You’re over-communicating!” at you whenever you’re going to send unnecessary message.

    The best summary came from Lech who pointed that risk of over-communicating is lower than risk of under-communicating. I’d even say that much, much lower. How many projects with too extensive communication have you seen? One? Two? Personally I’ve seen none. On the other hand how many projects suffered because of insufficient communication? I’ve seen dozens of them.

    On general we still communicate too little. Yes, we can over-communicate from time to time but I accept the risk just for the sake of dealing a bit better with insufficient communication which is a real problem in our projects.

    How does it look like in your teams?

  • My Biggest Mistakes

    Have you ever wondered what were your biggest mistakes in your professional career? Which things you should do another way or at least try to change? It’s usually easy to judge others, especially looking from a perspective of time. Hey, he shouldn’t have left the company then, because now he’d have been promoted at least twice. Easy to say, because it’s about him and you know exactly what happened during those two years after he left. Back then the decision probably didn’t look like a mistake.

    With the same schema we can judge our own decisions, however it’s much harder. First, for most of us it’s difficult to accept that we actually made a mistake. Second, it’s even more difficult to be unbiased when you consider yourself and your own actions. Nevertheless it’s worth a try.

    There’s one thing more – people usually tend to share with others their successes, not failures, so your own experience is even more precious – you have unlimited access to it. You won’t find a lot of “failure stories,” so I thought I’d share some of mine.

    Personal interactions

    When I was leading a support team I had a couple of conflicts with developers partially based on personal background. I thought that if I’m so dedicated and if I struggle to do my best everyone should too. It’s not so hard to imagine that it was rather naive point of view (we worked in a corporation then). Instead of letting other managers to resolve the problem with their people I was making my private tiny war. E.g. we did some performance tests to prove that one of developers didn’t make optimizations, just to show he’d ignored the task. Why didn’t I ask him if he had done that and spent much time for useless tests? Bah, don’t ask me now. You should have asked me then. I can recall several similar situations, all of them having source in my personal likes/dislikes and resulting in, let’s say, not optimal business decisions.

    Building a team

    I was once a department director, building a team and a product from a scratch. By the way it was a great job. I think my biggest mistake then was too slow promotions within the team. For me it’s very hard to promote someone unless I’m completely sure she’s the right person. However I should overcome my resistance instead of waiting too long before official promotion for a couple of the leaders. Not mentioning that I didn’t even thought about potential successors of any of the leaders. Subconsciously I tried to direct my people through the way I passed once: first informal role of leader with real manager controlling whole team and then eventually getting own team and formal managerial role. Unfortunately, I and one of my colleagues changed the job leaving over a dozen of people with no junior and middle management. The promotions were soon carried out, but with people rather unprepared to managerial role and little supervising it wasn’t a vast success. Some time was wasted too.

    Communication with sales

    As a manager of operations team (development, implementations, quality assurance and project management team) my biggest mistake was poor contact with several sales people. I know there’s always a conflict between sales and development, but I’m far from thinking that the technical side is the one which is infallible. Quite the contrary, I even wrote that in general it’s better to have a business person as a CEO and sometimes having a geek as a leader of a company isn’t a great idea. I know all of that, but still I haven’t managed to be on good terms with few sales. And by now I still don’t see how I could get it done right with those people. I’m not even sure if it was possible. Maybe more time has to pass and I’ll find out the answer then. Maybe our characters are too different and we hadn’t even a chance. Nevertheless, the fact remains, it’s my failure too.

    Choosing an idea

    I was working with my friend on a piece of software. Whole thing was intended as a micro-ISV idea, but none of us decided to leave everyday job. In this case our biggest mistake was choosing an application we worked on. It’s not about a market for the application – I still believe we had a chance. It’s about our attitude – we had little fun while working on the software we’d chosen and we reached the point where none of us was still motivating himself, not mentioning about motivating a partner. The software died unfinished. We’d chosen the application only because some of work (part of the code) was already done, so we thought it’ll take much less work to finish. Now I think we had about 5% of work completed, so the choice wasn’t a well-thought one.

    Depending on situation my mistakes were followed by different consequences – in the first situation results were negligible, in the last example whole initiative ended up as a failure. It’s just a bunch of examples, but I can think about a list of others based on both my experience and my observations. Generally, it’s not shame to err – making a mistake once is an occasion to learn, but making the same mistake twice becomes a stupidity.