Things learned from being part of a failed startup

Root Cause Analysis

After the company closed its doors I asked the team and the managing directors to carry out a root cause analysis of what decisions and factors led to the situation we found ourselves in. This involved listing out a few topics we wanted to discuss and for each drawing up a fishbone (ishikawa) diagram within which we listed items for discussion on each of the six stems which represent:

  • Machines: The systems and processes we used to help us with the topic
  • People: The roles in the team that were involved in the topic
  • Materials: The input the team received around the topic
  • Measurements: How the team measured their effectiveness around the topic
  • Environment: The factors external to the team around the topic

Quality

Ultimately there was a lack of ownership over quality, mostly due to a focus on feature delivery but also due to management trusting people to be developing with quality in mind and not building quality checks into the specification.

Sacrificed quality for feature delivery

The way the company conducted itself was to sell the idea of the product to a client and then to build the product they wanted quickly, instead of building a product and getting customers this way. This meant a lack of a roadmap or solid specification and ultimately meant that the development team were focused on churning out features to keep clients happy without putting the appropriate quality checks in place to ensure these features were performing as intended.

No one took ownership over quality

While the company frantically dashed to get features out to customers we never bothered to measure the quality of the work being done. In the early days quality assurance was part of the CTO’s duties but the activities this person did were not scrutinised by the other senior managers which meant when they failed to get the development team to take ownership of the quality of the code they were writing no one picked up on this.

We didn’t practice iterative development as a company

The company conducted most of its work within the context of iterative development, however this only really ever applied to the development team. This meant the business, infrastructure and client sides of the equation were all working at different paces to that of the development team and meant we were often out of sync with each other.

We didn’t measure ourselves or our processes

In the early days of the company we practiced Scrum but never paid any attention to the ceremonies of Scrum apart from the daily scrum / stand up, we didn’t have retrospectives and we most certainly didn’t use burn down/up charts to show our performance in the sprint — to be honest we didn’t even really use any notion of a sprint. This meant that we were unable to really understand how we conducted the work and how to improve our efforts.

Product Development

The initial business plan was to create a platform on which the plan was to build a series of products. This would allow for the company to quickly create a portfolio of products to be sold with the platform allowing for each product to integrate with each other. However due to a lack of ownership for these products and quality issues the products took too long to deliver and suffered from bad quality which in turn cost us the clients who were putting up the cash to fund the product development. This lack of product owner meant that there was often no single person in charge of making executive decisions on how to evolve the products or platform.

There was a product but no product team behind it

Due to the way that the product was developed there was never a product centric view of the work and no clear roadmap. This way of working combined with no clear product owner meant that the company struggled to effectively build a product. While we had Business Analyst, CTO/Software Development Manager and User Experience staff in the company we never truly managed to work together to form a product team.

The solution to having no clear product owner was to delegate to a design committee

The company’s way of dealing with the lack of product ownership was to move this role to a Community Interest Company (CIC) which would be made up of a group of users of the software who would hold meetings and decide as a group on what features would be built into future releases of the product. The CIC structure never materialised due to a lack of client’s to start it as well as a lack of help from a national programme the product was part of, though I do wonder how well this would have worked as essentially this leads to design by committee.

We never really validated the features we developed

As stated in the quality section above we never validated the features we built with the end user before shipping to production but this lack of user input is also true of the product development process too. As we focused on building the product on the requirements given to us by clients who ultimately funded the development (having been sold the notion of these features existing) we never got a full user centric view of these features and never validated that the requirements of the one user group we did a pilot for were in fact universal. This of course led to poor architectural decisions as we only had part of the picture to work with and ultimately meant there was quite a lot of changes between customers as well as the implementation of the product having more of a change management element than was anticipated.

Architecture

We made two iterations of the product architecture but both of them started life as Rapid Application Development (RAD) prototypes that were then built upon instead of these RADs being used to learn from. The second iteration was architected by a senior developer who worked alone on the architecture and never validated the scalability, this was due to a lack of technical acceptance criteria and trust the company had in people doing their job properly. The silo the senior developer created led to issues with the other developers working within the design as the senior developer had made a few performance penalty inducing decisions.

We made RADs the foundations of what we built instead of using them to test ideas

While I don’t necessarily think building on a RAD was the entire reason for the architectural issues we encountered I do feel our lack of proper validation of the RAD before jumping onboard with this solution was a bad idea. In both iterations of the architecture we failed to build more than one RAD and we failed to test the RADs non-functional abilities such as how it handled under heavy load.

Solution was architected by one person not a team

As the first iteration of the architecture was in production the company hired a senior developer to architect a new solution based on the issues that where discovered from use of the first iteration. The senior developer they hired was given a job and seniority based on the fact they had one years experience working with the framework that met the business needs of the company but they were not a senior developer in the way they acted towards more junior members of staff. The senior developer in question spent two months in a silo thinking about the solution they were creating before announcing it complete and everyone moving the product over to the solution they created.

Staff and Culture

While I have definitely benefited from the lenience the senior management team showed to the people they hired it’s also true that this did mean that people who should have been let go were not fired in a timely manner due to a lack of performance management. The culture of the company was something that we had to change over time, at the start the emphasis was on hacking things to get them to work but once I started leading the team we changed the culture to reflect the benefits of evidence based engineering over hacking, this also changed the way the company looked at the responsibilities of the senior developer towards more of a coaching role.

Staff were not performance managed

During my time in the company I had an appraisal after the first three months then one after two years. The lack of a formal feedback loop on the performance of staff as well as the lack of proper retrospectives until I introduced Scrum meant that unless a staff member was very self-motivated then there was very little to show that staff were working in the right direction. This ties in with the trusting of staff to do their job that led to people exploiting this trust and wasting company resources and money as there were no formal processes in place to show people were underperforming.

The culture of the company at the start was around hacking

Although when I started to lead and manage the team I changed the culture of (at least) the development team to be one of evidence based engineering the initial culture was around hacking software together to show that we could do things the big players in the industry could do very quickly and for far less money. The problem with this approach, as I’m sure anyone who has bought a imitation of a luxury item will tell you, is that it does not hold up in the long run. I’m relatively sure this culture is what led to a lack of quality in the development work carried out in those early days.

In conclusion

Here’s the TL;DR:

  • Don’t expect people to do everything to the same high standards you have, if you want those standards then measure their output and work with them to meet them
  • If you’re going to practice iterative development then don’t focus solely on the development team include all relevant parties in the iteration to reduce communication issues
  • Validate your potential features and architectural decisions to ensure they are the going to do the job correctly

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Colin Wren

Colin Wren

Currently building reciprocal.dev. Interested in building shared understanding, Automated Testing, Dev practises, Metal, Chiptune. All views my own.