Erik Dietrich — March 7, 2017 To create the most efficient work environment, you need to standardize on tools and processes in a way that makes sense. Read on for tips on what works best.
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 whom 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. Rather than leave this to chance, 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 check-ins 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 judgment by only creating standards when they prove absolutely necessary.
To learn more about the advantages and disadvantages of standardization as well as to get tips on what, when and how to standardize for maximum result and minimum pain, check out the recent whitepaper I wrote: Striking the Development Standardization Balance: Key Considerations.
Business & Finance Articles on Business 2 Community(46)
