2 ms·

> This is hard to explain on non-technical terms though, and it's a hard sell for business and marketing oriented people, mostly because they can't immediately

> This is hard to explain on non-technical terms though, and it's a hard sell for business and marketing oriented people, mostly because they can't immediately connect the dots I think managers are usually capable pf connecting the dots. I guess the problem is that for managerial roles it is very hard to distinguish between engineers who are slow because they are careful and methodical (thus enabling future growth) and engineers who are slow because they are bad or lazy or prone to bikeshedding (thus enabling nothing). Since the cost of error here is very high, they tend to err on the side of caution,and discourage slowness altogether.

proc0 2y ago
The reason that's a problem is because of how most companies structure their engineering roles. Individual contributors are the bottom part of the metaphorical pyramid. IC engineers are meant to be managed because by definition the progression of the career is to move towards doing less code and managing projects and people... that means that you will not have high level contributors that you can trust because they're all doing more management work. In other words companies don't see the value of highly experienced code contributors, because writing code is seen as the relatively easy part of the job, and the engineers who manage people are "force multipliers", etc. But in my opinion this is just a structure that enables the 'move fast' mentality, and the 'scale by adding people' mentality, both of which can be fine but the consequence is code that breaks, is unreliable, and hard to maintain.