The level of formal process in an organization is a pretty esoteric topic that I haven’t seen discussed very often, or in very much depth. Yet I believe it is critically important to any CEO looking to grow a company, particularly a software or hardware technology-based company.
The reason I believe it is so important is that, in aggregate, how process-oriented your company culture is effects every nook and cranny of company operations. Oftentimes, however, senior management doesn’t even explicitly think about how much process they want governing company operations. More often than not, this part of the culture grows in a random and haphazard manner, driven by unforeseen key events that shape the level of process in different areas of the company. Sometimes this level of structure/process varies dramatically by department. In these cases, managers below the senior executive level usually are driving department cultures that may or may not end up being very process-oriented, depending upon their own operating styles. The key takeaway here is that process levels often aren’t being driven strategically, but occurring tactically or even haphazardly. This is usually a mistake–here’s why I think so.
Why process levels are so important in software & hardware companies
In technology companies, in particular, the level of processes can play a key role making or destroying your business. There are three reasons that I feel there should be much more sensitivity in high tech companies to process levels:
- The rapid evolution of technology and technology markets
- The need to innovate if you want to thrive in technology businesses
- The necessity and difficulty of constantly ‘taming” new technology
A low process software company example
I’ll use as an example a recent experience with a client to illustrate my point. The client is a small but growing software company. They have in their culture a high level of chaos, as is common with many growing, young software businesses. The company was bootstrapped and grown out of what started as a service business, and possesses very little in the way of corporate controls or processes.
On the positive side they are very responsive, fast-moving and innovative, able to capitalize on changes in technology and inefficiencies in the market. These are very important qualities in an startup software company, particularly one of the thinly capitalized variety. These “nimble” attributes are the very reason they’ve been able to crack through the very early stage that kills many startups, and has allowed them to grow and thrive.
But there’s a flip-side to this type of unstructured, low formal process corporate environment, however. This company lacks the discipline that is required to “stick to the plan”. Indeed, there is very little planning going on to begin with – let alone “sticking to that plan”! This operating style fits great in the segments of the company where innovation is critical, such as conceiving new products. But in other areas where a more disciplined, structured approach is important, operating this way often leads to performance which may be much lower and in this company is a drag on company results. While a low-process culture is excellent at conceiving and quickly prototyping new products, my client’s follow-on releases often come out much later than planned. QA is not a formal function for them and as a result the initial new releases and documentation are lower quality than they could and indeed should be. The website has very little formal oversight and is littered with a lack of consistency, broken links, old content and grammar & spelling errors. We’ve worked on correcting these problems — carefully — without killing the very environment that is enabling success. It’s tricky to fix without “throwing the baby out with the bathwater”.
This company is just one example; and of course the level of process needed to run IBM optimally is fundamentally different from that of an early stage software startup. In your particular company, it may be very important to have a high level of formal process in one department–and just as important to minimize the level of process in another. This may be quite different altogether in other companies.
So how do you know that you need to adjust your level of process in a strategic sense? Here are a few guidelines to get you thinking about where your process level stacks up vs. what may be optimal:
Your competitors are beating you to the punch
This is a common sign that you are bureaucratic and process-oriented relative to your market. While there may be good reasons for the processes you have installed, being consistently behind in responding to market needs can have a very negative effect on your growth prospects.
You are constantly releasing “flawed” products into the market
This is the converse to the first point above. It usually indicates you are moving too fast, with too little process and structure in product development, QA and release. Maybe in Marketing/Product Planning as well. In truth, the end results of this approach is usually worse that being beaten to market.
Employees are complaining about so much formal process
I always listen to what individual-contributor employees are saying; they are the “canary in coal mine”, often a leading indicator of issues that later show up in your financial statements. The caveat here is that these types of complaints can also indicate a hiring problem. Make sure you’re not hiring people who’s operating style just aren’t a good fit with the way the company wants/needs to operate.
Employees are complaining about the lack of process controls
The converse to the point directly above is when employees are complaining about how much chaos exists in the company. While the point above about watching for hiring mismatches rings true here as well, this is often the time you need to take a hard look at adding some structure to how you operate. Most of the time employees personally prefer less process to more. If they’re crying for more you’re likely to have a REAL problem.
There’s no “chaos” in your organization–and little innovation as well
I have a rule of thumb when it comes to pricing new products: if no one is complaining about price, you probably are leaving money on the table. My “chaos corollary” is similar: if there is no chaos in your operations that folks are complaining about, you probably have created an environment so process-oriented it will stifle your innovation and resulting revenue.
Generally speaking, I have a bias towards a little less process and a bit more chaos in software and hardware companies. Often excessive process is just a bad band-aid covering up poor hiring practices. Nothing allows you to minimize process – while maximizing productivity – like a strong, responsible, empowered group of employees. Creating the environment to hire and retain highly responsible people generally leads to a company getting done everything it needs to, with a good level of innovation to boot–while keeping formal process to a minimum.
I recommend holding off adding new processes until you absolutely have to, because going the other direction is much more difficult. But in fact, it’s important to have the proper balance if you want your company to function optimally. Analyze what the proper level of structure and process is not just for your company overall, but within each discrete operating segment of your business.
There you have it–my view on how to analyze and instill the proper amount of formal process for your company. What’s your view on this topic? Post a comment to expand the discussion.
Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or the PJM Consulting Quarterly Newsletter. Contact Phil directly at info@pjmconsult.com
If you liked this post please share it with you colleagues using the “share” buttons below:
Hi,
thanks for penning that article and describing the balancing act between keeping innovation and quick reaction ability to market forces vs. process, structure and related metrics.
I can certainly echo the experiences and challenges you describe from high-tech start-up and SME environments, as well as large corporates I have served.
Getting that balance ‘right’ in the aforementioned environments takes strong leadership skill, which supports your point of hiring the right people.
Best regards,
John
Hi,
You give three reasons for sensitivity from within technology companies, particularly software groups.
I would add two more that drive process decisions for us: firstly, the most critical one is agility: the need to have just enough process to support the fastest delivery of the highest quality code. Any process that supports that for our organisation is good and any that doesn’t isn’t.
I run a smallish software group of 40-50 engineers, and we’ve eliminated our former QA group, because it hampered the sense of responsibility that the engineers needed to “get to done”. And we don’t obsess on documentation, preferring to favour automated tests as specifications. You seem to list both as examples of responsible process and signs of a mature organisation; as above, I would respectfully disagree.
For us, these were examples of “formal process” that got in the way and kept us from being agile: fast to market, with the highest quality possible.
Lastly, I would add to your “sensitivity list”, the continual need to continually eliminate [and not create] “technical debt”. This bit of insight constantly drives our decisions about process.
regards,
Hal
Hal,
Thanks for your comments, and it’s certainly fine to disagree–I don’t think there are any absolutes when discussing things of this nature. Your experience is real and valued. Let me clarify one thing however, and make an additional point. When I was speaking about documentation, I was referring to end user documentation. I agree with you statement about not obsessing about internal documentation–with an eye on staying agile.
I must say, however, that from my point of view eliminating forma, independentl QA is playing Russian Roulette. I don’t consider 40-50 engineers a small group at all. Eventually someone (or more) will let you down, and you won’t catch it because of a lack of oversight. It’s human nature not to check your own work as well as needed. Many people want to belief the code is working properly and move on. I understand independent QA slows you down, and in the extreme (bad process!) can be a real impediment to getting to market on time. Just because you haven’t had an issue yet as a result doesn’t mean you won’t, and it could be a really big one. I personally belief there are better ways of instilling responsibility than eliminating a reasonable level of oversight. That’s my view–don’t expect you to agree.
Phil,
Thanks for clarifying your point about documentation; I did miss that you were speaking about end-user docs, and I agree that poor end-user docs are just plain poor practice.
I don’t agree with the notion that having a QA “team” that is “independent” is necessarily an example of a mature process. It depends on the maturity of the organisation. Having run several groups over the years, I suspect that a great majority are at our maturity level or less.
“Many people want to belief (sic) the code is working properly and move on.” Our approach, is to ‘trust but verify’, by writing automated specifications for all code, and to do it preferably before the code is written; a process known as Test Driven Development, or TDD. So, we don’t do our Quality Assurance based on “belief”. Since we’re an XP shop [Extreme Programming], we also have two pair of eyes continually watching every line of code that goes into production.
So, the issue becomes, will an “independent” pair of eyes find something that the initial pair of eyes won’t. And this is a legitimate question, and one that we’ve pondered. In our organisation, we felt that “getting to done” by encouraging each pairing team to take complete responsibility for their product by avoiding the temptation to just “throw it over the wall” so that someone else will catch the bug, was a compelling reason to not have that function.
I still feel that it has been a great call; our code is of substantially higher quality and better tested than when we had a fully functional independent QA department.
If your organisation is considering the XP approach vis-a-vis QA and you feel that you want to pursue TDD and pairing, it’s hard to imagine how you would do those activities without having the QA folks sit with the application engineers to pair on the tests, since that’s the optimal time to write them. [and yes, I get that there are other kinds of tests that QA folks do]. And if you do that, you might as well call them application engineers and eliminate the extra QA step, since having seen the code once, they won’t be independent any longer, and they wouldn’t or shouldn’t have missed any critical test the first time. I get the independence argument; it just doesn’t work in practice for my experience in the real world, with real engineers. YMMV.
So for us a substantial win that I would recommend for any group that I might run in the future.
regards,
/h