Find the Best Way to Organize Your Geospatial Talent

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

How to structure a team of geospatial professionals is a dilemma that comes up time and time again, regardless of the size or maturity of an organization’s geospatial program.Typically, the question revolves around whether to centralize or decentralize.

Should you group everyone who can spell GIS into a central team to get some consistency?

Or should you leave departments to their own devices and let them grow and manage their own teams?

Or should you do a bit of both, developing a hybrid model?

In some organizations, there’s a strong philosophical tendency toward centralization. The desire for control compels these organizations to group people with 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 bottleneck by the rest of the organization. Every map, app, or dataset that is conceived of is provided by this one team—often to the dismay of the organization.

On the other hand, a decentralized organization can find itself facing widespread redundancy in roles, systems, and datasets and often struggles with collaboration. The phrases “that’s our geodatabase” and “they work for me” are often heard in these organizations.

The swing back and forth between centralization and decentralization usually leads organizations to consider a hybrid approach. It’s natural to want to 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:

Common Organizational Models

Before looking at how to define your model, it’s helpful to look at five organizational models: Centralized, Hub-and-Spoke, Balanced, Federated, and Decentralized. They fall on a spectrum between centralized and decentralized. While it’s rare to find an organization that implements its geospatial program exactly as defined by these models, it’s useful to review some common patterns.

The key takeaway from these different models is that each serves a different purpose that closely reflects the goals and culture of the organization. This can’t be overstated. When considering a reorganization, don’t lose sight of what your organization will realistically accept.

Note the location or organizational home of the central group that is a feature of the Centralized, Hub-and-Spoke, Balanced, and Federated models. The home of this group depends on several strategic factors. In practice, a shared geospatial team typically reports to IT, reports to a specific business unit, or operates as a stand-alone corporate function. When a shared geospatial team operates as a stand-alone corporate function, it can be managed internally or outsourced.

Defining Your Model

This list of organizational archetypes does not suggest that there are just five ways to organize a geospatial program. This list underlines that organizing talent is a balancing act.
To settle on a model that fits your organization, you’re better served if you think about reorganization as a design process. This means following a structured and iterative process that starts with a base model and incrementally refines that model until the desired version emerges.

The approach suggested in this article was derived from one developed by Amy Kates and Jay R. Galbraith and explained in their book, Designing Your Organization: Using the Star Model to Solve 5 Critical Design Challenges.

Start with a decentralized model.

Start at one end of the centralization spectrum or the other. It might be best to start with a decentralized model and work toward increasing centralization, rather than working in the opposite direction. A decentralized model prioritizes autonomy and freedom and puts decision-making in the hands of those closest to business challenges, so 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 an organization’s geospatial resources is important. However, centralizing them may not be possible. For example, city police services often require infrastructure, databases, and security credentials that must remain separate from the rest of city government.

Pull out functions that are noncore to the departments.

Systems, data, or roles that are not essential to the mission of a department are candidates for relocation to the center. Often these functions exist on the business periphery or are supporting functions. Examples of these functions could include applications 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 such as a pool of generalist location analytics professionals.

Identify the management and governance functions that should be owned centrally.

Functions, like overall geospatial management and governance, are often better when centrally coordinated. These functions might include the development of corporate architectural standards, policies, and frameworks; solution rationalization criteria; and talent development plans.

Determine the need for integrative roles.

You don’t want to introduce new silos by creating a centralized function that is closed off from departments. That means you need to look at the roles and systems you centralized and identify where there could be gaps in coordination or collaboration. Any of the gaps uncovered could be addressed by adding roles for relationship manager or business analyst that coordinate with the organization. This could also indicate a need for systems that support cross-departmental information sharing, collaboration, and innovation.

Test Your Model for Fit

Once you’ve taken a first pass through the model selection process, you’ll want to take a step back and conduct a sanity check by asking some probing questions:

If you answered yes to any of these questions, go back through your model and make practical adjustments. You are just using the organizational archetypes as a guide.

Identifying the Home

Assuming you landed on some form of a centralized geospatial organization, you’ll have one more very important decision to make: where should this organization be located? The answer will vary depending on your organization’s business model, its strategic objectives, and its culture. There are several reporting structures that fit most geospatial teams: inside the IT department or as a department function, as a shared service, or as an outsourced function.

Choosing IT as the Location

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

Making It a Department Function

In some cases, embedding a central geospatial organization inside 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 situation. However, it’s important to regularly review this arrangement as demand for geospatial systems, data, or services in other areas changes.

Making It a Shared Service

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

Using an External Provider

An outsourced geospatial function can be considered for some organizations. This model is highly dependent on the organization’s culture and how amenable it is to external service providers. The benefits of this model include having flexibility in staffing, reducing operation costs, and being able to scale up and down quickly. On the downside, an external provider model can result in privacy and IP concerns, difficulty managing service quality, and concerns over cost control.

No Model Is Perfect

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. You may realize that your current model is no longer a fit and needs a refresh. By looking at alternative models and taking a structured approach to organization design, your organization will be better positioned to get the most out of its geospatial investment.

About the author

Matthew Lewin is the national director of Esri Canada's strategic consulting services and Enterprise Advantage Program (EAP). He helps businesses and governments grow and transform their organizations through location intelligence and GIS.