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.

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?

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.

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:

• Managers Are Clueless
• What Motivates People

Under my recent post about best engineering practices I was pointed that it is just another “do whatever works for you” or “I don’t know experiment” kind of advice. Well, it was that kind of advice indeed. Have I ever given you a different one?

Anyway I admit shot was on target. If someone is one of those battlescars who has seen much they probably would be more than happy to hear something like that. On the other hand if you happen to be a freshman you may expect to get something like a real advice. You know, the one which you can simply take and apply in your team without much thinking since “the wise guy said so.”

Coming back to best practices than. What can I tell you besides you should experiment with your practices to find what works for you? Well, if I had to choose one engineering practice which is definitely a sure shot I’d go for continuous integration. And yes, I’m not expecting a flame war under this post.

“Who the hell doesn’t have continuous build yet? We are in 21st century, haven’t you heard?” Yes, I used to treat continuous build as an obvious thing a decade ago and you know what? I was wrong. There are many teams and companies which don’t have continuous build implemented. Why? Because they think it is hard, because it takes time to setup the whole thing, because the project is oh so legacy, because no one cares, because no one approved order for build server, because, because, because… If you want to hit the dog you will find a stick. And many companies are still beating poor puppies hard. I could name huge systems sold to big institutions which never touched a build server.

I can tell it as an anecdote: pretty much every company I worked for set up continuous build once I was working for them. This basically mean the earlier you hired me the better. Not that every company I’ve worked for still exists but we aren’t discuss business here, are we?

If I think about setting up a team or project the very first task to do is getting and configuring a build server. It is a prerequisite to write a first program. And I’m not going to take a look at damn hello world application until build server is up and running. Don’t even say you dared to write any code without continuous build set up.

So this is my first answer about specific engineering practices we all should employ. Unfortunately once I started to give you specific answers I expect to hear “what’s next?” And from this point every answer can be only more difficult.

That doesn’t mean I won’t try though.

I was taught risk management the classic way. You know, risk log, voting for probability and impact, finding out which risks are the most painful, deciding on mitigation plan, discussing results etc.

A cool thing in this old-school process is that it activates different members of the team. Even those, who wouldn’t be asked otherwise. Even those, who would tell you that the project is doomed unless you decide to do something about that performance issue found last month.

At the same time in small teams this kind of process looks like complete overkill. In small teams which deal with small chunks of work knowledge about risks (about everything actually) is often commonly shared. The problem isn’t about bringing individual opinions to the table. The problem is to make risk management as simple as possible yet still effective.

An easy and powerful approach here is to forget that there is something like risk management at all. At least to the point where you don’t consider having dedicated formal process to do risk management. Instead you incorporate risk management to everyday tasks: stand-ups, retrospectives, demos, planning meetings etc. You discuss potential risks every time you discuss a task or story. You discuss potential risks whenever you feel about it.

You won’t even need a risk log. If you talk about risks at every occasion you quickly learn how to catch those which may become painful (filtering by type) and those which are likely to hit you (filtering by frequency of mentioning).

When you keep talking about risks all the time people learn to deal with them naturally as they work on their tasks. Potential performance problem Luke mentioned yesterday? I’ll run some stress tests as I just have a while and maybe Mike would take a look at database as he’s already tweaking it to build that new feature. The trick is we don’t call it a risk. It is just a performance issue. Possible performance issue actually. Luke just thought it might become a problem but in a couple of days the problem will be gone, this way or another. And you don’t need to use the word risk, have a risk log, perform risk assessment, build and implement mitigation plans etc.

The only thing you need to have this kind risk management in place is a bit of trust and open atmosphere. Oh, co-location and no-meeting culture may help as well but in small teams both are usually in place already.

Kanban, as any other methodology, isn’t a silver bullet. There are situations and teams when it shows its full potential but there are others where its impact will be limited. Where Kanban suits best then?

Micro-sized teams

It is said Scrum works best with teams of 7 or close to this size. Sometimes we deal with smaller groups. 3 people working on a project isn’t something very uncommon. For such micro-sized teams Scrum is often too formalized. You can limit a number of rules you follow and still keep good quality. And you have a bit more time to do the real work.

Frequent priority changes

“Walking on water and developing software from specifications are easy if both are frozen.” Unfortunately we deal with a lot of changes as we build software. There are new features; importance of tasks changes, new top priority bugs requires instant attention. Our response is moving to more flexible approaches. We try to avoid BDUF projects. We switch to agile methods employing short iterations. We even make iterations shorter and shorter. It allows us to change priorities frequently. Once every couple of weeks if we take typical Scrum implementation.

The problem is when priorities happen to change even more frequently. Once every few days. Or even every single day. And yes, there are such projects. Kanban is a great answer for them. Feel free to change priorities every day. As long as it is well-grounded it shouldn’t ruin your project.

Maintenance projects

A typical maintenance project routine looks like this:

1. Whenever high-priority bug is submitted fix it as soon as possible
2. Low-priority bugs becomes high-priority ones when resolution deadline approaches; then see above
3. Whenever a client orders change request (CR) and there’s no high-priority bugs – try to do it as soon as possible
4. If there are more than single concurrent CR ask project manager about priorities
5. If there are no bugs or CRs do some refactoring or other improvement job

Sounds like ideal Kanban playground, doesn’t it? That’s typical case of event-driven development (not event-driven programming) where you don’t actually have a roadmap or something but you do whatever new day brings. After all you don’t expect to have a bug submitted tomorrow, or do you?

Multiple small projects

Working on several rather small projects or sub-projects with the same team at the same time is pretty difficult. Resources (what a nice name for your people) are usually insufficient since it is harder to synchronize stream of small orders to keep it at the same level all the time and bringing more people just-in-case isn’t the best business strategy around. This ends up with (surprise, surprise) a lot of priority changes and trade-off games. “We can complete this additional project on time but we’d fail to meet a deadline here or there.”

With standard structured project management approaches coordinating different threads with ever-changing priorities becomes pretty much a hell. What Kanban does is it organizes workflow so the main, well almost the only, thing you should care about is setting priorities at the beginning of workflow.

Common part

The common part for all of environments above is they don’t require many constraints to work. Few simple rules which come with Kanban should be enough to get things done. Another common thing is mid- and long-term planning is hard or even close to impossible, which is another problem hardly resolvable with more structured approaches. These two things are the most specific for environments where Kanban shows its full potential.

This isn’t really a post which is a part of the Kanban Story but if you found it interesting you should like the story as well.

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

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

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

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

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

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

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

You may also like other posts on motivation:

• Why Money Doesn’t Motivate
• Money and Motivation

If you’re into Kanban you probably have heard the term swarming. Actually chances are good you’ve heard the term despite your lack of interest in Kanban.

What is swarming?

In short swarming is all about getting more people to do the task than you’d get otherwise, in normal situation. An example: you have a bug which normally would be fixed by a single developer, but for some reason you have the whole team working on it. And you already have another question…

Why, oh why?

Why would you want people to swarm around a small task? Typically teams do this when they face either a blocker, which hampers whole team, or a very difficult problem, which is hardly solvable by a single person. Either way you get more people to move things further, which would be impossible or at least very difficult otherwise.

Swarming in Kanban, part 1

Up to this point swarming is something teams do intuitively at times. The reason why the term is mentioned so often in the context of Kanban is one of Kanban rules: limiting work in progress. Because in Kanban we want to have as few ongoing tasks as possible, yet as much as it still does make sense, we have limits for different stages of our process. And it when we hit the limit we treat it as a problem which we want to solve and we want to solve it fast. That’s why we swarm.

Swarming in Kanban, part 2

There is another thing which you may read about, which I call everyday swarming. Everyday swarming is done by teams which swarm by default, when no emergency situation happens. The reason standing behind this behavior is trying to make cycle time and/or lead time as short as possible thus flow of tasks very rapid and smooth. Oh, and you have fewer ongoing tasks then too, which means you have less work in progress, which means you have less waste, which means you are oh so lean.

Our story

I must admit I don’t really like the idea of everyday swarming. I mean cycle time is definitely shorter but I’m so sure about throughput. Flow is smoother but you kick in a lot of micro-switches when a few people need to integrate their work into one piece of code since they all have worked on a single feature. You also may invite some issues with version control this way since you’ll be working on the same chunks of code. For me the net weight of swarming by default is negative.

Basically that’s why we avoid swarming whenever possible. When there is some serious problem to solve and standard approach is not enough we naturally help each other. One person after another joins the rescue team and this basically ends as swarming. But other than that we prefer to have only one person working on the task at the same time. Well, of course there are exceptions like discussing design or testing and bug-seeking/bug-fixing but these all are pretty natural things for any software development team. After all it would be pretty schizophrenic to discuss the design with oneself.

It looks like we swarm as David Anderson initially proposed, despite ignoring David’s teachings when it comes to lead time. I think this is the most natural way of swarming. But of course you remember the rule to experiment like crazy, so you may want to try something different in your team.

Read the rest of Kanban Story as well.