I’ve spent enough time walking the halls of large-ish-to-massive organizations to have formed some opinions and made some observations.
If I had to characterize the motor that drives these beasts, I’d say it is comprised of two main components: intense risk aversion and an obsession with waste elimination that sits somewhere on a spectrum between neurotic and quixotic.
Let me explain.
Large organizations all started as small organizations, and all of them survived organizational accretion, besting competitors, dodging bad breaks, and successfully scaling to the point where they have a whole lot to lose.
It is this last concern that drives the risk aversion; upstarts are constantly trying to unseat them and rent-seekers are trying to sue them because they’re sitting on a pretty nice pot of gold.
It is the scaling that motivates the waste elimination. Nothing scales perfectly and few things scale well, so organizations have to become insanely efficient in a number of ways to combat the natural downturns in efficiency caused by scale.
Risk Minimizing and Process Efficiency
With risk minimizing and waste elimination as near-universal goals, organizations tend to do some fairly predictable and recognizable things.
Risk elimination takes the form of checks and balances, with pockets of “need to know” being created to isolate problems. For instance, a “security compliance” group may be created to review work product independently from the people producing the work, and it may even go so far as to seek outside certification. This sort of orthogonality and redundancy make it less likely the organization will be sued or compromised.
Unfortunately, though, redundancy exacerbates the other struggle, which is to eliminate waste in the name of efficiency. It’s not exactly efficient to have two separate groups spend time going over the same product and doing the same things, but with slightly altered focus. The organization compensates for this with hyper-specialty and process.
As a software developer, you can probably picture this to an extent. The organization will mandate that everything security-related in your application must happen in a stored procedure. It will then hire application developers, DBAs, and database security specialists, demanding that they all collaborate in some sort of workflow dreamed up by a process specialist that does none of those three jobs. The process will ensure that none of them need ever look at the same line of code or concern herself with any of the things the others are doing.
Should anyone point out that what’s gained in risk mitigation and duplication avoidance might be lost to process complexity and the resultant overhead, the organization will respond by convening a committee to optimize the process with more rules. I’m serious. And, why not? After all, the process people don’t actually interact with the people incurring the communication overhead. This is, perversely, how organizations, used to hyper-specialty, react by reflex.
Collaboration Stops the Madness
It is precisely this bureaucratic death spiral that keeps cartoon writer Scott Adams and his famous Dilbert character in business. Enterprises become mired in this vicious cycle. To understand how to break free, let’s first consider the nature of human collaboration.
Collaboration – true collaboration – is everything that the organization has been conditioned to avoid. It’s messy, unpredictable, erratic, hard to regulate, ad hoc, and just generally fun, assuming the participants like one another. People bounce ideas off of one another, wave their hands, draw on whiteboards, argue, scratch their heads, sit staring at their hands, and sometimes even give up and go for beers. They act like humans.
As developers, these take on familiar forms. Pairing on a particularly nasty bug or a particularly tricky feature is an obvious form of collaboration, as-is an impromptu whiteboard session in a cubicle. Developers collaborate when they review each other’s code, and they collaborate (albeit dubiously) when they spend 45 minutes arguing about the coding standards document.
These activities have elements of everything that makes the enterprise sweat.
Code review may be acceptable for insulating against risk and ensuring ISO9001 compliance, but only if you time box the review at 15 minutes and carefully follow the code review checklist. If you actually have a conversation about the code, that’s inefficient because it’s two people doing the same thing.
Collaboration Is Good for the Business
And yet, it is this ‘inefficiency’ is exactly what the organization needs. It’s inefficient if you look at it from within the hyper-specialized world of silos, but it’s macroscopically efficient because it serves as a governor on the amount of process that can be introduced.
If you have 4 people each following a procedural checklist for their slice of the application, you wind up with gridlock where a simple application change takes weeks. If you put those same 4 people in a room together and dispense with the processes, checks, and controls, the simple change resumes being, well, simple. It happens quickly.
Organizations do realize this, even if getting there isn’t easy. A lot of the work that I do with larger clients of mine falls under the general heading of “agile/craftsmanship transformation.” But I’ll let you in on a little secret. What most of that really boils down to is getting skilled people in rooms together, removing obstacles to their process, and empowering them to make decisions.
When I’m enlisted in this capacity, helping people collaborate is absolutely critical. I collocate teams, I institute pairing and code review setups, I facilitate whiteboard sessions, I cover the concept of behavior driven development, etc. Enterprises are actually starved for this sort of thing, even if it takes some nudging for them to realize it.
So many human problems at scale in the corporate world come from trying to automate the human element out of everything in favor of process. And, try as we might, we don’t do a particularly good job of this. When it comes to software development, empowering knowledgeable workers and having them collaborate is critical.
You may not be in a position within your organization to change the world. But you’re almost certainly in a position to change something. So if you want to make a positive impact, see if you can’t conceive of a way to get the people in your group collaborating, working together, and spurring each other on to better things. It will likely make both you and the organization feel better about your work.
Learn more about collaboration within enterprise organizations
SmartBear Software recently released the findings of a software industry survey, looking at how teams are maintaining code quality in 2016. The survey included responses from individuals within organizations ranging from less than 5 employees to 10,000+.
According to The State of Code Quality 2016 report, two-thirds of respondents working within organizations with 10,000 employees or more, are now using a tool for peer code reviews. Learn about this finding and more by downloading the full report here.