How to organize your geospatial talent

Struggling to get the most out of your geospatial investment? It could be how your people are organized.

Regardless of the size or maturity of an organization’s geospatial program, how to structure a team of geospatial professionals is a dilemma that comes up time and time again. Typically, the question revolves around whether to centralize or decentralize. Should we group everyone who can spell GIS into a central team so we get some consistency? Or should we leave departments to their own devices and let them grow and manage their own teams? Or should we do a bit of both and form a hybrid model?

In some organizations, there’s a strong philosophical tendency towards centralization. The desire for control and focus compels these organizations to group common capabilities. For others, a culture of autonomy empowers managers to focus on their own interests. The drive toward speed, agility and innovation motivates these organizations to build what they need, where they need it.

Each model has its advantages, but inevitably, over time, cracks emerge. A centralized team becomes overburdened with responsibility and is perceived as a bureaucratic bottle neck by the rest of organization. Every map, app or dataset that is conceived of is provided by this one team - often to the dismay of the business. On the other hand, a decentralized organization can find itself facing wide-spread redundancy in roles, systems and datasets and often struggles with collaboration. The phrase “that’s our geodatabase” or “they work for me” is commonplace.

This swing back and forth between centralization and decentralization usually leads organizations to consider a hybrid approach. It’s a natural conclusion, really. Let’s have the best of both worlds - the control and oversight of centralization and the autonomy and agility of decentralization! The trick is figuring out what, specifically, should be centralized and what should be decentralized. This leads to several questions. How do we balance the competing forces of centralization and decentralization? How do we make sure the resulting model is a fit for our organization? And where in the organization should my new team reside?

Let’s find out!

Common organizational models

Before we look at how to define your model, it’s helpful to look at some example organizational structures. While it’s rare to find an organization that implements their geospatial program exactly as defined by these models, it’s useful to review some common patterns. Generally, they fall on a spectrum from centralized to decentralized as described in Exhibit 1.

Exhibit 1 – Common organizational archetypes for geospatial programs

The key takeaway from these different models is that they all serve different purposes and closely reflect the goals and culture of the overall organization. This can’t be overstated. When considering a re-organization, don’t lose sight of what your business will realistically accept.

Another point of note is the location or organizational “home” of the central group described in the Centralized, Hub-and-Spoke, Balanced and Federated models above. The home of the group is dependent on a range of strategic factors. We will discuss these in the next two sections. In practice, we most often see shared geospatial teams reporting into IT, into a specific business unit or operating as a standalone corporate function. In the case of the standalone function this could be internally managed or outsourced.

Defining your model

The intention of the organizational archetypes is not to suggest that there are five ways to organize a geospatial program. The point is that organizing talent is a balancing act. To settle on a model that fits your organization you’re better served by thinking about re-organization as a design process. This means following a structured and iterative process that starts with a base model and incrementally refines the model until a desired version emerges.  A suggested approach (derived from an approach developed by Kates and Galbraith in “Designing your Organization” (2007)) is described as follows:

Start with a decentralized model. To begin we need to start at one end of the centralization spectrum or the other. The recommendation is to start with a decentralized model and work toward increasing centralization rather than the opposite. A decentralized model prioritizes autonomy and freedom and puts decision making in the hands of those closest to the business challenges. We want to start with that as a baseline.

Identify functions that cannot be centralized. Certain systems, data, roles and services must remain in the departments for legal, regulatory, privacy, risk or security reasons. Identifying these components and acknowledging them as part of the greater geospatial complement is important, but centralizing is not possible. City police services, for example, often require separate infrastructure, databases and security credentials from the rest of the city government.

Pull out functions that are non-core to the departments. Systems, data or roles that are not essential to the departments’ mission are candidates to be moved to the center. These are often functions that exist on the business periphery or are supporting functions. This could include application development, production mapping, application support and geodatabase administration.

Move functions that would benefit from economies of scale. Many functions, while important to the work of the business, could be more efficiently delivered through a central, shared provider. Often these are functions that are not fully utilized by any one business area. Centralization, in this case, enables sharing the cost of expertise. Examples could include a pool of generalist location analytics professionals.

Identify the management and governance functions that should be owned centrally. Overall geospatial  management and governance functions are often better suited to a central, coordinating function. This  might include the development of corporate architectural standards, policies and frameworks, solution rationalization criteria and talent development plans.

Determine the need for integrative roles. We don’t want to introduce new silos by creating a centralized function that is closed off from the departments. That means we need to look at the roles and systems we’ve centralized and identify where there could be coordination or collaboration gaps. This could be addressed by relationship management or business analyst roles that serve as liaison with the business. This could also point to systems that support cross-department information sharing, collaboration and innovation.

Test for fit. Once you’ve taken a first past through the process, you’ll want to take a step back and conduct a sanity check by asking some probing questions. Is our centralized team now so big that it would be too unwieldy to support? Would the change imposed on the organization make this model impractical? Would senior management see this as too risky? If so, go back through your model and make practical adjustments. Use the organizational archetypes as a guide.

Identifying the home

Assuming you landed on a centralized geospatial organization of some form, you’ll have one more very important decision to make: where should this organization be located? The answer to this will vary depending on your organization’s business model, strategic objectives and culture. But there are several reporting structures that fit most geospatial teams.

Information Technology. IT is a logical place to locate a central geospatial team as the systems and data that are at the heart of a geospatial capability are likely supported in some way by IT already. The IT function is also used to supporting a wide variety of business areas and business needs. That said, the disadvantage of reporting into IT is that this area may already have a reputation for poor or slow service and this could rub off on the geospatial team.

Department Function. In some cases, embedding a central geospatial organization inside of a department other than IT is desirable. This can be true when a strong and effective central team is already in place in a department or where one department is the overwhelming user and beneficiary of geospatial systems and services. In this case there’s no sense in disrupting a good thing. It’s important to regularly review this arrangement as demand for geospatial systems, data or services in other areas grow.

Shared Service. In a shared service model, the geospatial organization acts as a standalone service provider to the business. The benefits of this model are that the geospatial organization can serve areas of greatest demand as long as funding is in place and resources can be allocated effectively. The downside is business areas that have funds or resources are often left on the sidelines.

External Provider. An outsourced geospatial function is a consideration for some organizations. This model is highly dependent on the culture of the organization and how amenable it is to external service providers. The benefits of this model include: staffing flexibility, reducing the cost of operations and the ability to scale up and down quickly. On the downside, an external model can result in privacy and IP concerns, difficulty managing service quality and concerns over cost control.

~

No organizational model is going to be perfect. But the rapid evolution of the geospatial industry has made it imperative that managers look closely at how they deploy their geospatial talent. How you organize your people can have far reaching implications in terms of employee productivity and customer satisfaction. For many, they will realize that their current model is no longer a fit and needs a refresh. By looking at alternative models and taking a structured approach to organization design, most organizations will be better positioned to get the most out of their geospatial investment.

If you would like to know more about organizing your geospatial talent contact me at mlewin@esri.ca.