I’ve worked in several settings where technical people announced their focus was on the technology, not the user of the technology. They would say things like: “I don’t care what they do, I just want to build it.”

This is a terrible way to work. It leads to bad solutions and miscommunication.

You cannot find the flaws in the spec, and there are always flaws, if you cannot sanity check it yourself. You cannot know for sure your solution worked if you don’t know what the data means and how it is used.

The Importance of Understanding

When my wife and I attended the Polo match pictured above we tried to ask some of the regulars basic questions about what was happening. They responded to us using all the words of the sport, but not in a way we could understand. If they wanted to attract new fans to the sport, they needed to explain the game to us in words we understood. It got even worse when a horse got injured and no one really explained what was happening until the ambulance trailer pulled onto the field.

To do our best work we need to understand the end goal of our users. The most effective way I know to communicate clearly is to use the same language as my audience does when talking about their work. If you try to force them to use the terms and phrases you know best they will likely make mistakes that cause you problems.

We must meet our audiences where they are.

When I was a Drupal developer, I was creating web sites that were customized to a specific organization’s needs. When I was a Salesforce consultant and developer, I was tailoring the platform to handle the specific needs of those users. In my role inside a nonprofit energy company I am making sure our Salesforce org meets our needs.

What was common across all those roles is that I needed (and still need) to talk with my users and understand their needs and the work they need the tool to do for them.

Problems with Failure to Understand

When I was a web developer, often the spec I was working to support was a graphic design. The designers would create a very attractive design, the client would approve it, and I was told to go implement it. Drupal, of course, can be implemented many different ways. To create a good implementation I needed to understand the designer’s intent and why the client liked the design (beyond it being pretty). I would ask why images were placed where they were, not to challenge the design but to make sure I called them the right thing in the backend. Those names were important to the content editors to help them select the right image in the future.

Working with Salesforce brings the same challenges. To understand if a Flow is working right, or even worth building at all, I need to know what the user expects to happen and why. When organizing a page layout, I need to know which information is most important and what fields are related to group them sensibly.

A Quick Note About Ethics

A complete discussion of the ethics of technology is impossible here; it’s a whole field of thought within Philosophy. Still we all should care how our work impacts the world. If I create a tools that’s helping someone commit evil, I’m supporting that evil. There is a mountain of nuance and detail to be thought through.

Just because the topic is huge and complicated does not free us from the basic responsibility to care about it. When someone tells me they don’t care how the technology is used, they are implicitly announcing they are comfortable supporting outcomes they consider evil.

When Do I Know Enough?

Probably never.

Over the course of my career so far I have worked on projects that involved:

  • International peace and conflict resolution efforts
  • The US federal budget
  • Private prisons
  • Economic empowerment of women in Africa
  • Lobbying at the federal and state levels
  • The DNS system
  • Youth empowerment in the US and other parts of the world
  • Explaining Quakerism
  • Phone system setup and operation
  • Desktop computer and server hardware
  • Web development
  • Web site infrastructure
  • Virtual machines
  • Open source licenses
  • Copyright (copyleft) and trademarks
  • General nonprofit fundraising techniques and strategies
  • Basic accounting practices
  • The child welfare system in several US states
  • Life guarding and water safety
  • Natural disaster planning and response
  • Rules for credit card processing and security
  • Sales of kayaks, canoes, and other related products
  • Advanced and basic marketing strategies
  • Chemical coatings for packaging
  • The US sales tax “system”
  • The energy industry in California and generally around the US
  • …and probably a bunch of other stuff I’m not thinking to include

While that might be a little more than is average in just over 25 years of professional life it’s probably not all that high for someone with a similar career track. If you’ve been working for a few years, think about all the different things you have had to work on – it’s a bigger list than you’ll expect.

All of that learning can be exhausting; I understand the temptation to say “I know enough, I don’t need to know more.” But if I want to keep getting chances to advance, I need to be ready to understand the next thing I need to know.

It helps to be curious.