Working with software engineering teams in startup
Throughout my career, as a non-technical person, I gained a lot of exposure working with software engineering teams in various startups. In this short 3 minutes read, I want to share some of my observations as food for thought for us who are working with or inside a software engineering team. I hope that this leaves us, non-coder, with the curiosity to learn more for a better working environment.
Let’s think about how we measure team performance, and how developing software is often seen as a project instead of an ongoing process.
Engineering Team Perceived Performance
Oftentimes, software engineering teams are measured by their ability to complete specific projects/features within a given timeline, or how many features they can develop. This is usually the case especially when startups are expected to grow significantly in a tight timeline. Engineering teams are constantly pressured to deliver fast, they need to finish their laundry list of features.
If the team can deliver the list of features before their deadline, it’s all good, but if they cannot, they are not performing well. This drives the team to burn out. Over time the performance will decline, new features will be delivered slower even with larger teams, and everyone will feel that the engineering team is underperforming without knowing exactly what causes the decline. Even worse, they might be actually working harder than before.
While the company is racing to launch more features, the engineers, given the tight timeline that they have, will find ways to make their own life easier. Engineers make it quicker for them today, but slow down everyone else who has to deal with the code in the future, including themselves. We call these shortcuts “tech debt”, the price we need to pay in the future when development is done in a rush with insufficient planning.
There are already a lot of resources to find on the internet about this, for example, an article by Martin Fowler titled “Is High-Quality Software Worth the Cost?” settling the confusion between spending time on improving the quality of software versus concentrating on releasing more features. The choices assume that quality versus cost is a trade-off, but this trade-off does not apply to software development.
It is not to say that this perceived performance is bad, business cares about the growth, they want to deliver more to their customers, it’s a good thing. What makes this worse is when the features built are not actually valuable while the engineering team accumulates tons of tech debt, which is most of the time.
To prevent that, the business and engineering team should be mindful of their roles. The goal is to deliver something valuable for the business while we minimize tech debt so we can deliver more valuable products faster. Everyone needs to be aligned on the full context of the product they want to build — the strategic context of what problem to be solved, what solution we want to build, and the technological limitations.
To move everyone to that shared goal, which is some metrics related to a business outcome, we need to see software development not as a one-off project, but as an ongoing process. Teams should be organized with that mindset as the principle.
Developing software is not a project, it is an ongoing process
We come to the idea that we need to treat software development as an ongoing process, not a project. Here is a really good article about this idea: Products Over Projects.
The article really explains in detail what it means to treat your software development as an ongoing process in “Product-Mode”, from what gets funded, the benefits, to the adoption challenges. It already covers the topic really well and I recommend reading it to really understand the concept. Now I want to highlight the key difference: ownership.
When no one really owns the software, they build it with the intent to ship the project. The team is formed for the project only, and after the project is done they will work on another project. This is also the case when we hire a software house/freelance developer to build the software for us. They are not responsible for the business impact.
If we treat development as an ongoing process, a product team is formed to answer business problems, not to deliver a list of features. They are responsible for the business outcome of their product/solution. They’re not only building the product, they run the product.
Engineers get to understand more about what they are building and why they are doing it, instead of aimlessly finishing a list. When they write code they will be more mindful, better code quality, better documentation. Tech debt is inevitable, but there will be an effort to minimize it to avoid the buildup. Over time, they will build more expertise in the domain, they will build a better solution until they will lead innovation in their area.
Rome was not built in a day, it takes iterations to build great software, it requires a properly empowered & skilled team owning the process to run through those iterations, and management must understand this concept to enable their product team to do their best work.
Hyperjump Update!
We just launched our free and open source synthetic monitoring tool called Monika on Product Hunt! Your review and upvote are greatly appreciated! 🤝
Hyperjump is an open-source-first company providing engineering excellence service. We aim to build and commercialize open-source tools to help companies streamline, simplify, and secure the most important aspects of their modern DevOps practices.
