Waiting and waiting…

The majority of cases of disappointing software results I see are the result of too little design or too few skills on the team.  For most software owners and businesses, the temptation to get started with coding as soon as possible leads to rapid development and often uneven and poor results.  But recently I’ve been working with a startup that is at the other extreme.  This company had developed and launched a minimum viable product and gotten into the market.   They had proved their concept, were generating revenue and were growing.  But their software had become a drag on growth it was not flexible, scalable and the basis for growth.  This was not a surprise and everyone agreed on the need to re-write the MVP and create a stable platform for more rapid growth and functional expansion but they spent too long spinning their wheels and not getting started.

After some digging I helped the leadership understand that some of them were letting their search for the “best team” and the right design get in the way of making progress.

On the design front I was impressed that what they had done was analyze enough of the core functions to develop a strong flexible data model.  That will really enable them to effectively implement an agile development approach.  In my experience iterative and evolutionary development through rapid releases is a great way to build functionality but often gets hung up on poor data design that requires future releases to either have data conversion or complex versioning of schemas.  In this company they were really ready to begin building functionality with a view to being ready to support future requirements.

The other challenge was a lack of agreement among the leadership on how to build their development team.  How many team members had to be on-staff and how many could come from contractors or partners (e.g. nearshore or offshore developers)?  For the people on-staff, there was also a lack of agreement on the skills required, and frankly a search for too many perfect people.

The use of offshore/nearshore in startups is considered a poor practice by some pundits and investors for reasons both good and poor.  In my opinion startups have to control their destiny and have full control of their strategy and key intellectual property.  But that doesn’t mean they have to do everything with 100% of their teams sitting in expensive real estate.  There is some intellectual snobbery around – some “experts” say things like “well, those developers from (fill in the blank) are fine for some things but not innovative software development”.   It is true that startups need good partners and need to avoid spending too much time managing the complexity of multi-team and virtual development.  But in some cases it’s the right answer, and in most cases it’s part of the answer.

Searching for the perfect people is a different problem.  Everyone wants the best people on their team, but all good teams have a mix of people with different levels of skill (and anyone who says they have teams with only the best people is BS’ing.)  I think that a software company has to balance getting the right people with waiting too long for the right candidate.  I helped this company map out a strategy to get moving on their development and begin building the team in ways that were flexible and open to change and improvement as they grow and expand.

In the end, I think that was the key insight.  Startups are not like legacy enterprises where every decision has to be weighed carefully since change is hard and complex.  Everything changes in a startup software company every six months so don’t try to plan for 3 years in the future. It’s impossible, get good people and partners and get started.  Get everyone excited about being part of a dynamic company and incent them to change as the company grows.

I’ll be working with them in the upcoming months as they get their new product launched and will post an update on how we are doing.