I am back from coaching summer camp and jumping right into CTO mode for a new project. Part of being a good startup CTO is being able to create a scalable workforce of developers that can get the job done. This means bringing on hand fulls of developers of varying backgrounds and talents and putting them to work efficiently building your product. This is much easier said than done. This post is on some tips and tricks I use to try and speed up that process.

Use Github for more than just Version Control:

I know, I know, I praise Github so much you would think I was their spokesperson. But they earn it.

Github is great for tracking changes to your code base but they come with a lot of other really useful tools. Their Wiki and README.md features are what I am praising at the moment.

The README.md is a text file using markdown formating that you can place at the root of any project. Here you can put all sorts of useful information about your project. It is used a lot in opensource projects but I don't see it used enough in private repos.

Here are some of the things I put in my README.md file:

Setup Instructions:

So new developers do not need me holding their hand as they try to get setup. It is also a good test of how resourceful they are.

Code Anatomy Map:

This folder holds the css, this one the javascript, this one the routes, etc

Common Errors:

If you run into a problem everytime a new developer runs your app and its easy to fix you should write that down so new devs don't need to ask you how to fix it. Remember the goal is to take you, the CTO, out of the equation as much as possible.

Resources:

These are links to any 3rd party resources you are using. It might be a whole library or just a stack overflow post that would be helpful. Sometimes I put these here more as quick links for myself than for the other devs.

Pair them with a senior dev:

Pair them with a senior for guidance.
The senior dev might see this as a waste of their time but what is worse?

• Temporarily wasting a fraction of the senior developers time to ensure that the new developer is at least partially efficient
• Wasting your time instead of the senior devs that could be spent on the big picture.
• Wasting none of the senior devs time but having a completely inefficient and frustrated new developer that you are still paying that may never become proficient.

Break down the architecture into logical pieces.

One of the best things you can do as you grow is to structure your codebase into logical pieces that can be isolated and worked on somewhat independently.

There of course will most likely be some type of core that ties everything together but this is a bad place for a new developer to get their feet wet.

Give them a small piece to start off on, preferably with a language or tech they are familiar with. Let them see how this little peace ties back in with the rest of your technology.

For example I am currently on boarding some new developers that know the webs front end technologies pretty well but don't know much about NodeJS or ExpressJS which we are using on the backend. I am planning on giving them some tasks that involve making Restful API calls to some services I already have written in Node. They can then go through and peak behind the curtain to see how the Node stuff is written and start copying or tweaking what I have done to allow them to start building the new services we need to get the job done.

Side Note - The JavaScript revolution:

The JavaScript revolution where anything that can be written in JS is being written in JS helps. No, its not 100% efficient but the fact that the basic syntaxes and commands are the same across the board really saves a lot of time on the little tedious syntax errors.

Since Javascript is the main language run in any browser it also allows you to hire a far wider range developers. If that have written anything that has run in the browser then they know JavaScript and this should speed up their learning curve with NodeJS.

Encourage fixable mistakes:

I want my developers to be a good balance of collaborative and independent. I have to allow that independence by trusting them and empowering them to make mistakes. Little, fixable mistakes at first so they can learn how to fix them and I can learn how bad they are likely to mess up if I were to give them more independence. To do this keep in mind the following:

Client Barrier:

Make sure that there is a barrier between them and the client. At first that means reviewing their work thoroughly but eventually you will need to push them out of the nest and let them interact with the customer.

Manage Customer Expectations:

When you let the fly a little make sure you manage customer expectation.

If you are consulting building a custom app this means that you be honest and inform the client that you are letting a new developer try something new. I would feel out the client first and make sure they are okay with this. This might even mean discounting your rates or giving a guarantee that you personally will fix any mistakes the junior makes.

If it is a digital product you are working on then you will want to make sure you tell people that the feature they are working on is in alpha. This is obviously much easier than the former.

Conclusion:

Building a scalable dev team capable of hammering out a functional app at break neck speed is not an easy task. These are just some of my tips and tricks. Please feel free to post/email me your own tips and trick on the topic. Good luck to you, now get back out there and ship your product.