What Technology Should I Learn? Which Contract Should I Accept?

At some point (or at many points) in the life of a busy business IT consultant, the inevitable question arises:

“What technology / technology stack / vendor product suite” should I learn?”

Or a variation:

“I’m looking at two projects. Project ‘A’ uses [insert older technology stack here] and project ‘B’ is using [insert newer/different technology stack here]. Project ‘A’ just finished and learned a lot, but ‘B’ uses a technology that isn’t as common. Project ‘A’ is offering to keep me on with the common but older technology, and ‘B’ offers an newer, but less common technology.

So…Should I stick with ‘A’, go with ‘B’, or train myself to do ‘C’ and get a project doing that?” (Yes, I do actually get this type of question a lot.)

Sound complicated? It can be, especially as your career builds and more opportunities open up to you. If the scenario is a bit vexing, my apologies. But, I needed to find some way to share this with you today; I get variations of this question sooooo…. often. In fact, I’ve faced it myself numerous times.

So let’s break it down. Do you stay with a contract and a known quantity, change to a different contract with an unknown (or lesser known) quantity, or do something different altogether? Oh the dilemma of it all!

Before sharing a few hard-earned insights, I want to suggest not locking yourself into any particular technology stack. If you’re talking about big programming languages such as oh…Java … or…oh….NET for example, bets are pretty safe that both will be around for some time to come. (No flame wars here guys and gals. We’re not picking sides…)

But we’re not talking about big programming frameworks here. The questions we’re answering revolve around more boutique and often highly specialized technologies and big enterprise vendor products such as Oracle Identity Manager, or Microsoft’s Forefront Identity Manager, or Sales Force, or SAP ERP, or PeopleSoft, etc. Stuff like that.

Approaching the “Which Project Should I Take/Look For Next?” Question

Here’s how I approach this whole issue:

1. I consider the project itself, and the type of client relationship it will be. The actual project tasks, the client, terms, how it fits with my business and my schedule working with other clients and projects are all way more important than the actual technology or vendor(s) being used. As IT consultants and entrepreneurs, we need to think of our current and upcoming projects in a “business first” mindset. Business and marketing first, technology and geekery later.
2. I consider where the market is going, or, where there are particular niche needs — OR, where the market has BEEN. I’ve said this a thousand times if I’ve said it once: many big careers are built in business and IT services by supporting non-glamorous or “old” / “legacy” technologies. I’d go as far as to say that if a project comes along and offers you a chance to work with some legacy stuff like mainframe integration or crusty versions of accounting and finance packages, it’s worth a strong consideration. There are a lot of old and unsupported versions of servers, operating systems, application software packages, you name it out there. And do their owners have a need not easily filled in today’s market? You’d better believe it!
3. Is there an opportunity to work with new technologies (as in new to me or my skillset)? Hands down, if faced with two projects of more or less equal weighting in the client/earning/satisfaction areas, I’m going for the “new-to-me” technologies each and every time. Skill portfolios only become broad and strong by working lots of different projects, with lots of different clients, in lots of different markets, and with lots of different people, processes, and technologies.
4. Is it a technology or toolset I cannot download or otherwise get a license for? This is huge, and a game-changing decision factor. If project ‘A’ uses off-the-shelf technologies that you can download and learn on your own, and project ‘B’ uses technology that costs thousand of dollars for a single license and a D&B number just talk to the software vendor, then … guess which I’m gonna get my hands on?

Something to keep in mind is that just because you don’t hear a particular vendor talked about much anymore, does not mean that their stuff isn’t deployed in companies or governments having huge contracts with that vendor. I can think of several software companies you no longer hear about, because they’re no longer “cool” or “sexy”. But guess what? their stuff is deployed at companies with hundreds of thousands or even millions of seats! That my friends is credibility.

If I can impart one other thought before my virtual ink runs out on this article: don’t look to job boards and contract services as your main source of project information. Remember way back in the day, when jobs were advertised in papers? And remember when the old adage was “the best jobs aren’t advertised?” That’s as true today — if not truer — than it was then. Look beyond the social networks and job boards when seeking good business technology contracts.

And one other little secret before I toddle off for the evening: most of the really big important players are not out there telling $5.00/hour recruiters what their actual project needs are. No sir (or ma’am). Companies like that find their talent discretely and indirectly, and don’t make their products and architectures publicly known.

When shopping for lucrative, portfolio-building projects, know that that whole “transparency” thing being bandied about today is hooey. (Yes, I actually said “hooey”.) If Mr. or Mrs. “Big” from the XYZ corporation offers up an interesting project using a technology that you haven’t heard your friends talk about? It’s time to get interested. Really interested.

Conversely, if they’re using stuff that triggers a “that stuff is so old I didn’t know ANYONE was still using it” reaction, — well yep — time to be really interested in that too!

Now it’s your turn. What is your take on all of this? What system or processes do you use to decide between projects and/or technologies to support? Sound off in the comments below.

Good night for now…