More Henry Ford, less Picasso: Why GR should scale, too

Havana, Cuba. Pic by Ansgar Baums

1. Scaling and GR — does it even exist?

As discussed in our introductory article, GR functions are likely to be put under pressure (or asked nicely) to “do more with less”. One of the main challenges for GR managers is scaling while building and retaining consistency in processes and products. This is particularly difficult in a field where most cases managed are very specific regarding both content (every law is different), and context (every political system and country footprint of a company differs). No wonder that Government Relations is often regarded a “one piece at a time” craft. It looks artisanal if not “artsy” rather than an “industrial” process that could be optimized over time.

Or is it? For sure, every briefing for a meeting with government officials is very specific, as well as defining a strategy to influence a particular law. However, despite the specifics there are also plenty of aspects that are often very similar — e.g.:

• the need to collect feedback from internal subject-matter experts on technical aspects of a specific law and present options of action to management
• the collaborative effort to write a briefing — and follow up on a meeting
• the need to monitor and evaluate regulatory proposals — which are often covered by different entities in a company (technical regulation, government relations, sustainability functions etc)
• the need to monitor and evaluate relationships with both individual policy-makers or regulators as well as industry associations.

We found that very few GR organizations actually have separated the artisanal from the industrial — therefore reinventing the wheel way too often. How many times you sieve through a chain of emails that were started by a “hey — we need to take a position on proposal x” — often lacking pieces of information that are key to come to a point of view conclusion quickly? How often have you rewritten meeting briefings on rather similar topics without leveraging content that already has been signed off?

We think that getting smart about the artisanal and the industrial aspects of GR is key to be effective and efficient. More Henry Ford, less Picasso!

2. Productization

So how could you “productize” GR work? First and foremost: Make it a team exercise. Start thinking about what is a product is a key step to establish a different mind-set.

Step 1: Identify core processes

Without claiming this is a definite list, we have identified a couple of standard products that most GR teams might relate to:

• Evaluate a public policy proposal and create a corporate point of view
• Prepare an executive for an external meeting with government officials
• Monitor ongoing policy proposals
• Distribute GR content (e.g. policy point of views, short info blips) internally and make it searchable
• Distribute compliance-relevant content to a “must read” audience (e.g. export controls regulatory changes)
• Hand over of a policy portfolio in context of job role changes or a GR manager leaving the company

If you would make these six processes really efficient, any GR team could save a lot of resources.

Step 2: Describe status quo

The next step would be a detailed process description for each of them — not how it could be, but how they are actually handled. It is key to be honest here: Don’t over glue inefficiencies, rather focus on them. As an example, let’s focus on what happens if someone leaves your team. He might collect a few important briefing or policy documents from his hard drive and email inbox, might wrap it up in a short “hand-over briefing”, and sends the package to his manager or successor. We estimate that 70% of the knowledge built up by this particular individual becomes inaccessible to the organization. Why? Because GR functions still heavily rely on emails to align on policy positions or personal hard drives to store content. These are the inefficiencies you want to unearth during this exercise.

Step 3: Adopt product management perspective

Once you have identified the process bits that repeat themselves and are scalable, it is key to adopt a “product management” perspective that would allow you to improve the processes over time. An easy way to do this is to assign “product management responsibilities” for each of these core processes with an expectation that responsible product managers are regularly checking in with the internal customers of such products (usually management who takes the final decisions on policy matters), and optimize the processes continuously.

Step 4: Identify IT core building blocks

If you look at the core products from an IT perspective, a few key functions are very likely to show up more than one time:

• A database where content is stored and searchable
• A workflow for contributions and approvals — including the definition of deadlines
• A de-brief option once content has been delivered (e.g. feedback from the CEO after a meeting with a government official — ideally this feedback is stored where the original briefing is)
• A hardcopy output function — at some point you would need to be able to press the printing button.

Unfortunately, we haven’t found off-the-shelf solutions that support a productization strategy for GR. However, development of tailor-made solutions is rather easy on platforms like Sharepoint (yes — it’s really powerful) or — even easier to program — Smartsheet. If you start developing your own software solutions, it makes sense to start the conversation with these building blocks. This will enable you to reassemble them across the different productization efforts.

3. Next steps

Here are some specific recommendations that you could take to your GR organization:

• Designate a “productization” manager in your team — ideally someone who is comfortable to reach out to IT for development support
• Pull together a user group that analyses the status quo: How are the four key processes mentioned above are currently handled? What are the biggest problems? The user group should ideally include “customers” — e.g. the CEO office manager responsible for briefings and potentially other global functions who depend on similar processes.
• Describe the status quo and clearly describe the problems. Start rather early on with a prototyping exercise — it could be as easy as developing a fictional dashboard or tool view in Powerpoint.

As we already talk about products, you might as well have a look into design thinking methodology to structure your workstream. Lastly there is a nice side-effect to this given that it opens up entirely new career paths and opportunities that are outside of the usual “Head of (insert as many countries as possible) Policy” trend where a policy professional is confined to define his growth trajectory by mainly the number and relevance of markets she/he covers.

If you think about it more through a product rather than regional lense, distributing interesting and rewarding work across teams becomes easier and can be fine-tuned to make sure the right people own and drive it. Some people are just more motivated and thus better at the skill of drafting excellent briefing documents, so why not have them own that process and help others become better at it?