I recently read a draft paper by Phil Agre titled "The Practical Republic: Social Skills and the Progress of Citizenship." It seems to have absolutely nothing to do with software, being largely a critique of some theories of political philosophy. But after I read it, I realized it almost provides a checklist for my own career's advancement. Maybe it can do the same for you.
Here's a story of my testing life: Throughout the 1980s, largely by chance, I kept having my attention drawn to code coverage. (Code coverage is a way of measuring how tests exercise programs. If a test suite makes a program do lots of things—where "lots of things" can be defined in various technical ways—the hope is that it will be good at finding lots of bugs.) I ended up writing two code coverage tools (one with K. Wolfram Schafer and Thomas Hoch). But throughout it all, something about coverage bugged me. So, around 1990, I wrote a third tool as part of an attempt at a Ph.D., read a lot, and used coverage more carefully than I had before.
Let me use Agre's lens to look at the story so far. I'd identified an issue: using coverage. I researched and analyzed it, became capable of talking about it competently to various constituencies, including academics who studied coverage, practitioners who used it, and managers who craved control over the development process.
In doing so, I developed my own position. The standard approach instructed programmers and testers to meet a particular coverage goal (80% "branch coverage" was common). But I observed that code coverage is "blind" to a particular, important type of bug. Moreover, people under time pressure, told to meet a specific objective goal, would not write the best possible suite that reached 80% coverage; instead, they would write became that coverage goals are a poor substitute for human judgment. Coverage should not be used to provide answers, only to provoke questions.
I then staked out a public position, mainly by posting to Danny Faught's swtest-discuss mailing list and by writing papers. As time passed, and more and more people mentioned coverage, and I kept posting, I became the "coverage guy." I was consistently involved in, and in some sense organized, an ongoing public discussion of coverage.
My public position brought me to the attention of those associated with related issues. For example, throughout the 1980s, I believed that tests should be 100% automated. But on swtest-discuss, I became acquainted with Cem Kaner, who convinced me that my simplistic rule had to give way to human judgment. Over time, I became part of a social network of people who came to be known as the context-driven school of testing, a set of people who were ideologically compatible in their attitude that each testing situation ought to be approached afresh and that details matter. The fact that I have the stature to write this article is due in large part to that network.
To advance your own career, consider becoming an "issue entrepreneur." Stake out a distinguishable position on an issue. Form a network by finding people you can help in various ways. Help them understand their own issues better. Help them advance their positions. Help them articulate the beliefs you seem to share. Exchanges of aid lead to long-term coalitions.
Some of your network will be people who do jobs like yours and work in the same building as you do. But cast the network widely. Suppose you're a tester. If there’s no local testing interest group that meets regularly, form one. Or at least find compatible testers in other companies and go to lunch with them semi-regularly. And don't confine your network to testers. There are programmers and managers in your organization who have compatible styles—cultivate them. Attend local programmer interest groups, even if you're the only tester there. (Especially if you're the only tester there: as an entrepreneur, you crave unfilled market niches.) Link up with people remote from you, perhaps by starting a weblog devoted to your issue, hosting a Stickyminds roundtable, or writing an article for this magazine.
I've a hunch that you can benefit by doing methodically what I did haphazardly.