4 ms·

I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking abou

I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking about it here. Instead of an essay, I'll use a modern writing format: the pithy list. 1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success. It's a very complex juggling act that most people are thrown into with no training, because training for the technical aspects is so bad. 2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first. 3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers? Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features. 4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter! It contradicts at least half of what the prior argument said.

tachyoff 9y ago
This is well-said. To add some anecdata, I work in a “managerless” organization. It sucks. It’s hard or impossible to make certain changes because nobody has any authority to do things that aren’t necessarily politically sexy (e.g. fixing bad security or setting up asset management). There’s also this expectation that if you want to do something, you can just do it. This sounds great on paper, until you realize that doing things like managing infrastructure is a full-time job for an entire team, and not a “once in a while” position for someone with little experience. I’d love to go the extra mile, but I only have 40 hours or so in my work week, and I’m busy with my actual assigned tasks. There needs to be a good balance (obviously too much red tape is counterproductive). Having managers can be nice when it explicitly assigns roles and responsibilities to a group, because that means not only are there dedicated people for certain tasks, but presumably they have a modicum of power to get things done. It also makes it plainly obvious whom you talk to if you need, say, a new laptop, or a printer set up, or a VPN account. Without managers you get company-wide emails like “who controls our website? I need to update something.”
lmm 9y ago
> I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking about it here. Well, put it this way: I've worked in more- and less management-oriented companies, and have found that those that were less heavily managed were both better working experiences for me and more effective as businesses. > 1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success. If managers fail because the role is too hard for them, we can't expect to get better people, we need to make the role easier. Some of those activities can be separated (e.g. having distinct "team tech lead" and "team line manager" positions), line employees can be empowered to do some of them themselves (personal development), and some simply don't deliver enough value to be worth doing at all (maintaining technical roadmaps). > 2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first. I think it's entirely reasonable for them to write from their own experience rather than mixing first- and second-hand information in the same essay. Their essay makes a positive contribution to the conversation; concrete experiences of failure of alternative approaches would also be a positive contribution (far more so than low-content "they didn't research" complaints). > 3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers? You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action). Better to give teams responsibility for delivery of client-facing functionality and have shared ownership of any common code; you write the functionality you need for the features you need. If you have a layer that really creates enough value to be worth other teams using it as a product, treat it as an actual product (ideally make it an actual product that you sell), and have a client-vendor-like relationship. Otherwise, a certain level of duplication of effort ends up being much less of a cost than constant between-team coordination would be. > Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features. You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo". (Of course occasionally a specific feature will require deep technical coordination with another team. But that coordination is best done by the person with the responsibility for delivering that individual feature - the line worker.) > 4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter! Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves - they're the people who will have the information they need to make those decisions. Software architecture is a lot more flexible than people tend to think; even on a large codebase delivering complex functionality, it's surprisingly easy to make radical architectural changes, and often the biggest impediment to those is well-meaning "architectural design" that exists solely due to management imposition rather than being driven by any actual functional requirements.

tachyoff 9y ago

This is well-said. To add some anecdata, I work in a “managerless” organization. It sucks. It’s hard or impossible to make certain changes because nobody has any authority to do things that aren’t necessarily politically sexy (e.g. fixing bad security or setting up asset management). There’s also this expectation that if you want to do something, you can just do it. This sounds great on paper, until you realize that doing things like managing infrastructure is a full-time job for an entire team, and not a “once in a while” position for someone with little experience. I’d love to go the extra mile, but I only have 40 hours or so in my work week, and I’m busy with my actual assigned tasks. There needs to be a good balance (obviously too much red tape is counterproductive). Having managers can be nice when it explicitly assigns roles and responsibilities to a group, because that means not only are there dedicated people for certain tasks, but presumably they have a modicum of power to get things done. It also makes it plainly obvious whom you talk to if you need, say, a new laptop, or a printer set up, or a VPN account. Without managers you get company-wide emails like “who controls our website? I need to update something.”

lmm 9y ago

> I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking about it here. Well, put it this way: I've worked in more- and less management-oriented companies, and have found that those that were less heavily managed were both better working experiences for me and more effective as businesses. > 1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success. If managers fail because the role is too hard for them, we can't expect to get better people, we need to make the role easier. Some of those activities can be separated (e.g. having distinct "team tech lead" and "team line manager" positions), line employees can be empowered to do some of them themselves (personal development), and some simply don't deliver enough value to be worth doing at all (maintaining technical roadmaps). > 2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first. I think it's entirely reasonable for them to write from their own experience rather than mixing first- and second-hand information in the same essay. Their essay makes a positive contribution to the conversation; concrete experiences of failure of alternative approaches would also be a positive contribution (far more so than low-content "they didn't research" complaints). > 3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers? You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action). Better to give teams responsibility for delivery of client-facing functionality and have shared ownership of any common code; you write the functionality you need for the features you need. If you have a layer that really creates enough value to be worth other teams using it as a product, treat it as an actual product (ideally make it an actual product that you sell), and have a client-vendor-like relationship. Otherwise, a certain level of duplication of effort ends up being much less of a cost than constant between-team coordination would be. > Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features. You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo". (Of course occasionally a specific feature will require deep technical coordination with another team. But that coordination is best done by the person with the responsibility for delivering that individual feature - the line worker.) > 4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter! Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves - they're the people who will have the information they need to make those decisions. Software architecture is a lot more flexible than people tend to think; even on a large codebase delivering complex functionality, it's surprisingly easy to make radical architectural changes, and often the biggest impediment to those is well-meaning "architectural design" that exists solely due to management imposition rather than being driven by any actual functional requirements.