Lessons learned growing a tech team

For the past 9 months, I’ve been helping a client as they turned a social media startup into a marketing intelligence company. The startup had gone through a turbulent period, and under new management was looking to change direction. Inheriting a large legacy Node.js codebase and a small development team, the company needed to build new products for a different customer base, and grow a new team for that purpose. This post discusses some of the lessons I’ve learnt along the way.

Define scope early on

The startup had created a number of products in the space of 3 years, and with it, created a large maintenance job given the (then) size of the development team. These products had varying levels of documentation, but more worryingly a lack of code coverage. To bring these products up to production grade would be a major effort, and became a distraction in the 1st month of working with the client.

So what happened? Eventually 4 of the 6 products were sunset. Not only did this improve the business’ focus on what they did for customers, but it also helped to concentrate efforts and thus deliver better products. Some may think of the Peanut Butter manifesto by Brad Garlinghouse, a then Yahoo executive who was warning the company of the dangers of not putting enough resources behind its products. This memo can apply to not just companies of Yahoo’s size, but even startups and small businesses. The desire to build lots of products is natural, but can create bigger problems of mediocre products in the future.

My lesson from working with the client was that after looking at the business and all of the products in its portfolio, it would have been better to define a clear scope of what products to work on, which ones to maintain, and which ones to sunset. Doing that early on would have saved some time and effort.

Document, standardise, and automate your workflows

As a language, Javascript offers a lot of rope to hang yourself with. Developers with different programming styles can and will likely write code that they can read, but others will struggle with. In the case of my client, past contract developers had been responsible for whole swathes of the codebase, and through using the tools that only they knew and understood, had created code ghettos as a result.

Introducing linting helped not only to apply some form of standardisation to how the code was written, but also helped to capture errors in the code, as well as spot unused libraries, and even swathes of code that had been lifted from other places, but couldn’t work as variables were not being properly instantiated and used.

Another area that is underrated is the importance of documenting how your products work — Some in the industry are familiar with the principle of making the README file in a project the central place to information on dependencies and installation instructions, but might neglect to document the procedure of seeding data for a local development, or in cases where product features are not yet automated end-to-end, the process for getting certain features to work. It was something I bore in mind, given the size of the team, the fact that I was not a permanent employee there, and the fact that I commutted each day to the office on a bicycle, something that unfortunately runs the risk of death in London.

A new hire to the team helped to bring continous deployment to our applications, automating deployments when tests in our continous integration service (CircleCI) passed. Reducing the manual effort involved with a task as mundane as deploying software saves developers cognitive energy, energy that can be applied to other tasks.

Make your hiring process fast

There has probably never been a better time to be a software developer in London than now. The demand for Node.js developers is high, and as a result finding developers can be difficult. Having interviewed a number of candidates for the development team, I learnt that having a fast decision-making process was crucial. Delaying an interview by a couple of days is enough to lose a good candidate, as we learnt early on. Eventually we recognised the need to make the interview process streamlined and fast, even interviewing 2 candidates in separate rooms at the same time.

Think of hell scenarios and prepare for them

Imagine the worst thing that could happen to a tech business, and then ask “what should I do to prevent this?”, then take preventative action. Startups are prolific for having lax security practices or neglecting to do things like implementing backup systems for their data (don’t believe me? Read “Hatching Twitter” by Nick Bilton).

The 1st day of working at my client, we had to delete an npm package that contained an SSL certificate. We deleted the package off npm, and revoked the SSL certificate. I’d like to say that was the worst thing that could have happened, but months later we had a real hell scenario; a developer accidentally deleted a production database. Thankfully backup systems were in place, and we were able to restore the database. To those who read a horror story on a web site and think “Haha, that’ll never happen to me” — it’s worth checking your assumptions.

Communicate the importance of testing

To those who often lament the need for testing applications and encourage developers not to do it, I’ll ask them if they would be happy to get onto a commercial aircraft where the parts were assembled together and not tested, and yet the plane was deemed airworthy. Recently a bug was found in the software that powers the Boeing 787 Dreamliner, a bug so serious that it could cause loss of control on the aircraft in mid-flight. A former product manager at a previous employer once told me “I don’t have time for tests” — he didn’t last in his job long, and neither did the startup he tried to build, but thankfully no one died.

Using Istanbul for code coverage is the best way to get visibility on the problem, and was one of the first tools I put into the codebase at my client. It highlighted areas where code had been written without any testing, and upon discussing the development approach with current and past employers of the client, learnt that the approach had been to develop prototypes and then put them straight into production.

There are 2 things to do in that case; firstly, communicate the importance of testing to your client, and secondly to make testing applications a solid component of the engineering culture. Keep an eye on code coverage. Capturing bugs before your product’s customers experiences them is the difference between having customers and losing them. We learnt this first-hand when a database hosting provider of ours were unable to provide us with a database at the specified size due to a bug in their provisioning software. We moved all of the databases hosted there to another service.

Summary

The experience of helping my client get to a better place has been hugely rewarding. Building a tech team is a difficult job, but one that with the right level of focus and approach can lead to great results, and provide something to look back on with pride.