Why you should teach your non-engineering team members to code

Many companies spend time teaching their engineering staff about the business strategies behind the products and features they’re developing. Although engineers aren’t responsible for product marketing or for developing a business rationale, they can often use their understanding of the business and its core products to make helpful suggestions during the development process.

But how often does this happen the other way around?

While it’s probably not necessary (or desirable) for non-engineering staff to provide feedback or advice about programming, it would be nice if they understood how the company’s products are built. It would also be nice if non-engineering staff could understand why one project takes eight hours of work while another projects takes multiple sprints.

You could provide your staff with a high-level training about the software development process. You could teach them about Agile methodologies, about debugging, and about how engineers tackle the tickets they submit.

If you’re going to invest time in high-level training, why not take it a step further and teach your staff the principles of programming and development?

It’s fun.

This isn’t about turning a content marketer into a senior developer. It’s about giving your staff hands-on experience in a low-risk environment so that they can really learn what the engineers at your company do.

Let them shadow an engineer for a day. Host a full-day hackathon and get your non-engineering staff involved. Host a 101-level “bootcamp” for a few days and encourage your staff to learn something new. At worst, they make something cool and they say it was fun. At best, they walk away with a deeper understanding of what engineers actually do, and they use what they’ve learned to improve their current way of work.

It helps them understand how the company’s products are created.

Product managers focus on the business strategy behind the creation of new products and features. UI and UX designers create mockups long before a project goes into development. Project managers go through a release checklist to ensure that everything is progressing as planned.

And then: engineering limitations surface mid-development.

Product managers are disappointed that a feature can’t easily be implemented. UI/UX designers are disappointed that the project, which is now in staging, doesn’t look exactly like what they designed. The sales team is wondering whether this particular engineering limitation has a workaround. Clients are waiting.

When non-engineering staff understand how things are programmed and built, they can anticipate engineering limitations in advance. Long story short -- it saves time.

Imagine that someone designs a feature that would take a multi-disciplinary team of six engineers multiple sprints to build, instead of the single sprint that has been allocated. Now imagine that the person designing this product had at least some understanding of the development process and of the company’s core technologies.

It creates a sense of camaraderie.

The role of the engineer is often a mysterious one in the eyes of non-developers. Teaching non-engineering staff how to code is an easy way to begin establishing camaraderie in the workplace.

We want the marketing team to celebrate the success of the engineering team, just as we want the engineering team to celebrate the success of the sales team. We want people to understand what really happens when a platform is down and engineers can’t access it. We want the whole company to laugh about “git blame” jokes. We want everyone to experience a hackathon -- not just engineers.

If engineers and non-engineers start going to lunch together and collaborating to improve the company’s products… consider it a bonus.

People rarely regret learning new things.

Teaching non-engineering staff how to code gets them more involved with the company’s process, but it can also be personally and professionally enriching. You might even spark an interest in something new (at my company, three non-developers ended up making a chatbot after working with a few engineers during a hackathon).

Since people rarely regret learning new things, and since having an engineering background can only be an asset to the company as a whole, why not give your staff the opportunity to learn?

By setting some time aside and by making an investment in hands-on training, you’ll likely get more than you bargained for.

Does your company teach non-engineers how to code? How has it worked out? Let us know in the comments!