Comment by passwordoops | Hacker News Reader

Comment by passwordoops | Hacker News Reader

Parent Full thread

My funniest experience as a pleb on the other end of an executive off-site working in product was being handed a detailed roadmap for the following year, which I had no input on and was politely told to shut up when I raised concerns about it. Specifically why wasn't "Big Feature X" that's been a point of emphasis for the past 4 months and that you made a big deal about being a top priority when I was hired missing from the roadmap? Nope, my job was to "deliver" not to ask questions.

Three (3!) weeks later, after adjusting the teams workload to focus on the new roadmap in conjunction with the Head of Engineering and getting approval on the new plan from the CTO, CFO and VP Sales I get called into a meeting with the CTO, CFO, CEO,, COO, VP Sales, and Head of Engineering, aka the group of Big Brained Leaders who came up with the roadmap that I was responsible for delivering but not allowed to comment on. They then began to attack me over "Big Feature X" - why is it not there, when can we deliver it, how it's my job to define the roadmap and it's unacceptable that we don't have "Big Feature X"...

Recently, I've been breaking into upper management and now that I've seen just how messy it is/was this is a completely believable story. Crazy stuff. As I continue in my career will be interested to see if different organizations handle that better at upper management or is it just the proverbial shit show everywhere you go.

My experience is that the higher you go, the less rules and objectivity exists. You get paid more because you have to navigate this. An e.g. Developer just has to work on the backlog, there might be technical challenges but the requirement is obvious.

Once you get to Exec level, do we hire more to produce more work? Close a department because it's losing money now (but might not in the future)? Do we stick with our current market that we have most of or go after a new one that is untapped but less familiar.

All of this with the situation/world/people changing all the time. People can call it a shit show but the truth is that it's hard. It's hard to put relative values on things to help make decisions. Ultimately, it usually takes a step of faith and the ability to execute well to increase your chances of making your decision work. You also need to balance the need to stick with something and make it work with accepting it was a bad idea and canning it.

I suspect in the very large corporations, it probably gets very surreal because 10 levels of management make the execs completely disconnected from reality so they can make it look like they are making decisions without really knowing what is going on (and most of those might never happen because they take too long to fall down the soil pipe!).

Some companies are clearly run better than others, this is mostly apologist nonsense.

What really goes on is that the goals of executives is different from that of people who actually do things, and paradoxically, the ones who actually do things tend to be valued the least.

But that is a failure of middle management. Middle management's main job is to get the ones who actually do things the tools they need. That includes roadmaps that make sense, etc. That also includes showing upper management the value of the opinions of the ones who actually do things. Upper management is not the advocate for opinions, they are the decision makers who base decisions on what they have been fed. Middle managers are the advocates for the opinions of their people.

Even if you assume that's true, whose job is it to ensure "middle management" is doing the right thing?

Upper Management

> An e.g. Developer just has to work on the backlog, there might be technical challenges but the requirement is obvious.

Ha, if only this were true.

Ironically, TFA highlights this as a common anti-pattern:

> Don’t stop the deep-dives. Sometimes executives get confused (or are too afraid) to step on toes and so avoid getting into the weeds. It’s seen as a waste of time or somehow not practical to spend the exec team’s time discussion “lower level” things. But where there are critical initiatives (see John’s point about points of leverage) I think you should get into as much detail as you can.

The more execs gloss over details (e.g., technical challenges, requirements), the less valuable (maybe even more dangerous) their plans become.

Computers are easy compared to people.

I've worked at several companies now, sometimes in a management role. In my experience it's always a shitshow filled with people making things up as they go.

One key difference is culture. Some cultures punish candid honesty which leads to reasonable people resorting to politics and blame games.

Not sure how to spot this when you're applying, but good culture seems to be correlated with competent and respected technical people in upper-management and lots of devs/engineers with a long tenure.

My most negative experience has been with business school grads, meaning BComms with MBAs whose experience is in the finance or accounting departments. Seems the culture is about doing what you're told and CYA rather than critical thinking that come from a solid STEM background.

It reached the point where I now believe any BComm who wants a leadership role should first spend 3 months shadowing the cleaning staff. Once that person convinces the staff they're capable of not setting anything on fire, they can be allowed to mop the floors for the next 3 months. So on through the organization until 10-15 years later they're deemed qualified to think independently and understand what taking responsibility means.

Again, could just be select negative experience, but it's what I've noticed

I have had both good and bad experiences with MBAs and other business school grads, but I could say the same about STEM folks. I agree there are major cultural differences (i.e. BS from engineers takes a totally different form from BS from MBAs) but I think the more salient problem is if your management team consists of nothing but a single background.

If a tech company is run by business and finance folks it can become unmoored from engineering realities. But a tech company run by engineers and scientists can become similarly unmoored from business realities. In my experience, companies that promote well-respected members of their key disciplines into senior management roles seem to be the least dysfunctional.

1. This is what happens when there are non-technical folks in the upper-echelons of an organization. The CTO should have highly technical backgrounds and should be able to do the work they’re pushing down to the rest of the engineering staff; however, oftentimes, they cannot and/or never could because their station comes from business acumen, not tech.

2. Now, there’s the other side of that where you have technical leaders who can code but cannot effectively communicate and/or make it known to other leaders why requested roadmap items are not feasible, possible, etc. This is a very common scenario where technical leaders are not great at communicating to other business leaders and making realities known.

The third issue is when a technical leader draws a line in the sand and gets sacked because the rest of the leaders hate having their ‘vision’ quashed. This leads to #1 and #2, above.

> This is what happens when there are non-technical folks in the upper-echelons of an organization

The described behavior can be found in non technical organizations as well. A room full of people will never blame itself, they will always blame someone not in the room (or failing that push someone out of the room and blame them). In group VS out group behavior[0][1].

You could tell the same story around a lemonade stand, "Looks like we are going to be busy next week, should I order more lemons?" "no, we ordered plenty", a week later "Why didn't you order more lemons!".

It's not a technical problem in the slightest, or even a human nature problem, this stuff was wired in when we were early primates.

[0]https://en.m.wikipedia.org/wiki/In-group_and_out-group

[1]https://en.m.wikipedia.org/wiki/In-group_favoritism

I used to believe this too, but I've worked in multiple organizations now where there was no shame associated with assessing who or what factors contributed to project failures. The primary desire was to understand them accurately to mitigate those same failures in the future.

Ultimately it comes down to the organization's culture and whether failures are punished or accepted as a necessary side-effect of doing ambitious work.

This probably predates primates and it's just a standard social animal trait that's useful so is kept around. Think dogs, wolves, ants, whatever.

Another pattern I've seen is that the CTO is technical and can do the work, but all their experiences actually coding for the company is from the early days where releasing half-baked bug filled messes was the standard. As the organization grows, maturity around quality, security, reliability, etc. increase but they still have an internalized notion that the company should be able to ship product "like the old days".

Alternatively, the slight variation where even shipping good clean robust code was easier in the old days because the product was much smaller and didn't have years of accrued product and technical decisions to work around or unpick, all of which were good at the time but don't work a few years later.

The "maturity makes things slower" thing can apply even if the quality of code was always good.

Then there's the 3rd issue, where everything has become a moat and it's just not worth the effort of trying to do a good job anymore.

I've literally seen things that should take an hour be weeks because it ended up involving 10 different teams. And while you may think that's an exaggeration, it's not.

software is often used to assert authority so people CAN'T even attempt to work around these issues. Paradoxically, software can actually make companies less effective.

Agree with everything, but I wouldn't be too strict on the requirement that the CTO be able to do the work - within reason and depending on the org. They definitely have to be able to understand it and have an intelligible conversation.

For example, my current place does hardware and software - CTO comes from the software side so he's not a specialist on the hardware and can't contribute directly to the electrical engineering work. But at least he knows how to ask the right questions, learn when he needs to, and got the right people under him to get the job done. And to your point, he has no formal business education and our CEO is the founder, and an electrical engineer

> This is what happens when there are non-technical folks in the upper-echelons of an organization.

Technical people can forget things and then try to play "shoot the messenger" just as well as non-technical people can.

Yeah I flirted but after that experience I moved on to a couple of other places and started to pay closer attention. Trying to be a competent higher-up is not worth the headaches. I'm happy to find my niche at a place that pays well, delivering just enough to whatever higher up is asking for it so people stay happy with my performance to say "he's a good guy!". Side projects are where I get my personal sense of accomplishment these days

I've had interactions with upper management some times and agree. I had an older boss who explained that part of his job is to politely head off bad decisions before they get too popular. It's not a people skill they usually teach in management/leadership training for obvious reasons. I guess it falls into the whole "managing up" communication.

This pretty much answers what executive offsites are for. Executives covering each other's asses and finding scapegoats.

Yep! I remember as a (very) junior dev being told that I was 'responsible' for product documentation. When I asked what I had to do, I was told "nothing, you're just responsible". And like you I got grief when things weren't as they should have been.

I think they used to call such people "whipping boys"

It was likely still your role to speak up. Just..probably didn't do it strategically, and with the right people.

Friction happens. Navigate it.

I did, but like I said I "was politely told to shut up" and "my job was to "deliver" not to ask questions.

This was raised in one on ones with the Head of Engineering, a weekly group planning with Head and CTO where it wasn't me but the Scrum master putting forward the question, then again as asides with the sales guys. This was a systemic issue with how the company was run and who was selected for leadership

And when you brought this up what did they say?

Variations of "stick with the plan" and "we have visibility you don't".

Keep in mind I'm an already experienced Product Manager at this point brought on specifically because I had a proven background in full product lifecycle, revenue growth and communication to higher ups at companies running on the 10-100MM revenue and profits in the 10% range. I got there because I know how to schmooze the C-suite. I appreciate you're trying to turn this into a "work on your communications skills to get ahead" coaching opportunity but this was not the case. It was my first, and I hope only, experience with yes men being thoughtless yes men.

I asked because you ended the story somewhat early, which was a bit unsatisfying.

Now I suppose you could humor these folks and look a bit foolish all the while collecting big paychecks. Or you could nip it in the bud at risk of souring the relationship. Believe I’d choose differently depending on how old I was at the time.

It’s on my mind because last night I watched “the bodyguard” (final night on Netflix). Main character nips all bullishit in the bud immediately, increases his rate by 1/3 and gains respect at the same time. Have to deliver however.

Yeah, it was tough because the CTO was either a flake or already checked out and the Head of Engineering was a brown nose who would do whatever the last executive told him to do. Totally different reality from the answers I got at the interview.

In this situation, unless you have a spot in the C suite, or a defender, you have to play ball because the decisions happen behind your back.

It was very disheartening because it was clear being a yes man who steals the credit and finding fall guys got you ahead. If that's the culture, there's really not much you can do but play ball or leave. And if you're not "in", playing ball means getting all the blame. I wasn't "in", but luckily since most conversations were over slack or email I always had documented evidence that they couldn't deny. But the people responsible wouldn't be held responsible.

Again I've been at a few places, and I've never experienced anything similar, and I hope I never do.

Another example. Supposedly the CFOs office was providing usage stats in presentations to clients, which I found odd because we only starting collecting this data shortly after I started. One day an underling from the finance department sends me a message saying they need the data for the next presentation happening in a few days... I ask what's needed since no one showed me one of these decks. We don't actually collect a good chunk of the data that are in that deck, and of the ones we do, the data from my pipeline doesn't match at all. Underling freaks out and says we can't present this, it will raise too many questions! (That's literally what she said)

As usual, I get called into a rush meeting where CFO reams me and Ops for having changed how we collect data, and this is squarely on our feet. We're remote at this point so me and Ops person start digging, and it turns out the data they present are effectively numbers the VP Sales pulled out of the air in the early sales days. Based literally on nothing.

At this point ops and I were able to provide enough documentary evidence on the topic that is clear the people responsible for these decks were making it up. Because it's the CFO and VP Sales, nothing happens it's all swept under the rug. They gave two more presentations to other clients with the fake data by the time I left. Apparently the practice stopped after a bigger company bought them out and both were shown the door

Experiences like this one affirm me to send brief emails for documentation.

“Is it true that we are winning clients by presenting usage statistics? Did you know that we recently started collecting that data in an organized fashion? This might save you time when you’re looking for updated figures.”

…or the original problem:

“Thanks for the updated road map. Accordingly, I just made sure that all tickets related to big feature x are marked as obsolete.”

Reply on news.ycombinator.com