Our digital ecosystem is big, and there are scores of teams using our design system to build their products (What is a design system?). Our design system has been around a while, it’s super-robust, and it has buy-in across the organization. My team’s main job is to meet with other teams throughout their design process to make sure that the teams’ products align with the rest of the website, meet web and accessibility standards, and of course, use our design system appropriately.
This doesn’t happen all the time, but there are some recurring patterns I’ve observed as product teams work with our design system. I don’t think this is unique to our context; I’d wager that these are totally normal things that happen when a design system matures and is in active use by a lot of teams.
Instead of designing an experience or an interaction, the team puts design system components on a page (or in a Figma file) to create an interface, without thinking about the actual user experience. Components are chosen because of how they look, not because of what they do. It’s not UX so much as paint by number. The design has features you recognize, but that’s where the familiarity ends.
If you have a pre-launch QA process for products (as we do), those design issues, if not caught early, result in a ton of problems that need to be fixed before the product goes live. If those findings aren’t deemed important enough to fix before go-live, they go to the team’s backlog to die, and the user experience suffers.
If the product ships as-is, it looks like the rest of your site in some ways, but it’s unusable, inaccessible (or 508-compliant only, rather than truly accessible) and you’re not sure what it’s supposed to do. It doesn’t actually help your users.
Because robust design systems and Figma libraries make it easier to rapidly develop high-fidelity prototypes, a team’s early design ideas can sometimes ossify too fast. At first glance, the solution seems good. On second glance, it’s clear there is something not quite right, and there is an increasing number of boo-boos being covered up. The sunk cost fallacy leads teams to keep as much of what they’ve got as possible, even if what they actually need to do is scrap it and start again.
The result is something that just ain’t quite right, an incomplete or overly complex solution that has gaps for some users with “non-standard” use cases. It’s an increasingly brittle interface that makes maintenance a bottomless pit until it can be rebuilt. This’ll create frustrating experiences for users, and it’ll be an interface that they have to learn over and over again.
Teams use the design system to design experiences (perhaps quite well!) but don’t contribute to the design system’s growth. Or, they may craft workarounds when the design system doesn’t do things exactly as needed, rather than suggesting changes.
The implications for this are system-wide. The overall user experience of your digital ecosystem can suffer. Stale, inflexible experiences don’t evolve with the times, or worse, teams abandon design system components to craft their own experiences, creating long-term maintainability problems. The end result is a degraded experience for your users, a maintainability quagmire, and inconsistent designs across your platform. In my work context, this is something we work very hard to avoid.
Technology is people. Design systems are people, too. Most of the issues here, and their solutions, involve deeply human stuff like relationship-building, conversation, clear documentation, conflict resolution, and feedback loops.
Like any other technology, design systems need attentive care, maintenance, upgrades, and human stewards to ensure that they’re used to do the thing they’re supposed to do. The key is being prepared to support the entire design system, including the people who are building with it.
]]>More about PDN:
The Prosocial Design Network connects research to practice toward a world in which online spaces are healthy, productive, respect human dignity, and improve society.
Here’s their recap of the event, and a video of our Q&A segment (15 minutes).
They shared the questions in advance, which I very much appreciated! Here are my prepared notes - we certainly didn’t cover it all during the call.
First off, hire people with different lived experiences from yours. Hire trans people. Hire Black people. Hire disabled people. Hire disabled Black trans people. Let them cook. Listen to them. Otherwise you are, as my wife says, “Pissing into the wind.”
Prioritize accessibility. Ensure spaces are accessible for users on many devices, using different device settings, in different contexts in the real world including with assistive technologies. Often accessibility is an afterthought. Shift left and allow it go drive your design and architecture decisions from the jump. For social apps, this includes setting smart defaults - i.e. requiring folks to add alt text if they’re uploading images.
Keep your tech stack light and boring. Design for a 4-year-old Android phone on a 3g connection, with bandwidth paid for by the megabyte. Bloatware takes longer to load and harms or disincentivizes participation from folks on slower connections or older tech.
Design for trust, privacy and safety. Design for people to be able to protect their privacy, control what they share and what they see.
Allow people to define themselves. The way you do it ain’t the way everybody else does it.
You may have noticed this isn’t necessarily specific to trans-inclusive design. That’s because this is the kind of work that, by considering folks in marginalized positions, benefits everyone. It’s the curb cut effect for accessibility AND privacy AND safety AND inclusion. By focusing our design on the margins we include everyone between them too.
The biggest fail I continue to see is that folks are asking for gender or sex information at all, because it is usually not needed. It usually means that this data is being brokered into a database somewhere and sold for money.
I don’t need to tell you my gender to book a hotel. Why are you asking for it?
The unnecessary asking for gender gets worse now that we are seeing a rollback of previous progress in inclusive design we had made in the past few years. We’d been doing so well! The US Web Design system had a really thoughtful pattern about asking for gender that was starting to roll out to all these government forms. But now agencies are in the process of removing the pattern for asking for gender in an inclusive way, and replacing it with a binary option for sex.
These design systems changes are in addition to removing all references to being trans from websites, and no longer offering services or information for trans people. It’s a very literal erasure of trans identity. It’s really upsetting, scary, and for trans folks, it’s existential.
I encourage practitioners to plan ahead for the moment when you are asked to do something that you know is wrong. That day will come. What will you say? What will you say no to? What’s your red line?
I have a lot of concerns with AI. I do think there are useful applications for the technology, and 99.99% of the applications out there are either actively predatory, passively harmful, gratuitous and mid, or all of the above. And they are all harming the environment and our health.
“synthetically generated texts from five of the most pervasive LMs …perpetuate harms of omission, subordination, and stereotyping for minoritized individuals with intersectional race, gender, and/or sexual orientation identities.” - Laissez-Faire Harms: Algorithmic Biases in Generative Language Models (2024)
…and this includes code. When AI is trained on design patterns or code that is widely popular, but that also includes a lot of code that’s inaccessible or unusable, the resulting code is also inaccessible or unusable. We should also be extremely wary of any AI tool that claims it can refactor a codebase written in a language that most modern coders are not using.
AI is a tool of capitalism and state violence. Generative AI is being used to consolidate, analyze, and generate information in a way that can be used to surveil, prosecute, incarcerate, and kill people.
AI is seen as a smart humanoid. People tend to believe algorithms more than each other as task complexity increases - but we also tend to view AI as human-like. We anthropomorphize AI tools by giving them human-like names or designing them as chat prompts (rather than command prompts or even search boxes), which leads us to believe that we are in fact talking with another living being rather than a computer. It also leads some folks to think that AI will become sentient. It won’t, actually, but it will if humans believe that it is, which is perhaps worse.
AI is mid. And by that, I mean that what it produces is functionally a middle-of-the-road, average, non-“edge case” output. This flattens our differences and creates a “norm” which actually does not exist. Individual people aren’t “normal”, but AI sure likes to tell us that’s a thing, and that really harms people who are far from that norm. Saying that everyone is the same denies the fact that we are all weird as hell. It’s our differences that make us stronger, more creative, better.
Critique is painted as fear. Proponents of AI say that skeptics are “afraid” of AI or don’t understand it. I, for one, am not afraid of it - I’m frustrated by how folks are positioning it as the solution to all our problems. I do understand it! I know too much. Dismissing AI detractors as “fearful” allows proponents to dismiss valid critique outright rather than engage with it. It’s a strawman argument.
If you are AI-critique curious:
If you don’t need to use AI, don’t. Do something else. Turn off default settings that include AI. Switch your search engine to DuckDuckGo and turn off AI features. Turn off Apple intelligence. Turn off Google Gemini. Take a harm-reduction approach to your tech use. (FWIW, this is my approach to eating animal food products. I’m not vegan or even completely vegetarian, but I don’t build my food habits around animal products, which reduces how many animal products I consume.)
Don’t make AI your main thing. Charles Eames said, “Never delegate understanding.” Don’t rely on AI alone to make decisions about what’s true, certainly not for core parts of your work.
Understand the bias that ships with your LLM. Do everything you can to critically evaluate outputs for inaccessible, biased or otherwise harmful content. Right-size your models and turn down the “creativity” setting.
Advocate for sustainable, safe AI, including regulation and environmental mitigation measures. Individual choices get us down the road a piece, but what we really need is to mitigate the impacts at a high level.
Engage your discomfort. If someone critiques AI and it makes you uncomfortable, listen to understand and be open to changing your mind. Most of the folks who are warning about the harms of AI are minoritized people - Black and brown women, queer and trans people. Believe them!
This is an excellent question. Some of the things I’d ask folks to understand include…
What are ways we can design for trust and safety? How can we create digital spaces where people feel safe? What are some of the ways we can foster trustworthiness?
What would trans-informed design look like? How can we use the very concept of transness - boundary-crossing, liminality, non-binary thinking - to expand our thinking about how technologies can be used, and to what ends?
Oliver Haimson is studying this very thing, and his new book Trans Technologies is available for free, open access, from MIT Press.
How might trans-inclusive digital design change IRL service design? We’re already seeing this as part of our work in Civic Tech, moving from automation to true digital transformation. We all know that real-world constraints map to technological design choices. How then do we transform the tech stack and use that to change our very service delivery model?
]]>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.
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.
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.
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.
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 needs to know how to code to do their work well.
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.
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.
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.)
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.
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.
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.
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.
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:
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.
]]>This is a lightly edited transcript of our interview in September 2023, shared here with her permission.
Erin joins us today to talk about what it’s like to be an information architect within an organization and how IA’s utilize organization, labeling, navigational systems in their day to day. Welcome, Erin.
Thank you. So excited to be here.
I know, we’re really excited to have you. Before we dive into IA, why don’t you tell us a bit about yourself and your career journey?
Yeah, sure. Like like many folks in the tech space, it’s been kind of a winding path for me. I’ve been making websites since 1998, since I was like a teenager. Didn’t really have many friends but I did have a dial-up modem connection!
Eventually I found myself in a graduate program for information science at the University of North Carolina at Chapel Hill. I knew that I wanted to do digital things and I was really interested in building for the web, but I wanted a theoretical match for that, to understand why we do what we do. I learned a lot and came out on the other side as an academic librarian.
And you know this, because you hired me for my first job!
Okay. I was just thinking about that today. I think you were my first hire ever.
Yeah! It was January of 2009. I interviewed for the job at Virginia Commonwealth University. I came in as a as a web developer, and at that time, “full stack web development” was – the word didn’t exist yet, but that’s basically what I was doing. Web design, web development, a little bit of usability and UX research and a little bit of information architecture.
And then I worked at VCU Libraries for 13 years. When I left I was a department head, leading digital strategy. By the time I was in that role as a department head, I wasn’t so much doing that hands on work anymore. I was leading a team, which I loved. Eventually, though, I was looking for something new. My family relocated a year ago, my wife got a new job, and I took that as an opportunity to pivot my career.
Over the past 15+ years, the roles in web work have specialized a lot as the field has matured. IA had always been one of, like, 20 things that I’d done as part of my job. When I was job hunting earlier this year I decided to try to go all in on information architecture as a career. There’s not a lot of roles out there; there are a lot more in corporate settings and or in large scale government settings.
I had been interested in entering the federal space for a while, then applied at Ad Hoc, and here we are.
We talked a lot at my last organization about Squiggly Line careers instead of the straight path. It sounds like you’ve definitely been on that journey.
Yeah, once I got rid of that idea that I needed to have a career path that just looked like a graph going up, that it could just sort of meander, and I didn’t necessarily have to manage people in order to advance in a career or feel like I was achieving things – I think that’s when I really was able to embrace an individual contributor role, on a team.
It’s different. My current role is really…it’s been a nice fit so far.
Fantastic. What do you find in this transition to a full-time IA since you had other things in the mix – web design, web development – what’s it like to have this full time IA role?
Well, for one thing, it feels like kind of a luxury to be able to just focus in on one practice area. With larger digital shops, you have people who are able to really be focused in on their area of expertise. You have people who are content strategists, who are UX researchers, who are developers. So to to really be able to focus in on the practice area of IA has been really great, and it’s allowed my knowledge to increase really rapidly, because I’m doing it every day instead of it being, you know, one of 20 things that I’m worried about.
Another thing I’ve noticed is, there’s a permeable membrane between information architecture and more strategic work on these projects. I’ve started to work on issues at my job that are not just specific to web interfaces or digital products, but that are more 30,000-foot messy information problems. For example, if we are trying to get a handle on a set of concepts, or how to categorize or group clusters of objects, ideas, etc.
It’s been cool to be able to focus on the website, but also to know that there are thorny info problems that really need that IA brain to be able to to conceptualize, put words on things, and be able to move the conversation. It’s about creating that generative space where you get people together talking about something and you’re asking the questions to move the conversation. IAs do that a lot and it’s a skill that really translates.
Yeah, definitely. When you think about, you know, the traditional things that we learn in IA: organizational systems, labeling systems, navigational systems – how does that appear in some of the day-to-day work that you do?
I think about this a lot in day-to-day work. I’m working on a huge federal project and my team specifically is a governance team. So we work with all the other teams that are working on this digital ecosystem to make sure that what they create is consistent based on standards, and that it’s going to be a unified experience for our users.
I’m not necessarily creating site maps or generating user flows, but what I am doing is working with others to give them guidance and review their work, and make sure that we’re all solving good problems.
We talk about organization a lot. One of the cool things about about this project is that we do a lot of user research. We talk to a lot of people and really try to use that research to understand people’s mental models of what they’re doing, understand how they think, how they group items together in their brains so that we can try to match what we’re building to those conceptual models. Everybody’s got a different brain, but you can observe themes and trends and make some decisions based on that.
On the flip side, we’re working often with legacy systems and designs. This isn’t the first time we’re building, a page about a service. There was a page or entire website about that service that was developed 20 years ago. And at the time, the way that we made websites was different. We didn’t have an emphasis on user research. We were building websites that matched our organizational structures.
That’s Conway’s Law, where the software you build matches your org structure pretty much one to one.
Yeah, Conway wrote that in the sixties and we’re still seeing it in a lot of sites.
Yeah, I saw it when I started at VCU! I was joining you in your work and you were like, oh my god, this website is the library org chart, and we need to undo that.
Yep, exactly.
So there’s a lot of legacy work untangling that and reorganizing to better match how people might actually use the site and understand things.
That’s really awesome to hear about the user research. Within this class, we’ve had a lot of emphasis on user research. One group has done a card sort, and they’ve also interviewed each other to try to dig in to how people think about labeling, and really making sense of any mess, to quote Abby the IA. You know, it doesn’t matter whether you’re in a meeting or not; IA is really integral to being able to connect those dots, but also simplify language.
Yeah, absolutely. And I feel like a lot of times the IA is also the person who will be saying, “Okay, I’ve got the 30,000 foot view of the ecosystem. Let’s talk about how how all of it ties together, and how folks might understand the whole picture of what they’re working with.”
UX folks are also going to be asking those questions. There’s a really strong kinship between IA and UX, and also with accessibility. There’s been a huge emphasis on accessibility with my team, which has been great because we’ve been forefronting the needs of folks with disabilities. Not just talking about folks who use screen readers, but folks with mobility issues, with cognitive impairments. Folks who are experiencing the digital product in ways that maybe people who are abled, are not.
So that’s one that’s been one of the really cool things, just seeing how everything sort of threads together.
Absolutely. A few people in this course have pointed out different ways – they watched a video from the 90s from Dan Brown from IDEO, and there were a few things in there that weren’t really thinking about how people with disabilities might use certain things.
Yeah, and there are good articles on A List Apart as well about accessibility in general, but especially designing for cognitive differences.
One thing I’ve been thinking about a lot, especially since COVID, is that folks are dealing with either situational or long term cognitive impacts of COVID. More and more we’re seeing folks who need more considerate design, who need captions along with their videos – not necessarily because they can’t hear the audio, but because they need to be able to read and hear to understand.
So it’s, it’s just been really eye opening, especially in the past few years, how much that accessibility emphasis is coming to the fore. We’re talking about it and we’re making moves in that direction.
But the more time you spend on a product, the more you see that needs to be improved.
It’s UX vs UI. It can be beautiful, but it can be completely unusable.
Exactly. Switching gears just a little bit, how have you designed for search? Especially given your library background, I would imagine that would be a huge part of that, but maybe in your current role as well.
We think about search a lot.
The big search on the brain, of course, is our favorite consumer search engines: Google, Bing, Duck Duck Go, the big ones. We assume that most of our traffic is coming in from search rather than someone saying, “Let me just type in the web address and click through and find the page.” None of us behave like that anymore. Search is often the default.
So, that encourages us to create digital products that are going to be optimized for search.
The good news is that if you structure your content and your site well for humans, it’ll also be structured well for robots! When you create pages that are accessible and that follow standards, best practices for web creation, that boosts your search engine optimization.
Some of this may be kind of basic information, but things like,
There are other things that can be done in your content management system too, like smart title tags, adding things to the meta description for the page. If you’re using WordPress or something, use an SEO plugin and make sure that you’re structuring things well. Use some of those common navigational elements like breadcrumbs in your theme that’ll show search engines how a site is structured, alongside your site navigation.
So that’s the things that we keep in mind for big search.
Many folks in the class are professional writers, and the things that you brought up about the structure of the page are so important. In an IA class, everyone’s thinking about navigation, but there’s all these other structural elements that you brought up that are really important.
Yeah! The navigability within the page, being able to place make and understand, “What am I looking at?”
Nobody’s reading every single word on a page. I don’t do it. You don’t do it. Nobody reads every single word on the page. So we gotta design for scannability, and use words that aren’t, you know, $12 words.
There’s some really good guidance from PlainLanguage.gov about how to write for the web and how to clearly structure things for folks. It not only helps search engines, but it helps your users to access the information quickly.
And, it’s an accessibility thing. It helps folks who maybe have brain fog, or folks who just need something simple and not something clever.
Right! Well, we’re almost at time, but I have a couple last questions for you. You mentioned that IA jobs are, not as abundant as other types of roles. What do you see in some of the challenges and the opportunities for the future?
There’s a ton of opportunities. The joining of the IA and the user experience spheres is very strong. We’ve got a lot of the same concerns. “How are people using our stuff? How can we make it better? Is the interface actually doing what we want it to do?”
One thing I’ve observed, and have been thinking about a lot, is how the web is transforming from this page-based model that we had. Especially in the late nineties, it was like, “Oh, it’s a website. It’s like a book. We have web pages. Sign my guest book.” We used that book mental model to think about the web.
Now, that’s kind of blown up; it’s no longer a thing. We’re having interactions that are nonlinear. We’re having chatbot interactions. Which, chatbots are a whole information architecture tangle. We’ve got people using mobile apps and mobile websites. We’ve got people interacting with different devices in different ways, across entire ecosystems with organizations.
And then we’ve also got third party websites that have information about us. So, you know, Google has information about us. But also we might have a page on Facebook or some other site where we have claimed a page.
So being able to tie that all together in a meaningful way, and to have consistent correct information, is the challenge.
One other thing that I’ll say: I’ve learned recently about Object Oriented UX, which is similar to information architecture in that it steps back from the interface part of the UX and is asking, “What are people’s mental models? What kind of objects to people envision in their brains in this space?”
That object oriented UX approach allows you to then operationalize within an interface, but it’s much more abstracted, and that’s where I really think IA is headed.
This has been amazing. I think everyone is gonna learn so much from you in this session. Is there anything else you wanted to add before we sign off?
I’m glad you said that. I would say, consider government service. There’s a ton of good work to be done, there’s a lot more attention to it recently, and there’s some legislation coming through about technology modernization that will increase the amount of funding. So there are ways to get in, especially if you’re in UX writing and content strategy.
With government work, you’re not necessarily worried about selling something. You’re worried about, are people getting what they need?
It’s mission-driven work and can be really satisfying. So, a little plug for public service.
Gov tech is taking off. I’ve noticed it too, and many of the things that we’ve looked at in class, examples for personas, we’ve pulled from Gov.UK. We’ve also pulled some examples from the USDA, which has an amazing customer experience site. So I think that definitely is helping to amp up government sector.
Yes! Gov.UK is excellent. They’re really leading the charge on a lot of civic tech and design things. Good work being done.
Thank you so much. We really appreciate it and I think this is going to be just amazing for the students.
Thanks so much for asking me.
]]>Three months ago I started working at TMI Consulting, after over a decade of working at a large state university. In my previous job I onboarded new employees often, but I had not started a new job myself since 2009. I was nervous about the transition, and worried about whether I would be able to succeed. But through my first few months of employment, the TMI team has given me space to find my way, made it clear that I am welcome, and showed me that my contributions are valued.
Here are some ways TMI has made my first few months so meaningful.
Keep in touch. I was hired in May but didn’t start work until August. Through that time, TMI staff reached out periodically to check in on me, make sure I had the information I needed, and remind me that they were excited for me to join. This allowed me to focus on closing out work at my previous employer while feeling confident and excited about starting at TMI.
Walk, don’t run. During my first few weeks at work, my new colleagues made sure to remind me that they didn’t expect me to know everything right away, and told me their own stories of starting work at TMI. The expectation was not that I would hit the ground running, but that I would take time to be curious and explore at the start of my journey.
Welcome the beginner’s mind. Moving from the public sector to the private sector reset many of my mental models about work. I explored the company with a beginner’s mind and colleagues supported me wholeheartedly. Rudimentary questions I posed in meetings or on Slack were answered sincerely and quickly. In meetings, folks asked what I thought as someone with fresh eyes on the business. Rather than seeing me just as someone who needed to be brought up to speed, my colleagues saw my newness as a value-add and encouraged my contributions right away.
Give space, give grace. TMI values space. Space to breathe, think, thoughtfully reflect and respond, and let ideas grow. By resisting the rush to a conclusion, avoiding either/or solutions, and not believing that there is only one perfect solution to everything, we actively resist the characteristics of white supremacy culture and give time for the best work to emerge.
Focus on people. As a core value, TMI employees honor each other’s humanity and dignity and enact that in all the ways we interact with each other, in every space. The baseline view is, “You are good enough. Your contributions make us stronger.” This means checking in, paying attention to how others are doing, listening, and valuing everyone’s perspectives and ideas.
Scaffold social time. Like most companies, TMI went fully remote in 2020 and didn’t look back. In addition to an annual in-person retreat, we have twice-weekly virtual check-ins that are optional, and the only rule is we can’t talk about work. I have loved being able to get to know my coworkers better in these spaces.
Make boundaries and rest everybody’s job. In my previous job, work-life balance was individuals’ responsibility and not an organizational mandate. I had dialed in a good work/life balance after years of finding out the hard way what my boundaries were. At TMI, there is clear organization-wide reinforcement of boundaries. There is no expectation of after-hours availability, we have dedicated days for rest, and we check in with each other to avoid overscheduling or overextending ourselves or others. This new-to-me consistent, predictable rest time has given me valuable space to learn, reflect, and find my way. I also love seeing how much this benefits my colleagues.
Hold space for unlearning too. When there is a culture that honors the wholeness of employees and communicates consistently “you are good enough”, it might take a while for new employees to adjust. I have been unlearning some of the patterns and behaviors that served me and my team in my previous job, but that are no longer necessary at TMI. This isn’t an indictment of my former workplace – this is, in fact, how most workplaces are! So, when an organization talks the talk and walks the walk, expect new employees to need a minute to breathe and to heal.
]]>