Oh hush, the title is just for fun.

I am happy to write this post as it crystallizes the approach I take to problem solving; an approach that until recently I had trouble expressing. To bring the approach into clearer relief we can take a hypothetical project example: updating a product support website.

Their Approach

The standard approach is to first assign a team to the project: a project manager, someone in charge of strategy, a client-facing manager, designers and UX reviewers, perhaps a data analyst and maybe a web engineer.

Next a framework of some kind is applied. Perhaps there are five phases, most of them sequential, each depending on the completion of some prior step. The phases in turn have many sub-steps to be completed. Team assignments are made as to who will do what. The project manager is certain to require status checks and keep track of logged hours.

The phased approach is sure to contain a structured research component, the creation of personas, a stage involving a careful UX audit, long discussions with the client about KPIs and getting really specific about their needs. An initial presentation of the phases will be made as well as follow-on presentations about how each of the sub-processes are progressing.

The approach aims to present a carefully crafted final product by moving slowly one step at a time in progression. The project phases, structure, and path are more or less laid out from the beginning. This is the approach everyone seems to take. It is taught in business schools. Questions are asked about it in interviews (“Tell me the approach you would take to solve this problem. What steps are needed?”). It is often encouraged by the client (because, after all, many of them went to business school). But it is a process I deplore. To say it does not come naturally to me is like saying flying does not come naturally to a fish.

My Approach

Instead of aiming to minimize errors by completing the project once carefully, I aim to minimize errors by completing the project quickly multiple times. Each time I learn from my mistakes and find out what is missing, gradually inducing structure as I continue to iterate. The word “stochastic” in the title wasn’t purely a flourish, it describes where I begin: anywhere I like; nor is the term “interrogative,” which describes in my process the act of putting on “the client hat” after each iteration and integrating myself about what is missing from the final output.

So how does it work?

The first step is to reduce the project down to the lowest number of dimensions, its essence. For the project above the assignment might be to “make the support site better and give me some wire frames.” And for my process that’s all the direction I need. What “better” means in practice isn’t so important at this stage, it will become apparent over time. Nor is a defined scope of work necessary, which I personally care little about. The scope becomes whatever I determine it to be as I iterate.

Next I pick a random place to start research. This might be to start looking at competitor sites, it might be reading about UX best practices, it might be examining academic articles in a business journal. Again, the starting point is stochastic. I simply start at whatever entry point seems exciting and relevant. I do some research for a while and if I don’t find anything or get tired of research I quit and start a new research thread. I take mental notes, begin inducing an organizational structure for the data I find and final client recommendations, and start thinking about what a wireframe might look like. I take screenshots and write down notes.

Then after some amount of research, whatever feels right (but in the case above probably a few days), I start to create a wireframe. I produce it as if I’m giving it to the client. As I create it my mind is filled with questions. Is addition X of the wireframe really needed? Why did I add it in the first place? What quantitative piece of data would support adding it? Can I get that data myself or does the client have that data? What if the data turns out to oppose my intuition? This begins the stage of interrogation as I aim to create a first draft product that withstands client review. As I play the role of the client I interrogate the output (the wireframe in this case). Can I truthfully say I did all the research I could in area Y to justify the removal of something currently on the support site? What are some of the themes that various aspects of the research fall under that would unify my approach? What KPIs would making these changes really drive? Do my changes work for all users or just a subset?

As my self-interrogation begins to make my output crumple and I begin to take notes about where it needs to be shored up, how I can shore it up, where I need to do more research, different conclusions I would draw depending on what various data look like, and so on. I have a list of things to tackle. What do I do? I start over. I pick a random item on the list that excites me. I again research, this time in more depth or in areas I know I’ve missed. I take new notes. A new picture is formed in my head. It’s not completely new, but rather a more robust and complete version. I remake the wireframe and re-interrogate myself. I continue the process until I have an answer for every question I can think of, until I pass my self-interrogation. Along the way I will have induced everything I need about how to structure the various aspects of the final deliverable and recommendations.

The Good and the Bad

My process is iconoclastic because I’m naturally a contrarian. I despise standard processes and opinions for no other reason than they are standard. I think it’s better to be interesting than right in almost all cases.

The process I just described did not arise from intention. It’s just the path I take naturally. My mind cannot wrap its head around what needs to be done a priori or how to do it without jumping in with two feet. Nor am I necessarily convinced I’m doing something new. The process I use is somewhat akin to rapid prototyping and has analogies to stochastic computer science optimization algorithms.

In a lot of ways I admire and am jealous of those that can clearly see the path set out before them and create the structured, phased, carefully crafted plan. But that’s not me. I used to want to imitate them, but I’m not sure I ever can. Perhaps it’s better to carve out a small space for myself using my off-beat approach.

My approach has some drawbacks of course. First, it takes a certain personality type (like mine) that combines intelligence, creativity, and impatience. To the outsider it seems as though I’ve skipped something, played fast and loose in an environment that demands caution and foresight.

Second, it’s almost impossible to use this process in a team setting. It creates a small space for a sole endeavor, which is why it doesn’t scale well. Medium-sized projects of the type I described are about as big as you can go (though often large tasks have small components which can utilize this process).

It can also be inefficient. Having to induce a new framework every time you start a project is perhaps not the most efficient way of doing things. Nor is stopping midway through a research thread and starting a new one simply because you were bored. There are very real switching costs to stopping your current task and starting a new one, only to later have to reorient yourself to the old task once interrogation is complete and you remember there are holes in your original research. And yes, you can miss things.

Because it has its own type of inefficiency my process benefits from soft deadlines. The process has no clear completion date, it’s done when you pass the self-interrogation and that can sometimes take longer than desired, so ultimatums like “Get this done by June 3rd” create artificial cycles and derail the process’s freedom.

Because it is less structured it can be hard to give status during the phase in-between draft outputs. Project managers are sure to hate it. In the standard approach we must all be comfortable all of the time, at the first sign of discomfort or ambiguity the project manager swoops in. We have to find out who is doing what, when they will be done, what resources they need, what the dependencies are, a list of next steps, ad infinitum.

But my process also has its benefits.

Just as surely as it is inefficient in certain respects, it is very efficient in others. It allows a single individual to do the work of many. In fact, it demands it. It takes a single individual with diverse thoughts crashing together in their head for the process to be truly effective.

As much as it seems unfocused from the outside, it is hyper-focused from the inside. It does everything at once — the UX audit, the data research, the competitive analysis. And as the one executing it, my mind is always on. I can work harder and longer than most people because the diversity of the approach allows me to stay fresh and hungry. I quickly begin to see the various strands of research combining in my mind and forming a unified story. I begin to see structure and patterns, which in turn combine with whatever new (or old) ideas I’ve encountered in podcasts, books, journal articles, interviews, movies, and conversations with friends; the approach has strong returns to analogy and rewards the combination of disparate thoughts and disciplines.

I’m bounded by no constraints and so can think more creatively and quickly than the alternative, structured path. The phrase “make the support site better and give me some wire frames” is enough direction because the process will figure out the details as it moves along. In this way it’s better at handling ambiguity.

My approach also better abides by Sister Corita Kent’s advice: “Do not try to create and analyze at the same time. They are different process.” The alternative approach fails in this respect because its goal is to simultaneously analyze the problem and create a path toward solution with predefined guardrails long before true creation has ever begun.

Because I don’t have to worry about process, I save up-front planning time. Because I work alone I save time on meetings and coordination. I get to a first draft product quickly, but one that is already coherent and rich with ideas; some of them are wild and may get culled out in later revisions. I can share these early versions with the client, and they are pleased with my progress. I can archive the wild ideas I’ve culled and present them coherently at the end of the project under the heading “Thinking Radically.” I go down dead-end research paths, yes; but so does the alternative approach. I get to fail quickly many times; the alternative approach can hardly afford to fail at all. And because I don’t start out with a pre-defined structure I induce only what I feel is essential rather than letting standard, business school-style frameworks dictate my path and thinking.

Just One Last Thing

Many will still view my process illegitimate, the ex-post justification of a hyperactive manic. I disagree, of course. They say that writing is thinking and I think articulating the process clearly here will only sharpen my skills at it.

The next step is to try to integrate my way of doing things into the standard business practices of my current employer. I will report back.

The following is an excerpt from my longer piece on Zambia:

Start with Zambia’s geography, which is not conducive to agriculture in the first place. Next, add in nshima as the stable food and subsistence farming as its primary source. What you get are livelihoods dependent in large part on the labor-intensive cultivation of maize, a cultivation exposed to the hardship of wildlife, weather, and vandals.

Low yields and hard work mean kids go to school tired and hungry and have little free time for homework. Instead, they clean the house, maintain the crops or livestock, or fetch water. By the time they get done with chores in the evening it is often too dark to study and electricity is still a luxury few can afford. At any rate, children have few incentives for investments in their own human capital through education — the only thing they know that exists for certain is what they have seen in their village. Schools could reorient them in theory, but in practice Zambian education has a long way to go.

For various reasons teachers may not show up to teach or may teach only half the day. If they happen to be dedicated, teachers must cope with classes that are too large and a severe lack of study materials. This often extends to an undersupply of even pencils and notebooks. Foreigners fund computer labs in schools with inadequate electricity to power them and no teachers knowledgably enough to maintain them. Young girls may not be able to find or afford feminine hygiene products and so are embarrassed to go to school during their period, possibly losing a week of education per month and maintaining the societal gender gap.

Unfortunately, government polices have too often only compounded the problem. Because it is poor, tax revenue in Zambia remains low. Infrastructure in the country is underdeveloped so domestic trade remains expensive. This keeps costs of necessities like fertilizer high, diminishing vital income for farmers. Healthcare remains a problem and this too the government struggles to provide. Low income in rural areas means the private sector has little incentive to invest in for-profit hospitals or other critical services.

The government has decided hunger is a problem in the nation so it has restricted maize exports, unintentionally limiting a key avenue to economic activity for farmers. Instead, it subsidies maize production; first, by offering maize seeds and fertilizer at reduced cost, and then by buying surplus maize from farmers at above market price. To compound the problem it has mismanaged the maize reserves it collects, in one case letting tens of thousands of tons rot in a state warehouse. On the whole, these policies lead to an oversupply of maize and discourage crop diversification. Families remain reliant on maize and so rural residents tend to vote into power those who will continue to subsidize its production. Maize is indeed a political crop.

Those educated or wealthy enough to escape usually do, moving to cities like Lusaka or Chabata or leaving Zambia altogether. Those who remain are mired in a poverty trap where education remains second to cultivating enough maize to survive, and where low income in turn leads to low government revenues, further inducing a lack of government services and infrastructure, reinforcing the trap.

This is to say nothing of culture, or laws, or colonial and tribal history, or national leadership, or domestic and international politics, or myriad of other factors that, along with those mentioned above, have contributed to the state in which Zambia finds itself.

Though they are mostly ideologically opposed, both William Easterly and Jeffery Sachs are concerned with this problem. Easterly wrote about “increasing returns” to skilled labor in his book The Elusive Quest for Growth. In it he posited that “brain drain” is partly a result of skilled workers’ desire to be around other skilled workers. When workers coalesce, skills are used more effectively and creatively and lead to higher incomes. This is similar to the O-Ring model. Sachs has helped start the Millennium Villages project, which basically aims to give small rural villages everything they need all at once (education, health, clean water, food, etc.). To be sure the challenges of development are great, which is the reason the area is so intellectually rich.