The Sergeants of Software Development

It’s 2017, and guess what?  It seems we’re still trying to discover our identity. Still asking questions about what it means to be a tester.

It’s perhaps worth offering one possible analogy that I’ve given to my testers once or twice that, while it doesn’t match perfectly in all respects, does resonate for me.

That is, if we were to imagine a software development organisation as a military unit, testers are the sergeants. Before I break down why I think it’s a useful parallel, I’ll provide a brief explanation of what a sergeant is, and does (which, being the military, is pretty well defined).

“Sergeants typically are second in command of a troop or platoon of up to 35 soldiers, with the important responsibility for advising and assisting junior officers.

After a few years as a Sergeant promotion to either Staff or Colour Sergeant may follow. This is a senior role combining man and resource management of around 120 soldiers, or even command of a troop or platoon.” – Ranks, British Army

To give some flavour for the worth the military places on its sergeants, I Googled for some quotes;

“…the backbone of the Army is the Non-commissioned Man!” – Rudyard Kipling, “The ‘Eathen“.

“The sergeant is the Army.” – Dwight D. Eisenhower

“If I had another life, that’s what I’d be – a regimental sergeant major or a similar rank. That’s where the spirit of the armed forces is.” – Bob Ainsworth

“Battles are sometimes won by generals; wars are nearly always won by sergeants and privates.” – F. E. Adcock

“Any officer can get by on his sergeants. To be a sergeant you have to know your stuff. I’d rather be an outstanding sergeant than just another officer.” – Daniel Daly

“Most armies are in fact run by their sergeants – the officers are there just to give things a bit of tone and prevent warfare becoming a mere lower-class brawl.” – Terry Pratchett

Of course it’s easy to find some quotes that fit the bill, and easier still to assert that one’s place in things is to be the glue that holds everything together and makes it work. However, in the interests of helping explain what testing is, I will explain, expand upon, and (probably, and inevitably) ditch the metaphor.


Chain of command

Let’s address the place of a sergeant in the chain of command. Granted, a sergeant is subordinate to the greenest first lieutenant fresh from officer training at Sandhurst, West Point, Frunze and the like. During the training, however, the officer cadet will have been under the guidance of several sergeants and sergeant majors, a dynamic that continues when the officer graduates and is given a command. The place of the sergeant is to assist and guide the young officer, using their far superior experience.

In software development teams, in my experience at least, good project managers tend to lean pretty heavily on their test team leads for organisational and management assistance. This is typically due to the type of knowledge that the tester typically has at their command, which I’ll go into below.

When I raised this analogy on twitter, someone said “I’m not a particularly good order-taker”.  As testers are an extension of the senses of our local stakeholders, it is natural that our relationships with them are more symbiotic than rigidly hierarchical. As I imagine is the case in any structured environment, high effectiveness stems more from mutual support and respect than from slavish devotion to the chain of command.

Also, much as I imagine a sergeant has scope to bring their experience to bear in their duties, so to does (should!) a tester. The chain of the command should support and encourage, not explicitly direct or restrict. As testers, we have a mission to complete, but we decide which tactics to best employ for the situation.

Systemic knowledge

The basis on which a manager comes to appreciate the support of testers is rooted in the nature of their knowledge.

A developer’s knowledge is typically narrow but very deep. They understand completely how a particular feature is put together, but might not know much about adjacent features, or other areas of the codebase. A tester, on the other hand, has pretty broad knowledge which, while not as in depth as a developers, is still pretty comprehensive, at least from a logical perspective.

This systemic view and understanding which the act of testing gives to the testers makes acting as deputy project manager a relatively small jump for a tester. My test leads have more often than not acted as deputy team leads at one point or another.

Another area of potential cross-over of knowledge is in the area of test strategy / planning. Depending on your organisation, the production of a test plan might be the first time someone asks questions like “What languages are we supporting?” “How many concurrent users are we expecting?” “What are we releasing?”.

You can actually get pretty far through the development lifecycle without ever having to answer these questions. If your focus is to deliver functionality above all things, it might never occur to people to have answers for these questions.

Testers can be the drivers for answers because test planning is the first stage where those questions have to be answered. Opinions are divided about test plans, because “no-one reads them”, and so they are waste. But, to quote Eisenhower again, “Plans are useless, but planning is indispensable” (this quote adorns the front of my test plans to this day). The artefact might be waste, but the process of filling in the blanks most certainly is not, especially if the review involves all the relevant local stakeholders.

Being the agent for filling in these blanks, for asking the broad, important questions upon whose answers can hinge the success of a release, makes the testers valuable support – and impetus for change – to management.

“Yes, Drill Sergeant!”

“But”, I hear you cry, “I’ve seen movies and the sergeant is always a shouty asshole. In Full Metal Jacket the Drill Sergeant gets shot!” True, but the role of Drill Sergeants is different. Their job is about breaking recruits down before building them back, minimising individuality and prioritising uniformity.

In a business environment, while mentoring and training will likely be part of a tester’s role, it shouldn’t involve any breaking down of the mentee. Certainly for a tester, that individuality is what makes them valuable. The ability to apply their individual skills and experience is a big chunk of why they find bugs that others have not.

One who serves

A sergeant is, in most in the armed forces but not all, the senior non-commissioned officer (NCO) rank. The word has its origin is the Latin serviens, “one who serves”, through the French term “sergent”.

There is baggage attached to the word “servant”, little of it positive. But if we check our ego at the door for a second, a servant is one who ensures that the needs of others are met; surely a noble calling. In software development, a current answer to questions about the place of the tester in the team is that we should strive to add value where and how we can. What is that if not to serve? That is literally the embodiment of quality; adding value to those who matter.

Rather than being a mere subordinate, meeting the whims of others, someone who chooses to put the needs of others ahead of their own has all they need to be a good, even great, leader. They need only to decide to lead. Those they have helped will often willingly follow.

The servant-leader is one whose desire to help others drives them to seek leadership positions purely to enhance their breadth and power to help others. This, I imagine, is the pure ideal that drives some politicians to seek high office, only to be brought low by human self-interest, and the corrupting effects of absolute power.

Lest we forget, we serve the needs of our customers by providing tools and services so they can do what they want to do. We should perhaps not be repulsed by the word service. We are not servile. The relationship is not servitude. Helping others, at both the company-customer and team levels, is what we should be about. Let’s embrace that.

The Sergeant

So, if you’re still looking for handle for your tester identity, I think you could do worse than a sergeant. The role is about adding value and supporting others, and creatively determining how to meet your mission directives. It also has the scope to develop as much of leadership aspect as you want.

Writing this has reminded me that, despite many years of trying to figure out what my passion was, I had at one point decided that my career goal was broader and simpler that what I had been looking for; that is: to help others. To seek leadership in order to better serve.  Lead to serve.

10 thoughts on “The Sergeants of Software Development”

  1. Nice post, I understand the relatable subject more than many, having lived and breathed it, for 11 years in the British Infantry.

    Some of the Army based information is just not 100% correct, unless that has been your life and you have served under these people you’ll never really appreciate what a serjeant’s (different spelling within my old regiment) role truely involves within a Platoon, Company or Battalion. You’re also bypassing the important role that the Corporal’s and Lance Corporal’s play, within that dynamic.

    I’m a Tester so I understand where your head is at while writing the post, I just personally feel a little uneasy with details you’re relating.

    I need to read through the post again to get it clear in my mind and offer some better and more constructive feedback…it’s easy to say you don’t agreee with something, harder to highlight exactly why. I’ll get back to you.


    1. Thanks for the message, Danny. You’re right of course. This is based on my understanding which, never having been in the military, is flawed and based mostly on movies. I look forward to your feedback.

  2. Hi, Richard!

    I guess this could be a useful analogy.

    I don’t have any military experience and, to me, there’s one thing missing before I could take this and share with a whole project team (so that it doesn’t sound just like a pat on the testers’ back).

    I got which are the testers and which are the managers in this analogy – which “role” do the programmers take?
    The reason this gives me pause is that, to me, it seems that programmers could be seen as seargeants too; so we might end up not building that much of a tester “identity” by using the analogy that you propose.

    What’s your take on this?


    1. Thanks for the comment, Valentin.

      Like any analogy, it begins to creak if you push it too far. I’m not proposing that there is a 1:1 mapping from the military to software development.

      That said, I agree that programmers can and do occupy the sergeant role, but in my experience it seems less often than testers do. Developers focus on doing their complex, in-depth tasks which do not require a systemic, strategic view of the system. The job of a tester does.

      So let’s just say it; developers are more likely to be privates. That’s not to denigrate them, or that role. They are the productive foundation of any software development business. But a source of frustration to me over the years has been the experience that many developers write code, and that’s it. They tend not to engage in any other project or business activity.

      The other developers, however, the ones who do look up from the code now and then, are much more likely to jump through / past sergeant into the officer roles. Software development businesses – again, in my experience – are predominantly developer-led, and so testers are much less likely to progress to management roles. Of course, this will vary from business to business.

      So, insofar as the metaphor (still) has value, developers are privates / corporals, but are more likely to become officers, whereas testers top out as sergeants.

      1. Thank you for your thoughtful reply!

        I think I can follow along; this fills in all the missing gaps I had.


  3. I think you have opened up a huge can of worms with your Anaolgy of ranks in the army . Please understand them before using them as they seem to make no sense and as comments above would suggest , people who have served and are testers now see a huge floor in your logic .

    You are right it’s not a 1:1 mapping from military to tester/ programmer roles etc but the more I read the more I devalue the anolgy

    Sorry , just a honest review . Love the thought of you using ex military as a model to use your statement on , being ex military of 13 years myself but wish most of it was correct and researched correctly to deliver a more powerful statement with inspiring facts behind it


    1. Thanks Chris, I really appreciate the honest review.

      Would you be willing to expand on your comments, or do believe the analogy is just too flawed to be worth examining further? I’d be happy to publish or link to a more thorough analysis if you’d like to provide one (if you think it’s worth it). Let me know.


      1. Hey Rich,

        I’m still struggling….based on my experience, the majority of your military references are just false.

        The Army just doesn’t work like the way you’re trying to describe, the quotes that you have chosen just don’t fit the model of what I first hand, know the army to be. If you were to pick a single countries army and base it from there I would be slightly happier but you’re mixing the role that a sjt plays within those different units.

        I wanted to get on board with your analogy and find some positives but I just can’t get passed the fact that it’s based on untrue information.

        I’d be more than happy to chat with you about this away from here, drop me a line on Twitter @dannydainton.

  4. As you say, like any analogy it comes to pieces if you pick too hard at it. I could see where you are coming from; like you, I’ve not been in the military, but my father was during the Late Unpleasantness with Germany; he joined up in 1943 and served until ’49, by which time he was a Drill Sergeant, responsible (amongst other things) for delivering the basic training for the first officer cadre of the reformed Dutch Army.

    This experience made him the person he was, and many of my best management dictums come from his stories and observations. Two of them (which he attributed to Montgomery) have particular application to testing: “A bad plan is better than no plan at all” and “No plan survives first contact with the enemy” (which seems to me to be at the root of Agile… but perhaps that’s a discussion for another time.)

    You wrote: “When I raised this analogy on twitter, someone said “I’m not a particularly good order-taker”.” As I understand it, the best sergeants aren’t good order-takers, especially if those orders are bad ones. The art of the sergeant is to be able to say “With respect, Sir, that’s a bad idea”, giving that officer pause to think again. And if the officer insists, then it’s the sergeant’s job to find the best way to execute that order with the minimum adverse impact on the people under their command.

    Having said that, I’ll end with this story: A group of officer cadets at training college were asked how they would put up a flagpole. There was a heated discussion over using winches, cables, derricks and pulleys, but the instructor wasn’t impressed. “You’ve all got the wrong idea,” he said. “All you have to do is say, ‘Sergeant, get that flagpole put up.’ “

Leave a Reply to Richard Paterson Cancel reply

Your email address will not be published. Required fields are marked *