Avoiding Frustration

The other day I had a chat with one of my friends. He told me one thing.

There’s nothing more demotivating than being helpless. You only frustrate yourself.

We were talking about taking responsibility for a part of the company as a chance to deal with issues which annoyed us. We considered that as a chance to do something about that instead of ranting about the situation. But there is another perspective.

It doesn’t matter if you’re manager or tester – there will be thing which you don’t like and you don’t want to accept them in the long run. It can be atmosphere of the workplace, it can be lack of order in project management, it can be constant context switching, it can be beef-head boss, it can be anything.

Now, you either see you’re able to change the annoying issue or you end up as frustrated employee and eventually leave. Yes, usually managers have more tools to change the environment they work in, but the rule is general. If a developer can’t go through with his great ideas how to improve development his frustration will rise. If a project manager is struggling to move her projects a bit from the complete chaos with no effects she won’t be happy with her job.

If you’re a manager you have to give your people chances to change their workplace. The place they work in and the way they work. It doesn’t automatically mean you have to agree with each idea, but if you listen you’ll hear a lot of reasonable ones. Except of improving performance of your team you’ll also limit their frustrations.

Fighting with Lack of Time

My last posts are mostly about dealing with workload. The reason is simple – last weeks at work are pretty hectic. Sleeping for 4 hours isn’t something very unusual these days.

Today I have another self-management tip. Leave less important things aside. If you lack time you should spend it neither on task switching nor on unimportant errands. That’s pretty obvious. Unfortunately we tend to forget about that.

And there’s another trap. We usually set unimportance level way too far. As a result we don’t have enough time to deal even with “important” tasks. The direction should be opposite. Start with the critical things and until they’re finished don’t touch anything else.

The rest should be delegated or forgotten.

Unfortunately for me it does mean significantly lower posting frequency on the blog, which I believe you’ve noticed. I hope to be back on track in a couple of weeks.

How to Support Your Backlog

Last time I got an advice for those who want to fight with their backlog. Today I’d like to share some ideas with those who like their backlogs and want them to prosper in great condition.

1. I’ll do it on evening. Yeah, sure. As you wouldn’t have a million better things to do on evening. As you wouldn’t be tired. As you wouldn’t think about a beer and a good book instead of another boring Excel sheet. Yes, that’s a good idea. Go for it.

2. I’ll die here but I’ll do it. What a consequence! Even if you are tired and ineffective consequence will allow you to... well, at least it’ll allow you to go to bed late. Or maybe, just maybe you’ll just die before you do it. And definitely all those stories you’ve heard from developers who found the bug fix while they were resting or even dreaming are just fiction.

3. Complain. I have wild loads of work. I’m so poor. I just cannot complete that on time. I try, but it surpasses me. At least you moved some pressure from your back. It was so big you just couldn’t work. And now, when everyone has heard you complaining you feel much better. Even if it took 2 hours.

4. Give me more, I’m the hero. You’re cool. And you help everyone. Hey, that’s what heroes do. You’re full anyway so another tiny task won’t do a difference, right? And you build your reputation.

5. Don’t delegate. You want something done well? Do it yourself. Delegating is overrated. You never know when someone screws something up. It’s better if you won’t allow others to do anything with your tasks.

Feel free to mix all of those. The more of them you use the better you support your backlog.

How to Deal with Backlog

You probably experienced that. Loads of work, limited time and no light at the end of the tunnel. For each thing you do there’s another one or even a couple of them which arrive to your inbox. The Mighty Backlog has taken you under control. Nowhere to run, nowhere to hide.

There are several techniques you can employ to do something with the problem.

1. Do it now day. A last-in-first-out model. You manage each new thing as fast as possible digging deeper to your todo list. Theoretically it shouldn’t work, but practically that’s great solution. You set up your mind to kill each incoming email and magic happens. You go through tasks faster than you’d think. There can be a problem with that approach if a big piece of work arrives but no excuses here. Last in, first out.

2. Begin with smallest ones. Start cleaning with managing the smallest tasks. The list will shrink soon and with less clutter it’ll be much easier to manage the rest. And you won’t need to answer all people who asked you for those little favors when you’ll be able to do it.

3. Follow the flow. That’s hardly controllable, but there are days when you’re on fire. You work more effectively than every day. Try to exploit those days to do the most important things or shorten your backlog.

4. Plan. Make a detailed plan for a several hours which things you’ll work on. One after another. Follow the plan. Make a remorse-list and put in on sight. Cross out each completed task.

5. Turn off disturbers. Messengers, websites, sometimes even email clients. Turn off everything which distracts you and isn’t crucial. Don’t go for a coffee. Don’t engage each discussion you hear.

You can try to mix a couple of those techniques but do it wisely. If you go for a do it now day, don’t try to fix the easiest thing first.

The one general advice is: don’t wait. Try to defeat your backlog as soon as possible. Other way that darn thing will grow and the task will be harder.

A Couple of Tips for (Not Only) Managers

Ray White gives a tip for managers:

“Love what you do. And show 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.

We Know Better

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.

Consistency Is the King

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.

Calm Down

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.

Clean Your Inbox

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.

Promotions from Both Sides of the Barricade

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.

Don’t Take It Personally

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.

10 Qualities of Good Project Manager

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.

Not Competent Enough

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.

Admit You Failed

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.

Know When You Suck

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?

Do It Now Day

You work in constant time-trouble. You barely have time to manage urgent things, as you totally focus on super-urgent ones. Your backlog grows day by day. As far as you do something around project management – you should be familiar with those situations.

Sure if we’d worked that way everyday we’d have been fired long time ago. That’s rather emergency than typical situation, although the emergency sometimes lasts for even a couple of weeks (months in extreme situations). After that period we’re left with no energy and huge number of overdue issues to resolve.

When you’re at that point typical reaction is to reject any new things and start to dig through the most important old stuff. You scan through your inbox looking for things your ass should be already kicked for. You try to recall those mega-important tasks your boss told you in a kitchen. Big effort is used to prioritize things.

In those situations I try to make a Do It Now Day. Any request/issue/you call it which comes is resolved instantly. You want that old document to be prepared? You got it. Schedule should be updated? I’m working on it. Now. I promised to check agreements with our contractors? Here it goes. No one wants anything more from me? Let’s go to the inbox. No priorities. Just one thing after another using any reasonable order. Can be from the newest to the oldest to give the first example. Overdue information to be send to a client. Done. A meeting to be organized. In your calendars. Updates in spreadsheet? Check the newest version.

I find a Do It Now Day works great whenever I have no tasks to complete which are highest possible priority. In other case the priority task will always come to you to kick you ass and the whole subtle plan fails. But if it works it really lets my productivity skyrocket. I just don’t waste any minute to unproductive context switching. I just cross out tasks from my virtual todo list. One after another.

Today, which was a Do It Now Day, I cleared my inbox from all urgent stuff for the first time in a month and I still had a time to lose a couple of darts games to fellow PM.

Try the Do It Now Day sometime and tell me how it went.

Why Reports Suck

You’re a project manager or you manage a team or you work in sales department or you’re a lead test engineer. For your bosses you have to prepare some reports. Sometimes they suck. Reports, not bosses. You get a bunch of remarks pointing inconsistent data, out-of-date information, wrong numbers or omissions.

On the other hand sometimes your reports are just fine. They’re fine even though you’ve spent much less time preparing them. Why is it so? Why reports sometimes suck?

When you prepare a report for yourself it’ll be good. You don’t need inaccurate data or out-of-date information. You most likely work on the report on-line. Whenever input data has changed report is adjusted.

When you prepare a report for others only, chances are good it’ll suck. You have to make up all the numbers because you don’t have them at hand. You have to reconstruct all changes which have happened since last time you prepared the report. And there are more interesting tasks to do than digging through all that crap anyway.

As far as your report bases on information you work with everyday for yourself it should be good. When you don’t work on the data regularly watch out – your reports may suck.

Selflessly

Tomorrow do one thing selflessly. Something easy.

Praise someone. Say “thank you.” Help someone with boring task. Do something by yourself instead of delegating work. Whatever.

It will come back to you. It will pay off. It is definitely worth the effort.

Sharpen the Saw

We usually work under pressure of time. We’re late with deliveries, customers squeeze us with deadlines etc. In the run to complete task as soon as possible we often forget out tools have become worn and it’s time to sharpen the saw. And it doesn’t really matter if your tool is a saw or a brain.

Take several minutes to actually design the important fix before coding it.

Think how to verify if all scenarios have been covered with the new function.

Spend a quarter thinking where communication between PMs can be improved.

Or better. Make use of some free time to leave the work behind. Because there’s one way to sharpen your brain – let it have some rest.

And let it be my wishes for you on Christmas – have some rest and distance to all professional issues.

Long Life Old Programming Languages

SDTimes brings a nice story about not teaching programming languages like LISP anymore. That reminded me about renaissance of programmers knowing ancient languages like COBOL when y2k bug was coming and there were still a lot of working software written in those languages. Suddenly it appeared it’s hard to find a COBOL programmer and being the one can be quite worthy.

It still looks like a good idea for me to know some old-school technologies and become a specialist in that area of knowledge. I consider C/C++ as dying language. Yes, students are still taught C++ and yes, it’s still easy to find software written in C++, but developers generally prefer more modern languages (Java, C#) or those trendy ones (Ruby on Rails, Python). Finding a developer who wants to write in C++ is harder and harder over time, yet market demands significant number of them.

The easy reasoning here is: still much code written in the technology, few people willing to use it, should be worth to be a specialist in the area. I think it’s easier to become highly-paid specialist when you choose less popular technologies than it is with the mainstream ones. Anyway, developers somehow follow the trends and rather rarely take into consideration above point of view.