3 ms·

I find this concept utterly baffling, but probably because I've never worked at this kind of org. I can see how letting engineers run their own process is great

by tootie 5y ago

I find this concept utterly baffling, but probably because I've never worked at this kind of org. I can see how letting engineers run their own process is great for engineering efficiency, but how do they know what to deliver and when? My conjecture (please confirm or deny) is that these self-organizing teams are a result of and not a cause of big successful companies. You are probably iterating on a very well-understood and successful business model with a huge cushion for mistakes because you have some much revenue. By contrast, I have mostly worked in consulting and non-tech orgs. If we don't show that we're spending their budget on high value features, we get layoffs. Hence we not only need very thorough clarity on what feature development will yield the greatest returns, but also deniability that we had good reason for doing what we were doing if it turns south.

regularfry 5y ago
I can't speak for Shopify, but in general you want teams that don't need anyone to tell them what to deliver and when because they can be trusted to figure that out for themselves and make a good call. That can't be done without having customer representation on the team (which you should anyway), and having engineers capable of taking a customer viewpoint. That is what "self-organising" should mean, but few organisations are mature enough to transition to it. If you're in a situation where you need to show you're "spending their budget on high value features" that's a low-trust feature factory being treated as a cost centre by a remote client, not a value-producing unit setting its own terms.
- tootie 5y ago
  There's a vast difference between being a cost center and being willing to set money on fire. Our teams have a lot of autonomy or at least influence in product strategy but it's because we empower our product managers, designers and researchers to help business understand how to achieve their goals. A lot of these projects are greenfield where the team comes in pretty blank on what needs doing. Developers are part of the process too but they don't generate much insight into what customers want. Only how to execute.
  - kragen 5y ago
    > Developers are part of the process too but they don't generate much insight into what customers want. Only how to execute. How could you fix that? Would it be sufficient to give the developers more contact with the customers, or would you need to hire different developers, for example domain experts who also knew how to program? I ask because, when you're writing software, you're constantly making tradeoffs between different aspects of quality: throughput vs. latency, flexibility vs. performance, learnability vs. routine usability, information density vs. skimmability, recoverability from errors vs. security, predictability vs. everything else. The more you know what your customers want, the better you can make those tradeoffs. Ultimately "how to execute" is the automatable part of the job.
    - tootie 5y ago
      There's nothing to fix it works great. And it's worked this way at every company I've ever worked at. As hard as it is to find devs who can do frontend and backend you can't find any who are good coders and also know how to generate customer insights and spend hours doing interviews and requirements gathering. They're different jobs. When it comes to actually designing a solution then tradeoffs on implementation approaches are definitely done with the dev team.
      - kragen 5y ago
        I sure hope one day you're my competition.
      - donavanm 5y ago
        What youre stumbling on is these “big tech” cos are growing horizontally when possible, and its normally local engineering roles that used to seed build and manage new teams. Thats why there some pretty extreme reactions to promotion process or senior role interviews. Yes, knowing how to organize a team, mentor junior developers, do market research, evaluate customer feedback, model marginal cost, and write a business proposal are key skills over the lifetime of those senior ICs. Yes, I could backstop those areas for my team mates today. But once we succeed each of those senior developers on my team will fork off to their own team and repeat the process, thats how we scale out. A corollary is these self organizing teams add up to self organizing business units. The teams know what to build because theyve at read & internalized what matters to the business. And senior members should be involved with the 6-12 month planning cycles that happen across that business unit. So their day to day execution is informed by, and happens in the context of, the larger business. Think of something closer to hierarchal federation than directed work silos. WRT to “lighting money on fire” there are teams that look like that. But thats generally a speculative investment with a medium term (~2-3yr) goal theyre working towards. This is business, so its not free or infinite, and in a sense their efforts are competing with the alternative efforts that could be more profitable.

by tootie 5y ago

regularfry 5y ago

I can't speak for Shopify, but in general you want teams that don't need anyone to tell them what to deliver and when because they can be trusted to figure that out for themselves and make a good call. That can't be done without having customer representation on the team (which you should anyway), and having engineers capable of taking a customer viewpoint. That is what "self-organising" should mean, but few organisations are mature enough to transition to it. If you're in a situation where you need to show you're "spending their budget on high value features" that's a low-trust feature factory being treated as a cost centre by a remote client, not a value-producing unit setting its own terms.

tootie 5y ago
There's a vast difference between being a cost center and being willing to set money on fire. Our teams have a lot of autonomy or at least influence in product strategy but it's because we empower our product managers, designers and researchers to help business understand how to achieve their goals. A lot of these projects are greenfield where the team comes in pretty blank on what needs doing. Developers are part of the process too but they don't generate much insight into what customers want. Only how to execute.
- kragen 5y ago
  > Developers are part of the process too but they don't generate much insight into what customers want. Only how to execute. How could you fix that? Would it be sufficient to give the developers more contact with the customers, or would you need to hire different developers, for example domain experts who also knew how to program? I ask because, when you're writing software, you're constantly making tradeoffs between different aspects of quality: throughput vs. latency, flexibility vs. performance, learnability vs. routine usability, information density vs. skimmability, recoverability from errors vs. security, predictability vs. everything else. The more you know what your customers want, the better you can make those tradeoffs. Ultimately "how to execute" is the automatable part of the job.
  - tootie 5y ago
    There's nothing to fix it works great. And it's worked this way at every company I've ever worked at. As hard as it is to find devs who can do frontend and backend you can't find any who are good coders and also know how to generate customer insights and spend hours doing interviews and requirements gathering. They're different jobs. When it comes to actually designing a solution then tradeoffs on implementation approaches are definitely done with the dev team.
    - kragen 5y ago
      I sure hope one day you're my competition.
    - donavanm 5y ago
      What youre stumbling on is these “big tech” cos are growing horizontally when possible, and its normally local engineering roles that used to seed build and manage new teams. Thats why there some pretty extreme reactions to promotion process or senior role interviews. Yes, knowing how to organize a team, mentor junior developers, do market research, evaluate customer feedback, model marginal cost, and write a business proposal are key skills over the lifetime of those senior ICs. Yes, I could backstop those areas for my team mates today. But once we succeed each of those senior developers on my team will fork off to their own team and repeat the process, thats how we scale out. A corollary is these self organizing teams add up to self organizing business units. The teams know what to build because theyve at read & internalized what matters to the business. And senior members should be involved with the 6-12 month planning cycles that happen across that business unit. So their day to day execution is informed by, and happens in the context of, the larger business. Think of something closer to hierarchal federation than directed work silos. WRT to “lighting money on fire” there are teams that look like that. But thats generally a speculative investment with a medium term (~2-3yr) goal theyre working towards. This is business, so its not free or infinite, and in a sense their efforts are competing with the alternative efforts that could be more profitable.