🔑 3 Sentence Summary

1. It isn’t favorable to be a programmer. You’ll be doing grunt-work, and it’s almost impossible to reach great careers. It’s alike being a factory worker. You don’t want to code all day if you want to get somewhere.
2. To go further, you first want to escape the delivery trap. That means to not have your performance be based on the delivery of some kind.
3. There isn’t really any way to summarize this book. I suppose, what he believes you want is leverage. Leverage such that you can’t be measured by the measurements of others. You want ownership. Your own thing.
4. Playing the game others have made is playing a losing game. They make the rules; of course the rules favor them. That’s why you want your own game.

🧠 Thoughts

The book makes some great points. Highly enlightening.

🤝 Would I recommend it? Why?

If you are any kind of knowledge-worker — especially a software engineer — you should read it. If not for any other reason than to form your own opinions about the ones presented.

✍️ Summary

• Do take a look at the 3 Sentence Summary. I won’t copy what that says down here. What follows is summaries of some of the points made in the book.
• Programming is about automation. The automation of tasks. It’s about efficiency. That’s the value programmers bring. They automate tasks.
  • Imagine a web form. If that didn’t exist, what would we have to do instead to provide the same results? Mail-in forms.
  • The same goes for websites in general. How would you present so much information, if not for the automation that the internet allows.
• There is much more to running a business than simply having a great product (in our case, building great software). Having a great product does not automatically result in sales, marketing, accounting, and so on. It is a minor part of a whole business.
• See yourself as a business. You work for yourself.
• You can and should work hard. But don’t take a 50$ gift card for your efforts.
• Market yourself.
• Create content.
  • Books, videos, blogging, training courses…
  • Position yourself as an expert.
• Sometimes it’s hard to stop doing something that isn’t valuable because you’re “optimizing,” or “refactoring,” or “cleaning.” This is, however, a trap. You want to do what is most valuable for the business (your business).
• Learn to sell.
• Start a blog.
• Start a “side hustle.”

🔦📒 Highlights & Notes

Opportunists Become Other

This transformation into an opportunist is, at its core, about altering your perception of yourself. You need to stop viewing yourself as a software engineer II or a QA specialist or a dev manager. You need to stop viewing yourself as an employee of your (or any) company and start viewing yourself as the owner of your own personal brand and operation. You are an island. You are other.

The Realpolitik Tragedy of Corporate Scrum

Being a good developer—participating gamely in team activities, learning enough algorithm trivia to pass interviews, being attracted to the best organizations using the coolest tech, and so on—is bad for your career. The real tragedy of all of this is that the current corporate structure forces you to choose between being a good developer and having a good career.

Makes it almost impossible to attain higher positions (than maybe architect or the likes)

The Programmer’s Escape Plan

I want to be very clear at this point. If you’re a programmer seeking to be an opportunist, you need to start figuring out how not to be a programmer in the near future. You need to plan for your graduation.

You can program at work, just don’t be a programmer. Programmers are the grunt workers - that’s not where you want to be (if you want what this books assumes you want)

Opportunists are busy figuring out how to stop being considered programmers, even if it means potentially getting fired.

The opportunist has a will-to-power attitude toward the organization. The opportunist programmer is one that wants to call the shots, the way that a department head or CTO does. And when she sizes up the situation earnestly, she comes to understand that this occurs neither through establishing herself through superior programming knowledge nor through acquiring superior carnival cash. It happens some other way.

Carnival cash = merit/currency only spendable inside the corporation

An opportunist view of the programmer condition reveals a sad picture. Some people go to school for computer science, earn computer science degrees, and get jobs as junior programmers. Other people go to school for business, earn BA degrees, and get jobs as project managers. Within a couple of years, the project managers have “dotted line” authority over their peer programmers, since the programmers are another resource in need of management. It’s classic Taylor. The opportunist programmer thus learns that it’s better to hang out with the project managers and distance herself from her fellow developers.

But there’s more to the escape plan than simply targeting non-programming roles and responsibilities. It’s in the lexicon and the manner of thinking. You need to learn the language of the business and talk intelligently in terms of profit and loss, return on investment, and the other terms relevant to the company’s big picture. You also need to swallow whatever joy you extract from correct, elegant implementations and adopt a willingness to sacrifice Cadillac quality for time to market. You must sell out and believe in selling out, taking your joy of working with the tech and completely compartmentalizing it. Fun with toys is for outside the office. Programming is not a calling, and it’s not a craft. It’s just automation that increases top line revenue through product or reduces bottom line costs through efficiency.

Once you’ve steeled yourself to thinking that way, the opportunities to move toward leadership will start to become obvious: who to talk to, what to say, and how to say it. Build the resume that you’d need in order to apply for a dev manager job and work backward. Find out how to get yourself in your company’s interviewing process. Volunteer to liaise with the project manager closely so that you can list project management activities. Same with the business analysts.

All of this is not going to be to advance your fortunes within your current company, of course. This is the company that brought you in as a line-level programmer, and getting them to see you as anything but that will be nearly impossible. Rather, you’re preparing for your next interview—the one in which you’ll go from a title that involves “software engineer” or “developer” to one that doesn’t. The next move has to be significant in terms of advancement (architect), something involving leadership or management (tech lead, project manager) or something vague enough to serve you well (consultant, associate).

Once you’re in a role like that, you can always leverage your technical background as much as possible to further your interests and career. Many CIOs/CTOs come from a programming background, as do many peripheral and line management types. But in order to get to those roles, you need to first step out of the software engineer assembly line and then step back in somewhere much higher up the food chain. And that first step out requires an escape plan.

Avoiding the Delivery Trap

Assuming you’re still on board the opportunism train, the key lesson from the last chapter is to find a way not to be a work-a-day programmer. The easiest way to make this happen is to make a lateral transition into a role where the title is something other than programmer (project manager, consultant—some kind of lead). And the easiest way to make that happen is to work backward. Evaluate what you need on your resume to get an interview for such a role, and then volunteer for those activities in addition to the responsibilities of your current role (or instead of, if you’re truly not risk averse).

The first thing to do is to learn from the aforementioned Team B. Delivering something on time isn’t a remarkable story. Delivering something on time against all odds!? Now that’s a remarkable story. Seek to dampen expectations without being overtly gloomy, and then blow those expectations away. Play up how much you’ve blown them away, too. The ostensible reward will be the fifty-dollar Amex gift card. The actual reward will be your growing rainmaker legend.

You want to escape the delivery trap (so you don’t have to deliver some output). Start by controlling the narrative- like this quote.

Any time you have lulls in your expected software delivery schedule, fill those lulls by volunteering for meta tasks around software development. Volunteer to audit the team’s use of JIRA and see if you can’t come up with a more efficient process. Schedule some talks with business analysts to learn the domain so that you can coach the rest of the team on it. Dig up your team’s yearly goals from some back email and do a research project, figuring out how to make those goals more likely. Do this during your lulls and, if you’re so inclined, do it during your spare time.

Once that’s established, keep it going. Make it visible to management for a while, and it will become an assumed part of your duties. The real litmus test, and the thing that you’re angling for, is a situation where you say, “I can’t pitch in on that second feature and continue optimizing JIRA and coaching the team,” and someone that matters says, “Well, we’ll just have to assign that feature to someone else.” You need to become too “important” for simple delivery.

And speaking of output, you have a line to walk here. You don’t want to be an incompetent programmer, but you also don’t want to be your team’s cleanup hitter. If (and I speak from experience here) you become known as the person on a team of ten that delivers half of each release’s features, you’re fashioning a delivery trap for yourself that’s sprung and made of granite. You’ll never escape because the organization can’t afford to let you. Instead, you need people to say of you something like, “He’s a decent programmer, but where he really shines is getting the most out of the other programmers.”

In the programmer’s escape plan, getting away from delivery is the absolute most critical pillar. There are other facets of that escape, but this is truly thing one. Opportunists in software development establish themselves as other, realize that they need to escape, and then get away from delivery as quickly as possible.

Partnership and Transcending the Realpolitik Glass Ceiling

Opportunists realize that there’s no such thing as a company outside of tax and legal documents. In other words, opportunists don’t view themselves as a tiny company dealing with a massive one. Rather, they view themselves as a tiny company dealing with a large population of other tiny companies. The opportunist may as well be in a co-working space, wheeling and dealing with partners and prospective partners.

This is why the concept of partnership is so important. Becoming other is a matter of mindset, a matter of leaving the cave wall. Learning to barter, broker, and bargain with partners provides the strategic tools to enable your ascent. And understand that everyone you encounter is a partner with varying degrees of power.

This partnership understanding is critical, particularly the nature of the partnership with your boss. Once you see your boss not as a parental champion of your career, but as the client making you a captive shop, important realizations start to flow. As with any business, that lack of diversification is dangerous. That’s doubly true when you’re stuck in the delivery trap, being measured in a game entirely of that client’s creation.

One of the best ways to really hint at options is to change the game in stock asymmetrical situations. For example, consider a performance review. Right at the outset, tell the reviewer, your boss, that you’re not really interested in more money. If she wants to show appreciation for your contributions, she could show it instead by letting you do some research into more efficient ways to manage the feature pipeline for your group. Explain that this would scratch a personal and professional itch of yours.

In one fell swoop, what you’re really saying here is, “I don’t need money, I’m intelligently interested in management, and I politely reject this silly performance review process.” There is some risk in an approach like this, particularly if your boss is an idealist, committed to the farce

The strategies I discussed for escaping the delivery trap were largely tactical in nature, rather than strategic or philosophical. Seek out responsibilities other than delivering software. Seize opportunities to exhibit leadership, real or perceived. Take the standard, LinkedIn-style career advice of emulating your manager’s behavior, but with the non-risk-averse, delivery-escaping approach of an opportunist.

Recall that opportunists succeed by becoming other. This means that real opportunists do not view themselves as employees of a company but as single-person corporate entities unto themselves, dealing with the rest of the corporation as a series of outsiders. Opportunists thus view all of their relationships at work as various flavors of partnership. And this partnership is the key to slamming your way through the various implicit glass ceilings that neither idealists nor pragmatists perceive. Partnership is the key to removing the governor that the corporation places on your advancement.

Your boss is basically your lone client, by default. In industry, you’re what’s known as a captive shop—you’ve placed all of your eggs in the basket of your only client. If that client fires you, your business is in deep trouble. The same is true if you have people reporting to you—they are captive shops of yours, where you are a big client that can throw its weight around with impunity. People of influence and “dotted line” relationships are essentially large industry players with the power to indirectly ruin your day. And so on and so forth.

Back in the corporate world, you need to start imagining yourself as a displaced owner/executive/entrepreneur with an explanation for hanging out among the grunts. Perhaps you’ve run point on a few startup ventures, but settled into a nine-to-five job for the sake of a little stability for a while. Perhaps you have a side business that’s really taking off, but you’re here, getting some perspective at the line level. Whatever the explanation, you’re an owner and executive among grunts by your own choosing.

You can do this in many ways, and you’ll need to find the strategy that works for you. Little things like tons of contacts and recommendations on LinkedIn can actually help. Speak extensively about your experience in other places, cultivating an air of the cosmopolitan that stands in stark contrast to your peers that have only had one or two jobs. Moonlight on the side and talk about your experience doing so. Casually cite experience on the level of your superiors in a flattering way. “I like what you’re doing in terms of dividing up the break/fix work—when I used to run a team, I had a strategy that I thought was pretty good, but I’ve definitely learned a couple of things.” The message that’s actually heard below the superficial? “I’m actually a peer of yours, but I’m not here to threaten.”

Strategies for “becoming a peer” of the opportunists

Remember, though—never threaten. Even in a situation where what you’re saying is a threat, couch it as “just business.” If you take a gig in another department or accept another job offer, don’t throw it in anyone’s face or delight in it. If anything, present it in such a way that a boss or compatriot is left in the end agreeing that you’re making a great move. You’re not vanquishing foes and you’re not settling debts—you’re playing the game well, simply creating advantages for yourself.

Opportunists don’t demand merit evaluations, and they don’t wait for performance reviews. If you want your boss to really hand you some valuable benefits, you need to do the same for her. Make her life better somehow, then look for reciprocity.

Avoiding Carnival Cash

The first generalized theme is that you need to avoid “‘A’ for effort” recognition as if it were a pile of dog poop that was also poisonously radioactive. Never, ever be in a position where being patted on the head and tossed a treat is an acceptable substitute for compensation for the value that you bring.

Don’t confuse this with advice not to work hard or even having people recognize that you’ve worked hard. You absolutely can and should work hard when appropriate. Work hard to help your boss advance. Work hard to bring in extra money for your department. Work hard to generate internal and external leverage to help your situation. But whatever you do, do not work hard to please some superior in the hopes that they’ll deem you worthy of a raise someday.

Now, I know what you may be thinking. “Making demands for doing your job well sounds risky.” Well, let me emphasize a few things. First, I said from the outset that opportunism is a high-risk game. Second, we’re not talking about doing your job but about going above and beyond your job; you have to do impressive or high-leverage things to move up quickly. And third, you’re not going to saunter in and make demands; that’s the idealist cartoon of negotiation, not real negotiation.
Present these quid pro quos as win-win, and leave yourself a plausibly deniable out. Consider the example I mentioned earlier. You tell your boss that your brother-in-law runs a firm and ask if you could be made team lead if you can bring in that business. If boss says yes, then great. If boss is an idealist and says, “It’s your duty to the company to bring in business” or “Bring in the business and we’ll see what happens,” then don’t argue with him. Simply agree, and then don’t bring in the business. If boss asks about it later, just smile a little and say, “I tried, but he just wasn’t that interested.”

When you’re able to manufacture some leverage for yourself, do not squander it. Do not voluntarily accept carnival cash. Do not give anyone the opportunity to swoop in and dump it on you. Avoiding carnival cash as recompense is critical.

You need to be like a shark. You must always keep moving. Always be transferring, switching roles, switching jobs, switching projects. If you start hearing things about yourself from coworkers along the lines of, “Oh, [insert your name] has been saying we should implement that forever,” then you need to march into your manager’s office and tell him you badly need a change of scenery.

This holds true for line-level opportunists looking to break into management, but it holds especially true for managers. Shark managers ascend through the narrative control that I talked about earlier. All transfers can be spun as taking on new challenges, graduating to more responsibility, or even staging victorious retreats. Suckers and idealists go down with the ship. Sharks like you swim away and live to fight another day. And most importantly, they don’t stick around long enough to get noticed for a hoard of accumulated feel-good carnival prizes.

I’ll close out the chapter by offering one last piece of comfort. If you find yourself in a situational quagmire, stuck in place for too long or pinned down and confronted directly with carnival cash recompense, all is not lost. No single employee of the month award will relegate you to idealist purgatory forever. I’m more talking about the noble act of politely refusing carnival cash. Let’s revisit the realpolitik petri dish from earlier. If you’re sitting there, minding your own business, and someone nominates you for $100, you have options. Stand up and graciously say that you can’t accept it because it was really Bob who did all of the hard work. Or consider a hypothetical scenario: you’re offered acknowledgement at some huge department meeting for landing a new client. You could always say something like, “I really get uncomfortable with that sort of broad recognition for my own work when so many of my teammates contributed to the pre-sales and onboarding processes.”

So form your partnerships as if you were a business. Offer and demand quid pro quos and understand when you have leverage. And always keep moving, lest you gather barnacles. If you seek and offer legitimate consideration and you avoid carnival cash, your rise will be swift and steady.

The Art of No

Ascendant opportunists have to learn the art of no. The art of no is broad and subtle, though. It dives far deeper than simply blurting out the word “no,” which I’d rarely, if ever, advise. And it comes in many flavors.

The first flavor I’ll address is what I’ll refer to as “no by saying yes.” It’s certainly the sneakiest way to say no, but it’s also the one that involves far and away the least amount of conflict. You agree to something that doesn’t benefit you, but instead do something that does.

In situations with far less muddy waters, you have other options. In the last chapter, I described a specific instance saying no that I’ll now call “no by self-effacement or sacrifice.” In that chapter, our hero opportunist downplayed his role and refused a cash reward. This is perhaps the best technique for avoiding carnival cash, but it can be used in other situations, too. For instance, consider a dubious “plum assignment” that actually sets you up for failure.

Such assignments represent frequent channels for bounded advancement in the idealist world. If some opportunist mistakes you for an idealist, you might find yourself “promoted” to work on an account or project that will certainly fail. “We know it’s a reach, but we feel that, if anyone can do it, you can,” they tell you. Counter (and show them that you’re not an idealist) by saying, “Oh, I appreciate the offer and am flattered, but I think Jim has been putting in tons of hours and would be a much better fit.”

A related but more compelling form of no is “no by counteroffer.” With this tactic, we begin a dive into better examples of powertalk and maneuvering. Saying no with a counteroffer is really just saying yes to another question.

In the world of improv, as I understand it, actors avoid the word “no” in favor of “yes, and…” when continuing the improvised dialog. For instance, let’s say that the first actor says, “I’m a serial killer responsible for gruesome crimes,” and let’s say that the second actor prefers more lighthearted topics. He wouldn’t (indeed, can’t, per the rules of the game) say no. Instead, he’d say, “Yes, and after undergoing a revolutionary new brain surgery, those impulses have been replaced with a desire to be a philanthropist!” The second actor basically says no via redirected narrative.

You can do a bit better than “no by counteroffer” if you’re clever. Specifically, I’m talking about the next form: “no by better idea.” It’d be fair to consider it a strict subset of “no by counteroffer,” in which the counteroffer is a better idea. But I recommend considering it separately.

“No by better idea” happens when someone throws something at you and you offer a demonstrably superior solution. If you look at “no by counteroffer,” the counter isn’t necessarily superior. Just different. Better ideas don’t tend to involve phrases like “I prefer,” and they don’t really amount to quid pro quos or horse trading. They involve addressing the same problem, but in better fashion. This requires root cause understanding.

Now, let’s get into even more political forms of no. Consider the case of “no by negative sell.” In case you’re not a connoisseur of sales techniques, I’ll briefly explain the concept of a negative sell.
You might think of it as reverse psychology. When someone tries to sell you something, particularly something of which you are skeptical, the encounter tends to follow a predictable script. They try to convince you to buy the thing while you list reasons for your skepticism. In the case of a negative sell, they confuse you by suddenly switching gears and asserting that they no longer want to sell to you. The idea is that you become subconsciously indignant and start to convince them that the sale makes sense.

“No by leverage” is probably the most powerful form of no that I’ve listed so far. I’d say it’s also the most perilous. This is where you say no by virtue of being able to create consequences for the person asking something of you.

To understand why this is dangerous, let’s consider the employee-of-the-month award in lieu of money situation again. You could exert some very self-defeating leverage in the situation by, say, hinting to the boss that you’ll get drunk at the awards presentation and make a ridiculous speech. Your leverage is the boss looking stupid. But to acquire it, you offer the disproportionately greater leverage of termination for cause. Better leverage plays take the form of stuff that doesn’t blow back on you.

As an employee, that power balance is intensely asymmetrical, and the scales don’t tip in your favor. The people in organizational positions above you hold all of the cards. Saying no tends to require outsize expenditures of what little capital you have.

The key is thus to acquire capital. As you’ve read here, that can happen in a variety of ways with a variety of ethical implications. You can do it by having great ideas or highly in-demand skills. Or you can do it with blackmail and trickery. But however you do it, you do it best by tipping the power balance scales in your favor and then judiciously parachuting out of suboptimal situations by saying no to them.

You need to avoid situations that impede your progress, which, beyond offers of carnival cash, might also include setups for failure or obviously subordinate assignments. Steering away from danger and status reduction is an art. Once you’ve worked your way up into the organization, a lot of this is done by maneuvering idealists into tactical locations. In the interim, you must be resourceful.

Control your situation via narrative-altering counteroffers. If your boss wants to bury you on some backwater legacy project, don’t accept that. But don’t resist by pouting or by kicking and screaming. Instead, offer something else. “I’d really prefer to see my current project through. What if I stuck with it 75 percent of the time and dedicated another 25 percent plus some overtime to getting someone else going on that project?” You’re not simply prevailing upon your manager’s sympathy or offering the unspoken threat to be disgruntled for a while. Rather, you’re implicitly expressing your preference, but doing so in value terms (value to the current project) and offering some actual skin in the game (your overtime). You’re changing the narrative—implying that your project will suffer without you and that the alternative project can still flourish with you in a reduced role.

The one word of caution here is to check your own ego. If you come up with an inarguably better idea and present “no by better idea” to your boss, he may simply look at you and say no anyway. Don’t blow your stack and sputter about his shortsightedness, like Andy Dufresne in The Shawshank Redemption calling the warden obtuse. Realize going in that there may be more at play than what happens on the surface and that superior arguments may not carry the day. If they don’t, it’s a data point.

Advancement

This chapter guides you from line-level programmer through avenues of advancement.

As I mentioned earlier, the first thing you need is your escape plan. Take a deep, sad sigh, resolve to leave your professional programming days behind, and pick out something else to do. Specifically, go job title/description shopping. You do not want to shop for the job of your dreams. Rather, you want to plan your road map away from delivery.

Here’s the best way to way to approach this. Look around you for opportunists not directly responsible for delivering anything. These will be folks with management or higher roles who do not guzzle the founder legacy kool-aid or worry about the company’s mission statement. Pick a few of these folks out that are not yet in the corporate stratosphere; this won’t work if you pick the CIO of a 40,000-person company. Study them a bit. What titles do they have? What educations? Past jobs?

Using these folks, build a composite of what you want to be doing in, say, five years. Then work backward. If you see a dev manager role five years in your future, what would three years in your future need to look like? And whatever you do, don’t answer something like that with “principal architect” or anything else that requires piercing the journeyman idealist veil. I said three years, not thirty.

On this point, I cannot overemphasize the importance of faking it until you make it. As an opportunist, you simply do not have time to manufacture all of the experience you seem to need in order to get these two roles in the next five years. Doing so would force you to wait a decade or more as people retired and you backed into positions by default. You’re going to need to jump way out of your comfort zone and you’re going to need to be okay with a bit of creative framing. To lay the groundwork for that, you’re going to need to use your current job as a gamification engine to earn all sorts of project management and consulting badges.

If you’ve bitten off more than you can chew, the solution isn’t to nobly offer your own head for chopping and cede responsibility. The solution is to maneuver an idealist into the firing line.

Just as you want to create success narratives in order to grease the skids of your ascendancy, you want to create failure narratives to prevent backsliding. If you take a project manager role and see that you’re off track for success on the new project, figure out a narrative other than “the project manager couldn’t get organized.”

I can get you started with two fairly obvious paths to pursue: consulting and project management. Both of these promise to let you step out of the software-engineer-I-through-VIII conveyor belt of pseudo-meritocratic turn waiting. You can step back in as the boss of the people doing that. If you can come up with other options that suit you better, then by all means do so. But I’ll proceed talking about these relatively standard options.

If you want to be a dev manager within five years, it’s probably safe to assume you should be a consultant or project manager within two or three. Now iterate a step back and think of what needs to be true in order for you to have those titles and responsibilities in two or three years. That should lead you to actionable tasks in the here and now. You’re ready to get to work remaking yourself.

At this point, I need to mention something absolutely critical. As a programmer, you are used to very objective, measurable criteria populating your resume. You talk to recruiters in terms of estimated proficiencies with languages, frameworks used, methodologies followed. Leave that world behind and start thinking in terms of narrative and what yours needs to be. You want to go from what you’re doing now to dev manager in five years via a role where your title is “consultant.” But when interviewing dev managers, organizations deal in narratives and feelings far more than you’re used to. Even if you have the title “consultant” but you’re just banging out code same as always, you’re still in better shape. It’s of course better to be doing actual consulting work you can speak of, but you can work a narrative around “consultant” that you can’t around “software engineer III.”

When you look down the road, imagine interviewing for dev manager. Imagine the experience you want to have going into that interview and contrive of ways to make it plausibly true. Then do the same for the immediate advancement and the consultant or project manager roles. Imagine the things you’ll be asked and the answers you’ll give. Then imagine how to make those answers as, well, truthy as possible.

Get yourself in a position, if only for a day, where you’re supervising something. Contrive of a way to be part of your department’s candidate interviewing process. Create some inane thing called the “committee for competitive salary review” and somehow get your boss to buy a lunch for its quarterly discussion of nothing of any import whatsoever. Make twenty-five Gantt charts. Seriously, make a list of these types of things that you want to be able to tell the next person considering you for a role, and go at it like you were gaming Stack Overflow for some arcane gold badge, upvoting long dead answers or something. You’re building the narrative that you’ll be pitching to your next boss.

With the seeds planted, it’s time to plan ahead to harvest. The things you’ve manufactured will sound contrived and hollow, so the first thing you need to do is come up with subtle ways of making them sound better. Then practice. If you can convince the people around you in your current group and company to remember a more impressive version of you, you’ll be in great shape for an internal transition/promotion or an interview with another company.

Here, you need to make yourself look big, as if a bear were looming nearby. Generalize singular experiences to multiple experiences without technically lying. You know people that do this sort of thing all of the time. Instead of talking about the one time you had supervisory responsibility, say instead, “Every time I’ve had supervisory responsibility for a team, I’ve…” If this were a US political debate fact-check, the panel would call it “true but misleading.” And that’s fine because “true, but misleading” is opportunist for “I’m about to get a better job.”

Turn single instances into generalities. “Every group I’ve managed projects for has done X.” Make unusual sound routine. “Every time I’ve found myself managing a group, we’ve done quarterly forecasting.” Speak flatteringly in upper and lower bounds. “I’ve never delivered a project that went more than 2 percent over budget.”

I’d like to briefly point out here that you don’t want to actually make stuff up. That can backfire. The trick is to do this without saying things that are technically untrue. Manufacturing pure BS is a higher risk, higher reward game, but in my experience, it alters the expected value equation against you. People are more likely to call you out or dismiss you if you make things up. So I’d advise a loose but consistent relationship to the truth.

This strategy will pay off for you. If you carefully build the resume of the person you want to be when you next interview, you will land those interviews. Learn from your mistakes, figure out the gaps in your knowledge, and correct them. Sooner or later, you’ll get that offer.

Now, given that you’ve audaciously worked your way out of your comfort zone and into a role potentially beyond your capabilities at the moment, impostor syndrome may kick in. You’ll look at your new responsibilities and think, “My God, what have I done?!” But when you feel outmatched, remember…don’t feel outmatched.

Whatever you do, accept more responsibility, authority, and organizational power. Always say yes to opportunity, even if you have no idea what you’ll do to make it work. You can figure out a way. Most ascendant opportunists are smart, and most programmers are smart. It’s likely that, if you’re the type of person who wants to read this book, you’re smart. No doubt you’ll be able to figure something out to get the job done, even if it’s not ideal.

Building a Composite—Developer Ubermensch

Developer opportunist trait 1: they don’t spend all their time programming

The first property of the developer opportunist is that he recognizes writing code is a means to an end. Whatever that end may be, other means matter as well, and those are also worth seeing to. Writing code may be an enjoyable means to an end, but it is not an end itself. Even in my own quest for independent wealth that allows me to program to my heart’s content, it’s not really the programming I love as much as it’s the tackling of projects.

Developer opportunists do not allow this to happen. John Sonmez summarized it nicely: “You should definitely expand your abilities beyond just programming code and become a more valuable software developer by adding communication skills, architecture, and true software development expertise into your arsenal.”

Developer opportunist trait 2: they market themselves

Developer opportunist trait 3: they create content

The people to whom I spoke create all kinds of content for the consumption of others. Some write books, some make videos, some blog, some create training courses.

Creating content requires a great deal of effort, but it repays that effort by offering one of the most effective marketing opportunities imaginable. Creating content positions the creator as an expert on the subject. Make no mistake. The primary benefit of this content is rarely the actual royalties involved. James Grenning said that his royalty check from his well-known book “is not a lot of money.” But he also said, “Test-Driven Development for Embedded C is my main marketing tool.”

Developer opportunist trait 4: they are literal opportunists

Developer opportunist trait 5: they manage the pipeline

Developer opportunist trait 6: they have options

Developer opportunists recognize this reality subconsciously, if not consciously. They figure out that they need to spend somewhat less time programming and somewhat more time making sure they have options. Typically, this takes the form of marketing that I mentioned in the chapter. As John Sonmez points out, and as I can echo, marketing himself generated all sorts of job and consulting opportunities that didn’t previously exist.

The Developer Ubermensch is a Businessperson

As long as we fetishize unmarketable levels of knowledge of arcane technologies, we will continue to be managed. When we start geeking out not about tech but about delivering value and participating in commerce, we will flip the script and start to manage businesses.

We = devs

Developers Becoming Efficiencers to Take Control

Our value proposition is that we provide expertise in efficiency. “I help you have more time and money.” Or, at the risk of sounding a tad overly dramatic, “I help raise the standard of living.” Sounds pompous, but that’s what we do—eliminate jobs of drudgery and create ones of knowledge work. I’d say that time and standard of living as by-products of our work put us on par with those offering services around rights and health.

As a developer

Anatomy of the Efficiencer Firm

Here are my principles:

Efficiencer firms are bootstrapped and self-sufficient, meaning they’re profitable from the outset.

The members of efficiencer firms are partners. All members execute on the organization’s value proposition and have skin in the game. Instead of employing pragmatists, they delegate to vendors.

They don’t rely on absurd practices like job interviews to scale up their delivery capabilities. That happens via trial, recommendations, and networking.

Everyone’s contributions to the organization’s profits can easily be measured. They only grow as long as that remains true.

In short, the firm is comprised of opportunists. Anyone who would normally be a pragmatist is instead a vendor. This in turn eliminates the need for an overenthusiastic buffer of managers and senior people.

The key is getting folks to believe that just because we’ve been doing something for a while doesn’t make that something inevitable.

Becoming an Efficiencer and Joining an Efficiencer Firm

I firmly believe that we need to start thinking of ourselves as automation professionals—efficiencers. Learning to write code alone does not come close to equipping us to deliver on this charter. As I said earlier, you also need to understand marketing, sales, operations, and finance. At least, you need to understand these things well enough to delegate them.

Now that you’d have a money-making opportunity to chase with your automation, you could learn to write code toward that end. By all means, learn to write clean code by studying software craftsmanship principles. Learn that you need to keep design flexible because your next client will almost certainly want some changes. Learn to partner up with other efficiencers to get the job done quickly. Learn all of the traditional boot camp stuff. Don’t learn any of the O-notation stuff. You can always pick that up if you become an efficiencer whose client needs a string manipulation library sped up slightly.

Once your product is built, learn to sell it. Learn to make those calls and deal with prospects. Learn to use a CRM and do enough marketing to be dangerous. Learn to give webinars. Learn that if you build it, they won’t necessarily come.

And then, maybe make a sale or two. Learn to keep some books, pay subcontractors and such. Learn a bit about taxes. Perhaps most importantly, learn to analyze your operating costs and revenue to see if you can sustain or grow with your product as-is or if you need to do some retooling.

Finally, gain some experience with the operational aspects of working with a client. Do you deliver and call it done? Do you maintain it and perform feature requests? Who handles bug fixes? What do discussions about the end of support sound like?

Concrete, Immediate Steps You Can Take to Become an Efficiencer

What you can do now: politely end interviews that involve trivia

What you can do now: train yourself as an efficiencer at your current job

So, first things first. Stop geeking out about how you could use some JavaScript framework invented yesterday to automate what Bill is doing. And stop diving in or volunteering to do it just because it’s there and you can. That’s the sort of non-strategic, subordination-inviting behavior we need to avoid, collectively.

Don’t volunteer anything at first, in fact. Just get practice observing what people are doing and assessing how difficult and expensive automation might be. Learn how to do gap analysis—find situations where actual performance falls short of what’s desired. Do a gap analysis that focuses on automatable activities. This could mean thinking about Bill and his manual data entry or the gigantic defect tracking spreadsheet that the QA department maintains. It might be something as simple as people routinely printing out emails and handing them to one another instead of using email. Remember, your goal isn’t to find things that you can write code to solve. Your goal is to find where you could eliminate inefficiencies with automation.

What you can do now: avoid draconian non-competes and other nasty corporate policies

What you can do now: stay away from big companies

What you can do now: realize that the tech giants aren’t that great

What you can do now: find a job that gets you out there

What you can do now: apply at non-traditional companies

What you can do now: apply at smaller app dev shops

What you can do now: start working from home

What you can do now: start a blog

What you can do now: start the side hustle. Like, now.