The agile art of knowing when to stop.
My 14-year-old son, who is into game design, got to chat with an older peer the other day who is taking software development classes at our local tech school. He asked him, “How do I decide when to stop adding things to my game?” The friend proceeded to teach him about “feature creep,” a term often used in the programming industry to describe when a product becomes overly complex because developers continue to add bells and whistles while it is being made. I giggled a bit as I listened to their conversation and told my son, “I think I am suffering from feature creep in my school.”
As I start my third year running a microschool, I am learning that iteration is not always the same thing as improvement. But in an agile learning environment, where the goal is to be flexible and adjust to the needs of the community, it is so hard to judge sometimes when to improve and when to allow things to unfold imperfectly over time.
My goal this year was to get back some of the work–life balance I lost in my second year when my enrollment more than doubled. Overnight, my school went from side-gig to full business, and while my school schedule was still three days a week, I suddenly had a full-time job just learning how to be a business owner.
This year, when I scheduled employees to run half of the days without me, I knew that I needed good systems in place. As I seek to clarify how I manage things, I am constantly noticing ways things could be improved to run more smoothly, increase student autonomy, share my workload across a team, and keep our space more organized. My perfectionism is in high gear, and I get a little hit of dopamine every time I “solve” something.
But there is a hidden truth about iteration that I am learning to bear in mind, and it is the reason that “new” does not always equal “better.” Every feature has a maintenance cost. This may include the time to train people in it, the supplies or technology required to run it, and the mental load of tracking it, enforcing it, explaining it, or documenting it.
Each new system creates a small obligation to keep that system alive. One question I am trying to ask myself more often when I consider whether to “improve” the school with a new idea is: Who has to keep this alive? If the answer is “me,” I have several follow-up questions before I jump into it.
In the 1950s, Herbert Simon coined the term satisficing. He combined the words satisfy and suffice to convey the reality that “good enough” can meet needs and solve a problem without sacrificing the very limited resource of time in pursuit of an elusive optimal solution. He proposed satisficing as the opposite of maximizing. Satisficing relates to the minimum viable product of Eric Ries’s and Steve Blank’s Lean Startup framework, wherein the goal is to create the smallest version of an idea in order to get real immediate feedback from its real use, and iterate based on evidence.
Satisficing is particularly helpful to me as a school founder because there is no shortage of things that could be better. After all, I got into this because I was sure that education could be done better, so my very aim is always to look for ways to improve.
But as a business owner trying to build systems, perfectionism and constant critical analysis is exhausting to both me and my employees. Perfectionism tells me that if I improve the systems enough, there will be no challenges. Everything will run smoothly, the space will stay clean, the students will all get along, the parents will always know what is going on, and the learning will happen naturally and beautifully.
But as my to-do list grows each day, I know that I will need to do more satisficing. So how do you know when a solution is “good enough”?
The first thing I have found helpful is to give it time.
My husband once told me that it would be easier for him to help me implement our family chore system if I didn’t change it so often. He helped me realize that I was sometimes responding to a perceived failure of the system with a complete overhaul, when really what was needed was just more training and more time.
In my school, I am developing the ability to discern when a system needs to be changed and when it just needs to be practiced.
I am also trying to become more comfortable with imperfection. When considering one of my many school-improvement ideas, I have to ask: Is this system actually broken or just imperfect? Often, an imperfect system is still working well enough to get 75–90% of the job done, so it makes more sense to direct my time, energy, and resources to more pressing matters.
As I reflect on the last two months of building systems, training new employees, and trying to perfect how the school runs without me, I realize that many of my decisions have been anxiety-driven rather than evidence-backed. I am beginning to see the difference between true iteration—decisions based on evidence from watching a system run for a while—and churn—the constant unsettled motion of trying to perfect all the things.
My ability to trust is going to be pivotal in helping me move from churn to healthy rhythms of iteration. I need to trust myself to make good-enough decisions and stick with them long enough to get real evidence. I need to trust my employees to learn and follow systems, and also to trust them to solve challenges in the scope of their stewardship. Most importantly, I want to continue to trust students to be capable of directing their own learning and shaping their community. Not every problem has to be solved by me. The beauty of an agile learning community is that we are learning together.
And maybe that answers my son’s question, too. If you know why you are building something, you will stop when it can do what you built it to do.
