The Retrospector

Being a geek myself, I think this is a subject I think needs to penetrate all levels of management in every company that values their geeks. By no means is this a rant, but for the last 10 years I’ve seen what motivates us and what doesn’t. I’ve seen the managers that just don’t get it. I’ve seen those that understand completely and react accordingly. So, I thought I’d share my observations and see what everyone has to add as well.

1. Geeks are curious. Let them feed their desire to learn things

I don’t know how much emphasis I can place on this point. You can take the ultimate geek…give them a rockin’ compensation package…and give them “rubber-stamped” projects (same tasks over and over) for two years and they’ll probably quit anyway. This point is based on the notion that if a geek feels his ability to gain knowledge is hindered he’ll try to find it somewhere else. Let them satisfy their curiosities with the task of picking up the latest technologies and applying them as they see fit. (Even if it’s just for a prototype.)

2. Geeks like to be self-sustaining. Let them figure things out on their own.

I haven’t met a true geek yet that wants you to hold their hand through every step of an implementation. In fact I’ve seen quite the opposite. They want to do things their way. If you suggest something, odds are the solution is wrong in their mind because it’s not what they would have come up with first. There’s many ways to complete a task in the technical arena, why cram your solution down their throats? Don’t hinder their creativity, just let them figure it out. The exception to this is probably in design. You obviously have to define your interfaces between components and have your requirements for the implementation. Let the details get figured out by whoever’s doing the dirty work. You can optimize things later if they aren’t up to par.

(more…)

For the last couple years I’ve been getting a bunch of magazines delivered to my work address. The IT Publications banner to the right is a link to where I ordered them all. Having a stack of publications related to your line of work, even if it’s just somewhat related can benefit you in a number of ways, and I’m going to share with you the few things I think benefit me.

If you want to give one or two of them a try, know that I’ve gotten zero spam whatsoever from ordering them other than renewal notices each year. This year I think I’ve signed up for about 7-8 of them, and though I don’t read them all every time they show up I manage to leave the latest copies out for all to see.

Benefits of publications with your name on them

The first benefit that comes to mind when having publications around the office whether it be on your desk or on a periodicals rack where everyone shares them is having your name on the address field. It’s not always the first thing everyone looks at when picking up a magazine, but it’s very common for management to take a look at where this magazine is coming from.

You not only get credit for having ordered relevant material for others to check out or peruse between meetings, but your name is associated with being up to date having been delivered recent news and being interested in keeping up with relevant case studies or articles in your field.

(more…)

I’ve actually had this conversation come up twice the last couple weeks without instigating it myself so I thought I’d go ahead and cover the topic. Both people were on completely different sides of the argument as to whether or not team building exercises were a benefit to the company in the end. Personally, I lean toward it being a general waste of time, but I can also understand why it is beneficial to some.

Today I’ll describe my experience with “team building days” and toss out some pros and cons on why a company would want to promote them. Is it something for your company? You’ll have to be the judge of that.

Building an “egg catcher”

One day out of nowhere at a large company I was working for right out of college, the program manager announced that we were all to meet in the cafeteria for an all-day team-building meeting. I’d never seen one, and was a little annoyed that I wasn’t going to be able to finish the stuff I was working on. However I was sort of excited for the change of pace.

When I got down there, I saw him standing next to 6 tables with a big pile of sticks and pillowcases. The day was reserved for the entire room of 50 people to split up into 6-7 teams (I can’t remember exactly, there were a lot of us) with the goal of producing an egg catcher out of popsicle sticks, a pillowcase, twine, and a bucket. The catch was, all the little sub-departments were shuffled up and sent to all different teams. Each team was made up of people from different groups that didn’t normally work together.

At the end of the day, the program manager went around and dropped an egg from 4ft off the floor to see if each device would prevent it from breaking as was supposed to end up in the bucket on the floor. I think only one egg broke that day, and we all cheered the teams on as they managed to barely keep the eggs in tact.

Well, that was fun. What did I get out of it?

Ok, I just spent an entire day away from the work that was fresh in my head this morning. It’s Friday, so I’m about to leave for another 2 days and my work isn’t nearly where I wanted it to be by Monday. So now I’ll just be a day behind and have to end up making up time next week to be done by the final deadline. So why did I participate? What benefit did the company get out of me building this egg contraption?

(more…)

In the corporate world, there is a very heavy weight put on successful delivery. Companies usually understand that some things have learning curves, but where do you draw the line on testing out new technologies before you actually stop and deliver something?

Are you known as the guy that knows about a lot of things but never delivers on time? Can you relate to someone that always delivers on time but ends up using the same outdated approach over and over again? Maybe you’re somewhere in the middle, but how do you know when to balance learning with delivery?

I’ll define some considerations you need to take, factors that should effect your decision, and give some tips on how to apply what’s known to deciding which approach you should take to still be successful.

Things to consider

• Time – How much time do you have? Are your customers patient? Is there a high visibility on whether or not you can deliver quickly?
• Risk – Do you already have success with similar projects? How much experience does your team have in completing like tasks? Do already know how to implement all requirements requested?
• Resources – Do you have enough help to get everything done? Are you in a volatile environment where people aren’t able to dedicate themselves long enough to be effective? Is everyone involved able to focus on just your project without worrying about other commitments?

All of these items should be weighed in when deciding on a project plan. If you know there’s a very low risk in being able to deliver on time, it’s likely a good opportunity to begin trying new things or experimenting with new technologies that can be applied to some of the components.

If the risk is medium or high that you might not meet the expected delivery, using what you know will work should take precedence over experimenting with frameworks or widgets you’re unsure of.

(more…)