What I learned running a failed dev shop

The web development department in the Philippines

I ran a dev shop in the Philippines for more than three years, and I’d like to share what I learned from failing.

Most of these lessons apply to developing software and selling it, but they’re specifically geared toward dev shops or IT consultancies.

Have measurable metrics for success

Have relevant metrics to ensure that people are actually moving the metrics that they need to. This is why many companies are investing millions into making dashboards to monitor KPIs.

The real challenge is in selecting the correct metrics. It is possible to be so laser-focused on pushing the needle on KPIs that people don’t stop to question if moving a certain data point is actually the most effective way to help the company.

These are some of the ones we’ve decided to use:

During development

Team velocity : Estimate how many weeks it would typically take to finish the project. Set milestones by using percentages to reflect the project’s progress per day. This is a non-objective metric and should not be used to evaluate the team’s performance, as it’s just a way to see whether they are hitting the goals they’ve set for themselves.

Open/close rates : See how quickly open issues are closed. If they are closed right away, it means that the architecture was done well. It could also mean that the team is able to efficiently solve the issues. This metric helps you see whether your architecture is off or whether your team is unable to easily rework the codebase.

Update cycle time : Track how efficiently your team can get back to a client regarding a requested change. This helps you identify flaws in either communication with a client or overall development practices.

Tools you could or probably already use

During production

MTBF (mean time between failures):  Track how long it takes to patch up errors and measure the time between when the error happens and when it is solved. If this number is very high, it’s either the team found the issue quickly or they put out the fire too slowly.

Understand the project’s purpose

Be precise in sharing and interpreting technical ideas

Push for rapid prototyping

Ride the highs, but stay lean

Enjoy the process