Crossposted from here.

I attended a collegiate Bollywood-Fusion dance competition a couple of weekends ago. This setting was nothing new to me; I competed at many competitions back when I was in college, and after graduating college, I spent a couple of years volunteering with a group that organized a large competition and assisted other competition-organizing groups with their logistics and planning. Basically, through my experiences, I had a high degree of familiarity with how these events typically run.

In my experience, the challenges associated with organizing these collegiate dance competitions are what I would call solved problems: problems for which already existing solutions have been adequately demonstrated. Each competition's core outcomes and processes are largely the same, and the organizing group’s responsibilities and tasks are generally static year after year. Even though Bollywood-Fusion dance is relatively new in the United States, there have probably been over 500 of these competitions run across the country over the last 10-15 years.

You’d expect each of these competitions to run like well-oiled machines by now, but I was really surprised to see that many of the things I viewed as solved problems…weren’t.

The emceeing and awards presentation was awkward. Teams were taking flagrantly unnecessary amounts of time setting up for their performances. Transitions between sets weren’t seamless. All this contributed to an experience that at times felt disjointed and clunky for the audience. And the worst part? The solutions to these problems weren’t secrets! They were widely known and well-documented.

I had no idea why this was happening, but it drove me insane enough that I decided I never wanted to run into this issue again. So I built myself a framework — a playbook — designed to prevent myself (or any team I'm part of) from falling into the same trap.

step 1: throw away roles, responsibilities, and titles — define problems instead

One of the biggest mistakes I’ve seen teams make is that they over-index on defining roles and responsibilities instead of focusing on the actual problems they need to solve. It’s so strange; very few people question why they dream more of holding a certain title or attaining a certain set of responsibilities than of the problems they’ll solve or how they want to make things better. Generally, it’s like shuffling deck chairs on the Titanic; no matter your role or responsibility, you still have as much power to solve interesting problems. And people who solve interesting problems generally end up doing quite okay for themselves, which means worrying about titles is just a waste of time.

For example, a competition committee will assign someone the title of "Stage Manager" and give them a list of responsibilities like:

• Coordinate performance transitions
• Ensure the backstage area is clear
• Communicate with emcees

But none of those tasks are the actual problem. The actual problem is this:

How do we ensure seamless, professional performance transitions that feel natural and don't disrupt the audience experience while giving performing teams a clear flow?

The difference here is subtle but critical. If you think in terms of roles, you get stuck in predefined job descriptions, boxing yourself into behaviors and actions that have to be performed a certain way. If you think in terms of problems, you open yourself up to solving the problem in whatever way makes the most sense. You give yourself the freedom to be creative, to learn, and to operate efficiently. Anything you're doing that isn't directly solving a problem you're experiencing is, by definition, a waste of time. The problem statement gives you a built-in filter to screen all the actions you and your team are doing, cut the waste, and optimize the rest. It gives you agency, ownership, and confidence in the areas that you’re investing your time into.

Outcome of this step: A clear, problem-centric list of challenges you’re trying to solve. Ideally, the list also includes acceptance criteria (ew scrum term 🤮) — i.e., how you'll know when each problem has been adequately solved.

step 2: aggressively find existing solutions

Way too often, people just start working on things without checking whether the problem has already been solved. It’s the equivalent of trying to reinvent the wheel every single time you’re building a car. Instead, start with the assumption that someone has already solved the problem you’re facing and that your task is finding the solution instead of creating it.

Here’s my approach for quickly surfacing existing solutions:

1. Identify analogous groups of people facing similar problems — in the case of groups organizing dance competitions, it would be other competition-organizing groups, even if they’re not directly Bollywood-Fusion groups.
2. Study how they did it — collect materials, ask questions, watch videos, etc. Do anything to gather as much intel as possible. I’ve found that people are really helpful and eager to share their solutions, especially when you come armed with specific questions directly tying back to the problems you’re trying to solve.
3. Build a library of case studies — use the information you’ve collected to build a library of examples to pull from as you define your approach.

In your research, you’ll probably find that you were previously unaware of a lot more problems that you’ll have to solve to actually meet the success criteria you listed. This is a good thing! It means your model of the problem space is expanding; you’re learning.

Outcome of this step: An enriched problem list with case studies and solution templates. Now you’re ready to cook.

step 3: spend your energy only on unsolved problems

Once you’ve found problems that already have clear, effective solutions, just implement them! There’s no need to waste your precious and scarce creative energy on them. Instead, shift all of your team’s remaining energy towards the unsolved problems — the ones where existing solutions either don’t exist at all or don’t quite fit. If you do that, you will be building on top of existing solutions, not recreating them, driving real human innovation in the process. That’s sacred! And it’s also just way, way more fun.

caveat #1: no problem is ever fully solved

I don’t think there’s a single problem that’s been universally solved. Solutions are always path-dependent and have contextual boundaries. The story is never as simple as “Solution A worked for Problem B”. A more accurate statement is something like “Group of people A employing solution B at time C in the climate D were able to effectively solve a unique manifestation of problem E.” Each of those variables is infinitely complex; it’s almost impossible that you’ll face the same exact problem as someone else, and even if that happens, there’s basically no chance that the exact solution that worked for them will work for you in the same way.

There are two specific challenges with researching existing solutions:

1. Extracting generalizable principles from the solution is hard! — It’s really hard to know what specifically about what someone else did solved the problem. So often, you mimic others but experience different results, and are left more confused than before. It takes lots of patience and experimentation to figure out what you can actually extract from other things you see and find.
2. Applying generalized principles to your specific problem instantiation is hard too! — If you’re able to figure out what key learning applies to your case, you still have the unenviable task of figuring out how it’ll manifest for you and how you’ll have to tweak it. How is your context different? How does that difference inform your approach and your application of the learning and solution that you find?

Some find it overwhelming. I find it invigorating and stimulating. For me, there’s no greater rush than actively being in it the way you are when you’re facing all these challenges head-on. 

caveat #2: learning, training, and coaching is a thing

Even if a solution exists, execution is still hard, especially for people who haven’t done it before. For example, the process of building a mobile app is well-documented, but it’s still an intense creative challenge for people doing it for the first time.

On every team, you’ll find people with wildly different experience sets, and executing effectively as a team often will require investment in learning, training, and coaching others. This is really important; contextual understanding is necessary to map out the problem space that you’re tackling. Someone who has no idea how apps are built has no hope of solving problems that developers face; they wouldn’t even know where to start.

Every leader should invest the time and energy needed to help others understand the contextual space enough to contribute to the problem-solving process! It’s often the people who have the least experience with the contextual space that find the most innovative approaches. It’s almost a fundamental law of human nature; as your experience within a contextual space increases, even though you know more and your speed of execution increases, your ability to think creatively within that space decreases.

Maybe one day someone will figure out how to walk the knife’s edge of executing like an expert while maintaining the mental plasticity and creativity that only people with fresh eyes can have. For those who are unable to build a savage and ruthless team of people like that, just ensure that you have some beginners and people unfamiliar with the domain space. It’s always worth having those people around.

caveat #3: some things aren’t problems to solve, but just artistic choices and expressions of taste

Not everything is a problem with a correct answer. For example, if you’re creating a logo, there’s no “right” answer. Sure, some designs might be a better fit than others, but eventually, you just have to run with something that feels right. I’ve found that situations like this often paralyze groups. I think about this anecdote all the time:

Sitting in a utilitarian beige room on those uncomfortable chairs that are often found in government offices, a committee of eleven civil servants sat hunched over copies of a large, seemingly never-ending 400-page document. The first topic up for discussion is a proposal for the construction of a 90 billion dollar nuclear power plant.

The chair of the committee has just completed an extremely thorough and lucid argument outlining the pros and cons for the current design, and now it is the job of the committee to deliberate and vote on the proposal. As you may have guessed, a nuclear power plant is an extremely complex system. You would also be correct in assuming that the decision to build one should require a lot of time and deep deliberation based on an understanding of the complexities of nuclear engineering.

Sadly, none of the committee members have any experience with nuclear reactor design, and most are not even engineers. Even more unfortunate, a fear of appearing unknowledgeable prevents everyone in the room from voicing any concerns. In fact it took less than ten minutes for all the committee members to vote in favor of the design.

The next topic up for discussion was a proposal for a ten thousand dollar bike shed that would house the bicycles for the nuclear power plant’s employees. This was a much simpler topic to discuss as each committee member could easily visualize what a bike shed typically looks like and how it should function. However because the proposal was so simple, every committee member felt empowered to provide their own subjective input into the design of the structure. For hours, they debated colors, building materials, and even signage.

Once the meeting was adjourned, the chair of the committee reviewed the minutes. She was taken aback when she realized that the committee spent over 20 times the amount of time to discuss the bike shed compared to the much more important and complex nuclear power plant proposal.

Subjective input into designs that are a matter of taste sucks up too much time. And, I cannot say this enough, this is not a creative act! It’s an executive and administrative one! So, please, just appoint one person to make a decision, trust their taste and intuition, and run with it. Any bitter feelings you have will be far dwarfed by the joy you will receive by freeing your energy to just solve problems and create.

This approach applies to pretty much every domain I’ve come across:

• Our feelings and experiences — Much of classic literature has solved the problems (or at least defined the problems) that many humans face in our subjective experiences. The more self-aware you are of the problems you’re experiencing, the more empowered you’ll be to find something deeply valuable and moving! Romeo and Juliet is a cautionary tale of the danger that awaits those infatuated with superficial images; Crime and Punishment vividly describes the experience of those who sin and their only path toward absolution; The Hobbit is a wonderful journey that shows the fruits awaiting those who journey outside their comfort zone and the confront the objects of their deepest fears.
• Learning — The pathway to rapid learning is to first define the limits of your knowledge (i.e. the problems in your understanding of a specific domain). If you don’t first take this initial step, you won’t be tactically and intentionally spending your time filling in the holes in your mind, which is the whole point of learning in the first place.

It also surfaces many opportunities for you, if you fully invest yourself in the process:

• If you’re intentional about mapping out the problem space, you can turn the work that you do into informational primers that give people a much better sense of what their day-to-day experience will look like if they choose to enter a similar domain as you. Imagine how valuable this would be for any kid in high school or college who is more naïve about the world than they could imagine! (Yes, I’m talking about myself here. Sigh.)
• If you’re intentional about conducting targeted research, you can turn your work into a consolidated knowledge repository that other people in similar domains can turn to to supercharge their ability to create things in their domain! I’m pretty sure this is how many podcasts start btw.
• If you’re intentional about solving problems, you can turn your efforts into explainers that other people can then learn from!

Each of these is generally a wonderful financial opportunity. But the part that gives me the most satisfaction is just the ethic and act of contributing to the whole and general unified field of human knowledge and experience. It’s special! It really makes you feel like you’re a part of something greater than yourself.