4 ms·

It's easy and obvious to set up queues and hand offs. It seems efficient and logical and it looks good on a whiteboard. The throughput of work in flight is of c

It's easy and obvious to set up queues and hand offs. It seems efficient and logical and it looks good on a whiteboard. The throughput of work in flight is of course amazing. Then, much later, you realise latency sucks. People don't care that you have 100 features coming in 2 years. They care that you have the killer feature now. So that's what counts here: latency to customer value. The time between picking the next most valuable feature and putting it in front of paying customers, is the one loop that needs to be optimised. I'm lucky to work Pivotal Labs. Our archetypal team is one product manager, one designer, two engineers from us and two engineers from the client. Currently we are experimenting with building teams with embedded data scientists as well. It works because we can, as an autonomous unit, do all the work that needs to be done to take a feature from ideation to production. When you have that, it's amazing what you can get done. I know I sound all-knowing and clever and stuff. But if I'd been setting up a software project before working at Labs, I'd have done a lot of the same things as this article describes as the starting point. [edited to try and remove the impression that I would've Done It Perfectly From The Beginning, which is the opposite of what I was trying to say]

marktangotango 11y ago
>> The time between picking the next most valuable feature and putting it in front of paying customers, is the one loop that needs to be optimised. Well said, BUT how to determine that next most valuable feature? I worked on a product once that required quiet involved sales engineering support, feedback from the sales engineers doing POC on customer sites was, to me, the most valuable feedback of all. But for other low touch or consumer targeted products, I'm baffled how to do this.
- jacques_chester 11y ago
  Sometimes you do it by user interviews, sometimes by paper prototypes, there's a huge grab bag of options. My peers who focus on product and design would be better at telling you their magic, but from what I've seen it's deep and broad and the results are often surprising. We've saved customers a lot of money by discovering that wanted to build something that their customers didn't want to buy. From the engineering side, my role is to make development fast enough that product and design can find out whether they were right by having something in production quickly. This obviously varies according to project. For a highly gatekept ops culture, I could have something in an acceptance environment in hours that takes days, or weeks, or months, to reach true production. But sometimes we get true CD and a team of designers and engineers can put tested code in front of users the same day, and have meaningful metrics shortly afterwards. On my first project we had a hard, immovable 6 week deadline. We had a path to production after 3.5 weeks of pushing to get through complicated deployment hoops. Once we had the path to production our product manager and designer were able to perform laser-focused surgery on our backlog in the final weeks. They knew, sometimes within hours, what changes were being used and what had not worked. It was a real eye-opener for me. Still a standard I hope for on any project.
bkeroack 11y ago
> Our archetypal team is one product manager, one designer, two engineers from us and two engineers from the client. This organizational system is also referred to as "squads"[1]. We also use it at DSC and it works remarkably well. 1. https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ https://labs.spotify.com/2014/03/27/spotify-engineering-cult...
- jestar_jokin 11y ago
  I think "The Mythical Man Month" (1975) calls it a "surgical team". If this practice works, I wonder why it isn't common? Just postulating here, is it because most established businesses cling to whatever they currently do, and the next generation get their start at those big companies, and copy what they're used to? Or, is it because the people who have the responsibility for organizing teams do not come from a technical background, so miss out on reading material that discusses this?
  - bjwbell 11y ago
    Could partly be because you can't have any B players on a squad.
    - masklinn 11y ago
      That's not what TMM advocates for surgical teams. IIRC, the surgical team is an A/A+ lead, and a few directee/assistants, some highly specialised (TMM advocated for each team to have a designated tool-maker responsible for creating and maintaining the team's tooling like scripts or codegen)
  - deleted 11y ago
    [deleted]
- davedx 11y ago
  Also "cabals" in the games industry: http://www.gamasutra.com/view/feature/131815/the_cabal_valves_design_process_.php http://www.gamasutra.com/view/feature/131815/the_cabal_valve... [1999]

marktangotango 11y ago

>> The time between picking the next most valuable feature and putting it in front of paying customers, is the one loop that needs to be optimised. Well said, BUT how to determine that next most valuable feature? I worked on a product once that required quiet involved sales engineering support, feedback from the sales engineers doing POC on customer sites was, to me, the most valuable feedback of all. But for other low touch or consumer targeted products, I'm baffled how to do this.

jacques_chester 11y ago
Sometimes you do it by user interviews, sometimes by paper prototypes, there's a huge grab bag of options. My peers who focus on product and design would be better at telling you their magic, but from what I've seen it's deep and broad and the results are often surprising. We've saved customers a lot of money by discovering that wanted to build something that their customers didn't want to buy. From the engineering side, my role is to make development fast enough that product and design can find out whether they were right by having something in production quickly. This obviously varies according to project. For a highly gatekept ops culture, I could have something in an acceptance environment in hours that takes days, or weeks, or months, to reach true production. But sometimes we get true CD and a team of designers and engineers can put tested code in front of users the same day, and have meaningful metrics shortly afterwards. On my first project we had a hard, immovable 6 week deadline. We had a path to production after 3.5 weeks of pushing to get through complicated deployment hoops. Once we had the path to production our product manager and designer were able to perform laser-focused surgery on our backlog in the final weeks. They knew, sometimes within hours, what changes were being used and what had not worked. It was a real eye-opener for me. Still a standard I hope for on any project.

bkeroack 11y ago

> Our archetypal team is one product manager, one designer, two engineers from us and two engineers from the client. This organizational system is also referred to as "squads"[1]. We also use it at DSC and it works remarkably well. 1. https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ https://labs.spotify.com/2014/03/27/spotify-engineering-cult...

jestar_jokin 11y ago
I think "The Mythical Man Month" (1975) calls it a "surgical team". If this practice works, I wonder why it isn't common? Just postulating here, is it because most established businesses cling to whatever they currently do, and the next generation get their start at those big companies, and copy what they're used to? Or, is it because the people who have the responsibility for organizing teams do not come from a technical background, so miss out on reading material that discusses this?
- bjwbell 11y ago
  Could partly be because you can't have any B players on a squad.
  - masklinn 11y ago
    That's not what TMM advocates for surgical teams. IIRC, the surgical team is an A/A+ lead, and a few directee/assistants, some highly specialised (TMM advocated for each team to have a designated tool-maker responsible for creating and maintaining the team's tooling like scripts or codegen)
- deleted 11y ago
  [deleted]
davedx 11y ago
Also "cabals" in the games industry: http://www.gamasutra.com/view/feature/131815/the_cabal_valves_design_process_.php http://www.gamasutra.com/view/feature/131815/the_cabal_valve... [1999]