I have often heard developers, and others working IT, say that they don’t want to have understand how the end user will be using the tool or technology they are creating. These developers will often resist learning to talk about their client/customer’s problem the same way the user’s do.

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

The Importance of Understanding

To do our best work we need to understand the end goal of our users. We need to really understand 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 specific users. In my role inside a nonprofit energy company I am making sure our Salesforce org meets our specific 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 to do that I need to understand their work.

The Words We Use Matter

To be understood by other people we need to use words they understand. We all know that, yet some how we don’t all do it consistently. Yes, we need them to use words we understand too, but in my experience that goes best when make every effort to truly understand their work.

In my current role, I need to understand the energy industry. I don’t need to understand every detail and nuance – but I need a working understanding of the terms, what the data points mean, how my colleagues talk the work, and other similar things. In the last few months I’ve needed to learn a lot to do this job.

There are bounds of what’s required to be effective. I don’t need to know it all, just enough. For example:

  • I need to understand every word of the software agreements and service contracts I sign or recommend others sign.
  • I need to understand that my employer enters into long-term power purchase agreements, but I do not need to understand the language of those contracts or how to time to market to be most effective.

Problems with Failure to Understand

I’ve worked in several settings where technical people just wanted to focus on the technology, not the use of technology. They say things like: “I don’t care what they do, as long as the spec is correct I can build it.” and “Why do I need to understand their business as long as I process their data right?” Those people did second rate work – more or less to the person.

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

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 expected to 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 (other than 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 and used the right tools to control their location.

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

There is an ethics issue embedded here as well. 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. A complete discussion of the ethics of technology is impossible here; it’s a whole field of thought within Philosophy.

But 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 announcing they are comfortable supporting outcomes they consider evil.

When is it Enough?

Probably never.

Those things I listed above as things I don’t need to understand, I will probably try to understand one day cause I’m curious about them.

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

  • International Peace and Conflict Resolution
  • The US federal budget
  • Private prisons
  • Economic empowerment of women in Africa
  • Lobbying at the federal and state levels
  • Youth empowerment in the US and other parts of the world
  • Explaining quakerism
  • Phone system setup and operation
  • Web development
  • Web site infrastructure
  • General nonprofit fundraising techniques and strategies
  • The child welfare system in several US states
  • Life guarding and water safety
  • Natural disaster planning and response
  • Sales of kayaks, canoes, and other related products
  • Advanced and basic marketing strategies
  • Chemical coatings for packaging
  • 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 20 years 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.

On the one hand, 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.