2025 Weeknote 15 : You manage things; you lead people —Grace Hopper

April 7 – 13

My weeknotes capture events, thoughts, and other items from the past week, typically focused on work. Learn more about weeknotes here.

Leading vs. Managing vs. Doing

Last week I talked about context switching and the trouble it causes me. Calendars like the one below—a snapshot of my own calendar from this past week—illustrate context-switching in color and pattern:

The event colors represent various “contexts” I work in. The colors cover several categories, and the most common are:

• DS = leadership and management time with our project management and business analysis teams
• ELT = time spent on organizational leadership at the exec level
• FCDC = Organization-wide events, sometimes with customers
• GXF = leadership and management time with software development, commercial platforms, and public digital service teams
• Project = time spent on cross-team / cross-organization project meetings or work
• Training = professional development time spent in webinars, national working groups, or training, including time spent developing training for others
• NOT SHOWN: Time spent after-hours and on weekends catching up on the work I couldn’t do during the day (because I was in meetings), posting and engaging on LinkedIn, writing this blog, and of course life in general

Wait… So what about leading / managing / doing?

While I was thinking more about context-switching this week, I realized there’s more to it. A flubbed interaction with a colleague revealed I was ignoring a key dimension to my role.

I’m not just context-switching on tasks and teams, I’m also shifting gears between (1) being a leader, (2) being a manager, and (3) being an individual contributor. And that is… confusing, especially for my colleagues.

• Being a “leader” means managing managers, setting and reinforcing strategy, mediating between teams, making calls about work priority, and coordinating with my executive peers.
• Being a “manager” means working with individual contributors (ICs) that work directly under me (I have both managers and ICs reporting to me right now), which can include assigning work, tracking work, providing direction, priority, and context, and handling even mundane things like timesheets, PTO or training requests, running team meetings, etc.
• Finally, being an “individual contributor” means participating in project or service delivery work personally, like building digital content, figuring out how to solve problems for customers or peers, developing documentation, and more.

I can “code switch” between these modes pretty fluidly. Indeed, it’s all just “work” to me, so I don’t even know when I’m slipping from one mode to the next and back again.

But this is—it turns out—a problem.

Yes, Chef!

While I switch between my roles and think nothing of it, my colleagues do not know which role I’m playing at any moment. Am I a colleague? A boss? Am I asking or telling?

Truth is, everyone has my title in mind whenever they see me. In the eyes of my coworkers, I cannot be an individual contributor. I am always a “Chief” of some kind. I’m a boss’ boss. I’m a half-step away from CEO.

This means my whispers are bold, loud statements. My “inside voice” sounds like yelling.

It is virtually impossible for me to “whisper” anything.

Can you hear me NOW?

So when I’m working on a project as an IC, and I push to get things moving, passing emails, documents, or decisions to coworkers (often after hours)… my intention is to be a colleague, but I can’t shake my title. My “request” comes across as a demand. My “observation” is a devastating criticism. My idle speculation becomes gospel. No matter how much I want to just be a peer, my three-letter title is like the neon sign outside Kramer’s apartment in Seinfeld.

And so, this past week, while working after hours on one of my contexts, I was blindly blending my leader / manager / contributor roles and ended up inadvertently “shouting” at a colleague. I didn’t even know I did it. Definitely wasn’t intentional. Indeed, if you read the words of my message and ignore my title, it’s actually pretty anodyne. But add the three-letter title filter and it sounds different to a lot of people—especially folks on parallel teams that don’t know me well.

Stuff to fix (eventually)

To ensure I’m focusing on the right things at the right levels, to reduce context-switching, and to just get the most valuable things done, I feel like I need to make several changes:

• Where possible, stick to one mode, and that mode should be Leader, because…
  • That’s the way people see me anyway (I can’t stop them)
  • That’s where I can make the biggest positive impact over time
• Redesign my default calendar model to…
  • Reduce context-switching by clustering similar activities and teams
  • Block out enough time to ensure I have thinking / strategy time; to be an effective leader you can’t be jumping from meeting to meeting to meeting all day, every day, and never reflect on what you’re doing, how, and why
• Reshape my role to…
  • Narrow my focus to leading managers rather than managing ICs
• And finally, I must remain ever-aware of my positional authority and perceived power
  • I may not think of myself as that big a deal, but a three-letter title—even in a small org of 100 people—carries more weight than I realize
  • Indeed, if “leading” is the best use of my time, talents, and efforts, that imposes the responsibility of minding the way I’m leading

All easier said than done! It will be difficult to achieve all these goals during 2025 due to some resource constraints in place today. But I may have some help on the way. The work we’re starting with USDR may allow us to think past the constraints. Speaking of which…

Working with USDR

As discussed in prior weeknotes, we started working with U.S. Digital Response (USDR) this week. Had a kickoff meeting with 4 volunteers and the 6 folks on our side. I fired up an online space on Basecamp to share files and updates along the way.

We’re really excited to get this going and see where it goes. The hope is we can get some fresh ideas on how to revitalize and update the GX Foundry structure and methods, and maybe a bit of sprucing up around the Delivery Services processes, too.

More Work Simplification

Last week I pointed to posts about the work simplification program built out during the 1950s in the federal government. And this week the conversation online continued, with thinkers Derar Deek and Kevin Hawickhorst sitting down for a discussion on the applicability of the old simplification ideas to our (seemingly) new problems.

This led me to comment on LinkedIn with an additional insight that struck me this week. Here’s the comment, lightly edited and re-shared here:

As I keep thinking about this, I’m starting to believe the problem is that the “new guys” promoting digital approaches simply believe the old rules should be abandoned in favor of new ways of doing things. They believe things are so different now there’s nothing to learn from our forebears. Digital folks (and I may be guilty of this at times, too) believe disruption is the point—that innovation and improvement comes from disrupting the old and ushering in the new.

But that’s not true. Or at least it’s an incomplete thought.

Disruption may be necessary to shake loose a locked-up machine, but it’s not a recipe for alignment with goals and continuous, iterative improvement. Eisenhower’s bureaucrats were raised in a society still traversing the Industrial Revolution at scale—they could see how constantly tweaking and redesigning could get good results, especially when small changes accumulate across massive processes. Think Six Sigma or Lean.

But too many of us digital folks—many born toward the end of the 20th century—never worked on an assembly line and have not realized the accretive benefits of small improvements, applied again and again (a “kata” in Japanese thinking).

We need these industrial ideas to power our digital refinements.

I and many of my colleagues are drawn to “total rewrites” or rethinking everything and starting over. That’s certainly one way to learn how a system works, but it’s also slow, hugely disruptive, expensive, and frustrating for all. The change management requirements are off the charts for that kind of work.

But establishing a baseline and tweaking, tweaking, tweaking allows for broad participation in devising improvements in processes and allows for smaller adjustments. It’s still a change management challenge, as you have to ensure everyone knows how and when things are changing, and keep them on-side as you go. But each change is smaller and you can get positive feedback loops established as teams quickly realize the benefits of the changes made.

So let’s get to changing. A little at a time.

Joined an AI training program with PPS

Speaking of changing… generative AI keeps bouncing around the digital government space, taking up a lot of attention but not yet really making a material difference. I have questions about where this is going and how we should pull AI tools into our work.

To that end, I’ve joined a pro-bono exectutive AI training program over the next few months, from here to September. Provided by the nonprofit, nonpartisan Partnership for Public Service, I found this opportunity via a post shared via the Technologists for the Public Good community.

An introductory session was this week, and the first seminar is next week. By the end, I’m supposed to generate a case for an AI deployment relevant to my organization. Should be interesting.

I talked to a customer! (and that’s way too rare)

This past week I saw a statistic noting how 56% of leaders haven’t talked to a customer in over a month and… yeah. More than a little true in my case. Except for this week!

For the first time in far too long I went on “safari” and met with a customer this week while getting a new teammate ramped up with a new, small project. (We’re establishing a new unified “archival” storage space for about 50TB of GIS digital imaging data going back literally 30 years.) This allowed me to ask questions, envision the customer’s experience, and ensure we’re solving the right problems the most efficient way.

When working on our internal processes and the interactions of teams in our shop it’s so easy to forget why we’re doing all this. It’s not for us—it’s for customers (agencies and their teams, all trying to provide good government for the community). So I was thankful for the chance to actually participate this week.

I can’t do this all the time, but I should figure out how to incorporate this into my work periodically.

Linknotes

• Shared by Tyler Jensen on LinkedIn, this Substack post by Kent Beck on why AI adoption is not taking off like wildfire. It’s the people and that pesky Law of Diffusion of Innovation they all follow. The seminal insight to understand: “The most effective driver of AI adoption isn’t better models or improved accuracy—it’s success stories from peers and respected figures in professional networks.” Indeed, a presentation at Code for America Summit 2024 finally got me to see where LLM-based AI tools can help digital government teams to accelerate their work, without ceding control to the messy world of AI.

---

About this week’s header photo