November 25 – December 1
My “weeknotes” capture events, thoughts, and other items from the past week, mostly focused on work. Learn more about the weeknotes concept here.
NOTE: I’m changing up my weeknote format (again) to see if I can keep it simpler, cleaner, and more flexible. Although this week’s post is pretty long. I’m starting to wonder whether I should be posting individual pieces rather than gathering everything into a single weekly post.
One Thanksgiving and a funeral
It was a short work week in the U.S., with the Thursday-Friday holiday. But I also had Wednesday off so I could attend a hastily-assembled funeral in my extended family (my brother’s mother-in-law). I drove down to Louisville, Kentucky on Tuesday evening (with 2 major accidents rerouting traffic along the way). The funeral was Wednesday morning — a sweet, but short ceremony. Then I was off to Columbia, Tennessee on Thursday morning for Thanksgiving with a portion of my nuclear family. Finally, we drove all the way back to Ohio on Saturday (avoiding the entirely predictable Sunday traffic).
So yeah, it’s been a little crazy this week. A lot of hurry-up to slow down.
How are people really using #genAI at work?
Oh man… this is a really great post from across the pond, and it made it into my weeknotes just under the wire! In this post Rachel Coldicutt shares her direct observations of how office workers in government and the private sector in the UK appear to be using generative AI in their day-to-day work. And it’s precisely what I’ve observed, but with far more thought.
This should be assigned reading for government technology folks everywhere. Like, turn in your badge if you’re promoting AI but you haven’t read this piece before the end of the year. Given that we in government deal in trust first and foremost, heed one of her summary observations:
If your business depends on trust – in delivering services, developing relationships, taking care of people – then generative AI in particular will probably only deliver marginal gains for some individuals, and that may risk the quality of your overall delivery. … I’d suggest starting with looking for easy efficiencies that can be delivered without an algorithm rather than trusting in tech to deliver the change.
Bluesky over Boston
Meanwhile… take note #govtech friends. You should probably move your primary short-form social media to Bluesky, the rapidly-growing platform that isn’t owned by Meta, isn’t as difficult and doctrinaire as Mastodon, and isn’t co-opted by Nazis. If you need inspiration to get moving, consider this: Boston is leading the way.
Even Mayor Michelle Wu’s office has a Bluesky account.
I previously argued in favor of Mastodon for government digital communications, given its open/federated nature, which feels like a better match with democratic principles. But Mastodon has remained too insular and too complex for mass adoption, meaning any government attempts to communicate with a large swath of the public would be wasted.
Earlier in 2024 Bluesky opened itself to public sign-ups (after spending the first couple years in invite-only mode), and it’s been gaining users rapidly in the last 6-8 weeks as the Nazi problem on X continues to expand and as Musk has proven to be an increasingly vocal, toxic, and anti-democratic billionaire.
So setup shop now and integrate Bluesky into your social media mix before all the good handles are gone. And shutdown your X accounts.
We need digital services training for government teams. But how do we get it?
Before heading out for the holiday, I had a great conversation with #civictech nerds Amy Martin and Caitlin Seifritz. Their talk at the Code for America 2024 Summit this past May caught my attention and they recently posted their research as well.
We discussed our shared concerns about how to get knowledge into the minds of pro-public-service government colleagues in our own organizations and across the country. Digital service teams sometimes struggle talking to front-line workers and leaders because we lack a common vocabulary or vision.
What I would love to see is some kind of “standardized” curriculum for teaching digital service concepts to fellow government workers that are pro-public service but just haven’t been exposed to design thinking, human-centered design and service design, user research, customer experience, product ownership, or… well, you get the idea.
So far the concept is to create and host an online “summit” for interested folks in spring 2025 and see how far we can get in addressing these needs. I’m definitely not a leader in this space, but would very much like to benefit from whatever might be created down the road.
Honestly, I feel like this is something one of the bigger players in the space could own, but so far it just hasn’t been addressed. This is basic capacity-building stuff, but it’s potentially really, really big. We’re talking about tens of thousands of potential “students” across local, State, and federal levels.
Personally, I’m dreaming of a cohort-based training model that knits together a lot of great training content that already exists out there. Civilla has training. IDEO U has training. There are resources from 18F. Even places like LinkedIn Learning or YouTube have bodies of content that address this need. It’s just that none of this stuff is organized in one place, and there’s not one well-planned curriculum. I hope we can foster creation of a solution.
Attracting and retaining talent via mission mindset
Also before heading out on vacation I did an interview with Makayla Hipke about how I try to attract and retain talent, specifically on digital service teams. She’s completing a degree program with a research project, and she’s interviewing digital service folks across the country. (We initially made contact via Technologists for the Public Good.)
My main point for both attracting and retaining talent is that we should focus first and foremost on hiring candidates that have a mission focus, even if it’s in the early stages of expression. If we hire employees that have a purely transactional mindset, government digital service teams will struggle to keep them satisfied—we can’t keep pace with private sector salaries, we don’t have bonuses, and we sometimes move slowly on career growth. A candidate or employee that prioritizes public service will be less enticed by dollars and more enticed by making a difference. We still need to do right by our teams in terms of cash and benefits and career growth, but we’ll all get along better if we’re on the team for the same root cause.
Yes, but…
A key realization I had walking out of this discussion, however, was that mission-focused teammates need to know, viscerally, that their work is making an impact. They need to know the mission is actually being accomplished. For that to happen, we as leaders need to do 2 things that we may not be doing well:
- Ensure a solid portion of the work really does make a palpable difference, ideally in a way that’s measurable. This means the work can’t all be technical debt retirement or rote service delivery. If we say we’re doing digital transformation, well… we better actually transform something.
- Build storytelling capacity. Because even if staff are making an impact, they may not be able to see it or feel it. We all struggle to see the outside surfaces of the boxes we’re inside. So let’s be sure we’re capturing metrics and human-scale stories and package all that into something employees (and customers) can feel, usually in narratives with a few stats.
Part 1 requires good project selection and prioritization of impactful work. Part 2 requires story discovery, storytelling, and perhaps a bit of media savvy, too.
Learning to slow down when building consensus around big ideas
I took over our “Delivery Services” team this past summer and began to explore what was working and what wasn’t. One clear problem was the way projects got started—it tended to be a chaotic process at best. There were other issues, too, but I’ve learned a key lesson in tackling this new challenge: slow down.
In years past when confronted with the need for process (or other) changes, I would assess the situation, devise a new model, and then put it out there. I’m pretty quick with assessments and typically my models have been appreciated (or at least tolerated). From first contact to new approach might only be a couple weeks.
But not this time. I knew that wouldn’t work.
I’d watched past leaders in our organization attempt to build and evangelize “intake processes” for projects and watched every single attempt fail. Indeed, I was handed some of the past process flow charts and, to be honest… I’d scoffed at them. The models were developed behind closed doors and described an ideal state we were far from achieving. All prior models were set aside and ignored by everyone, including the team that developed them.
I didn’t want to repeat those mistakes, so I had to set aside my fast-planning tendencies. I had to find a way to do this as a group, and do it slowly, to build shared understanding and shared ownership. Any attempt to “impose” a solution would fail (and rightly so).
It’s been hard to alter my approach! But it’s been more rewarding than I expected.
I won’t get into the model right now (I can save that for another day), but at a high level the intake process has 3 main phases, each led by one of 3 teams, aimed at producing one of 3 key artifacts (documents). It’s not terribly complex. But there’s a lot of baggage:
- 2 of the 3 teams have the same manager while 1 of 3 has a different manager, under a different executive
- 1 of the 3 teams was only created this summer and they are figuring out their role and where they fit in; plus they added 1 new hire and 1 transfer from another team during formation
- 1 of 3 teams has strong feelings about having been ignored in past efforts to organize incoming work and deliver results—they’ve always gotten the short end of the stick and get blamed for project difficulties they didn’t create
- The artifact (document) templates don’t exist yet and are being developed in-house
- A lot of other teams (like engineers) have to be brought into our process as resources, so they need to understand the model, too, to be successful and to ensure they don’t undermine the process (inadvertently or intentionally)
That’s a geometrically complex set of feelings to manage. So you can’t just write a white paper and pass it around for everyone to read (like I have in the past). A lot of stuff has to come out and be processed. It has to be a shared experience.
So it has to be slow. People need time to process, participate, and take ownership.
It’s nearly killing me to go slow like this. But I’m learning.
A strategy execution model
Saw this post on LinkedIn from a strategy consultant and I really appreciated it. Jeroen Kraaijenbrink is a good one to follow if you like nerding out on leadership, strategy, and other mental models for teams and organizations. His summary graphic is below, but go see the original post for details.
Models don’t work without strategy
Speaking of strategy, another LinkedIn post got my attention this week, and it starts off strong:
The problem with OKRs is the problem with JTBDs is the problem with SAFe is the problem with user research. The problem is that you didn’t define a goal or a strategy.
As a fan of all kinds of models and tools for organizing and thinking about work, this is a great reminder that a tool is something you use. Otherwise the tool is using you.
Added Civic Match to Digital Government Jobs
I saw this post on LinkedIn about the launch of a new candidate / job matching service: “Civic Match by Work for America connects public servants in transition—from the White House to federal agencies to campaigns—with critical roles in state and local governments.”
I’ve added Civic Match to my Digital Government Jobs page and I hope it helps out a lot of folks, especially in the likely federal purge we all fear is coming.
Podcast: Politics Recoded (Civic Tech Chat)
Finally this week… while traveling I was able to listen to the Civic Tech Chat podcast from Ryan Koch, in which he interviewed Aure Schrock, author of Politics Recoded: The Infrastructural Organizing of Code for America. You can listen to the episode here.
This was super-inside-baseball stuff from the national #civictech scene, and pretty academic, to boot. So yeah, this was my jam.
I learned a bunch of stuff about the history of Code for America that explained what I’ve seen but until now not quite understood. For example, when I attended the 2024 Summit this past spring, I was shocked only 2-3 vendors were there with tables, hawking their services. I later found out the cost to appear at the conference was astronomical, pricing out even the most well-heeled vendors. Then at the conference we learned CfA was doing direct work with the federal government (on the IRS Direct File program), which was confusing. Is Code for America an advocacy and capacity-building nonprofit in the civic tech space? Is it a development contracting shop? And if it’s a contracting shop, is it a competitor to the organizations doing contracting work, so maybe they aren’t welcome at the conference?
If you’re confused by this, too, check out the podcast.
Additionally, I appreciated the academic notion of “infrastructural organizing,” which explains a ton about my direct experience over the past 5 years, where my host organization’s lack of strategy has been, at times, frustrating. We say “yes” to just about everything, which leads to bouncing from priority to priority. So did Code for America as it struggled to learn how to engage in the complex #govtech and civic tech world, especially at the federal level.
At least now I have a name for it.
Discover more from digitalpolity.com
Subscribe to get the latest posts sent to your email.
digitalpolity.com 