Thoughtful and actionable paper from Johan Allspaw about engineering resilience—with principles and tactics applicable to other kinds of work, I think. Importantly, resilience as defined here depends on a number of different behaviors, including open and honest communication, reciprocity, and a lack of judgment. What I find notable about this framing is the sense that resilience is a collective, rather than individual, attribute. That is, it depends on sharing information, inquiring into team member’s experiences, and drawing from the knowledge and capacity across a team or teams. That’s a lesson for how we think about resilience generally: not as something each of us has independently, but something that we build and maintain together.
Recent entries from the blog.
-
“Why did Caroline Ellison do it?” asks Liz Lopatto in The Verge. What I find interesting about her answer is the connection to Ellison’s desire to please the people around her. I often talk to people (mostly but not always women or femme folks) who recognize those people-pleasing behaviors in themselves—and who wrestle with when and how to interrupt them, whether or not its worth it. There’s a kind of double vision to this awareness: knowing that you’ve been trained or conditioned to these behaviors and that they reduce your own agency; knowing, also, that relinquishing them can expose you to harm. It can feel like a game in which the house always wins. Ellison’s situation is extreme enough that I’m not wont to generalize, but I do agree with Lopatto’s conclusion: “If this is where being a good girl gets you, I recommend being bad.”
-
Miriam Eric Suzanne explores what it means for design to be collaborative without being authoritarian, and lands upon models more commonly talked about in infoshops than product orgs. She writes, “good collaboration [is] more involved and messy than voting, or tallying a majority opinion. It requires deep engagement, and shared ownership of a vision. Let’s call it anarchist, maybe, with an emphasis on mutual aid?” I think that’s exactly right and also instructive on several levels: when we say that a team isn’t a democracy, we’re often thinking of the most anemic version of democracy: an annual ballot, with no other organizing or collective action in the months between. But real, active democracy—the kind that is largely absent from public life in the US and elsewhere—involves more inquiry, negotiation, compromise, and consensus-making. And it’s those skills that have atrophied on many of our teams, and in most of our streets. Happily, today is always a good time to practice something new.
-
Many of my clients make big decisions while we’re working together—to change jobs or fields, to move to another city or country, to pursue an exciting but daunting new project. Part of the momentum that drives people to seek out coaching in the first place is the sense that a big decision is looming just up ahead, and you want some company as you approach it, someone who can help you map the terrain and confirm that your rope is secured to the rock. But then there comes a moment when the decision has happened, when it’s in the past, and a changed future gapes before you. Sometimes, people are wont to look back over their shoulders, to verify that the decision really did happen, to wonder if it’s not too late to go back. And my advice in those moments is the same every time: wait. Give the decision a few days or weeks to settle in, to distribute itself evenly across your body. Big decisions can take time to reach every part of you, as if they started in your head or your heart but need time to spread themselves all the way down to your toes. I think of a freight train, where the first car has already switched tracks even while the last car is miles behind. It will catch up, eventually; you just have to give it time.
-
Seeds for Change has a great and brief guide to consensus decision making, useful for anyone who wants to quickly get a group up to speed on best practices. I’ve written before about how consensus is an underused and under-acknowledged method in most organizations, in part because of the myth that it takes too long. But often, top-down decisions only seem faster: because they skip over people’s concerns, they can lead to lots of thrashing and resistance when implementing a decision, ultimately costing more time. One way to look at consensus processes is that they foreground alignment rather than saving it for later. And being explicit about a consensus process also builds clarity when it comes time to communicate about how and why a decision was made—which is a win all around.
-
One of my hypotheses about this moment in the tech industry is that, as more and more people burnout on layoffs and AI-sparkle-driven product plans, a great number of talented people will be ready to start their own ventures—and will be looking for alternatives to the VC model. Enter worker coops: worker-owned organizations with an emphasis on solidarity, equity, and democracy. John Luther has written a three-part series about how he and his teammates founded Limeleaf, a software development company and worker-owned collective, including a callout to the very first step of building alignment about what you want the coop to achieve. And if you need a hand thinking through what it is that you want? Let’s talk.
-
“To get there, I had to first understand I’m not cut for the web industry anymore.” Great and resonant post from a web designer whose frustration with the direction of the industry led them to find good work elsewhere. I think this is a common, if often unremarked upon, pattern. A lot of folks have been working on the web for twenty or more years now—two plus decades during which nearly everything has changed. One thing is abundantly clear to me: the skills that made people good at building websites are readily transferable and even sought out skills in other fields. Not just the code or the pixels, but the ability to organize, to project manage, to break a big goal down into discrete steps, to collaborate with people with very different expertise, to deeply understand how people experience technology in their lives, to learn and to be constructively critical when the work could be better. It’s possible that some number and some kind of tech jobs aren’t coming back; but there remains ever so much work to do in ever so many other directions. The path from one industry to another is never easy—but it can be traveled—and I have so much faith in the people who are ready to venture forward.
-
Charity Majors argues cogently that generative AI, whatever its abilities, will never build your engineering team. In fact, she notes a kind of time bomb inherent in the oft-repeated assertion that you can replace a bunch of junior engineers with AI: what happens, years from now, after you’ve destroyed any path for people to become senior engineers? There’s a kind of magical thinking to much AI hype, as if the senior staff who can competently judge the output of that AI will appear fully formed, drawn forth from the CTO’s head. In reality, senior engineers need training and opportunities to learn on the job, as they always have. Go ahead and use AI to automate drudgery, if you can; but presume it will let you slide off the bottom half of your payroll at your peril.
-
“Leaving a situation that doesn’t serve you is a strength, not a weakness, and don’t let anyone tell you otherwise,” writes Karolina Szczur, in a post about founder burnout. As she notes, this is one of the more taboo topics in the conversation about burnout—for many reasons, among them a persistent and dangerous mythology that likens founders to small gods. But Szczur also notes that burnout can happen even in an environment that’s been carefully and thoughtfully built with an eye towards sustainability. This gets at something I’ve written about before—that to get to the bottom of our own burnout we have to identify and name its roots with more precision than the word “burnout” can provide. It may be overwork, or, as in Szczur’s case, it may be something else. But naming it is the first step to doing something about it.
-
S.E. Smith writes in YES! about the intersections of remote work and disability rights. In particular, they note that the conversation around remote work has neglected to consider the ways in which it’s an often critical accommodation—while still remaining largely inaccessible to the majority of disabled workers. Ultimately the question about remote work isn’t one of whether or not working from home (or elsewhere) is better or more productive than working from an office; it’s about whether or not our workplaces are aligned with human flourishing—for all kinds of humans, in all kinds of bodies.
-
I work with a lot of self-identified overachievers, many of whom are working hard at reform. After decades of doing too much you eventually realize at least one of two things: that you are a body with limits that will assert themselves one day, and that often the most joy we can find in our work comes from those collaborations in which we leave enough space for others to step in. But it can be hard to break those old patterns, even when you recognize that they are no longer serving you. So here’s a small piece of advice, from one reformed overachiever to another (future) one: half-ass it. Pick a task, something small to start, and do it carelessly. Do half (or less) of what you would ordinarily do. Then see what happens. Consider it an experiment in which your intention is to learn, whatever the outcome. I’m betting your half-assed version is better than most people’s whole ass, but you can test that assertion yourself.
-
From the Developer Success Lab comes an excellent resource: the Code Review Anxiety Workbook. While geared towards engineers, I think the counsel here is relevant to the anxiety of sharing work and getting feedback across many other fields, and likely to be useful to those both inside and outside the tech industry. Among the many good features here is a mini toolkit with brief tips for addressing and working through workplace anxiety. All the counsel here is great but I’ll call out the list of thinking traps in particular, and the way taking note of them can help you recognize that you’re only considering one angle on what’s happening. Questions like—why is this perspective the one I’ve adopted? How is it useful, and how might it be holding me back? What other perspectives might be possible here?—are great tools for dislodging narrow or stuck ways of seeing, and giving yourself some space to see what other futures are possible.
-
Here’s a small trick that worked for me over the dozen years I led remote teams: at the end of your working day, shut down every app on your machine. Yes, all of them. Stash your tabs somewhere if you must, but close them all down. The only exception that may be made is for a simple note-taking app—the kind that lacks any kind of notifications. Then, spend ten or perhaps fifteen minutes reflecting on your day, whether in said note-taking app or, even better, on paper. This needn’t be anything formal or structured, just jot a few things down—maybe short phrases, maybe just some key words. The only hard rule is to do your best to keep any sense of judgement out. Then, in the morning, when you open up your machine, there should be nothing yelling at you—no unread badges, no cluster of notifications calling for your attention. At that point, you can reverse the practice, and spend a few minutes thinking ahead to the day that you want to have, and anything you think is important to keep your attention on, even as everything and everyone else tries to drag that attention in a million other directions.
I’ve found this practice is useful on two fronts: one, it serves as a kind of bookend, starting and ending the day, so that you don’t end up working all the time, with no sense of beginning or completion. I think this is important for any work, but especially for remote work, where the environmental differences between working and not-working are wont to blur. Turning off all those apps, and spending a few minutes with pen and paper, creates an adjustment to the environment that helps bring the work day to a close in the evening, and permit it to open with a sense of calm and intention in the morning. At the same time, taking even a few minutes to reflect or contemplate helps with the inevitable overwhelm that most remote working environments generate. It gives you a place to ground yourself and return back to each day, no matter what happens in between.
You don’t have to take my word for it though. Accept it as a hypothesis, and give it a shot. Then see what happens. Whatever the results, I bet you learn something new.
-
Here’s a small rhetorical shift you can try: whenever you’re prompted to say “imposter syndrome,” substitute the phrase imposter phenomenon instead. The latter was the term used in the original paper introducing the concept, while the former has emerged in the decades since. But where phenomena are rooted in the observable world, “syndrome” both medicalizes and pathologizes the people with the experience. That is, by talking of an imposter phenomenon, we turn our gaze to the material circumstances that give rise to a false sense of inadequacy; while when we talk of a syndrome, we locate the problem within the confines of an individual’s body—and limit our ability to respond and attend to that problem to what is within that individual’s control. The more I hear the phrase “imposter syndrome,” the more I worry we are recreating the very thing we are trying to eliminate, through the simple fact that our language excludes the worldly conditions from which it grows. But small changes in language can lead to big changes in the way we think and act; try it and see what happens. (Or, better yet: try talking about how an environment or situation leaves you feeling impostered.)
-
In a preprint, Catherine Hicks, Carol Lee, and Morgan Ramsey outline research that identifies four factors for developer thriving: agency, motivation and self-efficacy, a learning culture, and support and belonging. I take two things away from this proposal: one, I think it’s very relevant that it rests on being able to be seen as being wrong (whether because you made a mistake, or because you disagree with someone). That is, an environment in which everyone can safely be wrong is one in which good work can happen. Second, while this research focuses on developer thriving, I see nothing here that wouldn’t also apply to other functions—especially the many peers (designers, researchers, product managers, and so on) who work alongside developers. Best of all, all of the factors can be managed to, so team leaders who care about thriving should take note.