Front and second line developers

In working with different software engineers, I've noticed that there are generally two types of developers:

• The first group, which I refer to here as first line developers, like to quickly bring value to the customer. They are very product-focused and excited about delivering features directly to the client. They are usually the ones who are best able to make trade-offs between code quality and business goals and deadlines, even if it means introducing technical debt. They are particularly good at launching new projects and finding the right balance to prove product/market fit.
• The second group, which I call second line developers, are more interested in the long-term maintainability of the application. They like to embrace complexity and think deeply about the architecture of the application so that new features can be added in the future without too much difficulty. They like to work on more technical issues such as debugging, monitoring, observability, incident resolution, or cost reduction. They are particularly good at helping the product, code base, teams, and customer volume grow so as to scale the business.

Note that this distinction does not mean that one group writes tests and the other does not. Or that one group is interested in providing value to customers and the other is not. The software engineers in both groups are business-oriented and both want to bring value to customers (if not, they are not engineers, just coders). The first group does this in a more direct way, while the second group does it by avoiding/reducing incidents, bugs and regressions, as well as maintaining the team's ability to develop new features.

When launching a new start-up, it is essential to hire almost only software engineers from the first group. The company has very few resources and needs to deliver proofs of concept and minimal products quickly to validate what is called "product/market fit." Hiring second-line developers at this point could be problematic because they could easily get bored and anticipate non-issues such as scalability or complex architecture too far in advance.

However, as the company grows, it becomes important to hire more of the second group of engineers to bolster the teams. Otherwise, the customer experience may deteriorate in the future (incidents, regressions, etc.) and feature delivery may slow down due to the difficulty of managing complexity.