I was charmed and captivated by this post, called “You Are Solving the Wrong Problem.”
In the late 1950s, a British industrialist proposed a contest, inviting folks to build an airplane powered entirely by human effort. Many groups vied for the prize, spending months on complicated designs, only to have them fail spectacularly during actual testing.
Finally, after almost 20 years of failed solutions, a man named Paul MacCready pulled it off, building what would come to be known as the Gossamer Condor and the Gossamer Albatross. How did he do it? He realized that the problem was the problem:
Paul realized that what needed to be solved was not, in fact, human powered flight. That was a red herring. The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges. He came up with a new problem that he set out to solve: how can you build a plane that could be rebuilt in hours not months. And he did. He built a plane with Mylar, aluminum tubing, and wire.
The first airplane didn’t work. It was too flimsy. But, because the problem he set out to solve was creating a plane he could fix in hours, he was able to quickly iterate. Sometimes he would fly three or four different planes in a single day. The rebuild, retest, relearn cycle went from months and years to hours and days.
Robert and I were talking about this last night, and he was telling me about agile software development. Read the link for more, but here’s a pertinent bit:
Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle… This minimizes overall risk and allows the project to adapt to changes quickly.
What’s striking is that this story of Paul MacCready and the Gossamer aircraft came to me after a session meeting in which our elders figured this out intuitively: the problem was the problem as we’d (or I’d) defined it.
I inherited a committee structure at Tiny Church that is organized into 11 committees, headed by elders. As you can imagine, some of these function well as committees, some are committees of one person, and some are basically dormant. Some of these areas have huge, constant responsibilities; others are seasonal or sporadic. Add to that the complication of only 6 elders and 11 committees—that’s a lot of different hats. Not to mention the fact that people want opportunities to do ministry, but they don’t join a church to serve on a committee. (Especially when there’s a perception that once you’re on it, you’re on it forever.)
So I’ve felt for some time that a reorganization was necessary, but I was stumped how to slice and dice it. I polled friends, posted queries on Facebook, you name it. Do we organize by elements of our mission statement? Form sub-groups on session? Consolidate several committees?
I brought all of this to session last night and expected we’d do some general discussion and, at least, get the different roles and options on the table, but that it would take several months to come up with a new structure. But we ended up with a specific way forward. We’ve got our structure, and it’s an agile one. We began our Gossamer Condor.
In essence, the session will no longer staff committees. (Yippee!) In fact, at this point at least, we do not even have specific elder areas of responsibility. Instead, each month we will look at the calendar of upcoming ministry events at the church, as well as emerging opportunities that come up, and determine how those items can be best implemented: invite a specific person to make it happen? Oversee the formation of a short-term task group, with the elder serving as liaison?
Thus, in addition to being the visionary/spiritual leadership of the congregation, the session will be “dispatchers” of a sort—matching ministry opportunities with particular people with the gifts and availability to implement them at a particular moment in time.
We solved the right problem. Our problem isn’t finding the most appropriate structure for our session. Our problem is how to get the church’s ministry done.
What excited me is how can-do the session seemed to be at this approach. And this excitement was present in spite of the fact that we know problems will arise. If we’d spent months developing The Perfect Structure, those problems could be seen as a threat to all our hard work and easily ignored. But with an agile process, problems are essential information—necessary parts of making our processes better. With an agile process, we will be constantly evaluating and tweaking.
I’ll be sure to let you know how she flies.