Technical Communication Skills for Software Startups

mockup-Section 2

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

Written by: Alex Senson, Ashley Burton, Tyler Boulanger

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


How important is getting a technical background?

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 methodologiesarchitecture design patternsprogramming 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.


The benefits of having a technical background – Alec Pestov from vGIS Inc.

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.


Know the basics of how coding works – Chris Houston from SurfEasy

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 toolsdevelopment 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!


The challenges of not having technical communication skills – Mark Oleniuk from ResQ

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.”


Prioritize Trust and Honesty – Andrew Opala from the Altitude Accelerator Board of Directors and the Mississauga Investor Network

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.


Summary: How important is getting a technical background?

  • A technical background can help you gauge how long a project should take to complete, how it should be designed, and whether code is going to work the way you want it to
  • Knowing the basics of how software development works can protect you from inaccurate claims and estimates from developers
  • Not having technical communication skills can cause a communication disconnect with outsourced developers because of complicated terminology
  • Trusting and being honest with developers is more important than knowing how to code, so long as you choose cofounders or developers worth trusting

Giving business insights to developers

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.


Understand the impact – Daniel Ruscigno from ClinicSense

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.


Be the voice of customers – Steve McBride from Weever Apps

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.


Summary: giving business insight to developers

  • Developers are more attached to a project when they understand the business implications of the task they’re working on
  • Communicating customer desires is much more effective when developers hear them directly from customers
  • Get to know your developers so you know whose estimates and claims are more pessimistic or optimistic

Technical communication strategies for giving better instructions and staying in the (while) loop

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.


How clients can give better instructions to outsourced developers – Jon Senson, Unity3D game developer and programmer

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.


Building a roadmap together – Jeff Lande from Lucky VR

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.


Summary: Strategies for giving better instructions and learning technical communication skills

  • Instructions given to developers without giving any thought to software design basics can be unusable. It’s critical to have some level of technical communication ability.
  • Instructions and plans should be created from a developer’s perspective whenever possible; whether you learn about it yourself or hire someone to work in that translational role
  • Spending time working directly with developers and asking a lot of questions makes it easier to stay in the loop during development
  • Making project roadmaps alongside developers is an effective way to translate customer desires into a development plan

How these technical communication ideas fit into a growing company

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.


Validating customer requests – Vishal Kothari from Red Lane Capital

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.


Summary: How these technical communication ideas fit into a growing company

  • At a growing company you can focus on your business role when you trust the developers with their job
  • Spending time with customers generates a lot of customer feedback, which needs to be filtered using customer validation
  • Validating customer suggestions before passing them on to developers streamlines communication and uses resources more efficiently
  • Someone can be hired for the translational role between customer research and developers to keep the best interests of both sides in mind

Some helpful software tools for technical communication

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

Slack 1024x274, Altitude Accelerator

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 HangoutsCisco Webex TeamsChanty

Bitbucket

Bitbucket 1024x258, Altitude Accelerator

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: GitHubGitLab

Jira

Jira Atlassian 1024x466, Altitude Accelerator

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: TrelloAsanaBasecamp

Concluding takeaways: technical communication skills for software startups

  • Getting some technical knowledge can help make more accurate timeline estimates, get a better idea of what developers are working on, and protect you from inaccurate claims and estimates made by developers
  • Trusting your developers to get the job done correctly without micromanaging them gives you more time to focus on business
  • Developers are more attached to a project when they understand the business outcomes and hear customer problems directly from the customers
  • Instructions and plans can often be unusable unless they are made by someone who can make them from the developer’s perspective
  • Spend time working directly with developers and ask them lots of questions to help stay in the loop
  • Translating customer problems into feature roadmaps alongside the developers will yield much better development plans; someone can be hired just for this role
  • When you are getting a large amount of customer feedback, it’s important to validate each suggestion to filter out which ones are worth building upon
  • Software tools are a valuable resource for communicating with developers; use the tools that developers are used to instead of making them use the ones you prefer

Recent Posts