TexBlog

Steve Teixeira's Blog -- Thoughts on parallel computing, Microsoft, the industry, and life

Everyone's a rifleman

Everyone's a rifleman

  • Comments 8

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?

  • That is an excellent way of putting it.

    I have worked for to several companies where the people running the show have no a clue to the software process; including several software companies. A decision maker must understand their discipline, or they will not consistently make the right choices. Thusly software company, need people that understand software methodology at the top. Unfortunately, venture capitalists and boards of directors like people who speak "money", and given the chance they will install someone they can talk to. They then expect that person to find a someone to execute the technology. More often then not, that person doesn't know what it is to be a developer, and the situation gets worse.
  • 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.)
  • Hi Norm,

    You're right that writing software with high quality and customer focus are important, but I don't want to get too bogged down in all of the other things that are important to being a great software company because they are many in number.

    Instead, let me offer another an analogy: winemaking. I contend that a winery with more people up and down the organization with a passion for wine and a deep understanding of winemaking will produce the better wine (other things being equal, like grape quality, etc.). Yes, botting and corking and distribution and pricing and customer service and all of that are also very important, but my point is that the people that do all of those important jobs should *also* be passionate and knowledgeable about wine and winemaking.

    -steve
  • 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.
  • Hi Craig,

    I caution against reading too deeply into this and then picking a job at Microsoft and trying to apply "everyone's a rifleman" to that job.

    Microsoft is a huge, complex corporation with many, many roles that having nothing to do with development but that are still crucial to our success. The "everyone is a rifleman" maxim applied to any big corporation will unvariably be a generalization and an oversimplification of reality.

    However, with that said, Microsoft is primarily a software company. Well, maybe it's better to say that I'm referring to the software company parts of Microsoft. At any rate, we're not a technical support company (like, say, Geek Squad). Great support is crucial to our success (just as "beans and bullets" are crucial to Marines' success), but we don't provide support for the sake of providing support; we sell it to support the software.

    But, you did jar an idea lose in my head... hey "jarhead"... funny. Anyway, I feel a blog coming about developers and support. <G>

    -steve
  • 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.
  • I think Joel Spoelsky read your post and then wrote this

    http://www.joelonsoftware.com/articles/FogCreekMBA.html
  • PingBack from http://workfromhomecareer.info/story.php?id=4830

Page 1 of 1 (8 items)