If I were a manager at a technical company, say software development. And I were hiring a new co-worker to work with my existing staff, the first place I would look for applicants is staff recommendations.
I would evaluate their recommendations to be sure they are competent. If they are competent and recommended, I would hire them. The existing staff is the ones who will have to work with the new-hire.
Sure, hiring from a larger pool might produce more technically savvy staff, but personality is more important. Technical training is a whole lot easier to come by then resolving a personality conflict.
So worst case hiring a recommendation is investing in some technical training, since the personality and ability to interact with the existing staff is known. But if we hire from a larger pool (say a classified ad or a job listing site) then worst case is that we have an unresolvable personality conflict, and need technical training.
Subject Tags: [Programming] [Jobs] [Workforce] [Personality] [Coworkers] [Training] [Staff]
3 comments:
Wise advise.
During the day I work at a five year old startup. I got in pretty early and watched as they built a 30ish person engineering team very fast. Every person hired came from an internal recommendation. It's been the best team I've ever worked with.
A related problem tho: hiring a Programmer Manager.
Nothing can break up a good team like a bad manager, and bad managers seem harder to get rid of.
That said, I just saw this interesting post today: http://positivesharing.com/2006/03/how-not-to-lead-geeks/
I agree with you, Chris. Effective IT managers are very rare.
In most fields, this saying applies: "You cannot manage what you cannot measure". Most IT managers don't know what to measure or how.
So they end up measuring futile or irrelevant things, such as comparing how well you progress against a projected schedule (futile), or else tell you how to line-up your labels with your textboxes (almost irrelevant).
There are two candidate areas for measuring: 1) Code quality and 2) Requirements (specifications) quality.
Requirements: the quality of the requirements is often out of the manager's hands, since they need to rely on untrained users.
Code Quality: there are products available to produce metrics for code quality, such as FXCop or my (now defunct) Code WalkThrough Pro. I still can't figure out why managers don't utilize this, or similar technology.
All I can guess is that 1) Managers aren't confident judging code quality and 2) Programmers are so iconoclastic that they feel insulted whenever some one tries to judge the quality of their work
Post a Comment