Stories about Software


Striking the Standards Balance: Scale Up without the Bureaucracy

Editorial Note: I originally wrote this post for the Telerik blog.  You can check out the original here, at their site.  While you’re there, have a look around at their extensive product offering.

In a whitepaper I wrote recently, I talked about two hypothetical organizations.  I used them to offer a study in hyperbolic contrast.

The first had a team of five developers, none of whom used the same development practices. In fact, one of them used a completely different programming language.  They tracked defects using email, and they operated less as a group and more as a collection of ships passing in the night.  If a customer issue arose in the code of a person on vacation, well, then that customer just had to wait.

On the other side of the aisle sat a massive enterprise.  Here, the team not only used the same programming language, but the same everything.  The organization restricted access to the machines so that developers couldn’t install anything of their choosing.  Instead of leaving things to chance, an architectural center of excellence controlled design decisions.  And any deviation from any practice required forms in triplicate.

I used this hyperbole to draw contrast between teams that could benefit from standardization and teams crippled by it.  Predictably, scale plays an important role in the distinction.  To scale an enterprise, one must standardize some operational concerns.  But in doing so, it risks choking the life out of individual innovation.

How can you standardize while minimizing bureaucracy?  Today, I’d like to offer some tips for striking the balance.

Get Buy-In

In my travels as a consultant, I’ve seen no quicker path to nonsense than tone-deaf edicts from on high.  Upper management decides to mandate 75% unit test coverage, and suddenly tests with no assertions and no value appear like mushrooms after a rain.  An important architect decides that all methods should have comments, and suddenly “//This is a comment” adorns every method in the codebase.  You get the idea.

When you force practices on intelligent people like software developers, you most likely won’t enjoy the results.  Instead, seek to enlist them and get them to believe in the standard.

Now you may have some team members that agree and others that disagree, depending on the standard.  But having any that agree will help with adoption.  This holds doubly true if the minority faction at least feels that people have heard its voice.  If the standards come from the team, instead of rolling down on top of them, you’ll have more success.

Create a Pit of Success

Speaking of success, you should create what I’ll call a “pit of success” for following the standards.  I can’t claim credit for this term.  It evolved to describe a situation where someone has the easiest time doing “the right thing.”  For example, imagine visiting a how-to website and finding yourself confronted with a big, fat “start by clicking this button” button in the middle of the page.  You will probably get this right.

Apply this sort of thinking to the standards that you create.  If people have to work hard and remember details, they’ll mess up.  When this happens, enforcing the standard becomes a matter of nagging and punishing.

Instead, seek to remove thinking from the equation.  For cosmetic coding standards, invest in tools that automatically “clean up” the code.  With unit test coverage, fail builds or deny checkins on on insufficient coverage.  Make information related to standards easily accessible, big, and visible.  Make it hard or impossible to fail.

Automate as Much as Possible

Did you notice something about the “pit of success” examples that I called out?  Use a tool to modify code cosmetically and use the build or gatekeeper to bounce untested code.  In both cases, automation answers the call.

Automation represents a specific instance of the “pit of success,” but I believe it worth calling out separately.  As software development shops, we trade in automation, but frequently fail to apply it to our own processes.  We should fix that.  Automation reduces effort and presents mistakes.

Standards create potential friction in a few ways.  Compliance can prove burdensome and annoying, and the pit of success addresses that.  But they can also cause bickering over compliance, reducing morale.  Automation frequently addresses this concern.  If nothing else, it displaces anger from a teammate to a tool.  Better to have your team despise “the stupid net nanny” than a line manager constantly snooping on their internet browsing activity.

Articulate the Why

Switching gears a bit, consider a more philosophical approach.  You should always be able to articulate the “why” about a standard.  In fact, so should everyone to whom it applies.

At the most basic level, this curtails the perception of arbitrary nitpicking over rules.  While team members may not agree with the reason for adopting a particular standard, at least they have a reason.  Without that, morale plummets as team members perceive bureaucracy for its own sake.

But articulation of why serves an even more important purpose.  It creates a self-policing guard against obsolete or pointless standardization.  A culture that continually asks “why” sets itself up to cut bait when no one knows why.  Follow this piece of advice and you’ll have a natural mechanism to retire standards that have outlived their usefulness so that you can focus on meaningful ones.

Standardize on Things that Please

The last tip that I’ll offer may seem a bit optimistic, but please bear with me.  You have a staggering array of things on which you could standardize, so try to choose ones that make life easier or better for the dev team.

I’ll get more concrete so that you understand what I mean.  Standardizing on a single source control tool simply makes sense to the point of being a no-brainer.  But you have a good bit of discretion in which system you pick.

I have seen source control tools whose existence can only be explained by frequent, expensive golf outings between a sales rep and a CIO.  Nobody that actually has to use these abominations would ever have picked them, and yet they become standard.  Don’t do this, no matter who buys you a round of golf.  Standardize around things that make the team members’ lives easier and that make them happy.

Obviously, not everyone will agree about every tool all of the time.  But you’ll get a lot further if you standardize on things with enthusiastic supporters.

Parting Advice

You’ll notice that all of this advice centers around involving the people asked to comply with the standards.  That’s no accident.  Standards apply to all of the people doing the work, so bringing them into the decision-making makes success much more likely.

In that vein, consider one last thing.  You hire intelligent people because you trust them to get their work done and to make good decisions.  But each standard you create and enforce takes a decision out of their hands.  So do that as infrequently as you can.  Err on the side of letting people exercise good judgement by only creating standards when they prove absolutely necessary.

Add a Comment

4 Comments on "Striking the Standards Balance: Scale Up without the Bureaucracy"

Notify of
Sort by:   newest | oldest | most voted

I never had issues with standards, until my current job.
This beginner expert is writing his interfaces in the same file of the classes. never seen anything like that.
Talked to him about it, nothing works. he likes things the way he is used to. the team has no team lead and this expert is trying to lead the band…annoying.

Erik Dietrich

Is this guy forcing his preferences on you? That sounds like a situation that calls for a request to work on some other project.

Yes. it’s a small company so other project will be on a different company, which is fine. the market is great and a good engineer can get an offer within a week. It’s one of those times you wish you could ‘try out’ the company first, for like a week and then decide if you want to take the offer. we basically go to interviews, ask questions about the process,org, maybe coding architecture, maybe even work life balance, but we don’t really know how it will be to work with the future colleagues. I think that on my next job… Read more »
Erik Dietrich

Oh, I’m completely empathetic to that situation. I can recall taking a job where, when I saw their code on day 1, I thought, “what have I done?” I think it’d be great if companies let you inspect their code (or, tongue in cheek, give their programmers programming tests).

I’ve actually thought about the merits of a business model wherein I create an automated static analysis and run a company’s code through it alongside candidates’ sample code to assess philosophical programming style match. Someday, maybe… 🙂