Clone Yourself: The Step by Step Guide to Finding Freedom at Work

(This article was originally published as part of PragPub)

Since the release of The Passionate Programmer, I’ve been thinking a lot about goals. The book is about how to build a remarkable career in software development. But, I ask, what does that lead to? Having a remarkable career sounds like a pretty good goal, but is it?

In a job I had seemingly several careers ago, I was a Six Sigma Blackbelt. That job was remarkable in that I had arguably the lamest title possible in any industry other than Master Blackbelt, which was the “promotion” from Blackbelt. Six Sigma is one of those methodologies that starts life as a good idea and, by the time it reaches anyone who has to actually do anything, is indistinguishable from self-satire. But, despite its amazingly bad implementation, I still managed to learn some pretty important lessons from this data-driven quality management approach. One of the simplest of such lessons is that we humans often confuse requirements with design. By that I mean that when we think we’re stating requirements for a system, we’re actually designing the system and stating our design assumptions.

A programmer acting in the role of a customer, for example, might say that a web system needs to support distributed session replication. That way if an application server dies, the user’s session isn’t lost. But that’s not a requirement. It’s an implementation approach. Other approaches to the real requirement (sessions don’t die when servers do) might include storing sessions in browser cookies or in a database. Distributed session replication is, in fact, probably the most complex and expensive approach we could design for this requirement.

When you’re doing something important, you can’t just take requirements at face value. You have to determine whether they’re actually requirements at all.

So, remarkable career… is that a requirement or a design assumption? I think it might be a little of both, depending on the audience.

What We Want

If having a remarkable career is not the real goal, then what is? What goal do all of us programmers seek? Money? I don’t think so. We’re creative people. We devote too much of ourselves to this craft for it all to boil down to cash. Money is important but, again, I think it’s part of the implementation of the real goal.

Recognition? Again, that’s a kind of currency. On a small scale, it buys you respect among your co-workers and peers. At a large scale it does the same industry-wide (or beyond).

So if cash and recognition are both types of currency, what do they buy us?

I’ve come to believe that what we all want is freedom.

Freedom from What?

You might say freedom is also a currency like money and recognition. But it’s hard to break down any further.

So what do we want freedom from or for? As creative people, I believe that most of us are ultimately looking for freedom to work on what we believe is important and to do it in a way that we believe to be right. In short, we’re looking for the freedom to be creative.

Early in our careers, we move from low-level jobs toward higher-level jobs partially for the money and recognition but largely for the ability to make decisions.

Let’s not confuse the issue — decision-making power and freedom are not the same thing. That’s where many of us go awry. Management jobs are effectively decision-making power wrapped up in a seemingly neat little package and hung in front of us like piñatas waiting to be shaken until the candy comes out. But this is the kind of candy that tastes OK but might make you really sick depending on how your immune system responds. It’s definitely not for everyone.

And it definitely doesn’t amount to freedom. By taking on a management job you’re assuming a greater amount of responsibility but relying on a bunch of other humans for your success. As an outside observer, it might look like an easy job, but experience has shown me that any time I have to rely on a large number of people to do even something trivial, it can feel like more work coordinating, motivating, and steering than just doing all of their jobs combined. (I did say “feel” — it’s not really more work. You get the idea.)

Of course, there are ways to manage teams that don’t eat up your every waking hour. And the manager’s solution to this problem leads us down the same path we must traverse to find freedom in our careers generally.

It’s Not about the People, Stupid!

Conventional wisdom says the following about people and teams: hire the best, get out of their way and let them do their jobs and you’ll achieve the greatest success. The more skilled and talented your team, the better chance you have of exceeding expectations. Hire inexperienced people and pay them low salaries, and it’ll be an uphill battle.

That’s what they say anyway.

As much as I’d love to believe this (it makes us feel good to believe it, doesn’t it?), my experience as a manager says otherwise. I’ve taken a chance on people I thought had potential but not enough experience or depth and been blown away. I’ve hired the smartest, brightest people and been completely underwhelmed. In fact, in my experience, this occurs almost frequently enough to call it typical.

I was recently reading Michael Gerber’s The E-Myth Revisited and came across a piece of wisdom which shone a light on this paradox. The E-Myth Revisited is a guide for entrepreneurs with the goal of leading them away from the classic, constantly repeated problems that cause the majority of new businesses to fail. In the book, Gerber lays out a methodology for designing a business as a system as opposed to just a new job for the business owner.

When you look at a business as a system, it significantly changes your approach to managing that business. Systems are consistent and are comprised of repeatable processes. Systems are measurable.

These aren’t surprising ideas. What was surprising to me was that Gerber recommends hiring the least skilled person possible for each job in your business. When I read this I did a double-take. I was sure I had misread it. But no, I hadn’t. And the reasoning is brilliant.

You don’t hire the least skilled people simply to save money. Sure, the tactical advantage of saving money is great, but you hire the least skilled person to fill each job so that it forces you to perfect your system and to not rely on the flakiness of human whim or mood for the success of your business.

If you hire low-skilled labor for each job in a business, the only way to survive is to create repeatable, measurable processes for each position so the low-skilled laborers can follow your directions, approximating the type of job you would do if you were doing it yourself.

The Low-Skilled You

The Passionate Programmer advocates planning and executing your career as a software developer as if you were an entrepreneur running your own business with you as the product. The parallels are strong enough that it’s more than a metaphor — your career literally is a business. Most of us just don’t think of it that way.

As I reflected on E-Myth, I naturally started to wonder how to apply its lessons to the business of one’s career. What would it mean to hire low-skilled replacements for me, the business owner (of my career)? Does this idea apply at all?

My conclusion is that it does — and very well.

Dissecting the Company that Is Yourself

As you begin to think of your career as a business, there are two ways you can deconstruct the task. The first is to think of it as a process, as I lay out in The Passionate Programmer. The process might look something like this:

• Choose Your Market. Choose both the technology and the domain you are going to invest in. Don’t forget that there’s more to professional life than just which programming language or framework you are going to learn. Working in the medical domain is vastly different from working on a personal productivity suite, for example, and provides different challenges and learning opportunities.
• Invest In Your Product. Now that you know what you’re going to do, make the investment. Develop deep expertise in your technologies of choice, master your chosen domain, and learn the business models of that domain.
• Execute. Perform like a star, optimize your workflow, minimize your defects, anticipate your customers’ needs.
• Market. If you have a great product and don’t tell anyone about it, you’re robbing them of the opportunity to benefit from it. You are that product. You have invested and executed and made yourself remarkable. Your employers and customers (or potential employers and customers) need to hear about you.
• Refresh. Maintain your edge. Repeat the process. Constantly evaluate yourself and your position in the market as well as your long-term goals. Are you on the right path to realize your life’s goals?

While this is a coarse-grained view of what the career management process might look like, at this stage it is helpful to break it down in a different way: as a set of different jobs. If you were running a multi-person company, you might structure this as an organization chart.

Organization charts serve two purposes. The first and most obvious is to show how an organization is structured. This can be helpful in a big organization but it obscures the more important purpose of an organization chart: to catalog and define the jobs required to make an organization run effectively.

Breaking down your own different sub-jobs into an organization chart can help you crystallize the various tasks that go into managing your career. Here’s an example that I might brainstorm for myself:

• Research & Development
• Frameworks
• Languages
• Domains
• Operations
• Admin (email, expense reports, status reports, etc.)
• Programming
• Testing (non-TDD)
• Support (production issues, bug fixing, etc.)
• Finance/Budgeting (money, time, passion as currencies)
• Marketing
• Customer Relations
• Identity and Branding
• Communications

Create a System

Now imagine your salary is magically ten times what it is today. You’re accountable for the same results from your work. You just get paid ten times more to get the work done. And on top of that you’re given total autonomy to get your work done as you see fit.

Obviously one option is to keep slugging away, putting in your 40 to 60 hours per week but getting paid ten times more for it. Another option, however, would be to see if you could use some of that money to buy yourself some freedom. What if you could hire a few part time employees to do some of the jobs we identified in the previous list? What if you could pay someone else to do all the stuff you hate about your job, leaving you to focus on the work you love?

And what if the people doing each of these jobs was more focused on them than you ever are? Might they even be able to do a better job than you usually do?

Here’s where the magic starts. Take any one of the jobs from the previous list and start listing its responsibilities. This is a job description you’re creating so you can hire the replacement for this part of your professional life. What would the ideal candidate get done? What would his or her typical work day consist of?

If you had absolute freedom to devote yourself to this one aspect of your career, what would you do every day with it to make it excellent?

What starts as a job description can quite easily become a task list and ultimately a how-to manual for the job. Sure, for a creative person like yourself a lot of the overall job is informed by split decision making and your on-the-spot creativity. But as you dissect your career management system into a set of clearly defined sub-jobs, it is increasingly possible to codify just about every aspect of what needs to be done into a neat daily, weekly, monthly, and annual task list.

There may still be parts of each sub-job that need to be left to the creativity of the individual doing them. Your goal is to eliminate as many of these as possible. The rest, you can handle as CEO of your career.

Do this with all of the sub-jobs and you have created a career management system. A clearly implementable strategy. There’s just one thing missing.

Make It Measurable

In software projects, we have learned over time that the best way to know when you’re done with some code is to put a test in place for it. If the test passes, it’s done. If the test doesn’t pass, it obviously needs more work. Each complex requirement is implemented in terms of a set of tests. If all of the tests pass, the requirement as specified “works.”

Many of us in the software industry use a technique commonly called Test-Driven Development to manage this process. Test-Driven Development is iterative and starts with the tests. You write a failing test; then you make it pass.

Tests (or, to be exact, their assertions) are discrete measurements. We take a reading and if the result is correct we register a successful assertion. Each test case is a collection of the measurements recorded for each assertion, and each test suite is a collection of those test cases’ aggregate readings. So as software developers, we’re very much used to using measurement systems to drive complex processes and products.

Each task for each sub-job in your organization chart should be measurable in this same way. What makes your customer relations “job” successful? What are the big measurable outcomes of the job? An example might be performance or survey review ratings from your customers. What are your goals for those measurements?

As the world’s leading expert in managing your career, what do you believe are the measurable components that would contribute to that big measurable outcome? Are these components atomic and easily measurable? If not, all you have to do is break them down further and recurse until you hit the truly measurable part.

As a Six Sigma Blackbelt, I used a technique known as “Quality Function Deployment” (QFD, for short) to formalize this hierarchical decomposition of measurement. I recommend learning about QFD. It’s an excellent planning tool. Entire books have been written about it, so I’ll avoid going into any more detail here.

Automate and/or Outsource (to Yourself?)

How do we prevent our team mates (and ourselves) from checking in code which breaks the build? Continuous integration.

How do we ensure that those performance enhancements we made to our Web application continue to be effective and don’t regress into an unusable state? Web application monitoring and alerting.

How do we make sure we have decent test coverage on our production code? Code coverage analysis tools.

We as technologists know that when something is important, it needs to be automated. Automation saves you time, but that’s not the point. Automation also makes things… automatic. If something must happen in a system, you should never rely on your memory. Instead, you should automate either that task or a reminder and a check for the task to ensure that either the system or a person takes care of it.

In Six Sigma parlance, this is known as the “Control phase” of a project. The Six Sigma process includes a host of tools and techniques to define problems, make them measurable, analyze them, and make improvements or designs. But the finish of every Six Sigma project is to put a control plan in place to ensure that the measurable outputs of a process stay within an acceptable range of performance.

Running a business is no different. If you were in the business of nuclear power generation, you’d damn sure have a system in place to measure your power plant’s outputs. If you were in the business of flying airplanes, you would certainly learn how to read the relevant measurements from the airplane both in real time and in after-the-fact analysis. And you would put a process in place to make sure you read, interpreted, and reacted to those measurements.

This brings us to the control phase of our career management system. How do we actually put all of these jobs into motion, and just as important, how do we measure their output? Automate what can be automated and outsource what can be outsourced.

Many of the tasks which eat up your time can be automated. When looking at your daily work-life as an amorphous blob of responsibility it’s hard to see them. But as granular, measurable tasks you’ll find that tools can be put in place to automate them. Status reporting, customer communication — even some programming tasks can be automated when you can see them for their sometimes-robotic nature.

And, even if you haven’t magically gotten a 1000% salary increase, some of the jobs or tasks you have defined can be outsourced. One option is low-cost programmers. Do you work with junior programmers, interns, or outsourced developers from lower-cost countries? If so, chances are you arrogantly don’t have much faith in their ability to perform any of your job at your performance level. And as a whole, you’re probably right.

But give a passionate intern a clearly defined task with a measurable outcome (and tell them what that measurable outcome is), and you will often be very pleasantly surprised at the result. The same goes for junior programmers, offshore outsourcing partners, and others you may be working with even today.

You might also actually experiment with outsourcing your daily work. I’ve recently experimented successfully with two companies which provide offshore virtual assistance for low prices. After a few bumps in the road, I’ve had them do everything from scheduling doctor’s appointments to detailed research for keynote presentations and a writing projects. Six dollars per hour and some creative delegation has saved me collectively a great deal of time, money, and most important, energy.

If you can’t automate a task and you don’t have the resources to outsource it, your last line of defense is to outsource it to yourself. This may sound pointless, but it’s not. You have now clearly defined each job in your enterprise and have decomposed it into a set of measurable tasks. Even if you have to do the tasks yourself, if you have an automated measurable system in place to make sure you do them coupled with concrete deliverables, you’ll find that you do the tasks better and faster than you ever did before. You are, in effect, not the same worker completing the work.

Freedom

Test-Driven Development frees us to change our software without fear. Continuous automation frees us to deploy our software without wondering if it’s horribly broken.

Business management systems free business owners to focus on the parts of the business they love.

Hopefully this little thought experiment will bring you closer to that same kind of freedom. And hopefully that freedom will make you happier.