No-code tools vs. engineering teams: Avoid conflict and ship faster

Historically, organizations have had a single design, development, and build pipeline for their software needs. Engineering has owned much of this and has a well honed set of processes and playbooks that help reliably deliver stable software at scale.

Unit tests, staging environments, schema management, code review and documentation are just some of the components of modern software engineering that have allowed organizations to quickly scale their development capabilities.

But things are shifting. The emergence of no and low-code tools such as Zapier, Retool and Airtable are creating new opportunities for organizations to empower non-engineers to develop and build software for the first time. This has some enormous benefits:

• Highly Efficient
  No Code / Low Code empowers team members to build software for which they are the end customer. This can be incredibly efficient, as the builder fulfills the role of “designer”, “engineer” and “product manager” and–arguably–knows best what they need. The creator can dog-food their own software and make changes in near real-time. Magic!
  
• Purpose Built
  It enables builders to create specific solutions that otherwise would not come to life. For example, it’s unlikely that the engineering team will have time to build the legal team a custom workflow tool to manage purchase order approval, but with no-code this is completely possible and within reach.
  
• Saves Engineering Time For Harder Problems
  It allows the engineering team to focus on higher leverage tasks. Instead of spending time building custom tooling for internal teams, they can focus on higher impact or more technically challenging work.
  
• Empowers Your Team
  It increases employee engagement and satisfaction. Using software to redesign your role as you perform it delivers enormous compounding value. Over time, teams can perfect and automate much of the manual tasks they do and increase their impact, learn new skills and accelerate their careers in the process. Everyone wins.

So what’s stopping everyone from rushing to give their teams the power to create software and experiences? Let’s dive in.

The engineering hesitation

Engineering has a well honed process for a reason. When a core system goes down at 2am, it’s the on-call engineer that gets PagerDuty notification to wake up and fix it. When customers can’t checkout for 2 hours during a holiday season, it’s engineering that has to explain to the leadership team what happened and run a post-mortem. 

The idea that anyone in the organization can create software–expanding the risk surface area for the engineering team–is an understandably scary one. Imagine telling the legal team that anyone can write their own contracts 👻. 

There is, however, a path forward. 

The Path Forward - build buy-in early and collaborate

The owners of the no-code/low-code initiative at your organization should aim to build buy-in with stakeholders early in the process. That means talking to key stakeholders from engineering, data and (sometimes) design early in order to be clear about the goals, parameters and process for the no-code project. 

Here are some of the things you may want to cover : 

• Decide what makes a project right (or not) for no-code
  Getting clear about the “safe space” for internal tools will help give everyone peace of mind. Stakeholders may be happy to have teams build tools that are not-user facing, or don’t touch PII or other sensitive data. Deciding what is off-limits or requires further approval will help alleviate concerns massively.
  
• Define the process for tool selection
  Getting tool selection right can save huge downstream discomfort. Engineering and data teams are going to want to make sure that new additions to the stack are compliant and easy to integrate with existing tools. Defining a lightweight process for tooling sign-off can be a game changer.
• ‍Commit to invest in documentation
  All too often, no-code solutions are poorly documented or misunderstood outside of their creators. Instilling a culture of documentation early is critical to ensure durability of no-code solutions. Loom videos in a centralized Notion/Coda or Confluence space can be a great way to ensure longevity of no-code tools, especially when team members leave the organization. Capturing institutional knowledge helps ensure the long term health of your no-code tooling solutions.‍
• Define a monitoring strategy
  All software fails from time to time. With no-code, because there are often multiple systems in play, failures can be silent or hard to detect. Quick detection of and visibility into common issues such as API auth failure, schema changes, or read/write errors is critical. Sadly, this is challenging with no-code and is one of the main reasons why organizations may be hesitant to put mission critical systems onto no-code infrastructure that lacks error reporting.‍
• Discuss and plan for “no-code in-housing”
  There will be instances where systems prototyped and iterated over in a no-code environment need to be brought back “in house”. This is not a failure of no-code because the engineering team has the perfect prototype/spec to build from. Aligning on when, why and how projects will  be recreated in the core stack is a worthwhile discussion to have up front. It will also help engineering see the value of experimentation and prototyping before they spend time building on their core stack.