Three Mistakes Non-Technical Managers Make When Building Software
Rate this post

Developing software applications isn’t easy. It’s even harder when managers don’t understand the underlying technology. When non-technical managers oversee software development projects, they must deal with the usual administrative problems while simultaneously learning about a whole new (and complex) world of technical challenges. It’s easy to get lost in the complexities of software development.

But technical knowledge is not a requirement to navigate a successful software project. Plenty of non-technical people work on complex software. The key is recognizing the top three most common blunders and how to avoid them.

Mistake #1. Underestimating the Language Barrier

Communication is essential to any project, but managers and developers must speak the same language to communicate effectively. Some of the biggest issues with software projects arise from misunderstandings, especially regarding requirements, expectations, and solutions. Translating technical language into plain English can be challenging. Just ask any product engineer.

And it’s not just the non-technical people who get lost. While technical language can confuse laypeople, industry speak can also confuse developers. Every industry has its own terminology or company-specific language. Technologists and developers may be experts in their field, but that doesn’t mean they understand the language of healthcare, logistics, finance, or other vertical industries.

The solution is to over-communicate. Talk openly with the team. Ask questions. Explain industry terminology. Review project requirements and expectations together to make sure there is mutual understanding. 

Also, be patient. It takes time to become a specialist. The best way to learn is with experience, and gathering experience takes time. Be diligent. Ask questions. Embrace the process.

Mistake #2: Focusing on the Wrong Things

It’s exciting to see something tangible come to fruition, but don’t become obsessed with the details. This phenomenon often occurs during the wireframing and design phases. Due to the visual nature of this stage, people over-emphasize images and copy in their feedback. However, it is too early in the development cycle to focus on content, which will continue to change. The focus needs to be on the structure and how the interfaces and menus work. At these early stages, the primary concern should be functionality. Does the application do what it is supposed to? 

The design phase provides an opportunity to consider colors, layout, and the application’s overall design. Images and text will come later. However, do pay attention to the text layout and the areas designated for the copy and images. Be sure there is sufficient room for the content.

Applying the agile methodology ensures there is a focus on the right tasks. With the agile development model, there are biweekly sprints designed to complete smaller functional elements, so the scope of the tasks is finite. Managers should ask the developers what they are evaluating. For example, for wireframes, page structure and user flows need to be assessed. For designs, they want to evaluate color schemes and page elements. It’s crucial to understand the goal of each sprint to provide the appropriate feedback.

Mistake #3: Simple to Explain, but Not Simple to Build

A mistake many non-technical managers make is assuming that if they understand the objective, it should be easy to develop. Just because a process or workflow is simple to explain doesn’t mean it’s simple to create. 

To illustrate the point, let’s assume that an online submission form needs to include the ability to attach a file to the form. This capability is common with online forms, and the actual code isn’t complicated. However, to perform the function correctly, the application should do more than accept and store a file in a database somewhere. There are user considerations, security concerns, error handling, data storage requirements, and more. Here is a list of just a few development considerations to add upload capability to a form:

  • What specific types of files will be accepted?
  • What protections are in place to determine whether the files are free of malware?
  • Is there a maximum file size?
  • Does the file transfer from the user’s browser directly to the database?
  • What is the indicator to show if a file submission was a success or a failure?
  • What happens if the connection fails before the transfer is completed?
  • Should the user be able to substitute a file if they upload the wrong one?

For every feature or function added to an application, consider how to address all the variables.

Never assume any addition or change is simple. Even if the requirement seems very basic, there will be any number of complexities that may have to be addressed.

Non-technical managers who work with software developers must trust the team and the process. The developers have the training, knowledge, and experience to deliver the finished application and help make decisions about technology stacks, architectural structures, user flow, and technical elements that non-technical managers may not understand. Whether it’s an in-house team or a professional software development firm, the programmers work to deliver the best software possible. Trust they know what they are doing, even if they can’t provide a simple explanation for every decision.

Author Bio:

Nik Froehlich is the Founder and CEO of Saritasa. Having started, run, and successfully expanded a construction-related service for businesses for 20 years, he always relied heavily on new technologies to create solutions and efficiencies. Combining his experience with business, his technical skills, and his vision for the future of technology, he left that company in good hands to focus on creating Saritasa, the technology consulting company of his dreams.

Leave a Reply

Your email address will not be published. Required fields are marked *