Technical choices have non-technical consequences. Here’s why engineering leaders need to factor in business needs.
Have you ever known an engineer to thrive in one company, receive rave reviews, and then switch jobs to end up clashing with a new team?
Maybe this engineer has a particular set of assumptions about the “right way” to do software engineering that runs adrift of their new team’s practices. Maybe they keep clashing with teammates over CI failures or resistance to writing tests. Or, maybe they care deeply about quality and are disheartened by a team that is more focused on shipping “good enough” MVP features at max speed.