Everyone's a rifleman
My military career was exceedingly short and undistinguished. I spent a month in US Marine Corps boot camp before they sent me home because of a preexisting medical condition. As an organization, the Marine Corps has a well deserved reputation for being highly motivated, having exceptional esprit de corps, and being extremely effective in accomplishing their missions. During my brief stint as a would-be Marine I learned about what I feel to be one of the keys to the Marine Corps' long history of success. It's their deceptively simple notion that everyone is a rifleman.
The rifleman is the backbone of the military. It's the individual on the ground, literally in the trenches, that does the hard work and heavy lifting required of the infantry. While the profession of rifleman is one generally held by young men of lower organizational rank, every Marine, no matter their rank or "day job," takes pride in being a rifleman. There are hundreds of job descriptions in the Marines, but everyone understands that the rifleman embodies their core competency. It's the "business end" of the organization. This all sounds a bit grandiose, I know, but it does have real meaning within that culture. From a practical standpoint, this literally means that any Marine -- whether a pilot, a general, or a cook -- must be capable of wielding a rifle and performing the job of a basic rifleman. Perhaps more importantly, though, it implies an emotional thread that connects all Marines. It's a sort of lowest common denominator that means everyone is in the same clan, a part of one team, and all decisions and actions will be undertaken with this fact in mind.
There are interesting parallels between the Marine Corps' "everyone's a rifleman" philosophy and the decidedly less-than-lethal profession of software development. For example, you might consider a software company's "riflemen" to be the individual developers and testers that embody the organization's "business end." They do the thing that provides the essential reason for the organization's very existence. One pattern I've observed over the years is that high performance software development organizations have an "everyone's a developer" philosophy. In these organizations, the ranks of company leaders and decision makers include people that understand what it means to be a developer. And I'm not talking about a CTO-token-techie type. I'm talking significant representation within company leadership of those in tune with what it means to be a developer. Think about some of the software companies you most respect and admire and then see how many of them didn't get that way without having "riflemen" calling a good number of shots. And, speaking anecdotally, I know some of the most frustrating times my career were spent in organizations led by individuals or groups that I believed were unwilling or unable to be riflemen, which severely compromised their ability to lead.
When I was considering whether to join Microsoft, one of the things that attracted me to the company is that the organization to a large degree is a manifestation of an "everyone's a developer" philosophy. Microsoft at its core recognizes that developers are not one trick ponies whose scope must be limited to All Things Coding but they instead recognize that the secret to a winning is finding and promoting those individuals whose skill set combines a little developer kung foo with other skills important to leading and managing a business. Of course, just like it's a mistake to promote an rifleman to general of he or she doesn't understand strategy and logistics, you don't promote a technologist to leader unless they have those other skills.
What about your organization? Is everyone (or almost everyone) a rifleman? Do you think it helps or hurts?
Comments
- Anonymous
October 24, 2005
The comment has been removed - Anonymous
October 24, 2005
In most of the companies I've worked for, even the people directly in charge of programmers don't understand anything about it. They can't distinguish whether the work has been done right or not, they can't tell the truth about decisions they made because they didn't even understand what they were saying when they pretended to make decisions, etc. But they can sure detect when someone causes trouble by reporting that they a bug, which makes extra work for everyone because of some troublemaker's opinion that bugs should get fixed. Fortunately my present employer is an exception in this way (too bad it's not exceptional in any other way though).
> manifestation of an "everyone's a developer"
> philosophy.
I'm not sure where to start with this.
(1) Suppose there were a philosophy that "everyone's a tester". Then maybe there would be more willingness to fix bugs.
(2) Suppose there were a philosophy that "everyone's a user". Then maybe in the few cases where fixes have been developed for bugs, users will be allowed to download the fixes instead of being told to first pay for support incidents. (I've read rumours that Microsoft US sometimes does allow this, but Microsoft Japan doesn't, and Microsoft US's web site doesn't.) - Anonymous
October 24, 2005
The comment has been removed - Anonymous
October 25, 2005
So where, then, would you say support fits in? In my mind — and to use your analogy — they'd be "riflemen," because they, like developers, are producing the "product" the customer pays for. More than just explaining how to use our software, our support team teaches our customers how to better conduct their business, and business process improvement, rather than the product per se, are what the customer really wants to buy. But unlike, say, a tester, I wouldn't necessarily expect a support person to really understand development at a very deep level. - Anonymous
October 25, 2005
The comment has been removed - Anonymous
October 26, 2005
Well, I had my company rather than Microsoft in mind when I posted that comment. Microsoft produces a huge number of products and people buy them for different reasons. People who buy a game pack might be buying it because they want a piece of software for its own sake, whereas people who buy Excel might buy it because they need to balance their books. They don't care so much about Excel per se as they do about passing their next audit, maybe. So I wouldn't really generalize about the motivations of Microsoft customers because they're too diverse. Heck, a great number of MS customers don't even buy the software directly; they get it preinstalled on a computer. That never happens with my company's products!
My real point is this: I agree with your post as far as it goes; there's a lot of truth in what you wrote. But I think it has to be considered in light of what your customer really wants, and what the customer really wants won't be the same for all companies, or all customers. Software developers sometimes make the mistake of thinking that their job is strictly to produce a product for its own sake, which I think is sometimes true but not always. More commonly, their job is to produce something which helps the customer meet a need. If the software can do that by itself, that's great, but often the customer needs guidance to use the software correctly; they may need to change their own process to something quantifiable. - Anonymous
October 26, 2005
I think Joel Spoelsky read your post and then wrote this
http://www.joelonsoftware.com/articles/FogCreekMBA.html - Anonymous
June 15, 2009
PingBack from http://workfromhomecareer.info/story.php?id=4830