Startups like other companies will at some point have employee turnover. When this happens among your development team you will need to invest the time to help them with :
– Understand the startup environment
– Gathering and using the startups technical documentation
– Understanding the startups positioning and goals
– Learning the development environment so they can participate in the product road map
We all know that training and incorporating someone new can take reduce productivity. This knowledge catch-up process usually takes weeks and can be streamlined with a bit of work ahead of time or during the very first day.
Even if the new recruit has worked in an another startup environment you should spend the first few hours talking about the startup’s business model. Who do we do business with, who are our customers, who are our key partners, how did we found out about them and what is the customer acquisition process. Having a developer in your team than doesn’t understand the startup’s goals and business model is like asking for someone to sell a product without knowing anything about what he is selling. Many of the choices your developer will face will need not to be made solely on technical requirements but also considering the available resources with the current skill sets available. He will also need to keep in mind the business objectives that have been set.
Once the new developer understands the startup’s business model and objectives you can begin training them in how the team works together on a daily basis to meet the customer’s needs. This step is vitally important. I have found that by sharing a simple visual diagram that sums up the process of how information and what needs to be done flows between customers, partners and coworkers helps them understand what takes place.
If the customer submits a request for service from the website… Who’s is responsible for examining the request and assigning to someone to complete it? How are other team members get information about what is going on? Generally speaking, what are the ins and outs of for all information that moves between customers, partners, and teams.
Having an understanding of the sometimes hectic and complex environment of a startup and understanding everyone’s responsibility is a requirement for any new developer in order to maximize their productivity.
Once your new developer understands the culture and work environment it will be time to share your road-map.
You should share things like:
– What has been done previously
– What is the product’s history
– Why have you made certain business decisions
– What is the current situation with the products strengths and weaknesses
– What new steps or goals do you want to achieve with your new team member
– Why you think that he is the right person to reach those goals
At this point it can be interesting to ask your new developer to share his vision of how he will reach the goals you have asked him to accomplish and his point of view on what he has learned so far. This is to make sure that you have covered everything and that the developer has not misunderstood anything about what you expect and how things are going work on a daily basis. Asking for a summary on what has been said is still one of the best ways to ensure that everyone has the same expectations.
Your new team member is now updated about where your startup currently is on the road-map and where it still needs to go. Finally, you can know talk about their part in the road-map.
It is very important to have at this point all the documentation on:
– Every tool or software you use
– Multiple saas accounts logins
– Servers and software architecture schema
– Access to source repositories ( GIT, SVN, CVS…)
– Bug/Issue tracking processes and tools
– Project management software and methodology
– The deployment process
– The test process
– Customer relationship process (even if you don’t have proper CRM yet)
– Server maintenance process.
– “What we do if …” documentation. (Disaster Recovery Plan)
No matter how confident you are in your new team member. Always make sure that he has the needed support to undertake his new goals. What I usually recommend is to not start a new team member on a new project. He needs to work with others first to completely comprehend how your startup works and his resources in order to be able to bring to the project his previous experience. Feel free to encourage him to propose his own ideas and recommendations in order to improve the project. Having an external point of view can be a great resource, utilize it during your employee’s early days.
This last but not least part is concerns motivation. Most of us are motivated by learning new things, being part of a movement, having dreams we want to pursue. Being part of a startup project is something exciting and it comes with lots of freedom and challenges. A startup is literally the result of the efforts from its cofounders and first employees. Sharing the story of the beginning stages that bring struggles while trying to not only create the product but the startup culture as well must be shared. Tell them Why you’ve build this startup, what led you to this stage? What were your best moments and your major mistakes? Be human, share what you’ve learned and what you want your team to learn as the company goes through this adventure. Beyond that share the startups vision and values. Why this business exists and why is it so meaningful to you and your team.
In other words, the new person you’ve hired is becoming one of the key members that will help catapult your startup to the next level. As a startup you do not only providing a job but a seat in your adventure where the destination is still out there.
I have often found myself recommending to co-founders and their new team members to go through the process above. I have refined this process from multiple experiences while working with and at startups. Having this kind of approach in your hiring practices allow you and your new employee to save several weeks of emails and questions. Have you ever experienced this kind of process? What have you found that worked well and how was it different from the process above? What would you do differently? As always, feel free to ask any questions, share experiences, and leave comments!