I've mentioned this before, but I'm a big fan of Eric Dietrich's blog. He focuses in particular on the topic of how developers can transition to becoming consultants. This post, in particular, struck a chord with me.

Now, I hold that software development is a fantastic career. You get to build cool things and solve challeging problems every day. The money is very good: I can't speak for the rest of the country, but in Minneapolis, the salary for a developer right out of college starts around $60K, and almost doubles over the next 8-10 years. (BTW, this is a strong motivator to job hop. The salary you can command on the open market goes up by easily 10%-15% per year during the first 5 years or so of your career, and raises on that level are simply not in the cards at most companies)

The only problem is, it seems like developer careers have a little bit of a glass ceiling. Once you've hit that 10~ish year experience mark, there's not all that much room for career growth. Developers with 30 years experience seem to do mostly the same jobs as developers with 10. Having just hit this point, I'm looking around and thinking to myself "Where do I go next, if I want to stay ambitious?"

This is one of those posts where I don't have a clear conclusion in mind. I'm very curious what you think after reading this, if one path sounds better to you than the rest. Here are some possibilities I see, in no particular order. Some of them are mutually exclusive, but certainly not all of them.

These thoughts aren't entirely my own. I'm digesting a few ideas that Eric proposes in more detail in different blog posts. I'll try to provide relevant links.

Satisfaction

"Dude, seriously? Breaking the six figure barrier doing something you enjoy, without working yourself to death? I would kill to have that job. Be content; it doesn't get any better than that."

That's legitimate, and I think it contains a lot of truth. Certainly, I don't need to achieve any further career achievements to be happy. I think many developers hit a stable point in their careers, and rest on their laurels. They still pursue goals and ambitions, but they do so outside of work. Or they stay put in one organization, and chase after incremental promotions to titles like "Developer IV", "Senior Developer", "Principal Developer", or "Software Architect". The problem is, the people I've met who have done this don't seem terribly happy with it. It seems like a universal truth of life that it's impossible to stay still. If you're not moving forward, you're backsliding. This is particularly true in software, where specific technologies seem to have about a 5-year half-life before they slide into obsolescence. It's not all that unusual to meet a developer who has grown into an exalted title by virtue of long tenure with the company, but who just isn't very good. That seems like a sad way to go.

Work on becoming the alpha-top-dog techno-master developer

The amount I know about the world of programming is dwarfed by the amount I don't know. If laurel-resting is a bad way to go, how about the opposite? Double down, and keep learning, learning learning. Become the technical master of many sub-disciplines. Contribute to open-source projects. Become the acknowledged all-around technical expert, with the assumption that rewards and prestige will inevitably follow from such mastery.

Learning enough to stay on the cutting edge doesn't seem to lead to higher pay, necessarily, but it appears to give me a lot more options. It also seems to create a natural gravity which pulls me towards situations where I am working with other people who are always learning and who enjoy their work.

The problem I see with this one, is that it has low returns beyond a certain point. It's good to know the current technologies, and to have a wide enough skillset to do whatever I set my mind to. But gaining enough technical mastery for it to translate into any sort prestige (e.g., being a big name in open source projects) puts me in competition with many people who have far more talent, time, and energy for it than I do. The prestige earned this way is not really prestigious among anyone except my fellow developers. It seems like a few programmers manage to get so high in the realm of pure technical mastery that they are rewarded with wealth and book deals, but it's only a small set of household names: The Jeff Dean's, Jon Skeet's, and Linus Torvald's of the world. In other words, trying to bust through the glass ceiling this way strikes me a lot like trying to be a football star. It's unbelievably competitive to make it to the top, and anything less than the top isn't a lucrative career; it's just a game.

Strike a balance

Okay, maybe both those extremes aren't great ways to develop a career? How about some in-between sort of moderation? Stay interested with side projects and classes, but don't kill myself. Cultivate satisfaction. Collect those vanity promotions for what they're worth, but without buying too much into them. Change jobs reasonably often, enough to keep from falling into a rut and getting bored. I don't think it's a bad option at all. But at the same time, it seems like it would be better to stay ambitious. It seems like human nature that we are better off when we feel we're working towards some kind of goal, even if we're just greyhounds chasing a stuffed rabbit (Those greyhounds look MUCH happier running after that rabbit than just staying in the kennel).

Go into management

This seems like the default corporate narrative of career progression: I start out at the bottom as a ditch digger, and my reward for being a good ditch-digger is to become a boss of ditch-diggers. I no longer have to break my back in the ditches, I just watch and shout orders at other people. In a couple more promotions, I no longer even need to spend time around ditches. I just sit enthroned in my air-conditioned office, and dispense orders to lesser ditch-digging bosses to spread to the actual ditch-diggers. Part of the theory is that, if I am a top-notch ditch-digger, the way I can work best is by directing less experienced ditch-diggers. The traits that made me successful can be spread across many people, and increase all their productivity. But just as much, it seems to function as a reward system, sort of like a heavenly reward. It's a promise to all ditch-diggers that a paradise awaits them, a job of ease and high pay, if they faithfully pay their dues at the bottom.

I don't think management is a bad career path at all. But it seems that this narrative above is not rooted in reality, and it's corrupting to the extent that it is real. Sometimes management positions are given to programmers as a reward for a job well done, but this is usually considered not to be a good idea. It can easily be a double loss to the company. They lose a good programmer, and they gain a bad manager.

Now, I don't think moving to management is necessarily a bad option.... For people who are either talented at management, or able to learn. Heaven knows, good managers are rare, and the need for them is immense. But management is a very difficult skillset. It's an entirely different job, and being a great developer doesn't necessarily translate into being a great manager. I have a sense that I might be interested in giving management a shot if just the right opportunity came along. But it would be a leap into the unknown. There's a great risk that it would end up being a small step up in autonomy and pay, but at the cost of doing a job that I'm good at and I enjoy. I'd need to go into it being very conscious of that risk, with a good exit strategy in case it didn't work out.

Go for a Tech Leadership position

A common way of organizing software groups is to have a bifurcated management structure. Rather than simply having the whole group report to a manager, they report to two people: A manager and a technical lead. The tech lead codes part time, but he also handles a lot of task delegation. He has the final say in decisions regarding software architecture, new technologies to adopt, or team-wide coding practices. He is usually the guy who gets on the phone with the big customer whose system is crashing from a mysterious bug, and the guy who is in the office at midnight gluing Humpty-Dumpty back together after a botched production release.

To me, these positions don't hold a whole lot of appeal. In theory, they offer a way into a management-level position while still coding. The reality I've seen, is that the tech ends up being subordinate to the manager, even if there's no direct line in the company org chart. He ends up taking on much more responsibility, but seems to gain little in the way of additional pay OR authority to make strategic decisions.

Chase Freedom

As I think through all the possibilities, it becomes clear to me that more money isn't really a goal for its own sake (I mean, I wouldn't say no, but if I can't be happy with what I have now, there's no amount I would be happy with). Neither is the privilege of ordering people around. But what I would like to work towards is.... It's something a little hard to put into words. The best word I can think of is autonomy. By this I mean, a job that involves making meaningful decisions, rather than just bringing other people's decisions to life. As I see it, many but not all programming jobs treat developers as a sort of fungible resource. Somebody decided that they needed 3 developers to make this project work, and any of the millions of developers in the world could be dropped into those 3 slots, provided they have 5+ years of [Technology X] experience and are reasonably competent. The other kind of jobs are one of a kind: I'm trusted with making and contributing to broad strategic decisions, because of my particular reputation, experience, and relationships. I'm no longer in competition with everyone in the world with a similar skillset, because this particular job is unique enough that if anyone else was in it, it would be a different job. If it were art, it would be the sort of commission of "We'd like to have a Stiennon for our collection", rather than, "We need some art on this wall. It should be about four feet high, and blue."

A related sort of freedom I'd like to chase (which might even be the same thing, viewed from a different angle), is the freedom of being accountable to a customer, rather than a manager. This is the freedom where my success or failure is judged on the results of my work (Useful software created in a timely manner), rather than the method of doing the work (I show up at 8:00 every day, attend meetings, submit accurate status reports, and look earnest and business-y whenever the boss walks by).

Find just the right organization

The dichotomy between strategic and non-strategic jobs really isn't as stark as I made it sound above. Many people (including people who ought to know better) view software projects along the lines of "A team of business experts makes all the important decisions. Then, they toss it to a team of software architects to make all the technical decisions, and then they toss it to a team of code-laborers to do the actual coding.

Software built this way is doomed to fail, because software is intrinsically creative. To us engineers, this is as absurd as trying to write a great novel this way: At Simon Schuster, a committee of marketers, editors, and publishers draw up an outline. Then, they send it to a small group of experienced authors who break it down into a paragraph-by-paragraph flowchart and a bunch of style guides, who then give it to an army of temps to actually write the thing.

Most companies don't go to this extreme. Most of the ones that do don't survive very long, unless they are sitting on such a fountain of money that it doesn't matter how wasteful they are. Developers are usually offered a reasonable amount of decision-making authority over how the thing gets built. But, at most organizations, we don't have too much input into what gets built.

It seems like it shouldn't have to be this way. Lawyers are professionals who bill by the hour for their work, but they seem (from my outsider's perspective) to manage to be self-managing. Law firms have partners and associates, but they don't have lawyer-managers who have MBA's rather than JD's, who get to order the partners around and collect status reports from them. The same goes for doctors: The upper echelon in a hospital seems to be made of senior doctors, not a hierarchy of medical managers who diagnose and decide which procedures to to use, but who never actually practice medicine.

So, one option may be to continue to switch jobs fairly often, until I manage to find some sort of organization which treats programmers as problem-solvers, not just implementers. This could be a big organization like Google, but more likely it would be on just the right team at a small-to-medium-sized software-focused company.

Consult

If I can't find such a company, why not make one? I could strike off on my own, starting my own consulting business. This would certainly give a lot of autonomy.

I see many obstacles in this path, but it could also be an awesome one.

• Owning a small business looks hard. Some advice I've seen on it has been a long the lines of, "If you're not willing to work 14 hour days to hustle your way to success, don't even try". I doubt this is entirely true, but I do think it reflects a reality that a small business will eat your life if you let it.
• It seems difficult to get from point A to point B. It would be going from "I am really good at coding and can build anything you ask me to build" to "I have experience using software to help you solve these kinds of problems". Most day-to-day jobs as a programmer don't seem like great preparation for doing this sort of thing. It seems difficult to go from a job executing bite-sized Jira tasks, with no decision-making horizon longer than the end of the 3-week sprint, to genuine strategic consulting.
• I don't have much idea of how to both locate people who have a use for my skills, and persuade them that they do indeed have a use for my skills.
• There are lots of traps. It seems like a lot of companies use language that indicates they are seeking out consultants, when they are really looking for well-paid temps. They are in search of development resources to drop into one of the three empty slots on that project.

But, these obstacles may well be surmountable.

• I have the good fortune of knowing several people who own independent consulting firms and even small businesses, and manage to do it without ignoring their families. It appears to take a steely-eyed level of courage sometimes, but they manage to do it.
• When I look at my career more carefully, I have plenty of experience solving people's problems, not just turning specs into code. It's just a different mindset.
• I would be left kind of high and dry if I quit my job tomorrow and declared myself a consultant. But I know that's not the only way. I've read a couple articles that have suggested that the best way to transition to consulting is to build your practice through moonlighting to the point that, all you need to do to switch to doing it full time is to stop turning down work. The path to get there looks complicated, but I can certainly get behind that incremental approach. The thing to do is probably to focus my learning onto topics which I could potentially consult on in the future, and seek out future jobs which could be good stepping stones. It's probably also good to build up my reputation by networking, attending meetups.... maybe even start a blog :)

Pursue a remote-work job

This seems to be a different way of chasing freedom. It doesn't necessarily lead to the ability to make strategic decisions, but it does offer the freedom of being out from under the direct eye of a manager. I see this as being desirable for two reasons.

First, it's more productive. I once had one remote-work project which lasted a few months, and I remember it being one of the most pleasant, productive work experiences of my life. It helped being free from the distractions of an office. But even better was the freedom to just move around. It was energizing to be able to take breaks between sprints of work that were real breaks (No worries about looking like I'm goofing off at work). It was tremendously helpful, if I wasn't having a productive morning, to get up, go for a run, and try again, or to be able to move to a coffee shop for a change of scenery.

But even more than this, it changed my mindset. I think at an office, it's easy to start to feel like I'm doing my job just by showing up. I have a list of demands, along the lines of "Show up for work at 8:00, wear proper business attire, attend these different meetings, submit the proper status reports". If I just go through these motions, I can have a feeling that I did my job for the day, without accomplishing anything at all. With remote work, there are no such illusions. The only thing that distinguishes remote work from no work at all is my results.

Conclusion

Reading over my own thoughts, my suspicion is that "Consultant" is probably the ideal endgame. I can see that I have quite a bit of work and learning to do to get there. However, finding the right company or working remote both seem like they could be good stepping stones towards consulting. In addition to its own merits, the "Right Company" option would build up my level of experience solving strategic problems in that company's domain. For example, if they make software for marketing, it would be a great way to build experience answering the question "How can I help marketers use software to be more effective?". Really, what I'm calling "The Right Company" option could be rephrased as "Company where I can function like an internal consultant". And in a remote work job, that results-oriented mindset is not just good for its own sake, but it seems like the ideal mindset to learn for consulting. Remote Work would also add an extra hour or two back to my day which normally gets eaten by a commute, which could be helpful for moonlighting.

I am very interested to hear your thoughts, ideas, or advice.