Software development teams draw from three disciplines:

• Engineering
• Design
• Product

Whether nonprofits know it or not, they draw from these, too. Here’s a quick summary of those disciplines and some ways they influence nonprofit work.

Engineering

Engineering may be the most apparent aspect of building software. You might picture Jesse Eisenberg in The Social Network wearing a hoodie and flip-flops, but developers have come a long way since then.

They wear Maverick Sheepskin Rancher Coats now.

Need a website to load in less than a second from anywhere in the world? Done. Need to store 10 million rows of data in a database? Check. Need to process donations in multiple currencies? No problem.

Engineers are technical. 

They sweat the details. (Especially in sheepskin!) 

They make incredible things possible.

With all due respect to their technical prowess, engineers only represent a third of the disciplines required to build excellent products. 

Engineers are the best in the world at telling you how to build something. But to know what you should create, you need a designer. 

Design

When I started in software, I wrongly thought that designers created logos and brand guidelines. Those are graphic designers. (A sub-species of designer.)

True designers create experiences and stretch far beyond software. They imagine a world where every car has cupholders and keys can be organized on key rings, and doors don’t just have to open and shut, they can revolve. 

Last time I walked through a revolving door, my six-year-old paused as we entered and said, “I love these.”

That’s world-class design. A door that is always open and always closed.  

The designer of the revolving door probably needed engineers to select the materials for the torque-limiting mechanism. But, without his design, we’d be opening and closing doors the old-fashioned way.

Designers don't merely think about how things look, but how they feel and are experienced.

If engineers answer the “how” and designers answer the “what,” product owners answer the “why.”

Product

Product owners are the easiest to take for granted. Unable to sketch brilliant ideas out of thin air or bend the laws of physics to achieve scale, they listen to people–customers, management, engineers, and designers (collectively called stakeholders)–and then try to give people what they want. 

And it’s brutally hard.

Because people disagree! And struggle to articulate what they want.

The people you serve may want one thing but management wants something else. The product owner has to carry the vision and the purpose through every tradeoff, design choice, and engineering decision. 

It’s a heavy burden, and they are easily scapegoated. But the product owners who get it right make the right tradeoffs that benefit everyone. 

The more hats, the better

Most teams have more than three people and have a variety of roles. These disciplines are better thought of as a spectrum with strengths and weaknesses. The more versatile people are, the better positioned they are to build solutions in the complex world we inhabit. 

The best product owners can sketch great designs.

The best engineers are great listeners in stakeholder meetings.

The best designers know how to code.

If you are thinking, “But, I’m already wearing a million hats, and now I have to add three more?!”, I promise these hats are good ones.

If you care about people, you care about their problems. If you care about their problems, you’ll learn whatever you need to know to solve them.

The only essential ingredient: 

You care.

When you care, the on-ramp to these disciplines is an escalator.

Earlier this week, I received a text from an executive director with a link to a custom CRM app he built using lovable.dev.

He is 0% technical but wanted to create a better way to stay in touch with his loved ones.

With a little grit and a lot of love, we can all be engineers.

Why this matters for nonprofits

Whether you intentionally develop these disciplines or not, they are present in your work. 

The people you serve will experience your program, and they will judge its quality based on how it compares to other experiences. 

You must create an experience that works (engineering).

You must create an experience that solves a problem (design).

You must create an experience that people actually want (product).

Your reputation will depend on how those people experience your nonprofit.

Whether that’s:

• On your website
• In the emails you send
• In the payment options you provide
• In the questions you ask in the follow-up survey
• On whether or not you write a thank you note (and remember their name) (and care)

These principles are not merely vital because they help us create better experiences.

They’re essential because this is how we demonstrate empathy to everyone we interact with. 

At our best, we send a subliminal message in every interaction:

This experience is our gift to you, and it works because of how deeply we care.

The best products in the world are the ones that understand and care about the people they help.

Nonprofit folks may not come from any of these disciplines, but they are pros at caring.

And there’s no hat for that. 

Just heart.

Until next time,

Ted

PS: I work hard on these emails because I care about you. Thanks for reading.