4 ms·

Well it's my experience that managers almost never think about the product or the customer, and almost never feel the need to justify their focus to the enginee

Well it's my experience that managers almost never think about the product or the customer, and almost never feel the need to justify their focus to the engineers who are (at least sometimes) thinking about the product and the customer. I've never once had a manager say anything along the lines of "I just think we're building a bad experience if we release this early." I have heard them say all sorts of politics like "If we get this out now, then that'll prove massive impact that will free us up politically down the line" Or for example I worked at a known location-sharing startup, and managers gave 0% thought to concerns like "hey is battery life impact worth measuring?" and kept pushing random integrations (like with Italian telecom company) hoping to get some huge amount of customers (which never payed off in my experience). When I picture managers and directors I think of the idiots at Yahoo managing to fail to understand I need more than 15megs of storage or a spam filter (can't imagine what those managers were wasting their time ona), while a company of mostly engineers with scarcely any management builds gmail and eats their whole market.

karmelapple 4y ago
> I've never once had a manager say anything along the lines of "I just think we're building a bad experience if we release this early." Then perhaps you had less-than-great managers, and I could think of a variety of reasons for that. Maybe it was as simple as you claim: no consideration was made to introducing an undercooked user experience. But if a software development manager is green lighting that, likely causing more work for customer service and perhaps sales, I would hope there’s more to the story than that. Maybe this manager didn’t communicate why releasing a bad experience by a specific date was, perhaps, mandatory to fulfill a contractual obligation. Or maybe you were not able to sort that out from the limited amount of information they gave you. Maybe they didn’t see the bad UX as truly as bad as you, and perhaps your team, thought it was. Maybe where you thought the feature’s UX passed the 80/20 rule was different than many customers. I’ve had (product and project, not as often people) managers who have pushed to hold on delivering a half-baked implementation. And I’ve been a manager who has done that. Those better managers exist Did you ever get feedback or do something to reevaluate why the bad experience was shipped? The experiences you describe do sound like clueless folks making calls, but know that there are folks in management positions not just wildly flailing about.
- Aeolun 4y ago
  These are all possible of course, but I’m reminded of the adage that: “The simplest explanation is often the right one.”
- ownagefool 4y ago
  Problem is with this argument is both sides are aruging their group is better. I find whether not you care about outcome usually irrelevant to the title / role. There's a couple of things going on here: - Personal ambition. Usually this is about money, especially the higher up the org you are, but it might also be about becoming a better at tech, or keeping a stable job to pay your mortgage. - Incentives. How the company rewards things it wants. This might be shares, commission, salary, or bonuses. But it's also about how the company measures and manages those things. - Ethics. What you're willing to do to achieve your goals. Both individually, and at an org level. It doesn't take long industry to realise that the few people are actually interested in helping orgs make money. This is shown by developers focusing on irrelevant shit all day long, and it's shown by the lack of incentives and rewards that drive the correct behaviour, so all you get is a whole bunch of personal ambition. Of course, some people do, but when faced with a company that allows people to focus on short sighted personal ambition, they'll either fall in-line or move along.
  - cutemonster 4y ago
    > both sides are aruging their group is better. And/or that the personal work experience they themselves have had, would be representative for people in general. (Not saying that the posters above necessarily did now) > couple of things going on here ... few people are actually interested in helping orgs make mone ... Yes, nicely written :-) Maybe in many cases they are "right" not to care, if the company doesn't contribute meaningfully to society anyway
HWR_14 4y ago
Google deciding to give everyone literally 100x or 66x more free space than their competitors did manage to acquire a lot of the email market, which meant non-negligible hardware costs. It spent three years in internal development of Gmail. I have no idea why you think managers weren't involved in those decisions. Meanwhile, I have no idea if battery life impact is worth measuring in your use-case. My assumption would be "no" because I would imagine the battery life impact would vary too widely to yield useful data and I don't see what I could do with that information anyway other than recommend some people not use the app. But I'm not really thinking deeply about it now, so I'd love to be enlightened. Meanwhile, trying to get more customers is a good thing, even if it fails.
- brazzledazzle 4y ago
  It's probably important to put this into context of Google's views towards management, especially back then. At one point they even experimented (briefly) with having no middle management. My understanding is that they still try to limit the number of managers and their ability to harm the organization by using tactics like higher ratios of developers for each manager. They actively try to reduce negative behaviors like micro-management by middle managers. It's not exactly common for an organization to actively attempt to mitigate the negative aspects of middle management so it's almost an apples to oranges comparison. But since we're on the topic of Google, maybe making management reduction one of an organization's goals is the correct strategy to reduce the bloat and increase the productivity of ICs.
  - treis 4y ago
    >My understanding is that they still try to limit the number of managers IMHO this is really the point. Somebody has to hire devs, run the evaluation/promotion stuff, facilitate communication to/from upper management, and so on. I've just never been to a place that couldn't do that with 1/2 to 1/3 of the EMs they have. For whatever reason the standard is one EM per team. A better ratio is on EM per 2-4 teams.
    - jensensbutton 4y ago
yowlingcat 4y ago
Gmail wasn't just built by a team of "engineers" that ate Yahoo's break fast. There was also a great designer and product manager on the team as well [1]. I have seen engineers hold the misstaken belief that a "heroic" engineer or team of engineers could out-box a traditional product team with an engineering manager, product manager, designer, and engineering lead, but it's just not the truth. Presumably, in your case, you're talking about an engineering manager. But you haven't mentioned if there's an engineering manager and no accompanying trained product manager. Engineering managers aren't formally trained in doing the hard work of talking to the customers to figure out what the market actually wants, so if leadership at your organization did not build it out to include this role, you would end up being in a tough spot. Based on you saying that your manager made the decision to build a random integration which had questionable value to the org it sounds like this was the case. Depending on the size of the team, an engineering manager may even be dead weight and engineers should report to a technical founder or GM. But regardless, you actually are making the case that more rather than less product ownership and management is necessary to ensure that a product isn't dead on arrival -- after all, the symptoms you mention are of poor prioritization and product discovery/strategy (symptoms of poor/nonexistant active product management) rather than of poor engineering management (endless tech debt, production outages, awful on-call support, inability for the team to deliver features, unrealistic delivery roadmaps causing endless late nights with poor quality and buggy software delivery, attrition and difficulty recruiting). [1] https://en.wikipedia.org/wiki/History_of_Gmail#Internal_development https://en.wikipedia.org/wiki/History_of_Gmail#Internal_deve...

karmelapple 4y ago

> I've never once had a manager say anything along the lines of "I just think we're building a bad experience if we release this early." Then perhaps you had less-than-great managers, and I could think of a variety of reasons for that. Maybe it was as simple as you claim: no consideration was made to introducing an undercooked user experience. But if a software development manager is green lighting that, likely causing more work for customer service and perhaps sales, I would hope there’s more to the story than that. Maybe this manager didn’t communicate why releasing a bad experience by a specific date was, perhaps, mandatory to fulfill a contractual obligation. Or maybe you were not able to sort that out from the limited amount of information they gave you. Maybe they didn’t see the bad UX as truly as bad as you, and perhaps your team, thought it was. Maybe where you thought the feature’s UX passed the 80/20 rule was different than many customers. I’ve had (product and project, not as often people) managers who have pushed to hold on delivering a half-baked implementation. And I’ve been a manager who has done that. Those better managers exist Did you ever get feedback or do something to reevaluate why the bad experience was shipped? The experiences you describe do sound like clueless folks making calls, but know that there are folks in management positions not just wildly flailing about.

Aeolun 4y ago
These are all possible of course, but I’m reminded of the adage that: “The simplest explanation is often the right one.”
ownagefool 4y ago
Problem is with this argument is both sides are aruging their group is better. I find whether not you care about outcome usually irrelevant to the title / role. There's a couple of things going on here: - Personal ambition. Usually this is about money, especially the higher up the org you are, but it might also be about becoming a better at tech, or keeping a stable job to pay your mortgage. - Incentives. How the company rewards things it wants. This might be shares, commission, salary, or bonuses. But it's also about how the company measures and manages those things. - Ethics. What you're willing to do to achieve your goals. Both individually, and at an org level. It doesn't take long industry to realise that the few people are actually interested in helping orgs make money. This is shown by developers focusing on irrelevant shit all day long, and it's shown by the lack of incentives and rewards that drive the correct behaviour, so all you get is a whole bunch of personal ambition. Of course, some people do, but when faced with a company that allows people to focus on short sighted personal ambition, they'll either fall in-line or move along.
- cutemonster 4y ago
  > both sides are aruging their group is better. And/or that the personal work experience they themselves have had, would be representative for people in general. (Not saying that the posters above necessarily did now) > couple of things going on here ... few people are actually interested in helping orgs make mone ... Yes, nicely written :-) Maybe in many cases they are "right" not to care, if the company doesn't contribute meaningfully to society anyway

HWR_14 4y ago

Google deciding to give everyone literally 100x or 66x more free space than their competitors did manage to acquire a lot of the email market, which meant non-negligible hardware costs. It spent three years in internal development of Gmail. I have no idea why you think managers weren't involved in those decisions. Meanwhile, I have no idea if battery life impact is worth measuring in your use-case. My assumption would be "no" because I would imagine the battery life impact would vary too widely to yield useful data and I don't see what I could do with that information anyway other than recommend some people not use the app. But I'm not really thinking deeply about it now, so I'd love to be enlightened. Meanwhile, trying to get more customers is a good thing, even if it fails.

brazzledazzle 4y ago
It's probably important to put this into context of Google's views towards management, especially back then. At one point they even experimented (briefly) with having no middle management. My understanding is that they still try to limit the number of managers and their ability to harm the organization by using tactics like higher ratios of developers for each manager. They actively try to reduce negative behaviors like micro-management by middle managers. It's not exactly common for an organization to actively attempt to mitigate the negative aspects of middle management so it's almost an apples to oranges comparison. But since we're on the topic of Google, maybe making management reduction one of an organization's goals is the correct strategy to reduce the bloat and increase the productivity of ICs.
- treis 4y ago
  >My understanding is that they still try to limit the number of managers IMHO this is really the point. Somebody has to hire devs, run the evaluation/promotion stuff, facilitate communication to/from upper management, and so on. I've just never been to a place that couldn't do that with 1/2 to 1/3 of the EMs they have. For whatever reason the standard is one EM per team. A better ratio is on EM per 2-4 teams.
  - jensensbutton 4y ago

yowlingcat 4y ago

Gmail wasn't just built by a team of "engineers" that ate Yahoo's break fast. There was also a great designer and product manager on the team as well [1]. I have seen engineers hold the misstaken belief that a "heroic" engineer or team of engineers could out-box a traditional product team with an engineering manager, product manager, designer, and engineering lead, but it's just not the truth. Presumably, in your case, you're talking about an engineering manager. But you haven't mentioned if there's an engineering manager and no accompanying trained product manager. Engineering managers aren't formally trained in doing the hard work of talking to the customers to figure out what the market actually wants, so if leadership at your organization did not build it out to include this role, you would end up being in a tough spot. Based on you saying that your manager made the decision to build a random integration which had questionable value to the org it sounds like this was the case. Depending on the size of the team, an engineering manager may even be dead weight and engineers should report to a technical founder or GM. But regardless, you actually are making the case that more rather than less product ownership and management is necessary to ensure that a product isn't dead on arrival -- after all, the symptoms you mention are of poor prioritization and product discovery/strategy (symptoms of poor/nonexistant active product management) rather than of poor engineering management (endless tech debt, production outages, awful on-call support, inability for the team to deliver features, unrealistic delivery roadmaps causing endless late nights with poor quality and buggy software delivery, attrition and difficulty recruiting). [1] https://en.wikipedia.org/wiki/History_of_Gmail#Internal_development https://en.wikipedia.org/wiki/History_of_Gmail#Internal_deve...