Building Communities, Not Companies (Part 1)
Lessons From Trying to Organize for Creativity
Part 2 here.
I t sometimes feels to me like most of my life has been spent trying to figure out how to support teams. As a young soccer player I was never the most individually skilled, but I played well in the center because I remembered to keep my head on a swivel and communicate observations to my team. I understood the game in moving triangles, and my job was to make sure that everyone stretched and rotated in harmony with one another. It was my more skilled teammates’ job to put the ball in the net. The triangle observation I made at a young age would eventually resurface as I began designing teams for innovation.
Later, as a college firefighter, I would have to learn how important understanding roles and dependencies was to effective incident command, and then again as an AMGA climbing guide I would see that institutional standards are good for instruction and decision making but almost never reflect real world scenarios. Managing the shit hitting the fan means understanding both fecal matter and aerodynamics in an emergent way and being humble enough to replace assumptions with observations and insights gathered on the fly. I’m not sure that I had an explicit understanding of the OODA loop back then, but it is an effective descriptor for how we were taught to work and think in both of those realms.
A few weeks ago I launched into a tweet storm sharing observations I’ve made while designing teams and organizations (I said over the past two years but realistically it is more like the last 15) with the capacity to improve and self-organize. A couple of people jumped in and asked me to expand upon what I was saying, so this long post is an attempt to dive deeper into each of the 9 points I made. This post operates on the assumption that the reader has a sense of the conversation about self-organization, but if not, here are a few good primers.
This is one thing that has really been on my mind a lot lately. Personally, I’m very interested in the ways that people work together. I find the topic compelling, and incredibly important because it is the undercurrent of nearly every job in our economy (I struggle to think of any examples of work that actually happens in a vacuum, but am listening to comments). I want to figure out the best ways for freelancers to work with companies. I want to figure out the best ways for agencies to work with clients. I want to figure out the best ways for developers to work with designers. I want to continue to understand the relationship between individuals and the organization-at-large. I’m curious about the the necessity of project management and the myth of the idea factory. I want to create working theory for the difference between innovation and technology appropriation, and why each can be valuable to the future of an organization. I want to talk about pairs and triads and meeting structures and the boon and bust of the calendar. I want to figure out how to not need email.
But many people don’t.
They just want to come to work, be respected, know what is expected of them, what they can expect of others, and produce things that they’re generally proud of.
These people can be horribly affected by poor organizational design. Sometimes they even know and acknowledge it, but when we present the need to design newer, better teams under the auspices of some values organizational designers hold dear, it seems like we see minimal adoption. When I’ve worked with teams and presented them new work artifacts and methoda that I find exciting, the moment I’m no longer part of the daily we see a huge drop off. Many times we see no uptake in the first place. Teams comprised of people that don’t share in this point of view deserve the benefits offered by better systems without having to dig deep on why Slack is a big deal or the newest version of Agile.
If we don’t communicate the value of new approaches to the organization’s individual constituents, then the cognitive load of rewiring habits and patterns seems to serve as a functional barrier, and we watch teams slip right back into old ways of working. Even as they recognize the old models as flawed, they’ll note that they are predictable and comfortable — two of the major types of corporate exposure we are hired to address (“the world is increasingly unpredictable and our work style should be able to handle this” & “comfortable positions in the marketplace are often the most exposed to disruption”). We need to not only offer models for evolving, we need to unearth the motivation for individuals to do so.
So our job, as org designers, becomes to understand the value of better designs in the light of our customer — the worker. This is painfully obvious and reflects lesson one of modern design thinking, but it was harder to figure out than I would have imagined. Now, when we’re working with new teams and we want to promote self-organizing principles, we begin by 1) spending time getting to know that team and then 2) sharing with them how it can help make things better for each individual present. We used to appeal to ideas that play on our own emotions (innovation! speed to market! novelty! openness!), but we’re learning to respect the different values that different people bring to the table.
This also has the effect of empowering much more customization within our org designs. An engineer’s primary concern with experimentation-oriented team structures might be the risk of significant technical debt, so it could be important to have regular architectural reviews at multiple points in a release cycle. Or we can help teams blend roll-outs with feedback loops so that we take advantage of beta but actually produce incremental revenue or case modeling. The most ideal situation is when these solutions emerge from the teams themselves and are shared up the stack, rather than mandated down by consultants or bosses, so we’ve started to realize that there is a fallacy in trying to lean on a specific system for team design.
One of the key ideas of self-organization is this notion that teams can choose their own ways of working, as long as there is a clear scope. Many systems exist to try to promote this, but there is a hidden danger to an approach that leans heavily on vague, coded language. Agile is a philosophy of software development underpinned by a long and diverse technical conversation, but often we work with self-described “Agile” teams that don’t even understand the reasoning behind why they support a certain lifecycle or how they should manage and respond to short-cycle feedback.
One of the ways that we have tried to combat this is to identify principles that unite teams or individuals without prescribing the specific means by which they can capture those principles. Theoretically this works, and it does seem to drive a little bit more consideration into why are we doing this this way? but it can also leave teams feeling isolated and as if they aren’t sure how they are being measured.
If you got value from this, you might enjoy Part 2.
👋🏼 Hi! I’m spencer pitman. If you’re looking for my food stuff it’s here. Otherwise, I’m an organizational designer interested in building better teams and companies (with a bit of cycling, skiing, cooking, photography and design thrown in). I work here. I tweet here. I write here. Feel free to reach out, I love to have conversations.
