Fairy tales first emerged as oral and written short stories. Later, they became plays, musicals, movies, art, pervasive elements of our culture. For children and adults alike, fairy tales serve critical social functions, teaching morality, values, history, traditions. And they also have an ugly side, long criticized for the ways they perpetuate inequalities and stereotypes, compel children to reproduce dominant culture, and normalize sexism, racism and classism.
This cultural study of fairy tales has produced a vast body of analysis and critique. Through tools like the the Aarne-Thompson classification system, Vladimir Propp’s morphology, and feminist, psychoanalytical and Marxist frameworks, we can reveal their hidden world.
Much as with fairy tales, we tend to only see the surface area of things unless we have the tools to deconstruct them. Take engineering organizations, and the work that they do. The work of deciding what to build, how to build it, and what to use — the work of making technical decisions and managing their consequences. We like to believe our behavior as individuals and as a team are driven by technical reasoning, by logical reasoning. But just the way that fairy tales are more than bedtime stories, technical decisions themselves are cultural artifacts — informed by signals, messages, interactions and beliefs within the culture.
In this post, we’ll look at five tools you can use to interrogate and critique your technical culture. By exploring your team along these axes, you can get past the surface space of function and dysfunction to a deeper, more generative understanding of how you work.
A fairy tale is in part constructed by the things characters are rewarded for, and what they are rewarded with. For example, rewards of money, land, ascension to the throne, or a beautiful husband/wife can communicate the importance of wealth, aristocracy and heteronormative gender roles.
In engineering culture, rewards can be material things like raises and titles, or they can be things like recognition, popularity, social capital, a place on good projects. What we are rewarded for can have a big impact on how we make technical decisions:
- In today’s community and workplaces, we can attain social capital and other rewards for coming up with new products, ideas and prototypes, for being the inventor, for starting something novel. This reward system ties into our individualist mythology and geek revenge fantasies, our delusional belief in meritocracy, our obsession with celebrity founders. But in a technical culture where genesis and individual creation is what we most reward, can we end up with teams that can’t work together, that can’t focus, that can’t successfully commit to products and markets, that invest a ton of time into projects that never get past the early stages, that build technology that is “hip” but doesn’t accrue to higher-level goals?
- “Shipping”: one of the most successful memes of our technical generation. If this is the foremost thing our team is rewarded for, is anyone taking care of long-term manageability? Are we developing healthy ops teams? How much technology selection is driven by the speed to ship, not inclusive of concerns like scale and maintainability? Are we shipping products that aren’t coherent, but rather jumbles of smashed-together features?
- What about when we reward acts of heroism — recovering from severe outages, working unreasonable hours, emerging triumphant from a death march? When such acts of heroism are very visible and rewarded, do we end up with a situation where people are incentivized to manifest the very conditions of catastrophe that allow them to be heroes? At what point are we actually incentivized to create unrealistic deadlines, work at an unsustainable cadence, even cause production issues?
What is the value system of the fairy tale? Perhaps modesty, chastity, virginity, physical beauty, or hard work despite poverty are core values that help form its subtext. In engineering culture, we have technical values, each playing a core role in how we make decisions. Almost always, these values involve tradeoffs, or choosing the most important out of several important things. What are our technical values, what do they mean, and how can we discover them?
- Oftentimes, it’s hard to determine our technical values by what we say. After all, our true culture is made primarily of the things no one will say. Luckily, the software evaluation process can be a great way to get insight into our technical values. What aspects do we pay the most attention to? Spend the most time on? Report to the broader group? Perhaps we focus on easy-to-use APIs, robust querying, and beautiful clients. If those are our foremost values, are we paying attention to how queries may be tied to properties of the underlying software, and how that may affect performance and viability over time? Has the software been tested at scale, it’s operational characteristics considered? Have we ended up picking a software solely on the basis of its interfaces?
- Openness, portability, interoperability, and standards: a set of technical values virtuous on the surface, but uniquely deadly to product development in early markets. If these are your foremost technical values, do you end up working on things the market is too early for? Are you wasting critical time on standards boards for things no one is using yet, or prematurely optimizing for portability of something there are no significant implementations of yet?
- Technical values come from places — they do not emerge, fully formed, from the combined heads of our team. What is your team reading, sharing, and discussing from the broader tech community?Are you passing around blog posts about trivial implementations someone got off Hacker News? Does everyone idolize the latest idiot-savant off Twitter dot com, but refuse to engage with true experts in the field? Or are you reading academic papers, case studies from large-scale systems or stable, production implementations?
Who has power, and how power is constructed and enforced, tells us a lot about the hidden worlds in fairy tales. Similarly, an examination of power in engineering teams can tell us a lot:
- In the most classical examples, you find situations where technical decisions are excessively influenced or even made outright by people who won’t actually be implementing, building and running the software, and probably have no place to. Of the many problematic effects, perhaps most toxic is that the power in this situation isn’t appropriately tied to responsibility. The incentive structure needed for success is thus utterly missing.
- There are kinds of power besides dictation and delegation, however. Each engineering organization has those unicorns — people who are uniquely charismatic or convincing, carrying a great deal of social weight. Even beyond those individuals, every team has its own social dynamics. Influence is never evenly distributed. This is natural and even healthy, but you must be aware of how allegiances, loyalty, senses of belonging, in/out groups and other social dynamics are affecting team decisions.
- How is power enforced and maintained on your team? Is dissent punished, is public shaming business as usual, is microaggression omnipresent, creating a culture of fear and blame? Can this result in risk avoidance, failure to report and escalate problems, or endemic dishonesty on the team?
- One way that power can be exerted over engineering teams, particularly by other groups in the organization, is by creating enormous pressure around deadlines, dates, timetables and roadmaps. Often this is symptomatic of insecure executives, ongoing turf wars, or management that doesn’t understand technical tradeoffs. But ultimately, it can result in burn-out, poor decision-making and low-quality software that is focused more on dates than utility.
We can tell a lot about a fairy tale by looking at things that characters in it have in common. In the workplace, the commonalities between workers — their attributes, skills, shared backgrounds — not only affect our day-to-day experiences, but also informs our technical choices.
- We would be remiss not to discuss the overwhelming homogeneity of most technical teams — predominantly white, male, straight men. Without any diversity or the empathy for other kinds of people that comes with, can you team innovate, diversify, reach new markets or break out of an early adopter segment? Indeed, can they even build products for any type of audience besides themselves?
- Another aspect of homogeneity is that of shared competencies and how skills are distributed across your team. When the foremost competencies of your team are examined, how do they split out across different skillsets — such as front-end development, distributed systems, operations, performance engineering? How might that bias your team towards certain types of technical decisions? What’s missing in the composition of your team as you grow?
- To go a layer deeper, what are the team’s common architectural beliefs, approaches to building services, methodologies for operating teams, and strategies for evaluating software? How is this affecting what you produce? Are there any dissenters that can offer different perspectives, preventing destructive group-think? And since people tend do what they already know how to do, what perspectives or opportunities may we be missing?
Historical context tells us a lot about the meaning of a fairy tale. For example, the Pied Piper tells the frightening story of a large group of children, disappeared from a village forever by a mysterious and vindictive piper. Historical context leads us to believe the story may be a metaphor for a plague, a mass emigration, or even a Children’s Crusade.
In engineering organizations, the history of a team — it’s patterns and context — is equally important to deconstructing meaning:
- Every team has traumatic events that shape how it functions. What are the traumatic events in your team — firings, layoffs, bad hires? Massive outages and failed projects? How are those elements affecting your team now? Are they making people scared to try new things or move forward? Are they causing interpersonal issues that are breaking down communication today? What were the lessons people took away from these incidents, and were they the right ones?
- Similarly, what are the past technical successes on your team and how have they trained you to think? We tend to repeat those things that were successful in the past. But will those patterns serve us well as we grow our team, try to build new products, or make significant changes in the way we operate? Could our successes themselves holding us back from pursuing new technical approaches and opportunities?
Well, we’ve made it through all five axes, seen not only how they help us understand fairy tales, but how they help us understand ourselves, our teams, and the way we make decisions.
Exploring the role of reward, values, power, homogeneity and history in our teams can be difficult and uncomfortable. It is profoundly challenging to approach questions of culture and dysfunction with honesty. Generally, this is not how we are taught to work. In fact, we are often incentivized to submerge conflict, uncritically accept existing power dynamics, and avoid difficult subjects to reduce friction and drama in the team. Yet doing the very opposite of these things can lead us to be more productive, happier, and better functioning. So how do we get there? How should we approach the difficult work of intervening in culture?
Approaching these topics with a shared sense of duality can be transformative in how we work together on fixing our teams. While we must get joy, happiness, fulfillment and positivity from our work, we must also be able to critique, to move towards greater honesty. Acknowledging and allowing space for both, and allowing each to coexist in our practice, is fundamental. Ultimately, there is no escaping brokenness within teams, or its effects — both direct and indirect — on the software we build and use. Our work is complex, and multi-faceted, and impacted by rewards, values, power, homogeneity, history and many other factors in good and bad ways. But we can become less broken, or evolve towards different kinds of brokenness, by examining our teams and our decision-making critically, and using tools to see beneath the surface to what is really going on.
This post is based on a talk I gave at the Distill conference on August 9. You can see the full slides here.