Pawel Brodzinski on Leadership in Technology

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

Tag: communication

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

  • What Motivates People

    Today I attended a training session where we were learning about motivation. I’ve heard pretty poor opinions about the session before, but I wouldn’t be me if I didn’t check by myself. And if you need to know these opinions were crap – training was pretty good.

    Anyway, we had a very small and very open group which was cool. I think I should thank here those who didn’t show up, since the session was planned for a bigger audience. The best thing about the group was each of us works in different team and we are on different levels in organizational structure. This means our perception of the organization itself and tools we have to motivate ourselves and our people differ vastly.

    This is kind of cool because otherwise we would barely have a chance to confront our points of view. And it appeared every single one of us pointed different things as our main motivators. This is basically the lesson I want to share with you. If you want to know what motivates people working for you, move your fat ass from your damn throne and learn what drives every individual in your team, instead of asking for universal recipes.

    Yes, you will hear all sorts of answers from “more money” up to “my cellar is cool actually; just don’t interrupt me when I’m in THE flow.” On a side note, money isn’t a tool you can use to motivate people.

    Motivation is a very individual thing. I remember sharing a really fat bonus with one of my former PMs after she completed one those hard core projects. Since we were getting on well I asked if that motivated her for further effort. The answer was “no, not at all.” I can’t say I was surprised much, since I’d moved my fat ass from my throne to learn what had driven my team. If you asked me why the fat bonus then, well, she’d still earned that money.

    Don’t expect simple answer for a question about motivating people. The subject is just too complex. And if you still believe there is a simple and universal solution for the problem you may want to reconsider predisposition to be a manager.

    In case you were curious my biggest motivators are learning opportunities and having things under control.

    You may also like other posts on motivation:

    http://blog.brodzinski.com/2007/10/money-as-motivator.html

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

  • It’s the Transparency, Stupid!

    A boss came to a worker:
    – Would you come to work on weekend to rescue project?
    – And what would be the reward? – asked poor little worker.
    And there was no answer.

    Actually the unspoken answer was “I don’t really know” or “I don’t want to say” or “Don’t mess with me, kid.” Either way it was wrong.

    The worker’s question isn’t a very nice one – personally I prefer working with people who don’t ask for reward before job is done. On the other hand it isn’t unexpected either. As far as you’ve done some extra job and haven’t been rewarded in any way or your so called reward could be interpreted only as an insult you learn to ask before, not after. Every manager should be prepared to hear the question.

    Being prepared here means having an answer and having the one which actually says something specific. Let it be “You’ll get this and that amount of bonus money” or “You’ll have higher engagement rating during next performance review” or “I can do completely nothing for you because I’m a crappy manager but I still ask you to come.” It’s still better than nothing.

    A reason why these are better than those above is simple. They are transparent. You show how things look like. You don’t hide your magic algorithm which is a number of overtime hours multiplied by standard rate multiplied by secret factor of 1,25. This by the way becomes perfectly clear for everyone once they do the basic math. Basically if you as a manager hide something it’s either wrong or it shouldn’t be a concern of a team. Actually the former most of the time. Even when you don’t hide you suck being a manager while you’re trying to be transparent it’s better than trying to play kick-ass boss. Everyone would know you suck anyway but you’d avoid a label of hypocrite at least.

    If something is interesting for the team or a person in the team – say it. An algorithm you use to tell how much bonus money people are going to get? Say it. Rules you use to decide on a promotion? Well, say it. New facts about this huge project you’re trying to get? Guess what. Say it. Unexpected issues with company cash flow which will bring some inconveniences for the team? How about saying it? Be transparent. People will appreciate this even if they won’t say that out loud.

    Being transparent cuts off gossips, increase team’s trust to their manager and helps to spread information among the team. It is good. Do the opposite and you won’t keep your alleged secrets and you won’t control information (and gossip) flow in any way either. Not to mention you’ll be considered as a poor manager by your team. And well, they’ll probably be right this time.

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

  • Too Honest, Too Straightforward

    Vast majority of people working on software products contact their customers directly or indirectly. Yes, software developers included. Each time we do it we play a role of salespeople. Of course customers don’t see us making product presentations or negotiating prices. What do they see then?

    In my case answer is pretty easy since my attitude was commented several times in the past by my colleagues. I’m too honest and too straightforward. It’s definitely a mixed blessing if that’s a blessing at all.

    Talking about business is expected to be like old-school negotiations. Two parties sitting on two ends of the table trying to squeeze others as much as possible using all tricks they know. I hate it. I dream about this kind of discussion:

    – We can do it in 4 months. Here’s proposed schedule.
    – Are you sure phase 2 has to take so long?
    – Yes, since we have to develop integration module for external system. It could be probably a bit shorter if we had experts of that system available but we’ve worked with these guys before and there are always problems with them. If they won’t be an issue this time we should be able to deliver 2 weeks earlier but I wouldn’t bet.
    – OK. Another issue is the price. We won’t pay more than $100000. That’s our approved budget.
    – Let me think… We’d need to cut some functionality out of scope to make it a win-win. How about messaging module and these complex reports?
    – Um… we can let reports go but messaging module must stay. Deal?
    – Deal.

    Yes, I know, I am dreaming. Anyway I often try to bring this kind of approach to the table. Too often. You shouldn’t be surprised if you’re a customer and I ask you: “We plan to develop this product for you, does it makes any sense for you or is that just a brain dead idea?” I may also state: “This function would make both your and our lives easier, although I don’t believe they’d allow me to do it for free. Would you find some budget for the feature? I promise the price will be good.”

    On the side note, if you ever worked as a salesperson with me I know, you already hate me. I guess I must live with that.

    This approach may weaken negotiating position of my party. Sometimes it is considered as pretty harsh by customers since you occasionally don’t wrap up the truth with nice marketing blah-blah (“No, we won’t build and deploy complex telecommunication solution in a month”). That isn’t playing by the rules and from time to time people find it hard to deal with it at the beginning.

    However the thing I found out is that when a relation with the customer is already built they start to appreciate this attitude. Having an honest source of information on the other side is quite a valuable thing. Even when the guy is sometimes too honest and too straightforward.

    It doesn’t mean I’m totally happy with it. It definitely would be better if there were no scary ‘too’ word in the label they stick to my back.

    What kind of person are you? What do your customer see when they talk with you?

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

  • How to Make Decision with a Team

    Short but very interesting discussion with Piotr followed my post about leading a team of developers. Piotr accurately pointed that a leader should listen to his team and the team should participate (more or less) in decision-making process. At least that’s true in most cases.

    Despite the last word belongs to the leader, the team should feel they’re important. They should feel their opinions matter. They should feel the leader wants to listen to them. To be honest, more important is what they feel, not what’s the truth. Even if the leader doesn’t really listen to the team he should try to create impression that he does. That’s better than nothing.

    When I was learning the MSF, one of sensible yet surprising principles was that there’s a team of peers and every decision should be made by achieving a consensus. That’s of course utopia, but if by any chance you’re able to proceed with a decision in this way, you should. Even if it’s easier just to force your opinion.

    How to make the decision with the team then?

    • Ask teammates about their ideas, not suggesting them yours. This can give you fresh look on the problem. You aren’t a smart Alec (oh, if you believe you are and you’re still reading – give up the rest). Someone from the team can have a better idea.
    • Encourage them to contribute. In many cases if you don’t directly invite your teammates to participate, they won’t find enough courage or will or whatsoever and they won’t even say a word.
    • Discuss all ideas with the team. You’ll sometimes find that people would have changed their mind after discussion. Even on their own ideas. That’s much better than telling him that their concepts are worthless. Even if they are.
    • During discussion drill down every idea until you feel you understand it. If something is ambiguous let it be explained. If explanation is ambiguous too – drill deeper. Force them to drill with you (that’s what my boss keep asking me to do and believe me – it does work).
    • Think about all possibilities and make the decision. Team of peers is nice idea, but unless the choice obvious or there’s countless amount of time to discuss, someone just has to make find the way out. You won’t guess who it could be…
    • Communicate the decision but give reasons for it. If there was another hot option that was turned down motivate it either. People should know what the motivation behind the choice was.

    Sounds easy? It is not.

    • Usually you don’t have enough time. Not enough for discussion. Not enough for thinking it over. Not enough for managing all risks.
    • Sometimes not every factor can be known by whole team. Especially when decision is rather organizational than technical. In this case you can have your team against you. Even if you’re the one who is right.
    • Sometimes you don’t have your own opinion and none of provided ideas is convincing enough. Choose one and act like you were convinced, then. Your team needs convinced leader.

    If it was easy the leader wouldn’t be needed.

    Feel free to add something to both lists (especially to the first one).