Comment by _heimdall | Hacker News Reader

Comment by _heimdall | Hacker News Reader

Agile, scrum, and OKRs have always bothered me (I know, how profound!)

My issue with them, though, is one that I don't usually see spelled out very often. All three promise, whether directly or implied, freedoms and responsibility being pushed further down the org chart. In reality all three are implemented in a way that further centralizes control towards the top of the org, leaving independent contributors at the bottom feeling almost entirely powerless.

I've always wanted to see a company flip OKRs on their head. Every employee should define key results for their little corner of the company. Managers should be responsible for taking those as fact and working to build a direction for the team that aligns as many of those results as possible. By the time you get to the top you have leadership setting the company's direction based on what the employees know to be most important rather than leadership seeming to energy on a hilltop to force key results down on everyone else.

Bottom up, not top down. Hire well, train well, and trust your people. It could fail spectacularly but at least your people would be respected and enjoy the ride, and we'd all learn something about the pros and cons of running a company without a dictatorship.

Companies usually exist to make money. I’ve seldomly seen software engineers that know the most effective way to make money. Therefore I see 2 problems with this bottom up approach:

- Software Engineers don’t understand the best way to make money - Bottom up means that everyone will optimize locally for their own turf instead of converging on a common goal/set of goals for the company (ie reaching a global optimum)

>Software Engineers don’t understand the best way to make money

Why not? Isn't efficiency and profitability fundamentally an engineering problem? Design a product to be as profitable as possible, understanding which items to focus on, and which corners to cut?

Yes, typically the reason software engineers don't know how to make money (a premise I actually agree with) is because some product person is trying to translate the business problem into an engineering problem, rather than exposing the business problem to the engineer directly.

IMO too much is lost in this translation step and you end up often with engineers not understanding why the product they're building actually needs to be the way it does, and then a product person chasing them in circles and telling them absolutely everything except what the business problem actually is.

Efficiency is, profitability is not I think. Maybe I’ve worked with the wrong engineers, but many engineers I have worked with know how to solve technical problems, which does not necessarily mean customer problems.

The reasons disciplines like marketing and sales exist and also why processes like product discovery exist is that if we would leave product development to engineers, we’d get super efficient machines and software that are really elegant but don’t necessarily solve the problems customers have, are way too expensive to build and are not being sold.

I would really like you to read and respond to my comment here: https://news.ycombinator.com/item?id=41211945

Don’t take offense at the “mindless repetition” part though, please. I genuinely want feedback from somebody who says what you just said.

That link seems to go nowhere? At least on Hack, the HN client I’m using on iOS

It was my comment to a different comment on this thread. I’ll repeat it here:

Yes, and this somewhat recent notion that corporations only exist to benefit their shareholders. Corporations exist in order to do the business that they’re in the business of doing, and their structure is such that it allows for the distribution of risk and the possibility of profit for investors. Ideally, people would make investment decisions based on whether the business was sound. Like, yeah, this business has tons of satisfied customers, is doing relatively efficient business and makes money doing it: I’ll invest because that company is a winner. Everything now, though, is entirely judged on growth and bottom lines that are easily manipulable quarter to quarter. You’re a successful corporation if number goes up. The financialization of literally everything erodes the real purposes the corporation exists. And the mindless repetition of the line that corporations exist simply to make profits for the benefit of shareholders is bullshit. How many times have we seen companies chasing those profits in such a way as to destroy the longer-term viability/success of their business? Yeah, they made profit for the shareholder in the short term. Hurray. And destroyed the business in the longer-term. That seems to me to be pretty anti-shareholder.

In this model, and again I'm absolutely not claiming it would definitely work, leadership's role is to align feedback and goals defined by their direct reports. Everyone won't get what they want, but its every manager's role to both trust and respect their team and to play the role of aligning it to whatever business goals exist st their level. If done well, the manager would also be defining business goals based on team-provided key indicators.

I would also add that if a company scales to such a size that this model wouldn't work, in my opinion the company is too large. I would expect this to work very well on a small team, if managed well. I'd expect it to scale okay for a while but to fail miserably at the scale of big tech. That's a feature in my opinion, I expect we'd be better off collectively without such massive corporations accruing so much power.

I'd also note that i don't think your concern is unique to the bottom up approach. With the usual top down approach, leadership at the top is likely very skilled in defining business goals and how to make money. They rarely are skilled at the day to day work that actually keeps the company running. I've personally worked at companies where having leaders define direction while so disconnected from the front lines led to a very poorly functioning company.

This only works when you’re able to hire the best of the best people, that are able to weigh both business and technical concerns against each other.

In my experience, most people I’ve worked with have a lot more capacity than they show at work. Who knows what your people are capable of if you empower your people to fix their own problems and treat them like adults? I’m sure they won’t all be able to step up to the plate, but it’s amazing how much of a difference the right corporate culture makes to the psychology of your employees.

For example, in my experience, people will only take initiative if they believe that they’ll get support from their team and manager for doing so. If not, they’ll bitch and moan about how bad things are but if you suggest fixing things, they’ll insist that change is impossible.

You are lucky you worked with those kind of people. A lot of the businesses I consult for have very mediocre teams (that’s why they need external help), and if they would decide what’s best for the business they wouldn’t get anything done that adds value to the business. These aren’t even necessarily large businesses, a lot of startups that are not doing high tech work (eg they “just” have an app or equivalent, and leadership is very strong commercially) have these kind of teams, and these developers would run the business into the ground if they would be dictating their leadership what to work on.

Again, it isn’t a bad idea, it’s just something that only works when you have a lot of senior engineers that have experience with sales/commercial aspects. Alternatively, it’s an already very much established business, with lots of processes and management layers, but in those cases these processes and management layers are designed as a safety net against poor business decisions from developers.

Reply on news.ycombinator.com