My recent post on verifying competence triggered some reactions, one of them being specifically interesting. Bob Marshall pointed that my idea of competence test isn’t congruent with Deming’s teachings, namely 95/5 rule.

Deming says that 95% of performance is attributable to the system and only remaining 5% can be attributed to individuals. Does it render the question “Would you hire a discussed person to your own dream company to work in the same role?” irrelevant?

I don’t think so. The question isn’t really a very generic one and there are a few assumptions made already before you ask it.

• You have control over the system. Actually the question is about your own company, which means it isn’t some hypothetical organization or random system. We’re discussing the organization you’d like to have. The best possible one you can think of. Besides, you will have a chance to improve the system too.

• The system is the same for everyone. We don’t discuss best possible performance in the world (whatever that would mean) but performance of different individuals within the same system, namely your company. This means the only differentiators which come into play are individual traits and individual performance.

• We compare similar systems. Even though we have in mind our dream company we shouldn’t assume it would automatically be top-performing system. If we worked whole professional life in average systems what we are likely to achieve is slightly-above-average system. The change between two organizations (current workplace and our company) won’t be as dramatic. Theoretically it is of course possible, but not likely.

Besides, what we look for in the competence test isn’t aimed at finding the best performing work environment. It is aimed at finding the right people. Of course I silently assume you won’t hire wrong people to do wrong jobs. I would probably hire none of great developers I know if I started a restaurant.

If I’m not clear enough let’s go through an example. There is Mark the Coder who works for yet another average software shop. Mark the Coder stands out, at least at his current organization. Now let’s hire Mark in another average software shop. Would he still stand out? Pretty likely.

OK, so now hire Mark in low-performing company. His personal traits which made him shine in the original organization will play even more important role as the background is worse. Would he still stand out? Yes. Would he perform better than in original situation? Rather not. Actually relatively he should perform worse, but he would still be considered as great performer in his new environment.

What happens if we hire Mark in high performing organization then? He will likely perform better, as the system itself performs better, but it isn’t so obvious whether he will still be considered as one of top performers. Why? First, high-performing organization is a competitive background for personal traits and second, high-performing organizations tend to draw many top performers making it more difficult to stand out. Either way Mark the Coder should cope with the new situation, even if he loses the guru plaque.

I know that what we really consider asking the question “Would you hire that person in your own organization?” is the last scenario, which is also the one with least obvious outcome. However if someone has a chance to become a top performer in the new high-performing system it is likely the one who was already among top performers in the old organization, thus Mark the Coder serves as a good candidate here.

So no, I don’t find the ultimate competence test conflicting with Deming’s teaching. Do you?

Every now and then we judge people we work with. We go through performance reviews, we recruit and we chat over coffee or beer backbiting our colleagues.

We use different metrics to make our judgment, anything from formal appraisal process to gut feelings, which renders the results incomparable. There is however one method you may use to decide about competence of different people, from junior team members to your managers.

The ultimate test of competence:

Ask yourself whether you’d hire the person to your own dream company to work in the same role.

If the answer is “I don’t know really” you should count is as “no.”

If you’d pay someone your own money to have them in the team and in the company it is obvious indicator telling that you consider the person as competent, non-toxic and cooperative. The same situation is with leaders – if you’d like to hire someone as a manager in your dream company they can’t suck. Or do they?

If you ask me, I’d hire my whole team in my own company. After all, this isn’t the first organization we all work in.

Now think how many of your current colleagues and managers you’d want to see as a part of your own business. I’m curious to hear your answers.

I was a part of an interesting dialogue:

– Pawel, tell me about your last success.

– The last launch went flawlessly which means the way we chose to organize the project proved itself as pretty damn good.

– OK, and what about your last failure?

– I feel I can’t get through with ideas on improving the organization.

Now the good part isn’t really me answering these two simple questions, even though I think it is a great idea to ask your people from time to time about their successes and failures. The good part is something I caught myself at after a while.

It was our success and my failure.

And the better part – it is not just about words. It is about the way of thinking. I might have said I had chosen our methodology and probably no one would have noticed. But what you say isn’t as important as what you believe.

If you just switch words to the right ones you will achieve something important – recognition in front of execs is quite a token of motivation after all. But if you really believe in what you say you’ll achieve much more. You’ll always act as the success was an effect of collective effort, not only when you are in front of senior management. Besides, it was an effect of collective effort, wasn’t it?

So tell me, what your last success was. And how about your last failure?

I discussed recently changing the process in one of teams in the organization. In theory everything is totally easy. We need to assess current situation, find out what should be changed to improve the way the team works, apply new ideas and support them over some time to make them persistent and then go for a couple of beers and congratulate each other a stunning success.

In this specific situation we have already a couple of ideas which should help. And yes, they include K-word. Yet still the plan is to start as we didn’t know much about the team. We try to act as the hammer wasn’t the only tool in our toolbox, even though we do have a hammer too.

Once we know what is wrong we can apply a cure. And that’s where the hard part begins. If you look at typical pattern of change implementation you will see that the first period after inviting change sucks. People don’t know yet how to work with the new tool, process, rule, you-name-it. Outcomes are likely to be worse than with the old approach. After all, no one said changes are easy.

Now, here is the trick: if you’re trying to implement change you not only strive to overcome typical issues but also have a reluctant team, which doesn’t want any change at all, you’re going to fail.

People will get enough arguments to abandon change and if all they want is to get back to the good old way of doing things they will use this chance. What do you need to do then?

Get more team buy-in.

Actually this is what you should start with. When you assess current situation you talk with team members. If you don’t talk with people your assessment stinks anyway and I don’t want to touch it even with a stick. Use this opportunity to get people buy-in. You will need every single supporter you can have when issues start popping out.

Don’t implement change unless you’re able to convince people it is a reasonable idea which would help them and you really don’t try to make their lives more miserable. Even if you personally are convinced that you have a silver bullet which would change your crappy software house into another Google, only better, you won’t win against people who have to follow your process, execute your idea and deal with all of side effects of a new situation.

When I read discussions about some approach, which appears to be working rather poorly, the first thing which comes to my mind is lack of buy-in among people who are affected by the change. In terms of implementing agile we often forget that problems seen within development team are often triggered outside, likely by management. That’s why, for the purpose of this article, I use term “team” to name everyone whose work will be significantly affected by the change.

Anyway the pattern remains the same. You just need more buy-in. You may need to work on this with development team but you may need to work with management too. Whichever case is true in your situation, go fix it before you start implementing change. That is, unless you find it pleasant to fail.

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?

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.

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.

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?

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.