Friday, July 06, 2007

school→industry transition

A few weeks ago, actually a couple of months ago, Laurie put the arm on me to teach "new college grads" who are becoming new employees at the office. I was to teach them about our development tools and workflow, but rather than cramming a ton of how-to stuff into their already-full heads (my part is coming about ¾ of the way through their indoctrination), I decided to start with introductions and so on.

The "school to industry transition" came to mind as a topic that might be useful to them, and nobody else was addressing it, so I came up with "the four Cs" -- a different set than you've probably heard before. Here they are:

Collaboration

When I interviewed at HP, now over 3 decades back, Peter asked me what I'd do when faced with a task I couldn't figure out. I had no clue, so I suggested I'd go back to my manager and tell him it didn't look feasible. Well, he didn't call me a moron, but he did correct me. "Ask your colleagues for help!"

D'oh! In school I thought mostly in terms of independent work. One of my profs actually said that "there is only one acceptable way to do homework: alone."

In school, we're often in competition with each other. There are only so many "A"s to be given out, right? This is less of an issue with group projects, but even a team-written research paper has only one primary author.

It's true that some companies rank their employees against each other. This is rather a nasty deal and can't be helped, but I hope you work in a company that rewards team players over prima donnas.

Because at least in most technological organizations, one person alone can hardly accomplish anything! No one person understands the entire operating system, or these days even the kernel. (Linus Torvalds himself doesn't know everything about Linux.) So we have to work together... which brings me to:

Contribution

There are some things that only you can do to help your team, some other colleague, or the company. That would be a unique contribution and perhaps you should do it!

Then there are things that nobody else will do, even though they could:
  • Take minutes at meetings!
    People seem happy to let you do this. When you send notes out, people can refer to them later and don't have to rely upon their memory. Along those lines,
  • Be kind to future generations in your prose (and your code)
    So when you take minutes at a meeting, write them in a way that will be convenient to refer to later on. The headache you save may be your own! Put "action items" at the very top or very bottom, or maybe set them off like this:

    ==>Joe: verify marketing has seen the design spec by next Tuesday

    That makes them easy to see...

    Analogous comments could be made about code (if you write code), even if they're just short scripts.

  • When you like something, tell them!
    If Joe or Jane does something you like, something nontrivial I mean, send 'em a short email saying basically "thanks for your help on X; that will speed up the next phase of design" (or whatever). Use "bcc:" to let their manager know, too. Or send their boss a separate note. These are always appreciated, especially when their boss has to write their review!
  • My current employer has a "wiki" that's full of info on how to do various needful things, and anyone (inside the company of course) can edit it. If you have one, and find something in there that's wrong, fix it! Your employer may require reviews or something, and there may be guidelines for how much time you spend on that kind of stuff. Follow all those. But every question you answer (assuming that your answer is in a section of the wiki that people will look early on) will save people however much time you spent figuring it out. (Yes, I assume you're "average"; if you're faster than average, your answer will save others more time than you spent figuring it out!)

Completion

Ph.D students don't generally suffer from this malady, but undergraduates will sometimes say, "Bah, it's good enough; I'll just turn it in like this and take a lower grade on this one" -- because their other assignments give them enough points to get their desired grade, or they already have an admission for grad school or a job offer, or whatever.

If code is inadequately thought through or inadequately tested, there may be a phone call from the customer to your CEO. Test now or escalations later!

The other thing, though, is this: "completed" is defined by the customer. Reliability may be very important, but every whiz-bang feature you want to put in? Maybe not.

CSFs (Critical Success Factors)

Sorry for the jargon, but basically this means: What does it take?

What it takes, in a word, is character: Not "laziness, hubris, impatience" -- at least that's not the usual list. Instead, things like
  • conflict resolution and cooperation
  • being conscientious (not contentious); very often haste→waste, if not in technology then in interpersonal relationships
  • self-control and work/life balance. You can cram for a final and you can push hard for a short while, but you can't do that for thirty years. Believe it or not, someday you'll be as old as I am and you won't be able to do that.

    And when you have a family and children, you really shouldn't be doing that. Don't let your job cost your marriage or your relationship with the kids; it's not worth that!
  • Humility -- a willingness to learn and take feedback. How many people, when you give them a suggestion, tell you why they thought what they did was OK? They might want to learn, but they care more about thinking themselves right.

    Don't be like them! Instead, copy Einstein, who supposedly said that he'd rather know whether he was right than that that he was right about something.

Conclusion

That's my list; if you're starting a job right out of college, I hope it's useful to you. Given average talent but above-average pursuit of those four things, you'll beat out the "genius" who can't work with others most of the time. You'll be a superstar.

postscript: a book recommendation

Drucker's The Effective Executive (amazon.com link) which may have influenced my work world as much as any other book

No comments: