I’ve just been reading Ken McLaughlin’s recent post Top Ten Signs an Integrator is the Real Deal #7: Best Practices and Standards and I have to say, my initial reaction is one of skepticism. I think Ken’s thinking is a little too narrow on this one. Let me explain…
This isn’t the first time I’ve considered the “problem of standards” on this blog. In an earlier post, Standards for the Sake of Standards, I explained how most corporate standards eventually end up being out-of-date and absurd, mostly because nobody making the standard ever things to write down Why the standard exists, which would allow future policy-makers to understand the reasons and change the standard when it no longer applied. Instead, it becomes gospel.
However, that isn’t to say you could run a large organization without best practices and standards. That’s the point isn’t it? In order to become large, you need built-in efficiency, and you do that at the expense of innovation. Big companies don’t innovate (in fact the only notable exception is Apple, and the rebuttal is always, “fine, so give one example other than Apple”). Almost all innovation happens in small companies, by a tightly knit group of superstars where the chains have been removed. Best Practices are, in fact, put in place to clamp down on innovation because innovation is risky, and investors hate risk. It’s better to make lots of average product for average people than exceptional products for a few people (hence McDonald’s). Paul Graham, as usual, has something insightful to add to this:
Within large organizations, the phrase used to describe this approach is “industry best practice.” Its purpose is to shield the pointy-haired boss from responsibility: if he chooses something that is “industry best practice,” and the company loses, he can’t be blamed. He didn’t choose, the industry did.
I believe this term was originally used to describe accounting methods and so on. What it means, roughly, is don’t do anything weird. And in accounting that’s probably a good idea. The terms “cutting-edge” and “accounting” do not sound good together. But when you import this criterion into decisions about technology, you start to get the wrong answers.
The reason small companies are innovative is that innovative people can’t stand corporate environments. Imagine if you were an inspired chef… could you stand working at McDonald’s? Could McDonald’s even stand to employ you? You’d be too much trouble! You’d have to work in that nice one-off restaurant called “Maison d’here” where the manager puts up with your off-beat attitude because ultimately you make good food, and you keep their small but devoted clientÃ¨le coming back. But you can’t be franchised. The manager of the restaurant can’t scale you up without making what you do into a procedure.
So back to Ken’s topic… if you are choosing a systems integrator, you need to decide if you’re buying an accounting system (i.e. something that’s generic to all companies, and not a competitive advantage), or something that is a competitive advantage to you. When you’re automating your core business processes, you must build competitive advantage into it, and it must be innovative. If that’s the case, stay away from larger integrators with miles and miles of red tape and bureaucracy. Go for the “boutique” integrator (somewhere in the 7 to 25 person sized company, under $10 million per year in revenue) that can show you good references. You’re looking for a small group of passionate people. Buzzwords are a warning sign; small companies don’t have time for corporate-speak.
I’m not saying you should use the two guys in their garage. These guys are ok for your basic maintenance tasks, small changes, and local support, but you do want someone who has been around for a few years and has at least a couple of backup engineers they can pull in if there’s a problem. Make sure they have a server, with backups, and all that.
On the other hand, if what you’re automating is very large and very standard, that’s when you want to go with Ken’s approach. If you need to integrate a welding line, paint line, or whatever, there’s nothing new or innovative in that, so you want to lower the risk. You know all the big integration companies can do this, so go and get three bids, and choose the one that’s hungriest for the work. Make sure they have standards and best practices. The reduction in risk is worth it if you don’t need the innovative solution.
You can do a hybrid approach. Identify the parts of your process that could be key competitive advantages if you could find a better way to do it. This is where innovation pays off. Go out and consult with some boutique integrators ahead of time and get them working on those “point solutions”. Then go to the bigger companies to farm out the rest of your automation needs. How’s that for a “best practice”?
Scott! This is my first ever in-response-to-blog post! Very cool.
Getting to the jist of your post… …The point I was trying to make, was I often see people re-inventing for personal preference, rather than real business impact(improved functionality, performance or efficiency). This type of re-inventing doesn’t move anything forward – it just creates more variations of something that doesn’t need more variations.
Where innovation needs to be fostered is where it will make a real business impact. If I change this design/process/standard will it make me or others more efficient? Will it reduce the cost/time to deploy? Will it make the final solution work better?
If it does one of these things – then it should become the NEW standard. If it doesn’t have a measurable impact, then don’t change it. The change can be small (an evolution) or large (a revolution), but at the end of the day, it needs to have measurable impact.
I think we can both agree that the goal is better communication of ideas from experienced people to less experienced people. Perhaps traditionally this has been done through Standards and Best Practices, but I think that more interactive methods like blogs, lunch & learns, Q&A Sites, and one-on-one mentoring are more effective ways to communicate this information.
Standards and Best Practices are dangerous. Effectively it says, “this is the safe way to do it, and if you follow this method, nobody will blame you because you can just blame the standard. Forego the standard at your own personal risk.” Remember the saying, “nobody ever got fired for spec’ing Allen-Bradley?” Where has that gotten us?
It would be much better if instead of having a strict rulebook to follow, a person knew who to go to for help. Who are the experts in the relevant areas?
When I did a lot of motion control, it was a tight-knit group that focussed on it. We didn’t have a rulebook, we kept consistency where it made sense but weren’t afraid to throw out the old if a new idea was better.
I think that’s the balancing act that needs to be met. Too much one way or the other is a bad thing. Any time a “standard” or any idea for that matter is used as a crutch to avoid change or improvement, the pendulum has swung too far in that direction.