How We Work #3: "Deliberate Allocation"

[@pedroaquino5496]

All the three concepts focus on building the morale of the team. Having uninterrupted time, being able to change / reduce scope and shipping things on time without technical debt really makes people excticed Plus, being self managed and having autonomy on how to work sounds like heaven for product teams.

[@xpcoffee]

Thanks for the video, Ryan. From the video it sounds like you have 2 core teams (small/big batch) + oncall + operations + security + infrastructure + performance. So 2/7 of teams can work on core design/development, with 1/7 of teams being able to concentrate on larger scale design. In my experience, this kind of separation leads to engineers coveting feature teams as spaces to do "fun/challenging/career-advancing work" vs. operations/performance teams being dreaded as spaces for "stagnant/grunt-work". How do you deal with this?

[@mabeltan8059]

I'm also curious to know how this is handled. Do the people in these teams rotate?

[@davidbcg286]

Loving this series of videos. Thanks for sharing

[@davecrow7622]

With the integrated teams, are there times when one team member finds they don't have much to do on the project during a cycle? For example, the QA person might not have anything to QA until a few weeks in to the cycle because nothing has been built yet. And the designer might have less to do towards the end of the cycle while the engineers complete implementation. I'd be curious to hear how you handle those gaps if they occur. Thanks!

[@feltpresence]

Good question. In the case of QA, there's quite a lag until they have something to look at. That's ok. We don't have a "hand off" between design and development here because our designers can code. That means that even up to the last moments before launch the designers can move things around in the interface, adjust copy, fix rendering issues, etc. That could be good to describe in a future video. The way we work "uphill", the designers and programmers are both running the apps on their computers and checking in changes to the source code in parallel. The designers will stub out views, sometimes with real data sometimes with mock data, and at the same time the programmers are working on the underlying wiring and APIs so that the views do the right things.

[@ovidiuc4]

So awesome that you're sharing all this. It would be great if, with these conceptual explanations, a practical example would be given. Say, in the "concept, not a spec", the concept would be something like: "we need a quicker way to delete and restore a task" and the non-desired spec would be: "make the task draggable to a trashcan icon that you put on the bottom right of the screen, with an undo icon afterwards; send notifications to all involved; allow unsubscribing from these notifications". I'm just making this up, I don't really know the Basecamp interface. I'm curious what you'd do with allocation in the case where there's no budget for a separate team dedicated to support and unexpected things, as is the case in my situation. Can't wait for the next videos :)

[@natelarcher]

Love the series Ryan! I know that you use a concept of the solution as an input for the 6 week cycle, and not just the problem alone. Is this something done while defining the work? If so, aren't these separate contributors and some info loss is a reality? And what if their is a clear problem needing deeper investigation /research, does this go into the cycle? how do you allocate time to fully understand the problem in order to define the concept of the solution?

[@sugarfreejones]

Do devs get to cycle through "on call"? In our org, devs would not be happy not working on product for extended periods of time

[@SteveHazel]

so all bug fixes wait for the next 6 week cycle then? i guess they'd have to with this setup. i guess that's fair tho.

[@cdamian]

It would be interesting to know how many teams there are and the types. Big Batch, Small Batch, Infrastructure, Bug Fixers, ... anything else?

[@feltpresence]

The Core Product team does cycle work by forming into Big Batch and Small Batch teams. Outside the cycle there is On Call for the technical side of support, SIP (Security Infrastructure Performance), R&F (Research and Fidelity, for some demanding front-end projects like our text editor), and Ops. Finally there are two mobile teams: iOS and Android.

[@cdamian]

Ryan Singer thanks! How many big/small batch teams do you usually run in parallel?

[@feltpresence]

One of each. The six-week cycle has two teams working in parallel: one Big Batch and one Small Batch team.