Who’s your boss?

Your boss is anyone who assigns you work. That includes the person the org chart says is supposed to assign you work.

But, as pointed out last week, it also includes anyone you let shift work from their inbox to yours. That can double your workload while cutting theirs in half, which is why I suggested specific techniques for keeping their work assignments where they belong.

However (you knew the “however fairy” was hovering between you and the screen, didn’t you?) … however, I say, take this too far and you can damage or entirely destroy the sense of teamwork that’s essential to effectively getting things done.

After all, teammates are supposed to support each other, helping out their colleagues when their colleagues get stuck.

How to tell the difference between when you should help and when you should say no?

If you’re on the asking end: It’s time for a hard look in the mirror. Ask yourself if the help you’re asking for is to share skills and knowledge, or you’re asking for someone to do your work for you.

While you’re looking in the mirror, ask yourself if asking for help is a one-time exception, or has it become a habit.

If it’s become a habit it’s time to break it.

Unless, that is, you aspire to management and have enough of a Machiavellian streak that you don’t mind taking advantage of your teammates. If so (and understand, I’m not encouraging this), asking for and getting help is a way to make it look like your colleague is “just” a technician, as you position yourself as the one who knows how to think and act like a manager.

Oh, and if you decide that’s a good career move, make sure your confidence in your manager’s gullibility is warranted.

If you’re on the receiving end: To some extent this is the asking-for-help side of the equation only backward. That is, sharing your knowledge and skills is providing help and support, while sharing your time and effort to do a colleague’s work is letting someone advantage of you.

But there’s another piece to the puzzle as well: A trap that’s easy to fall into is enjoying the ego gratification that comes from showing off what you can do to someone else who doesn’t know how.

There’s nothing wrong with this, assuming, that (1) you have the time, (2) you don’t mind your colleague getting the credit for your skills, knowledge, and work, and (3) you’re happy to be branded as a technician, with all the career consequences it implies.

Bob’s last word: It’s a variation on an old and trite, but still true saying: Give someone a fish and they’ll eat for a day. Then they’ll ask you for another fish tomorrow, and the day after that, too.

Bob’s sales pitch: Just in case you weren’t sure about this, yes, I’d be delighted to keynote your event. You read KJR on a regular basis, so by now you have a good idea of the subjects I’d be delighted to keynote about. Here’s where to get in touch: Contact – IS Survivor Publishing .

Now showing on CIO.com’s CIO Survival Guide: “XaaS isn’t everything – and it isn’t serviceable.” It’s about how “everything as a service” doesn’t include everything, and in fact it doesn’t include lots of important things. And no, I don’t know when “X” came to mean “everything” either.