Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Accountability Problem

jamesshore.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: The Accountability Problem

#51

Post by marcosdumay »

firesteelrain wrote: post #27
akickinthestone wrote: post #17

On one company I worked on, in one year tech team shipped 53 epics, delivering all the features sales, CS and product needs. By EOY the company grew zero. Literally zero. This was a series A company. CTO got in a meeting with the CEO and said: we delivered everything you asked for, but the company didn't grew. What went wrong? CEO wasn't able to act on this. In the end the company started by laying off the tech team…

In all of these types of stories, it is always the CEO or CTOs fault the way it is framed. There is never any accountability on the engineers part. CEO/CTO sets the vision. They are not the ones developing the UI or developing the API or writing documentation etc CEO determined there was a market fit or vision for a product, convinced an investor or shareholder to invest based on multiple reviews of this vision then…

Unless a single person decided to go completely against what they are told and did something bad all on their own, then yes, it's always the CEO/CTO fault.

That shouldn't be an alien concept.

Re: The Accountability Problem

#52

Post by marcosdumay »

It's not really a criticism because the author is very clear this is about early stage startups. At least, it's not a criticism of the author, it will be if random people start to adopt the idea...

But yet another software administration policy that is against maintenance.

Re: The Accountability Problem

#54

Post by Seattle3503 »

drooby wrote: post #35
alphazard wrote: post #29

Everyone who has worked in tech should reflect on the fact that it would be shocking to see a product manager produce a spec for the behavior of a feature, or a spreadsheet with discounted value analysis as in TFA. Those are both artifacts that aid in decision making, and especially aid in making the kind of decisions that product orgs have taken from other more qualified people at a company. Unfortunately, product m…

I was spoiled at my first company out of college. My director cared deeply about product specs, acceptance criteria, and making sure engineers actually understood product and business decisions. It was so nice. Oh, how sweet and naive I was to the world… hahah. It still blows my mind that product isn’t treated like a soft engineering discipline in its own right. When product doesn’t do its own thinking, the cognitive…

> The project falls apart because Product drops the ball, but Engineering is the team at the end of the funnel, so the blame naturally tends to land on them. Product’s output is often hidden, and it’s easy for them to say, “Well, we did our part. Engineering just didn’t deliver.”

I've seen this get worse with LLMs. I've had specs that were wholly or in significant part generated by ChatGPT, but they look detailed so the are plausible workslop. I've been given a spreadsheet with nonsense items "Implement adaptive intent-driven workflows across user touchpoints" (I generated this example with GPT).

When I asked what any of it meant I was met with silence. Later through the grapevine I hear the requirements were generated by ChatGPT and the guy responsible for them doesn't understand the system at all. But guess who is responsible for delivery?

Re: The Accountability Problem

#56

Post by Pannoniae »

Amazing presentation, the real gold is buried somewhere in the middle:

"To paraphrase Kent Beck, professional software development is about...

Communication and collaboration between large numbers of people with different perspectives."

This is why large organisations suffer, communication;)

People say it a lot that the code isn't most of the value but the auxiliary stuff is, which is true - but the conclusion from that shouldn't be that the work itself isn't that important, it's just that you'll see way less of it in a large organisation.

This is also why a well-aimed startup can easily blow the socks off companies with thousands of employees - the communication overhead is high, accountability is very diffused and everything is codified.

In an ideal world, you'd spend 100% of your time with either the work or something adjacent (like research), but of course, that's completely unrealistic. But if you aren't doing work but something else, it's probably a good idea to ask yourself, does this matter? Does it help my goals?

Re: The Accountability Problem

#57

Post by travelalberta »

gubicle wrote: post #43
alphazard wrote: post #29

Everyone who has worked in tech should reflect on the fact that it would be shocking to see a product manager produce a spec for the behavior of a feature, or a spreadsheet with discounted value analysis as in TFA. Those are both artifacts that aid in decision making, and especially aid in making the kind of decisions that product orgs have taken from other more qualified people at a company. Unfortunately, product m…

The (relatively big and successful) tech company I work at, has gradually seen ~all high level decision-making positions filled with PMs, while senior engineers who have been at the company for years are being pushed out and/or leaving. Most of these PMs have very little understanding of the tech, the market, or how software engineering works, yet they now make ~all of the product decisions at the company. I haven't…

I thank the stars every day that my direct manager is an actual engineer.

Re: The Accountability Problem

#58

Post by harimau777 »

firesteelrain wrote: post #27
akickinthestone wrote: post #17

On one company I worked on, in one year tech team shipped 53 epics, delivering all the features sales, CS and product needs. By EOY the company grew zero. Literally zero. This was a series A company. CTO got in a meeting with the CEO and said: we delivered everything you asked for, but the company didn't grew. What went wrong? CEO wasn't able to act on this. In the end the company started by laying off the tech team…

In all of these types of stories, it is always the CEO or CTOs fault the way it is framed. There is never any accountability on the engineers part. CEO/CTO sets the vision. They are not the ones developing the UI or developing the API or writing documentation etc CEO determined there was a market fit or vision for a product, convinced an investor or shareholder to invest based on multiple reviews of this vision then…

What's the alternative? Going against what the powers that be say is a great way for an engineer to get fired.

Re: The Accountability Problem

#59

Post by IAmBroom »

gus_massa wrote: post #26
shevy-java wrote: post #21

"And like medieval scholars drawing elephants they’ve never seen, we make those interpretations through the lens of our own biases." Those images are quite amusing. They drew an elephant like a boar but with odd tusks. So the tusks were probably described correctly (semi-correctly) for the most part, but the size is totally wrong, which is weird. It's like ... "hey, I saw a thing with huge tusks but it was not bigger…

The ears are also extrange, but quite incorrect in shape and size, but they are not horse ears. Is it possible that they saw some tusks IRL, but no elephant ear? About the size, one elephant is smaller than a horse but has 4 small guys standing on it. Is it possible that it was a standard convention to get everyone in the drawing, instead of tying to make a photorealistic image.

Before Renaissance perspective was developed, artists used relative size to indicate things like relative importance (kings and Jesus were sometimes 20-50% larger than their followers), or timescale, or as you are suggesting, convenience to fit things in.

Basically, they didn't put much stock in making the scale realistic throughout the piece.

Re: The Accountability Problem

#60

Post by lunias »

The site is down for me, so I'll check back later because this sounds like it discusses something that I've seen my entire career in tech... Imagine showing up to work at the fire station after getting out of the fire academy and 50+% of the people working at your station (including your manager and their manager) have never been to the academy, they don't know anything about the engine, they've never donned turnouts, and never gone into a fire; they are "in charge", but have to ask the people they're managing what to do.
Post reply on HN