Everyone likes being a hero. It feels good to be the hero. Especially in information services, where providing a solution that removes a user’s pain is a great boost to one’s psyche. Being the hero, wins trust, and may even enhance job security. However, organizationally, too many sideline heroics create chaos. The day after the crisis has passed, things are left in a less than wonderful state. The created chaos forces every group to try to handle every kind of thing with no specialization. Every kind of tool and approach is used somewhere, because it was “the easiest thing” for one person or another. Database management may be distracted by application development; reporting groups may be off building websites; business analysts, even project managers, may have created various solutions that no one can now properly support.
Things can become even more confused should non-technology focused work teams get involved. Business people with super savvy spreadsheet skills can perform heroics solving many people’s problems … but what happens when change is necessary and there really is no one who is responsible to support the previous solution? Sadly, the usually occurring answer is that a new hero builds a new solution for the new variant need. Now two unsupported solutions exist, then three, then four…leading to more chaos. If these shadow IT teams are kept small, and if kept unorganized and chaotic, then they can survive. Once they need to scale in size, and need some structure, then problems emerge. In a fractured environment, filled with heroes and heroic teams churning out the bits, each group flounders on its own; each group works at its own change management approach or its own scheduling approach (often manual). Often shadow IT groups ignore problematic details. Sooner or later, as the business grows, these shadow IT teams become the problem. The organization is forced into multiple processes for everything The Dunning-Kruger effect comes into play as the shadow IT groups are mostly unaware of the minutia and details that they overlook and leave unaddressed. Architects are useless in an environment in this state, as there is no real structure; and unless the organization desires change there may never be structure. If there are any rules or procedures at all, they are either ignored or only followed within individual workgroups.
Certainly, for small organizations or small technology groups within organizations, smallness dictates that everyone serves as a generalist, and that everyone pitches in when needed. But once the organization grows beyond a small team, there are great synergies provided by specialization. Project managers, business analysts, web developers, ETL developers, DBAs, provide the specialized professionals following best practices customized for a specific industry and organization that strengthen the team as a whole greater than the parts.
In ancient Rome, the army units were not allowed to cross over the Rubicon, as that action was considered the harbinger of soldiers in a state of insurrection. Similarly, IT managers’ need to be careful of identifying those things that would be “crossing the Rubicon,” and overstepping the order of things, of going beyond what is reasonable – even when tempted to do so. Building a solution without any consideration of ongoing execution and maintenance is ultimately a destructive act. The heroism of today in solving the immediate need sets things up for eventual failure. Managers must acknowledge that once they agree to have one of their team build one solution or another, these managers have committed their entire team to be skilled in the tools and technologies used to build that solution and to shepherd that solution through future changes. Upper management must be vigilant too, and not blindly reward a good solution done in the wrong manner. Solutions must be viewed in an enterprise context not in myopic isolation.