The Retrospector

One of my recent articles on Top 10 Ways to Motivate Geeks has gotten some good attention lately and driven quite a bit of traffic to the site. I’ve had some interesting “opposites” approaches show up in comments regarding the things that do NOT motivate geeks. I’ve also stumbled onto some other pages that hit the some of the same points I have. Some good thought and effort went into these, and I think some of the points made are things I had in mind when coming up with my own geek motivation list.

The links:

• Top 10 Ways to Demotivate Geeks
• How to make IT Staff Less Angry (series)
• What Makes People Unhappy at Work
• Why Your Employees Are Losing Motivation

I’m not one to normally post things without something unique to add, but I felt inclined to share a little “link-love” with others that have hit the topic of motivation in a similar manner. I think this also establishes that I’m at least on a somewhat correct track with my own list seeing that many others out there not only agree with me, but have also been posting their own perspectives which aren’t far from my own.
Feel free to add any attitional twists to the geek-motivation topic. I’ll keep my eye out for some more interesting and unique takes on the matter.

I’ve decided to write a little about integrity, and I just didn’t feel like it was something I wanted to do entirely in one single post. As I was wrapping up one topic, I would too quickly stumble into another that was lengthy enough to be it’s on post. So I’ve split my draft into a few pieces that I’ll reveal over the next couple weeks.

Integrity is something I think is very underdeveloped in many corporate cultures. I’ve seen some pretty shady stuff happening behind the scenes and am much more comfortable in the environments where pretty much everyone is an open book without much to hide. What I’ll start out with in this series is the topic of taking undeserved credit.

Avoid taking undeserved credit

Something I learned a long time ago from my uncle, who was an executive for fortune 500 companies for years, was that “making it” in a corporate environment sometimes meant dealing with people who learned the art of taking credit and deferring blame. I was fascinated by this while thinking that it just couldn’t be that easy…until I worked for one of the largest companies in the world for a few years.

I just couldn’t believe how easy it was for some people to take credit and defer blame without the slightest hesitation. I soon realized that participants in this method may get ahead in the near term with praises from above, but in the long run their credibility is shot by many peers around them making it more difficult for them to do the same in the future.

What I’d like to point out in this series are some things to watch out for. The what-not-to-do things that will get you labeled as a credit stealer. In simple terms, the dishonest prick with potentially no spine. (Though I can’t say everyone can be honestly labelled this way as they just don’t realize what they’re doing. Thus the article to help you avoid such labeling.)

The “we” factor

One of the easiest ways to get some credit for not really doing anything is using the term “we” often when describing a project that was completed or some task that was done by others in the group. I’d say this is probably the most over-used method of getting credit for being involed with something, even when being involved just means you’re up to date with what’s happening in the project.

The kick in the tail here is, not everyone does this to intentionally gain more credit than they’re due…but it happens to work out that way sometimes. Saying things like “well, we’re working on that and hope to have it done by tomorrow” even though you really only are a stakeholder that signed some dotted line because you were invited to participate in discussions about some project can really make it look like you’re down in the trenches to some clueless executive.

Some managers are able to decipher all the “we” factor out of conversations by being involved enough to know who’s doing all the work, but some aren’t. If at all possible, encourage your team to take responsibility by being more specific about who’s doing what. The accountability in some components is amazingly avoided by using “we” instead of individual names. If you’re barely involved, give full credit where it’s due by mentioning the names of the “grunts” that are pulling all the weight on the project. Certainly let others know you’re involved by keeping tabs on the project, but don’t allow people to create a picture in their minds of you doing a large portion of the work.

Of course some would say that you want to look like you’re more involved than you really are, but the point of this article is to let you know that such practices are noticed by your peers. You really need to make sure you’re spreading the “credit wealth” as much as possible, and people will be more than likely to work with/for you again. A point in one of my posts for motivating geeks mentions giving full credit when it’s deserved. Avoiding the “we” factor is a good way to do just that.

Not mentioning the people doing the work at all

When talking about a project or tasklist, just not talking about who’s actually doing the work implies that you have a much bigger role than you really do. Make sure to mention those doing the work so they have the proper credit for doing it. This kind of overlaps with the previous point so I’ll keep this brief.

My father once taught me the meaning of “lying by omission” in a probably well-deserved lecturing when I was caught misbehaving and didn’t fess up. This is probably a weak analogy, but it’s what came to mind, so bear with me. By not telling my dad exactly what happened, I was indirectly lying to him about being involved with some of my buddies in the mischievous event. I like to compare this to discussing progress on a project with upper management without ever mentioning the people that are working on it. When doing so, I think it’s somewhat like “taking credit by omission” because you’re not really giving the full picture of what’s going on.

Flat out lying

Ok, this is just stupid. Anyone that flat out says “that piece I completed” for a component that was done by someone entirely different deserves whatever evil look they get from management when they’re called out on the lie. This is an extremely risky move on anyone’s part. I do not recommend lying as a tool to get credit for any work done to anyone. For those that don’t listen, I laugh at your stupidity and gladly stand in line for your paycheck next time I’m on the job hunt.

Conclusion

Taking undeserved credit is just something we all have to pay attention to. Not everyone is doing this on purpose, but I’m sure there’s many out there that are doing it without even realizing it. The classic example is the project manager that presents the product and acts as a liason to the rest of the business for the team. The PM has every opportunity to look like a major contributor without ever revealing the opposite truth. I’ve seen few intentionally do this and look good to everyone around while doing it. Actually, I’ve not really seen anyone pull this off. So be warned!

How about you? What qualities about your peers and managers do you notice where they get undeserved credit? What other methods have you seen where people get praises for work that they didn’t even do? Was it intentional or not? Share with us your frustrating or humorous views on the matter.

Other posts in this series:

• Don’t Defer Blame
• Avoid Exaggerating
• How to say you don’t know

Tags: integrity, credibility

One of the crucial points in a project is near the end where you have to decide to simply wrap things up enough to deliver. The ability to enhance the product forevermore can creep into your scope so easily if you let it. (Scope Creep) Sometimes it gets to the point where you’ll be on an endless timeline of development where you can’t just finish it and get the product shipped.

What I’d like to talk about in this article are some of the things to watch for to make sure you can get your product delivered to your customer. Such things include avoiding scope creep, properly comparing requirements with personal opinions, and follow-through on making sure your product gets to a deliverable state.

Scope Creep

This is a subject that probably has enough issues that it could be an entire series of posts. What I think you should take away from this for today’s article is simply that allowing the scope to broaden or change too much will prevent you from every being able to clamp down on the “moving target” deliverable. You will spend so much more time trying to factor in new features or implementation approaches for a dynamic scope than ever wrapping up the ones you currently have on the table that you will never get the original requirements in a deliverable state.

(more…)

The last few weeks I’ve come across a number of things that required some sort of estimations, so that everyone involved could get a set of expectations in their minds on what would result with each endeaver. (I’ve also noticed quite a few articles about estimation lately.) Tasks range from honey-do projects around the house, to components on an application in the office, to personal estimates on some little things I’d like to just get done.

Estimation is very simple in most cases, but it can get very complex for some things. I’m going to break down some of the issues that effect one’s ability to accurately estimate projects here and hopefully share some insight on how to find your most likely results when forced to think about quantifying your abilities.

Experience

If I had to sum up the art of project estimation in one word, that word would be experience. There’s simply no replacement for what experience can do for you when you have to think about tackling a problem.

If you were given a task of figuring out how to start a campfire, you would have learned the first time around some of the things that don’t work by trial and error. You may have spent an hour trying to get it started the first time, but this time you know you should give plenty of airways to the bottom of the fire to let it breathe while you put the tinder in the flame to get it going. There’s really no way to know that without having experienced it for yourself the first time around.

Case study

Let’s apply this to a scenario at work. Let’s say your boss comes to you and asks how long it’s going to take to get the florescent green with dancing monitors background CSS generator doo-hickey working. Now you know you really need to get this really cool background generator done this week, and if you could get it done today you could impress people. Not only that, but you quickly realize that it’s just some string parsing that you could do blind-folded because it’s just some little class with a few methods for generating color and monitor outlines.

(more…)