For any organization to remain relevant in changing times, you have to be able to change. Organizations need to be able to adapt to uncertain futures, new technologies, new tools, and the changing needs of the communities you serve. You need to build a working environment where teams are able to try new ways of working and to develop new projects, and to not be afraid if an experiment doesn’t work out.
Our four-person non-hierarchical leadership team, which is itself an experiment in alternate models of leadership, shares what it means for Fractured Atlas to cultivate a culture of experimentation.
Shawn Anderson, Tim Cynova, Lauren Ruffin, and Pallavi Sharma discuss how leadership can create teams that are empowered to experiment, how to end and evaluate those experiments, plus an inside look at how Fractured Atlas has iterated on everything from finances to the structure of our teams.
What does it mean to have a culture of experimentation? Why is it important to Fractured Atlas?
Pallavi: At the leadership team we often talk about a “growth mindset” being a vital part of an individual or team's ability to evolve, adapt, and succeed in a constantly changing global environment. I believe a culture of experimentation is the extension of that concept to encompass how the entire organization thinks, behaves, and executes on its mission.
In practical terms, it means we find ways to empower the team to recognize challenges or opportunities in how we support the creative sector, encourage the development of creative solutions to those issues, and support testing of solutions in their success and in failure.
Tim: Not all experimentation is created equal. Naming the type of experimentation that a team does can help prevent challenges down the road. For instance, we talk about the difference between proficiency and creativity. Sometimes you’re experimenting to hone a current process (proficiency); sometimes you’re experimenting to find or create the next thing (creativity). It’s not that they’re one or the other, or mutually exclusive, but knowing the environment you’re operating in is useful to the type of work you’re doing. You don’t want to completely overhaul a payroll process if you don’t have to, but might want to make tweaks to how it operates (proficiency). Conversely, if you’re launching a new program you’ll need to live more in the creativity space and throw a lot more spaghetti against the wall to stick.
I also like the “Ten Types of Innovation” frame that our coworkers first discovered in the NAS Leading Innovation course. Are we innovating and experimenting with the configuration of something (profit model, network, structure, process), the offering (product performance, product system), or the experience (service, channel, brand, customer engagement) allows us to break down what often feels like an amorphous thing – let’s experiment! But where, in what ways, and how?
Shawn: It means embracing that what works today doesn't necessarily work tomorrow. For an organization like Fractured Atlas, the only way to survive is to keep working towards a future that has a certain amount of unknowns in it. To thrive in that environment, you need some kind of culture of experimentation where it's okay to think beyond today and especially important to think beyond what was yesterday. Once you get there, it's a new future again.
How does a culture of experimentation shape team dynamics?
Ruffin: I think the team dynamics change because communication has to change. If people are trying new things, the way that gets cascaded down and across an organization changes dynamics. It adds a certain level of uncertainty. So organizations who do this well have a high level of trust.
Pallavi: A culture that encourages change and innovation inherently also needs to be extremely comfortable with ambiguity. This applies not just to the work that teams do, but sometimes also to roles. Especially in smaller organizations or teams, people need to be able to adapt to shifts in roles and responsibilities. In many ways, it places a greater tactical emphasis on mission focus.
This has also been an evolution as we've hired new team members.
Each role has a different proportion of stability and ambiguity. When we first started hiring for a newly evolved Program Associate role, we went in with a predetermined and quite structured list of job duties and responsibilities. Yet, on the job we expected them to be ready to adapt very easily to all kinds of change.
As we've gone forward in the hiring process, we've adjusted that. So now, there’s clear messaging in the job description that candidates need to be able to deal with change, need to be able to thrive in some level of uncertainty. And the interview process also now incorporates that, too.
Sometimes the organization is at a very significant level of change and flux. Leadership might be able to operate at that level of uncertainty. Maybe senior directors can operate in that environment too. But someone operating with less context or with limited control just wants to come in knowing this is what I need to do when I come into work. We need to be constantly reminded that there needs to be a core of roles, responsibilities, expectations that are stable, and then there's that little bit of stretch that's allowed, and I think that's how you also control the experimentation, innovation, and creativity.
Iteration is a way to see what’s working and to tweak what isn’t. How do you know exactly what to iterate on?
Pallavi: We never go in with this idea of “This is how it's going to be.” It is more a question of looking at what the next step is, and then working towards each step a little bit at a time. The evolution of the Program Team was based on identifying a problem or challenge, and then figuring out how to address it.
The problem we had was that our Program Team was structured in independent silos. Each Program (Fiscal Sponsorship, Visas, etc.) had its own team that addressed customer and member needs with a level of expertise. That was a real challenge for our members. Members would call in who were engaging with Fiscal Sponsorship, Artful.ly, and insurance would have to get passed from team member to team member. Not only was it frustrating for members, but at a cumulative level, the amount of time we were spending as an organization was inefficient. We were spending time passing the call from one person to the next or [passing] an email from one person to the next and then a second or a third person reading the question, reading the email, or listening to the whole issue again. And at the same time for the team members, it was limiting; they just learned one thing and they kept doing the same thing again and again. It didn't give them a chance to explore new skills, or abilities or interests or anything like that.
I had an idea of what that end point might look like an ideal scenario based on my experience with other places, but we obviously couldn't go from zero to 100% straight away. First we started with a few team members who worked across programs, and then increased the number of team members who worked cross-program. Then, we collapsed all the silos and merged everyone into one big Program Team. And now we're learning that's not ideal either. Sometimes you don't get it right, even after going through all of this. You learn that, maybe this is not the way to do it, and you need to roll back a little bit or scale back a little bit. And so we're going back to some level of specialization, but not as extreme as it was.
Tim: One of the ways that we've found spaces to experiment is by having someone ride along who's not familiar with a particular process or workflow. When Pallavi and LJ were new, they would “ride along” [as people worked] and ask "How do you do your work?" and then "Why do you do it that way, why do you go through all those steps?" Often, the answer would be that that’s the workaround we had to create. Sometimes these conversations identified that if you just changed one thing, you'd save four steps or you could automate the process altogether.
You might not be able to articulate why something sucks if you've done it for years. Oftentimes that outside questioning helps you reframe and expand. An outside perspective can say, “You've been working on it for 6 months, it keeps getting delayed, what's going to change that makes you think this time you’ll achieve the goal?”
I use the example of payroll. Payroll has to happen. It needs to post in people’s accounts on a set and regular date when they expect it. But even within that there's ways to experiment. There’s this push to get people paid in real time. I learned recently that some CEOs who get paid millions often get paid on a daily basis. They negotiate daily pay because they don't want to wait two weeks or a month for their pay. They want to get it to their investment advisors as quickly as possible. Why do just the CEOs get to be paid like that? Is there a way so that rather than people needing to use tools like payday loans, can we just pay people the day they work so they don't have to get that loan in the first place?
There's not a lot that you can experiment with there, but there are ways to experiment. Most people think payroll is a pretty dry thing versus creating a new program or new software where nothing exists. How Jillian Wright figured out how to move money without an office is pretty experimental. Most organizations send checks or occasionally wire money, but Jillian has figured out with the finance team how to move money in a variety of different ways.
We also have been engaged in a decade’s long experiment in how we work. We didn’t just go from everyone working together five days a week in one physical office to being an entirely virtual organization with team members spread across 12 states and six countries. We experimented with things relatively small (like headsets and one person working from home one day a week) to relatively large things (like online file storage systems and entire teams working “off site” several days a week).
How do you know when to end an experiment?
Shawn: You certainly have to be careful about putting too much on the initial reaction. With structural change, there's going to be concerns and anxiety. You need a number of weeks not days to really see if something's working. You need to give people who are having trouble adjusting enough time to overcome it. They could be even intentionally or unintentionally sabotaging the change because of their own internal protest mindset. Once you get through that, it's just a matter of if you can get the team efficient in whatever the change is.
Ruffin: Most things shouldn't last. There are very few things that need to last forever. Cut your losses? I think you have to plan to stop.
We're seeing this in the pandemic. People are talking about re-opening but very few people are talking about re-closing. People want to open up now but we have to talk about the point at which coronavirus infection rates increase and public spaces need to close again. What does that disruption look like? We're always so eager to get to success but we never discuss what happens if this idea or program or project doesn't work out. Tim likes to talk about pre-mortem exercises for this.
People really want to build lasting institutions and I think that's really problematic. That's one of the things I love about fiscally sponsored projects because, to me, they’re the core of what it means to iterate.You have creators working on projects that explicitly aren’t meant to be permanent.
Artist Campaign School (ACS) is a good example. We did that really really fast, primarily because I knew people who could do the work and I knew that it was timely. The goal with that was really clear, it wasn't supposed to last forever. It was time-limited — it had a goal of training 100 artists and we got really really close. I was only planning to do it twice. I did it twice and now it's done.
Iteration requires an understanding of what it means to stop doing it. I love pilots and I love time limited projects. Once you go out and say “I’m building a nonprofit to do this thing” or “this is a permanent program that we're going to make sustainable and scale,” you get stuck. When I was building ACS, I didn't say any of those words. No sustainability, no scale, no nothing. I think some people think that's being afraid to commit, but I think it's really important to be thoughtful.
You’ve gotta cut your losses when it's not fun anymore. Work with the willing. If it's not fun, if people aren't trying to work with you, get out of it.
Pallavi: All of us in some way are very careful about closing the loop and making sure that if we do come up with a new idea we're following through on it. And we're making sure that there's an understanding of relevance as we go forward. I am not a fan of the question “How do you evaluate success or failure?” Because I think that can miss changes that are unexpected, and yet good. So I prefer to call it an evaluation. I prefer not to calibrate it to success or failure because that is binary, and evolution is never that simple. Is it mission relevant? Is it mission impactful? Does it leverage existing strengths and resources that we have in the organization? Is it going to come at a cost? Is there a revenue benefit? Is there a qualitative benefit? Is that benefit coming at a cost that's higher than the value of the benefit itself? Those are some of the things I would tend to look at.
Are there ways that you've seen the framework of a culture of experimentation used in a toxic or harmful way?
Ruffin: I think this happens a lot with visionary leaders, who are super brilliant and super generative. A leader who is always hopping from thing to thing to thing, who can't stick to a path for any period of time to get good data points, can be really challenging for someone to follow. The manic swing of that can be very intoxicating and amazing to work with...and also really really hard.
When you have charismatic leaders who require less charismatic operational people to implement things, the brunt falls to the implementer when the visionary leader turns to the next bright shiny thing. The operational person becomes the person with the hard job of always starting something while also frequently having to tell staff they have to stop doing something.
Shawn: The danger is when you have experimentation embedded in your culture but it happens so frequently that even those who could usually roll with it can't roll with it, there's a constant danger [of burnout and disappointment]. You need to be able to just enjoy it for a moment. That's why we had a big get-together once about one of our thematic goals. In part it was an attempt to say that even though this wasn't perfect, we're going to find a way to celebrate accomplishment based upon big change. In our jobs, I think we want to get to a point where you can be done and be good with that, but since we leverage technology, it's always going to be moving at least a little faster than we want it to.
Tim: Constant and nonstop experimentation can lead to burnout and low morale when you never reach the, or any, goal. We've seen this at Fractured Atlas, when we've been working on something for a long time, and we never arrived at a milestone along the way. It begins to feel like you’re always iterating and iterating and iterating, and you never get the dopamine hit from those milestones. Burnout comes when people feel a sense of permanence and pervasiveness about something. This is going to go on forever and it’s taking over all of the work that I do. Figuring out how to reflect on how much has already been accomplished provides a useful perspective, and finding ways to celebrate things along the way, especially if you’re developing in really long arcs, helps chunk the work into small(er) wins.
How can leadership create a culture of experimentation?
Ruffin: Say yes often and let people fail. The freedom to fail is important. I think it's mostly leading by example. Tell people to experiment. It's especially important as a leader to fail publicly and to admit to failing all the time. There's nothing worse than a manager who pretends they're perfect. In particular, at Fractured Atlas, we do things that nobody else has done. There's not another organization in the whole world that does fiscal sponsorship the way we do it. As a result, all the things that we're doing are things that have never been done. And so we're going to fail.
Tim: Most things won’t work as intended on the first time around. You don’t give someone keys to the entire organization on day one and then see if they burn the place down. You start with small things, small bets, and see what happens. People and teams need to learn how to exercise this muscle. As leaders, we need to be encouraging of this process. Resist the urge to say “we tried that before” or “that won’t work.” (Or if you do say “we tried that before,” consider saying it in an encouraging way that provides background about how and why something didn’t work before, but recognizing it was a different time and place.) Give people space to try things, be an appropriate distance away if people need support, ask “How might we?” and “What if?” questions to get people to think about the possibilities that might be available.
I think Susan Scott’s Decision Tree Model for delegation is a useful frame for leaders to help guide this process.
Image credit: Holly Garrison
Pallavi: Experimentation and innovation can easily get out of hand. Without careful calibration this approach runs the risk of becoming "what" we do, and not "how" we achieve our mission. As important as (and sometimes more than) encouraging creativity and testing, leaders need to ensure there are processes that require evaluation, and moving forward or shutting down of ideas based on success or failure.
Shawn: I subscribe to the notion of radical candor, which means when you have critical feedback for someone, they get it. You don't wait, you don't do it in a way that embarrasses them in public but you let them know. There's something special about knowing that when your manager sees something that needs to be corrected that they're going to tell you. That actually gives a lot of security to someone because then they can actually believe that the inverse is true. You need to enforce that they are doing a good job, that you appreciate them. But you can't get there without going right to the “Here's what went wrong, here's what happened, here's how you were a part of it, let's move on.” I don't think you can function otherwise.
You can talk about failure in action but not failure at the personal level. You can frame things in such a way like you, the person, are the failure or you can frame it like this thing you attempted to do failed. It's a really important distinction to make. You need to make room for someone to believe that they can do better. Whereas if you're encouraging them to believe that in themselves they are the failure that happened, then there's just no room for enough optimism to get up and try again.
If our non-hierarchical, four-person leadership team is fundamentally an experiment, how are we measuring its efficacy? Learn how we are evaluating this ongoing, iterative process to develop structures of power that are aligned with our values.
.svg)