Series Code Makes The Latka 100: The Fastest Growing SaaS Companies in 2019

Since 2016 we’ve been focused on helping you grow your business. We’re excited to share that out of 3,500 SaaS companies last year, we were in the Latka top 5% in terms of revenue growth rate. This is a clear sign that our product continues to be loved as we work to scale. Big thanks to all of you for helping us grow 183% over the past 12 months, landing us a spot in the top 100 fastest growing saas companies.

We’ve grown the Series Code team to over 28 people as of today and look forward to another year of helping you grow!

How We Compare to Other SaaS Companies

The top 150 fastest growing private SaaS companies in 2019 together added over $1.2 billion in new ARR. When you put all of us together, we employ over 11,383 employees serving 697,428 customers.

We’re proud to say we’ve driven our growth without raising any capital! Click here to see the full rankings.

It’s not my fault – Agile made me do it!

I argued in a previous blog that the first of the twelve “Principles behind the Agile Manifesto” misses the mark in naming the highest priority of Agile practitioners. In truth, it doesn’t just miss the mark, it misses the target. As a refresher, the principle reads:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

I contended that the principle expresses a false absolute. More importantly, I believe it advances a false allegiance. I don’t believe “satisfying the customer” should be the highest priority of people using Agile frameworks at all. Customer satisfaction certainly matters and it’s not unfair to say it’s a key business priority for any organization. But to call it a singularly transcendent one that surpasses every other goes too far. Whether Agile standards of care are used in the process is inconsequential in making that determination. There are far more important priorities development teams should recognize.

The first and second Theses of the Denver Method, which I introduced in that blog, offer just two examples of valid business objectives organizations might consider to be equally important to satisfying customers. But far more critical are the ethical and moral values a development team must be duty-bound to uphold. These ideals should soar far above any potential business goal or profit motive when a development team is forced to weigh its loyalties.

Imagine, for example, a situation where a team is asked to build an application that clearly doesn’t fit that team’s area of expertise or skillset. Should its top priority be attempting to ‘satisfy the customer through early and continuous delivery’ of a software solution when the developers know very little about that particular area and probably can’t build the app without major flaws? Or should the team lead just be honest and let the customer know the application requested is outside the team’s sandbox, perhaps suggesting another development group more qualified for the task?

As a more prescient example, consider the case of the infamous software-based Volkswagen “defeat device” which, between 2008 and 2015, illegally altered VW diesel engines to keep nitrogen oxide emissions within U.S. EPA limits whenever the software detected vehicles were being tested for emissions, but allowed the same vehicles to emit up to 40 times that limit under normal driving conditions. Ignoring, for now, the question of whether the developers who wrote and implemented the code were ordered to do so, they clearly created this ‘valuable software’ to ‘satisfy the customer.’ So, if the team members used ‘early and continuous delivery’ to create it, can we assume they should be allowed to plead “The First Principle of Agile” in their defense?

Yes, there was a touch of sarcasm there, I’ll admit. But the point remains a valid one. To say, “It’s not my fault – Agile made me do it!” would be a preposterous rebuttal for criminal behavior, and Agile certainly encourages no such dereliction. Yet, as we enter an age where software drives cars, controls weapon systems, monitors health conditions, powers devices that have the potential ability to spy on us in our homes, and even guides life-and-death surgeries; development teams have an ever-greater duty to exercise a standard of care that exceeds every business priority. What concerns me isn’t that Agile encourages unethical or negligent development practices – it doesn’t. What concerns me is that nothing in Agile’s values or principles actively tries to prevent them. Instead, it calls on Agile practitioners to “satisfy the customer” as the practitioner’s “highest priority.” Therein lies the false allegiance.

Let’s look at the VW case again, supposing this time that executives did indeed order the software engineers to create the defeat device, then threw those developers under the bus when the deceit was uncovered. From the facts that have come to light so far, this appears to be what happened – at least superficially. Even if the software engineers only followed their bosses’ orders, they broke both legal and moral codes of behavior by not refusing to comply with those orders. One might say in such a circumstance the executives were the real “criminal masterminds,” but the developers still chose to be their ignominious “minions,” however coerced that choice seemed to them at the time.

In April of 2017, James Liang became the first VW engineer to go to jail for his role in the emissions scandal after a U.S. judge sentenced him to 40 months in prison and a fine of $200,000 for conspiring to defraud the U.S., committing wire fraud, and violating the Clean Air Act. Speaking on Liang’s behalf, his lawyer said, “We’re not saying he didn’t commit a crime, but he’s a good and decent person. He blindly executed a crime because of a misguided loyalty to his employer.” If that is indeed how Mr. Liang saw his actions, his “loyalty” was “blind” indeed: Blind to the jeopardy it placed on his own career, life and family; blind to the livelihoods of hundreds of VW employees who were unaware of the deceit but lost their jobs because of it; and blind to the good faith it destroyed for millions of VW customers around the world. He clearly didn’t see where his real loyalties belonged.

As software becomes an integral part of nearly every aspect of human life; and as that software becomes incomprehensibly complex; we find ourselves racing toward a crisis of loyalty, responsibility and integrity unlike anything the software development industry has ever faced. Imagine, for instance, what happens when an executive insists that a team cut costs “or else.” Now suppose that the developers, already stripped to the bone, determine the only place left to cut is testing. Next, picture what happens when those cuts cause the team to miss a bug in their autonomous driving application, and that bug costs human lives before it is caught and fixed. Finally, consider the developers’ plight when executives, trying to deflect personal blame, accuse the team of criminal negligence for irresponsibly cutting corners.

We must begin thinking about conundrums like these. They are coming. Soon.

I don’t pretend to think I can prevent every crisis of conscience with a few words posted on a blog page. But I do think there are ways to help the development team understand its real priorities and make its decisions a little less arduous or complicated. The secret lies in understanding exactly where a team’s loyalties are. In the Denver Method, this is one of the Aegis’ most important duties.

Each Thesis is written to specifically address the Aegis. I have two reasons for this: (1) Because I first began writing the Theses as a guide for training new Aegises, and (2), because that role personifies the very heart of the Denver Method’s essence. The competence and dedication the Aegis displays in fulfilling that role and manifesting the Theses determines the caliber and integrity of his or her team. This is especially true of the third and fourth Theses, as they embody the ethos and marrow of the Denver Method itself.

THESIS THREE: In all things and above all things, the Aegis must do what is right. An Aegis must resolutely understand where his or her loyalties lie and use them to guide difficult decisions. Preeminent among those loyalties rests doing right for the team: The Aegis is its champion, tasked with the well-being and livelihood of its members. In addition, the Aegis must be loyal without fail to his or her higher being, to the highest service of customers, to the good reputation of the business, to its financial success, and to the law.

My developers and Aegises like to call Thesis Three the “Aegis’ Professional Code of Conduct.” Its substance, however, applies to anyone in a leadership position. Developers and other employees in an organization should find beneficial guidance in Thesis Three as well.

To further define and clarify the Thesis, I’ve written some Corollaries. The first relates to understanding the deeper meaning of the first sentence. Knowing precisely what is right can sometimes be tricky, but Rotary’s well-known “Four Way Test” offers an unlimited free supply of “virtual litmus paper.” Herbert J. Taylor wrote these four simple questions when he worked at Club Aluminum Products in the 1930’s, at a time when the company faced looming bankruptcy. Taylor posted the maxim for other employees to see, hoping to change the company’s ethical climate and thus its fortune. Years later, Taylor became an international director of Rotary and offered the organization his Four Way Test, which it readily adopted. Today, Rotary continues to promote the axiom as the standard by which all behavior should be measured.

THESIS THREE, Corollary 1: It is sometimes difficult to know with conviction what path is the right one, but if it can’t pass Rotary’s time-honored standard of behavior keep looking, because you haven’t found it yet.

“The Four Way Test”

Is it the truth?
Is it fair to all concerned?
Will it build goodwill and better friendships?
Will it be beneficial to all concerned?

NOTE: Okay… I need to admit I’m not being truly honest here; at least syntactically. My exhortation to “keep looking” is meant to ensure the Aegis goes outside the box as far as possible before settling for a lesser path; because any course of action that can’t pass every stipulation of the Four Way Test remains, at the end of the day, a lesser path. Thus, when an Aegis has explored every imaginable alternative with the test in mind and fearlessly resolves that no path is better, then I will trust he or she has found the best solution there is.

I firmly believe that meeting the first two challenges is never impossible; therefore, any course followed must, at the very least, be the truth and fair to all concerned. On rare occasions, however, no practical solution exists that benefits everyone or builds “goodwill and better friendships.” While win/win answers should always be the goal, sometimes the only viable choice – even though it’s as fair as humanly possible – leaves someone feeling they’ve lost. When that happens, the Aegis must look to the Thesis’ hierarchy of loyalties to know whose interests he or she must try to protect.

Notice that the Aegis’ boss, per se, is not one of those interests. This is deliberate. Nothing in the Thesis addresses the organization’s hierarchy of command, because if leadership in general (and the Aegis’ superiors specifically) always uphold genuine loyalty to the company, the community, the customer, and the law – and always have the Aegis’ back regarding the welfare of the team – there will never be a conflict between them. If a leader or group of leaders’ loyalties diverge from the Code of Conduct, however, the Aegis must stand by the Code. There is a Corollary for that, too.

THESIS THREE, Corollary 2: While an Aegis should always be a good corporate citizen and respect his or her leadership, it remains a critical part of the Aegis’ duty to his or her team and to the reputation of the company to know when the instructions of a superior must be resisted in a fair and honorable way. When a directive or policy will result in loss of well-being or livelihood to those the Aegis serves as guardian to, or when it is illegal or immoral, the Aegis has a duty to speak up and take necessary steps to prevent its implementation.

The next Corollary my Aegises and developers jokingly call “The Aegis’ Conduct of Code.” It points out that, as part of honoring the priorities in Thesis Three, an Aegis should realize the software his or her team creates can affect the lives and welfare of countless others.

THESIS THREE, Corollary 3: It is the Aegis’ apodictic responsibility to ensure that every line of code published by the team serves the higher good of the customer, the user, and the community. The Aegis’ vigilance in this duty reflects on the team, the company and everything the Aegis stands for.

In the next blog, I will introduce Thesis Four, which is existentially linked with Thesis Three, defining the way in which the Denver Method creates a thriving culture of genuine engagement; one that is palpable, exciting, and magnetizing for highly creative people.

[Cross-post from the Denver Method Blog]

Greasemonkey Script to Prevent Smartsheet Emails From Scrolling Off the Screen

On March 23, 2017, Smartsheet deployed a software update that made its alert emails very difficult to use in Gmail. They added blank space to the updated table rows that pushes content far off the right side of the screen. The image below shows the difference. The email on top is what alert emails previously looked like in Gmail; the email on the bottom is how they appear now.

I asked Smartsheet to fix this problem on April 11th. They assure me that the development team knows about the problem but they can’t provide a timeline of when it will be fixed.

Until then, I’ve created a Greasemonkey script that makes the alert emails usable again. Greasemonkey is a browser add-on that lets you run scripts to modify a web page once it is downloaded to your browser. Install Greasemonkey for Firefox here or Tampermonkey for Chrome here. Then click the following link:

Install Userscript to Resize Smartsheet in Gmail

Reload your Gmail tab and the script should be active. This script works by checking that the text “” appears on the page and then removes the width attribute from all “td” elements (table cells) and changes the min-width property to zero.

If you have an improvement to the script, please let me know. If the link above doesn’t work, here is the full script:

// ==UserScript==
// @name        Resize Smartsheet in Gmail
// @author      John Steele, Auxiliary Teams Inc.
// @namespace
// @description Resizes Smartsheet email content to fit inside Gmail.
// @version     2017-07-02
// @include     /^https?://mail\.google\.com//
// @match*
// @match*
// @grant       none
// @require
// ==/UserScript==


    Copyright (C) 2017 John Steele and Auxiliary Teams Inc. All Rights Reserved. 
    This work is distributed under the W3C(R) Software License [1] in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$.fn.shrinksmartsheetgmail = function(){
    if ($('div:contains("")').length > 0) {

568 Days Uptime, 200ms Global Response Time, and How We Do It

Uptime Image

Enterprise RADIUS, or ERAD, is Eleven’s secure 802.1x Wi-Fi authentication system that is used by leading hotel brands. I had the honor of building this system in 2015 and we continue to improve and maintain it. As of today, it has achieved continuous uptime of 568 days; no downtime for scheduled maintenance and no unexpected outages. This system also achieves worldwide response times of under 200 milliseconds.

Now, I don’t want to mislead you. These statistics are for the user interface component of ERAD. Most web technologies also have a backend component. In ERAD’s case, the API backend has achieved uptime of “only” 252 days.

How did we achieve these results? There are 3 keys to our success with the frontend component of ERAD:

  1. The frontend consists entirely of static files.
  2. The static files are hosted on AWS S3.
  3. The files are globally distributed using AWS CloudFront.

First, and in my opinion most important, is that the user interface is purely static. There is no server side processing — no dynamic logic. The files hosted on the server are sent as-is to the user’s browser. By doing this, we are able to host the files on Amazon’s S3 service, which has excellent up-time statistics.

Using purely static files does introduce some difficulties but these are good difficulties to have. It forces a separation of concerns, requiring application logic to be contained in the API and not the UI. For example, there is nowhere in the UI that a connection to the database can be made because doing so would mean embedding the database credentials in the source code that is sent to the user’s browser. Instead, the UI must interact with the database through the API, as would be expected when following best practices.

This configuration is highly stable and results in long uptime statistics because it is able to use mature services such as S3 and because it enforces best practices, which help improve stability. And because these files are hosted on S3, they can be globally distributed via AWS CloudFront, which is how we achieve 200ms response times

Why Agile?

I have had the benefit of seeing the Agile development philosophy from both the developer’s and the manager’s perspectives. From my experience, it seems that developers whole-hardheartedly embrace Agile while managers often seem to do so begrudgingly. This article is for managers and explains the primary benefit managers receive and should embrace from an Agile philosophy.

Agile Avoids Waste, Reduces Risk, and Responds to the Market

A primary premise of Agile is to deliver early and often. Delivering early means getting features in front of users, even before they are complete and polished, so that users can give feedback. This feedback is critical to assuring that features aren’t being developed that will either be unused or unusable.

Extensive, multi-year studies by companies like Microsoft, Netflix, and Quicken Loans show that two-thirds of software features fail to provide the benefit they intended to provide. The vast majority of software written simply doesn’t provide value to users. Companies throw billions of dollars at the problem of figuring out what users want and get it wrong over and over again.

The answer to this problem is delivering early and often. By getting features in front of users as quickly as possible, users can give feedback about whether the feature is valuable. That feedback can be used to iterate: decide to continue on course, change course, or scrap the feature and spend development resources where they will provide higher value.

Ready to put Agile to work for your organization? Get started with Auxiliary Teams today.

What is Managed Software Development?

Let’s face it. Managing developers is like herding cats and you have more valuable ways to spend your time. Hiring developers from Auxiliary Teams isn’t hiring contractors that you still have to manage and supervise. You get a team leader who is your organization’s single point of contact. This team leader is the technical architect who designs a cohesive system and ensures all code merged into the production repository adheres to that vision. With managed software development, you manage the ideas, we manage the development.

Managed Software Development

We follow a surgical team model, as described in the Denver Method. The model is that a single individual, a highly talented and experienced developer, is the head of the team and responsible for every line of code put into the project. That individual is surrounded by a team of great developers who also write production-ready code but all of that code is presented to the team leader for acceptance. On a surgical team, the head surgeon is responsible for every incision. One primary reason for this is to make sure the action takes place in light of all other information. The other team members might not perceive the full situation or might not be experienced enough to recognize the interaction between two different and seemingly unrelated activities. The head surgeon has the experience to assimilate all of the information together into a cohesive picture and the ability to visualize hidden pitfalls before they occur. We believe following this model in software development also reaps similar benefits resulting in greatly increased code quality.

When hiring a typical software contractor, the managing company has to closely supervise the individual. Contractors are usually hired only into an existing software development infrastructure. On the other hand, managed software development can fit into an existing infrastructure, with much lower supervision requirements, and can also fit into a company that has no infrastructure for software development and can provide immediate benefit without significant ramp-up time.

Ready to try managed software development from Auxiliary Teams? Get started today.