3 ms·

At Shopify, we tend to do whatever our engineers want in this regard. My team meets weekly and looks at a kanban project board. If we need to adjust, we have re

At Shopify, we tend to do whatever our engineers want in this regard. My team meets weekly and looks at a kanban project board. If we need to adjust, we have retros, etc and change the process. We have the autonomy. In a past life you would be told Agile meant “self organizing teams”. But in practice that was only allowed in a narrow definition of change under the prescribed process being foisted on teams from above. IMO while you need some consistency to get alignment on goals at a high level and coarse quarter-level goals, at the team level you can more or less let the team decide and then judge them on their effectiveness. Odd how so many companies want to do “what [successful tech co] does”. Yet those companies innovate their own processes.

snarf21 5y ago
One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.
noneeeed 5y ago
Nice to see big companies working like this. I wish more places would understand that different approaches work for different people, teams, products, technologies and contexts. There is no one true way, and most attempts to impose one tend to create something that is bigger and more complex than any single team needs. It's like the human equivalent of a code library that is trying to solve too many problems and so becomes an unweildy mess of config and options and meta-problems. We (Bugsnag) are a relatively small engineering team, so have the advantage of low comms overhead, and we do have an overarching approach, but each of the teams works a bit differently. Even from project to project I'll adjust what makes sense based on complexity/risk/size.
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.
      - 5y ago

snarf21 5y ago

One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.

noneeeed 5y ago

Nice to see big companies working like this. I wish more places would understand that different approaches work for different people, teams, products, technologies and contexts. There is no one true way, and most attempts to impose one tend to create something that is bigger and more complex than any single team needs. It's like the human equivalent of a code library that is trying to solve too many problems and so becomes an unweildy mess of config and options and meta-problems. We (Bugsnag) are a relatively small engineering team, so have the advantage of low comms overhead, and we do have an overarching approach, but each of the teams works a bit differently. Even from project to project I'll adjust what makes sense based on complexity/risk/size.

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.
    - 5y ago