P-p-p-policy!! (Or, what Lucas does at work)

Hello there!

A happy Sunday to you. I’m writing after a weekend of coffees, walks, reading, and Don Giovanni. Also rom-coms. I hope yours was equally nourishing.

A great privilege of my job is working with my good friend and inspiring colleague, Sean Boots. Before he moved to the Yukon, we’d often engage in random side of desk conversations. (They were literally side of desk—we’d lean over to see each other without our monitors in the way.)

During these chats, we’d discuss our latest adventures in (digital) government (reform). We often developed small theoretical frames to explain our thinking. (Despite his recent move, we still do this—now over a much greater distance of time and space.)

There’s a model Sean developed, one I find quite applicable for understanding organizational change. He graciously gave me the go-ahead to write it up. If organizational change interests you, I encourage you to read about it. I wanted to share it here, but it would’ve needed cuts to fit—and I’m loath to remove its details!

Instead, I’ll share with you a much less profound model. It’s one I use to explain what we mean when we talk about “policy” at work. Less profound, but newsletter sized. If you’re curious about what I do at work, read on!

There are two big buckets of “policy” in the government:

1. Program policy. What challenges the government takes on, and how it responds to those challenges. For example, the government decided that to improve people’s experience of government services, it would create the Canadian Digital Service.
2. Administrative—or management—policy. How government teams do their work. For example, before using artificial intelligence to make decisions, teams need to complete an “algorithmic impact assessment”.

Administrative policy is my daily playground. Working in (digital) government (reform), the rules shaping how teams work are candy to me. (Though I’m more of a cured meats guy than a candy guy…)

But administrative policies aren’t always easy to find. I find they take three forms. Get ready for a lot of Ps (awwwww [y]ah awesome alliteration!):

1. Policy as paper. The most straightforward. Requirements are written down in a widely available place. For example, the government’s policy suite page. Generally, these carry weight: if you don’t comply, there may be consequences. They change very formally.
2. Policy as process or practice. Sometimes teams or organizations operate a certain way. They’ve done so “forever” and it seems to work. This process becomes a policy of its own—even if it’s unwritten, and the details not widely accessible.
3. Policy as pronouncement. Sometimes people say stuff and it sticks. Often this happens when a senior leader—or someone with a loud voice and little shame—states a preference. That preference goes unchallenged or unexamined, and it becomes accepted as-is, calcifying into a policy of its own.

For extra fun, policy in these three forms can exist in “the centre” (a few departments responsible for making rules for all of government), in each department, in divisions of each department, or in teams.

Some of these policy forms carry more legitimacy than others. Generally speaking, paper is more legitimate than process. Pronouncement is rarely “legitimate”. (But, importantly, legitimacy can differ from what’s actually heeded.)

When trying to help folks—from CDS or from a department—do their work, my job is to understand this landscape: policy as paper, as practice, and as pronouncement, from the centre down to teams. It’s fun, but at times mind boggling.

A frame like this situates me. Maybe it can be of use in your life, too, whether you’re in a big bureaucratic machine like me or operating at a more personal scale. I think it can help explain the “policies” that govern much of daily life, too.

This was probably a more niche letter than normal, but I hope a tidbit or two spoke to you! All the best for the week ahead.

Lucas