Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • The Role of Manager

    I took part in a very interesting discussion today. We were talking about criteria we should use to appraise leaders and managers in the organization. The most surprising part, at least for me, was discussion about notion of line manager among disputants.

    It came out that we considered average functional manager as anything between pure-manager to person who does 90% of engineering work mixed with 10% of managerial tasks. That’s a variety of options, isn’t it? As you may guess I supported rather the former than the latter.

    Well, if I’m such an opponent of letting people do what they used to do before they were promoted to management, likely coding if we talk about software teams, what I think they should do all day long? In other words what is, or should be, the role of manager.

    Leader

    This vague term describes first and most important trait most managers should have and only few have. If I’m a team member I expect my manager will show leadership and charisma. I want to be ignited to follow his ideas. I need to be sure he knows why and where we are heading. I have to see him around when problems arise. I eager to be managed by someone I’d like to follow even if no one told me so. A good manager is also a good leader but these two are not the same. What a pity it isn’t common mixture.

    Coach

    Help newcomers with learning the organization. Help inexperienced with gaining experience. Help everyone with growing. Help those with problems with fixing them. Easy? No, not at all. First, you need to know who needs what. Then, you need to know how to reach people so your helping hand won’t be rejected. Finally, you need to work carefully and patiently sharing your knowledge in experience in a way which doesn’t frustrate or dishearten people. Repeat when finished.

    Shield

    As a line manager you have some senior management over your head. This is a bad news. Actually there’s usually a lot of crap flying over there and, because of the gravity, it’s going to land down on heads of your team. There will be blame games. There will be pointing fingers. It is your time. Be a shield. Take enough bullets on your chest for the team. You’ll earn respect. You’ll earn a bunch of loyal followers. And that’s how you earn your spurs.

    Advocate

    As a manager you’re also an advocate. Devil’s advocate to be precise. You have to present and defend different decisions made up there, in the place where only C-level execs are allowed. Sometimes these decisions you won’t like. But for your people you’re still the face of the company so don’t play the angry boy and act like a man. We don’t always do what we want. After all, they pay you for this, remember?

    Motivator

    Sometimes everyone needs a kick in the butt to get back to work at full speed. It would be quite a pleasant task but unfortunately kicking butts is used as a metaphor here. It’s all about motivation. And I have a bad news here, there’s no easy answer for a question what motivates people. You have to learn each of your people individually. Oh, forgot to mention, it takes quite a lot of time to learn what drives all these people.

    Adviser

    Yes, an adviser. Not a decision-maker. At least not unless you really have to make a decision by yourself. People will come to you asking different things. Well, they will if they think your opinion may add some value and you’re capable to understand what the hell they are talking about. Of course you can guess or shoot or use magic 8 ball but you better learn (oh no! more learning) what the problem really is and help your team to solve it. Note: it is different than solving it for them, even if you know the answer. If an association which comes to your mind is delegation I must praise your reasoning.

    Now if you are done with those and still have enough time to keep up your outstanding engineering skills, please do Mr. Anderson. Unfortunately chances are good it is enough to fill more than a full working day so you’d have to choose between focusing on your management or technical skills.

    And if you happen to spend two third of your day coding, well, I dare to say you aren’t a manager I’d like to work for. Your people would say the same, but you don’t talk with them so you don’t even know. After all there’s no time to chit chat, you have to code, right?

  • Performance Reviews Are Dead, Long Live Performance Reviews

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

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

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

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

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

    Don’t make it all about money

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

    It is your goddamn duty to listen

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

    Make it more a chit chat than a formal meeting

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

    Let them set the rules

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

    Be open, be transparent

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

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

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

  • The Kanban Story: When and Why We Abuse Limits

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

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

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

    When do we abuse limits?

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

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

    Why do we abuse limits?

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

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

    How do we abuse limits?

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

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

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

    How often do we abuse limits?

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

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

    So far it works pretty well.

    Read the rest of the Kanban Story.

  • Why I Prefer to Hire Women

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

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

    There should be more women in the industry.

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

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

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

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

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

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

  • Learning Project Management Basics

    A question about starting career in project management is heard pretty often. A question about value of different project management certifications usually follows.

    There is a bunch of standard answers for these questions. Apply for junior role in project management. Attend a course. Help your PM in her job. Get a certificate (this or another). Buy and read a stack of books on project management etc.

    I have another answer. Actually the answer isn’t exactly mine. I’ve ruthlessly stolen it from Scott Berkun.

    Go, run a project.

    “How? I mean I’m yet trying to get project management job, remember?”

    Pretty much everything which happens around you is a kind of project. If you invite a group of friend for a dinner it is a project. If that doesn’t sound like a real project think bigger. Maybe you can organize vacations for friends?

    “Yeah, and what do I learn from such a simple thing?”

    Don’t tell me it’s easy – I’m just finalizing sailing trip for 25 people. And, believe me, friends aren’t the best clients you can find around. It requires the same skills you’ll be using once you get your PM job to organize this kind of trip.

    “Maybe that’s a nice idea but I don’t have 25 friends.”

    That sucks, man. But you definitely have some non-profit organization which would appreciate some help in their projects. And they do have a lot of them. And they’d love your help they’d get for free (non-profit often means non-paying too).

    “But, you know, this whole non-profit stiff isn’t really something I’d like to work on.”

    Um, you think once you are a project manager you’ll be able to choose projects you like and reject those you don’t. I have a bad news for you. You won’t. You know life isn’t as nice as they told you.

    “OK, but how it helps me to learn project management?”

    You basically organize a group of people to do what you want. They come to a meeting point. They go to target place where they’re warmly welcomed by your hosts. People know when they can go watch latest World Cup match and when they should bring you a cold beer in exchange for organizing this great trip. Earlier everyone paid you their share of costs so you could have paid for your shelter.

    This isn’t much different from project management in real world. You make people doing what you want. They work on a project tasks of your choice. Everyone knows when they’re free to learn new technology and when they should focus of finishing before deadline. Earlier people agreed on plan of splitting tasks and build a schedule etc.

    “What about all the formal stuff? I don’t have to create technical specifications when I organize a trip for friends.”

    Oh, really? You don’t? That’s interesting… OK, just joking. All the formal stuff will differ among companies so it isn’t so important anyway. Of course you should know what WBS is and understand how to find critical path, but that’s not a rocket science.

    What more usually candidates for project management positions lack practical knowledge – lack of understanding of some technical terms isn’t so common.

    So go, find a project and run it. After all there aren’t many things which would match your friends thanking you for a great trip and asking whether you’re organizing it next year too. This single thing is worth the whole effort. The funny thing is it works similarly in projects you run at work.

    By the way, I’d use the same method to learn leadership.

  • Agile Isn’t Immune for People Who Don’t Give a Damn

    I like presenting. I just love the fact that every time I deliver the presentation I find something new in there. It’s like having tiny epiphanies while you’re talking to a crowd. And I’m sure I wouldn’t have them if I didn’t overcome my fears and didn’t start speaking publicly.

    A thing which hit me last time I was delivering my Kanban Story presentation was how fragile agile is in terms of people who don’t give a damn. In the summary of presentation I make a point that Kanban may not be for your team if you work with undisciplined engineers.

    But what I realized while I was talking it is not only about lack of discipline. It’s about care. In Kanban people have to care about Kanban board. They have to move cards as they progress with features. They can’t abuse limits unless it is agreed among the team and team rules allow to. They should think how they could improve the board. They should keep the board up to date.

    Why it is so important? Because the board is single most important information radiator in Kanban teams. If contents of Kanban board are random you spread random information about project among the team and outside the team. You pretty much misinform everyone around. And now the important thing:

    In Kanban teams anyone can easily abuse Kanban board.

    It’s enough someone doesn’t care. He doesn’t care to move cards through the board or put his marker on task he’s working on at the moment or ignore transition criteria or whatever. Suddenly you have random Kanban board and no systemic tools to deal with the issue. People versus Kanban 1:0 at halftime. If you want to know how the match ends, well, you’ll have to read the blog in future since it is a subject for another post.

    It’s already half of A4 page and I haven’t really mentioned agile in general. Only Kanban. Kanban this and Kanban that. Don’t I have something else to say? Well, I do, thanks for bearing with me so far.

    One of reasons why Kanban is so easily abused by people who don’t give a damn is the fact that Kanban prescribes close to nothing. But enough of K-word. Scrum is more formal. Actually Scrum is pretty formal approach if you ask me. How it deals with the problem?

    A bit better. Stand-ups, time-boxing and planning meetings are all practices which help to deal with undisciplined team members. (I wanted to write “engineers” instead of “team members” but I’ve just recalled there are no roles in Scrum besides Scrum Master, Product Owner and Team Member and I prefer not to be killed by some Scrum extremist.) With these practices it is easier to make someone stick to convert folks who don’t care. If you work with Scrum you can’t work without time-boxing while the rest of the team has 2-week long sprints. You are asked the same questions as everyone else during stand-ups. There is more of a stick in Scrum than in Kanban. (Have I just said K-word?)

    XP goes even further. Rules are surrounding you everywhere, my poor engineer. It almost tells you how to pee. Not in pairs. fortunately If you work with XP and you don’t give a damn you’re probably already fired.

    But let’s face it – how many teams out there use eXtreme Programming religiously? Few. More of them follow just a couple of engineering techniques choosing Scrum as their process base. And even then we have whole variety of Scrumbuts, Scrumbans and Scrumwhatevers.

    Average agile approach in real world, if there happen to be something like that, would cover a very limited number of rules. I’d say that there would be less of them than Scrum proposes. And even then rules are often softened or teams choose those which are less painful to adapt.

    So we come back to the first point. The fewer constraints (aka enforced practices) we have in place the more easily our process can be abused by people who don’t give a damn. If your method base on a lot of common understanding instead of tons of process documentations and a number of strict rules buying all people in becomes crucial. Having few rules means that you give people power to create and adjust your software development/project management approach.

    It also means you give them power to destroy and harm it.

    If you like this post you should thank Michal who took the discussion up on Twitter.

  • Don’t Promote Best Engineers to Management Positions

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

    I knew nothing.

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

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

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

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

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

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

  • Choose Your Battles

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

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

    Stop.

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

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

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

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

    You learn to choose your battles.

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

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

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

  • You Can Manage Your Boss

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

    And this is wrong.

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

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

    Wrong.

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

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

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

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

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

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

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

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

  • We Know Nothing about Our Teams

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

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

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

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

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

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

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

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

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