Founded a decade ago in Melbourne, Australia, document signing and productivity company Nitro has grown rapidly. It's now in use at more than 550,000 businesses, including more than half the Fortune 500. How can technology leaders cope with growth like this? In this interview, CTO Tiho Bajic explains his strategy.
The Enterprisers Project (TEP): You've watched Nitro grow from its early stages to the widespread adoption it has now. What was most challenging about that growth?
Bajic: Hiring the right people at every stage of growth has always been a key area of focus. At each stage we had to evolve our culture and adjust our pitch to attract the right people. We also worked hard to onboard them by providing the right runway. For example, we gathered a group of experienced startup generalists in our original "SEAL Team Six" who built our first cloud services in fast iterative cycles. As those services were adopted, opportunities around data mining arose.
To even begin to explore those opportunities we needed to attract different kinds of engineers who specialize in machine learning and frequently work on longer cycles. And as that group was successful in turn, we needed to add expertise in scaling data pipeline architectures and embrace an "all-ops" model where engineers and DevOps work symbiotically with shared ownership throughout the software development life cycle.
TEP: Were there times when you had to make major technological changes to accommodate that growth?
Bajic: It's almost inevitable that if your product is successful you'll need to accommodate change. For example, for our web services platform, over the last four years we've moved from a closed-platform .NET cloud-hosted model to an enterprise Java self-hosted model and finally to a cloud-agnostic, fully open-source Scala reactive stack model.
It's simply impossible to predict future needs, especially in the face of new emerging technologies. At the same time, collective experience has taught us certain patterns that embrace a continuous learning and system gardening mindset. At Nitro, we talk a lot about our software engineering craftsmanship and how to practice it appropriately.
TEP: How can CTOs create technology that won't lose its relevance within a couple of years? Or is that impossible, and instead should they plan what to do when it does lose its relevance?
Bajic: The rate of technology change in the software industry seemingly continues to accelerate, so there's no such thing as "future-proofing." So everything from tooling and processes to how we'd prefer to interact with one another and our cultural beliefs should be up for debate.
Over time at Nitro, certain decision-making frameworks emerged to help us reason about ongoing technology change or our growth that might cause us to reconsider our tenets. Being explicit about debating, documenting and communicating change decisions is important — it helps a lot with onboarding new engineers and in general establishing a common shared operating context.
TEP: It says in your bio on the Nitro site that you helped develop the company's revenue model. Can you tell us a little about how you came to be involved in the revenue model and how you helped develop it and contributed to its success?
Bajic: This is what attracted me to Nitro in the first place over four years ago. Our CEO Sam Chandler understood well the customer needs and the great value of our desktop PDF productivity solutions. He and the senior leadership had ambitions to enrich Nitro solutions with web and mobile productivity.
In the process, we wanted to enhance how our customers purchase and benefit from our solutions from a perpetual license, key-driven desktop solution to a rich, account-based subscription offering that enables form-factor specific experiences. This called for core business operations platform changes, and I was given the opportunity to be in the co-pilot seat for this journey.
TEP: Any advice you'd pass along to other CTOs at rapidly scaling companies?
Bajic: Surround yourselves with technologists from whom you can learn on a daily basis and who are passionate about teaching others. Then be their student. Your job is to provide the common context and decision-making information so that your team in turn can engineer the best solutions possible. You should not necessarily be the chief architect for everything.
