Pawel Brodzinski on Leadership in Technology

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

Tag: team management

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

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

  • Money as a Motivator

    OK, the subject will be controversial. Money as a motivator. If you ask people what motivates them to work, they’d throw a bunch of different things much more often than they’d say about remuneration. Self-development options are evergreen here, but good atmosphere, top technologies, interesting products or well-organized processes are all mentioned more often than pure cash. By the way that’s one of my interview questions and, believe me, I hear “money” much, much less than I’d expect. Rob Walling presents quite a long list of different qualities which are valued more than money by developers. That’s first perspective.

    Another one is pointing money actually does no good in the area of motivating people. David Carr in his post about money as a motivator shows a list of examples where money doesn’t really affect positively people’s work or even harm their attitude and, as a result, effectiveness. That’s other perspective.

    Personally I strongly believe in non-monetary motivating techniques. “CEO’s handshake” followed by several words of praise can have much more impact than a payload of money. That’s another perspective.

    Having said all of that, ask people if they’re willing to change the job for a better one in almost every aspect they can imagine. Better atmosphere, cooler technology, more interesting products and wide range of possibilities to self-develop. The only worse thing would be money. Few would follow. And if you leave aside those who are starting their own businesses you end up almost empty-handed.

    Now, do another test – situation is the same but in the second job money is better, but e.g. atmosphere is worse. More candidates? What a surprise. Oh, is that really such a big surprise?

    OK, where’s my point then? There are a few of them actually:

    • Money alone doesn’t work very well when you want to add motivation over the standard effort.

    • Money is very often used wrong. If it is so the result are usually opposite than intended.

    • When used well, which is rather rare by the way, money can work as a motivator.

    • Non-monetary motivation techniques are essential but they don’t substitute remuneration – they supplement money.

    • Money is more important for people than they’d be willing to admit.

  • Team Management: Find Your Way

    As you probably know, my view on management is rather classic – nothing very far from whatever you can find in a respected canon. I’m against micromanagement, but I try to care about details which are important for people. I try hard to be honest with the team and praise them when they deserved. I believe good performance reviews are important. Just old-school, boring management techniques.

    I believe that’s the way the whole management thing should be done. However it fascinates me every time I read about Bill Gates’ style of management or One Google Management Way.

    Bill, the builder of the greatest company in nineties was considered as bully and the one above isn’t the only example. OK, you can find a lot of bullies in high management around, but somehow many people in Microsoft saw in there a way to improve people’s performance. Everyone had to be superbly prepared, ready to discuss every detail of their opinions and able to resist pressure. Bill’s charisma was essential in building company’s power and his attitude was an integral part of it. You can say it’s weird and it doesn’t work anywhere else, but with Microsoft results speak for themselves.

    When you take current decade and look for its symbol you probably see Google. And you see another strange approach to management. More than 50 people in teams, when 7 people are considered as the optimal group to manage. Famous 20% of time for pet projects. Extremely tough recruitment process with more than 7 meetings on average before hiring. Engineers as sacred cows. All of those, and many more, combined in one place create unique management culture, which is against anything you could learn during an MBA course. And it builds the success of the company.

    I’m impressed. But I’m not going to follow. There are of course some ideas I’d like to implement but, in both scenarios, model as a whole isn’t copyable. As Tom Evslin writes, a barely-graduated hire won’t be as smart as Bill Gates only when he’s as rude. Typical organization won’t achieve a stunning success only when they spend one day in a week for employees’ pet projects.

    I think that organizing a company in a way which allows people to like (just like, nothing more) their employer is tough enough to doom the management to failure in vast majority of cases.

  • My Micromanagement Experience

    I’ve already written about micromanagement in general. Thing I haven’t yet shared is my own experience with learning how to live without micromanagement.

    When I started having any impact on my colleagues (I wasn’t their formal boss, it was just an informal leader role) I also got some responsibility for a part of development process – it was planning and running functional testing against an application. Because people I worked with were all newbies I decided (surprise, surprise) that I’ll do the most responsible part leaving “my” team the rest. It looked so natural. Hey, who’s the most experienced person here? Who’s the hero?

    There were only five of us, including me, so it worked well that way – the final release was hard earned, but despite 3-week slip I still consider it as a success. I earned my very own team then. It soon grew up as we took over also responsibility for support. And then the model collapsed. I could no longer take every important issue on me. I could no longer check everyone’s work. I could no longer say how to do every tiny detail of our work. More people – more managerish work and less time for the rest. Bigger responsibility – more important tasks to control.

    I was lucky to have quite a good team then with several persons which had already earned my trust, so my lesson didn’t have a big impact on our general performance, but with other people I wouldn’t be so sure if I’d be there, where I am now.

    Later on, my boss asked me who’d be my successor as a manager. I didn’t know, but I told him I’d come with some plan on that. I thought about that: “Hey, I’m the one who know the job – the team is only executor of my will. How they’d know what to do without me?” The Red Light of Micromanagement would blink then if there were any. This was another lesson to learn – the team has to do all the tasks, even most important ones (maybe except of some managerial crappy things no one wants to deal with). “What-ifs” came to support the lesson. What if I went to holidays and something serious would happen? What if a car hit me? What if I changed the job? Oh, wrong example, who’d care than? What if I was promoted than? The answer was always: it would be a problem.

    I found a couple of people and delegate (what a nice word) important tasks to them. Not every single case was delegated, but at least every type of task. I found my successor too. And when I was promoted half a year later, my leaving was totally smooth.

    There’s another lesson I still learn. I work with project managers these days and I’m often tempted to say: do this and that. Act like this. Send the darn e-mail to the darn subcontractor with the darn escalation of the darn issue. To be honest I don’t always restrain the temptation (in other case it wouldn’t be the lesson I still learn). With experienced PMs it’s easier because I know they’ll discuss it with me if they have another idea. It’s harder with those who are still learning the job. I keep reminding myself, like a mantra: “let them decide, let them decide, let them decide, let them…” I know they’ll screw some tasks. However, that way their learning curve will be narrower and they’ll progress to a level when they’ll be tough partners in discussion. Especially when I’ll try to micromanage.

    I think the last thing is the most important one – let people learn. Even when you know they’ll fall, don’t take them through the obstacles on your own back. Let them fall and give them a hand then. Most of people learn on their own mistakes, only some very smart ones learn on others’ mistakes. I prefer to have first two project done with some issues and another ten done well (without my help) than to have first to project done well and another ten facing serious issues, because I can no longer make decisions and PM hasn’t had a chance to learn how to do it himself.

  • Micromanagement

    Today, I’ll write something so obvious that I’m almost ashamed of it. I thought if there’s anybody who doesn’t know that, but I still see lots and lots of people who act like they should read below advices. There’s a second reason also – it’s always worth to remind to myself these points.

    Micromanagement, that’s what I want to write about today. Why is it bad? There’s a bunch of reasons:

    • Manager can’t do everyone’s work. He has in the team 5, 10 or maybe 50 people, so in every case they do more than a single person could. Even if he’s a superhero. Even if there’s only one person in the team. Remember the manager has his own work. Oh, at last he should have some.

    • Manager’s competence doesn’t cover all competence in her team. She usually isn’t the best developer, the best tester, the best project manager. She has the best managerial attributes. Oh, at last she should have some. That’s why she’s the boss. I hope that’s the reason, in other case I offer my condolences to you.

    • Telling people how exactly they should do their tasks is usually stupid because they usually know better. They are closer to issues, closer to code/functionality/project plan/whatever and they work on that every single day (not only during micromanagement day of the week). Manager is like a driver – he can say if the car looks nice and drives fast. His team is like mechanics – they know what exactly happens in the engine. You’d rather ask the mechanic, not the driver how to fix brakes in you car, wouldn’t you?

    • In these several cases when the manager knows better what to do and how to do, telling people how exactly they should do their tasks is stupid, because people don’t learn accountability then. If the manager taught them micromanaging, they won’t take initiative, won’t be creative and won’t look for improvements of their work. Why should they? That’s the manager who tells them exactly how to work. But remember, she doesn’t have the time to micromanage every single person on regular basis. Even if she’s a superhero.

    Yeah, stupid indeed. It’s obvious. Why to write about that? I’ll answer with a question: why so there’s still so much micromanaging?

    I think reasons are different. When I recall micromanagers I met they’re driven by different demons. There’re two I Know It Better demons – first when the manager really know better how to deal with a task or an issue and second when he thinks he knows. The latter is much more common. There’s Do What I Say demon, when it doesn’t really matters if the solution is right or wrong, it’s all about doing what the manager said just to support his ego. There’s You Don’t Know The Big Picture demon, when micromanaging is justified with lack of wide knowledge about whole situation within the team. Nothing easier but to share the knowledge. There’re of course others, but those are the most common.

    You should listen none of them. There’s always a better way to deal with the task or the issue than micromanaging. You can come with your idea in every situation but don’t treat yourself as unmistakable, because you’re not (I bet). Bring discussion and be open to change your mind if someone, especially someone who’ll actually do the work, comes with another idea. And tell people what to do, not how to do that.