This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: Protecting Your Job
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog.
The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
Today more than ever we need to take steps to protect our jobs. You can't just sit by and hope your career turns out the way you'd like. With outsourcing around every corner, the rapid pace of technological change, and corporate "right sizing" you have to be proactive about protecting and enhancing your career.
This is a topic to which I've devoted some amount of thought for my own benefit and I've been fortunate enough to work around some people who are very good at this sort of thing, so I decided to share some of what I've learned.
If you simply follow these three principals, your job will be very secure and outsourcing will be something your friends worry about, but it won't touch you.
Open Standards
What do I mean by an open standard? The Junit log file format. It's a format that any tool can write and any tool can read. This lets any tool vendor or open source project create a new product around that format. There are lots of little open source utilities that will generate reports based on your Junit logs or export their own test results into a the Junit format. This lets a wide variety of tools import and export the information.
Open standards create "magic glue" between various applications. Ruby on Rails is a great example of a wide swatch of dissimilar technologies being stitched together. Rails uses web servers, testing frameworks, databases, OR frameworks, and more, all stitched together into a brand new product with a entirely new paradigm.
And that's the problem with open standards. They enable disruptive technologies to march in and obsolete your existing skill sets. When all the information can be consumed by anyone, what's to prevent some hot shot new college graduate from coming in and taking over? Not a whole lot! All the open source hippies never think about this huge liability! If you want to protect your job, you need to keep this in your mind all the time.
Instead of using "magic glue", create your own glue. Keep all your glue bits in house. Proprietary protocols and data formats can't be easily duplicated or replaced. And never use text. It's just too easy to parse with Perl or Ruby. Stick with a binary, undocumented format.
Remember, information is power. Guard it carefully.
Tip: Make sure you create and own every data interchange format your organization uses. Never use something configurable like XML. Binary is always better than flat text.
Build or buy?
You'll inevitably face the decision to build a product from scratch or reuse an existing product. Whether the products are open source or commercial, you're still looking at the "build or buy" question. Does the solution come from within the company or without?
Let me tell you right now that anytime you reuse an existing product, you are putting your job at risk. Anytime you reuse an existing product there's a chance that someone else might know the technology better than you. And those people start showing up at your company, you lose control.
While it's true that there is nothing new under the sun, and problems just like yours have been solved over and over again, you've got to present your situation as new and different. You've got to convince your management that your situation is "special" or "unique" in some way. It doesn't really matter what you tell them as long as they believe that no one else has ever encountered this exact problem before, so no existing products can possibly be used to solve your organizations problems.
This might seem like a side issue at first glance, but it's actually a vital part of this strategy. By creating every tool in house, you ensure that your management can't bring in outside expertise or outsource your job. Since you created every tool you use, you are literally the world's foremost experts on the toolset! You'll be nearly untouchable.
Unless the entire company goes under or the entire product line is discontinued, you'll be safe. To replace you would mean replacing all the infrastructure and momentum that you've built over the years. It would neither be easy or cheap to do so.
Someone on your team wants to use Java RMI? Write your own socket protocol. Someone else wants to use Ant or NAnt? Create a new build system that uses your own language! Are you on a middle-ware project? Don't go with a known app server. Write your own.
Sure, this approach means you have to start from scratch instead of reusing an existing well-tested product. It'll cost your company a ton of money and more time than you can imagine... but you'll be safe and that's what really matters.
Not Invented Here (NIH) syndrome is well-known for a good reason!
Tip: Write everything in house
Create Your New Tools Without Permission
Keep your new project "under the radar" as long as possible. If your project becomes common knowledge too soon then you risk someone bringing an equivalent (or better!) product from outside. The best way to get entrenched is to spring a working (or nearly working.... or apparently working) system on your coworkers. You'll need a head start on the competition to get buy in on a system like this.
Your new software doesn't have to really work. It doesn't have to handle all the difficult edge cases, just take the easy scenarios and make an impressive demo. This type of system appears to work at first glance and is all you'll usually need to get management buy in. Once you have management buy in, use it to force everyone else to fall in line. As long as everyone thinks you have one hundred percent backing, they'll do exactly as you "ask".
By the time everyone realizes you "solved" the hard problems by skipping them, it will be too late. The company will have invested so much time and money in your project that they'll feel compelled to see it through. Additionally, the people who initially backed your "working" demonstration don't want to see you exposed as a fraud because it shows everyone how they were fooled.
So work without official sanction as long as you can. Invest your nights and weekends if you must. Don't worry about the overtime. You'll make up the time in spades once you're new system is in place and you're running the show. That's when you can leave early most days, spend your time surfing the web, and doing minor maintenance from time to time when the common folk start yelling loud enough to interrupt your afternoon.
In Conclusion
Just to recap, avoid open standards. Never reuse existing products or software. And sneak the new products into place.
Follow these three simple guidelines and I promise you'll have a very secure career.
Previous Topic
