Alone on an Island — How Centralized Opps is Better for Public Sector App Developers and Data Gurus

Ian Gordon posted his piece on LinkedIn titled “Too Many Cooks, Why the Public Sector Only Needs One Data Team.” His thoughts mirror my own as I experienced the pitfalls of too many cooks in the data kitchen, and worse, have had to pick up the pieces where programs designed by hot shots (like the firefighters who parachute into remote terrain to put out forest fires) fail to remain viable after the hot shots depart. I could write about those issues, and maybe I will at some point, but I’d rather expand upon the value proposition of centralization.

My experience is that when departments within the public sector go it alone with data analysts AND with software engineering or app development, the departments maroon those specialists and their work products on an island. The island metaphor is more appropriate because in the truest sense these technologists and the systems they create are marooned from a “mainland” of centralized IT operations where the governance is created and evolves, where an array of skills and perspectives mix, and where the decisions are made on strategic goals and procurements services, software, security, and professional development. At first being on the island is great. There’s a feeling of freedom to build, experiment, and be the hero for the department. However, individual departments rarely have the funds to hire multiple developers, so typically, there’s that one app developer who’s paired with a business or data analyst. Not exactly a bench with backups for when vacation strikes. Nor is it a setting stocked with collaborators who can aid, challenge and motivate you (with their coding or UX skills).

As time goes by, these islanded developers become further and further disconnected from the changes occurring within central IT be it the evolving standards, addition of platforms, new staff with fresh skills and tools, or exposure to the leadership discussions behind all these changes. The disconnect occurs because individual departments tend not to look at their small IT shop as functional area that requires nurturing. Budgets may include software renewals, but often not the resources to adequately upgrade and replace code and ensure proper documentation and disaster recovery. Even if there’s a budget for conferences or training, that’s not exactly the same as plan for professional growth that’s typically crafted and championed by senior software developers or team leads. I’ve had staff in these island situations come to me (data analysts and developers alike) with concerns that the conference budget does adequately offer the upskilling experiences they need to stay current, and as the single techie or small techie team within the department, their managers don’t understand how to support their professional (or the technical growth of the operation) or advocate on their behalf.

As a result, skills age, as does the developer’s custom apps and architectures. Eventually when staff leave or require a long-term absence, the department must ask the central Dev/Ops to support business critical systems. This is doable, with time and resourcing. The alternative is a centralized strategy where staff, as part of a larger team of developers, UX designers and PMs, are assigned a portfolio of projects for one or more departments. In this way there is a bench of support. Someone is out of vacation? No problem, one or more developers assigned to that department will know what needs doing and step in. Being part of a central team allows staff to also cross train on different portfolios and acquire new skills and experiences without having to leave the job for a new role in another department. A benefit of centralization is the collective adoption and reinforcement of standards for code design, documentation, UX, and security controls.

Of course, all this takes leadership from the top including a well articulated and demonstrated set of values that drive quality, engagement, curiosity, and collaboration within the teams and between the teams and the business (departments). But, that’s what a centralized IT operation is designed to do, where as a Building and Licensing, Social Services, or Revenue department is not.