It’s hard to deny the truth that for a lot of us “difficult” means “good,” and “more difficult” is “even better.” From video games to exercise to music to cooking, if someone accomplishes something perceived as hard to do, it’s a clear indication of their skill. Conversely, saying something is easy or simple is often a veiled insult, an insinuation that anyone could do it and therefore the thing is therefore barely worth acknowledging.

And, while I don’t want to discount the system upon which so much of our leisure activities are based, I think this is a lesson we in IT have taken too much to heart. I’m writing today to ask us to all consider shifting our thinking in the direction of “easy can also be good.” In fact, things which are easy are often better overall than things that require a greater level of individual virtuosity.

Meals that are simple to make yet still come out tasting delicious are a delight on many levels. Music that is easy to play but rich in themes can be profoundly moving. Backyard football matches might not make the sports segment on national TV news, but nevertheless, they shine brightly on the highlight reel of our memories.

But it’s more than that. In tech terms, difficulty and complexity often mean friction, an unwelcome hurdle for the end user to overcome before achieving their goal, exploring their environment, or solving their immediate issue.

Making a solution less complex isn’t “dumbing it down;” it’s making it more accessible. It enables users to complete tasks and solve problems on their own with minimal assistance. It enables those same users to teach others how to do the same. When individuals and organizations experience that kind of quick success, it highlights the value of our solution.

And that leads me to the main question of this essay: When we create features and solutions, who is the primary persona we envision using these tools?

Typically, successful software creators start with a single target audience in mind. Certainly that was true at New Relic, a company built for (and largely by) developers and DevOps practitioners. We speak primarily to “people who look like us” (i.e., working in the dev space), providing solutions to things that we ourselves see as key problems. But that doesn’t mean we shouldn’t push ourselves to see beyond that segment to other groups.

To explain what I mean and who I’m talking about, I need to engage you in a little bit of a logic puzzle: Two people fall down a chimney. One emerges with a dirty face and the other with a clean face. Which one washes their face?

If you are a reasonable person, you’re probably thinking, “The one with the dirty face.” But there is another way to answer the question. Logically, the person with the dirty face looks at the person with a clean face and thinks their face is clean, too, and so they don’t wash. Conversely, the person with a clean face looks at the one with a dirty face, assumes their face is also dirty, and thus is the one who washes.

What’s this got to do with software creators and the solutions we build?

Imagine we have two developers who fall down an application stack or, more precisely, are dealing with an application that’s fallen down. One of the devs is “dirty” —  skilled, experienced, and knowledgeable; able to investigate the application using native commands, home-grown techniques, and hard-won know-how. The other is “clean”  —  a relative novice.

Which one uses a tool  to observe, navigate, and explore the situation?

Many companies operate under the presumption that the dev with the dirty face will appreciate our tools. These sophisticated folks have the experience and acumen to appreciate all the rich features and capabilities we’ve jammed into our solution. And this is often true. As the cool kids say, “Game recognize game.”

But in making that presumption, we miss the power of reaching out to the dev with the clean face. Seeing how the "dirty dev" is able to quickly, albeit manually, navigate the application stack and zero in on the issue, the "clean dev" wants to do the same. However, they can’t. As they sit in the midst of a bug hunt, there’s no way for them to magically become more experienced. Nevertheless, they yearn for something that would at least give them a leg up.

The toolmaker should be their leg up. In some circles, the term for this is a “force multiplier,” a tool or technique that helps a group accomplish more, often by an order of magnitude, than their numbers or skills would normally allow.

Tying this back to the start of this essay, simplifying our tools so screens are easier to navigate, workflows are more clearly laid out, and relative newbies can quickly instrument and use new data ingests runs very little risk of diminishing our perceived worth or skill in the eyes of experienced developers. But doing so has a very strong likelihood of enabling less-skilled IT professionals to get meaningful data more quickly and, therefore, allowing their capabilities can grow along with their skills, experience, and needs.

It also means making it easier to experience the tool without friction — providing a robust free tier, offering your solution to students just learning the ropes, and even offering your solution at no charge to organizations that are demonstrably working to make the world a better place.

“A 10x engineer isn’t one person who does 10x the work or does the work 10x better. It’s a person who can inspire and teach 10 other people to be just as good as they are.”
Yechiel Kalmenson

Meanwhile, the experienced developers will see how the solution lifts up the more-junior members of their team. Real leaders in tech don’t gatekeep because they know there’s more work than hands. Instead, they look for ways to bring others up to speed quicker. If a tool helps that happen, they’ll naturally encourage others to jump in and get their hands  —  and faces — dirty too.