Last summer, I landed a job at an agency that specializes in digital transformation (making better websites) for the U.S. government. Before that, I spent the first decade-plus of my career working in digital strategy at a large academic library.

My current role is my first job at a digital services company, my first time working on an Agile team, and the first time I haven’t been one of the only experts in the room on web technologies.

The other big differentiator? Scale.

Simply put, the projects my colleagues and I are working on are huge. Within the single government agency I’m serving, there are scores of teams working on complicated tech stacks with tons of dependencies, all in support of millions of users – our fellow citizens.

Here are a few things that I’ve observed in my shift from working within smaller digital ecosystems, to working on large-scale federal digital projects.

UX is a given

Thanks to a lot of heavy lifting by UX advocates, user experience and human-centered design are accepted (and funded) norms, rather than something that has to be fought for. User research is an imperative, and product teams are open to – and even hungry for! – their assumptions being disproven through research.

Accessibility to the front

There is a lot of good accessibility work being done in the civic tech space, specifically an accessibility beyond compliance approach that makes a lot of work in civic tech a model for how accessibility should be done in other industries. Accessibility is baked in from the beginning phases of design and development, rather than being an afterthought, an add-on, or a grudging nod to legal compliance. I’ve learned more about accessibility in the past 9 months than in the previous 9 years. There’s a long way to go, and it’s exciting that accessible, inclusive, trauma-informed design is part of everyone’s work.

We prioritize who we’re designing for

This seems obvious, but for many organizations who are trying to use their websites to do everything for everyone, the idea of designing only for certain users can be a tough sell.

We aren’t designing for agency employees, internal stakeholders or casual external audiences. We’re designing for, and prioritizing the experience of, defined groups of users.

We know our target audience(s), and acknowledge that people are visiting our websites to perform tasks. We measure results based on whether folks can do that. Though business needs show up to some degree in the design, the stuff we’re building optimizes for the user experience and task completion.

There are a lot of us

Our digital teams are cross-functional, meaning that there is some mix of front end coders, back end coders, UX designers and researchers, accessibility specialists, content strategists, and product managers working on each team. Each team is working in support of the larger project, and there are many teams that are here just to support other teams. We are all building the thing as we go. We spend a lot of time talking with other teams about what we’re working on.

Not everybody codes

Not everybody needs to know how to code to do their work well.

Email: LOL

Coming from a workplace that relied primarily (and heavily) on email for communication, it’s been a refreshing change of pace that I can count on two hands the number of emails I’ve sent since starting my job 9 months ago. Everything happens on Slack and GitHub.

This also means that we spend time optimizing processes for the best use of each of these tools. My email muscles may have atrophied, but my GitHub contribution history looks great, I have GitHub-flavored markdown syntax memorized, and I now know more about Slack workflows than most folks.

Work is in the open

All our work is paid for by taxpayers and subject to FOIA. We expect that everything we say is public. Most Slack conversations happen in open channels rather than DMs, and we’re helpfully able to hyperlink to previous conversations in other channels, creating a much more dynamic and interconnected communications ecosystem.

Meetings are focused

After years of attending faculty senate meetings that regularly ran an hour over time, I wrote in my notes the first few weeks at this gig: “People know how to run meetings here.”

If there’s a meeting on my calendar, I know who is running the meeting; what the purpose, agenda, and expected outcomes are; and how documentation will be captured. If we have to meet, we get to the point and we make it snappy. (On the flipside, it also means that we have to work intentionally to build community and rapport.)

I have one job

It has taken some time for me to get used to only having one job. My role is limited in scope, and I remain busy. Coming out of my previous role as a manager, the fact that I’m an individual contributor (IC) with a limited role has been extremely freeing. I’ve spent a lot of time focusing on improving within my practice area, learning from my colleagues, improving operational processes, and supporting my team.

No room for big egos

Everybody here is trying to do a thing to help people (or at very least, do no further harm to people). Working on projects with so many stakeholders and multiple levels of review for most decisions, it’s almost impossible to have a big ego, or hold on too closely to darling ideas, and survive.

Blameless but still accountable

The blameless approach to problem-solving asks: what if we assume that people make mistakes because of a systematic or cultural issue, rather than a personal moral failing?

Agile processes encourage us to reflect on how things are going through regular retrospectives and iterative changes. These processes allow us to identify systemic issues, including failure points, without fear of reprisal – and to still hold our teams accountable for making improvements.

Impact hits different

When working on products that have millions of users, one small change can mean a lot for users – in both good and bad ways. Any time my idea shows up in a final product design, no matter how small, I feel like a million bucks (while also hoping that the change doesn’t have unintended harmful effects for our users).

I also know that sharing my knowledge can result in a ripple effect of changes when other practitioners apply it to their work. When I shared a link to the Trans-inclusive design article I wrote almost five years ago, my coworkers applied the takeaways to the project they’re working on at an entirely different federal agency.

The potential for impact is humbling, and balances out the days when I feel like a tiny cog in a big machine.

Same problems, different scale

As much as things change, they also stay the same. For all the things I’ve seen that have been welcome changes, I’ve also seen stuff that’s been present wherever I’ve worked before:

• Varying adherence to, or buy-in for, standards
• Rushed, band-aid solutions
• Making it up as you go
• Teams working in silos, sometimes on the same problems
• Teams not taking feedback well
• Teams working on the parts but not the whole
• “Put it on the backlog. We’ll get to it later”
• Maintenance as an unsolved mystery
• Upgrades breaking stuff
• Legacy technologies secretly holding crucial components together
• Inconsistencies grudgingly accepted as a path to progress
• HIPPOs pushing through bad/precious solutions
• Weird workarounds for weirder constraints
• Constant change and turnover
• Competing priorities
• Growing pains
• Scope creep
• Failure!

The people, though.

One thing I say often is that technology is people – and civic tech as a field tends to attract folks who care very deeply about outcomes for our very human users. I have yet to meet someone who is hesitant to share ideas, give advice, or otherwise help when needed, and I have learned so very much.