What do you call someone who writes code for a living? Developer? Programmer? Engineer? Architect? Coder?

Many people in the public service perform the same basic job with vastly different titles. It would be good for them to hang out together to compare notes and best practices. Unlike the private sector—where you can’t share proprietary information or intellectual property with your peers—in government, sharing should be encouraged. When two people who are working on the same thing meet, they can find ways to collaborate, putting more wood behind fewer arrows.

At our first FWD50, an excited attendee told me she had met four people in four other departments working on basically the same thing. None of them had any idea the others existed—and at that time, they couldn’t even see one another’s calendars to coordinate a meeting, had they known.

But this kind of serendipitous encounter has always been the exception, left to coincidence or a random conversation in a lunch line. This year, we’re going to try and engineer serendipity a bit more through something we call Job Jobs (the name comes from people asking, “yes, that’s your title, but what’s your job job?”)

 

A hierarchy of jobs

George E. P. Box said that “all models are wrong, but some are useful.” And so it is with any system that tries to sort the nuanced nature of jobs into a manageable set of groups. We could define jobs by seniority; or by department; or university degree. None of these would be perfect, but they might be useful. So when I set out to design the Job Jobs activation for this fall’s FWD50, I knew plenty of people would have opinions on the matter.

I chose a product lifecycle model, based on the idea that everything done in digital government involves some initial research and planning, delivering the service, and operating it. This works well enough for most kinds of service.

Consider a restaurant:

• Planning means researching dining trends and locations, finding staff and a chef, and building a financial model that includes food costs, rent, and profit.
• Delivering means building the kitchen and seating, printing the menus, hiring the cooks and waiters, setting up a website and social accounts, buying ads, and making sure you get the proper permits and licenses, designing the menu, and testing the recipes.
• Operating means producing meals, charging diners, making payroll, crunching the numbers, tweaking the menu, and eventually, expanding into additional restaurants or shutting things down.

The same is true of a funding program, a passport website, or an apartment building: Planning, delivery, and operation. Each of these functions has subordinate functions, which can be arrayed along a rough timeline: Delivery means managing people, projects, and money; Operating means running the data, code, people, and platform or physical infrastructure.

I drew this all in the following diagram:

And then, because it’s the best place to quickly find out all the ways you’re wrong, I posted it on Twitter to see how I might make it better.

I was not disappointed.

 

What we learned from the thread

I’m going to summarize some of the most important things in that thread below, and then explain how we’re going to run Job Jobs based on this feedback. I promise that some people won’t like what we do, but the map is not the territory, and I hope the activity will be useful for a significant number of the people who attend, both in person and online, when we run it.

 

Delivery and operations aren’t distinct things

The diagram is overly simplified in one important way: Delivery and operations are actually more overlapping in modern technology. The field of DevOps (a portmanteau of Development and Operations) underscores this. Because, unlike a physical asset, software can be constantly updated and modified; and because software behaviour is intrinsically linked to the platforms, operating systems, and networks on which it runs, the separation of “building” from “delivering” is a fiction in mature software development environments that embrace Lean Startup and Agile methodologies.

 

It’s not a line, it’s a cycle

To rectify this, the diagram actually needs a cycle of building, measuring, learning, and improving. But that makes the illustration overly complex, so we’re not going to include it here; just know that often fixing a bug and implementing a feature are often indistinguishable, and performed by the same person.

 

It ignores strategy

As Jacky Tweedie pointed out, strategy and planning are two different things. “Strategy sets the priorities & desired outcomes. Planning lines up needed resources & people in order to undertake activities to hopefully bring about the outcomes.” She suggested this excellent overview from Rotman professor Roger Martin.

The best line in here is “strategy has a theory about how to win.”

 

Focus on outcomes

David Pepin suggested we look at an outcome-based model—make a list of the outcomes being delivered, such as usability or cost reduction, and then bring together people focused on those outcomes. He referenced Pavel Samsonov’s diagram contrasting this approach with output-driven models.

 

Current versus desired state

Pia Andrews said that while the diagram reflects the current state, but not the one we want. Policy, delivery, and operation should be one continuum, part of a greater product lifecycle. Several folks referenced Neil Bouwer’s talk on policymaking and policy transformation recorded at the 2022 Public Sector Summit.

Neil lays out the current model for policymaking: Research, options, and advice leading to a decision, which then triggers implementation and evaluation. This model has several big limitations:

• It’s compartmentalized and slow.
• It can’t change fast enough to take advantage of real time analytics and modern tech.
• It’s impossible to predict every outcome of a policy, and rather than stubbornly continuing when a problem is found, policies should be able to adapt.

There’s an Integrated Policy Framework formally published by the Government of Canada’s School of Public Service that lays out this cycle, which turns the “funnel” of policymaking into an endless loop of instigation and approval.

 

An imperfect filter

Several folks DMed me, some concerned, to say that they couldn’t find themselves on the chart. There’s a reason for that: The diagram is very functional, and focused on delivery. It doesn’t show the designers and communicators and “connective tissue” that often keep an organization running smoothly. Others suggested we look at the National Occupation Codes, the Canadian system for describing occupations (did you even know there’s a taxonomy of skills, knowledge, personal attributes, interests, and more, created by government?)

The seven categories of the Canadian Skills and Competencies Taxonomy.

 

The reconfigured diagram

I’ve modified the initial diagram, splitting it into distinct phases of strategy and implementation. To do this, I’ve merged Neil’s model with the UK Design Council’s Double Diamond approach.

• The left side is about strategy: What might we do, and what will we do? Why is this the winning approach, and what outcomes do we expect?
• The right side is about delivery: Now that we know what we will do, how might we accomplish it? And how will we?
• There’s a gatekeeping process (“approval”) where budget and staffing are assigned to the initiative. But there’s also an evaluation step where we decide whether to update and iterate the thing we’re delivering; adjust the policy based on new evidence; or end the project.

It ain’t perfect, but no model is.

 

What we’ll do

Based on this model, we’re going to ask attendees three questions to classify them:

• Whether they work on strategy (on the left) or delivery (on the right.)
• The “verb” of their job (words like “approve”, “build”, and “analyze”.)
• The “noun” of their job (words like “people”, “software”, and “compliance”.)

Attendees will be able to answer these questions by scanning a QR code, and then navigating a branching survey leading to a number between one and ten. We will then direct them to one of ten areas. In the physical world, this will be a set of ten tables in our workshop space. Online, it will be areas in a Wonder.me meeting room.