5 ms·

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

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.

stingraycharles 2y ago
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.
- josephg 2y ago
  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.
  - stingraycharles 2y ago
    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.
DandyDev 2y ago
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)
- everdrive 2y ago
  >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?
  - snovv_crash 2y ago
    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.
  - DandyDev 2y ago
    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.
- dmvdoug 2y ago

stingraycharles 2y ago

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.

josephg 2y ago
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.
- stingraycharles 2y ago
  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.

DandyDev 2y ago

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)

everdrive 2y ago
>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?
- snovv_crash 2y ago
  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.
- DandyDev 2y ago
  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.
dmvdoug 2y ago