For those in the software engineering, system administrator and generalist IT fields, you may have heard about a culture shift known as DevOps.
Designed to break down the interdepartmental barriers that exist between business technology divisions at strategic and tactical levels, the tactics behind DevOps bring together traditionally partitioned IT resources, such as software engineering and development, with IT operations, including system administration and infrastructure, by enhancing communication, collaboration and integration. The long-term strategy yields a more productive IT organization that is able to deliver more business value throughout the company.
For too long, IT organizations have been plagued with the blame game, which is what the concept of AllOps aims to eliminate. Tell me if you’ve heard of or been part of one of these scenarios before…
- Engineering develops products to run on systems and when something goes wrong, the systems folks point fingers at the engineers for too many bugs in the software.
- The systems team cannot move data around the network fast enough, so they blame the network/infrastructure group for delays with data backups.
- The network/infrastructure team cannot grow the infrastructure fast enough due to budget and/or time constraints and cite the business team for the constraints.
These problems have ripple effects throughout the organization until someone steps in, setting up “business process” to streamline communication between departments through formalized interfaces (ticketing systems, PMO, etc.).
Over time, the relationship between these departments degrades due to the processes in place (a.k.a “throwing the problem over a wall” syndrome) and culture degrades. The log jam between departments continues, eventually affecting non-IT departments, who are simply looking at IT to help them be more efficient in their work.
The worst part about a scenario such as these described above is that each part of the organization could mitigate the effects of the problem at their respective layer simply by communicating with the adjacent group.
If the network/infrastructure team cannot grow the network fast enough, they should talk to the systems and software engineering teams about better tuning systems or streamlining code to reduce load on the network. In actuality, the network/infrastructure team (who are experts in their domain of knowledge) could probably make specific recommendations to other teams on how to accomplish this, reducing time spent on researching a solution.
In cultures with DevOps, these scenarios don’t happen as much because teams no longer rally around protecting their own departmental goals and initiatives, but rather relate everything to the larger business-enabling picture. Teams no longer get “requests” or “tickets” from others in the organization. Instead, they are are given information about the business impact or efficiency enabled by getting something done.
This gives all stakeholders a common vision, goal and reason to get something done without putting up false barriers. In fact, DevOps goes further to enable non-technical individuals in the organization to do more technical-oriented actions with proper support systems, enabling enhanced levels of delegation and increased productivity.
So having experienced these scenarios as our organization has grown to 100 full-time staffers, I conjecture the idea of “AllOps.”
AllOps is a culture movement at the C-suite, VP and Director levels in an organization designed to break down the traditional barriers to communication between departments. The concept relies on various levels of the organization to assemble as a cross-functional team and as a team themselves, not as “representatives from various portions of the organization”.
The cross-functional team is charged with a business objective and leaders from various portions of the organization are empowered to look broadly for resources across the organization. For example, directors are charged with developing and deploying business tactics throughout a company. Directors are responsible for the day-to-day business operations and workings of the company and to do so, function holistically as a management team.
In the AllOps model, the team sets common business goals and utilizes the required resources throughout the organization to complete objectives. This enhances information flow greatly between departments with common vision shared amongst all stakeholders.
If your business is feeling the effects of the traditional top-down, hierarchy-driven management model, you might want to consider the AllOps strategy. Organize your teams around levels of management and greater business objectives, not specific department or team objectives. Take the time to look at the DevOps model and think about how to expand AllOps throughout your company.
By sharing vision and goals between departments, barriers to communication get lowered, and the logjam gets cleared. Alignment is created, and success is realized. So far, it is working at my company and I’d be interested in getting your thoughts in the Comments section or via Twitter.