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?
Because information is freely accessible, there is less need for dedicated "reporting" processes every time a manager is added into the system.
> 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.
No I will not.
Day to day shielding from nonsense wasn't his best feature but it was a contributing factor in having such a productive relationship.
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.
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.
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.
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.
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
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 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.
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.
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...
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...
Now that can sometimes align with adding actual value or figuring out the best product or organizational strategy, but not always.
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.
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?
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.
LOL, my current team does 2 hours of meetings per week (at most!) and we are incredibly productive. I hope we never work together!
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'm sure that 90% of the current team would quit if we suddenly had to attend 10X more meetings per week :P.
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.
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.
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.
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.
That’s after a very-long (nearly three decade) career as an IC in “big tech”.
I think my take on this is not surprisingly different than yours.
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.
There is a lot of management above first-level that doesn’t seem to add a lot of value, but I’m not sure how much of that is inherent versus the specifics of who is in those roles. I expect my manager to be focused on strategy, long-term direction, team composition, building relationships with other orgs, etc. Up a level from that, again an even broader perspective. Depending on who is filling those roles I may or may not see those behaviors.
It’s very common and convenient to focus on personal productivity as an IC, but if 25% or 50% or 90% of that effort is going towards things that ultimately don’t have impact for customers, it’s not very productive after all.