Pawel Brodzinski on Leadership in Technology

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

Category: team management

  • Should You Encourage People to Learn?

    A very interesting discussion followed one of my recent posts about people not willing to learn. There were a few different threads there but the one brought by David Moran is definitely worth its own post.

    David pointed it is manager’s responsibility to create learning opportunities and incentives for people to exploit them.

    At the first thought I wanted to agree with that. But after a while I started going through different teams and people I worked with. I recalled multiple situations when opportunities were just waiting but somehow barely anyone was willing to exploit them. The rest preferred to do nothing.

    I believe most of the time it is not the lack of opportunities which is a problem but lack of will. Now the question is: whether a manager or a leader should create incentives for people around? If so what kind of incentives should it be?

    First of all, I don’t believe in all kinds of extrinsic incentives which are aimed to encourage people to learn. If you set a certification or exam passed as a prerequisite for someone to be promoted people would get certification just to get promotion. They won’t treat it as a chance to learn but as one of tasks on ‘getting promoted’ checklist. You get what you measure. If you measure a number of certificates you will get a lot of these.

    The results are even worse when you create a negative incentive, i.e. you don’t get bonus money (you’d earned) unless you submit your monthly article to knowledge base (seen that). What you get there in majority of cases is just a load of crap which looks a bit like knowledge base article. After all no one will read it anyway so why bother?

    What options do you have then? Well, you can simply talk with people encouraging them to learn. “You may find this conference interesting.” “Taking language course would be a great for you.” “I’d appreciate that certification.” Unfortunately it usually works with people who are self-learners in the first place and don’t really need an incentive – the opportunity is enough (and they probably find opportunities by themselves anyway). The rest will most likely agree with you but will still do nothing.

    You may of course promote self-learners over the rest and most of us probably do it since people who feel an urge to learn are generally considered as great professionals. Unfortunately this mechanism isn’t completely obvious and is pretty hard to measure (how would you measure self-learning attitude?) so its educational value is close to zero.

    Coming back to the point, I don’t think that it is manager’s responsibility to build incentives for people to learn. I think the role of a leader ends somewhere between supporting everyone’s efforts to learn and creating opportunities. Besides if learning is enforced it won’t build any significant value.

    And yes, it is manager’s role to have a knowledgeable and ever-learning team but forcing people to learn is neither the only nor the best available approach.

  • Managers Are Clueless

    So you’re a manager. You even think you’re pretty damn good manager. Fine for me. Do you remember Pointy-Haired Boss? Yes, that clueless manager from Dilbert cartoon. You have this guy sitting in your head. So do I, by the way.

    Is that supposed to be insult? Well, not exactly. I really think every manager has this clueless version of himself in the back of his head which is used more often than we’d like to admit. You still don’t believe me. Do a simple exercise. Think about your team. Arrange members from the best to the worst. Easy?

    It wasn’t supposed to be easy. The trick is how you decided that one ‘average’ person is after all better than another ‘average’ person. Some guessing I guess. Why exactly you have chosen the best one? And what a couple of worst people have done to earn their place? Is it possible that you justify their position with some past event (success or failure) which was spectacular enough they earn the place in your mind? Is it possible you didn’t take into consideration recent history because you already are strongly biased?

    And now the best part, think how many things you haven’t taken into consideration. You haven’t thought about tons of important things and you were still able to say who is better and who is worse from others. And no, I don’t believe none of them are important. Isn’t that clueless?

    A Confession

    I worked with bunches of underpaid and overpaid folks. I saw work which was underrated or overrated just because of person who authored it or the person who judged or both. Many of decisions standing behind these situations were mine. I’m not proud of it.

    What I can say is I didn’t do it on purpose. I just lacked knowledge. Sometimes I wasn’t even conscious my knowledge was insufficient to make a right call. Sometimes I should try harder or think more. I was, and I am, a clueless manager. I try to fight it but that’s an uphill battle. I have my prejudices and preferences and I don’t claim I’m able to fully ignore them.

    The Bad News

    I’m not the only one. I’m tempted to say that every manager is so because the only ones who would be different must be heartless robots which aren’t great candidates for managers anyway.

    This means you as a manager, and your manager too and her manager and so on, are clueless to some point. Usually more than you’d like to admit. This mean there’s a chance your judgments aren’t fair or your work may be misjudged. And finally this means your subordinates can trick you along with your cluelessness to make you think better about them.

    Managers were, are and will be clueless. We may fight with it but we’re likely to fail. Most of us don’t even try anyway.

  • No Meeting Culture

    Meetings are boring. Most meetings are irrelevant. There are too many meetings we have to attend.

    A confession: during past half of year I organized exactly two meetings with engineers in my team. Both were mostly about organizational issues regarding whole company, not just my team.

    How did I do that?

    Let’s start with why meetings are organized. Most of the time meetings happen to enable communication between people. Why don’t people just go to meet each other at their desks? Well, because they sit in different places, have different things to do and, often, have little free slots in their calendars. Sometimes they need to prepare themselves to say something reasonable and invitation to the meeting gives them time for that.

    Basically all these reasons become non-existent when whole team sits in one place.

    You don’t have to busily gather people from different places because, surprise, surprise, everyone is there.

    You don’t have to wander what people do at the moment since, well, you just see it in a glimpse. You can make your call whether it’s a good time to interrupt them at the moment or you should wait for a quarter.

    You don’t feel urge to finish in planned time slot even when the discussion is great and you’re solving problems like crazy. Neither do you feel this funny feeling when everything was said but no one hurries back to work and you just spend your time on chit chat because a meeting room is reserved for another half an hour.

    You can even allow starting talking with folks on subjects they aren’t prepared to. You can because whenever they need to prepare they’ll tell it and a discussion will be restarted later. This is like instantly starting a meeting instead of sending invitations. Odds are everyone is ready and you don’t waste time. If they are not it works similarly to invitation with agenda but better since you start meeting as soon as everyone’s ready.

    You should still think how improve transparency and communication flow but, believe me, once you start talking about almost everything in front of your team, even though you’re talking with a person next desk, people will know way more than they would otherwise. It would work that way even if you reported all your workweek on 4-hour long weekly summary with your team, which would be a candidate for the top dumb management practice of a year by the way.

    And the best thing. With this approach you magically clear everyone’s calendar. Finding slot when everyone is free becomes the easiest thing under the sun because everyone basically stopped attending meetings.

    A cherry on the cake: finding free conference room doesn’t bother you anymore.

    Downsides?

    It won’t work for 50 people. As far as teams aren’t bigger than 10 people it should do well. Vast majority of teams fall in to this category. Sometimes you need to focus and you don’t care about architecture discussion happening over your desk. You can take a break or try to isolate yourself with headphones. Either way it is a cost, but on average it’s significantly lower than it would be if you switched for old-school meeting approach.

    This applies only to team-related meetings. If your people have a lot of cross-team meetings and spend long hours on company-wide roundups filled with jabber this doesn’t have to be huge improvement. But then you’re doomed anyway. One of my engineers attended a few meetings on coding standards beyond these two I organized.

    The approach works best for engineers. Project managers and business people will meet other people more often that once per quarter but it should be still an order of magnitude meetings less than it used to be.

    I wouldn’t get this kind of crazy idea but it happened so my whole team is collocated and it’s the best organizational thing which could happen. If you think it’s drastic, you’re wrong. Meetingless environment comes naturally. Maybe it so because this way you possibly are all time at the meeting, but at the same time you “meet” people only when it’s really needed.

    Try it. And tell me what happens.

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

  • Technical Leadership and People Management

    The other day I had a discussion about leadership and management. When we came to an argument that there’s no chance to advance to a position where you can facilitate leadership and management skills in discussed organization several people (from present and from past) automatically came to my mind. They all have the same problem which they may overlook.

    They all are (or were) great engineers. People you’d love to have on your team. But at some point of their careers they started to think about having their own teams, managing their own people. Hey, that’s natural career path for great engineers, isn’t it?

    Well, actually it is not.

    Do a simple exercise. Think who you consider as a great engineer, no matter if he’s a star book author or your colleague no one outside your company knows about. Now what do they do to pay the rent? I guess they are (surprise, surprise) engineers, tech leads, freelancers, independent consultants or entrepreneurs. I guess there are none who would be called a manager in the first place, even when they happen to do some managerial work from time to time.

    Why? Because these two paths are mutually exclusive. You can’t keep your technical expertise on respected level in the meantime, between performance review of your team member and 3-hour status meeting with your manager. You either keep your hands busy with writing code or you get disconnected with other developers out there.

    On the other hand what makes you a great engineer usually makes you a poor manager at the same time. If you spend all day long coding, you don’t have enough time for people in your team. And they do need your attention. They do much more often than you’d think. If you’re going to be a decent manager big part of your time will be reserved on managerial tasks. There won’t be enough time left to keep on technical track. Sorry.

    That’s why all these people who I thought of have to (or had to) make a decision which way they are (were) going to choose. Technical leadership path means most of the time you won’t have people to manage but you may be respected as an architect, designer, senior engineer. If you’re lucky enough you can even get one of these fancy business cards with title of Chief Scientist or Chief Guru or maybe just a simple Co-Owner.

    Managerial path on the other hand will make you feel lame during basically every technical discussion out there but yes, you will have people to manage. If you’re lucky, and I mean lucky, not competent, you’ll become VP or something.

    You have to choose. Or you had to some time ago. What’s your choice? What do you regret about it?

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

  • A Company Which Didn’t Know How to Fire People

    There was a company, which was doing reasonably well. When times were good they were growing stronger. Some people were leaving, as it always happen, but more were coming on board. Since things were rolling fast no one really had time to stop and verify whether all new faces are doing fine.

    Some time passed. Newbies were no longer newbies – they were semi-experienced people or at least their seniority would indicate that. Reality was a bit different. Some new people appeared to be great hires but other were, well, pretty mediocre.

    Then stagnation period came. There were reasonable amount of work but not as much as it used to be yet somehow everyone looked still pretty busy. Incoming stream of new people were limited and the company mostly stuck with these who already were on board. World crisis increased employee retention.

    Then people started telling stories. A story about the guy who was sleeping at his desk during one third of his office hours. A story about lad who was in the office barely 6 hours a day even though he was paid for 8-hour workday. A story about lass who was spending all days long browsing the web. A story about colleague from another office who claims she’s completely overworked yet she was doing about one tenth of what other people did on similar positions. Morale nose-dived. Productivity started dropping. On a side note – no, these examples weren’t made up.

    Where’s the problem?

    The first symptom was not doing much with poor-performers. OK, they were trying to fix their approach but when coaching and setting rules didn’t work there was no another steps. Underperformers soon learned they didn’t have to change.

    A real problem was: the company wasn’t able to fire people.

    They stuck with every single employee no matter how they sucked. And yes, I know they should try coaching, training, finding new role first. To some point they did. But face it: it isn’t possible to have only perfect teams and only perfect employees. It just doesn’t work that way. Even companies which have very strict recruitment process find black sheep in their teams from time to time. And vast majority of companies aren’t very demanding when it comes to recruitment. Especially when time is good and they need all hands on deck and would take almost anyone who can help at least a bit.

    I understand lack of will to fire people. Firing people sucks. But it’s a part of manager’s job and from time to time it just has to be done. Cost of rejecting to do this is way higher than just poor performance of a couple of people. It spreads like a sickness. Yet somehow I still hear about companies accepting underperformers for some reason.

    Update: Since the post received pretty much buzz in my company a small disclaimer: this is true story but not about my current company, not even about any IT company. Yet still it’s about a firm I know pretty well. Anyway I used the example since the case is pretty general.

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

  • Great Performances in Failed Projects

    It’s always a difficult situation. The last project was late and I don’t mean a few days late. People did a very good job trying to rescue as much as they could but by the time you were in the half you knew they won’t make it on time. Then it comes to these difficult discussions.

    – The project was late.
    – But we couldn’t make it on time even though we were fully engaged. You know it.
    – You didn’t tell me that at the beginning. Then I suppose you thought we’d make it.
    – But it appeared to be different. We did everything by the book and it didn’t work.
    – The result is late. I can’t judge the effort with complete disconnection from the result.

    How to judge a project manager? Final effect was below expectations. Commitment on the other hand went way above expected level. Reasons for failure can be objectively justified. Or can’t they?

    Something went completely wrong. Maybe initial estimates were totally screwed, maybe it was unexpected issue which couldn’t be predicted, or maybe we didn’t have enough information about the way customer would act during implementation. Who should take responsibility?

    It is said that while success has many fathers failure is an orphan. There’s no easy answer, yet manager has to come with one.

    I tend to weigh more how people acted (their commitment and effort) than result (late delivery) but I treat them as interconnected measures. In other words great performer from failed project will get better feedback than underperformer from stunning-success-project. Here’s why:

    • I prefer to have committed team even when they don’t know yet how to deal well with the task. They’ll learn and outgrow average teams which already know how to do the job.

    • I wouldn’t like to encourage hyena-approach, when below-average performers try to join (already) successful projects. It harms team chemistry.

    • If there’s a failure I (as a manager) am responsible for it in the first place. If I did my job well me team would probably be closer to success.

    • Punishing for failure makes people play safe. Team will care more about keeping status quo than trying to improve things around.

    • Lack of appreciation for extraordinary commitment kills any future engagement. If I tried hard and no one saw it I won’t do that another time.

  • Difference between Managers and Leaders

    When talking about managers people often confuse two terms: a manager and a leader. The difference is pretty simple however.

    Management is a job while leadership is an attribute.

    You can be promoted to a manager role, but you can’t be promoted to be a leader. To become one you need to work your butt out showing your leadership in the battlefield. You have to inspire people, make them believe they can achieve a goal and motivate them to work harder. Or smarter. Whatever. That’s definitely not enough to tell them “go and get that and better be quick.”

    In normal situation managers, who aren’t leaders, usually end their work when they tell their teams what to do. Micromanagers go even further. They tell what and how exactly thing should be done. Anyway they’re barely a kind of task-dealers.

    Leaders not only point goals and give out tasks but also encourage people to show their own initiative and creativity. They take decisions when it’s needed and are always ready to face any problem team can encounter. You’d willfully follow the leader while you wouldn’t follow the manager if you didn’t have to. Not that you often have a choice.

    Good manager is always a good leader while poor manager is barely a white collar.