Our team was reinforced lately by an experienced project manager. He worked in his previous company with one of our clients. I’d add that our client works in formalized environment where compliance with procedures is (usually) very important, which should limit freedom in project management. The interesting thing is we can confront our experience.

If I had to give one general conclusion I would say that the way the project is run is highly dependent on people, especially project managers, on client side.

Project manager’s strengths and weaknesses have great impact on the whole project. With a great organizer you won’t need to ping them for each delivery you’ve agreed. With a PM with wide technical knowledge most issues can be resolved in small group and there’s no need to check every little thing with specialists. Person who work in the organization for years will know each shortcut and backdoor within procedures and will be able to exploit them. Overloaded project manager won’t push a project very hard as he’s, well, overloaded. Guy who’s not liked much among colleagues will find hard to organize help whenever needed.

Project we compared were run completely different. While general procedures which applied were exactly the same project managers had different profiles. By the way, I guess if we had other guy on the other side we would finish our project later.

On a side note I’m sure the same rule applies when you’re a client and you look at vendor’s project manager.

That’s why it’s so important to know who is on the other side. You want it or not you’ll have to adjust to people you work with. You’ll need to exploit their strengths and mitigate impact of their weaknesses. And I’ve seen enough different types of PMs to believe that depending on people on the other side project implementation can look dramatically different.

Who is on your other side?

Ray White gives a tip for managers:

“Love what you do. And love it.”

I wouldn’t limit it for managers only. No matter if you have to show leadership or expertise or engagement. As far as you like what you do and you’re able to show it to others people will appreciate your efforts. It is true when you’re a leader and you try to fire up your team. It is true when you’re a team member and you look for support from your boss and colleagues.

Scott Berkun comes with another law of management. A true gem:

“It is your fault.”

Whenever you screw something up take the responsibility instead of looking for an excuse. Another time I definitely don’t leave that for managers only. Your colleagues should appreciate your ability to admit your failure. Your bosses should appreciate that too. And of course most of all your team will appreciate when “you take enough bullets for them.”

When I read Ray and Scott I realized once again these are things I look for whenever I recruit. And I do it partially unconsciously. Except of expertise in specific area I want to work with people, who love what they do and are able to admit it’s their fault.

It makes a better team that way.

I hear that question a lot during interviews.

What’s your working hours here?

And my answer is always the same.

Whichever suit you fine.

Of course flexible work-time brings some issues. It will be harder to organize meeting when you have in the team a person who starts at 7am and another who starts at noon if you’re lucky. It can happen that you’ll end up with sleep lovers only and no one would react early in the morning. You won’t predict exactly when your colleagues will be at work.

But these are rather small issues when compared with making people a bit happier. People able to wake up late if they like that. People able to go on errands for themselves during workday whenever they need. You can’t count that in money. It’s hard to verify productivity growth. But making people a happier always works.

There’s one trap here. Flexi hours are often a name for working overtime. Then, well, it’s not so good idea. I prefer to tell honestly: sometimes we do work overtime. It happens. We don’t treat as a normal situation but it happens from time to time. And we don’t call it flexi time.

As far as a deal is fair it is definitely worthwhile. Especially when you work in IT environment where you can find more people who appreciate freedom. If it doesn’t kill your work processes, go for it.

How many times you were in a situation when salespeople told you how to develop software? Or how much time you need to complete an application. Or how easy it is to implement an integration interface.

OK, I have another question. How many times you told salesmen how to sell your software? Or how much they should charge for your professional services. Or how they should talk with the customer.

One of wisest things one of ex-CEOs said was “developers always know better how to sell and salespeople always know better how to develop.” Since then I try to catch myself each time when I tell our friends from sales team how they should do their work. Although I’m not completely successful at that I think my awareness has grown much. As the side effect I’m also more aware when others tell me how we should produce our software.

Anyways, my observations aren’t very optimistic. I can say we generally think we know better how others should work. And we rarely stop to think why the heck we’re spending all our days writing some code in Java instead of selling software if we’re so darn good at that. Or the other way around.

Whichever technique, habit or task you’re trying to invite, be consistent. No matter how poor you are on the beginning consistency will most likely make it work.

It can be new system managing tasks from other departments. Just force yourself to use it always, for every single task you receive. It can be a simple training you try to exercise to learn new things. Just start every day doing that. It can be code review you’re trying to implement in your team. Just have the code reviewed every time you submit it to the repository.

Even when a starting point is far, far away from whatever you’re trying to achieve consistency will give you a chance to succeed. With each day the task will be a bit easier. Just be consistent.

By the way if I consider this blog as a success the only reason is I am consistent with my writing.

We use to say user interfaces we create are ugly. And in many cases we don’t care.

When I’m a user I complain every time when I work with unintuitive application.

Where’s my consistency then?

A little difference is within target group of users. When a target group for an application are typical Internet-eaters, like you or me, you need to give more. It’s not enough to have every single feature user can think of. You need to have it intuitive and nice. Other way people will go away choosing either ease of use or beautiful façade of competitors. By the way I’m still struggling with Office 2007 – it is way nicer than its predecessor but for biased user of a series of older version new interface isn’t very intuitive. That’s definitely not a sure shot when talking about GUI.

Fortunately you can have another group of end-users. System administrators are great example. They need to be able to do as much things as they can with their UI. Flexibility is a number one here. Intuitiveness is important too but usually users are far too experienced to allow your application to defeat them. But nice GUI design? Who cares? As far as it allows you to do what you want you don’t give a damn how it looks like.

On the side note I’m not a complete hypocrite. In our internal timesheets application I don’t care about GUI design as far as I have reports I need and my team doesn’t cry whenever they need to fill in monthly data. And that interface is ugly indeed.

Coming back to GUI we develop, most of them are either for administrators or for maintenance teams. Then we don’t have to focus much on UI graphical design. No one would really pay for it. Ugly can be good enough.

I had a discussion with Simon a couple of days go about procedures in a company. Do people need them? When they need more RAM in their machine or they’d appreciate a new chair would they prefer having written instruction telling them what to do or they’d choose just to say about the problem to someone, possibly their supervisor.

In my opinion people don’t need procedures. Companies do.

When organization grows it’s harder to keep everything in order as more people mean more issues and more chaos. Over time it appears no one can handle this and procedures come to save the world. I mean company. And that’s perfectly OK.

But an average employee needs just to have his issues resolved. Nothing more. I think most people don’t give a damn about procedures unless they’re forced to do that.

And what do you think?

Do you like your team?

Can you ask your colleagues freely whenever you feel like it?

Would you feel supported if you wanted to change your profile within the organization?

Do you feel comfortable when you go talk about work issues with your superiors?

Do they listen to you?

Does your boss say simple “sorry” when he screws something up?

Did recruiters were completely honest during your interview?

Is there “one for all, all for one” kind of environment?

Have the most annoying thing changed over the past year?

Would you recommend the company to your friends?

If the answer is 10 times “yes” you probably work in a great company.

You get an unfair email from the customer addressed to you. You publicly hear an opinion about you which you definitely don’t agree with. You face negative feedback which has to do much more with the “negative” part than with the “feedback” one. You are accused of something you don’t feel responsible for. I guess everyone was in those kind of situations. And it hasn’t happened only once.

Then you want to express your whole indignation. You want to answer immediately.

Don’t.

Calm down. Don’t let emotions to play first fiddle. If you can talk face to face about the situation wait until you can discuss merits, not emotions. If you can’t talk don’t rush to reply the email instantly. Wait. And don’t do the whole thing publicly.

Other way you won’t get what the other persons wanted to tell you. You won’t move closer to a problem solution but rather keep it where no consensus can be achieved and no one can learn anything.

Calm down, unless you keep your emotions boiling on purpose, which should be very rare situation by the way.

I’m just after 7 hours of interviews in a row. Exhausting. Don’t try that at home. I know I should use smaller chunks. It would be better both for me and for candidates. Anyway I made it on purpose and I don’t regret although my brain is dead today.

I had some time to think about the way we interview and how it is connected with small size of our company. When you’re small you recruit much different than when you’re big. You don’t have evil HR team organizing the whole thing. Sometimes you struggle with not enough resumes. You can’t afford to make 6 interviews before hiring a person. It’s different.

How to deal with that?

1. Many to one interview model.
I usually take a colleague with me to have numerical advantage over a candidate. OK that’s really to have better coverage of merits on our side. And we sometimes ask similar questions so it limits redundant answers. After all we still can cross check our opinions. It also limits our needs when talking about meeting room reservations, which can be quite a pain in the ass.

2. One interview is enough.
We don’t have enough time to make numerous interviews so we stick with one meeting although we’re not religious when talking about interview time. We don’t pack it into an hour. Standard plan is hour and a half although, depending on the candidate, we can go longer. One interview is enough, one hour is not.

3. Do look where others don’t.
People suck at writing resumes. Yes, they should learn that but you can’t force them. But you can find real gems among poorly written resumes. That’s a hard work and most of poor papers are followed by poor candidates but that can be your chance.

4. Don’t waste the time.
As you don’t have your HR army recruitment takes your time. Time you could have spent on other tasks. Don’t waste it then. When you see there aren’t even a chance, end quick and go do something more useful. I can’t force myself to just end interview at the very moment I realize I waste the time. Instead I just ask a couple of finishing questions, which takes just a few minutes more. If you went out from my interview after a quarter, I’m sorry but your chances aren’t good.

5. Make it tough.
Make it nice, but tough. You have way less chances to evaluate a candidate, so make the test difficult. Other way you’ll be guessing, not deciding. And you don’t want to guess whether the candidate is worthy, do you?

6. Be honest.
You’ll probably get some questions from a candidate you’d rather not answer. Sure you have the choice. You can say the truth, color a bit the reality or just lie. Choose the answer number one. Be honest. You can lose a person who will go to another company but you won’t lose your credibility. And if you lied about important things he’d leave soon anyway. Personally I wouldn’t like to work for a liar.

7. Exploit your strengths.
Remember you’re small and you’re proud of that. If you don’t believe in that repeat it to yourself until you believe. Small companies are cool. You can always find a solution for any issue as far as you want it. You don’t have strict corporate rules. For some people it is a great plus. And for you having people who like your organization is even bigger plus. You won’t be big, but nothing should stop you to be cool and fair. You’ll find people who appreciate that.

Having said that, if you like to work in a small and cool company, remember we’re recruiting like crazy now. Feel free to ruin my day being one of those people who steal another couple of hours from my schedule and kill my brain during days like today. Hopefully your approach and knowledge will stun me and the day will be rescued. I will be more than happy. You can be sure.

Lately I had a chance to observe a discussion about using agile methods. The problem which started the discussion was how to apply agile when we work in a fixed budged scenario. It wasn’t much later when I heard arguments like:

You can’t estimate effort needed to complete something which is done during nth iteration. It’s a fiction. Does client want a fiction? I don’t think so. You can explain it.

Then another great idea followed:

When the client changes requirements after they were approved we change the price. You shouldn’t be tricked. If you are it’s better to find other clients.

Nice. So simple. Your methodology tells you to work exactly that way so you do it. And when your client doesn’t accept that, sorry, you just leave. They aren’t worth to waste your time.

Oh, on the side note I think it’s time to declare which side I’m with. Neither against nor for agile. I just try to find the most reasonable way out in every situation.

Coming back to the discussion. Yes, the clients quite often want “the fiction.” They want to spend specified amount of money for specified amount of features. A surprise? It shouldn’t be. At least as far as you deal with people who doesn’t spend their own money.

And if your answer to scope creep is to leave the customer I wouldn’t invest my money in your company. Yes it can work that way and it can even bring money, but telling the customer they’re wrong isn’t the best strategy I’ve ever seen. Neither is rejecting to adjust your approach to the environment you work in.

Don’t be an orthodox. When something doesn’t suit your vision of software development and project management it doesn’t automatically mean it’s wrong. If you believe in your methodology go, convince the customer to use it. But don’t cry when they say they want it other way. They pay, they decide.

We are usually closed in our small niches. We usually don’t see all sorts of choices around. And we believe we know better. Until we see we don’t. For me the eye opener was moving to another company with different team, different processes, different products, different clients, different everything. And now I can’t say that one or another approach is better. They’re just different.

How to measure if the team is great?

Two perspectives.

Team member: When emergency comes will you join and add some more from yourself? Will you meet your colleagues there? The more people on board during tough times the better is the team.

Manager: How many people left lately? How many of them were key players of the team? The lower rotation ratio the better is the team.

Best teams I’ve seen were on the better end of scale in both points. I’m lucky enough to be currently a part of one of them.

And when we talk about my team in Wind Mobile, we have some positions for great people willing to join small, flexible company where people are important. If you have an open mind, like to learn and will to develop yourself as developer, support engineer or project manager in Krakow check our website or contact me directly at pawel.brodzinski@windmobile.pl. We have internship program too. Let me know you found the information here.

Everyday work of project manager is, well, interesting. You talk with clients. You manage your team and organize their work. You work on schedules. You prepare reports. You deal with different issues. You supervise everything. You prepare a thousand of different things. You create hundreds of documents. Phone calls, emails, instant messengers and meetings. Quite diverse job. And quite complex.

It requires specific type of people, that’s for sure. But you can do more. You can simplify a bit project manager’s work. How? Actually that’s the question for you.

Range of tasks done by PMs differs. There are companies where PM is one man army and is responsible for almost everything, sometimes even getting a deal. Unfortunately the more tasks are assigned to a project manager the less time he has to spend on the most important thing – managing a project.

If you can safely take off his head anything with no significant impact on business do it. Maybe budgeting can be done by someone else? Possibly presales team can take a bit more of work with preparing offers. Definitely someone should isolate PM from office wars and let him do his job. Nice idea is not to force project manager to think if he has enough office space for the team.

Sometimes when I talk with fellow PMs I’m surprised how many strange things they have to do. Typically these are things which PM will rather easily deal with although I can hardly say it’s typical PM job. Unfortunately it takes the time. First it takes time to do those things and second it takes time to switch threads. OK, PM will often switch threads anyway and unlike developer it’s rather normal situation but still, the less switching the better.

The recipe for each organization can be different. If no one else can prepare a budget for a project or there’s no sales force to work on new deals you can’t just cut out those tasks. But I guess there are things you could easily switch to more appropriate people. Just think about it.

You plan to introduce a new version of your widely spread application and one of key features will be new user interface. Or maybe you enter the market with new product which shall compete with market leaders and now you design GUI for your app.

And you have lots of ideas how to organize user interface better than it was done before. That’s for sure.

Unfortunately it does mean you set up a goal which is hard to achieve. I can even assume all your improvements ideas are great, which is rarely true. But let’s not complicate the situation. They are great.

You launch your new version/product/whatever and complaints start. We want to have spreadsheet working Excel-like. We want to work on Gantt charts in a way we work with MS Project. We want to have search looking like Google. We want to have invoicing window the same as it is in SAP. We want to have it the way it used to be. Keep your great ideas for others, we want our old damn interface back.

Because we like what we know. And we don’t want to learn new ways of doing things we do. We just don’t.

If you want to try to change the world of users habits you have two ways. You either believe your idea is strong enough to prevail or you stick to standards (no matter how low they are) and work hard to teach users new ways of doing things. The most obvious example of former is Google with clean search engine design. The examples of the latter can be Project-ON-Demand or Google Spreadsheet.

The first option has much higher failure rate. For each example of success you can find a bunch of examples of failure. From time to time I check different applications from area of project management and every time I see GUI totally different from what MS Project offers I see incoming failure. People won’t know it so they won’t like it. I don’t say MS Project is cool. It isn’t. I don’t like MS Project. Actually I hate it. But I used to it and most people around did too. Everyone knows how it works. Everyone expects other software doing the same things will work similarly.

Sure, you always can try to educate me with different approach but remember I’ll be reluctant. I’m like a typical user. Users like what they know. And they are lazy too. Remember about that next time when you start redoing all your user interface or reinventing the way people do things.

I was held at work today a bit longer today as we had a nice discussion about how our email inboxes are organized. Of course there are different strategies applicable in different roles but we had one common conclusion.

Clean your inbox.

Usually a number one reason for forgotten tasks is cluttered inbox. It doesn’t matter which techniques you use, just make it clean according to your standards. It will help.

By the way if we had our inboxes cleaned and there was no issue to talk about I would make my way out and wouldn’t be grabbed to an ad-hoc meeting. And that’s another argument supporting above thesis.

I had quite an insightful discussion lately about promotions. When people hit the ceiling. Why it is so. What to do in that kind of situation.

Of course, as always, I won’t give you a sure-shot answer but from my observations a number of promotion issues have sources on both sides of the barricade.

Managers suck with promoting people.

Above generalization is built from small pieces including:
• Poor knowledge about people working in the team.
• Inability to take the risk.
• Virtually no information about how people are willing to build their career paths.
• Poor judgment.
• Lack of will to train or coach promoted people.
I don’t say every manager can be blamed for every of above points but probably almost every manager can be blamed for at least one or a couple of them. I’m no saint here if you ask me.

With all those problems managers often tend to choose outsiders instead of insiders as all those issues supports fear of failure. Then the most important thing kicks in. When you promote good specialist from your team to another position you actually lose specialist with no guarantee you gain suitable person on the new position. The fear skyrockets. The question pops: is promoting an insider really a good decision?

Most likely it is. Not allowing people to develop themselves you risk of losing them at all. You end up with no specialist on either position. And from my experience outsiders are much more risky than insiders. It’s much harder to judge a person after one or a couple of one-hour meetings than after a couple of years working in the team.

The fear is the most important issue on manager’s side. But it should be overcome.

People suck with promoting themselves.

How many times you hear a friend or colleague who is complaining how hard is to get promotion and you want to ask if her manager actually knows she want to be promoted? How many times you see people who don’t try to do anything with their career just waiting for bosses to do something about that? I can add a number of people who haven’t even tried to talk about what they like and what they don’t like about the job with their bosses. They just left rejecting a chance to change anything within their workplace. Even when the chance was just waiting for a smallest piece of initiative from them.

Sure, managers aren’t cool with promotions but most of them are in fear of losing good people. And sometimes they’re just lost with looking for a good candidate in the team and giving them some hints what you’d like to do can be really helpful for both sides.

Remember managers don’t know everything about their people’s professional goals. They should but they don’t. As far as you leave all in their hands you put your career in risk.

Don’t fear talking with bosses. You can’t lose much as far as your superior isn’t a kind of psycho. Help them. Put a pressure on them. Hey, that’s what they’re paid for. Managing their teams.

Among the best promotions I remember there’s a significant place for those which were made in difficult situations when both manager and employee overcame their fears, started talking with each other and found a way out. Profitable for both sides. And it all began with honest discussion about future with a boss.

You go to a meeting with a client. You expect discussion won’t be easy so you work hard to prepare yourself. You know your team screwed something in the past but you want to look to the future. Anyways you expect talking about merits.

You get a bucket of crap dropped on your head on the very beginning. Then your failures are pointed and criticized. And then you hear people on the other side have no empathy to share your pains.

Sounds familiar? For many of you it should.

After those meetings I always feel like I was slapped into my face. I feel like someone has drained my whole energy. My motivation peaks down.

That’s utterly and completely wrong. You shouldn’t take it personally. Me either. You should care as far as it pushes you to improve things and that’s all. You shouldn’t allow those situations to influence your work negatively.

Why? Because it is business. They have to play “you screwed” card to show you they’re unhappy. Nine vendors out of ten would ignore them if they just said they were unhappy so they hit high tones since the beginning.

You’ll go to the very same people a couple of months later and they’ll be all happy with your efforts and performance improvements. They’ll remember neither a bucket of crap nor lack of empathy. The future will look bright.

Why? Because it is business.

You shouldn’t take it personally. Or at least you should try to act like that. I can’t guarantee you a success, as I’m rather a failed example here. Even though I know how it works.

Some time ago I wrote about post mortem basics. As anything else in project management post mortem is not a silver bullet. There are a number of issues you’ll face when you do it. These are my top 4 listen in no particular order.

1. Get people involved. If you want to make a good post mortem you have to get people involved. On general people don’t want to be do that as that’s another additional task for them. No one likes additional tasks. And usually it has nothing to do with value of feedback they can provide. Sometimes I get worthy opinion from people who I have to force to receive anything from. Of course typical quality of post mortem answers will be better when someone do it because she wants, than when you force her to participate. But anyways the more opinions the better.

2. Compromise. You’ll get some points which are submitted to different categories by different people. You have to find a compromise there. Usually you need to understand reasons which stand behind an opinion. You can talk more with people who provide their feedback. And sometimes you’ll just know why someone thinks a quality engineer on client side sucked and someone else believes he was one of greatest thing which happened during projects. Maybe these are different ways to tell that client tests were very good but unfortunately solution’s quality sucked and that’s why customer tests were ordeal.

3. Discussion. You can prepare good starting point. You can encourage people to share their thoughts. And still discussion can fall flat on the face. And while answers can be forced somehow, you can’t force hot discussion to happen. Thing you can do is to focus on preparing better summary when you don’t expect a lot of ideas flying over the room while summarizing outcomes.

4. Improve the future. If you don’t plan to use post mortems to improve future projects don’t even bother. Don’t waste your time. Let the team do the work which brings you something valuable. Doing post mortems just for the sake of doing post mortems is just dumb.

1. You should be a great organizer.

2. You should communicate more often.

3. You should be honest with clients.

4. You should look for solution instead of ones to blame.

5. You should like to work with customers.

6. You should understand business story laying behind the project.

7. You should understand technical issues which appears during implementation.

8. You shouldn’t hesitate whether to escalate or deliver negative feedback whenever needed.

9. You shouldn’t cry over unfair opinions about your work and your projects.

10. You should always expect unexpected.

You’re a manager and someone calls you to tell about some emergency situation. The first thought is “I’ll do that.” I’ll replace sick guy who was in the middle of resolving the issue along with a subcontractor. I’ll run the meeting where all the technical issues are resolved.

Stop for a moment. Take a step back. Are you a person who’s competent enough?

Do you know all the history of communication with the subcontractor? Can you make good decisions how to deal with all technical stuff? When you’re a manager quite often answers will be negative.

Then the best thing you can do is to find someone who is competent. Playing a hero doesn’t pay. Sorry. Admitting you aren’t competent enough to deal with the specific issue doesn’t make you a poor performer. It makes you a wise performer.

What is it?

To make long story short post mortem is a little discussion after a project or important part of project. The team discusses what was done well and what was screwed. Before discussion one person gets feedback from all team members to bring a food for thought. Outcomes are used in future projects.

What’s in it for me?

Why to do post mortems? You usually feel what went wrong and what went well. But do all team members feel the same? Does a developer care if communication with a client went perfectly? Does a project manager understand all architecture flaws developers had to face? Does quality assurance team was aware about complex hardware installation part?

Post mortems bring two main outcomes.

1. Knowledge sharing. Everyone adds their two cents. All perspectives are included. Even the least important team member can bring a refreshing insight about project.

2. Written summary. The process of preparing post mortems forces a person to prepare a piece of document before discussion. You just raise your chances to have a written summary after all which won’t fade in a week.

How to do it?

The scenario is simple:

1. A person who knows a project well, ask all team members to answer three questions:
• What went well and should be repeated in future projects?
• What was on a good path and should be improved in future projects?
• What went wrong and should be avoided in future projects?

2. Then the person needs a lot of squeezing to get answers from most people from a project team, as many people won’t just answer a polite request.

3. All answers are assembled into one summary. That’s part can be tricky as it sometimes happen the same thing will be put in different categories by different people.

4. The whole thing is discussed and adjusted during team meeting, when everyone can add anything what comes to her mind.

5. Post mortem can be, and should be, used to improve future projects.

The questions can be adjusted if you feel like it, although I find the more general they are the more interesting things people will bring in answers. You don’t force people to change their perspectives, you just let them exploit their area of competence.

When to do it?

Definitely when a project is finished. But when you run a project which lasts three quarters you won’t remember all the issues you had to resolve during first phases after all. Then it’s quite a good idea to run post mortems after each important milestone.

When you shouldn’t bother?

If you don’t plan to use post mortem outcomes to improve future projects, don’t waste your time. Looking back is worthwhile only when it is a tool to improve future.

Whether you’re a project manager or a developer or a support engineer or you call it who you probably are asked quite often to estimate some work effort. You do your estimates, sometimes better sometimes worse and go with a number or better a couple of them. A person who was asking takes the number, if you gave two of them the higher one will be forgotten, and fades in shades of the office.

You forget the whole thing as it has never happened.

And then, after weeks of being processed by business processes, your estimate comes back to kick your ass.

“You said two weeks. I want to see that delivered in exactly 14 days from now. Bye.”

Hey, has anybody thought about other tasks I have to do? Or maybe I’m considered as a person who does virtually nothing, just waiting for a task to be assigned? That way I guess I should have been fired, shouldn’t I?

These are wrong answers. Don’t try that at work. But you can do what common sense tells you to do. Ask about priorities.

“Of course, that can be done in fortnight but other tasks will be dropped. If that one has the highest priority I’ll stop doing anything else and complete the new task as soon as possible.”

Ask for prioritizing the task. You’ll give yourself a chance to avoid being blamed for a slip. You’ll give better-informed people a chance to make a wise choice. You’ll make folks aware that resources aren’t made of gum and can’t be stretched as much as most of people think.

It works whether you manage just your own work time or you have a big team working concurrently on several projects.

Next time when you forget about something, you screw something up or something just go completely wrong don’t do things you usually do. Don’t make excuses. Don’t look for others to blame. Don’t make like there’s no problem. Just don’t.

Do one thing. Admit you failed. Admit you sucked at that and you know it’s your fault.

You’ll be surprised how different will be a reaction. More positive. More constructive. Just better.

You can’t be an expert in every area. The wider your area of competence is the more superficial is your knowledge. That’s by the way one of biggest issues higher management has to face when they get their promotions – they become generalists, they want it or not. However it really doesn’t matter if you’re an expert in one area or jest knowledgeable enough in many of them. You will face situations when you will play a role which doesn’t suit you very well.

Let it be some office politics played between vendor and client for a developer who’s accidentally in the room. Let it be contract negotiations with customer for a support services manager. Let it be cold calling for a technical guy who supports sales forces. Let it be deciding about code-level issues for a project manager. Let it be whatever.

Sometimes you can’t avoid being involved. Sometimes you can’t even avoid making decisions. Although you can limit negative impact those decisions have on you, your project and your team. The trick is simple. You just have to be aware when you suck. If you know you weaknesses and you consciously avoid entering the ground where you lack experience you won’t harm your side much.

If I suck at negotiations (and I really do) I don’t negotiate. I work hard to avoid situations when I’m a single person responsible for negotiating anything. And when I’m in the bigger team I just try to limit my participation to merits I came for. When someone in my team chooses other line of negotiations than I would, I take a step back. He knows better 9 times out of 10 as I suck at negotiations. Although not always I’m successful at that it doesn’t mean I shouldn’t try. The whole thing is being aware of my weakness.

And what is your weak side? Are you aware of it?

One of measures of good management is a number of situations when people, not a manager, decide how to do things. When the manager allows people to make their decisions. Let them become accountable.

I’d like to see technical design document, but you decide what should be in, what out and how the whole thing will look like. Hey, you guys will be working on that later, not me.

We need formalized risk management in the project, but it’s you who decide how to run whole thing. You know a project team better. You know what will and what will not work.

We have some emergency in server room in another city and it has to be dealt with. Find a way to fix the problem and to minimize impact on other tasks. I don’t have all the data to make the best choice.

The more you hear those kinds the better manager you work with.