3 ms·

> Decentralize decision-making authority as much as possible. Remove barriers in their way, slash approval layers, attack dependencies. This is awful advice. Y

> Decentralize decision-making authority as much as possible. Remove barriers in their way, slash approval layers, attack dependencies. This is awful advice. You can only operate in this mode for at best 2-3 months before your entire SDLC grinds to a halt because it's been the wild west in github. > Bias heavily toward action - it's better to decide and be wrong sometimes than to paralyze the team with analysis. This is...more awful advice. My startup has gone through COVID and the financial slowdown and the only reason we've succeeded is because we never stop measuring. The very next paragraph after "decentralize everything and communicate heavily" is "allow your team to focus and centralize administrative duties." And the the NEXT paragraph is "work closely with your team and even write some code." This entire blog post is all over the place. It reads like each paragraph was written by a different person with completely different experiences. If you want to manage your team while the house is on fire, don't change anything. Communicate clearly, ensure that the culture and philosophy of the team bend when necessary but don't break, and work on alleviating the real problem. One of: lack of product market fit, burning cash like it's going out of style, or no clear path to profitability or the next raise. Your engineering team is probably not the problem if your startup is failing.

herval 2y ago
> You can only operate in this mode for at best 2-3 months before your entire SDLC grinds to a halt because it's been the wild west in github FB is operating that way with tens of thousands of engineers. More approval layers don’t necessarily mean more order, but it always means slower processes
- debacle 2y ago
  Facebook has a very thorough code review process, and their product is heavily data driven. They've even productized their code review process internally, and that product is also data driven.
  - herval 2y ago
    The code review process is quite literally “you need a stamp from anyone because of some regulations we follow”. Definitely nothing thorough.
    - XorNot 2y ago
      The seriousness of any code review process can be determined by whether it diffuses liability from the original code author for any bugs. So far in my career this has never been the case.
      - Aeolun 2y ago
        I think we do, to some extend. As the TL, when I’ve reviewed their PR I’m definitely not going to blame them for the bugs I missed during review. They’ll still have to fix them, because that’s just most efficient.
- toast0 2y ago
  You can operate anyway you want if you have a printing press for money in the back. It's not a model to follow when you've got constraints.
jajko 2y ago
> You can only operate in this mode for at best 2-3 months While article is named "How to Lead Your Team When the House Is on Fire" - if your business is constantly on fire you are doing something terribly wrong, I don't think you understood the main points.
halfcat 2y ago
All the advice is very similar to the leadership advice that comes out of military special forces, like decentralized command, prioritize and execute, cover and move, and so on. With the point being, if all of your team members are elite, then everyone ’yeeting into main’ can be wildly productive. But it’s not good general advice, as you say, where most organizations have a range of talent.
afro88 2y ago
>> Decentralize decision-making authority as much as possible. Remove barriers in their way, slash approval layers, attack dependencies. > This is awful advice. You can only operate in this mode for at best 2-3 months before your entire SDLC grinds to a halt because it's been the wild west in github. If that happens, you decentralised more than was possible ("as much as possible" doesn't mean "completely"). You removed too many important barriers. A bit more concretely, you gave authority to those that weren't capable of handling it, or weren't supported properly. You removed an approval layer without supporting your team to check these things for themselves.
- AdrianB1 2y ago
  The idea is that you should already have the decision in the right way, if you push more towards decentralization then you are already in the danger zone. Yes, you should not do that.
- lubujackson 2y ago
  Makes sense, but at some point this advice boils down to "have the perfect amount of centralized control" which doesn't say anything useful at all.
  - afro88 2y ago
    I think the advice is based on "peace time" management, during more comfortable profitable times, leaning towards more centralised control. There's no appetite for the risk of moving faster by removing approval bottlenecks or changing processes. The advice here is to challenge what actually needs to be centralised. Identify things that could be safely delegated. For example, why does a list of managers and an exec need to approve a $10 per month subscription that saves a bunch of engineering time by managing cascading PR merges? And identify safe ways to delegate. For example, if we move container image vuln scanning into CI/CD pipelines, the dev team can update dependencies themselves without a security team being involved to do it for them and approve. These might seem like silly examples to someone working at a half decent start up or tech first org. But these kinds of centralised control structures are the norm for most large organisations until they are very strongly challenged.
cm11 2y ago
Decentralize decision-making, delegate, bottom up culture, etc. These things have merit, but increasingly less the more you move away from "whole" plans in which they make sense. These particular ones are troublesome because they fall closer on the spectrum to "reduce executives". If you're pushing decision-making downstream, it should also be reduced upstream. If you reduce it upstream, you have less (not zero) need for leadership there. That has to manifest either in fewer leaders or leaders doing a better job at their other duties. In particular, they need to be producing much clearer stronger vision for the downstream folks to align their decisions to. Vision is perhaps the hardest task in the org and when it's hard it's easy to shirk on. Often, when leaders talk about trying to move to a bottom up culture, they are (unconsciously?) trying to absolve themselves of the vision work. And they're usually doing it while still gatekeeping information and resources they were meant to have because they were decision makers. This is going too far, but directionally: Leaders should largely not be advocating for delegation and bottom up decision-making. It's not that this can't be better for the company, it's that they could be executing the goal better by quitting or firing their peers. It's more of a catch-22/worst of both worlds situation—leaders shouldn't be advocating for it because they shouldn't be there to advocate for it.
aorloff 2y ago
Thank you. No amount of wartime valor is going to overcome a lack of product market fit.

herval 2y ago

> You can only operate in this mode for at best 2-3 months before your entire SDLC grinds to a halt because it's been the wild west in github FB is operating that way with tens of thousands of engineers. More approval layers don’t necessarily mean more order, but it always means slower processes

debacle 2y ago
Facebook has a very thorough code review process, and their product is heavily data driven. They've even productized their code review process internally, and that product is also data driven.
- herval 2y ago
  The code review process is quite literally “you need a stamp from anyone because of some regulations we follow”. Definitely nothing thorough.
  - XorNot 2y ago
    The seriousness of any code review process can be determined by whether it diffuses liability from the original code author for any bugs. So far in my career this has never been the case.
    - Aeolun 2y ago
      I think we do, to some extend. As the TL, when I’ve reviewed their PR I’m definitely not going to blame them for the bugs I missed during review. They’ll still have to fix them, because that’s just most efficient.
toast0 2y ago
You can operate anyway you want if you have a printing press for money in the back. It's not a model to follow when you've got constraints.

jajko 2y ago

> You can only operate in this mode for at best 2-3 months While article is named "How to Lead Your Team When the House Is on Fire" - if your business is constantly on fire you are doing something terribly wrong, I don't think you understood the main points.

halfcat 2y ago

All the advice is very similar to the leadership advice that comes out of military special forces, like decentralized command, prioritize and execute, cover and move, and so on. With the point being, if all of your team members are elite, then everyone ’yeeting into main’ can be wildly productive. But it’s not good general advice, as you say, where most organizations have a range of talent.

afro88 2y ago

>> Decentralize decision-making authority as much as possible. Remove barriers in their way, slash approval layers, attack dependencies. > This is awful advice. You can only operate in this mode for at best 2-3 months before your entire SDLC grinds to a halt because it's been the wild west in github. If that happens, you decentralised more than was possible ("as much as possible" doesn't mean "completely"). You removed too many important barriers. A bit more concretely, you gave authority to those that weren't capable of handling it, or weren't supported properly. You removed an approval layer without supporting your team to check these things for themselves.

AdrianB1 2y ago
The idea is that you should already have the decision in the right way, if you push more towards decentralization then you are already in the danger zone. Yes, you should not do that.
lubujackson 2y ago
Makes sense, but at some point this advice boils down to "have the perfect amount of centralized control" which doesn't say anything useful at all.
- afro88 2y ago
  I think the advice is based on "peace time" management, during more comfortable profitable times, leaning towards more centralised control. There's no appetite for the risk of moving faster by removing approval bottlenecks or changing processes. The advice here is to challenge what actually needs to be centralised. Identify things that could be safely delegated. For example, why does a list of managers and an exec need to approve a $10 per month subscription that saves a bunch of engineering time by managing cascading PR merges? And identify safe ways to delegate. For example, if we move container image vuln scanning into CI/CD pipelines, the dev team can update dependencies themselves without a security team being involved to do it for them and approve. These might seem like silly examples to someone working at a half decent start up or tech first org. But these kinds of centralised control structures are the norm for most large organisations until they are very strongly challenged.

cm11 2y ago

Decentralize decision-making, delegate, bottom up culture, etc. These things have merit, but increasingly less the more you move away from "whole" plans in which they make sense. These particular ones are troublesome because they fall closer on the spectrum to "reduce executives". If you're pushing decision-making downstream, it should also be reduced upstream. If you reduce it upstream, you have less (not zero) need for leadership there. That has to manifest either in fewer leaders or leaders doing a better job at their other duties. In particular, they need to be producing much clearer stronger vision for the downstream folks to align their decisions to. Vision is perhaps the hardest task in the org and when it's hard it's easy to shirk on. Often, when leaders talk about trying to move to a bottom up culture, they are (unconsciously?) trying to absolve themselves of the vision work. And they're usually doing it while still gatekeeping information and resources they were meant to have because they were decision makers. This is going too far, but directionally: Leaders should largely not be advocating for delegation and bottom up decision-making. It's not that this can't be better for the company, it's that they could be executing the goal better by quitting or firing their peers. It's more of a catch-22/worst of both worlds situation—leaders shouldn't be advocating for it because they shouldn't be there to advocate for it.

aorloff 2y ago

Thank you. No amount of wartime valor is going to overcome a lack of product market fit.