This guide is intended to be a one stop shop for entrepreneurs who have the skills needed to operate and grow a business, but often find themselves in situations where they are spending too much time managing and handling technical people. In this article, I will give an overview of what it takes to build a software development team from scratch, and grow it to the point it becomes self-managing.
The Three Pillars For Building Great Software
The first thing you need to know is that building great software is a 3 step process:
- Hire The Right People: No matter how hard you try, if you don’t have the right people on board, you will lose.
- Help Them Thrive: As an entrepreneur, your best bet is to create a culture that maximizes your team’s performance and passion about their work.
- Stay Out Of The Way: Creating processes will help you guide your team to doing things your way, without requiring you to closely monitor the situation
Surprised I haven’t mentioned great code? Well, keep in mind that great code is the result of the above. Focusing on creating good code without passing through the above pillars is a recipe for failure.
Step 1: Build Your Dream Team
Building a great team is an art and a science. It involves following a series of steps in order to find the right people. However, after you have shortlisted your ideal candidates, it’s up to you to judge whether you want to hire that person or not. Here’s how you do it:
A. Define The Reasons You’re Hiring
Know why you’re hiring someone to join your team. Sure, you might need to build your website, but why are you building it? What is its role? Is it there to help you generate more sales, to give your existing clients complimentary access for products they already purchased offline…. The more specific you can get, the better.
For example, if you’re looking to impress potential investors, you might need someone with great UI skills and has been involved with a startup in the past. If you’re building an API interface for your IoT device, you would need someone with lots of backend expertise. You also want them to perform well under stress, because as you’re first building your application, you can expect it to break from time to time.
Once you know the reasons you’re hiring, it’s time to hire the right candidates.
B. How To Hire The Right Candidates
You can either hire remote or onsite candidates. Each has its pros and cons. Personally, my whole team is remotely based, because the burden of managing a local team does not add any value to my business. However, if you’re operating an application with sensitive data for example, you would want to consider a local team.
In this article, I’m mostly covering remote teams, but the same principles apply. This is the process that has successfully helped me hire more than a hundred employee over a decade. I’ve refined it over the years and it rarely fails these days. Here’s how to do it:
- Put yourself in your ideal candidate’s shoe: Ask yourself why would they want to work with you, and what skills & personal qualities they would have.
- Write a job description that speaks directly to your ideal candidate: Show your personality, and don’t stick to rigid job description writing etiquette. Write as if you were speaking directly to your ideal candidate.
- Post your job description on Upwork: You can use other marketplaces or job boards, but I personally find Upwork the fastest and easiest way to hire. I can get someone hired in less than a couple of hours from my initial job post.
- Shortlist to 3 candidates based on the following criteria:
- Ability to Communicate: Did they take the time to write a personal reply or are they just copying and pasting a template for every job post they see?
- Their Motive: Are they passionate about working with you, or do you already feel their disconnection?
- Their Passion: Check their Upwork, LinkedIn and website. Does it look like they love or hate their job?
- Ability to learn new skills: For long-term hires, check if they have worked with lots of technologies and tools during their career. You don’t want someone to know your particular technology, but is unable to evolve as your company’s needs evolve.
- Ask for a Skype interview: If they refuse, they aren’t your ideal candidate. It doesn’t matter how good their accent is, what matters is their ability to step outside their comfort zone and have a phone/video call. There is an exception for programmers, since most of their work would be text-based. Still, I highly encourage you have a one min video call with them, to make sure they are who they claim to be. (Sometimes people post fake profiles in order to get jobs they wouldn’t otherwise)
- Hire Your Hero: By now, you should clearly have a winner. Go ahead and hire them. If you have two candidates and you’re not sure which one to hire, go with your intuition, as it usually works.
Step 2: Coach Your Dream Team
After you have hired the right people, you need to empower them to get the job done. Since these are people you believe in, you should give them as much control as possible, while offering them processes to follow. In short, processes are step by step documentations that everyone needs to follow in order to achieve a certain task. Here are some general guidelines on the most common areas you need to create processes for, and some quick recommendations:
When it comes to coding, there are mainly three things your developers need to understand:
- Your Coding Standards: This details how your code should be exactly written. Don’t try to reinvent the wheel, as there are already lots of good coding standards for almost every programming language and framework out there. For example, here are WordPress’s Coding Standards . However, write a process to insure that your coding standards are being met. For example, I would personally state that a senior developer should check the coding standards every Friday. If I have more than one senior developer, a different developer will examine the code very week.
- Your Development Workflow: This is how your development process should take place. It would be hard to illustrate this in words, so here’s an image that displays a typical workflow many of my clients use
- Your Current Setup: Always have documentation for your current setup. I can’t stress this enough. Although existing developers can help new developers get up and running, almost always they forget to mention some important details to them. Letting developers figure it out by themselves is a waste of time. Here is what your documentation should include:
- Technologies used: Are you using a LAMP stack, RoR, a NoSQL data store, Redis as a caching system… Have your lead developer write all of this. A newly hired developer reading this documentation should be able to understand your system at a glance
- Tools Used: State the tools that are used to get the job done. For example, you might be using Nagios to monitor your servers, NewRelic to optimize the performance of your app… Mention them here.
Having such guidelines will provide efficient communication and save everyone from playing the blame game when problems arise. Here are three things you need to create processes for:
- Define Communication Channels Roles: Every team must have a bug reporting tools such as Github, and a communication tool such as Slack. In my current setup, Github is exclusively used to report and discuss bugs. Anything else goes into Slack. If a team member tries to use Slack to report a bug, they are gently instructed to report it via github.
- How to properly report bugs: Improperly reported bugs have the potential to waste time more than anything else. One improperly reported bug can require lots of back and forth. People would be “discussing” the bug instead of actually fixing it. Here is how to properly report bugs:
- List the steps needed to reproduce the bug
- State the current output: In other words, what is the result you’re getting
- State the desired output: What is the output you should be getting
- Add a screenshot if helpful
That’s all it takes. With this approach, you would eliminate 90% of time wasted “discussing” bugs. Here is a sample bug report in action:
Step 3: Observe and Step Up If Needed
That’s it. Now all you need is to give up control. For the first few months, keep a close eye on the situation. If you’re not technical enough to understand everything that is going on, have a senior developer explain everything to you.
This is your baby now. It has to learn to walk, and you should only step up if you’re really needed. As the team continues to grow, you should exert less and less control. As an entrepreneur, you want to spend more time growing your business, not dabble with technical stuff.