Hacker News Reader

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.

> 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.

These are all possible of course, but I’m reminded of the adage that: “The simplest explanation is often the right one.”

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.

> 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

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.

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.

>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.

Then don't be surprised when you don't get promo's because the manager responsible isn't familiar with your work.

From what I've been told, you need to "change something" in order to get promoted at Google. Doesn't much matter what, as long as it's a visible change, presumably at least marginally improving things.

And that illustrates what releasing half-baked stuff and not caring much about tech debt is all about - visibility. This seems to be true across industries. Not releasing something, even if it's not ready gives impression of not doing enough, not delivering, always being late, etc. Releasing stuff shows you (the manager) are the person who delivers. If it's crap, you'll get even more resources to throw at fixing stuff that's already delivered. And you're the hero again (even if it's "techies" who did 80-hour weeks to make it happen).

This doesn't even break down too much in physical product world. "Deliver" could mean sales, first to the market, we'll add copy&paste in 3.0, and so on...

I feel like this happens at every tech company I've worked for. The management in charge of promotions is not tech savvy, so 'under the hood' improvements and general maintenance goes completely unappreciated, while flashy, superficial UI updates are bestowed with gold medals and promotions.

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_deve...

> As a first-level manager my job is all about execution and getting things done. Being in 20+ hours of meetings a week gives me a lot more perspective on the big picture than the ICs on my team.

> They often think certain work is important because they have a very myopic view of what we do. I am always looking for the ICs to drive our work, and expect the more senior people to come to the table with ideas. Sometimes those ideas are great, and they have a low-level perspective that I am missing because my nose isn’t in the code as much as it once was (it still is, and I still commit code, but it’s opportunistic and not that frequent). But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term.

I would love to hear your perspective (or pointers to other resources that might explain this better) on how one can effectively communicate this kinda of context with ICs.

I've worked with managers who have been from "fully transparent about org dynamics" to "Ill shield you from shit (i.e. politics)". Personally, I prefer the former approach as an IC since I respect honesty and the truth, so e.g. if its a political decision I can simply stop trying to push for another direction. However, I understand that this kind of radical transparency might come at a cost and might only work with certain kinds of ICs.

There’s “shield you from shit” as in “don’t let upper management abuse you” and then there’s “treat you like a mushroom.” Some managers conflate the two.

Mushrooms translated - “keep them in the dark, feed them shit, watch them grow”

Some managers don't conflate them and straight up use it as an excuse to keep you in the dark.

I've certainly had that before, too. "You have no idea how much corporate crap I shield you from." "OK so... tell me?" "Just be grateful."

No I will not.

My best ever manager was both. Radically transparent but also a human shield against the onslaught of political bullshit that was going on. He made it clear what we were up against, stood tall for us but also told us when he did all he could and we were going to have to deal with whatever decision was coming down from on high.

Day to day shielding from nonsense wasn't his best feature but it was a contributing factor in having such a productive relationship.

What your comment, in other words, boils down to this: managers, directors, VPs, etc, just build their empires by hiring more and people. That's why it is possible that "25% or 50% or 90% of that effort [personal productivity] is going towards things that ultimately don’t have impact for customers, it’s not very productive after all."

Maybe, time to trim the fat from the top: get rid of these empires by downsizing. Also, companies at very high level should look at the bad effects of empire building, which happens in every large organization. Now one can ask "who gonna bell the cat"? If executive vice presidents start empire building, who gonna stop that? After all, CEO should give free reigns to his underling EVPs. Maybe, the majority stock holders should bell that cat; however, they have delegated that to the board of directors, who are different set of cats.

Could you clarify what you mean by the expression “bell the cat”?

https://en.m.wikipedia.org/wiki/Belling_the_Cat

https://en.wikipedia.org/wiki/Belling_the_Cat

The mice have a solution for the murderous cat: simply put a bell on the cat’s collar and then they will know when it’s coming.

But… who’s going to “bell the cat”? i.e. who is going to perform this unpleasant and possibly fatal job?

> What your comment, in other words, boils down to this: managers, directors, VPs, etc, just build their empires by hiring more and people.

No, my comment doesn't boil down to that. It boils down to many (not all) ICs, especially ones without a lot of experience, are more interested in focusing on problems that interest them than actual issues that customers want solved. So they go off and start working on interesting problems rather than important ones.

If I’m reading this correctly, you’re saying that there needs to be someone on a higher level to ensure that the correct work gets done.

How do you balance the additional work needed to provide the necessary transparency to this decision-maker?

Providing this additional reporting often becomes an unreasonably (I think) large part of the job, creates friction, and unexpected changes of direction interrupt flow.

As a manager with experience and sensibility for both the importance of doing the right thing and productivity, satisfaction and flow - what are some ways you lower the cost of managing?

One way to lower the cost of managing is to promote transparency within the organisation: allow and encourage manager to read the PR and the discussion around them, this will give them some sense of the progress of the projects. Provide KPI/OKR about the state of the company on a very regular basis, allow and encourage IC to take a look at them. Announce good and bad news on dedicated channels, allow and encourage employees to read them.

Because information is freely accessible, there is less need for dedicated "reporting" processes every time a manager is added into the system.

Agreed for small companies in certain business contexts, but just “reading through the PRs” doesn’t scale or may not be that valuable to decision makers at different levels of the hierarchy, and not all ICs want to be involved in the decision making. I don’t think there’s a one size fits all option besides having smart people who know what they’re talking about and not going too heavy on process and hierarchy too fast.

Spectacular question, thank you. I’ve had this concept rattling around in my head but not had the words. Cost of managing is really succinct.

>> But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term.

One company had a homegrown debug protocol and tool to interface with it. I needed to add some custom info screens for development, but it was very hard to add because the code was $h!t. So I started fixing it just to be able to add my new data. Not only was I told that Work should be "managed" and prioritized, it was later discarded even though I had done it.

When programmers do things to "make the code better", it may not have an impact on today's customer demands, but it is meant to make the programmers more efficient in the future. This is stuff that will - by definition - Never be a priority in management's eyes.

> This is stuff that will - by definition - Never be a priority in management's eyes.

I'm not sure why you think that is "by definition" not a priority. Of course it is if it's impacting being able to do new work that adds value.

The question is, is that a priority at the moment it's noticed, or something that should be added to a backlog to be addressed later?

If it's a small amount of code clean-up, it's usually easy to squeeze into current work without disruption. We always try to refactor as we go along. If it's "This 3000 lines needs to be redesigned and rewritten", it really amounts to feature work and should be added to a backlog and prioritized along with all the other work.

The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important.

>> The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important.

Sometimes that new person is wrong, buy often there is truth in their assessment. If they're right that they've walked onto a bunch of garbage then their desire to fix it immediately is IMHO the correct thing to do with the exception of making critical (meaning contractual) deadlines for a customer.

The time to fix a disaster is when someone has that intrinsic motivation to do it.

Completely agree. A managers task isn't so much to make sure 'more work gets done'. They are there to make sure 'the right work gets done'.

And that the right people are there (and stay there), that the right tools are there (which does increase efficiency), that no work gets left behind, etcetera, etcetera.

>Being in 20+ hours of meetings a week

LOL, my current team does 2 hours of meetings per week (at most!) and we are incredibly productive. I hope we never work together!

ICs on my team have 1-3 hours a week of meetings.

I have 20+ hours because I work cross-functionally across a huge company that is both designing hardware and writing software for it. The complexity of what we build and ship is many times that of anything I've worked on during most of my career. As a result, there are a large number of moving parts and a lot of coordination that needs to happen across teams.

I guess no one size fits all, but here is not 2 hours per IC, its two hours total with all ICs involved. We have a very async nature and mostly keep track of each other through tools, so maybe that helps.

I'm sure that 90% of the current team would quit if we suddenly had to attend 10X more meetings per week :P.

What you're describing is a role fulfilled by a product manager, rather than a traditional people manager.