If I had to pick the biggest challenge that companies large and small face when it comes to building a SaaS development team, it would be that they simply don’t know what to look for. This is especially true when the organization in question’s core industry is something other than software development. For example, the oil services company that maintains a SaaS application for collecting and analyzing well site data, or the restaurant chain that with a proprietary inventory control app.
IT, SaaS development...what’s the difference?
Often, the closest thing such a company has to an expert in SaaS development comes from the ranks of their IT department. While there are very smart and capable people among the ranks of corporate IT, it’s quite difficult to run a software team - or even worse write code - when your day-to-day consists of things troubleshooting IP telephony and domain conflicts. While these things may look to the untrained eye to be quite similar to software engineering, they aren’t.
Before I move on, it bears mentioning that the above isn’t intended to be a knock on our IT brothers and sisters. In fact, this very much cuts both ways. We at Metisentry love to solve problems with technology, but we have no business trying to configure your corporate firewall.
In some cases the company has leaned on an individual on the IT team to do the work his or herself, an approach that isn’t unlike hiring a handyman to build a house - and in others, the internal resource is in charge of hiring and managing a group of contractors or employees that do all the hands-on work. But regardless of the particulars, those who have been down that road often express frustration over a lack of progress that spans a number of months or longer.
Now that we’ve covered the biggest “don’t” of building a SaaS development team, let’s move on and talk about some “do’s.”
Five or more years of direct experience
Any less, and you are likely to be paying for them to learn on the job. Think of the handyman analogy. Five years isn’t enough to develop deep a high degree of skill in floating drywall and and installing a new breaker box.
Sure, you can get the less experienced guy or gal for less, but they’re likely to be much less efficient and prone to mistakes, so be sure to ask yourself if you’re really saving money in the long run.
At Metisentry our SaaS development teams consist of four core roles: User Experience Specialist, Project Manager, Product Manager and Software Developer (front-end and back-end).
If you expect any of those roles to be able to ‘fill in’ for the other, you are likely taking from the quality of your outcome and adding some late nights and weekends to your schedule. Again, it’s going to take the handyman a lot longer to put in that breaker box than the electrician, the latter’s work is likely of a much higher quality.
Another area of specialization to hire for is that of the front-end developer. With all the different hardware platforms (mobile, tablet, desktop, etc.) available, it’s imperative that your SaaS application work well across all of them - and making that happen is the domain of the front-end developer.
Great SaaS businesses pay developers healthy sums to release updates to work on an ever changing matrix of devices, operating systems and browsers.
The mindset of a front-end developer is quite different from that of their back-end counterparts. The best way to describe the disparity is that back-end developers tend to see applications from the inside-out, which can lead to a pretty dreadful user experience. Front-end developers, on the other hand, are typically much more ‘design-minded’ and cognizant of the user’s point-of-view.
Agile but focused
Successful SaaS development teams are both agile enough to capitalize on emerging opportunities and sufficiently focused to avoid straying from the product’s business or strategic vision. Taking the time to define a product roadmap gives the team a “true north” and ensures alignment between the business and the team. It doesn't have to be anything too detailed, just a long-term list of milestones that your business and platform is aiming for, broken down by monthly or quarterly increments.
On teams of six or less people, the quality manager will often be an individual contributor as well, so in most cases the best approach is to pull this individual from the ranks based on their attention to detail, commitment to the overall product vision and relationship with the team.
If your team is greater than six-strong (including yourself) you may want to consider a dedicated role. A team of that size will produce output at a higher rate, and gathering, ranking, classifying and reporting the feedback that comes out of user acceptance testing, code reviews, load testing, user testing and the like will almost certainly be a full-time job.
This is one area where breadth is desirable. Since most coding platforms work on similar principles, the differences between them aren’t as wide as the gulf between IT and SaaS development is, and a history of working across multiple tools and methodologies indicates a desire to use the right tools for the job, rather than the right tool for themselves.
In addition, individuals with cross-platform chops are much more likely to possess the kind of foundational knowledge necessary to make the kind of big decisions that impact long-term success factors like scalability. On the other side of that coin, lies the one-trick-pony that will build a product that seems great at launch but proves later to be difficult to extend or upgrade.
Starting on the right foot
Consider the above, and your SaaS development team will be primed for success. Whether you’re a SaaS startup, or looking to upgrade existing software, there are a lot of forks in the road between concept and launch. My intention in writing this post is to share the experience I’ve gained over 18 years of building software in the hope of bringing some clarity to a few or those early decisions.
If you have any questions or need any help, please feel free to reach out.