Building Enterprise Node.js Tools

NodeSource is a technology company that provides enterprise-grade tools, security, and support for the Node.js ecosystem. Founded in 2014, NodeSource played a pivotal role in enterprise adoption of Node.js. They were instrumental in offering a repository of Node.js binaries for Linux, helping reunite the io.js community fork with Node.js and driving the Node.js Long-Term Support (LTS) plan.

When I joined NodeSource as VP of Engineering in April 2015, I was excited at the opportunity to build products at a fully distributed company. Engineers were spread across the United States and Australia. We had a few true digital nomads as well. NodeSource was such a remote company that I did not meet our CEO in person until several months after I started working. The team started off doing consulting work and contributing to the upstream Node.js project. We had several engineers on staff that were deep experts in JavaScript and the Node.js runtime. This was both a blessing and a curse. Employing that much Node domain expertise gave NodeSource instant credibility with customers. However, getting those same engineers to spend cycles on the non-open source product work that generated revenue was often a challenge.

Shipwreck!

NodeSource had shipped their first product, N|Ship, prior to my joining. N|Ship focused on packaging and securing Node.js applications for enterprises. While beautifully designed, N|Ship only attracted one customer and had a host of quality issues mostly stemming from an over-engineered implementation. That first meeting with our CEO? It came after a disastrous demo with potential customers in Seattle. While I was not blamed for the N|Ship debacle, the CEO made it clear that we had to absolutely nail the launch of our next product. This would be an application performance monitoring (APM) tool we called N|Solid. We were on a fixed schedule as we needed to ship alongside the first Node.js Long-Term Support (LTS) release in October. This would be a challenge as we were working with the bleeding edge version of Node.js which had just reunited with the io.js community fork. Finally, I had just started planning the first engineering offsite where I would finally meet most of the team in person.

Early in the offsite planning process, I decided against having the founders join. Following the N|Ship customer demo, the CEO cancelled the product which lowered morale for the engineers on that team. They also felt that the CTO shared responsibility for the failure so I excluded him from the offsite as well. I needed to bring the N|Ship and N|Solid teams together and build rapport with them as well.

Previously, NodeSource had two company offsites in Austin, TX. As I started looking for locations for the engineering offsite, one engineer innocently asked “If we are a fully remote company, why are all our offsites in the US?” Great question! We needed to lean into our global presence to lend credibility to the company vision we were selling. Working with our admin, I found a beach house rental in Punta Cana, Dominican Republic. Not only was it affordable but it came with a cook who would provide three meals a day during our stay. Sold!

Finding A Solid Path

With the offsite venue booked, the final step was to unite the team in order to deliver N|Solid. After arriving in Punta Cana, the team spent some time socializing and enjoying the great food and drink that was provided. There were a few complaints about the heat that were met with “We’re less than 50 feet from the ocean… go take a swim!” That first afternoon, we hooked a laptop up to a large screen TV so that we could get demos of all the work in progress. One engineer had been building a set of visualizations of the Node and npm ecosystems collectively called N|Sight. The former N|Ship engineers walked everyone through the architecture of the application and some of the challenges they faced. The N|Solid lead engineer explained the basics of APM and the work he did at Google and his previous startup that informed the design decisions behind N|Solid. Finally, several of the open source engineers talked about the features they were trying to land upstream in Node.js.

After all the demos and presentations were done, I told the team that we were going to spend the rest of the week building a pathfinder. We would implement a slice of end-to-end functionality that integrated a modified version of N|Ship’s frontend with the current N|Solid backend. Our goal would be to have a working, usable demo of the commercial N|Solid product to show the company by the following week. The focus would be on creating a great user experience for N|Solid users to generate CPU profiles and take heap snapshots. With clear and narrow goals, the team was able to come together and implement the necessary functionality before the end of the week. To celebrate I took the team on a zip lining excursion where, around the fifth level, I discovered a new fear of heights.

The following week we demoed N|Solid to the entire company. While there was still a ton of work to do, the founders were both impressed and encouraged. The next two months was a whirlwind of N|Solid feature development coupled with trying to remain in sync with the Node.js runtime changes. N|Solid 1.0 launched in September 2015, Node.js v4 LTS was released in October and we followed with support for the LTS release with N|Solid 1.1 in November. By December, we landed our first large enterprise sale.

Conclusion

It has been said, “Never let a good crisis go to waste”. This was certainly the case with the launch of N|Solid. N|Ship was a business and technical failure that lowered morale. However, we were able to use the engineering offsite as a way to reset the team and refocus our efforts. Rather than demonizing the N|Ship team, we found a way to salvage and leverage their work in order to deliver a great experience for N|Solid. Bringing the product engineering and open source teams together to collaborate on a shared goal led to a highly successful product launch. This reinforced my philosophy that regular, in-person meetings are essential in maintaining the bonds between people on remote teams. More importantly, this experience led to pathfinders becoming one of the more valuable tools in my product development toolbox.