This article is for: Non-technical founders, management or sales professionals who need to interface with development teams, programmers, coders and engineers. Learn technical communication skills and ‘speak the language of developers’ to improve project outcomes and deliverables
<– Back to “Software Development Communication Essentials for Startups”
Running a software startup without much of a technical background can be extremely challenging. Doing so without a technical cofounder adds a whole extra layer of difficulty. And when you factor in the constant evolution of the technologies involved with your product, keeping up on the technology becomes seemingly impossible. Developers start to seem like they’re speaking a completely different language and you feel completely out of the loop.
Whether you have a technical cofounder or not, these issues are more pervasive than you would think. It all comes down to one question: how are you supposed to turn customer problems into software solutions if you have no idea how those ideas translate into writing software code?
Here at the Altitude Accelerator, we work with clients who have been through it all. In this article, this situation will be explored through the viewpoints of ten individuals who have had varying roles at businesses that develop software; that includes non-technical founders, CTOs and developers. This should shed some light on how you as a non-technical entrepreneur can communicate your ideas to developers.
The key concepts explored in this article include:
We will illustrate these ideas through case studies of companies and founders who work with the Altitude Accelerator network
If you’re reading this article, it’s likely that you don’t have a technical background. Obviously, it’s always an asset to know what you’re talking about when leading a business, so it would definitely be ideal to know how to code. But learning how to code takes a lot time. Even learning enough to give your developers technical specifications can be tedious. Because of this, you need to judge whether or not it’s worth it to spend time getting a technical background. Regardless, it’s important to brush up on your technical communication skills.
You obviously need to consider the qualities of your unique business during this decision, since a more sophisticated technology would benefit more from your knowledge than a simple app. It would definitely be helpful to have a grasp on concepts such as software development methodologies, architecture design patterns, programming languages and IDEs when making this decision. The following case studies should help inform you of the benefits of having technical communication skills in your toolbox
For information on where you can learn to code or just learn about programming, refer to this article on developing software yourself.
Alec Pestov is the founder and CEO of vGIS Inc., a software program that transforms traditional Esri GIS (geographic information systems) data into augmented reality visualizations and holograms. He has been a client with the Altitude Accelerator for four years, starting off with his parent company, Meemim. Pestov’s team at vGIS is composed of himself and thirteen developers, making him their only point-of-contact on the business side of things. As a result, he spends around two hours every day discussing the product’s next steps with the development team.
Pestov is relatively technical himself, having worked in technical consulting twelve years ago. He wouldn’t be able to program the product himself but has enough knowledge to tell whether the code has been done properly. His experience has also given him a better ability to gauge how long things will take to be coded. Having some insight into software development is especially useful when translating his design goals to the UI team.
Overall, Pestov feels as though he has enough knowledge to “recognize how things should be designed and who is able to design them.”
With this level of technical background, technical communication with the development team is efficient and effective. There are fewer misunderstandings and expectations are aligned more effectively.
Chris Houston was the CEO and founder of SurfEasy, a VPN service focused on security at large companies, which has since been acquired twice. Houston now acts as the VP of mobile product development at Symantec, SurfEasy’s latest acquirer. He has been building tech companies for over two decades, giving him a large amount of experience to draw from.
In his experience, Houston admits that non-technical founders usually don’t know how to code. However, he urges founders to push themselves to learn more about how things work and what is required in software development. Knowing about the coding languages and tools, development methodologies, frameworks and architectures of tech products makes it a lot easier to recognize the limitations of your project ideas. It’s hard to develop sufficient technical communication skills without this background.
Overall, you just don’t want to be made to believe something is impossible when it is indeed possible. In his words, “Don’t be [lied to] during the process by companies that are trying to take advantage of you.” Having some basic knowledge of the software development process is key to managing a tech business.
Luckily, it’s getting easier to learn about coding every year according to Houston. In fact, his seven-year-old son is learning to program AI!
Mark Oleniuk is a cofounder and managing partner for Get ResQ Ltd., an app that organizes on-demand maintenance and preventative fixes for restaurants. He is a Registered Professional Engineer (P.Eng) by trade but didn’t have a background in development when he got into the software business. Along with his two other cofounders, Oleniuk also didn’t feel pressure to get a technical cofounder. Despite the lack of technical leadership on his team, ResQ has succeed by outsourcing development to a software development company; eventually the team brought on a development lead.
Despite their success, Oleniuk does recall some challenges that arose as a result of his lack of technical communication skills. He says it would often cause a disconnect between the ResQ team and the third-party company developing their product. In general, the terminology of how different pieces of the software fit together was difficult to understand. There were also language and time zone barriers when they needed to communicate with the company’s overseas division.
Oleniuk’s team relied heavily on communication tools like Slack, Bitbucket, and Jira to keep their in-house developers on the same page as third-party developers. He says there was “a lot of learning along the way” during the development process, as he was able to pick up useful insights into software development from the experience. Although he was able to make his business work without it, Oleniuk concurs that “you can never go wrong by having someone with knowledge on your side.”
Andrew Opala has held a wide range of leadership and development roles at innovative software companies over the course of his career. After collecting a wealth of experience and knowledge from leading and founding startups, he now lends his wisdom to Altitude Accelerator clients through his position on the Board of Directors.
Although learning about software development is obviously useful, Opala does not see learning programming as one of the more important aspects of leading a business in a non-technical role.
Instead, he advises tech entrepreneurs to prioritize trust and honesty in dealing with their technically-inclined counterparts. This can include a technical cofounder, a project manager, or the development team itself. No matter how hard it is to trust someone else with such a high-stakes project, you just need to find a way to trust them. Trusting those in charge of development allows you to focus on business and sales. This often comes down to choosing a technical cofounder that you trust; Opala says that single non-technical founders are far less likely to receive outside funding than those with a technical cofounder.
Honesty, as mentioned, is also key. This involves maintaining a transparent line of communication between the non-technical founder and those in charge of development so everyone can stay in the loop. Building a common structure for technical communication and reporting throughout development makes this much easier.
As a non-technical person at your software startup, your role likely revolves around some combination of sales, marketing, operations, and more. Because of this, your relationship with your developers largely comes down to bringing them your ideas from customer research. It’s not only about being proficient in technical communication, it’s also about understanding how to articulate business requirements in a way that technical people are receptive to.
A significant aspect of running a lean software startup is constantly iterating with new ideas, most of which are inspired by user feedback. You need to be able to effectively communicate your vision to developers. Here we have two cases of entrepreneurs finding a way to handle this situation.
Daniel Ruscigno is cofounder of ClinicSense, a practice management software system for massage therapists. Whether he would really call himself a “non-technical” cofounder is undefined, seeing as he was studying computer science in university before making the switch to marketing and economics. With prior experience as both a product manager and project manager at software companies, Ruscigno has had to use technical communication skills in these settings.
When defining tasks and features to developers, Ruscigno finds importance in having them understand how what they’re working on impacts the business side of the project. Essentially, he wants them to see “here’s why you’re working on this and here are the expected business outcomes.” Ruscigno finds that developers are more attached to a project when they can see how their work affects customers directly. For example, a proposed feature could allow customers to navigate the app quicker, leading to a more convenient product, leading to more customers.
Ruscigno also makes use of communication tools to stay on top of the development team. Specifically, he uses Jira to keep track of which stage the developers are at on a project.
Steve McBride is the CEO and cofounder of Weever Apps, a service providing cloud-based software products that increase productivity and profit for corporate customers. As someone with a wealth of experience in sales and less of it in software development, McBride acts as the voice of the customers at Weever Apps while his more technical cofounders oversee development.
However, McBride plays an important role in communicating customer desires to the software design team. Then, the designers communicate those desires to the development team. He finds the best way to have designers and developers understand customers’ desires is to have them sit in customers meetings. That way, they get a first-hand account of what the user is going through and what they want changed. In McBride’s words, “a customer saying they need something is much more important than their boss saying it.”
McBride has also realized that getting to know each of your developers plays an important role in communicating effectively. Some are overly optimistic while others are pessimistic; you need to find out which describes each developer. Getting to know the mindset of everyone on your team allows you to plan properly. For example, you can assess whether a time estimate is shorter than it should be or longer based on which developer provided it.
If you didn’t understand the coding reference (or pun if you can call it that) in the title above, you may want to brush up on programming basics.
Beyond just passing on customer desires, many non-technical founders often find themselves in a position where they need to propose new features and projects to developers without the support of a technical cofounder. It is important that specifications are proposed by someone with enough technical knowledge to make instructions that developers can actually use. Even for those that don’t have that responsibility, staying in the loop with development allows you to keep your eye on what’s happening in all areas of the company. Monitoring progress on projects is important to marketing, estimating release dates, getting funding and more.
The perspectives below can shed some light on how to effectively navigate these tricky positions.
Jon Senson is an experienced developer who has worked at multiple video game development companies. His work at these companies involved programming and updating games both internally and for clients.
Developing for clients involved a lot of technical communication which often wasn’t sufficiently technical. Senson often struggled to make use of clients’ specifications when they were poorly thought through and designed. When you make instructions for developers without a decent understanding of design, those specifications can often be unusable. Often individual parts of plans don’t fit together in a way that can possibly work on the specific software platform.
Senson recommends that someone with UI experience has some input before specifications are given to developers. At the very least, he says, clients should get a basic idea of how object orientation and some of the basic frameworks of software development work. That way, you can at least make instructions that make sense from the developer’s perspective. It is also very helpful if clients are able to diagram their thoughts, perhaps with a program like UML, or at least make a wireframe of what they want. Overall, having a knowledge of how software is planned out before development will result in more developer-friendly instructions.
As you can see, translating your ideas into a more technical format is key to getting developers to make exactly what you want. Just saying “make me something that does this” is not the way to move the product you’re envisioning into reality. Senson advocates for hiring a project manager, or anyone technical, to function in that translational role between business people and developers. They can function as a liaison between the two sides and keep track of changes so everyone stays informed of project progress. As a startup founder, you may have to wear this additional hat yourself.
Jeff Lande is the founder of Lucky VR, a company that builds online virtual reality casino games. He built the company around three of his passions: poker, technology, and entrepreneurship. With no technical background in software development, Lande hired a contract developer to build the prototypes – that developer later became his technical cofounder. As the business has grown, Lande’s team has grown to about seventeen developers and artists. With a team that size, Lande has needed to find effective ways to translate customer desires into a plan for his developers.
Rather than taking the time to learn coding, Lande became technical enough to stay in the loop (I hope you’re still thinking about while loops) with developers by spending time working with them. Just being with them during development allowed him to pick up some key knowledge; at least to the extent that he could understand what was going on.
Another entrepreneur, Adam Gellert, the CEO and cofounder of HiredHippo, shared in this sentiment. He claims that non-technical founders need to ask a lot of questions during development to learn about how engineers think and stay afloat of what progress is being made. Learning technical communication is a lot like learning a new language: it’s fastest when you’re immersed in it.
Lande prioritizes new features based on customer feedback and works with developers to create a roadmap for development. Roadmaps are strategic plans for a project that outline the timeline and process of a project. Working closely with developers allows Lande and the Lucky VR team to have a tight feedback loop during development; updates and features are developed, they collect customer feedback, and the roadmap is adjusted accordingly.
Because Lande stays in the loop during development, he’s able to get more accurate feedback on how long things might take to complete or what changes need to be made to a feature. Overall, working directly with developers to create roadmaps based on customer desires is an effective way to translate your ideas into a plan for the development team.
Thus far, the ideas discussed around building technical communication skills have applied mostly to small or medium-sized software startups. But how do these notions change as a company grows into a larger business? It’s obviously much more difficult to communicate directly with each individual when the team grows to ten times its size. This section uses a case study to explore the relationship between business people and developers at a large company.
Vishal Kothari is currently a managing partner at Red Lane Capital and cofounded RedKnee, now rebranded as Optiva, a provider of business support systems software for the telecommunications industry. When he cofounded RedKnee over two decades ago alongside three engineering peers, the company had about fifteen employees. Since then, the company has grown to about 1,500 employees when he left the company last year. Kothari says the company endured a lot of evolution over the first five or six years and finally achieved a more focused product about seven years in.
With one of the three other cofounders being a talented software engineer, Kothari never found much of a need to learn to code while running his business. He finds software development pretty straightforward, stating that “if you figure out a customer’s problem, you can communicate that to software developers and trust them to make it well.” When you’re at a large company, you can’t spend time micromanaging each developer; trust them to do their job so you can focus on your role in growing the business. You obviously still need to effectively and consistently document and communicate features to the developers, but just avoid spending every minute of the day worrying about development.
At RedKnee, Kothari’s policy was always to spend a lot of time with customers and learn about their pain points. They had about 500 customers around the world but investing their resources into talking to customers in person was a huge priority. Every department at the company was run in a customer-centric way, focusing exclusively on doing what’s best for customers. With that being said, this led to a lot of feedback and ideas coming their way from customers.
Large companies that interact with customers are bombarded with suggestions. But if you pass along every suggestion to the development team, they’re going to end up wasting a lot of time on features that the majority of customers don’t actually want. “They may ask for everything from A to Z,” Kothari says, “but you need to validate what they want. The customer may only actually want five things when you end up building a whole bunch.” You also need to translate what they say they want into a simplified version that still addresses their most important problems.
Much like a startup, large companies still need to validate ideas before they start building them. Since you can’t just be a custom shop for customers, validation lets you see if the customer problems are common or high impact. If they do turn out to be common, then you pass that along to the developers and move towards that. As a company grows, it remains important to filter out customer suggestions using validation This ensures you’re not wasting developers’ time and the company’s resources on planning the roadmap for an unnecessary feature; this leads to scope creep and feature bloating.
As the company grew, RedKnee hired managers to validate customers and turned their suggestions into a roadmap that could be sent to developers. They played a key role in creating development plans that were both representative of the customer’s viewpoint and feasible from a developer’s viewpoint. This also largely eliminated the need for the R&D team to be in constant communication with the developers. The key point here is these plans still needed oversight by someone with good technical communication skills to be feasible from a developer’s viewpoint.
As discussed in several of the above cases, tools are an integral part of maintaining effective communication with your software development team. Here is some more info on the tools mentioned in this article.
For information on tools used for communication with outsourced software developers, refer to this article. Other helpful software tools for startups can be found here.
Slack is gaining popularity in the tech community at a rapid pace, allowing remote development to collaborate just like they’re texting one of their friends. Slack can function as a replacement to both email and instant messaging for your team, hosting a collection of conversations that is easy to navigate. You don’t want important messages getting lost in someone’s busy email account; Slack organizes conversations between individual conversations, team group chats, or discourse with partnering businesses. Quick messages can include polls, videos, or even push notifications for urgent matters. You can also share files, have video conversations, and integrate several other tools.
Slack is the best way to streamline technical communication between employees, teams, and business partners onto one centralized platform.
Altitude Accelerator companies that use Slack: ResQ, Lucky VR, Analyticly, Routible
Alternative software choices: Google Hangouts, Cisco Webex Teams, Chanty
Bitbucket, by Atlassian, is a commonly-used version control system for software developers. Version control systems allow software developers to collaborate on projects while separating code from separate tasks into branches; code changes on different branches can later be combined. They’re a good place to keep track of changes and compare new versions to previous ones.
Version control is a little difficult for someone with no technical background to get involved with but can provide a detailed glimpse into project progress once you get the hang of it. BitBucket in particular offers detailed access control for code branches and has a pipeline tool that lets developers build and test their code on the platform. When integrated with a project management platform like Jira or Trello, Bitbucket allows you to stay updated on what exactly developers are working on.
Altitude Accelerator companies that use Bitbucket: ResQ, Analyticly
Alternative software choices: GitHub, GitLab
Jira, also by Atlassian, is a project management platform optimized for teams using an agile methodology for software development. Project management platforms are a great place for you to collaborate with your team when you can’t meet in person. Most include visual representations of project plans, team chats, to-do lists, and task assignment. Jira in particular boasts advanced agile project management features including scrum boards, Kanban boards, roadmaps, and issue reporting. It also integrates seamlessly with other Atlassian platforms like Bitbucket, so many departments of your business can collaborate in one place. Jira is one of the more expensive options for project management platforms however, as a small team of one to ten employees would cost $100 per year, with larger teams costing much more.
If you’re looking for a platform that fully supports the use of agile project management, you can’t go wrong with using Jira.
Altitude Accelerator companies that use Jira: ClinicSense, ResQ, Lucky VR
Alternative software choices: Trello, Asana, Basecamp
<– Back to “Software Development Communication Essentials for Startups”
© 2023 Altitude Accelerator | Brampton, Ontario, Canada
