Solutionism

Let’s say we can neatly divide the world into two groups: people who have problems and people who have solutions. Commerce happens because people who have solutions offer those solutions to the people with the appropriate problems.

There’s a matching problem. Not all problems have solutions. Not all solutions apply to any given problem. Just because you have a problem doesn’t mean it’s going to be solved. Just because you have a solution doesn’t mean it’s of any value.

There’s an interesting pathology that floats about that last point though. I call it "solutionism".

Being a problem solver is empowering

A lot of people spend their entire lives preparing to be the sort who offers solutions. In a lot of senses, that’s what a lot of the focus of education in the US is all about. You take a class to learn a skill which has—historically—been of use in generating solutions for folks.

There’s an empowering narrative sitting behind this. You learn a skill and then are, as a consequence, more valuable. People who learn particularly challenging skills or skills at particularly high levels are thought to have acquired the most value. There’s a pride to this, those who obtain excellence in the most difficult of skills presume that they have the capacity to offer the most valuable solutions to the biggest problems.

Generally, you can find places where this narrative is supported. For instance, a very skillful accountant can find numerous ways to offer their skills as solutions to problems in the operation of a business, a government, or even an individual’s life. A very skillful doctor can be employed at hospitals around the country or world, solving the problems of their patients.

In practice, skill is valuable when the "problem havers" have a very well-developed sense of their needs. There’s been a lot of work done to make the need concrete, transactional, well-scoped. The very fine question has been asked and is just in need of someone with the answer.

Field of Dreams was dead wrong

Solutionism is the stance that occurs when empowered solution-havers think that possession of a solution is enough. It’s the feeling of having a swiss army knife of answers and, subsequently, the hard-earned right to take over the world.

"If you build it they will come…"

It turns out that this is just plain false. It’s very exciting, very gratifying, but just plain false. If you build it "they" almost certainly will not come. In practice, even if they already have those very fine questions and a fantastic sense for their own needs, you’ve still only just begun when you offer the solution.

In so many interesting cases, the people who you can ultimately serve with your skills haven’t even begun to understand their needs, their problems.

Solutionism is the hubris of believing that the empowerment of skill earns you the right to successfully solve the problems of your clients. You’ve won the game of commerce because you brought the most interesting toys.

What-ing before how-ing

Above I made this all sound very grandiose, but it’s also something that plays out in nearly every plan ever made. Let’s say you want to build a boat.

Okay, so you’re going to need wood, and perhaps a workshop. Probably to employ someone with expertise in woodworking… and boats! Do we have to build the engine, too? Now this is feeling very overwhelming, but surely there are people out there with those skills as well?

Concrete ideas are easy. There’s a certain kind of anxiety that’s soothed by talking about them, getting tangible. And, to be clear, that’s all a good thing. Without getting real there’d never be any forward motion.

But we also didn’t even think about what kind of boat we wanted, or why we really wanted it. Maybe if we really got down to it all we even wanted was a toy boat. How often does the whole process of planning and getting excited get derailed by the hows of the situation before the whats are even understood?

"If I had asked people what they wanted, they would have said faster horses…"

Don’t listen to people talk about their faster horses, listen to them complain about getting to places slowly. About dealing with all the excrement.

Service

The opposite of solutionism, as a provider seeking to do commerce by solving people’s problems, is service. It’s the humbling work of asking someone what’s wrong… and listening. You make their needs the center of your universe. You toss out all your shiny toys and go in with a different sort of skill: empathy.

The key skills in listening are being vulnerable and asking questions. It sounds like I’m talking about being a good friend now, not "commerce", but it’s the same idea. Offering service to someone begins wherever they are.

So, perhaps we’d call this Problemism—the opposite approach.

Synthesis

If solutionism doesn’t work, does problemism? Well, no. Just knowing someone’s problems is not the same as resolving them.

If you come bearing only solutions then you will fail because you’ve presupposed too much and left so much of the burden of service on those you would seek to help. If you come only listening to problems, you’ll become a compatriot, but one without much to offer.

To maximize the chances of succes, you really want to approach from both sides at once. You want to be a really, really resourceful compatriot.

Imagine a vast, dark forest where on one side are all the hows and on the other all the whats and whys. Study of solutions, acquisiton of skills and experience, is the process of mapping out the forest starting from the hows. Empathetic understanding of the problems of people is building the map starting on the side of the whats. In such a twisted forest with so many false turns and dead ends, you’ll maximize your chances of crossing by having both of those maps and comparing notes.

The resourceful compatriot

To really solve people’s problems, focus on serving them. Get close, understand the need and respect it. But be resourceful, have many senses for how to make things better.

In the setting of a company, be aware of your assumptions and act to invalidate them. Be flexible to opportunities that may arise and create exposure and vulnerability so that they don’t pass by. But also be practiced and prepared and guide people’s sense of their problems toward the forest paths you know well.

Agile

Oh how I loathe the term: capital-A-Agile.

It’s a common refrain. Software is difficult, teams are tough, projects change, companies learn, clients don’t know what they want, nobody knows what they want.

Oh, but they do know that they want it in 6 weeks. What do you do?

The obvious thing was to write out a detailed 6 week plan which captured all of the needs of the project, minimized known risks, delivered confidence that the project would succeed, and delivered success at rates only slightly higher than chance.

Agile was a breath of fresh air which came mixed in with other revolutions like Extreme Programming and Cynefin. The Agile Manifesto was written and essentially told people to embrace uncertainty through practices which supported change. If the 4 lines of the Manifesto are too much, I’ve also enjoyed hearing it digested into “Prefer small, reversible decisions”. Perfect.

But now it’s all fashion and no passion, baby!

Or, more specifically, you can’t throw a stone in an engineering department without hitting someone talking about how you should convert all your team processes to Scrum. Or maybe you already did, but they’re telling you how you’re doing it wrong. There are enough stones for all flavors here.

They’re not wrong. Agile isn’t wrong. But it’s all oh-so-wrong. Scrum or Kanban (or 6σ) will never save you.

What it’s all about

Fundamentally, you’ll never make change by pushing process. You get leverage when you change principles, when you change values.

Practices and processes can be a mechanism for training a team, but the irony is that you have to be completely self-aware about that fact. If we’re going to pull a Wittgenstein and throw away the ladder we’ve climbed, then we need to be aware that the ladder is immaterial.

Let me be more concrete. If you’re a team lead or lead of leads and you want to teach your teams to be more agile, then you should have a plan in place Day 1 for when you teach people to abandon the very practices they’re learning.

Because what Agile is all about is agility and agility is all about deliberate, focused, optimized change.

Learning to change

I already linked my past post on reorientation above but let me do it again. Agile is about agility is about change. Change is painful and scary and difficult unless you own it and practice it.

Why do people “prefer small, reversible decisions”? Because they’re cheaper to change. That’s an adaptive behavior for people who practice change enough that they can live and thrive in dynamic environments. A team that really embodies is a whole different animal.

But if practices don’t make change, then what does?

In my opinion, practice does.

Next time you’ve got free time with your team (or yourself) consider spending that time running an intentionally chaotic project as opposed to cleaning up some tech debt (though that’s good too). Treat it as practice to work with an awful client who changes horses like they have a problem with funk. Maybe simulate that customer yourself.

Reflection and growth

And then for f’s sake do and get good at retrospection. Retrospectives are again a practice, so instead ask

How good are we at seeing ourselves for who we are, for how we are embedded in reality, and for understanding the gap between what happens and what we desire?

Are you good at listening to your own emotions? Your own intuition? Are you good at contextualizing and disregarding those admonitions if they don’t line up with the reality you desire? Is your team good at that? Do they know how to talk about this stuff?

And here I’ll say that sitting down regularly and making time for this—sure, call it a retro—is a smart, smart move. It takes time, it takes practice, and since retrospection is itself the engine of deliberate improvement… well it all gets very meta and very, very important.

Take two and call me in the morning

So here I contain multitudes. I’m very eager to get teams up and running on basic life- and work-improvement processes be they Scrum or Kanban or Whatever-Our-Internal-Bastardized-Agile-Process is. I’m also very eager to tear it all down and start fresh. Actually, even better, I’m very eager to set in motion the machine that will tear down every process you throw at it and start fresh. I’m very eager to ask that machine to go to work on itself.

And I’m very eager to understand, with an actual group of people living and sweating and practicing together, what kinds of behaviors and beliefs and emotions and 100% organic practices make (local) sense.

That’s what I think agility feels like. Now let’s chat about that project you need in 6 weeks.

Reorientation is key

Sometimes it can feel like it takes all the running in the world just to stay in place. Heraclitus says that the only constant thing is change, but “keeping up” is expensive.

It’s easy to consider this with respect to business or other organized endeavors. You might have a competitor who is working to upset your current flow. You might be trying to serve an audience which is itself changing.

On a personal axis, this can be a feeling of being adrift with respect to your goals (expressed or otherwise). It could be the root of feelings purposelessness or anxiety. Tangibly, it might even be the constant need to learn in order to keep on top of your profession.

The key to handling all of this change is the process of reorientation.

(more…)

A differentiable modeling language

Differentiable programming is getting a little exciting nowadays. The core idea is that you can build a language from the ground up that simultaneous supports both (a) computation of direct numerical results and (b) cheap, cheap computation of the derivative.

The most popular implementation of this idea is TensorFlow. TensorFlow is by most accounts a tool for constructing neural networks. The principal way you build a neural network is by designing its architecture as a series of interacting “layers” that compute a forward prediction based on input data and then you train that architecture through a process known as gradient descent—which essentially requires computing the derivative of the forward prediction over and over and over.

Before tools like TensorFlow you’d construct the equations for the NN architecture and its derivative by hand. This placed a significant constraint on both the accessibility of the technology and the complexity of architectures you’d reasonably want to explore. It’s a big, mostly mechanical, pain in the ass to compute these derivatives.

So TensorFlow creates a lot of leverage by just doing that for you automatically.

Where else do we want cheap derivatives?

TensorFlow today enjoys a bit of an underground role as being the premiere language for differentiable programming. While it’s geared toward construction of NN architectures, there’s nothing preventing you from writing other kinds of “tensor” programs and exploiting the same cheap derivative property.

Cheap derivatives are important in many other statistical and modeling applications. They’re the key technique for big hammer tools like convex optimization and Laplacian approximation. Many physical processes are specified as systems of differential equations where the interaction between derivatives and first order terms is key.

Is TensorFlow a good match for other domains that are further afield of neural network machine learning? Is there an opportunity for new kinds of differentiable programming languages?

I can imagine a differentiable modeling language that’s explicitly geared for designing models of physical processes. It’d need a good story for modularity as well as unit quantities and would plausibly want to compile to fast code both on the forward path and the (higher order?) derivative paths. Packaged in a tooling system that prints out traces of intermediate quantities and can run various optimization routines over the core model, this feels like it opens new doors for the process of building, refining, and using these sorts of models.

Managing a reading strategy

Reading list. Digital junk pile. List of tabs. One Tab. Pinboard. Goodreads. That stack of books on your bookshelf, kitchen table, living room table, in a series of 6 stacked boxes in your basement. Papers. Mendeley. That voice of residual guilt nagging you. Amazon wish list. Amazon Kindle library full of aspirations. Stacks of papers strewn about your desk.

Enough assorted guilt. If you’re like me then you already know what I’m talking about: the indefatigable list of things you’d like to read and learn, be inspired by, be challenged by, enjoy, take notes on, write a rebuttal to, mine for new things to read, etc.

I fancy myself a bit of a lifelong learner. Maybe even a researcher of various things that interest me. I’ll get on long binges where I chow down on everything I can think of related to functional reactive programming, stoic philosophy, management philosophy inspired by process flow and queueing theory, intuitionism, the history of the East India Trading Company, more emotionally-aware mentorship, and pointless topology.

These can be incredibly productive and seriously widen my worldview about a topic in a deep and enriching way. Or they can be a pile of anxiety and confusion, full of sound and fury, signifying nothing.

My suspicion is that I’m not alone in this.

It’s super frustrating! I collect these digital knick knacks and breadcrumb trails because at least at some point in my life I felt that this sort of experience is worth the time! Which mostly goes to show that I wildly undervalue and overestimate my time.

But that means that as these piles get deeper and wider that they start to be measured in missed opportunities. Some are opportunities which I’ve reasonably deprioritized, but others are still good, important ones that have just been lost to the waves of time.

I want to be better at creating, reviewing, and coordinating my reading strategy. By which I mean the intentional choice to invest this much time in this spread of topics because they’re right for whatever ends I’m holding on to.

I’m not very good at this. It’s expensive and challenging to even just get a sense for the places I could investigate. In the past I’ve collected huge lists and largely failed to keep up with them. Instead, I tend to be somewhat significantly at the mercy of what has come to mind recently or what’s persistent enough that I can’t ignore it. In these ways this isn’t even my strategy but instead my allergic reaction to the marketing strategies of these content creators.

Side note for the GTD crowd

There are lots of obvious connections from this pain to GTD, but I’ve personally found a lot of them to be failures so far. “Read what’s important to you” is a giant project with many hudreds of potential next actions which I’m continuously renegotiating. You certainly can use GTD to be a more present and dilligent researcher, but when I say reading strategy I mean something slightly different. In GTD terms, I want to become structured in how I plan and consider this entire “research” project.

So how do you manage your reading strategy?

I know I’m not very good at it, but maybe you are. Maybe there are whole different approaches to this which help the amateur researcher to get really in sync with their interests. Or maybe it’s just honestly a pretty difficult thing to get just right.

I’m planning on writing a few more posts exploring this pain and what’s worked and not worked for me. Ultimately, it’s a problem I’d like to find a decent solution to.