The Government of Canada is not a software company
Weeknotes #14: Aug 24–28, 2020
That may seem obvious, but the implications ripple through what and how work is done.
I first entered the public service as a Code for Canada fellow within Public Services and Procurement Canada before accepting a term position with Transport Canada.
Fellows help build digital capacity in government, and demonstrate what’s possible when the latest methods in software development, design thinking, user experience research and product management are applied to serving the public.
— From https://codefor.ca/fellowship/
Although we prototyped over at PSPC, I always knew that our team wasn’t going to build the next government travel portal, we were helping with the procurement process. That was the name of the department, after all!
Then a few months after my fellowship ended, I joined Transport Canada, officially as “Team Leader, Application Development”. I joked sheepishly that it’s been a long time since I’ve done any development, but for me the implication was that we were working on delivering technical solutions. That’s a space I’m pretty comfortable with.
I’ve spent the bulk of my career working in technology companies, contributing to the design, development and delivery of software products. They were all private companies, and we knew that the company profits came from the products we made and sold. In my time at ReadyTalk, first as a product strategist and later as the manager of innovation strategy, I was involved in discussions about our strategic vision and portfolio. I led a lean startup team to explore a new product concept, to pitch back to the company.
Denver/Boulder isn’t Silicon Valley, but there is a very strong entrepreneurial ecosystem there. Companies and talent are willing to invest in trying new ways of working, with the admittedly capitalist-driven approach that you need to take some risks to reap big rewards. It wasn’t all about turning profit, though, sometimes a ‘big win’ was getting the best employees, or funding, or simply getting written up in some big tech blog (yes, I know a VP of a company who declared to his team that that was their metric of success for a product launch). I won’t spend too much time on this tech-driven approach other than simply to point out that despite any aspirational vision statements about ‘helping people connect and thrive’, these companies were staffed and organized around building and delivering technology products.
The private sector throws around the word “mandate” pretty casually, but in the public sector, mandates come from the top and clearly set the priorities and objectives for each Minister. The mandate letter for the Minister of Transport, from Dec 2019 is posted publicly, for everyone to see. Just like a CEO of a company may establish goals for the company, here’s a list of priorities to deliver on.
This sounds a bit silly, but when I look at this mandate letter, I don’t see anything about building or delivering software. Sure, that may be a delivery mechanism, but it’s not central to what we are here to do.
Which is fine, except….
You may have heard of the triple constraint theory in project management. Otherwise known as: “Good, fast, or cheap. Pick two.”
When we are operating in a project-oriented mode, we often focus on delivering on time and on budget, and so scope may suffer.
When I look at something like a mandate letter, that says “this is your focus for the foreseeable future”, I see a project. We want to be able to check off that we’ve achieved what we were asked to achieve, and then we can move to the next objective.
That’s not how great software is made and maintained.
Software, especially the powerful tools we increasingly need and expect, takes time to design, build and test. Software takes effort to maintain. And if we expect to maintain and build upon the products we release, we need to consider that from the start.
From 2008–2012, I worked for a small agency that offered marketing and communications for the non-profit and public health sector. I led their digital solutions offering, working with clients to determine their objectives and readiness to take on new digital initiatives. Part of that was about ensuring they had the capacity to continue to maintain their digital presence.
wait. did I lead digital transformation efforts? 😝
Sometimes I felt like the wet blanket: a client would come in all excited about some cross-channel campaign that with multiple touchpoints, etc etc, and I’d work with them to help them understand that this wasn’t like a billboard ad buy. This was an investment and would need ongoing maintenance.
Software companies get this. They invest in infrastructure. They invest in talent, so that they don’t lose knowledge and expertise. They recognize that while building a simple tool may get cheaper and easier (“my 11 year old cousin can build an app over the weekend!”), the quality gap is becoming enormous.
They know this because they live and breathe it. They understand what goes on behind the scenes, how investing in process improvement can see huge returns.
But clients don’t ask for backend process improvements. They don’t ask you for devOps, or design systems, or product teams. They want what those things enable, but they are not going to mandate how you do what you do.
In the private sector, you answer to your shareholders. Generally speaking, if it seems like in the future you will make more money than you do now, you’re good. Public opinion factors in, but only insofar as it may affect the flow of $ and shareholder return. (An example: people in the US claim to hate Spirit Airlines. But people continue to buy tickets on their planes, so that opinion doesn’t appear to have a lot of impact on how Spirit conducts their business).
In the public sector, we are always concerned with public opinion. Are we being good stewards of public funds? Are our actions what’s best for Canadians? Are we comfortable defending our financial decisions?
We need to build systems, not buy them
I want to talk about the importance of investing in systems and infrastructure when it comes to building software. I’ve seen a few projects where we stand up something small and discrete to solve a specific need, but it’s separate from other systems. So we deliver on our project on time and on budget, but are we truly increasing the value generated for our clients? Or are we duplicating efforts, and introducing complexity for our users?
I started to write about how we can’t only make these small bets, because it’s inefficient. But then I realized that I don’t think that’s our real fear when it comes to government software. I think we’re also afraid of the other side: the big complicated systems that we are afraid to touch. Those that evolved from reams of business requirements and architecture diagrams.
We’re afraid because we don’t understand how these things work, because we don’t have people working on them all the time.
When I say “build systems”, I’m not talking about a bunch of one-off applications. I’m talking about having a shared foundation that is built and maintained internally, that can help teams work more efficiently. Standards. Reusable components. Patterns. And to be clear — this also isn’t a one-off project you can fund-and-forget. This must be maintained as a product if it is to continue to be useful and valuable over time.
Last week I was speaking with a few folks about what Transport would look like if we were organized as product teams. I took a look at the Spotify Tribe engineering model, and tried to think about how that could work. This is just a first take and I haven’t solicited any feedback on this yet, but it was just something I wanted to try to start to think my way through. Could this work?
The piece that’s the most foreign to me is the funding piece. We have project-based funding right now. Shifting that to dedicated product funding seems like a significant departure. And does it even really align with those top-down mandates? This is about how to structure a technology group, not how to deliver a safe and efficient transportation system for Canadians.
I know that dedicated product teams, devOps and designOps improve how software companies deliver solutions. But delivering amazing software isn’t our raison d’être as a government agency. It’s hard enough for a software company to make the case for shifting resources to internal tooling rather than customer-facing features. In the case of the government context, it’s even more daunting…
