The level of formal process in an organization is a pretty esoteric topic. I haven’t seen it 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.
I believe it is so important that how process-oriented your company culture is affects every nook and cranny of company operations. However, senior management often doesn’t even explicitly consider how much process they want governing company operations. More often than not, this part of the culture grows randomly and haphazardly. It’s often driven by unforeseen key events that shape the number of processes 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 drive department cultures. Each manager may or may not be very process-oriented, depending upon their operating styles. The key takeaway 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 in 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 formal process software company example
I’ll use a recent experience with a client to illustrate my point. The client is a small but growing software company. Their culture is highly chaotic, as is common with many growing, young software businesses. The company was bootstrapped and had grown out of what had started as a service business. It possessed little in the way of corporate controls or processes.
The upside
On the positive side, they are very responsive, fast-moving, and innovative. This makes them able to capitalize on changes in technology and inefficiencies in the market. These are very important qualities in a startup software company. Particularly one of the thinly capitalized varieties. These “nimble” attributes are the very reason they’ve been able to crack through the very early stage. The stage that kills many startups and has allowed them to grow and thrive.
The downside
But there’s a flip-side to this type of unstructured, low formal process corporate environment, however. This company lacks the discipline 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 well in the areas of the company where innovation is critical, such as conceiving new products. But in other parts where a more disciplined, structured approach is important, operating this way often leads to lower performance. In this company, it is a drag on corporate results.
A low-process culture is excellent at conceiving and quickly prototyping new products. However, my client’s follow-on releases often come out much later than planned. QA is not a formal function for them. As a result, the initial new releases and documentation are of lower quality than they could and 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”.
Just one example
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 quite 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 completely different in other companies.
So how do you know that you need to adjust your level of process from a strategic standpoint? 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. There may be good reasons for the processes you have installed. However, 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 of 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 results of this approach are usually worse than being beaten to market.
Employees are complaining about so much formal process
I always listen to what individual-contributor employees say. They are the “canary in the 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 whose operating style just isn’t a good fit with the way the company wants/needs to operate.
Employees are complaining about the lack of formal process controls
The converse to the point directly above is when employees are complaining about how much chaos exists in the company. The point above about watching for hiring mismatches rings true here as well. But 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 simple rule of thumb when it comes to pricing new products. If no one is complaining about the price, you are leaving money on the table. My “chaos corollary” is similar. If there is no chaos in your operations that folks are complaining about, there is a problem. You probably have created an environment so process-oriented it will stifle your innovation and resulting revenue.
Generally speaking, I’m biased towards a little less process and a bit more chaos in software and hardware companies. Often, the 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 accomplishing everything it needs to. Generally, with a good level of innovation to boot. All while keeping formal processes to a minimum.
I recommend holding off adding new processes until you absolutely have to because going in 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 department 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 Subscribe to the Morettini on Management Newsletter hosted by LinkedIn. Contact Phil directly at info@pjmconsult.com
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