The Great Teacher

Some years ago, I was feeling stuck at work. The product problems I was working on were exceedingly hard to move and I was struggling to feel a sense of progression.

I decided I needed to learn something far removed from the world of software. I wanted it to be something concrete. I wanted something that I’d have no expectation of ever being good at it. I wanted something that would feel like an accomplishment. I wanted to learn something cool.

I chose unicycling.

I had seen videos of people riding unicycles with fat tires and thought it looked like a blast.

Play

Common wisdom is that you should start out on a small unicycle with a 20” wheel so that your feet are close to the ground. That didn’t interest me. I wanted to ride something BIG.

So I bought a 26” Surly Conundrum unicycle and protective gear, suited up for battle, and headed down to the garage in our apartment building, found a way to get up on the thing, and started to learn.

After fourteen half-hour sessions over two weeks, I was able to mount, tool around, ride in figure eights, and voluntarily return to an upright postition more often than not.

I was shocked by how easily it happened and later came to realize that unicycling had taught me valuable lessons about learning, but also about making software.

Here’s what I learned:

1. Choose something worth learning.

Find a thing that calls to you.

The first and most important thing I did was follow my intuition that this would be a fun thing to learn how to do. Sometimes it’s better to not overthink things.

When setting off on a project, It's important that you choose a skill or a problem that you're invested in. The more invested you are in what you're doing, the more likely you'll stick with it when things get hard.

Choose something you think will be hard to master.

One of the easiest ways to not learn a thing is to think that you should be good at it. No one goes into unicycling with the expectation that they’ll be good at it from the start. My expectation that unicycling would be hard forced me to acknowledge my ignorance in how it was going to go. I was able to give myself permission to be bad at it. There’s freedom in this.

When choosing something hard to do, it's important to acknowledge what you don't know. Questions are more important than the answers. The difficulty of the problem relative to your understanding much shape the approach you take. Acknowledging the possibility of failure is a precondition for solving a wicked hard problem.

Choose something where your ego isn’t at stake.

It was helpful to choose a thing to learn where I had nothing to prove. No one ever starts out looking good when unicycling. Humility is a useful when you’re learning a new thing as it keeps you open to the hard lessons you’ll learn along the way.

When there's a lot on the line for a project you're working on, or if that project can't fail, then you're almost certain to work in ways that result in fewer lessons learned.

Have a reasonable starting goal in mind.

I kept my goals modest so that I’d be more likely to have a win at the end. I’d be happy just to learn how to get up on the unicycle and tool around. The more constrained the initial problem, and the clearer you are on what your desired end state will be, the more likely your effort will be successful.

So many software projects fail because they are all-or-nothing propositions. A key to being successful is to choose the kinds of problems that generate something useful along the way.

2. Create the space for learning.

Accept that failure is the most common state.

The desire to get something right is one of the greatest impediments to learning something new. Learning happens when you discover that the world doesn’t work as you think it does. If somehow I’d been magically able to unicycle the first time, it would mean that I had learned nothing. Since I knew the failure was inevitable and would likely result in my crashing in various undignified ways (unicycles are inherently unstable machines), I understood that the project would require some preparation, and some safety equipment.

Anticipating what's at stake for your project before the work happens is a good way to improve the odds you'll be successful. If you understand the nature of the problem you're trying to solve, it will help you to figure out what you'll need to have in place to increase the chances you'll be successful in the long run.

Find a safe place to practice and fail.

I decided I’d learn in the garage in our apartment building. It was flat and would be big enough to roll around and quiet enough in the evenings that no one would see my failures. When you think you’ll have an audience, you’ll be less likely to put yourself in a position where you can fail.

I think this is one of the reasons why so many useful software capabilities start off as side projects.

Mitigate the consequences of failure.

I assumed that I’d get injured without protective equipment. I invested in shin guards, wrist guards, and a helmet. When you reduce the consequences for failure then you don’t have to try and avoid it, and you can learn faster.

So much of a software project's success comes down to how it's set up and what the rules of engagment are. Is there space to fail? Do we have the kinds of infrastructure in place where we can push changes to production regularly, safely, and cheaply? Can the problem we're hoping to solve be broken down into smaller parts? Is the team supported by leaders that will back them when mistakes happen?

3. Get to work.

Break the problem down into logical components.

I assumed that there would be two major problems to solve: Riding and mounting. It seemed reasonable but my understanding of the problem turned out to be incomplete. More on this two paragraphs down.

Unexamined simplifying assumptions is one of the most common ways software projects fail. They can be hugely consequential but can also escape our notice quite easily. Make it a habit to identify and articulate the simplifying assumptions you are making when you embark on a software project. You'll often end up figuring out the thing you need to test that will determine whether you'll be succesful in the long run.

Figure out what the first step should be.

My research indicated that the easiest way to start was sitting on the unicycle while hanging on to something. Also, given the height of the unicycle, mounting felt daunting. I was most interested in learning how to ride, so sitting and trying to move felt like the right place to start. Besides, even if you could somehow learn to mount a unicycle, would it count as mounting if you can’t figure out how to get moving?

Product teams can often spend more attention worrying about how a particular feature or capability will be adopted, rather than focussing on the heart of the thing they are trying to make. Getting to the heart of a problem -- the thing that everything else hinges on -- is key to making rapid progress when building new software.

Double check to ensure that there aren’t other important problems to solve.

Once I let go of the wall for the first time, I quickly discovered that safe dismounting was also a problem to solve for. I think learning by doing and letting the problems come to you can be a valid way to operate but thinking more clearly is helpful too — especially in situations where overlooking something important could have significant repercussions. It’s a good thing I started with unicycling rather than DIY paragliding.

A great number of software projects fail because it's easy to overlook all of the things that must be true in order for a project to work. What are we missing or overlooking? What do we wish were true that might not actually be true?

Operate within the current limits of your understanding or skill.

When you try to ride a unicycle beyond your skill, you’re on your ass and fast. Successful unicycling is really the practice of delaying the moment when you’re on your keister. If you can delay that moment indefinitely, then you’re a pretty good unicyclist.

When designing software it's always important to be aware of the limits of your understanding. Don't design more than can be reasonably built. North star vision exercises almost always write checks that designers and software organizations are not prepared to cash.

4. Learn through encountering, recognizing and understanding failure.

There’s no way to learn how to unicycle without putting your ass in the saddle.

You can’t unicycle by proxy. You can’t workshop it, no user journey will get you closer, you can’t storyboard it, you can’t plan it in advance, you can’t mock it up, you can’t low-fidelity prototype it. Putting your ass in the saddle and having some skin in the game is the only way to learn.

So much of the design process is geared towards reducing the chances that a bad idea will come in contact with the real world. This has the result of depriving designers and the teams they serve the opportunities to learn as quickly and as deeply as they might.

Create the conditions where success and failure are clear.

Unicycling is awesome in that success and failure are binary. If you’re up, that’s a 1. If you’re on your backside, that’s a 0. The clearer the distinction is between these two states, the easier it is to judge your progress and diagnose problems.

So many software projects can get mired because a team doesn't have clear ways to determine what success and failure looks like. This is a consequence of making things that touch many people at a distance where the impact of design choices can not be easily observed.

Make failure fast and cheap.

When starting out in unicycling, failure happens almost immediately. Gravity operates at 9.8m/s, and it’s always operating. Strictly deterministic systems that are easy to observe make great environments for learning. The cost of learning unicycling is inversely proportional to how much protection you’re wearing and how much health insurance you have.

The easier and safer it is to make a change, and the clearer success and failure are, the faster software teams can learn.

Diagnose what doesn’t work and adjust

Much to my surprise, the riding portion of unicycling was pretty straightforward: lean forwards and keep the unicycle moving with you. Unhappy path avenues were more complex and varied. If you lean too far to one side or another, you tip over. If the unicycle moves too slow relative to you, then you fall forwards. If the unicycle moves too fast relative to you, then you fall backwards. For the record. It’s much preferable to let the unicycle roll ahead of of you as you gently drop to your feet behind it. I learned this after I took my feet off the pedals while I was still moving and ghost rode myself into a rapid unscheduled disassembly event.

The lesson here is to not overthink too much before you embark on a software project. It's always going to go differently than you think it will. As long as you are paying attention to the signals, you can adjust as you go.

When the cause of a failure isn’t clear, reduce the number of variables you’re juggling at one time

Getting up on the unicycle turned out to be more of a challenge than I had anticipated — owing in part to the altitude of the unicycle I chose to learn on. I found that it was helpful for me to build up the motion of mounting one step at a time while observing the outcomes. I also found that building a routine of rituals that I repeated gave me a good foundation upon which to judge whether the next new thing I did was an improvement, or a step in the wrong direction.

In software, it can often be helpful to build up iteratively by establishing a baseline that you know works and then experimenting as you go. If you make too many changes at once, it can become hard to diagnose what the cause of a problem is.

Don’t argue with reality.

One of the harder lessons I learned was what happens when things would start to go south and I’d attempt to compensate. When an unstable system is out of equilibrium, poorly applied corrections can exacerbate the problem. Imagine what happens to Wile. E. Coyote when he hits a wall. So much for dignity.

Arguing with reality is a very common mistake for software organizations to make when they are driving towards a goal they've set for themselves. It can take real courage to admit that the thing you were tasked with making won't work.

Learn to anticipate when it’s about to go poorly.

After I was able to consistently recognize the signs that impending failure was approaching, it became easier to gracefully dismount. The more practice you have, the easier it becomes to anticipate correctly. The ability to anticipate is a sign that you’re in tune with the problem space you’re operating in.

Being in tune is how you get to be able to trust your gut and intuition, critical ingredients for any designer hoping to make something new that hasn't existed before. Building deep domain knowledge is also critical for being able to build something new in software. After all, almost all of the simple and easy things have already been invented. You can't make something truly novel if you don't know your stuff.

Notice when you’re repeating mistakes. It’s a sign there’s something you need to learn.

I definitely struggled with getting up reliably during my second week of unicycling. It took me maybe a hundred tries to get a feel for how to mount with the right pressure on the pedals. Sounds like a lot, but it only takes about 30 seconds to get into position and give it a go. When working in a situation where the unknowns outweigh the knowns, the cheaper it is to try a variety of things out and learn from them, the faster learning happens, and the more likely you’ll discover the right solution.

There's a big difference between trying a lot of things in Figma, and trying a lot of things in working software. You'll learn much faster and find better solutions if the cost of trying out ideas in software is cheap.

5. Learn through repetition.

Daily practice facilitates nervous system rewiring.

I found that practicing each day had the greatest compound effect as my nervous system rewired to incorporate the lessons learned in the past. Repeated small changes paid greater dividends over time compared to me trying to brute force my way into unicycling competence.

Getting into the habit of releasing small additions to software, and building the muscle memory through continual releases is one of the most important skills a product design team can learn how to do.

Repetition over time will eventually free up cycles for higher-level thinking.

When I started, I had to focus very intensely on what I was doing. Learning how to unicycle involves rewiring your nervous system so that more of the the activity is handled subconsciously. This frees up mental cycles for observing what’s happening while it’s happening.

As designers, when we focus too much on process rather than outcomes, we're not able to give ourselves over to the thing we're making. The more complex and involved the process, the longer it takes to reach a state where you can focus on outcomes and impact. There's a world of difference between learning a set of dance steps and performing the dance so that your audience feels something.

Find balance first, then aim for flow.

I’ve always had good balance from cycling, so it only took a few days for me to be able to tool around the parking garage in our building — and after a few weeks, I experienced flow. It was surprising to reach this state so quickly given my assumption that unicycling would be hard to learn. That said, the inherent instability of unicycling meant that flow state was often rudely interrupted as gravity took over. The important takeaway here is that flow is the thing that happens when you do a bunch of other things right, and flow stops when you do one or more things wrong. If I had tried to aim for flow without first having the basics in place, I think I would have struggled a great deal, or ended up in traction, or both.

The ordering of problems is incredibly important when you're in the business of inventing new technologies or products. What's the core of your product? What's the first real bit of value that the whole thing hinges upon? Spend the majority of your attention there. If you've made something that really offers value, inventive humans will figure out a way to use it, even if there's almost no first user experience or polish. That can come later after the thing you're making is humming along.

6. Celebrate your wins.

Define what success looks like

There are at least a couple of different framings for success that are important where unicycling is concerned. On the macro scale, success is pretty easy to spot. When you’re up for as long as you want to be up, and you can gracefully come down when you want to stop, you can count that as a success. On the micro scale, there are a bunch of different steps you need to take in order to mount the unicycle, get it moving forwards, make left turns, right turns, cycle in place, and return to the ground. Each has success and failure states. Thankfully, they’re all quite obvious and easy to discern.

When making something new, I think it's quite easy to not think about all the things that must be true for a particular feature to be successful. Figuring out what those hard parts are requires smart people to work very closely together to talk through what the obsticles and challenges might be. The requirements for a project should follow from this essential work, not preceed it. The more we treat the creation of software like factory work, the easier it is for people to stay in their lanes and not take responsibility for the sum of the parts.

Successes are just as important a signal as the failures.

Unicycling is a game of doing a lot more of the right things than the wrong ones. The harder part of learning is understanding why one behavior results in success while another will result in failure. Since the physics of one wheeled vehicles are pretty simple, and the mechanics of having a body are also relatively well understood, it wasn’t too hard to understand why one thing worked while another didn’t, and this helped me learn faster. The more cause and effect are joined, the easier it is to diagnose problems.

Situational awareness is incredibly important when you're making something for people not you and the impact of your design decisions happens at a distance. If the thing you're making isn't instrumented well enough, or if you change too many variables at once, you lose the ability to pinpoint the downstream consequences of the choices you're making.

Pay attention to what’s working over time.

When you’re learning a a skill that requires the integration of a number of sub-activities, it’s important to identify which ones are working well in isolation and in concert. The more you can integrate the successful parts, the better you’ll get at the whole activity. As I became more comfortable with unicycling, I was able to identify the areas where I wasn’t as strong. Turning right was easier than turning left for a while. The more that went well, the easier it was for me to fix the things that still needed improving.

I think it's very easy for busy software teams to stop taking stock of whether the thing they are making is actually good. Even when they do, they may not factor in the time to improve things because they're too busy making the next thing. Team members may not use the thing they are making regularly enough to be able to judge whether it's any good, or whether it's really improving.

Work to build a sense of momentum.

By practicing a half hour each day for two weeks, I was able to build success upon success with few setbacks. The more progress I made, the more enjoyable unicycling became. Momentum is something that’s often hard to come by when working on software design problems. Being able to go from sitting to tooling around after about seven hours of total practice time was a huge boost for me.

It's incredibly easy for software teams to get bogged down in wanting to get things right before a product is launched, but I've always found that getting something early out, learning from it at each stage, and iterating like hell always results in better software faster than when teams try to polish what they're making to a high sheen before launching.

7. Change it up.

Shift tactics if you’re stuck.

I found it helpful to change things up when I got stuck. If tooling around was a challenge, I’d practice mounting the unicycle. Shifting tactics made the whole thing feel like a problem to solve. As long as I could try new things, I didn’t feel as if the problem would be too hard to solve indefinitely.

How often is it that software teams decide that the thing they're trying to make just isn't working? How big is the thing you're trying to test? The more expensive it is, the more invested we become in the outcome and the harder it is to change tack.

Know when to call it and come back fresh.

I noticed that during each practice session, I’d start to reach a point of diminishing returns after 45 minutes of practicing. Calling it and coming back fresh the next day would often be enough to give me the perspective needed to figure out how to get past yesterday’s blocker.

The harder a software problem is to solve, the more likely you'll need to step away and approach it from different perspectives. How much room is there to do this in a culture that tends to think in two to four week sprints?

Be open to the journey and adjust as you go.

One of the things I was surprised to learn was that the thing I thought would be the hard part — riding around — wasn’t all that difficult. Reliably getting up on the unicycle was more of a challenge.

Part of learning or making something new is being open to the challenges it presents. The fewer preconceived notions you have about how it's going to go, the more open you'll be to where the project takes you.

Look for the a-ha moments that unlock things

I struggled with mounting the unicycle for a while because I thought the job was to hop on and sit upright on the unicycle. Each time I’d do this and start to pedal, the unicycle would move forwards and out from under me. The trick for solving this was to realize that the goal needs to be to get up and lean forwards so that you start to fall forwards. My flash of insight was to realize that unicycling is the act of falling forwards and then have the unicycle catch up just enough to maintain your momentum. If you start to slow down, just fall forwards a bit more. I’m still amazed that being able to unicycle isn’t a physical activity as much as it’s a way-of-seeing activity.

Truly understanding what's at stake for a project only happens when you go on the journey of putting it out into the world. Learning how to understand what's at stake is one of the most important skills to develop as a designer.