How to effectively build software
Some principles I follow to build productive dev teams
We just released Latitude 1.0! A product mostly built by a team of 2 developers in under 6 months that doesn't skim on features: realtime collaboration, support for multiple warehouses, a canvas editor, automatic dashboard generation, and whatnot. This kind of development speed often surprises people, so I've compiled a set of principles I follow to make the most out of my teams.
Startups need to maximise the return on each hire. By hiring engineers that can do 80% of the job a specialist does, but across your whole stack, you ensure the compounded productivity of your team is higher than if you had a specialist for each area.
Hire people with a focus on business
Avoid hiring developers who are interested in the tech behind the product rather than the product or the business themselves. Their lack of care for the business will eventually clash with the company's focus on bringing value to customers. As a rule of thumb, I've found that developers who want to become founders themselves are often excellent hires.
Some aspects are often necessary but not core to the daily work of your dev team. In Latitude’s case, for example, it’s been the public pages. In those cases, consider using an out-of-the-box SaaS solution or contracting a by-the-hour freelancer.
Stop playing with new toys
Developers are prone to spend countless hours tinkering with the latest technology du jour. Avoid this. The job of a tech lead is to pick the few set of technologies that will become the bedrock of the team's software development efforts. From there, the team should focus on delivering the most value to customers, and that almost never involves trying that fancy new database.
Give room for choice
Developers don't want to feel like machines that get handed human readable instructions and output code on the other end. Give them the freedom to choose what to work on within the constraints of you product roadmap. Maybe a developer has expressed an interest on a particular part of your codebase for a couple of weeks, make sure their next epic touches that part.
Wind down time
Developers cannot be in feature-building mode for months at a time. Always be mindful of giving all your team members some breathing room between epics. You can use these time windows to fix bugs, develop small improvements, or do some tangential work that still brings value to customers.
Developers need to feel their work has an impact, and the best kind of impact is customers using the features they've developed. Surface this information to them.
Don't place blame
Startup work is based on ownership; Each developer has an outsized responsibility on the product working properly. When something goes haywire, do not place blame. Acknowledge everyone is trying to do their best, fix the issue, and move on. Otherwise, people will start fearing the job.
Think of it like a control system
Control systems rely on error signals to correct their input in order to achieve a desired output. Product development is a control system: the company objectives are the desired output, the error signal is a compendium of customer feedback, employee satisfaction, team productivity, growth metrics, and some other minor stuff.
Every once in a while take a step back, look at the overall system, and think if something is broken in it.