In software world we can try to slim down career progression of developers into two different tracks, a technical track and a business driven track. Which track one chooses usually comes down to an individual. That is, in a perfect world where humans would be able to take the career track they would want to. I beliveve it comes down to early decisions on which company one has chosen to work for as much as individual’s selfish aspirations. There are two kinds of programmers in this profession. There are also two kinds of companies a developer can work for [1]. I believe this duality has a massive effect on software quality. Depending on business model, that might eventually affect the bottom line of the company.

We can split software developers to ones who have a passion towards what they are doing and ones who don’t. In this case when I talk about passion I’m specifically meaning the passion towards technology and all technical aspects of programming. Passionate people tend to want to learn more about what they are doing and become better. They want to specialize into individual languages or techniques, subsystems or niches within their programming universe or the whole profession as a whole. The ones who are not so keen or passionate about the profession tend to shift their focus towards business and domain specific things.

Similarly we can split companies into technologically driven (or even competent) companies and traditionally driven companies. Traditional companies are driven by traditional business minds who tend to steer their companies in a non-technical manner. Technologically competent companies understand tech and are able to use that to their advantage.

This kind of model makes a big difference in employee careers within companies. The traditionally driven company does not usually have a strong technical track. The lack of progression path for technical people means that the only way for promotions is usually a managerial route. Ways to get forward in companies like these tend to be tightly coupled with individual’s domain knowledge. Because of that dependency to domain knowledge career advancement tends to go hand in hand with the number years within the company. A traditional company also has a tendency to overlook technical track and advancement on the technical ladder. This affects the quality indirectly because of recruitment and competent employee retention. If a company is dependant on software, that puts it into a disadvantageous position.

Technically minded employees are usually better at producing quality product than their non-passionate counterparts[2]. Even though a good value is usually attained to a business from each technical employee, it is also usually always not as much as it would be in an optimal situation. Of course we can think of value leakage coming from onboarding process and employee’s ramp-up time when joining a new company, but this ramp-up might not be the biggest leak. If we consider that a top talented developer eventually rises in to a position within its new team where he or she is respected by surrounding colleagues, a lot of teams technical decisions flow through this passionate developer. Because of this the ramp-up might not actually affect only that new technical developer. Biggest hurdle could be that the whole team might need to jump on their own startup ramps.

Depending on the team, this might have a massive detremental effect. Especially if the team consist of highly “specialized” people who have good domain knowledge but lack general understanding of the technical aspects of the profession at large. A non-passionate developers journey to ramp-up on new things is usually much steeper than techical ones’.

For companies it might be beneficial to actually not hire the best technically talented developers because of this case. Introduction of new (objectively better) techniques, updgrading of systems and technically more complete, solid and robust (and therefore possibly more complex) approaches could have bad effects on short term roadmap. That coupled with the impeding unhappiness, boredom and lack of career paths to the technical employee, leading to a short tenure is a difficult question to ponder about. The other side of the coin is to think about the health of the technical product itself. If a team consist of non-passionate developers, the product itself might slowly succumb to software entropy and eventually become a burden.

How would you build a perfect team? How would you scale that to a full company?

[1] Note that I am not including the entrepreneur track on this count on purpose. That is a different story altogether.

[2] I’m omitting managerial and business driven issues from this equation for now (because that matches my narrative better), for safety net we can assume that technical people have good managers driving them to make the right business decision.