build a rich mental model of how software engineering orgs work and be able to use this to change the organization
Are there ways to do this apart from direct experience?
After a little over a year at the startup I switched to from a Large Company, I realized that the engineering org is broken in a way that is not just “growing pains.” Levels are hazy and promotions are unclear, which makes it impossible to work towards greater responsibility / bigger problem areas. Hiring is owned by HR, so engineering has no say in this apart from conducting the actual interviews. Engineers high in the hierarchy, eg. “distinguished engineers”, are mostly focused on their own 1-person projects and almost never interact with other engineers.
I describe this because it took me over a year that all these behaviors are not merely growing pains and that I cannot do anything to change them because I am merely a “code/yaml production resource”. I am now looking for another company (in NYC!) and thinking really hard how to avoid joining another broken engineering organization.
Yes! There’s a bunch of great books out there that are helpful. The Managers Path is probably the best in some sense, but I find it’s kind of dry and easy to miss its points because of the way it’s presented. I highly recommend the blog and books of Michael Lopp. These won’t tell you everything you need to know, some of it you’ll have to figure out for yourself (even if it’s not through direct experience but thinking seriously about how to make an org that functions better), but you can learn a lot from these.
Harvard Business Review is also useful. Not because it’s going to necessarily give you a bunch of good ideas, but because it’s the equivalent of ACM Queue for managers, so you’ll get a sense of how managers think about things and that will be valuable in building up your model.
Are there ways to do this apart from direct experience?
After a little over a year at the startup I switched to from a Large Company, I realized that the engineering org is broken in a way that is not just “growing pains.” Levels are hazy and promotions are unclear, which makes it impossible to work towards greater responsibility / bigger problem areas. Hiring is owned by HR, so engineering has no say in this apart from conducting the actual interviews. Engineers high in the hierarchy, eg. “distinguished engineers”, are mostly focused on their own 1-person projects and almost never interact with other engineers.
I describe this because it took me over a year that all these behaviors are not merely growing pains and that I cannot do anything to change them because I am merely a “code/yaml production resource”. I am now looking for another company (in NYC!) and thinking really hard how to avoid joining another broken engineering organization.
Yes! There’s a bunch of great books out there that are helpful. The Managers Path is probably the best in some sense, but I find it’s kind of dry and easy to miss its points because of the way it’s presented. I highly recommend the blog and books of Michael Lopp. These won’t tell you everything you need to know, some of it you’ll have to figure out for yourself (even if it’s not through direct experience but thinking seriously about how to make an org that functions better), but you can learn a lot from these.
Harvard Business Review is also useful. Not because it’s going to necessarily give you a bunch of good ideas, but because it’s the equivalent of ACM Queue for managers, so you’ll get a sense of how managers think about things and that will be valuable in building up your model.