Software Development Career Paths: Up or Out?

Continued from Software-Development Career Paths: Organizational Quality.

Moving Up
For this option, mostly I can only repeat the traditional oft-heard worries: your tech skills will get rusty and you'll be stuck in middle-management forever.

On the other hand, I don't think developers who like to code should dismiss moving up out of hand. If you get a chance, try it. Who knows, you might like it.

There's a nice discussion about staying technical as a manager over on Rands In Repose: Technicality. If you keep your technical skills sharp, then hopefully if it turns out that you hate being a manager, you can still go back to being a developer.

Moving Out
Lately I have a new perspective on moving out, thanks to the software craftsmanship movement. How many books and articles have you read lately that use the word "journeyman?" There's a reason the word "jouney" is in there.

In parts of Europe… spending time as a journeyman, moving from one town to another to gain experience of different workshops, was an important part of the training of an aspirant master. [Wikipedia, Journeyman]

Although I don't think it's a perfect book, Apprenticeship Patterns by Dave Hoover and Adewale Oshineye is currently the best reference I know for thinking about different ways to approach a career as a software craftsman from the perspective of an individual developer rather than that of a manager.

Another Option: Stay Small, Maybe Even Really Small
Keep in mind that not all organizations force you to choose between coding and managing. Smaller companies often don't have "Eiffel Tower corporate hierarchies." If you're moving around, you might find more satisfaction sticking with smaller companies, especially since that way you're more likely to personally provide value to customers, as described by Cameron Purdy in his great article Eight Theses.

Don't forget that you can go it on your own. Recently at DDD8, Liam Westley gave a talk about owning your own software development company. Of course, the talk assumed that you already "have commercial ideas, clients, or sales leads." I have no idea how to get to that point, but the fact that Liam was there giving the talk is a reminder that people actually do manage it.

Staying Motivated
Whether you literally become a journeyman by moving among companies or you stay for a long time at a single company, if you don't want to move up, you may need to look for non-traditional ways to keep yourself up-to-date technically and otherwise generally motivated, especially if you find yourself occasionally working at places that treat you as an interchangeable coding machine.

Apprenticeship Patterns gives some ideas about how to do this. Obviously, there are always things like learning new languages, participating in either local or virtual developer communities, and in open source projects.

Interestingly, all of those things follow a general leadership-followership pattern that's pointed out in The Art of Followership:

[An] example, which is becoming increasingly common in developed countries, occurs with employees who have extensive professional education. These employees can often perform their work assignments without relying on technical guidance from their hierarchical superiors. Their education often includes a strong socialization component, instilling in them a desire for autonomous, self-controlling behavior and the tendency to look to their professional colleagues for support and recognition. This often occurs with university professors who are highly educated and tenured. These individuals often view their university as a place to practice their teaching and research skills with little interference by administrators. They work with and obtain feedback from colleagues, they read academic journals for up-to-date information on their field, and they derive intrinsic satisfaction from their publications and recognition at academic conferences. Similar tendencies exist in firms that provide consulting and accounting services. In these instances, professional education and socialization can replace or substitute for a leader's direction and supportive behavior. [Chapter 3, Three Perspectives on Followership by Howell and Mendez]

I don't think the software development profession has necessarily quite reached this point yet, but it's an interesting perspective to keep in mind. Ideally, you can get "support and recognition" from your "hierarchical superiors" as well as your peers. Anything else is draining. However, in a pinch, don't forget to look out as well as up to get the sustenance you need to nurture your craft.

Software-Development Career Paths: Organizational Quality

A developer-friend of mine, Tom Wessels, recently asked the computer-age-old question:

I just want to be a programmer. But can I?

He follows up the question with a great quote from the great and still-relevant book Peopleware by DeMarco and Lister, which points the career path encouraged, or at least tolerated, by many organizations: If you're not on your way up, you'd best be on your way out.

To be fair, DeMarco and Lister follow up this description with a contrasting one, "The Mentality of Permanence:"

Over the years, we have been privileged to work and consult for a few companies with extraordinarily low turnover. You won't be surprised to learn that low turnover is not the only good thing about these companies. Indeed, they seem to excel at many or most of the people-conscious qualities discussed in these pages. They are the best…. In the best organizations, the short term is not the only thing that matters. What matters more is being the best. And that's a long-term concept.

DeMarco and Lister go on to describe ways in which these companies invest in their employees, fostering a culture of learning, professional improvement, permanence, and organizational excellence.

To answer the question, I think you need to look at your career along a few different dimensions. One of which is the quality of the organizations at which you will work.

It might be possible, to get a job at one of these "best organizations" and be comfortable for some time with one of the options Tom presents:

You reach a point where you just accept that you're at a good company, you get to write code in a somewhat enjoyable fashion, and you leave it at that.

Hooray! Yes, I think it would be good for everyone to at least have that option for a few years at some point in their careers.

But a couple things stand in the way.

First, it can be hard to get a job at an organization like that, not only because its bar to entry might be pretty high, but also because from the outside, it can be hard even to identify which companies are truly the best. Or maybe you just don't happen to live near the offices of any of those best organizations and aren't able to move.

Second, nothing lasts forever, including "being the best." I'm not sure the great organizations DeMarco and Lister use to demonstrate their "mentality of permanence" are still considered to be the best now that it's 10-20 years later: Reader's Digest, Hewlett-Packard, Pacific Bell? Even the lean software development movement's favourite company, Toyota, has recently shown signs of falling off the "being the best" pedestal.

In short, the mentality of permanence may not be permanent. If you're lucky enough to find yourself working for one of these best organizations, that's super. Enjoy it while it lasts, or for as long as you're comfortable staying. But don't be shocked if it doesn't last forever.

Which brings us to the next dimension. Given that you might find yourself working at lower-quality, "up or out" organizations during your career, should you move up or should you move out?

Continued in Software Development Career Paths: Up or Out?

Quitting Isn't a Way to Effect Organizational Change

Today I heard someone discussing why they were leaving a company, and that discussion involved them saying something like, "This job has been a bit crazy, and hopefully this will be a bit of a wake-up call for the company that something needs to change."

Baloney.

If you're unhappy with your job and you have a better position available somewhere else, then by all means, you owe it to yourself to switch.

But don't kid yourself that your leaving will make the organization realize they need to fix what was wrong with your position, department, or team.

As someone who has been working long enough to watch more than one person quit under circumstances like these, I can say that I have never seen the organization "fix what's broken" due to a single person leaving.

Maybe—just maybe—if an entire department or team left, the organization would experience enough pain to realize that something must have been very, very wrong and try to fix it. I think I may have seen this happen once.

But when a single person on a team quits, it just leaves a hole that the rest of the team scrambles to cover. They are so busy doing so, that the last thing they have time for is organizational change. And after a while, the organization sees that the person who quit really could be done without, and that no change is needed after all.

Recently, over on codesqueeze, I read Companies Aren’t Progressive (But People Are…). I don't agree with everything in the article, but at least it has a point—if you want change to happen, it's up to you to try to bring it about.

Once you're blue in the face from trying, and sick to death of it, feel free to quit with a clear conscience and go work someplace where people (might) better appreciate your efforts. As I said, if you have the opportunity to do so, you owe it to yourself to take it.

But don't delude yourself that your departure will be the tipping point that makes your organization wake up to how badly it needs change.