Jason: And I'm your co host, Jason Peerman. You're listening to The Public Practice, the show about the people behind public sector transformation.
speaker-0: I'm your co-host, Nick Scott. In this episode, we talk to Dorothy Ng, CEO of Code for Canada, a nonprofit organization that works with government and corporate partners to help build digital capacity of public service teams across the country. Dorothy Ng, the CEO of my favorite national nonprofit organization, It is so good to have you on the show today. Thank you for being here. ⁓
speaker-2: Thank you, Nick. Thank you, Jason. It's a pleasure to be here.
speaker-0: We're we're looking forward to to hearing more about you, the person, the hero, the the ⁓ the leader. And as we do with all of our our shows, we want to start off by just getting to know you and how you became ⁓ you today as CEO of Code for Canada. What is your origin story?
speaker-2: My origin story. yeah. Well I'll start ⁓ I won't go too far back. I'll, you know, start maybe like in the middle of my life journey.
speaker-0: You were born and then you applied to work at Code for Canada.
speaker-2: And then I'm here I am. What else can I No, we'll talk about I was I was in university and ⁓ not everybody knows this, but I studied ⁓ materials engineering at ⁓ McMaster University in Hamilton. Nice. ⁓ which is like steel steel city. So ⁓ I was like destined to work in a steel mill as my career. Like I learned all about steel, how to make
speaker-0: And here you are.
speaker-2: Tempered steel, high quality steel. But then ⁓ when I was graduating from university, it was the ⁓ 2008 recession. So then all the automakers tanked. And then all the steel mills tanked as well. So when I when I graduated, like all of my ⁓ colleagues and me had zero jobs, no, no job prospects. And so we were just scrambling, applying to any any job out there. And so I ⁓ I saw this posting for this firm called a a small little firm called Accenture, just like a little little technology consulting firm. You know, and I read the the job posting, I was like, I have no idea what any of this is. So I just applied for it. ⁓ you know, go went through multiple interviews ⁓ and ended up getting the job. So I was like, okay, I'm working here as like kind of a it was a systems integration analyst, ⁓ just kind of like working with their clients, doing systems design, which was not really like my background. ⁓ in university. And my first ⁓ and like biggest project at Accenture was with ⁓ Metrolynx. So Metrolinx is the agency ⁓ in Ontario. I'm based in Ontario, by the way, just for all the listeners out there. and ⁓ it's the agency that oversees all public transit across Ontario. And so they were just rolling out this new digital fair payment system called Presto, the Presto card. And Metrolinx had contracted ⁓ Accenture, this place that I worked to ⁓ to like do a lot of like the design and rollout of that system. ⁓ and so here I was, like I hadn't I really knew nothing about like technology or fair cards, but I was thrown in there and I helped to design like the first Presto fair card. It was like green and it was it was like vertical and and it looked really, really snazzy. And then and the system could do a lot of things. Like you could tap on and tap off at different like subway stations and go train stations. ⁓ I felt like very proud of the work. And then one day, I remember like showed up to ⁓ this like dinner party and people were like, ⁓ like what do you do? I was like, ⁓ you know the presto fare card? I designed that thing. And this one person was like, You designed that, that thing sucks. I was like
speaker-1: No.
speaker-2: and yeah, and they were like going on, you know, I came from I've lived in Hong Kong, I've lived in London, ⁓ they have the oyster card, the octopus card, listed all these different fair cards, and they like, Those cards are like way better than this card. Like actually I c I can't do so many things with this card. I was like, ⁓ my god, like I never really thought of all that. ⁓ and then when I like kind of thought about it further and and ⁓ really evaluated like how the work was rolling out, it's true that like the the system was not really designed from like a user's perspective. It was designed from the perspective of like honestly was a lot of like transit providers. It's like the transit provider must receive this amount of the fair payment and and fraction and that other transit provider receives that fraction. ⁓ and so it was very like designed for the players within the system, like the agencies and not the actual writers. And so very few kind of user stories were embedded in the design of that that system at at the time. Since then, the system has gone through I think many iterations. They are Or customer centric. But ⁓ yeah, it was a bit of like a wake up moment of like I had never been exposed to like user centered design or like, you know, design in general. And I was like, ⁓ yeah, this is what happens. Like users are not really consulted in the design of technology. So that really like started ⁓ this like idea for me. And then from there, you know, I left that that firm and worked at kind of like smaller technology firms. And along the way, I picked up ⁓ methodologies like, you know, agile and iterative, you know, delivery and design and testing. ⁓ and really learned more about kind of like modern iterative software design principles, ⁓ which led me to, yeah, like kind of where like at this this fork in the road at some point. ⁓ you know, I really, meanwhile, I was very passionate about like giving back To our community or my community. I had heard about Code for America in the US and knew that they were starting up like a Code for America brigades network, which are essentially groups of volunteers who come together and, you know, hack on community problems using technology and data and design. And ⁓ and I thought, well, we really need to like have one in Toronto, which is where I'm based. So I met a few folks and ⁓ outside of my day job and and ⁓ we started Putting together like the first civic tech group in Toronto, which was Civic Tech Toronto. And we started meeting up and having hack nights every Tuesdays. And then that really took off in popularity. And ⁓ yeah. And then from there, actually, it was at a time in in the Ontario where the Ontario government had just hired their first chief digital officer. Digital started being a real priority at At the province. And so some ⁓ some public servants ⁓ from the OPS actually showed up to a hack night and were really like thrilled, like seeing kind of people in the community actually like wanting to contribute their skills for good. And so through some folks on the civic tectron side as well as on the Ontario government side, put together a bit of a proposal around like what if the Ontario government funded the formation of Code for Canada? Kind of like stood up an official nonprofit. In fact, one of our board members here now, Charles Finlay, was a part of that original group that helped to stand up that proposal with the Ontario government. And the rest is just history. I was like kind of part of that group along the sidelines. You know, first was on the board of Code for Canada for a bit, then moved into staff, kind of overseeing our sales. ⁓ and then eventually just that led me into the CEO role. And that's my story, all from, you know. Some bad feedback that I got at a dinner party. How embarrassing. Put me in my place.
speaker-1: That's so important, right? It seems like that helped really shift to actually understanding from a user's perspective what is Yep. ⁓
speaker-0: That was so serendipitous for you to get that feedback at that party.
speaker-2: Yeah, it was honestly it was like the triggering moment of just like, You're right. I had no idea that this is how people feel. Yeah. Real like enlightening enlightening
speaker-0: Yeah. How did you bridge the gap like from from materials engineering into Accenture? Like was there anything that you brought over, like anything that you learned that you were able to apply ⁓ that kind of helped you get into the world you're in?
speaker-2: Yeah, I mean, I think even though like I did materials engineering, there's a lot of kind of like basic engineering, you know, thinking and concepts that really apply to like, you know, technology and and ⁓ and the kind of work that that I was doing at Accenture. ⁓ and and actually a lot of it, you know, when I when we layer in concepts like user centric design and testing with users, it all actually comes together quite nicely in that like what engineers are taught in in university is like first is getting really clear on the problem, right? Like what's the current state? What are you dealing with based on all the, you know, the constraints or the criteria that is in front of you. So doing very like thorough kind of like assessment of like, are things working? Are they not working? And you know, when we think of that in terms of like a service or which has users, that includes like asking the users those questions, right? Of like, is this working for you? Is this not working? Did where are we thinking the problems are? in in this service that we're running or this product that we have. So so engineering ⁓ you know, drills that into into students like quite well. The next thing too is also what is like really drilled in to engineering students is documenting all of your assumptions and then using that to then move forward. Because I think there's like an approach, once you've kind of gathered all your information, it's easier to it's easy to kind of like fall on the trap of just like overthinking and over hypothesizing like like what could be happening versus really what that approach of just if you document everything and say, here are the things I assume based on what I'm seeing. And now here's what I think might be the solution and how, and we're going to test that solution. And we're going to use the information we gather back from that test to actually update my assumptions. That really just points to that iterative, that iterative process, right? Of like, you never know what you don't know. And you'll never know it till you actually do it. So what's more important is just at every every so often, every cycle, you're just documenting what you know and you don't know and moving forward and then and then checking in with that again to kind of like re reevaluate or rebuild your picture of reality. So yeah, then definitely a lot of like kind of frameworks and approaches taught in engineering really synonymous with like good user centric design and like iterative building.
speaker-0: Nice. Yeah. And and so Dorothy, ⁓ at Code for Canada, you you run programs that help bring extend the capacity of government and help them build the capabilities for the digital age. Can you talk a little bit about like what does it look like when public sector capacity building work is done well?
speaker-2: Yes. A couple I think a couple things happen. The first is like you start to feel like things feel different, I think among teams. Like once you kind of get a few, once you you help teams get a couple wins under their belt. And honestly, the wins could just be like, We finally shipped a thing. Like we've been talking about this thing for so long. And we finally took all of that talk and just translated it into a thing that we're able to demo to whether it's like our adjacent IT department or our executive sponsor or even to users. That feels really good for teams. and and it like gives them this like leg up in confidence. Like what we find is that once that thing gets shipped and they're like forced to demo a thing, they like actually really grow, grow in confidence of like, okay, now now we know more clearly what the problem is and where this thing needs to go. We can iterate on it and like let's show them again. and like demo demo it at the next, you know, the next schedule demo. So I think like the evidence of like capacity building and transformation starts there, just at that team level, right? Seeing people kind of come out of their shell a bit and like getting a bit more engaged in the actual work. ⁓ I think beyond that, like beyond that will that will go far, but it'll probably only go so far, right? Like you'll you'll have teams that kind of like build momentum, but then how do you actually take that and translate that into kind of more like broader capacity building and transformation, maybe high with the higher ups. And and here's where it's like it's a bit harder because you're trying to look for, you know, that that really comes down to who are the leaders, you know, do they care about capacity building? Do they care about transformation? And what in their eyes is are they defining as transformation? And so here's where you actually need a a bit of like a person who's leading a team who kind of knows how to manage upwards. Who can spin this or frame the stories and the benefits in a way that really resonates with that leader? ⁓ and then and once you've kind of like identified that, there are so many ways that you can, you know, show up, like show that next thing that really gets the buy-in and that capacity build of that leadership. And so a really good example, you know, that that we've found is we run this one ⁓ service that we call inclusive user research. It is a, we have a Pool of test participants from across Canada. A lot of these folks are from more marginalized communities, like think people living with dis ⁓ disabilities who use assistive technology to access services, newcomers who don't have English as a first language, seniors. And we engage these people to test technology. Like maybe it's like no surprise. I don't know. It's no surprise to me now, because I've seen it so many times. Most serve most government services are just like, pretty bad at at reaching these kinds of populations, especially folks using assistive technology. ⁓ and it you don't you have no idea how powerful it is to kind of show a leader, a government leader, ⁓ a video of like a a user trying to access a service and hearing them be like, I can't even my screen reader can't even identify that there's a button on the screen right now. Like, or I can't even get into this access into this service. Or like there's no like This login feature not even working for me. ⁓ and so having that evidence and showing that to a leader often like galvanizes them ⁓ more than anything else, than any other kind of like demo or feature build. It's just like the most, it's the most impactful form of just like taking that mirror. It's that, it's that moment that I just described, right? Of someone coming to me being like, that service sucks. It's the exact same thing. And and you'll find like there are so many. leaders, government leaders across Canada who have had that moment, who have been transformed, right? Like, well, I'll I'll refer back to, you know, one of our dear old friends in in the digital government ecosystem, De ⁓ Natasha Clark, former deputy minister of at ⁓ Government of New Nova Scotia, also had that moment. I think there was a moment she has a story. You'll have to ask her about the story, maybe on this podcast, of her moment where she received a tweet of someone complaining like, Wow, this portal like really sucks big time. And ⁓ and that was the one that she she had launched. And so I think it's those like those those like real moments that help to ⁓ like get through that like ceiling of to like push innovation to the to the highest level and really like get leaders to pay attention. And I think that's what capacity building really looks like at the at the higher levels of just like getting them to care and why it's important. And then from there there's all the things of like how do you now how do you get leaders to enable their teams to actually, you know, deliver value for for users now so that like we're we're not ending up in these kind of like moments where it looks like we have egg on our faces.
speaker-0: I love I love that you you are now kind of like your job is to create those moments. Like you you you had that that moment in the in the dinner party and now you're like trying to like give those out like little Johnny Apple seed. But it it's it's you can describe a problem to somebody, but what you're saying is you're showing them the problem, like in real life with real human beings and their their technology or their services, and and you're like You can't turn away from seeing it firsthand in that way. And that's such a powerful thing. And so in that, you're creating that that awareness and perhaps the desire to to change, right? But then there's that next gap, that challenge of okay, as a leader, you know that a change needs to happen. But the gap is do you know now how to change? Do you know now how to lead a team in the way that can solve these problems? kind of in a continuous fashion from now on. And I think that's the that's the next kind of big challenge. Can you speak a little bit about that? Because I think I'm I'm facing it now in my own work, right? Where you mentioned how do they talk, how do they define transformation? You know, that's not even there's no consensus on on what anyone means by transformation as an example. Totally. And even if you agree, you don't really know how to do it. And so how do we how do we bridge that gap?
speaker-2: Yeah, and that's that's the like million dollar question that like ke keeps us going and you know, helps helps pay the bills too, you know, 'cause like every government's just like trying to figure that out. literally like it's it's impossible to answer. That's the reality. Because it it ⁓ is case by case basis for like every single organization. It is so easy for people to be like, ⁓ digital transformation, a formula, it's blah blah blah. ⁓ regardless of organization. ⁓ but then when you when you get down to it, ⁓ every, you know, department in government has Different mandates, like similar mandates, but for really different mandates, different kind of makeup, you know, maybe their procurement works this way and another procurement works that way in another department. And so each one is almost needs to be treated a bit like a case by case basis, which is why I think what comes what it comes back to is that that approach of like, you know, knowing what we know and documenting those assumptions, but then knowing that we have to update those. And so that will only happen just by like testing different things. Because we're never we're never gonna get it right right the first time. And so I think the real there's there's a couple of things that obviously need to happen in order to enable that kind of like ongoing testing of like if we're gonna transform as an organization, what's gonna work and what's not gonna work, it has to start from the top, right? There has to be a desire from leadership that also like we leaders are like, We don't know what we don't know, but what we do know is we're committed to learning, we're committed to, you know, we're gonna try we're gonna experiment, we're gonna make a lot of mistakes, but we're gonna pick ourselves up and learn from that as teams. And, you know, ideally that's that's given that that ability and that space to learn is given to teams, right? They're they're given the space to to also learn and then escalate when they've when they've learnt something or, you know, have reached new blockers. And yeah, so I think it really does first and foremost come down to the leader of whether they are able to like create that, create those conditions for learning, which is hard to Right. Like that that is that's just like a hard quality to find in in like mu many people. And then on top of that, you add like kind of the pressures of what ⁓ of that role, right? In in governments parti particular, there's just everything always feels like things are on fire. There's always like a new fire. And the kind of stress that that leaders are have to deal with of like responding to the fire, also like there's not a lot of rope, right? They don't like a ton of wiggle room and yet they still have to And they like give room give teams enough space to be able to fail. Like it's a lot to ask of a leader to like manage all these conditions. So ⁓ and then sorry, then the last thing I would add to that, along with the kind of pressures of of that role, like maybe from the political side or like mandates that that are expected of leaders. ⁓ we now have, you know, new technologies like AI that are just also distracting like a lot of people. It's like as this other kind of Headwind, but also a tailwind that is like just taking, I think a lot of leaders' eyes off the prize of like, why are we why are we doing this work? Like, why do we care about transformation? To what end? Like, what's the benefit ultimately to users? And what I find, at least in my conversations with leader government leaders, is that AI is just really distracting them. Like they're they're they're now just getting kind of caught up in the technology and they're forgetting like that North Star. ⁓ so you put these all together and it's like, yeah, it's it's challenging for leaders. They're also getting super distracted, and like teams underneath are just like, Wow, what do we do? ⁓ so I do think that opportunities, like with that still, is like ⁓ the the the government teams that can find can that can take these like really challenging situations and like find the opportunities, like translate them into opportunities that serve those like Outcomes of like better services for people and again like bring leaders back to the North Star are the teams that are going to get through this storm, like this latest storm a lot faster. ⁓ and so one thing in particular, like the teams that have figured out like a can be used to rewrite my emails and write briefing notes, cool. But also it can be used to just like get that thing at the door faster. Like, my God, we've been talking about this thing for so long. And like, look, I can just like spend, you know, 10 minutes vibe coding. Now I've put together that same thing we've been talking about and and demo that to then show like like let's get this thing in front of again our adjacent IT group or business or like business stakeholders or maybe a small group of end users to get that feedback and like get that cycle of tests and learn going. Those are the ones, those those are the teams that are gonna like really pull through and bring us back on track to to those like digital government values. ⁓ because I I think like, you know, I mean, we we've talked about this before, Nick, like we're when Code for Canada started, it was like a different time, right? There were like Canada was riding off of a a wave of excitement that was coming out of the UK, out of the US, like out of Australia, like just like seeing all these other governments stand up like digital service teams and like and like harp on these values of like we gotta talk to users, we gotta test with them, we gotta ship, we gotta test and learn. And that seems to be That seems to like going away a bit. Like we don't hear that as much. AI we hear about AI a lot more. But it's like there is a world where we can bring AI and like bring it back to those things that really matter. ⁓ but it just takes it just takes some framing. Like it just takes people to realize, like, wait, can be the same thing. Gotta be a bit creative.
speaker-1: yeah. So for me, it's it's really interesting to hear that in the past there might have been more energy around digital transformation. There might have been ⁓ a more more awareness of some of the fundamentals, and now there's a whole bunch of potentially noise that's kind of crowding out some of the the really strong fundamentals. But maybe it was also that there were a number of Teams or units that kind of made it through the storm, they transformed their service area, but the organization or the institution wasn't able to codify some of the things that would have been needed for more teams to make it through the storm. Have you seen examples of We're gonna change this policy, this directive, this funding model. have you seen ⁓ that level ⁓ of transformation that goes beyond a project, goes more towards an organized. Like,
speaker-2: Totally. Yeah, that's such a great question. And, you know, I'm not like a scholar in this area at all. Like I wouldn't wouldn't use me as like I'm like Dorothy is the central source of truth. All all of my, you know, opinions are very like they're through a lens like that is a bit jaded. So, you know, you can take t take some of this with a gray cell. Like, I don't know. So I would say though, w with that, knowing that, ⁓ I don't think I have seen many organizations, little centric, user-centric organizations that have made it through the storm in the way that you just described, of like not just, it's not just at the project level. It's not just like training up some staff. Some of them have gone so far as like, hey, let's like revisit our tech stack. You know, let's like, you know, some of the more innovative ones have been able to build out APIs and, you know, even some of them are like care about open source. And so value that. So, you know, moving into that like heart of bureaucracy, I'd say like I've seen teams kind of ⁓ institutionalizing some of the digital principles through technology architecture. But then when you go layers deeper, like you know, budget cycles, procurement, that's where we see less evidence of that. And and it becomes it it becomes more obvious when you kind of hold up, if you go to like a government's you know, main website on their policies. Let's use the government of Canada as an example. And you're holding up the kind of like ⁓ I think they call it the ⁓ policy on digital directive or directive on digital. I can't remember the
speaker-0: The po the policy on ⁓ service and digital?
speaker-2: Yes, that's the one. And so that one, you know, was formed at a time. It was like ⁓ the Canadian Digital Service contributed that. And it was like, you know, ten great principles, being user-centric, you know, being agile, being data data driven, your decision making, all the great, all the great things. And you hold that up, but then you also hold up like another adjacent policy on like project planning and financial management. And the two policies like are totally conflicting. Like one is like Don't first make sure you're validating your assumptions with users before you're going to ask for budget for things. The other one's like, how dare you do any work before you ask for budget? Like, you better come with us with like 5,000 requirements, and then you'll get your budget. I'm very like, you know. Yeah, it's like so once you start getting like into those layers of of bureaucracy, like you start to see how the last mm you know, five, ten years of digital.
speaker-1: Yeah.
speaker-0: This is so true. This is real.
speaker-2: Have been great, th but they've all been kind of like layers that we've slapped on top of like old policies. And often it's the older ones that trump the newer ones. So like the end of the day, like digital projects just keep they'll hit like that wall of like, Well, ⁓ we need more funding again for the next phase of the roadmap, but they're asking for all the requirements of the next phase of the roadmap, which means we're in we don't have time to talk to users. We're just gonna make a whole bunch of assumptions about users to get that budget. Yeah. So I'm gonna say no.
speaker-0: That's it.
speaker-2: The long, long answer and short answer is no. I don't think I have seen any, you know, digital teams to that degree, like top to bottom, vertical, I don't know, integration. Is that what it's called? Mm-hmm. ⁓ I haven't seen
speaker-1: No. Okay. Lauren Hunter from last season, who's like legendary in the Canadian federal government, she was like, We need a policy fight club where if there are two ⁓ overarching or directives that are in conflict with each other, you need a committee of DMs to just like hash it out and be like, Which which one's gonna trump? Because we can't continue to have
speaker-0: No. that policy too. ⁓
speaker-1: these directives layered on to move towards digital government or a government that is usercentric or in a government that invests heavily in experimentation or test and learn. Like we can't have those things as add-ons. They actually need to be embedded as kind of the new fundamentals, but we we can't do that unless we reconcile these two different views, these two different models. Do public management. versus Agile State. Like like you can't have them both.
speaker-2: Yeah. And and that really does come back to that question you were asking, Dick, of just like how do we, you know, equip leaders or how do we like get to that layer and and make sure that they're creating those conditions that actually like enable transformation of teams. And my hypothesis, again, not validated, is like it comes down to that, right? It's like if you as a leader is ex are expected to work within policies that are extremely waterfall.
speaker-0: Mm-hmm.
speaker-2: Mm-hmm. And that's how your success is measured, then those directly conflict with like the ways that, you know, teens need to actually like test and experiment and learn. So it's like
speaker-0: So there's there's on learning to do. Like the thing about the the policy on service and digital is that when I was there, the federal government, I felt like we had everything we needed. With that policy, I have more than enough direction to do what needs to be done. Yes. But the thing was, I don't think there's somewhere between like a lack of digital literacy to even understand the implications of that document of that policy. Right. And then even if you did see the value of that. policy and and the subsequent directives. You didn't know how to execute it. Like you didn't know how to do the the actual practice required. And that would involve on learning some of the waterfall things. That would involve unlearning some of the more conventional approaches to the work. And where do you get the opportunity to do that? And my my hope at the time was the digital accelerator inside government was the opportunity for people to practice new ways. Yeah. But I still love that document. And I love the strategy map that came out of it. And I'm like Just do that. If you could just do that, then you're s
speaker-2: Yeah. Exactly. Yeah. We we were like we always just fall back to that document of like, you know, if there's governments that are like, What's our north s which north star should we falling? I'm just like, go to the federal government's page, like
speaker-0: Here it is.
speaker-2: ⁓ yeah, and it and it's so it's just like that that great thing is just so contradictory to everything else that already exists. It's like a bit like gaslighting, you know? You're just like, ⁓ yeah, you can do digital, these really great things. And like, ⁓ by the way, well better not do that.
speaker-0: No, you can't.
speaker-1: Right. Well, you can. You just have to pass through the eye of a storm. And, you know, some of us are whatever it is, like we decide, yeah, well I'll try it and like I'll keep I'll keep going. But our colleagues who are probably ⁓ more sane are just kinda like, Yeah, I'm not passing through that. Like I can see that storm. Like I know what it takes to get through. I know I probably won't make it. So I'm gonna stay
speaker-2: Up the port. Yeah. Good luck. Yeah. Totally. Which like I know now this is getting into another another thread, but I I think it is a really important one is that like this whole like we we talked about this movement in Canada has like slowly been, you know, like I don't know, dissipating, maybe like everybody's kind of going in different directions. And and there's like other there's like major macro trends that are affecting that, you know, with AI, there's like, you know, movement kind of surging from the US around like government efficiency and like and all that stuff. And so that that might be also affecting the state of the digital government movement. But also it's just like it's exhausting, right? Like like trying to like we're so far we keep calling it like storms. Like weathering storms and whether we're like ready for that. And yeah, the leaders that have been like pushing to get through that storm, like maybe they capsize. They're just like, I'm not gonna try and get back up. I'll just Wait till someone rescues me now. Yeah, it's it's a it's a tough it's like a long slog. Yeah, and so that that could also be the thing, right? We're like losing losing people 'cause ⁓ it's it's tiring to constantly be like pushing against the tidal wave of policies.
speaker-0: Hm, ⁓ yeah.
speaker-1: So so Dorothy, would you describe the teams that Code for Canada spends the most time with as of your innovators or your early adopters if you're looking at the diffusion of an innovation curve?
speaker-2: Totally. Definitely early adopters. And there there's always gonna th they will always exist, right? Like even though we just talked about like, ⁓ yeah, it feels it's exhausting and there's not a lot of a lot a lot of folks left. There will always be kind of those people who are just like their interest has peaked just enough to be like, wow. Like maybe they're a bit newer to government. And they haven't yet gone through that full they don't have that full historical context. But like things can be different around here, and you're like, ⁓ yeah, yeah, like I like. I like that. I like the way you're talking what?
speaker-0: Come with me.
speaker-2: ⁓ and they don't they don't know what they're in for yet. But ⁓ and and honestly, that person could be a new public servant, but they also could be a longtime public servant that's just like always been a bit frustrated. They've like learned the game, right? They know how to like navigate procurement and all all the like weird things. They've just like flown under under the radar, kind of like finding little loopholes. But yeah, they're those people are out there. And when you find them, it's like It's super invigorating to get to like you like you you you explain the kind of work that that we do or like this this digital work. They they match it up to like what they've noticed as like, ⁓ yeah, I've just I always knew things didn't work around here. I just didn't have a word for it. ⁓ and then you marry those two together and it's just like light bald moment. I'm like, well, we're gonna we're gonna try this. We're gonna try and do it in do things in a different way. Yeah. So I'd say that that also qualifies as an early adopter. Like a a l be in very seasoned public servant. But an early adopter.
speaker-0: Yes, absolutely. They're early adopters of your program. Like you've created you've created the program, the opportunity for them to try new things. So they're early adopters of that. And once they're in there, then they become innovators in that they're now innovating a product or a service inside. And now they're looking for early adopters of that.
speaker-2: Exactly. Yeah. Yeah. And we we like really evolved our model. I guess I should I should probably describe this to listeners out there, but we when we first started as Code for Canada, we used to run a program that we called the Fellowship Program, where we would recruit teams of technologists. Often they were in groups of three and kind of looked for that trifecta of technology development roles of like product manager, UX designer, and a software developer. And when you kind of marry those three three groups together, like you've kind of got the the perfect team to build, you know, really great software in an iterative way with users. And so we would always kind of embed that team of three into government and help government teams deliver a great service, then also coach them up to to be able to keep that service running after we're gone. And over the years we have evolved that model just in response to what we noticed with governments and that like, One is that, you know, government budgets are slimming and so they can't always afford like a full team and they might just need one person or one or two people. ⁓ and so we kind of like slim slim that like made made the options a bit more flexible for governments. The other thing too is we're noticing, you know, let's say the governments can really only afford one practitioner and not three, then but they but they still need all those skill sets. And, you know, enabling our staff to be able to know a little bit of design, a little bit of you know, development and and a little bit of product management while they still kind of maintain that like central craft. Maybe they came as a product manager, but they're like learning a bit more of development. And that is definitely a lot more possible these days, like with the state of AI and like LM lately. People who have never coded before can now like a designer can quickly prototype something much faster and in a way that gets like much more robust feedback. So yeah, lot lots of opportunity too for governments to gain access to those skills nowadays with AI and just with like the state of, you know, technology labor kind of shifting as well to be able to leverage AI more effectively.
speaker-1: Very interesting. So assuming you have a leader with the right vision who can mobilize enough resources and acquire acquire a mandate, then ⁓ you know you've have outside partners like Code Canada that can come in and help actually kind of build support for your team to execute. It sounds like the the cost for entry or whatever it was required. 10 years ago is potentially a bit less. I guess my big question is what does it look like, not for the early adopters or the innovators or the teams that fit that profile, but kind of for your early majority? So, like a team that is like, my government has a new mission on affordability as an example. And we got to move fast in order to improve access to benefits for citizens. What does capacity building look like in that kind of a context where there's not like, you know, somebody that's heard about Code for Canada for years and has just been like waiting for an opportunity? Yeah.
speaker-2: Yeah. I mean, for the most part, we're always trying to find those opportunities where like we actually kind of fly under the radar a bit. Like we don't ⁓ we don't love to come in kind of like guns blazing, like, hey, we are not from here and this is how you should do things. Although some governments do like that. So so we'll do that too. You know, whatever they need us, whatever role they need us to play, we'll do. But but for the most part, yeah, we want to kind of come in and like tag on to an existing project or mandate, right? Like new thing needs yet. shipped quickly, ministers asked for this new portal or dashboard. What do we do? And yeah, I would say the first thing that we're we're doing is like obviously doing that like current state assessment right to understand like, well, what's what's the purpose of this portal? What who are the users? How in what ways have they been getting the information they need now? How how do they not get that information? And ⁓ what we call for that, for that initial kind of currency analysis, we call it options analysis. So it's really just trying to like figure out like what's the deal, what are we trying to do here? What are our options in front of us? Should we be like prototyping something pretty quickly? Do we need to present it in a way that like shows interoperability with existing systems? And the key here is that process could take months, but for the most part, we don't want to wait that long. Because if we did, then we'd just be another government team. So we're just trying to get government teams to move a bit more quickly than they're used to. And so this is where leaning on things like AI, right? To help us prototype more quickly and get that feedback cycle and just get the conversation going through demos, through testing is like the ultimate, like most important thing we want to do like right off the get-go with with any. any project or any partner. and then from there, essentially what it becomes comes down to is kind of like what's the reaction to to the to the prototyping and to the demos. We might end up with like really negative reaction. We might be like, well, like this is this thing that you build is not going to work for all these reasons. And so like this makes no sense. It has to go back to the drawing board is is like better than getting no reaction. Like we would rather just have people like come in maybe hating the thing, but giving us really negative feedback. Again, it's that dinner party moment, right? Like, God, this thing sucks. But what it does is it just gives the team direction to then be like, okay, like, what did we learn? How do we now like, how does it take us like one step closer to that next final product? And and then I think importantly along that whole journey, it's like engaging the leader, right? The leader who at the end of the day is gonna have to maybe demo this new portal or dashboard to their leader, whether it's like the minister or whatever. And getting them bought in and engaged in the process so that they are understanding how what it takes to build technology, like how it works and how teams need to work around technology. But then also like they're just like getting into it. Like leaders who understand the business, who understand the service and like the risks of the service are just like better leaders. Like they're more well spoken, they're like more respected by their staff. And so those are those are things that are like actually kind of easy to do to like build up that confidence in a leader just by kind of engaging them in the work and and showing them the work more often.
speaker-0: That's a good segue to advice you would give to folks on the inside.
speaker-2: The inside.
speaker-1: Piece of cake.
speaker-2: I mean it's hard 'cause like, you know, I've actually never been on the inside, so is this advice legit?
speaker-1: We'll let you know.
speaker-0: It's novel.
speaker-2: Yeah.
speaker-0: Fresh eyes on the problem.
speaker-2: Yeah, yeah. Yeah. Okay. Okay. I like it. Okay. I guess some advice. And I'll pick I'll like nitpick at the things that I've where I've seen like really good ideas like fall flat. The first is like befriend the procurement people. ⁓ maybe maybe mm like give ⁓ some cookies, bring in box chunk. I don't know if procurement people like that. But befriend the procurement people so that you can understand how things work. How Does that procurement black box work so that you can get the thing you want and need at the end of the day? I think there's like a massive, like there is just this giant chasm in the value chain of government that is like procurement. It's like that's the chasm. And it's just like all this work went into like figuring out, maybe you did all the work of like, I know exactly what I need. I know exactly what the user's problems are. But then if you can't get from like that point to the the next point, which is just like now I have people that help me build the thing that I know I need I need to build or have this SaaS service that I know for sure we're gonna need. ⁓ if you can't jub that chasm, like, like what was what was the point? You know? So I think that's a big one. Here's where I think like I don't know if that's like legit ⁓ input as an outsider, because like maybe people do know they're procurement people. Maybe there's just like It is just like a black box. I'm I'm really not totally sure like exactly how it all works. All I know is that that's just like the biggest risk to any idea kind of taking off government. That's one. I don't know, like Nick you've worked both of you, Nick and Jay Z, you've both been on the any like, is that valid?
speaker-0: We're asking the questions here, Dorothy.
speaker-1: And yes, all roads pass through procurement.
speaker-0: Yeah, yeah. Yeah. Yeah. I no, I I love what you're you're saying about befriending procurement. Cause I think I think it it's any of these functions are a black box if you're outside of them. And they'll remain a black box if you don't have a friend on the inside who can help you see it and understand it. Yeah. Yeah. and I think I think that goes with with policy. I think it goes with with finance. I think it goes with any of the the functional areas of government that oftentimes And it's not just the innovators, like people on the inside perceive them as barriers, right? And the attitude is you're not here to help me. You're here, you're gonna make it harder for me if it's HR to hire someone. ⁓ if it's procurement, it's to to contract someone. If it's policy, it's to get the the policy through. Whether it's a memorandum or whatever you're doing. If it's finance, it's the it's the budget giving me the money, whatever. ⁓ and they all have their own processes. But
speaker-1: Yeah.
speaker-0: I have been doing a lot of work with folks in those functional areas and they all want to be helpful. makes it almost impossible for them to be helpful is being brought on at the tenth hour of something. Right. And and I think that tends to happen. I think I think there's a a pattern in government where we are rushing to get things done. And so we like cut corners or we don't bother with all of those folks bringing them in early. And then it takes longer because we didn't do that. And so like the rushing is c is actually gonna make people say, ⁓ three months is a long time. We don't have three months and so you rush and get it done in three weeks and then six months later you're still trying to get it done because you rushed in the first in the first place.
speaker-1: Yeah, I I I totally agree. And I think this came up quite a bit in the previous season is that sometimes you need to go slow in order to go fast. If you're in government, you need to understand the fundamentals of government. And so this analogy that we've been using, passing through the storm, often describe to my teams that we're on like a seafaring vessel, and you need to understand the vessel. In its entirety. You need to understand the rigging, you need to understand the storage, you need to understand the sales. And it's only once you've mastered those fundamentals that you can navigate well. Now that's our current context. Should we still be using a sea faring seafaring vessel that was designed in the 10th or 16th century? Maybe not, but it's the vessel we're in right now. So if you want to navigate. Or if you want to bring it to a better place, then you gotta understand all of the systems well. And to Nick's point, those functional communities are more than happy and really excited to engage, at least in my experience. But timing matters. The one conflict, though, that I've seen between program policy, digital transformation teams, and some of these functional teams is that we're all coming at like innovation and transformation slightly differently. And so more often than not, our innovation work works across purposes. And so I think that's one of the areas where leadership ⁓ really matters to say we're all doing really important work, but our organization needs to respond to this need and we need to do it collectively. And that's that's a that that's a kind of leadership that I think we're seeing more of. Missions is certainly like a framing that allows for that. That narrative and a bit of a vision of the whole organization going towards that North Star. But it's we've been optimizing for decades in like silos. And I think the creative challenge of those of us that are still in government or work closely with government is to break those silos down and help the organization see itself as an entity that needs to approach a particular endpoint, but do it in a way that's really efficient. really effective, collaborative, and works with outside partners or partners outside of the institution as well. Cause these are complex challenges, many stakeholders. That'd be my two cents.
speaker-2: Yeah, that was a great
speaker-0: Now Dorothy, we want to know if you had the top job, let's say you were prime minister, premier, chief digital officer, CIO, whatever. But top job, queen for a day, what would you do? What would you do for one day? Like it's a for a year.
speaker-2: Right. Yeah.
speaker-0: For yeah. It's I was riffing off of the saying. But yeah, like if if you were wearing the crown and and you you had that level of that power and influence ⁓ in in a government organization, what would you do to enable the kind of transformation you think we need?
speaker-2: Yeah, I mean, okay, I think first it starts with like a goal. Like and it's gotta be like one of those, what is it, big, hairy, audacious goal B hag. I think
speaker-1: Yeah, the Jim Collins being here.
speaker-2: We need like a goal that is like very and audacious, but also just like a good one. Like, you know, better services for everyone. I don't know. Like pretty simple, plain language, everybody ubiquitously across Canada, you know, could mostly agree with. No one wants like terrible services, so like So I think like start with a BA. Maybe step one. Mm-hmm. Step two, I guess with the B Hag, I'm thinking about like what are those outcomes that would lead to that BA. So if it was like better service for everyone, like pick the like, you know, three, five ones that are that like put us on the map to say like, yes, if we did these, we're gonna like drastically improve our ranking on the e-government index. I don't know if you folks and folks listening are familiar. We're UN does this like e-government index and we're like so low now. So like like that's embarrassing. Let's like Bring us up a bit, also, you know, figure out like what are the three to five things that will trend us back upwards. Which I feel like shouldn't take too long, right? Like I wouldn't want that to turn into like a one year project, let's say, which it could easily be like, what are the three to five services we're gonna improve? So we're gonna like make it quick. We're gonna like we're we're picking we're picking a handful. ⁓ And then from there, once we've like narrowed our focus on like what are those like OKRs, than really setting up the teams, the leaders and the teams under that to like create accountability in the system. So if there's like things that we already know are like hot spots in where ideas go to fail. It's like where, you know Budgeting policies don't match like user centricity agile policies. So like let's like zoom in there and be like, what is not working? Let's get that like DM fight club going and like attack that problem. So like maybe SWAT team goes there. Another one is like where certain black boxes, right? Or like stakeholder groups being engaged just like way too late. And that's just just Creating like major stall later on. So maybe it's like procurement, maybe it is HR if we need to hire folks. Maybe it is like finance. ⁓ and so like getting clear on those broken parts of the process, and we like engage them sooner, we like get ahead of those problems sooner. So I think that's like, okay, so now I've addressed the like hot spots, like, okay, this is what's gonna trip us up pretty soon. We're like getting ahead of that. Then I think the rest of it is like. Honestly, just kind of more textbook in terms of agile and digital transformation. So starting with, you know, that like current state assessment of like what are our serv what are out of these three or five services, what do they look like? Let's like get a bunch of teams around those services. Like hope ideally they're like, you know, how to do user research, know how to do service design, know how to like assess like a technology stack. ⁓ yeah. And they're just like building like a kick ass current state assessment. And they're like, okay, we see all the problems. It's this, this, this. You want to de-risk these three to five services. This is it. And then we execute and we get all the teams in. It's like shipping, shipping, shipping, and testing and learning. And then finance is like and procurement, they're like they're like in they're like in the demos, right? They're like engaged. They're like, ⁓ yes, we see how like This is this is how the team works. They're gonna work in this like agile, iterative way. And procurement's like, wait a minute, you're gonna reach this blocker like three sprints from now. Let me start getting ahead of that and start a conversation, you know? And like legal saying the same, like all these groups are just like jumping ahead, being like, hey guys, you haven't thought about like six steps ahead, but let me help you with that. ⁓ it's just like everybody's rolling the same direction. And then I can just like chill in the pool. You know, I dial in the Zoom meeting, like catch the update. Everybody's just like really engaged and working and like they're so do a baseball game. And then I show up at that thing. Then they they like and they love going to work.
speaker-0: Mm-hmm.
speaker-2: 'Cause yeah, they're just they can like deliver results together and they're and it's like fun time.
speaker-0: Yeah, and that speaks to the beginning of our of our conversation today, just like that people feel different. They feel the the difference. And so you're creating that opportunity for them to have that experience, to feel the difference of working in a different way, and be able to show something that will attract more people to working in a different way.
speaker-2: Yes. And then ⁓ yeah, one root one year rolls around and we get that. And then the UN is like knocking on our door, being like, Hey, guess what? We just did the assessment and like you're no longer in fiftieth place on this index. You're up to like 30 after one year. We're just like, like what? We did that in one year, guys. Like let's do it for another year. And then we're gonna crush it. And we just like then we end up back in number one. It's like
speaker-0: So good. ⁓ man, this is the Blue Jay story. You're the comeback kid. You'll you'll be the new comeback kid.
speaker-2: I know. This is hopefully the the way it ends.
speaker-0: Like, I'm really hoping. Really, here's the hoping. Here's the hoping. I know I had to for the end of the show. And ⁓ we wanna we wanna get into this rapid fire. These are rapid fire questions. So we're gonna throw out some questions and ⁓ you answer them as quickly as you can. My first the first one is and my favorite one is government works when
speaker-2: He said we weren't gonna talk about it. People are empowered to ship and demo and learn.
speaker-0: Nice. That's the title of the episode. If government was a sport it would be
speaker-2: It would be spectators sitting on the side of like a soccer match. Like they're but they're sitting, that's the sport. It's the spec. Yeah.
speaker-0: Okay. The sport is is watching. Okay. And what are your top three favorite mental models for transformation? The kind of like how you think about transformation.
speaker-2: Yeah. People process technology. ⁓ just that like framework for just like understanding an organization from top to bottom. Test and learn. So that cycle loop, you know, just shipping something, testing and learning. And the third one, I mean, this one's a bit like ⁓ further out there, but like I I I would love us to get to this state is like government as a platform, government as a product, you know, that like layer cake.
speaker-0: Mm-hmm.
speaker-2: that David Eves has is like there's that like database layer and then there's like a services layer on top and there's like a middleware application layer. ⁓ I like I like that one nice.
speaker-0: ⁓ and your two two books that have had the most impact on your approach or that you would recommend people read.
speaker-2: Recoding America. That's the one by Jen Palka, founder of Code for America, our sister organization in the US. So definitely good read. The other one, not not really a book, but like just like at a online resource. The 18 F D Risking Technology Projects Guide. Very good.
speaker-0: Hmm. Nice. Nice. Do we have time for yeah, go ahead.
speaker-1: We have to have time for one more. Is there anything that can't be taught?
speaker-2: It's hope. I think I think it's just like it's like hope and belief belief in yourself, in others, you know, assuming best intent by by all teams, you know, whether it's your team, your colleague, your procurement team down the hall. Yeah, those are things that are like they're really hard to teach. And there's just so fundamental to like keeping things moving forward. And keeping momentum and until things reach that tipping point, right? Like you just need enough energy to reach that tipping point and then hopefully things just roll on their own. But ⁓ yeah, you need a lot of like optimism and hope to get to get up there. Maybe it can be taught, I don't know.
speaker-0: That's a great answer. No, I love that answer.
speaker-1: That's ⁓ that's a good place to stop. This was such a great conversation, Dorothy. Thank you so much.
speaker-2: Thank you. Likewise. It was so nice, ⁓ catching up with you both me here. It was really ⁓ therapeutic for me to just
speaker-1: That's what that's what we do. Therapy.
speaker-0: That's it. That's how we do. Yeah. All right. Have a good day and go Jays.
speaker-2: Go Jays go.
speaker-0: But ⁓ man, Dorothy Ng. So so insightful, man.
speaker-1: so good. He was I haven't had like a long conversation with her. Yeah. She's funny.
speaker-0: Yeah, yeah, yeah. I know.
speaker-1: I really loved the origin story that she had, kind of starting at Metrolink, thinking everything was great, and then being confronted with unvarnished user feedback. ⁓ that thing sucks. ⁓
speaker-0: That's so good.
speaker-1: And you know, she mentioned designing for institutions versus designing for people.
speaker-0: Mm.
speaker-1: And then I really loved her perspective on the Code for Canada origins. So it was a good example of like top down, bottom up, and then inside out kind of engagements across like the stakeholder communities, which eventually like spat out Code for Canada, which was which was super cool.
speaker-0: Mm-hmm.
speaker-1: In terms of when capacity building works well, I really loved how she articulated like people feel different.
speaker-0: Yes.
speaker-1: And that leaders have that moment, that experience where they see when what they're responsible for isn't kind of up to the task. So as she was describing, like the use of the inclusive users research network that Code for Canada ⁓ curates and how bringing that to the table has been really good to get leaders engaged. But
speaker-0: Mm-hmm.
speaker-1: Then I loved how we started talking about the limits of how far COF for Canada and others can go ⁓ in terms of public sector capacity building. ⁓ that, you know, leaders are being bombarded by information and pressures and shiny objects and teams have to be able to pull them back. That organizations are struggling to go from projects to transformation projects to transforming teams to transforming their organizations. But she's not really seeing that. And then the fact that she was like, you know, this is really hard. And maybe people are just dropping off. Like you advance one novel thing, two novels things. And then You look and you're like, I'm not going through that storm again. So part of me was like, Holy maybe we're just losing people and we're not refreshing that that network of public sector innovators at the rate that we're losing people, which I hadn't I hadn't thought about.
speaker-0: ⁓
speaker-1: Yeah. So that's what I
speaker-0: Amazing. Yeah. You got the last half of the the podcast that I didn't get. So that's great. My my f my favorite part wa also was the origin story. Like that just like w right out of the gate in the interview with that origin story, couldn't have you couldn't have written a better origin story in my mind. Like she went from materials engineering to consulting.
speaker-1: Yeah. Mm-hmm.
speaker-0: Doing systems design and got to work on, you know, a service that is just so massively used in Toronto. And I remember when that first came out as well. But like her first time and and getting user feedback at a dinner party and how like that shook her. What I loved about it was that she, in that story, she goes through the journey that we want most public sector. people to go through and most executives to go through, which is the practice of designing from the inside out, designing for institutions, for organizations, then having the aha moment hit you in the face when you realize, ⁓ this isn't working for the people that are meant to use it. And there's actually a way to do this that works for the people that use it, that creates a better experience. And so learning the value of feedback from users.
speaker-1: Mm. Mm.
speaker-0: And then she finds herself leading an organization like Code for Canada, where a big part of her job, not explicitly stated, is to recreate that experience for executives in government. It's not explicitly stated, but that is that is largely like what success is for Code for Canada, is helping teams inside government do the work necessary to have those aha moments and share those with decision makers.
speaker-1: Mm-hmm. Mm-hmm.
speaker-0: So that they invest more in in that work.
speaker-1: Mm-hmm.
speaker-0: You couldn't Marvel couldn't have written a better origin story than Dorothy's.
speaker-1: Yeah. And it's it's pretty cool because it gives her I I think it gives her a sense on what it looks like when that realization happens. I remember years ago ⁓ hearing Adam Cahane and his team from Rio's partners speak about facilitating conversations across stakeholders in complex spaces and the team ⁓ Him and the team are talking about the click or the click. Like this moment that's unspoken when all of these stakeholders like just kind of get something and you like it's not audible, or maybe the silence is what's audible. Anyway, he's like like you know, you know when it happens. And ⁓ that's probably what Dorothy can pick out and the rest of the Code for Canada team. that's so cool.
speaker-0: Cool. And and clearly able to empathize with folks who have not yet like arrived at those same clicks or aha moments, right? Like, you know, she can remember when she took for granted the weight like the status quo. And then having that, you designed that? That thing sucks. Which needs to be the title of her episode, I feel like you designed that. That thing sucks.
speaker-1: Right. But ⁓ but again that there are limits. Right. You can get that moment of realization at the executive level. You can support the teams to move faster and to, you know, go from taking six months to decide on like what the look and feel for a service should be to six weeks where you do a whole bunch of great discovery, kind of use your research, you do some rapid prototypes and you just like get ideas and options in front of people to get their real feedback. But that can happen at a team level, that can happen at a project level. But ⁓ nothing ⁓ really driving towards, okay, how does the organization kind of move to that that model? Or what what are the directives and conflicting policy or conflicting incentives that help an organization go from waterfall being the base ⁓ of model of how things are approved and strategies form to something that's more agile and user centric. So there's there's always gonna be tension unless you get into kind of rebuilding some of those ⁓ those f foundational rules and and processes.
speaker-0: You it's like you almost like you need that that thin slice from from the very top of a department or organization all the way down to the front line where there's someone, you know, whether it's the deputy minister's table or s the the C suite table, all the way through, you have managers through that are empowered to do the necessary thing. So going from the team level designing services to I using that as an opportunity to identify the policies, the legacy policies, the legacy processes, the legacy structures that are in the way of meeting the needs of the beneficiaries of your services and your programs, all the way to the strategic level where you're continuously feeding, you know, findings from the front lines, findings from the service level to the strategy level. And using that to manage your the performance of executives all the way through. ⁓ and I don't think that we
speaker-1: Mm.
speaker-0: We have that in many places.
speaker-1: Hmm. Yeah, no, no, I haven't seen like the full slice. Maybe, maybe in in some areas, ⁓ yeah, again, this came up in in the interview, but missions is potentially a way where you can kind of go from your like what is the impact on the ground, what's changing on the ground, are we halving the poverty levels or we improving mental health for youth by X percentage?
speaker-0: Are you?
speaker-1: And that being like a political accountability and making sure that the public sector is lined up from the deputy minister all the way down to achieving outcome. But I'm most curious about when you can create a slice ⁓ that makes sense? How do you then grow that that slice? how do ⁓ use that new business model? to take over the existing business model of your public sector institution.
speaker-0: I mean, maybe that's a question that you answer when you get there. But somebody I no, it's a it's a fan it's a fantastic question. I feel like to where I'm where I'm at in the year, I'm thinking like if I can just get that victory. And I and I'm thinking too about that connection between mission oriented government and the service level and how do you make the connection between the particulars of a service experience and
speaker-1: He's got for asking that question. Mm, mm.
speaker-0: the grander challenge, the grand challenge of things like ⁓ you know, homelessness and and poverty and climate change, et cetera. So I think that's a huge, a huge question and opportunity in terms of expanding the slice or the island of coherence, is that where is that where capacity building comes in? Is that where we start to think about Once you get that foothold and almost that that thin slice is the early adopter slice. And now you're thinking about how do you facilitate the adoption of these roles, these behaviors, these performance metrics, these decision making frameworks out. And what does that look like?
speaker-1: Mm, mm. Well, Policy Fight Club, it keeps coming up.
speaker-0: Okay. ⁓
speaker-1: That's definitely one of the one of the ways to try to go from creating a new set of rules and practices and patterns and resolving any conflict that this new slice has with the existing slice. And I think, yeah, like in both of our experiences and the people we've been interviewing, it's not like they've been breaking the rules or breaking the law. It's more that
speaker-0: Right.
speaker-1: you know, agile requires a new or an expanded set of rules or a different set of rules. And that we've been adding these new kind of rules directive on program experimentation that we have at the federal level. It's another good example where it's like layered on top. Mm-hmm. And what we're not doing is kind of pruning the things that might have been
speaker-0: Yeah.
speaker-1: really relevant rules and directives in the sixties, seventies, eighties, nineties, but in the two thousands, the twenty tens, the twenty twenties, like it's time to now kind of prune those back. And I don't know if we've been doing that as intentionally as as we probably should.
speaker-0: Right. Like reconciling the the conflict between policies. This is the fight club. Yeah. Or or Loki's ⁓ time variance authority where have to prune prune the timeline. Yeah.
speaker-1: Yeah. Yeah.
speaker-0: I don't I don't remember who wrote about this. I don't know if it was Dana Chisnell or Jennifer Polka, but this concept of red policies and blue policies. Do you know this one? Words like
speaker-1: Hmm. No.
speaker-0: One one version is is an actual policy, the other version is a policy interpretation. So when someone says someone says we we can't do X, Y, or Z because of whatever policy, then you have to go and find the policy. And what what they found was that much of the time there was no policy. It was just the way people did things. ⁓ and it was maybe based on an interpretation, you know, eons ago.
speaker-1: Mm. Mm-hmm.
speaker-0: Yeah. That's stuck. That's stuck. And I love and this has been coming up in my work lately, where people will will talk about we can't do X, Y, or Z because of this policy or these departments have conflicting policies. This is the opportunity to identify that very specifically. Like don't just say that in an abstract way. Be very specific, like this policy and this policy and show because we can't you'll never prune.
speaker-1: Uh-huh.
speaker-0: the timeline if if you don't get very specific about where those things are. And this is the value in service design, I think. If if if you were doing the work to identify what is desirable in terms of the experience and the outcomes for the people that we're serving, and you then encounter some policy or law that makes it unfeasible to accomplish, then you then have to go through the work of changing that policy or law.
speaker-1: Mm-hmm.
speaker-0: So that you can do the the positive thing. And without having people empowered at the higher levels to do that, based on the findings of the folks doing the design work, you can't do that. And so I think it just needs to be ⁓ an embedded part of of the new world for government.
speaker-1: Hm, one hundred percent. When we were leading on ⁓ program experimentation for one of the departments federally and we were working closely with central agencies to support more program experimentation, one of the values was explicitly to identify where there were friction points. running all these experiments will help us better see ⁓ what's slowing us So we need ⁓ to keep like ledger of friction points. So as part of my team's tools for programs and service units that wanted to use a new or novel policy making tool, be it like prizes of challenges or human-cepter design or whatever, ⁓ we were like, okay, document What was the objective, the things you tried, some of the outcomes, but what were some of the the friction points? What were some of the barriers that you were that you encountered? Because we wanted to see all the things that needed to be worked with to make it easier to do kind of program experimentation more systematically across the organization. We passed my list to a few central agencies.
speaker-0: Mm-hmm.
speaker-1: But yeah, to your point that that wasn't really anyone's job. Like to actually like pay attention to the friction points and then to ⁓ to resolve them.
speaker-0: Yeah. A hundred percent. I I used to call that when I was at the Digital Academy and we were running the digital accelerator program, like the prototypes coming out of that program needed in its sort of next level of maturity, needed to be treated as probes to the system to understand what what is stopping this when you go back to your home departments. What is stopping this, preventing this from taking root and growing and scaling? And we need that feedback so that we can start to address the
speaker-1: Yeah.
speaker-0: the contextual barriers. And I think this is why you have like parallel learning structures in organizations or like parallel organizations. And I think this is the this is huge value of the reimagine G and B initiative that I'm part of right now. Is that this is there's no one is no one's job right now, but this could become this program's job to continuously keep track of what's stopping us. And feeding that to decision makers and have that in as an embedded part of the decision making cycle.
speaker-1: That brings me back to one of the other things that I loved about Dorothy's reflections on what she would do if she was Queen for the Year. Creating accountability in the system, I think that's how she framed it. Trying to really map out if, you know, the government of the day had a transformation agenda, what's gonna slow that agenda down? And being really clear at the get-go, like what are some of the friction points that
speaker-0: Yeah. Mm-hmm.
speaker-1: the organizational leadership needs to needs to work through. ⁓ and I think we often skip that step, kind of get right into the build, right into the design work, but we don't do some of the critical preparation to split it away.
speaker-0: Yeah, what did she say she would focus on establishing like the OKRs and performance metrics?
speaker-1: Yeah, vision and OKRs to start.
speaker-0: Yeah. You change I mean there's a huge power in in changing what you measure, right? And I think
speaker-1: Class. Mm-hmm, mm-hmm.
speaker-0: That's a smart w like precondition to success that she focused on.
speaker-1: And I was at a political day this year and the former deputy minister of digital transformation of Ukraine was there she she was a panel related to exponential technology and government. ⁓ As you know, Ukraine went being pretty low on the digital readiness. ⁓
speaker-0: Mm-hmm.
speaker-1: ⁓ rankings to being kind of in the top five over a very short period of time. We all know why. But she was like, if I had to pick two things to focus on to really get my government ready to to take advantage of new technologies, it would be a vision of what we want and OKRs. I was like, there you go. it wasn't like ⁓ Digital accelerator. It wasn't give everyone a blockchain ⁓ a quantum computer. It having clarity of of where you want to go and ⁓ having a way to determine if you're there or not.
speaker-0: Yeah. Yeah. Why is that lacking? Why is that so hard? I mean, it it's not like the it's the first time anyone said that ⁓ leaders have to have a vision.
speaker-1: Mm-hmm. ⁓ I don't know. Maybe maybe it's that it's harder ⁓ to have a that's precise. You know, when we were chatting with Sarah around mission-oriented governments, ⁓ she was like, You need to precise about what you're after. Otherwise, it's, you know, I I wanna make innovation accessible or ⁓ we wanna be ⁓ a lot better at pick your social policy challenge or economic ⁓ policy challenge. that that's not precise enough. You need to you don't wanna be overly precise, but y you have to provide some some boundaries around what is in ⁓ a success perspective versus what is out.
speaker-0: Right. Hmm. Cause from from my standpoint, I would prefer a a audacious and ambitious vision and then find precision from there, if that makes any sense. Then the goal of a vision being precision. My concern with that is that you immediately are constrained by what you can imagine is precise. Like
speaker-1: Mm-hmm.
speaker-0: I think with metrics in general, it's like we will we're more likely to I think to choose what we know how to measure than what matters to measure. Yeah. And it's like I'd rather you pick the thing that matters and have no way of measuring it than pick the thing you know how to measure that doesn't really matter.
speaker-1: Mm-hmm. Well the the the foundational book around OKRs is Measure What Matters, I think is the title. we know a lot more how to set the right stretch goal. The whole the what is it, the prizes and challenges ⁓ practice. Like you want a goal ⁓ far enough outside of what
speaker-0: Right. Yeah. Yeah. Yeah. Yeah. Yeah.
speaker-1: It's deemed to be reasonable, I think. Is that the frame it? So it needs to be like a BHAG, like a big, hairy, audacious goal. But a big, hairy, audacious goal that is achievable, but it's just like you're pushing it. Yeah. Like going to the moon. Big vision. We we knew what it takes. You didn't have to get super precise. It wasn't like Kennedy saying we need to send somebody.
speaker-0: Mm-hmm. Outside of our reach.
speaker-1: X thousand kilometers outside of the Earth's orbit.
speaker-0: Yeah. But land on the moon.
speaker-1: But it was precise, like the moon, like not things.
speaker-0: Right, right.
speaker-1: So so I think you're you're right and you gotta find the right goalpost. Yeah. Because when we don't have a goalpost then it's easy to say, Yeah, we're contributing to that vision. And we're gonna change things incrementally and we're
speaker-0: Mm-hmm. We're good. Yeah. I mean, okay, the level of precision that the physicists had to achieve was pretty high. J J JFK didn't lead with that. Yeah.
speaker-1: And then the OKRs is like, okay, what's the process by which we're gonna get there? And I love OKRs because it also takes into account organizational capacity.
speaker-0: Right, right. It would have to become the goal. Cause at what point then we're going down a rabbit hole right now, but I just really want to have this conversation. We're gonna be cutting some things out, I think. But at what point do you okay, like if you're if you want to achieve X, you wanna get to the moon, but right now it's not organizationally feasible. Therefore, we need to set the conditions that allow us to get there. Like where does that fit for you if if The OKRs is about organizational readiness or feasibility. You know, it has to fit within that frame. What about the adjacent possible? Like how do I chase the adjacent possible?
speaker-1: Yeah. really good question. I think some of it is organizational design. ⁓ you know that your ⁓ mission or your ⁓ state requires a bunch of new capabilities, then ⁓ you build that into organization. sticking with that Apollo ⁓ mission
speaker-0: Right.
speaker-1: NASA had a huge group of like so many different components to getting a person on the moon. And yeah, there was a new organization set up, new rules established to make sure that the physicists were talking to the manufacturers. ⁓
speaker-0: Mm-hmm.
speaker-1: who were talking to the academics making all of these pieces of technology fit ⁓ those roles didn't exist before. So I think, yeah, if you have your OKRs, it gives you a bit of clarity on what's the next critical step that you need to build into your work plan and your funding to advance towards that. but you yeah, you need to give your teams the flexibility to be like, ⁓ we'll figure it out.
speaker-0: Bigger default. Yep.
speaker-1: the humility to be like, yeah, we don't currently have the skills to to do that. We're gonna have to we're gonna have to shift how we're organized. Or
speaker-0: It's such a it's such a brilliant example for that reason because you it's it's it's the perfect it's almost the like it's like a great case in that you have an organization, you have a system, an ecosystem set up, not just an organization, but an ecosystem set up ⁓ that moves from mystery to heuristics, right? And into execution or or you know, whatever process operationalization, etc. Whereas most organizations kind of ignore the first two parts. mystery and heuristics are are off the off the table and we're just operating.
speaker-1: Yeah, yeah, yeah. Just get collaboration mode. Like what can we do with what we currently have at our disposal? Which programs are already investing in, conservation or climate readiness and we'll just double down ⁓ on that. It's rare that the reflex of our public organizations are like, do we have ⁓ thing we currently have the capabilities? Is our organization designed in a way to go after that mission or that goal? And if not, then we need to go into the kind of institutional architecture space and make some adjustments or build something new. Like that is not the reflex.
speaker-0: What needs to be true for this to yeah. Mm-hmm. I d also just love it from coming from the research network, the like the level of collaboration that was required with universities across the globe to achieve that. And the infrastructure you needed, especially before the internet, The social infrastructure would have had to be credible. A hundred thousand people. A hundred thousand people to achieve that mission. Yeah.
speaker-1: Mm-hmm, mm-hmm.
speaker-0: That's big that's bigger than the city I live in right now.
speaker-1: Yeah, yeah. And it and it had to it had to work. So they figured it out.
speaker-0: Yeah. Yeah. Yeah.
speaker-1: You had to open up that space of possibility on how you're organized ⁓ ⁓ make adjustments.
speaker-0: So this has been a fantastic chat. I I that we're we're sort of closing on this this idea that organizations for true transformation and to achieve, you know, big hairy audacious goals and missions, there's a a level of boundarylessness that needs to to happen, right? There needs to an integration that needs to happen working with outside organizations like Code for Canada, who come in with external expertise and practitioners to work in an embedded way with teams to practice design with ⁓ with users and technology in a way that builds the capabilities of those teams inside government. We'll leave that for the next episode. Until then, thanks for joining us. Ciao.
speaker-1: Chao. I actually think there's a lot more entrepreneurship that happens in the public sector than people sometimes realize. If a child's about to wind up homeless on the street, does a deputy minister of social development get an email? Seems to me that's worth an email. Seems to me somebody should care about that at least as much as whether or not somebody rented a damn car. Show me your incentives and I'll show you the outcome matches very well.
speaker-0: Very well.
speaker-2: Same activism that likely drove you in those earlier days needs to stay with you.
speaker-1: What about ⁓ bigger questions around how people thrive in our society?
speaker-2: Person has a career path, a project has a crew. What if there was a ministry that could approach something in an unbounded way? And what if it had ministers or public servants that aren't confined in some kind of role or job description? For me, that journey in the internship, it was one of the best jobs I've ever had. And still that is still true today because of the impact that it has had on me personally. Nothing.
speaker-0: figure it out as we go and we built out these citizen things in a very unwaterfalled way.
speaker-1: Services. Many of these flaws are tied to deliberate choices. We may not have wanted to deal with the outcome, but they're there because somebody wanted it them. And maybe what I'll say about that is if it sounds like I'm cynical, I'm actually not. Because the fact that it is a result of choices means that we can also have the power to undo those choices.
speaker-0: I'm your co-host, Nick Scott. In this episode, we talk to Dorothy Ng, CEO of Code for Canada, a nonprofit organization that works with government and corporate partners to help build digital capacity of public service teams across the country. Dorothy Ng, the CEO of my favorite national nonprofit organization, It is so good to have you on the show today. Thank you for being here. ⁓
speaker-2: Thank you, Nick. Thank you, Jason. It's a pleasure to be here.
speaker-0: We're we're looking forward to to hearing more about you, the person, the hero, the the ⁓ the leader. And as we do with all of our our shows, we want to start off by just getting to know you and how you became ⁓ you today as CEO of Code for Canada. What is your origin story?
speaker-2: My origin story. yeah. Well I'll start ⁓ I won't go too far back. I'll, you know, start maybe like in the middle of my life journey.
speaker-0: You were born and then you applied to work at Code for Canada.
speaker-2: And then I'm here I am. What else can I No, we'll talk about I was I was in university and ⁓ not everybody knows this, but I studied ⁓ materials engineering at ⁓ McMaster University in Hamilton. Nice. ⁓ which is like steel steel city. So ⁓ I was like destined to work in a steel mill as my career. Like I learned all about steel, how to make
speaker-0: And here you are.
speaker-2: Tempered steel, high quality steel. But then ⁓ when I was graduating from university, it was the ⁓ 2008 recession. So then all the automakers tanked. And then all the steel mills tanked as well. So when I when I graduated, like all of my ⁓ colleagues and me had zero jobs, no, no job prospects. And so we were just scrambling, applying to any any job out there. And so I ⁓ I saw this posting for this firm called a a small little firm called Accenture, just like a little little technology consulting firm. You know, and I read the the job posting, I was like, I have no idea what any of this is. So I just applied for it. ⁓ you know, go went through multiple interviews ⁓ and ended up getting the job. So I was like, okay, I'm working here as like kind of a it was a systems integration analyst, ⁓ just kind of like working with their clients, doing systems design, which was not really like my background. ⁓ in university. And my first ⁓ and like biggest project at Accenture was with ⁓ Metrolynx. So Metrolinx is the agency ⁓ in Ontario. I'm based in Ontario, by the way, just for all the listeners out there. and ⁓ it's the agency that oversees all public transit across Ontario. And so they were just rolling out this new digital fair payment system called Presto, the Presto card. And Metrolinx had contracted ⁓ Accenture, this place that I worked to ⁓ to like do a lot of like the design and rollout of that system. ⁓ and so here I was, like I hadn't I really knew nothing about like technology or fair cards, but I was thrown in there and I helped to design like the first Presto fair card. It was like green and it was it was like vertical and and it looked really, really snazzy. And then and the system could do a lot of things. Like you could tap on and tap off at different like subway stations and go train stations. ⁓ I felt like very proud of the work. And then one day, I remember like showed up to ⁓ this like dinner party and people were like, ⁓ like what do you do? I was like, ⁓ you know the presto fare card? I designed that thing. And this one person was like, You designed that, that thing sucks. I was like
speaker-1: No.
speaker-2: and yeah, and they were like going on, you know, I came from I've lived in Hong Kong, I've lived in London, ⁓ they have the oyster card, the octopus card, listed all these different fair cards, and they like, Those cards are like way better than this card. Like actually I c I can't do so many things with this card. I was like, ⁓ my god, like I never really thought of all that. ⁓ and then when I like kind of thought about it further and and ⁓ really evaluated like how the work was rolling out, it's true that like the the system was not really designed from like a user's perspective. It was designed from the perspective of like honestly was a lot of like transit providers. It's like the transit provider must receive this amount of the fair payment and and fraction and that other transit provider receives that fraction. ⁓ and so it was very like designed for the players within the system, like the agencies and not the actual writers. And so very few kind of user stories were embedded in the design of that that system at at the time. Since then, the system has gone through I think many iterations. They are Or customer centric. But ⁓ yeah, it was a bit of like a wake up moment of like I had never been exposed to like user centered design or like, you know, design in general. And I was like, ⁓ yeah, this is what happens. Like users are not really consulted in the design of technology. So that really like started ⁓ this like idea for me. And then from there, you know, I left that that firm and worked at kind of like smaller technology firms. And along the way, I picked up ⁓ methodologies like, you know, agile and iterative, you know, delivery and design and testing. ⁓ and really learned more about kind of like modern iterative software design principles, ⁓ which led me to, yeah, like kind of where like at this this fork in the road at some point. ⁓ you know, I really, meanwhile, I was very passionate about like giving back To our community or my community. I had heard about Code for America in the US and knew that they were starting up like a Code for America brigades network, which are essentially groups of volunteers who come together and, you know, hack on community problems using technology and data and design. And ⁓ and I thought, well, we really need to like have one in Toronto, which is where I'm based. So I met a few folks and ⁓ outside of my day job and and ⁓ we started Putting together like the first civic tech group in Toronto, which was Civic Tech Toronto. And we started meeting up and having hack nights every Tuesdays. And then that really took off in popularity. And ⁓ yeah. And then from there, actually, it was at a time in in the Ontario where the Ontario government had just hired their first chief digital officer. Digital started being a real priority at At the province. And so some ⁓ some public servants ⁓ from the OPS actually showed up to a hack night and were really like thrilled, like seeing kind of people in the community actually like wanting to contribute their skills for good. And so through some folks on the civic tectron side as well as on the Ontario government side, put together a bit of a proposal around like what if the Ontario government funded the formation of Code for Canada? Kind of like stood up an official nonprofit. In fact, one of our board members here now, Charles Finlay, was a part of that original group that helped to stand up that proposal with the Ontario government. And the rest is just history. I was like kind of part of that group along the sidelines. You know, first was on the board of Code for Canada for a bit, then moved into staff, kind of overseeing our sales. ⁓ and then eventually just that led me into the CEO role. And that's my story, all from, you know. Some bad feedback that I got at a dinner party. How embarrassing. Put me in my place.
speaker-1: That's so important, right? It seems like that helped really shift to actually understanding from a user's perspective what is Yep. ⁓
speaker-0: That was so serendipitous for you to get that feedback at that party.
speaker-2: Yeah, it was honestly it was like the triggering moment of just like, You're right. I had no idea that this is how people feel. Yeah. Real like enlightening enlightening
speaker-0: Yeah. How did you bridge the gap like from from materials engineering into Accenture? Like was there anything that you brought over, like anything that you learned that you were able to apply ⁓ that kind of helped you get into the world you're in?
speaker-2: Yeah, I mean, I think even though like I did materials engineering, there's a lot of kind of like basic engineering, you know, thinking and concepts that really apply to like, you know, technology and and ⁓ and the kind of work that that I was doing at Accenture. ⁓ and and actually a lot of it, you know, when I when we layer in concepts like user centric design and testing with users, it all actually comes together quite nicely in that like what engineers are taught in in university is like first is getting really clear on the problem, right? Like what's the current state? What are you dealing with based on all the, you know, the constraints or the criteria that is in front of you. So doing very like thorough kind of like assessment of like, are things working? Are they not working? And you know, when we think of that in terms of like a service or which has users, that includes like asking the users those questions, right? Of like, is this working for you? Is this not working? Did where are we thinking the problems are? in in this service that we're running or this product that we have. So so engineering ⁓ you know, drills that into into students like quite well. The next thing too is also what is like really drilled in to engineering students is documenting all of your assumptions and then using that to then move forward. Because I think there's like an approach, once you've kind of gathered all your information, it's easier to it's easy to kind of like fall on the trap of just like overthinking and over hypothesizing like like what could be happening versus really what that approach of just if you document everything and say, here are the things I assume based on what I'm seeing. And now here's what I think might be the solution and how, and we're going to test that solution. And we're going to use the information we gather back from that test to actually update my assumptions. That really just points to that iterative, that iterative process, right? Of like, you never know what you don't know. And you'll never know it till you actually do it. So what's more important is just at every every so often, every cycle, you're just documenting what you know and you don't know and moving forward and then and then checking in with that again to kind of like re reevaluate or rebuild your picture of reality. So yeah, then definitely a lot of like kind of frameworks and approaches taught in engineering really synonymous with like good user centric design and like iterative building.
speaker-0: Nice. Yeah. And and so Dorothy, ⁓ at Code for Canada, you you run programs that help bring extend the capacity of government and help them build the capabilities for the digital age. Can you talk a little bit about like what does it look like when public sector capacity building work is done well?
speaker-2: Yes. A couple I think a couple things happen. The first is like you start to feel like things feel different, I think among teams. Like once you kind of get a few, once you you help teams get a couple wins under their belt. And honestly, the wins could just be like, We finally shipped a thing. Like we've been talking about this thing for so long. And we finally took all of that talk and just translated it into a thing that we're able to demo to whether it's like our adjacent IT department or our executive sponsor or even to users. That feels really good for teams. and and it like gives them this like leg up in confidence. Like what we find is that once that thing gets shipped and they're like forced to demo a thing, they like actually really grow, grow in confidence of like, okay, now now we know more clearly what the problem is and where this thing needs to go. We can iterate on it and like let's show them again. and like demo demo it at the next, you know, the next schedule demo. So I think like the evidence of like capacity building and transformation starts there, just at that team level, right? Seeing people kind of come out of their shell a bit and like getting a bit more engaged in the actual work. ⁓ I think beyond that, like beyond that will that will go far, but it'll probably only go so far, right? Like you'll you'll have teams that kind of like build momentum, but then how do you actually take that and translate that into kind of more like broader capacity building and transformation, maybe high with the higher ups. And and here's where it's like it's a bit harder because you're trying to look for, you know, that that really comes down to who are the leaders, you know, do they care about capacity building? Do they care about transformation? And what in their eyes is are they defining as transformation? And so here's where you actually need a a bit of like a person who's leading a team who kind of knows how to manage upwards. Who can spin this or frame the stories and the benefits in a way that really resonates with that leader? ⁓ and then and once you've kind of like identified that, there are so many ways that you can, you know, show up, like show that next thing that really gets the buy-in and that capacity build of that leadership. And so a really good example, you know, that that we've found is we run this one ⁓ service that we call inclusive user research. It is a, we have a Pool of test participants from across Canada. A lot of these folks are from more marginalized communities, like think people living with dis ⁓ disabilities who use assistive technology to access services, newcomers who don't have English as a first language, seniors. And we engage these people to test technology. Like maybe it's like no surprise. I don't know. It's no surprise to me now, because I've seen it so many times. Most serve most government services are just like, pretty bad at at reaching these kinds of populations, especially folks using assistive technology. ⁓ and it you don't you have no idea how powerful it is to kind of show a leader, a government leader, ⁓ a video of like a a user trying to access a service and hearing them be like, I can't even my screen reader can't even identify that there's a button on the screen right now. Like, or I can't even get into this access into this service. Or like there's no like This login feature not even working for me. ⁓ and so having that evidence and showing that to a leader often like galvanizes them ⁓ more than anything else, than any other kind of like demo or feature build. It's just like the most, it's the most impactful form of just like taking that mirror. It's that, it's that moment that I just described, right? Of someone coming to me being like, that service sucks. It's the exact same thing. And and you'll find like there are so many. leaders, government leaders across Canada who have had that moment, who have been transformed, right? Like, well, I'll I'll refer back to, you know, one of our dear old friends in in the digital government ecosystem, De ⁓ Natasha Clark, former deputy minister of at ⁓ Government of New Nova Scotia, also had that moment. I think there was a moment she has a story. You'll have to ask her about the story, maybe on this podcast, of her moment where she received a tweet of someone complaining like, Wow, this portal like really sucks big time. And ⁓ and that was the one that she she had launched. And so I think it's those like those those like real moments that help to ⁓ like get through that like ceiling of to like push innovation to the to the highest level and really like get leaders to pay attention. And I think that's what capacity building really looks like at the at the higher levels of just like getting them to care and why it's important. And then from there there's all the things of like how do you now how do you get leaders to enable their teams to actually, you know, deliver value for for users now so that like we're we're not ending up in these kind of like moments where it looks like we have egg on our faces.
speaker-0: I love I love that you you are now kind of like your job is to create those moments. Like you you you had that that moment in the in the dinner party and now you're like trying to like give those out like little Johnny Apple seed. But it it's it's you can describe a problem to somebody, but what you're saying is you're showing them the problem, like in real life with real human beings and their their technology or their services, and and you're like You can't turn away from seeing it firsthand in that way. And that's such a powerful thing. And so in that, you're creating that that awareness and perhaps the desire to to change, right? But then there's that next gap, that challenge of okay, as a leader, you know that a change needs to happen. But the gap is do you know now how to change? Do you know now how to lead a team in the way that can solve these problems? kind of in a continuous fashion from now on. And I think that's the that's the next kind of big challenge. Can you speak a little bit about that? Because I think I'm I'm facing it now in my own work, right? Where you mentioned how do they talk, how do they define transformation? You know, that's not even there's no consensus on on what anyone means by transformation as an example. Totally. And even if you agree, you don't really know how to do it. And so how do we how do we bridge that gap?
speaker-2: Yeah, and that's that's the like million dollar question that like ke keeps us going and you know, helps helps pay the bills too, you know, 'cause like every government's just like trying to figure that out. literally like it's it's impossible to answer. That's the reality. Because it it ⁓ is case by case basis for like every single organization. It is so easy for people to be like, ⁓ digital transformation, a formula, it's blah blah blah. ⁓ regardless of organization. ⁓ but then when you when you get down to it, ⁓ every, you know, department in government has Different mandates, like similar mandates, but for really different mandates, different kind of makeup, you know, maybe their procurement works this way and another procurement works that way in another department. And so each one is almost needs to be treated a bit like a case by case basis, which is why I think what comes what it comes back to is that that approach of like, you know, knowing what we know and documenting those assumptions, but then knowing that we have to update those. And so that will only happen just by like testing different things. Because we're never we're never gonna get it right right the first time. And so I think the real there's there's a couple of things that obviously need to happen in order to enable that kind of like ongoing testing of like if we're gonna transform as an organization, what's gonna work and what's not gonna work, it has to start from the top, right? There has to be a desire from leadership that also like we leaders are like, We don't know what we don't know, but what we do know is we're committed to learning, we're committed to, you know, we're gonna try we're gonna experiment, we're gonna make a lot of mistakes, but we're gonna pick ourselves up and learn from that as teams. And, you know, ideally that's that's given that that ability and that space to learn is given to teams, right? They're they're given the space to to also learn and then escalate when they've when they've learnt something or, you know, have reached new blockers. And yeah, so I think it really does first and foremost come down to the leader of whether they are able to like create that, create those conditions for learning, which is hard to Right. Like that that is that's just like a hard quality to find in in like mu many people. And then on top of that, you add like kind of the pressures of what ⁓ of that role, right? In in governments parti particular, there's just everything always feels like things are on fire. There's always like a new fire. And the kind of stress that that leaders are have to deal with of like responding to the fire, also like there's not a lot of rope, right? They don't like a ton of wiggle room and yet they still have to And they like give room give teams enough space to be able to fail. Like it's a lot to ask of a leader to like manage all these conditions. So ⁓ and then sorry, then the last thing I would add to that, along with the kind of pressures of of that role, like maybe from the political side or like mandates that that are expected of leaders. ⁓ we now have, you know, new technologies like AI that are just also distracting like a lot of people. It's like as this other kind of Headwind, but also a tailwind that is like just taking, I think a lot of leaders' eyes off the prize of like, why are we why are we doing this work? Like, why do we care about transformation? To what end? Like, what's the benefit ultimately to users? And what I find, at least in my conversations with leader government leaders, is that AI is just really distracting them. Like they're they're they're now just getting kind of caught up in the technology and they're forgetting like that North Star. ⁓ so you put these all together and it's like, yeah, it's it's challenging for leaders. They're also getting super distracted, and like teams underneath are just like, Wow, what do we do? ⁓ so I do think that opportunities, like with that still, is like ⁓ the the the government teams that can find can that can take these like really challenging situations and like find the opportunities, like translate them into opportunities that serve those like Outcomes of like better services for people and again like bring leaders back to the North Star are the teams that are going to get through this storm, like this latest storm a lot faster. ⁓ and so one thing in particular, like the teams that have figured out like a can be used to rewrite my emails and write briefing notes, cool. But also it can be used to just like get that thing at the door faster. Like, my God, we've been talking about this thing for so long. And like, look, I can just like spend, you know, 10 minutes vibe coding. Now I've put together that same thing we've been talking about and and demo that to then show like like let's get this thing in front of again our adjacent IT group or business or like business stakeholders or maybe a small group of end users to get that feedback and like get that cycle of tests and learn going. Those are the ones, those those are the teams that are gonna like really pull through and bring us back on track to to those like digital government values. ⁓ because I I think like, you know, I mean, we we've talked about this before, Nick, like we're when Code for Canada started, it was like a different time, right? There were like Canada was riding off of a a wave of excitement that was coming out of the UK, out of the US, like out of Australia, like just like seeing all these other governments stand up like digital service teams and like and like harp on these values of like we gotta talk to users, we gotta test with them, we gotta ship, we gotta test and learn. And that seems to be That seems to like going away a bit. Like we don't hear that as much. AI we hear about AI a lot more. But it's like there is a world where we can bring AI and like bring it back to those things that really matter. ⁓ but it just takes it just takes some framing. Like it just takes people to realize, like, wait, can be the same thing. Gotta be a bit creative.
speaker-1: yeah. So for me, it's it's really interesting to hear that in the past there might have been more energy around digital transformation. There might have been ⁓ a more more awareness of some of the fundamentals, and now there's a whole bunch of potentially noise that's kind of crowding out some of the the really strong fundamentals. But maybe it was also that there were a number of Teams or units that kind of made it through the storm, they transformed their service area, but the organization or the institution wasn't able to codify some of the things that would have been needed for more teams to make it through the storm. Have you seen examples of We're gonna change this policy, this directive, this funding model. have you seen ⁓ that level ⁓ of transformation that goes beyond a project, goes more towards an organized. Like,
speaker-2: Totally. Yeah, that's such a great question. And, you know, I'm not like a scholar in this area at all. Like I wouldn't wouldn't use me as like I'm like Dorothy is the central source of truth. All all of my, you know, opinions are very like they're through a lens like that is a bit jaded. So, you know, you can take t take some of this with a gray cell. Like, I don't know. So I would say though, w with that, knowing that, ⁓ I don't think I have seen many organizations, little centric, user-centric organizations that have made it through the storm in the way that you just described, of like not just, it's not just at the project level. It's not just like training up some staff. Some of them have gone so far as like, hey, let's like revisit our tech stack. You know, let's like, you know, some of the more innovative ones have been able to build out APIs and, you know, even some of them are like care about open source. And so value that. So, you know, moving into that like heart of bureaucracy, I'd say like I've seen teams kind of ⁓ institutionalizing some of the digital principles through technology architecture. But then when you go layers deeper, like you know, budget cycles, procurement, that's where we see less evidence of that. And and it becomes it it becomes more obvious when you kind of hold up, if you go to like a government's you know, main website on their policies. Let's use the government of Canada as an example. And you're holding up the kind of like ⁓ I think they call it the ⁓ policy on digital directive or directive on digital. I can't remember the
speaker-0: The po the policy on ⁓ service and digital?
speaker-2: Yes, that's the one. And so that one, you know, was formed at a time. It was like ⁓ the Canadian Digital Service contributed that. And it was like, you know, ten great principles, being user-centric, you know, being agile, being data data driven, your decision making, all the great, all the great things. And you hold that up, but then you also hold up like another adjacent policy on like project planning and financial management. And the two policies like are totally conflicting. Like one is like Don't first make sure you're validating your assumptions with users before you're going to ask for budget for things. The other one's like, how dare you do any work before you ask for budget? Like, you better come with us with like 5,000 requirements, and then you'll get your budget. I'm very like, you know. Yeah, it's like so once you start getting like into those layers of of bureaucracy, like you start to see how the last mm you know, five, ten years of digital.
speaker-1: Yeah.
speaker-0: This is so true. This is real.
speaker-2: Have been great, th but they've all been kind of like layers that we've slapped on top of like old policies. And often it's the older ones that trump the newer ones. So like the end of the day, like digital projects just keep they'll hit like that wall of like, Well, ⁓ we need more funding again for the next phase of the roadmap, but they're asking for all the requirements of the next phase of the roadmap, which means we're in we don't have time to talk to users. We're just gonna make a whole bunch of assumptions about users to get that budget. Yeah. So I'm gonna say no.
speaker-0: That's it.
speaker-2: The long, long answer and short answer is no. I don't think I have seen any, you know, digital teams to that degree, like top to bottom, vertical, I don't know, integration. Is that what it's called? Mm-hmm. ⁓ I haven't seen
speaker-1: No. Okay. Lauren Hunter from last season, who's like legendary in the Canadian federal government, she was like, We need a policy fight club where if there are two ⁓ overarching or directives that are in conflict with each other, you need a committee of DMs to just like hash it out and be like, Which which one's gonna trump? Because we can't continue to have
speaker-0: No. that policy too. ⁓
speaker-1: these directives layered on to move towards digital government or a government that is usercentric or in a government that invests heavily in experimentation or test and learn. Like we can't have those things as add-ons. They actually need to be embedded as kind of the new fundamentals, but we we can't do that unless we reconcile these two different views, these two different models. Do public management. versus Agile State. Like like you can't have them both.
speaker-2: Yeah. And and that really does come back to that question you were asking, Dick, of just like how do we, you know, equip leaders or how do we like get to that layer and and make sure that they're creating those conditions that actually like enable transformation of teams. And my hypothesis, again, not validated, is like it comes down to that, right? It's like if you as a leader is ex are expected to work within policies that are extremely waterfall.
speaker-0: Mm-hmm.
speaker-2: Mm-hmm. And that's how your success is measured, then those directly conflict with like the ways that, you know, teens need to actually like test and experiment and learn. So it's like
speaker-0: So there's there's on learning to do. Like the thing about the the policy on service and digital is that when I was there, the federal government, I felt like we had everything we needed. With that policy, I have more than enough direction to do what needs to be done. Yes. But the thing was, I don't think there's somewhere between like a lack of digital literacy to even understand the implications of that document of that policy. Right. And then even if you did see the value of that. policy and and the subsequent directives. You didn't know how to execute it. Like you didn't know how to do the the actual practice required. And that would involve on learning some of the waterfall things. That would involve unlearning some of the more conventional approaches to the work. And where do you get the opportunity to do that? And my my hope at the time was the digital accelerator inside government was the opportunity for people to practice new ways. Yeah. But I still love that document. And I love the strategy map that came out of it. And I'm like Just do that. If you could just do that, then you're s
speaker-2: Yeah. Exactly. Yeah. We we were like we always just fall back to that document of like, you know, if there's governments that are like, What's our north s which north star should we falling? I'm just like, go to the federal government's page, like
speaker-0: Here it is.
speaker-2: ⁓ yeah, and it and it's so it's just like that that great thing is just so contradictory to everything else that already exists. It's like a bit like gaslighting, you know? You're just like, ⁓ yeah, you can do digital, these really great things. And like, ⁓ by the way, well better not do that.
speaker-0: No, you can't.
speaker-1: Right. Well, you can. You just have to pass through the eye of a storm. And, you know, some of us are whatever it is, like we decide, yeah, well I'll try it and like I'll keep I'll keep going. But our colleagues who are probably ⁓ more sane are just kinda like, Yeah, I'm not passing through that. Like I can see that storm. Like I know what it takes to get through. I know I probably won't make it. So I'm gonna stay
speaker-2: Up the port. Yeah. Good luck. Yeah. Totally. Which like I know now this is getting into another another thread, but I I think it is a really important one is that like this whole like we we talked about this movement in Canada has like slowly been, you know, like I don't know, dissipating, maybe like everybody's kind of going in different directions. And and there's like other there's like major macro trends that are affecting that, you know, with AI, there's like, you know, movement kind of surging from the US around like government efficiency and like and all that stuff. And so that that might be also affecting the state of the digital government movement. But also it's just like it's exhausting, right? Like like trying to like we're so far we keep calling it like storms. Like weathering storms and whether we're like ready for that. And yeah, the leaders that have been like pushing to get through that storm, like maybe they capsize. They're just like, I'm not gonna try and get back up. I'll just Wait till someone rescues me now. Yeah, it's it's a it's a tough it's like a long slog. Yeah, and so that that could also be the thing, right? We're like losing losing people 'cause ⁓ it's it's tiring to constantly be like pushing against the tidal wave of policies.
speaker-0: Hm, ⁓ yeah.
speaker-1: So so Dorothy, would you describe the teams that Code for Canada spends the most time with as of your innovators or your early adopters if you're looking at the diffusion of an innovation curve?
speaker-2: Totally. Definitely early adopters. And there there's always gonna th they will always exist, right? Like even though we just talked about like, ⁓ yeah, it feels it's exhausting and there's not a lot of a lot a lot of folks left. There will always be kind of those people who are just like their interest has peaked just enough to be like, wow. Like maybe they're a bit newer to government. And they haven't yet gone through that full they don't have that full historical context. But like things can be different around here, and you're like, ⁓ yeah, yeah, like I like. I like that. I like the way you're talking what?
speaker-0: Come with me.
speaker-2: ⁓ and they don't they don't know what they're in for yet. But ⁓ and and honestly, that person could be a new public servant, but they also could be a longtime public servant that's just like always been a bit frustrated. They've like learned the game, right? They know how to like navigate procurement and all all the like weird things. They've just like flown under under the radar, kind of like finding little loopholes. But yeah, they're those people are out there. And when you find them, it's like It's super invigorating to get to like you like you you you explain the kind of work that that we do or like this this digital work. They they match it up to like what they've noticed as like, ⁓ yeah, I've just I always knew things didn't work around here. I just didn't have a word for it. ⁓ and then you marry those two together and it's just like light bald moment. I'm like, well, we're gonna we're gonna try this. We're gonna try and do it in do things in a different way. Yeah. So I'd say that that also qualifies as an early adopter. Like a a l be in very seasoned public servant. But an early adopter.
speaker-0: Yes, absolutely. They're early adopters of your program. Like you've created you've created the program, the opportunity for them to try new things. So they're early adopters of that. And once they're in there, then they become innovators in that they're now innovating a product or a service inside. And now they're looking for early adopters of that.
speaker-2: Exactly. Yeah. Yeah. And we we like really evolved our model. I guess I should I should probably describe this to listeners out there, but we when we first started as Code for Canada, we used to run a program that we called the Fellowship Program, where we would recruit teams of technologists. Often they were in groups of three and kind of looked for that trifecta of technology development roles of like product manager, UX designer, and a software developer. And when you kind of marry those three three groups together, like you've kind of got the the perfect team to build, you know, really great software in an iterative way with users. And so we would always kind of embed that team of three into government and help government teams deliver a great service, then also coach them up to to be able to keep that service running after we're gone. And over the years we have evolved that model just in response to what we noticed with governments and that like, One is that, you know, government budgets are slimming and so they can't always afford like a full team and they might just need one person or one or two people. ⁓ and so we kind of like slim slim that like made made the options a bit more flexible for governments. The other thing too is we're noticing, you know, let's say the governments can really only afford one practitioner and not three, then but they but they still need all those skill sets. And, you know, enabling our staff to be able to know a little bit of design, a little bit of you know, development and and a little bit of product management while they still kind of maintain that like central craft. Maybe they came as a product manager, but they're like learning a bit more of development. And that is definitely a lot more possible these days, like with the state of AI and like LM lately. People who have never coded before can now like a designer can quickly prototype something much faster and in a way that gets like much more robust feedback. So yeah, lot lots of opportunity too for governments to gain access to those skills nowadays with AI and just with like the state of, you know, technology labor kind of shifting as well to be able to leverage AI more effectively.
speaker-1: Very interesting. So assuming you have a leader with the right vision who can mobilize enough resources and acquire acquire a mandate, then ⁓ you know you've have outside partners like Code Canada that can come in and help actually kind of build support for your team to execute. It sounds like the the cost for entry or whatever it was required. 10 years ago is potentially a bit less. I guess my big question is what does it look like, not for the early adopters or the innovators or the teams that fit that profile, but kind of for your early majority? So, like a team that is like, my government has a new mission on affordability as an example. And we got to move fast in order to improve access to benefits for citizens. What does capacity building look like in that kind of a context where there's not like, you know, somebody that's heard about Code for Canada for years and has just been like waiting for an opportunity? Yeah.
speaker-2: Yeah. I mean, for the most part, we're always trying to find those opportunities where like we actually kind of fly under the radar a bit. Like we don't ⁓ we don't love to come in kind of like guns blazing, like, hey, we are not from here and this is how you should do things. Although some governments do like that. So so we'll do that too. You know, whatever they need us, whatever role they need us to play, we'll do. But but for the most part, yeah, we want to kind of come in and like tag on to an existing project or mandate, right? Like new thing needs yet. shipped quickly, ministers asked for this new portal or dashboard. What do we do? And yeah, I would say the first thing that we're we're doing is like obviously doing that like current state assessment right to understand like, well, what's what's the purpose of this portal? What who are the users? How in what ways have they been getting the information they need now? How how do they not get that information? And ⁓ what we call for that, for that initial kind of currency analysis, we call it options analysis. So it's really just trying to like figure out like what's the deal, what are we trying to do here? What are our options in front of us? Should we be like prototyping something pretty quickly? Do we need to present it in a way that like shows interoperability with existing systems? And the key here is that process could take months, but for the most part, we don't want to wait that long. Because if we did, then we'd just be another government team. So we're just trying to get government teams to move a bit more quickly than they're used to. And so this is where leaning on things like AI, right? To help us prototype more quickly and get that feedback cycle and just get the conversation going through demos, through testing is like the ultimate, like most important thing we want to do like right off the get-go with with any. any project or any partner. and then from there, essentially what it becomes comes down to is kind of like what's the reaction to to the to the prototyping and to the demos. We might end up with like really negative reaction. We might be like, well, like this is this thing that you build is not going to work for all these reasons. And so like this makes no sense. It has to go back to the drawing board is is like better than getting no reaction. Like we would rather just have people like come in maybe hating the thing, but giving us really negative feedback. Again, it's that dinner party moment, right? Like, God, this thing sucks. But what it does is it just gives the team direction to then be like, okay, like, what did we learn? How do we now like, how does it take us like one step closer to that next final product? And and then I think importantly along that whole journey, it's like engaging the leader, right? The leader who at the end of the day is gonna have to maybe demo this new portal or dashboard to their leader, whether it's like the minister or whatever. And getting them bought in and engaged in the process so that they are understanding how what it takes to build technology, like how it works and how teams need to work around technology. But then also like they're just like getting into it. Like leaders who understand the business, who understand the service and like the risks of the service are just like better leaders. Like they're more well spoken, they're like more respected by their staff. And so those are those are things that are like actually kind of easy to do to like build up that confidence in a leader just by kind of engaging them in the work and and showing them the work more often.
speaker-0: That's a good segue to advice you would give to folks on the inside.
speaker-2: The inside.
speaker-1: Piece of cake.
speaker-2: I mean it's hard 'cause like, you know, I've actually never been on the inside, so is this advice legit?
speaker-1: We'll let you know.
speaker-0: It's novel.
speaker-2: Yeah.
speaker-0: Fresh eyes on the problem.
speaker-2: Yeah, yeah. Yeah. Okay. Okay. I like it. Okay. I guess some advice. And I'll pick I'll like nitpick at the things that I've where I've seen like really good ideas like fall flat. The first is like befriend the procurement people. ⁓ maybe maybe mm like give ⁓ some cookies, bring in box chunk. I don't know if procurement people like that. But befriend the procurement people so that you can understand how things work. How Does that procurement black box work so that you can get the thing you want and need at the end of the day? I think there's like a massive, like there is just this giant chasm in the value chain of government that is like procurement. It's like that's the chasm. And it's just like all this work went into like figuring out, maybe you did all the work of like, I know exactly what I need. I know exactly what the user's problems are. But then if you can't get from like that point to the the next point, which is just like now I have people that help me build the thing that I know I need I need to build or have this SaaS service that I know for sure we're gonna need. ⁓ if you can't jub that chasm, like, like what was what was the point? You know? So I think that's a big one. Here's where I think like I don't know if that's like legit ⁓ input as an outsider, because like maybe people do know they're procurement people. Maybe there's just like It is just like a black box. I'm I'm really not totally sure like exactly how it all works. All I know is that that's just like the biggest risk to any idea kind of taking off government. That's one. I don't know, like Nick you've worked both of you, Nick and Jay Z, you've both been on the any like, is that valid?
speaker-0: We're asking the questions here, Dorothy.
speaker-1: And yes, all roads pass through procurement.
speaker-0: Yeah, yeah. Yeah. Yeah. I no, I I love what you're you're saying about befriending procurement. Cause I think I think it it's any of these functions are a black box if you're outside of them. And they'll remain a black box if you don't have a friend on the inside who can help you see it and understand it. Yeah. Yeah. and I think I think that goes with with policy. I think it goes with with finance. I think it goes with any of the the functional areas of government that oftentimes And it's not just the innovators, like people on the inside perceive them as barriers, right? And the attitude is you're not here to help me. You're here, you're gonna make it harder for me if it's HR to hire someone. ⁓ if it's procurement, it's to to contract someone. If it's policy, it's to get the the policy through. Whether it's a memorandum or whatever you're doing. If it's finance, it's the it's the budget giving me the money, whatever. ⁓ and they all have their own processes. But
speaker-1: Yeah.
speaker-0: I have been doing a lot of work with folks in those functional areas and they all want to be helpful. makes it almost impossible for them to be helpful is being brought on at the tenth hour of something. Right. And and I think that tends to happen. I think I think there's a a pattern in government where we are rushing to get things done. And so we like cut corners or we don't bother with all of those folks bringing them in early. And then it takes longer because we didn't do that. And so like the rushing is c is actually gonna make people say, ⁓ three months is a long time. We don't have three months and so you rush and get it done in three weeks and then six months later you're still trying to get it done because you rushed in the first in the first place.
speaker-1: Yeah, I I I totally agree. And I think this came up quite a bit in the previous season is that sometimes you need to go slow in order to go fast. If you're in government, you need to understand the fundamentals of government. And so this analogy that we've been using, passing through the storm, often describe to my teams that we're on like a seafaring vessel, and you need to understand the vessel. In its entirety. You need to understand the rigging, you need to understand the storage, you need to understand the sales. And it's only once you've mastered those fundamentals that you can navigate well. Now that's our current context. Should we still be using a sea faring seafaring vessel that was designed in the 10th or 16th century? Maybe not, but it's the vessel we're in right now. So if you want to navigate. Or if you want to bring it to a better place, then you gotta understand all of the systems well. And to Nick's point, those functional communities are more than happy and really excited to engage, at least in my experience. But timing matters. The one conflict, though, that I've seen between program policy, digital transformation teams, and some of these functional teams is that we're all coming at like innovation and transformation slightly differently. And so more often than not, our innovation work works across purposes. And so I think that's one of the areas where leadership ⁓ really matters to say we're all doing really important work, but our organization needs to respond to this need and we need to do it collectively. And that's that's a that that's a kind of leadership that I think we're seeing more of. Missions is certainly like a framing that allows for that. That narrative and a bit of a vision of the whole organization going towards that North Star. But it's we've been optimizing for decades in like silos. And I think the creative challenge of those of us that are still in government or work closely with government is to break those silos down and help the organization see itself as an entity that needs to approach a particular endpoint, but do it in a way that's really efficient. really effective, collaborative, and works with outside partners or partners outside of the institution as well. Cause these are complex challenges, many stakeholders. That'd be my two cents.
speaker-2: Yeah, that was a great
speaker-0: Now Dorothy, we want to know if you had the top job, let's say you were prime minister, premier, chief digital officer, CIO, whatever. But top job, queen for a day, what would you do? What would you do for one day? Like it's a for a year.
speaker-2: Right. Yeah.
speaker-0: For yeah. It's I was riffing off of the saying. But yeah, like if if you were wearing the crown and and you you had that level of that power and influence ⁓ in in a government organization, what would you do to enable the kind of transformation you think we need?
speaker-2: Yeah, I mean, okay, I think first it starts with like a goal. Like and it's gotta be like one of those, what is it, big, hairy, audacious goal B hag. I think
speaker-1: Yeah, the Jim Collins being here.
speaker-2: We need like a goal that is like very and audacious, but also just like a good one. Like, you know, better services for everyone. I don't know. Like pretty simple, plain language, everybody ubiquitously across Canada, you know, could mostly agree with. No one wants like terrible services, so like So I think like start with a BA. Maybe step one. Mm-hmm. Step two, I guess with the B Hag, I'm thinking about like what are those outcomes that would lead to that BA. So if it was like better service for everyone, like pick the like, you know, three, five ones that are that like put us on the map to say like, yes, if we did these, we're gonna like drastically improve our ranking on the e-government index. I don't know if you folks and folks listening are familiar. We're UN does this like e-government index and we're like so low now. So like like that's embarrassing. Let's like Bring us up a bit, also, you know, figure out like what are the three to five things that will trend us back upwards. Which I feel like shouldn't take too long, right? Like I wouldn't want that to turn into like a one year project, let's say, which it could easily be like, what are the three to five services we're gonna improve? So we're gonna like make it quick. We're gonna like we're we're picking we're picking a handful. ⁓ And then from there, once we've like narrowed our focus on like what are those like OKRs, than really setting up the teams, the leaders and the teams under that to like create accountability in the system. So if there's like things that we already know are like hot spots in where ideas go to fail. It's like where, you know Budgeting policies don't match like user centricity agile policies. So like let's like zoom in there and be like, what is not working? Let's get that like DM fight club going and like attack that problem. So like maybe SWAT team goes there. Another one is like where certain black boxes, right? Or like stakeholder groups being engaged just like way too late. And that's just just Creating like major stall later on. So maybe it's like procurement, maybe it is HR if we need to hire folks. Maybe it is like finance. ⁓ and so like getting clear on those broken parts of the process, and we like engage them sooner, we like get ahead of those problems sooner. So I think that's like, okay, so now I've addressed the like hot spots, like, okay, this is what's gonna trip us up pretty soon. We're like getting ahead of that. Then I think the rest of it is like. Honestly, just kind of more textbook in terms of agile and digital transformation. So starting with, you know, that like current state assessment of like what are our serv what are out of these three or five services, what do they look like? Let's like get a bunch of teams around those services. Like hope ideally they're like, you know, how to do user research, know how to do service design, know how to like assess like a technology stack. ⁓ yeah. And they're just like building like a kick ass current state assessment. And they're like, okay, we see all the problems. It's this, this, this. You want to de-risk these three to five services. This is it. And then we execute and we get all the teams in. It's like shipping, shipping, shipping, and testing and learning. And then finance is like and procurement, they're like they're like in they're like in the demos, right? They're like engaged. They're like, ⁓ yes, we see how like This is this is how the team works. They're gonna work in this like agile, iterative way. And procurement's like, wait a minute, you're gonna reach this blocker like three sprints from now. Let me start getting ahead of that and start a conversation, you know? And like legal saying the same, like all these groups are just like jumping ahead, being like, hey guys, you haven't thought about like six steps ahead, but let me help you with that. ⁓ it's just like everybody's rolling the same direction. And then I can just like chill in the pool. You know, I dial in the Zoom meeting, like catch the update. Everybody's just like really engaged and working and like they're so do a baseball game. And then I show up at that thing. Then they they like and they love going to work.
speaker-0: Mm-hmm.
speaker-2: 'Cause yeah, they're just they can like deliver results together and they're and it's like fun time.
speaker-0: Yeah, and that speaks to the beginning of our of our conversation today, just like that people feel different. They feel the the difference. And so you're creating that opportunity for them to have that experience, to feel the difference of working in a different way, and be able to show something that will attract more people to working in a different way.
speaker-2: Yes. And then ⁓ yeah, one root one year rolls around and we get that. And then the UN is like knocking on our door, being like, Hey, guess what? We just did the assessment and like you're no longer in fiftieth place on this index. You're up to like 30 after one year. We're just like, like what? We did that in one year, guys. Like let's do it for another year. And then we're gonna crush it. And we just like then we end up back in number one. It's like
speaker-0: So good. ⁓ man, this is the Blue Jay story. You're the comeback kid. You'll you'll be the new comeback kid.
speaker-2: I know. This is hopefully the the way it ends.
speaker-0: Like, I'm really hoping. Really, here's the hoping. Here's the hoping. I know I had to for the end of the show. And ⁓ we wanna we wanna get into this rapid fire. These are rapid fire questions. So we're gonna throw out some questions and ⁓ you answer them as quickly as you can. My first the first one is and my favorite one is government works when
speaker-2: He said we weren't gonna talk about it. People are empowered to ship and demo and learn.
speaker-0: Nice. That's the title of the episode. If government was a sport it would be
speaker-2: It would be spectators sitting on the side of like a soccer match. Like they're but they're sitting, that's the sport. It's the spec. Yeah.
speaker-0: Okay. The sport is is watching. Okay. And what are your top three favorite mental models for transformation? The kind of like how you think about transformation.
speaker-2: Yeah. People process technology. ⁓ just that like framework for just like understanding an organization from top to bottom. Test and learn. So that cycle loop, you know, just shipping something, testing and learning. And the third one, I mean, this one's a bit like ⁓ further out there, but like I I I would love us to get to this state is like government as a platform, government as a product, you know, that like layer cake.
speaker-0: Mm-hmm.
speaker-2: that David Eves has is like there's that like database layer and then there's like a services layer on top and there's like a middleware application layer. ⁓ I like I like that one nice.
speaker-0: ⁓ and your two two books that have had the most impact on your approach or that you would recommend people read.
speaker-2: Recoding America. That's the one by Jen Palka, founder of Code for America, our sister organization in the US. So definitely good read. The other one, not not really a book, but like just like at a online resource. The 18 F D Risking Technology Projects Guide. Very good.
speaker-0: Hmm. Nice. Nice. Do we have time for yeah, go ahead.
speaker-1: We have to have time for one more. Is there anything that can't be taught?
speaker-2: It's hope. I think I think it's just like it's like hope and belief belief in yourself, in others, you know, assuming best intent by by all teams, you know, whether it's your team, your colleague, your procurement team down the hall. Yeah, those are things that are like they're really hard to teach. And there's just so fundamental to like keeping things moving forward. And keeping momentum and until things reach that tipping point, right? Like you just need enough energy to reach that tipping point and then hopefully things just roll on their own. But ⁓ yeah, you need a lot of like optimism and hope to get to get up there. Maybe it can be taught, I don't know.
speaker-0: That's a great answer. No, I love that answer.
speaker-1: That's ⁓ that's a good place to stop. This was such a great conversation, Dorothy. Thank you so much.
speaker-2: Thank you. Likewise. It was so nice, ⁓ catching up with you both me here. It was really ⁓ therapeutic for me to just
speaker-1: That's what that's what we do. Therapy.
speaker-0: That's it. That's how we do. Yeah. All right. Have a good day and go Jays.
speaker-2: Go Jays go.
speaker-0: But ⁓ man, Dorothy Ng. So so insightful, man.
speaker-1: so good. He was I haven't had like a long conversation with her. Yeah. She's funny.
speaker-0: Yeah, yeah, yeah. I know.
speaker-1: I really loved the origin story that she had, kind of starting at Metrolink, thinking everything was great, and then being confronted with unvarnished user feedback. ⁓ that thing sucks. ⁓
speaker-0: That's so good.
speaker-1: And you know, she mentioned designing for institutions versus designing for people.
speaker-0: Mm.
speaker-1: And then I really loved her perspective on the Code for Canada origins. So it was a good example of like top down, bottom up, and then inside out kind of engagements across like the stakeholder communities, which eventually like spat out Code for Canada, which was which was super cool.
speaker-0: Mm-hmm.
speaker-1: In terms of when capacity building works well, I really loved how she articulated like people feel different.
speaker-0: Yes.
speaker-1: And that leaders have that moment, that experience where they see when what they're responsible for isn't kind of up to the task. So as she was describing, like the use of the inclusive users research network that Code for Canada ⁓ curates and how bringing that to the table has been really good to get leaders engaged. But
speaker-0: Mm-hmm.
speaker-1: Then I loved how we started talking about the limits of how far COF for Canada and others can go ⁓ in terms of public sector capacity building. ⁓ that, you know, leaders are being bombarded by information and pressures and shiny objects and teams have to be able to pull them back. That organizations are struggling to go from projects to transformation projects to transforming teams to transforming their organizations. But she's not really seeing that. And then the fact that she was like, you know, this is really hard. And maybe people are just dropping off. Like you advance one novel thing, two novels things. And then You look and you're like, I'm not going through that storm again. So part of me was like, Holy maybe we're just losing people and we're not refreshing that that network of public sector innovators at the rate that we're losing people, which I hadn't I hadn't thought about.
speaker-0: ⁓
speaker-1: Yeah. So that's what I
speaker-0: Amazing. Yeah. You got the last half of the the podcast that I didn't get. So that's great. My my f my favorite part wa also was the origin story. Like that just like w right out of the gate in the interview with that origin story, couldn't have you couldn't have written a better origin story in my mind. Like she went from materials engineering to consulting.
speaker-1: Yeah. Mm-hmm.
speaker-0: Doing systems design and got to work on, you know, a service that is just so massively used in Toronto. And I remember when that first came out as well. But like her first time and and getting user feedback at a dinner party and how like that shook her. What I loved about it was that she, in that story, she goes through the journey that we want most public sector. people to go through and most executives to go through, which is the practice of designing from the inside out, designing for institutions, for organizations, then having the aha moment hit you in the face when you realize, ⁓ this isn't working for the people that are meant to use it. And there's actually a way to do this that works for the people that use it, that creates a better experience. And so learning the value of feedback from users.
speaker-1: Mm. Mm.
speaker-0: And then she finds herself leading an organization like Code for Canada, where a big part of her job, not explicitly stated, is to recreate that experience for executives in government. It's not explicitly stated, but that is that is largely like what success is for Code for Canada, is helping teams inside government do the work necessary to have those aha moments and share those with decision makers.
speaker-1: Mm-hmm. Mm-hmm.
speaker-0: So that they invest more in in that work.
speaker-1: Mm-hmm.
speaker-0: You couldn't Marvel couldn't have written a better origin story than Dorothy's.
speaker-1: Yeah. And it's it's pretty cool because it gives her I I think it gives her a sense on what it looks like when that realization happens. I remember years ago ⁓ hearing Adam Cahane and his team from Rio's partners speak about facilitating conversations across stakeholders in complex spaces and the team ⁓ Him and the team are talking about the click or the click. Like this moment that's unspoken when all of these stakeholders like just kind of get something and you like it's not audible, or maybe the silence is what's audible. Anyway, he's like like you know, you know when it happens. And ⁓ that's probably what Dorothy can pick out and the rest of the Code for Canada team. that's so cool.
speaker-0: Cool. And and clearly able to empathize with folks who have not yet like arrived at those same clicks or aha moments, right? Like, you know, she can remember when she took for granted the weight like the status quo. And then having that, you designed that? That thing sucks. Which needs to be the title of her episode, I feel like you designed that. That thing sucks.
speaker-1: Right. But ⁓ but again that there are limits. Right. You can get that moment of realization at the executive level. You can support the teams to move faster and to, you know, go from taking six months to decide on like what the look and feel for a service should be to six weeks where you do a whole bunch of great discovery, kind of use your research, you do some rapid prototypes and you just like get ideas and options in front of people to get their real feedback. But that can happen at a team level, that can happen at a project level. But ⁓ nothing ⁓ really driving towards, okay, how does the organization kind of move to that that model? Or what what are the directives and conflicting policy or conflicting incentives that help an organization go from waterfall being the base ⁓ of model of how things are approved and strategies form to something that's more agile and user centric. So there's there's always gonna be tension unless you get into kind of rebuilding some of those ⁓ those f foundational rules and and processes.
speaker-0: You it's like you almost like you need that that thin slice from from the very top of a department or organization all the way down to the front line where there's someone, you know, whether it's the deputy minister's table or s the the C suite table, all the way through, you have managers through that are empowered to do the necessary thing. So going from the team level designing services to I using that as an opportunity to identify the policies, the legacy policies, the legacy processes, the legacy structures that are in the way of meeting the needs of the beneficiaries of your services and your programs, all the way to the strategic level where you're continuously feeding, you know, findings from the front lines, findings from the service level to the strategy level. And using that to manage your the performance of executives all the way through. ⁓ and I don't think that we
speaker-1: Mm.
speaker-0: We have that in many places.
speaker-1: Hmm. Yeah, no, no, I haven't seen like the full slice. Maybe, maybe in in some areas, ⁓ yeah, again, this came up in in the interview, but missions is potentially a way where you can kind of go from your like what is the impact on the ground, what's changing on the ground, are we halving the poverty levels or we improving mental health for youth by X percentage?
speaker-0: Are you?
speaker-1: And that being like a political accountability and making sure that the public sector is lined up from the deputy minister all the way down to achieving outcome. But I'm most curious about when you can create a slice ⁓ that makes sense? How do you then grow that that slice? how do ⁓ use that new business model? to take over the existing business model of your public sector institution.
speaker-0: I mean, maybe that's a question that you answer when you get there. But somebody I no, it's a it's a fan it's a fantastic question. I feel like to where I'm where I'm at in the year, I'm thinking like if I can just get that victory. And I and I'm thinking too about that connection between mission oriented government and the service level and how do you make the connection between the particulars of a service experience and
speaker-1: He's got for asking that question. Mm, mm.
speaker-0: the grander challenge, the grand challenge of things like ⁓ you know, homelessness and and poverty and climate change, et cetera. So I think that's a huge, a huge question and opportunity in terms of expanding the slice or the island of coherence, is that where is that where capacity building comes in? Is that where we start to think about Once you get that foothold and almost that that thin slice is the early adopter slice. And now you're thinking about how do you facilitate the adoption of these roles, these behaviors, these performance metrics, these decision making frameworks out. And what does that look like?
speaker-1: Mm, mm. Well, Policy Fight Club, it keeps coming up.
speaker-0: Okay. ⁓
speaker-1: That's definitely one of the one of the ways to try to go from creating a new set of rules and practices and patterns and resolving any conflict that this new slice has with the existing slice. And I think, yeah, like in both of our experiences and the people we've been interviewing, it's not like they've been breaking the rules or breaking the law. It's more that
speaker-0: Right.
speaker-1: you know, agile requires a new or an expanded set of rules or a different set of rules. And that we've been adding these new kind of rules directive on program experimentation that we have at the federal level. It's another good example where it's like layered on top. Mm-hmm. And what we're not doing is kind of pruning the things that might have been
speaker-0: Yeah.
speaker-1: really relevant rules and directives in the sixties, seventies, eighties, nineties, but in the two thousands, the twenty tens, the twenty twenties, like it's time to now kind of prune those back. And I don't know if we've been doing that as intentionally as as we probably should.
speaker-0: Right. Like reconciling the the conflict between policies. This is the fight club. Yeah. Or or Loki's ⁓ time variance authority where have to prune prune the timeline. Yeah.
speaker-1: Yeah. Yeah.
speaker-0: I don't I don't remember who wrote about this. I don't know if it was Dana Chisnell or Jennifer Polka, but this concept of red policies and blue policies. Do you know this one? Words like
speaker-1: Hmm. No.
speaker-0: One one version is is an actual policy, the other version is a policy interpretation. So when someone says someone says we we can't do X, Y, or Z because of whatever policy, then you have to go and find the policy. And what what they found was that much of the time there was no policy. It was just the way people did things. ⁓ and it was maybe based on an interpretation, you know, eons ago.
speaker-1: Mm. Mm-hmm.
speaker-0: Yeah. That's stuck. That's stuck. And I love and this has been coming up in my work lately, where people will will talk about we can't do X, Y, or Z because of this policy or these departments have conflicting policies. This is the opportunity to identify that very specifically. Like don't just say that in an abstract way. Be very specific, like this policy and this policy and show because we can't you'll never prune.
speaker-1: Uh-huh.
speaker-0: the timeline if if you don't get very specific about where those things are. And this is the value in service design, I think. If if if you were doing the work to identify what is desirable in terms of the experience and the outcomes for the people that we're serving, and you then encounter some policy or law that makes it unfeasible to accomplish, then you then have to go through the work of changing that policy or law.
speaker-1: Mm-hmm.
speaker-0: So that you can do the the positive thing. And without having people empowered at the higher levels to do that, based on the findings of the folks doing the design work, you can't do that. And so I think it just needs to be ⁓ an embedded part of of the new world for government.
speaker-1: Hm, one hundred percent. When we were leading on ⁓ program experimentation for one of the departments federally and we were working closely with central agencies to support more program experimentation, one of the values was explicitly to identify where there were friction points. running all these experiments will help us better see ⁓ what's slowing us So we need ⁓ to keep like ledger of friction points. So as part of my team's tools for programs and service units that wanted to use a new or novel policy making tool, be it like prizes of challenges or human-cepter design or whatever, ⁓ we were like, okay, document What was the objective, the things you tried, some of the outcomes, but what were some of the the friction points? What were some of the barriers that you were that you encountered? Because we wanted to see all the things that needed to be worked with to make it easier to do kind of program experimentation more systematically across the organization. We passed my list to a few central agencies.
speaker-0: Mm-hmm.
speaker-1: But yeah, to your point that that wasn't really anyone's job. Like to actually like pay attention to the friction points and then to ⁓ to resolve them.
speaker-0: Yeah. A hundred percent. I I used to call that when I was at the Digital Academy and we were running the digital accelerator program, like the prototypes coming out of that program needed in its sort of next level of maturity, needed to be treated as probes to the system to understand what what is stopping this when you go back to your home departments. What is stopping this, preventing this from taking root and growing and scaling? And we need that feedback so that we can start to address the
speaker-1: Yeah.
speaker-0: the contextual barriers. And I think this is why you have like parallel learning structures in organizations or like parallel organizations. And I think this is the this is huge value of the reimagine G and B initiative that I'm part of right now. Is that this is there's no one is no one's job right now, but this could become this program's job to continuously keep track of what's stopping us. And feeding that to decision makers and have that in as an embedded part of the decision making cycle.
speaker-1: That brings me back to one of the other things that I loved about Dorothy's reflections on what she would do if she was Queen for the Year. Creating accountability in the system, I think that's how she framed it. Trying to really map out if, you know, the government of the day had a transformation agenda, what's gonna slow that agenda down? And being really clear at the get-go, like what are some of the friction points that
speaker-0: Yeah. Mm-hmm.
speaker-1: the organizational leadership needs to needs to work through. ⁓ and I think we often skip that step, kind of get right into the build, right into the design work, but we don't do some of the critical preparation to split it away.
speaker-0: Yeah, what did she say she would focus on establishing like the OKRs and performance metrics?
speaker-1: Yeah, vision and OKRs to start.
speaker-0: Yeah. You change I mean there's a huge power in in changing what you measure, right? And I think
speaker-1: Class. Mm-hmm, mm-hmm.
speaker-0: That's a smart w like precondition to success that she focused on.
speaker-1: And I was at a political day this year and the former deputy minister of digital transformation of Ukraine was there she she was a panel related to exponential technology and government. ⁓ As you know, Ukraine went being pretty low on the digital readiness. ⁓
speaker-0: Mm-hmm.
speaker-1: ⁓ rankings to being kind of in the top five over a very short period of time. We all know why. But she was like, if I had to pick two things to focus on to really get my government ready to to take advantage of new technologies, it would be a vision of what we want and OKRs. I was like, there you go. it wasn't like ⁓ Digital accelerator. It wasn't give everyone a blockchain ⁓ a quantum computer. It having clarity of of where you want to go and ⁓ having a way to determine if you're there or not.
speaker-0: Yeah. Yeah. Why is that lacking? Why is that so hard? I mean, it it's not like the it's the first time anyone said that ⁓ leaders have to have a vision.
speaker-1: Mm-hmm. ⁓ I don't know. Maybe maybe it's that it's harder ⁓ to have a that's precise. You know, when we were chatting with Sarah around mission-oriented governments, ⁓ she was like, You need to precise about what you're after. Otherwise, it's, you know, I I wanna make innovation accessible or ⁓ we wanna be ⁓ a lot better at pick your social policy challenge or economic ⁓ policy challenge. that that's not precise enough. You need to you don't wanna be overly precise, but y you have to provide some some boundaries around what is in ⁓ a success perspective versus what is out.
speaker-0: Right. Hmm. Cause from from my standpoint, I would prefer a a audacious and ambitious vision and then find precision from there, if that makes any sense. Then the goal of a vision being precision. My concern with that is that you immediately are constrained by what you can imagine is precise. Like
speaker-1: Mm-hmm.
speaker-0: I think with metrics in general, it's like we will we're more likely to I think to choose what we know how to measure than what matters to measure. Yeah. And it's like I'd rather you pick the thing that matters and have no way of measuring it than pick the thing you know how to measure that doesn't really matter.
speaker-1: Mm-hmm. Well the the the foundational book around OKRs is Measure What Matters, I think is the title. we know a lot more how to set the right stretch goal. The whole the what is it, the prizes and challenges ⁓ practice. Like you want a goal ⁓ far enough outside of what
speaker-0: Right. Yeah. Yeah. Yeah. Yeah. Yeah.
speaker-1: It's deemed to be reasonable, I think. Is that the frame it? So it needs to be like a BHAG, like a big, hairy, audacious goal. But a big, hairy, audacious goal that is achievable, but it's just like you're pushing it. Yeah. Like going to the moon. Big vision. We we knew what it takes. You didn't have to get super precise. It wasn't like Kennedy saying we need to send somebody.
speaker-0: Mm-hmm. Outside of our reach.
speaker-1: X thousand kilometers outside of the Earth's orbit.
speaker-0: Yeah. But land on the moon.
speaker-1: But it was precise, like the moon, like not things.
speaker-0: Right, right.
speaker-1: So so I think you're you're right and you gotta find the right goalpost. Yeah. Because when we don't have a goalpost then it's easy to say, Yeah, we're contributing to that vision. And we're gonna change things incrementally and we're
speaker-0: Mm-hmm. We're good. Yeah. I mean, okay, the level of precision that the physicists had to achieve was pretty high. J J JFK didn't lead with that. Yeah.
speaker-1: And then the OKRs is like, okay, what's the process by which we're gonna get there? And I love OKRs because it also takes into account organizational capacity.
speaker-0: Right, right. It would have to become the goal. Cause at what point then we're going down a rabbit hole right now, but I just really want to have this conversation. We're gonna be cutting some things out, I think. But at what point do you okay, like if you're if you want to achieve X, you wanna get to the moon, but right now it's not organizationally feasible. Therefore, we need to set the conditions that allow us to get there. Like where does that fit for you if if The OKRs is about organizational readiness or feasibility. You know, it has to fit within that frame. What about the adjacent possible? Like how do I chase the adjacent possible?
speaker-1: Yeah. really good question. I think some of it is organizational design. ⁓ you know that your ⁓ mission or your ⁓ state requires a bunch of new capabilities, then ⁓ you build that into organization. sticking with that Apollo ⁓ mission
speaker-0: Right.
speaker-1: NASA had a huge group of like so many different components to getting a person on the moon. And yeah, there was a new organization set up, new rules established to make sure that the physicists were talking to the manufacturers. ⁓
speaker-0: Mm-hmm.
speaker-1: who were talking to the academics making all of these pieces of technology fit ⁓ those roles didn't exist before. So I think, yeah, if you have your OKRs, it gives you a bit of clarity on what's the next critical step that you need to build into your work plan and your funding to advance towards that. but you yeah, you need to give your teams the flexibility to be like, ⁓ we'll figure it out.
speaker-0: Bigger default. Yep.
speaker-1: the humility to be like, yeah, we don't currently have the skills to to do that. We're gonna have to we're gonna have to shift how we're organized. Or
speaker-0: It's such a it's such a brilliant example for that reason because you it's it's it's the perfect it's almost the like it's like a great case in that you have an organization, you have a system, an ecosystem set up, not just an organization, but an ecosystem set up ⁓ that moves from mystery to heuristics, right? And into execution or or you know, whatever process operationalization, etc. Whereas most organizations kind of ignore the first two parts. mystery and heuristics are are off the off the table and we're just operating.
speaker-1: Yeah, yeah, yeah. Just get collaboration mode. Like what can we do with what we currently have at our disposal? Which programs are already investing in, conservation or climate readiness and we'll just double down ⁓ on that. It's rare that the reflex of our public organizations are like, do we have ⁓ thing we currently have the capabilities? Is our organization designed in a way to go after that mission or that goal? And if not, then we need to go into the kind of institutional architecture space and make some adjustments or build something new. Like that is not the reflex.
speaker-0: What needs to be true for this to yeah. Mm-hmm. I d also just love it from coming from the research network, the like the level of collaboration that was required with universities across the globe to achieve that. And the infrastructure you needed, especially before the internet, The social infrastructure would have had to be credible. A hundred thousand people. A hundred thousand people to achieve that mission. Yeah.
speaker-1: Mm-hmm, mm-hmm.
speaker-0: That's big that's bigger than the city I live in right now.
speaker-1: Yeah, yeah. And it and it had to it had to work. So they figured it out.
speaker-0: Yeah. Yeah. Yeah.
speaker-1: You had to open up that space of possibility on how you're organized ⁓ ⁓ make adjustments.
speaker-0: So this has been a fantastic chat. I I that we're we're sort of closing on this this idea that organizations for true transformation and to achieve, you know, big hairy audacious goals and missions, there's a a level of boundarylessness that needs to to happen, right? There needs to an integration that needs to happen working with outside organizations like Code for Canada, who come in with external expertise and practitioners to work in an embedded way with teams to practice design with ⁓ with users and technology in a way that builds the capabilities of those teams inside government. We'll leave that for the next episode. Until then, thanks for joining us. Ciao.
speaker-1: Chao. I actually think there's a lot more entrepreneurship that happens in the public sector than people sometimes realize. If a child's about to wind up homeless on the street, does a deputy minister of social development get an email? Seems to me that's worth an email. Seems to me somebody should care about that at least as much as whether or not somebody rented a damn car. Show me your incentives and I'll show you the outcome matches very well.
speaker-0: Very well.
speaker-2: Same activism that likely drove you in those earlier days needs to stay with you.
speaker-1: What about ⁓ bigger questions around how people thrive in our society?
speaker-2: Person has a career path, a project has a crew. What if there was a ministry that could approach something in an unbounded way? And what if it had ministers or public servants that aren't confined in some kind of role or job description? For me, that journey in the internship, it was one of the best jobs I've ever had. And still that is still true today because of the impact that it has had on me personally. Nothing.
speaker-0: figure it out as we go and we built out these citizen things in a very unwaterfalled way.
speaker-1: Services. Many of these flaws are tied to deliberate choices. We may not have wanted to deal with the outcome, but they're there because somebody wanted it them. And maybe what I'll say about that is if it sounds like I'm cynical, I'm actually not. Because the fact that it is a result of choices means that we can also have the power to undo those choices.