toward a trauma-informed database culture

This post is dedicated to my sister, Abbie Shain, and my friend, Rabbi Ariana Katz (thanks for starting that FB thread on Maslow!) – both of whom have been generously supportive of this project and all-around rockstars in general!

This weekend, I had the opportunity to host my twin sister for a weekend of revelry and earnestness in Philadelphia (It’s us, what can I say??). And treats. Definitely, treats. My sister is a therapist and social worker in the midwest, where she has specialized in feminist, anti-oppressive, and trauma-informed methodologies. I’ve been thinking about these themes for a long time, but talking more directly about post-traumatic stress disorder and treatment methods inspired me to dig into it in a more concerted way.

Let me begin by offering a few grounding assumptions.

1. I’m not a therapist or an expert (by any stretch) in trauma healing, but I can write about what I’ve experienced firsthand and what I’ve learned from peers and scholars.
2. To do this work well, it will be important to resist comparing or ranking trauma (from micro-aggressions to impostor syndrome to harassment to violence to structural oppression, it all counts, it’s all real, it’s all harmful, and it all shows up in our culture, workplaces, grassroots orgs, bodies, and yes, data!)
3. We are our full selves in our data work – identities, memories, desires and all – gendered, racialized, dis/abled etc. We all know how that relates to whether people believe us, trust us, harm us, pay us fairly, expose us to toxins, etc. This is why we need an intersectional approach to database management… but perhaps that’s the topic for a future blog post 😉
4. Sometimes on this blog, I write for an audience of spreadsheet learners – and this post is for you – but even more, I’m speaking to people who identify as data “professionals.” I’m going to write about how we may do harm in our work – remember, impact is different from intent! We need to get sharper about how the people we support may be living with mental illness or trauma, may have low self-confidence or a low threshold for frustration, may experience Impostor Syndrome, may have had bad experiences learning tech in the past. While none of these experiences define the staff members we support entirely, they should absolutely inform how we go about our work building effective systems and supporting staff day-in and day-out. If we incorporate this truth into our practice as database admins/managers/engineers/developers/architects, I feel we can live up to our fullest potential as change agents – both from an internal change management perspective AND a broader social justice perspective. This is going to take a lot of practice and I believe that we are up to the challenge!

In my research for this post, I learned that there are a variety of models for understanding trauma and well-being, and I’m sure there are even more that I did not encounter. One of the most common is Maslow’s Hierarchy of Needs (comprehensive article here). I think this is a good starting point, but at the same time, I agree with a lot of the criticism of the model. I especially want to highlight this critique from the Blackfoot Nation. Moreover, I think it is healthy to be skeptical of theories that are so thoroughly embraced by “pop” management philosophers. Maslow’s Hierarchy is often contrasted with Chilean economist and environmentalist Manfred Arthur Max-Neef’s “fundamental human needs.” As an Olympic spreadsheet nerdette, I felt particularly drawn to Max-Neef’s “matrix” of needs, which overlays 7 fundamental needs with 4 existential categories. Uh-oh, I think this might be getting a bit too philosophical! So if you want to dig in more, jump over here). By the way, I’m certainly not the first person to apply these principles to software and design – I think this article does a good job explaining the area of overlap. Literature review – CHECK!

Ok, so we’ve covered some of the basic principles underlying human needs. By extension, violation, repression, or neglect of those needs can be considered trauma. Trauma is bad! And it can last a long time! Then again, people and brains are resilient, and there is a LOT of research available now about understanding trauma and learning how to cope with it. Some of that research fits under the umbrella of “trauma-informed care” – a relatively recent set of practices “that promote safety, empowerment, and healing” – particularly in a medical context (see link, note: content warning for describing medical trauma and sexual violence). When I say “relatively recent,” I mean that trauma-informed care standards were largely developed and popularized in the 90’s, with great influence from treating Vietnam veterans with PTSD diagnoses as well as insights from feminist and Womanist movements. Learn more about the history here. Using a “trauma-informed lens” is becoming more common (which I see as a move in the right direction!) but I still think in many circles, the conversation is just getting started.

Next, we’ll explore 5 Trauma-Informed Care Principles (quotes below are borrowed from the Wisconsin Department of Health Services) and apply them to work-themes that come up as a data practitioner. The 5 principles are Safety, Transparency and Trustworthiness, Choice, Collaboration and Mutuality, and Empowerment.

Safety

“This includes creating spaces where people feel culturally, emotionally, and physically safe as well as an awareness of an individual’s discomfort or unease.”

• Be aware when you are asking people to stretch beyond their comfort zone. Celebrate their growth and thank them for their trust.
• Expect that people are dealing with “more than what meets the eye” (especially if they have been structurally discouraged from learning STEM and/or if they are dealing with hard stuff in their personal life that you may not know). Channel patience and compassion in your database-related interactions, knowing that they can bring up insecurities for people because of their past experiences or current circumstances.
• Offer “office hours” and cultivate a reputation of being accessible and approachable. If you manage staff, emphasize that those qualities are important!
• Create training environments with a positive tone in the most pleasant room available
• Ensure that no one is punished for making mistakes; don’t ridicule anyone for “not knowing stuff”
• Use example scenarios with multiple cultural or ethnic reference points
• Craft clear and precise instructions
• Encourage questions and provide multiple avenues for support (some options could be written instructions, video recordings, live demos, support tickets)
• Be rigorous and comply with best practices for data privacy and confidentiality

Transparency and Trustworthiness

“This includes providing full and accurate information about what’s happening and what’s likely to happen next.”

• Share regular updates about your technology roadmap, especially if change is on the horizon
• Maintain a central repository with up-to-date instructions and documentation
• Add time for training/learning to every release cycle
• Share thorough and accessible release notes that make it clear how each change will affect different roles
• Tell the truth when people report bugs or request/complain about features that are not yet available.
• Believe staff when they share their experience using the database – even if there’s a “user error” component, we can still learn from their feedback and it’s our job to take them seriously
• Be honest and realistic about your turn-around time when people request support, reports, meetings, enhancements, etc.
• Follow through on commitments to staff – it’s the right thing to do AND a great way to build trust and credibility
• Explain WHY you use spreadsheets/databases/systems the way you do and WHAT ROLE individuals have in participating/maintaining the system

Choice

“This includes the recognition of the need for an approach that honors the individual’s dignity.“

• Remember, all technology projects are people projects! There is no perfect answer, only a solution that works for these people at this time.
• Ask how people prefer to receive information (automatic alerts? running reports? scheduled reports? dashboards?) and comply with their requests
• Teach staff how to manage their own settings so that they can make choices that are best for them (email settings, views, colors, etc)
• When there are trade-offs, compromises or downstream effects that must be taken into consideration, communicate clearly, purposefully, and in writing
• Be up front about where there is flexibility/optional steps and where you need 100% compliance/completion/accuracy so that staff are aware of expectations and can plan their time accordingly
• Regularly survey your community to get a sense of what is most important to them and demonstrate how you take their feedback into account

Collaboration and Mutuality

“This includes the recognition that healing happens in relationships and partnerships with shared decision-making.“

• Databases need users … as much as staff need a central system to keep track of stuff! Honor that reciprocity!
• Expect that everyone is trying their best
• Create a committee of “super users” who regularly give feedback and see demos
• Ask for opinions on a regular basis, including feature prioritization
• Encourage staff to take on a public speaking role (or lead a demo) in staff trainings to showcase their skills, leadership, and buy-in
• Go to where your users are, rather than expecting/waiting for them to come to you. In the immortal words of Marc Baizman, “Salesforce Admin By Walking Around” (SABWA). I learn from my staff all the time!
• Admit, with humility, that some things don’t work as well as you would like. Ask for patience and offer it generously.

Empowerment

“This includes the recognition of an individual’s strengths. These strengths are built on and validated.“

• Celebrate your staff for getting “it” right – following processes, achieving data integrity, adopting new features, etc. Methods could be a shout-out in release notes, an all-staff email/slack/Chatter post, a quick note, or even a prize!
• Never miss an opportunity to verbally recognize the expertise of your staff – they know their work best, and it’s our job to support them
• Ask staff about their learning goals (spreadsheets/systems/problem solving) and dedicate time to support them, even if it does not directly tie to database adminning
• On-the-job database skills are professional development for staff and transferable to other jobs! Acknowledge that you are working to overcome potentially dis-empowering data or STEM experiences that they may be holding on to
• Seize storytelling opportunities for “personal wins” and collective examples of “things we can do now that we couldn’t do before!”

I used the lens of a database administrator and their staff (or, end-users) in the suggestions above, but I think we could apply a lot of the same lessons from Consultant –> Client or Volunteer–> Volunteer. The practices I have in mind range from mindfulness (cultivating awareness that people are going through hard stuff) to accountability (follow-through and clear expectations) to thoughtfulness (especially in training) to plain-old not being an asshole.

Recommendations

I have a few more recommendations that deal directly with the intersection of trauma and what I see in my community of database practitioners that I want to offer by way of conclusion. Let me be clear – I am just as critical of the “social justice word police” as I’m sure many of you are – but I’m asking you to re-consider a few key terms below, and I think the potential benefits are definitely worth it.

1. Mother, may I? It is SO, so important to consider privacy and consent when collecting data. (See resource here). What’s being collected? How will it be used? Is it stored securely? How long do you retain data? Do all staff/consultants/interns sign a privacy agreement? (If relevant…) Do people filling out the form KNOW that they will be asked questions about sensitive, private, or painful experiences? Practices like adding a “content warning” AND connected opt-out to data-intake forms, a clear purpose statement for why data are collected and how they will be used, and a privacy policy are a great start.
   
2. Trigger happy? In mental health and social justice spaces, a “trigger” is known as an event that reminds someone of a traumatic experience and causes intense emotional distress/flashbacks. Meanwhile, in database-land, it’s common to hear the term to describe automation in general, or a specific type of automation in Salesforce. I recommend introducing some alternative vocab, like “automation” or “launch” or “domino effect” unless you are specifically talking about Salesforce triggers.
   
3. Therapy parity! In nearly every left-wing database conference I attend, someone will introduce themself as a “technology therapist”, and to be honest, it really bothers me! Being a therapist is a specific career path with extensive training, credentials, and values at stake. Being a therapy patient or client is really different (in my experience, anyway!) from being a technology client. I think it is misleading and dangerous to conflate what therapists do with what we do as technologists. Plus, for people who access therapy as a part of their wellness strategies, it can seem flippant and disrespectful. This critique isn’t directed at any specific individuals – but I think it merits some real food for thought! I recommend (1) therapy in general (2) other metaphors/verbs for what we do, like “consulting” (duh!) “guiding” “mapping” or my personal favorite, “solution-ing!”
   
4. Undermine impostor syndrome whenever possible. I feel like this can’t be repeated enough! Everyone I’ve ever trained in databases and spreadsheets has faced some degree of of insecurity/overwhelm/self-doubt – and has decided to keep trying, anyway. ROUND OF APPLAUSE! I think this will continue to hold for the forseeable future. So it becomes our job, as technologists/trainers/map-makers to affirm, affirm, affirm! Take it slow. Acknowledge pain points. Review directions/procedures as many times as it takes. Be the most encouraging presence possible!

I want to end with a note about why I named this post “toward a trauma-informed database CULTURE” – specifically the culture part. I think it is incumbent upon us database managers / data practitioners to critically evaluate our culture. Culture likely assumes all end-users have an uncomplicated relationship with math and technology. Culture that makes fun of end-user mistakes behind closed doors. Culture that can gravitate toward impatience and exasperation. Culture that can deprioritize training and documentation in favor of building shiny things. I contributed to upholding some of those norms on occasion, but what I really want is to undermine them! I think that is possible because culture is also where I see qualities like creativity, altruism, and ambition show up in the Salesforce ecosystem. I want to develop an industry standard of compassionate database management and I think that starts with learning, reflection, behavioral change, and wider, culture shifts. I don’t think that’s all going to happen as a result of one blog post… but I did want to share some of my motivation for spilling all of this ink!

I could go on and on about resilience, trauma, ethics, intersectionality, and empowerment/self-actualization, but I think it’s time to stop here. This is the first time I’m writing about a topic like this; it feels like a risk! Your feedback is ALWAYS welcome. Even better? Reply with a comment about how you incorporate trauma-informed pedagogy into your work and maybe I’ll be able to write a follow-up post!