Last Friday, I published a post called “The Polyglot’s Dilemma.” I had actually had a stubbed draft for this post, “Always Be Leaving,” before writing that one. But it turns out that post segues nicely into this one.
Programmers (especially polyglots) face a dilemma wherein the thing that makes them most employable (broad generalist skills) also positions them as resources rather than strategic experts. To make matters worse, broad industry generalizing also puts programming labor in the category of fungible commodity. Knowing many languages and techs makes it easy for a company to assign you to any arbitrary upcoming automation project. But it also makes you easily replaceable by any similar generalist.
The polyglot generalist comes to the company as an easily-deployed generalist. He/she then waits for people tasked with organizational strategy to deploy them. But then, of course, they do. This represents the only way for him to remain indefinitely engaged as an employee. A specialist comes in to execute on a limited duration charter. A generalist signs on to do whatever the company happens to need for the rest of his career (theoretically). This context demands a generalist since nobody knows what the company will need in 5, 10, or 20 years.
And so we see that the polyglot’s dilemma arises naturally from indefinite employment.
Leverage: A Study in Contrasts
“Always be leaving,” as a title probably reminds you of the pop culture sales phrase, “always be closing.” Popularized by movies like Glengarry Glenn Ross and Boiler Room, it evokes images of the iconic pushy sales guy. This sales guy does things like cold call you and say, “should I sign you up for two or just one?” See what he did there? He gave you no option to say no. Slick man that he is, he’s always closing.
If you take the self-important testosterone out of the situation, you can see a more basic psychological reality. “Always be closing” applies to situations with little to no leverage. Fast-talking sales guys call up “whales” and, through force of personality, convinces them to buy stocks they don’t need. He has no actual leverage — nothing they really want — so he exerts his dominance by turning on the forceful charm and bamboozling them. Then he high fives his buddies afterward and rings a bell and screams or some such. He creates leverage theater in order to secure the metaphorical kill.
“Always be leaving,” on the other hand, offers a complete leverage reversal. When you find yourself ending an engagement or an employment tenure, you have tons of leverage. But you usually forgo using it. You give your notice, and the notified party often asks what it can do to keep you, even though you feel excited about looking ahead to the next thing.
The Merits of Leaving
Think of that awkward couple of weeks after you give notice at a job. You feel generally lighter and unconcerned about much. This happens because all of the implied leverage from your tenure has melted away. You’re already leaving, so almost nothing you do will have any real consequences. You operate with nearly complete freedom to do and say as you please, almost as if you were your own boss. Nobody at that job has any real leverage over you.
But you might notice another subtlety as well if you pay enough attention. Generally, people’s esteem of you increases just a little bit in this situation. Unlike any of them, you’re headed for greener pastures, which gives you a little cachet. Your words seem to carry more weight.
This and the nature of your time as a limited resource make you, your knowledge, and your opinions in higher demand. Your calendar fills, and people come to you for help. They treat you deferentially and ask if it’d be all right if they call you even once you’ve left.
When you’re demonstrating your leverage by leaving, you get a taste of true autonomy. Unfortunately, you only get this in two week stretches every now and then.
The Merits of Perpetual Leaving
You could presumably extend your periods of leverage by giving months of notice. I don’t recommend this, though. You have leverage, but the limbo state becomes unbearably awkward after a while (I can speak to this from experience). Wage employment means signing up for the mutual pretense that you and the employer will be together forever, à la marriage. So, while breaking this covenant may furnish temporary leverage, it also creates a slight sense of betrayal.
You can’t avoid the divorce feel once you’re an employee. But you can avoid it by not becoming an employee and by taking on projects rather than indefinite arrangements. I wrote about this last summer in a post called, "my realizations about software consulting." Prominent among those realizations, I concluded that I always wanted to take on work with a well-defined end to the engagement.
With this, you get the best of all worlds. You have the leverage and the cachet with your clients, but without the sense of betrayal when things end. You exude options. When you have open-ended engagements, you start to resemble “just another employee” regardless of your rate card or title. But when you make your time and attention fixed resources, your clients always want to take advantage.
“Always be leaving” allows you always to be closing, but without all of the sleazy sales guy stuff.
Always Be Leaving
I can imagine what you’re thinking. “Always be leaving” seems like decent advice if you have a prospective client list and an appetite for risk. But it asks you to cross a bridge too far from the 9-5 world. Fair enough.
But consider something for a moment. Even though employers and programmers alike engage in the mutual fiction that the relationship will continue indefinitely, it usually doesn’t last all that long. We tend to leave jobs with relative frequency, jumping ship for better pay, better titles, or just a change of pace. We’re kind of already always leaving — just not deliberately. So, really, you don’t need to take a bridge all that far.
To get started, you don’t even need to flip over to something like staff augmentation contracting. In fact, you can keep plowing right ahead with salaried employment. You just need to do two things:
- Start thinking of a problem you can help organizations solve to position yourself as an expert.
- Approach any new job you take with success/exit criteria in mind from day one.
Now, I’ll grant that I’m advising you to do something slightly shady, but opportunism is not for the faint of heart. Besides, when you start to view yourself as a consultant with success criteria, you’ll plot exits that make sense for both parties and don’t leave your employer (client) in the lurch.
If it Hurts, Do it More
Here’s the thing. You’re not going to stay around all that long anyway, most likely. At best, you might offer up 4 or 5-year stints with a company, on average. Then you move on. I propose that you go from reactive mode to planning mode. Lay out goals up front, and move on exactly according to a plan for your career.
Draw on the wisdom of continuous integration: if it hurts, do it more. I remember hating job searches and interviewing early in my career. Then I started doing it more. And, while I didn’t exactly come to love it, I got used to it. After that, I went off on my own and my life became a never-ending string of finding the next gig. While I don’t enjoy lining up gigs as much as writing or programming, I really don’t mind it. I actually kind of like talking to people, listening to their challenges, and laying out a proposal to help.
If you get into a mode of constantly lining up your next challenge, you’ll get used to it and you’ll get good at it.
The Specialist Career
Hopefully, this brings two disjointed parts together as a whole. The specialist career involves saying no to the polyglot’s dilemma by saying no to open-ended tenure as a fungible resource. And you can only say no to open-ended tenure as a resource by viewing each entity that pays you as a gig, even if it views itself as your employer.
It’ll feel weird at first. But practice in the low-risk setting of your current and next few jobs, if you’d like. Go in there with a mission and with exit criteria, and develop a specialty wherein you start to solve a business problem using automation. This makes up the essence of what I call the “efficiencer” in Developer Hegemony.
Maybe you help banks secure the data access layer of their web applications. Or perhaps you help embedded shops improve their test automation. Whatever you choose, make sure you position yourself by specializing in some combination of a business problem, technical expertise, customer segment, and domain. But whatever you do, don’t make your specialty Node.js or C# or whatever. Those aren’t specialties because they have you competing with every staff aug and W2 grunt developer in the world.
If you want to go this route and take more control over your career, you need to plot out your next victorious exit. And from then on, you should always be leaving.