Who Is On the Other Side?

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?

A Couple of Tips for (Not Only) Managers

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.

Flexible Working Hours: Worthwhile or Not?

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.

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.