Introduction
Fast growing startups face unique difficulties for building development and operation teams. Although I haven't had fully successful experience, I will share my experience across few different startups. There are successes and failures.
Difficulties
There are unique difficulties for building agile/SCRUM/Lean team for fast growing startup. The ones are on top of my list are:
(1) Uncertain about how big team will be in 3 months, 6 months, 12 months
(2) Lots of pressure from business to catch opportunities
(3) There are not enough senior team members which faciliate growth of business
(4) It is hard for business to find right candidates
(5) What is strategy for team growth, splitting team or build a new team
(6) System developed is a "Legacy" system although it just has been developed from 1-2 years ago
Of course, there are lots of others. If you want to share your experience, feel free to post here.
My Solutions
I will post my solutions and ideas here for broad discussion. And hopefully, with that, we can work together to find few best solution fits for several scenarios. Feel free to give critic and feedback. I love to hear them.
Agile Way to Find right candidate
For whatever reason it is, my personal experience with few startups are that team member growth and budget are uncertain. Most of time, recruitment will be managed by top level management who has technology exposures like General Management of Technology, CTO or others.
We have personally tried or experienced following ways:
- Start with contract and then moved as full time
- Have a graduate who gona graduate in next 6 months, and have him onboard fulltime after his/her graduation
- Interview someone and have he/she onboard if he/she is right candidate
- Buy a company for its development team members
Every way has its own advantage and dis-advantage and it fits for different purpose:
(1) Start with a contractor give business an opportunity having a look at candidate's skill set for a high pressure. It fits that there are spike for one or two major projects which have hard due date and current resource can't handle the project anymore.
(2) Have a fresh graduate or someone who gona graduate is big fun and interesting. Most of them love technology and work very hard with my experience. Most of them are willing to stay if company can offer reasonable salary package. It fits for projects which require unique skills. The advantage of this way will be low cost and outcomes are normally very good. The dis-advantage is that there are risks that developers may leave in short time and it takes time educate. If there are enough senior team members, this way will be best going forward. I have successfully mentor most fresh in past 3-4 years.
(3) Have someone full time after interview. I always am keen to recruit right employee instead an employee. For fast growing company, it should never stop looking for a best candidate.
(4) Buy a company which has unique skills that we require. There are many companies who have big budgets are doing these. The advantage is that new team members can pickup skills very quickly. Disadvantage is that costs are too much. Google even just throw product away and have team members to do other things.
The "Agile" way that I want to prompt is to try different choices and add team members one/two at once. My personal preference is (2) because most of time, the outcome is fantastic.
Cope with uncertain of team size
Uncertain of team size has been a big problem for me all the time. But it has been natural for most of startups.
There is a rule that I always follow "always solve current resource shortage" instead of "trying too hard to solve future problem".
I personally find out the "cumulative" diagram are extremely helpful to decide whether current resources can cope with workload that we have.
Senior VS Junior Candidate
For any company, it is good to have as many senior members as possible. But the reality, it is hard to rightful senior candidate for a startup working in niche market. Most of time, senior team members are familiar with other technologies which are different from the technologies you gona to use. At the moment, I am more towards to team members with 0-2 years experience which can be trained to use technologies which you are familiar with.
With my experience, a candidate without experience and lots of passion on technologies and business are far better than a candidate with more than 3 years experience and has not progressed well in career.
But the skills that you need to look out for are:
(1) Communication
(2) Over-Engineering (lots of candidate are intended to do over-engineering. It is hard to change the habit.)
(3) Be able and willing to talk with users directly
(4) Strong skills and knowledge background
Team Growth, Splitting or Build a new team
There are arguments about splitting or build a new team while team grows very quickly. I am more towards splitting team, the following are my points:
(1) The most important part for development to spread is "domain knowledge". Without splitting team, it is very hard to do so esp for startups
(2) The most concerning part for splitting team is bond and connection. If we can keep most of one team unchanged, the impact is small.
My solution for agile team growth are:
(1) Let a team grow to 8-10;
(2) Split 2-3 team members out as base for new team
(3) Try to train new team leader / SCRUM Master while team growth period
Legacy System
The startups that I have worked with have the same problem, a legacy system. There are general two ways to get test coverage up:
(1) Get test written for new jobs
(2) Write a new system from ground up and make sure that at least 95% test coverage
Difficulty of first way is the difficulty in calculate test coverage. But I am strongly towards first way as risk on re-write a system from ground up. But an alternate solution would be enforcing test cases on new jobs on old systems and write test cases on new systems to make sure test coverage if there are architecture problem in old system.
I am personally find that it is very easy to use the first method if you are able to get test coverage for existing system. Ironically, sometimes, I am able to easily calculate test coverage for one system but it is very hard to calculate for another. I just find it is very hard for most PHP systems.
If you are starting new projects and want to choose a framework, you need to choose a framework with test written.
