Specialist vs. Jack of All Trades

February 12, 2009

Do you focus on the details necessary to complete a task, or do you dwell on end results and overlook implementation details needed to achieve? Are you big picture or little picture?

Little Stone Carrying Big StoneI believe that the big picture people will inevitably rise above the smaller more detail-oriented picture people. This view does not state that the little picture people will fall off the face of the earth as the big picture people rise to power, but instead represents it as a yin-yang relationship in which one cannot be successful without the other.

This analogy can apply to almost anywhere, but for now put it in perspective of people trying to determine their career path, specifically in the technology industry. At this point in my life I am an impressionable, eager developer, faced with a difficult decision:

Should I become a Technology Specialist or a Jack of All Trades?

Do I want to put forth all my efforts into a specific product or do I want to step back a level and just understand a little about it and let the experts take care of all the nitty-gritty details?

I choose this example because I cannot see a path that says one of these is better than the other. I believe the decision to be made is a decision that no one can make but you. As a developer are you really interested in being an e-commerce, AJAX, or CMS “go-to” guy? Or, are you more interested in understanding most of the strong (and weak) points of many different product lines and knowing enough to be dangerous in any scenario?

Employers have use for both types of people. There is a time and a place. When business is booming and there is money to throw at the problem, bring in the specialist (and pay more). They are the sharpest tool in the shed and the one who will crank out the quality solution as fast as possible. Reverse that situation and do some budget cuts, lay off employees, and we find that a company can’t afford to pay as many specialists. They can pay our jack of all trades the salary of one person, and pile on the workload (of many people) for the same price. Do you see the trade-off?

I’ve made my decision. Up until a few months ago, I wanted to be a jack of all trades until I realized that choice lacked some opportunities available only to specialists. After further thought, I have settled on jack of all trades master of some. As to what that “master of some” will be, I do not yet know. Time will determine that.

On another note, this may be going against the other author’s post, but I believe that we must all show a bit more humility and acknowledge that even though we think we are big picture there is always a bigger fish in the sea that is more bigger picture and depends on us to implement the details.

The Reverse of Job Security

January 29, 2009

During times like these, why should I give up my responsibilities and throw away any job security that I have?

Job security should not be because you are the only one capable of performing fixer-upper tasks or upgrading a legacy system.

Job security should mean the company views you as an irreplaceable asset. If job security were based on your responsibility of maintaing an application or system, how are you ever able to grow and take on new projects?


As a consultant, I ended up in this scenario because the responsibility of the developed system was left completely in the hands of contractors. Any full time employees who were previously involved left the company. When I was the last contractor on the project and ready to start another gig, upper management discovered that there were no internal developers with knowledge of the system that was built. I became irreplaceable, but not because of my abilities. I and the upper management team failed to ensure that other developers understood the system. No one had the confidence that they would be able to maintain it should something go wrong. As a result, this hurt me by preventing me to take on additional work opportunities and start on other projects.

Unfortunately we cannot always depend on management to take care of spreading knowledge around to other teams as that requires more resources to schedule on their part. The key here is spreading the knowledge by taking initiative. Invite other developers, junior ones specifically, in to your circle and educate. Question them and teach them. Tell them you are doing this so you can move on they gain a more well-rounded view of different application designs and roles. Make it sound interesting. Don’t pass on what you did right about the system. Pass on what is wrong with the system and what you would have done different so that they learn from your mistakes.