Proposal: change the order of stage gates

[saintsal]

@saintsal said in Convergence Rules Of Engagement:

Gate 1: length of block & schedule communicated to fellows
Gate 2: specific modules decided with input/output between them agreed
Gate 3: modules prepared for execution

Looking at these gates now, I remembered that Gate 1 and 2 were actually inverted in an attempt to get us to an announcement by December 15th.

Since we’ve now decided to extend that deadline for Services, I think it makes sense change the gates to a more natural order:

1. Modules decided with input/output flow
2. Length of block and schedule
3. Modules prepared for execution

Let’s do this an accordance dialog: if you’re in favour it, reply with . If you’ll go with the group decision: . If you see an issue, please ️ and make an amended proposal.

[vivek]

@saintsal I’d propose a minor amendment to Gate 1: length of block & schedule communicated to fellows start date + length of block confirmed and applications open, and keeping the order as is currently stated.

I am happy for us to use “stage gates” as terminology, but it feels natural that gates 1 & 2 are worked in tandem, which seems a bit against the metaphor of gates, which suggests one must complete before the other is worked.

I want gate 1 to still be the top priority; the longer we wait to open apps the more pressure or lethargy we will feel as stewards. this gate will inevitably complete first in the process, by at least 3 months, with the launching of apps.

This said, gate 2 is clearly where our control lies while we regain footing on Services. the more progress we make on gate 2, the better we feel about gate 1, and in general, i agree that it is our focus now.

gate 2 informs gate 1 in many ways, but it need not be 100% complete to announce the block. i’d say aiming for 80% completion would be a wonderful goal.

Perhaps some of this is semantic, but in general, I appreciate the opportunity to reset and to test out the accordance model.

[saintsal]

@vivek said in Proposal: change the order of stage gates:

the longer we wait to open apps the more pressure or lethargy we will feel as stewards

I hear you here. I guess you mean the pressure to announce something as soon as possible? (I personally don’t feel lethargy when there’s a path open to get some meaningful design work done on a program iteration, but I see that you like to have a public announcement and deadlines to keep you on the move.)

Looking at the different design everyone chose at the workshop, there’s no obvious way to get to a length without first narrowing down on some designs. (I was hoping some of the versions we put forward would have some clear lengths and would highlight some counter-contraints or dependencies that would be useful to focus on, but it seems there aren’t any.)

The stage-gates are more than an arbitrary metaphor too. They’re a key part of the methodology (and well-documented) so we can’t just make them parallel and expect the process to work.

The question in front of us then is, how do we narrow down to a program length and start date without first agreeing on the content and structures in the program – and do that by a specific date?

I’ll think about it too, but since this is your proposal, I’m interested to understand – how do you see it happening?

[aliyajypsy]

@vivek said in Proposal: change the order of stage gates:

the longer we wait to open apps the more pressure or lethargy we will feel as stewards.

may i ask what is the rush here? i agree that we need to communicate a timeline publicly to those interested in applying/interviewing since we’re deviating from a normative schedule we have established in the public eye, or maybe more specifically, on crypto twitter.

why isn’t making a public acknowledgment, even if somewhat vague, suitable? as we pass time now constructively trying to redesign it intentionally and with evidence-based practices? a post such as ‘kernel is taking time to redesign a better program for you - we don’t expect the next applications to open for another 1-2 months with KB8 kickoff in Q1 2023.’

what do you think we might lose by taking longer to constructively figure out how we’d like to redesign kernel? i agree that it seems you like to have a deadline to keep us moving, but if it only creates pressure, it doesn’t feel healthy to me. it feels like we’re not carving the time for the meaningful deep work required to wean off SaaS applications and complete a transition to kernel services.

building on @saintsal’s point:

The question in front of us then is, how do we narrow down to a program length and start date without first agreeing on the content and structures in the program – and do that by a specific date?

if we could narrow down a program length and start date, the next step popping into my mind is an application ready to go live, which we also don’t have, and doesn’t feel accounted for.

furthermore, to think of receiving applications and managing prescreen review processes while ‘specific modules decided with input/output between them agreed’ feels too heavy of a workload simultaneously. i can only imagine it working if we divided responsibilities, and the rest of the team worked on ‘specific modules decided with input/output between them agreed’ while i solely focus on managing application intake and prescreen review processes with guides.

[aliyajypsy]

@saintsal agreeing with the stipulation that we communicate to the public our best gu-estimated timeline for our internal reflection time (~1-2 months) along with when applications will likely be live and when KB8 will likely kickoff.

I imagine this communication as a Twitter post, an email to all those candidates whose interviews were deferred, and accepted candidates who deferred their participation.

[vivek]

Okay, I’m open to the re-org of the stage gates formally. Changing my vote to

@aliyajypsy said in Proposal: change the order of stage gates:

KB8 kickoff in Q1 2023

Typically, we take 85-90 days between announcing the block and it actually starting. A December 15th announcement of apps already meant a kickoff of March 2023. Assuming an evolution of the past processes, we could still sneak in with a late Q1 2023 kickoff date, but only if apps open by Jan 15th. Here is the model if you want to play around with it yourself.

I support the evolutionary time, but we should acknowledge that this is what is happening.

@saintsal said in Proposal: change the order of stage gates:

(I was hoping some of the versions we put forward would have some clear lengths and would highlight some counter-contraints or dependencies that would be useful to focus on, but it seems there aren’t any.)

My suggestion is specifically for a 9 week Kernel Block, making space for a reflective week. I’d want to spend more time in Aliya’s suggestions here in other posts (“setup of office hours, mentor engagement, guide outreach.” Maybe missing some counter-constraints / dependencies?

@saintsal said in Our Clearest Learning Container: KB8:

Lots of great ideas here, and I can some convergence possibilities right away:
several proposals have a break, especially around 1 month in
breaking things into smaller parts with starts and ends, than a more nebulous, layered flow
seems a few people are interested in exploring smaller blocks

I the convergence thoughts. Breaks & smaller parts, deeper learning environments. Also open to smaller blocks and keen to see how they might work. (Noodling on a 9-week spring / 4-week summer / 9-week fall timeline, which we’ve floated in the past – not feasible for '23 anymore, but maybe '24).

I also have now spent 3 hours writing 2 responses, and am yearning for some time together to untangle together outside of the forums. Just putting that out there

[aliyajypsy]

@saintsal can you share your 4-week idea for a Kernel Block that is a puzzle piece to continuous Kernel? can you also share your idea for a simultaneous 3-month long build track that’s only available for fellows who have already completed a block (the other puzzle piece)? and share how the two would complement each; one feed into the other? Salim’s 4-week timeline has a handful of elements worth considering in our discussion for program redesign, whether we vote for a 4-week program or not.

since i don’t have much program design experience, i’m questioning my authority to share my opinion for comprehensive program designs in this process. my opinions are mostly based on ‘senses’ and ‘feelings’ that i have. sure, they’re based on real-life experiences which are valid, and i have helped to coordinate two kernel blocks before, as well as short experience in philanthropic programming. but i can’t say my opinions are grounded in research, or many samples of lived experience. at best, they’re grounded in observations i’ve made from being around kernel fellows for two complete blocks and the time between. i do have plenty of fellow anecdotes in my repertoire, but i’m not sure it equips me to participate as fully as the rest of you in the redesign. Vivek and Andy, you have the experience of running Kernel 6-7 times + prior work experience in senior roles. we know that Salim has worked in such educational environments designing programs for 10+ years.

i think right now is the point at which i’m beginning to learn - about web3, about peer learning environments, about program design, and i’m grateful to begin at all. i thank each of you. i thank you for giving me the chance to learn alongside you and from you, and trusting me to do this work. i just want to call out my weakness here, as maybe my time right now can go to another effort. and if you’re ever wrestling with specific facets, i’d love to hear and talk through it, and provide my opinion once ideas have reached fuller fleshed out forms.

lastly, i sense tension between the baby Vivek and Andy have built and Salim’s work experience and best practices. i’d would like to frame this tension as a strength. we have your three experiences building peer-learning environments together in one place. how lucky are we? it is an immense strength that bolsters our ability to improve the experience we create for fellows. i don’t want us to get lost in this strength or be frustrated by it. i’m hoping we can communicate clearer, better. whether that’s here, or in sync meetings.

[vivek]

@aliyajypsy said in Proposal: change the order of stage gates:

lastly, i sense tension between the baby Vivek and Andy have built and Salim’s work experience and best practices. i’d would like to frame this tension as a strength. we have your three experiences building peer-learning environments together in one place. how lucky are we? it is an immense strength that bolsters our ability to improve the experience we create for fellows. i don’t want us to get lost in this strength or be frustrated by it. i’m hoping we can communicate clearer, better. whether that’s here, or in sync meetings.

strongly agree and believe we can find something better together. we’re in the thick of the search! it’s a struggle sometimes, but i am grateful for your words and your honesty aliya, it comes through as always. & thank you sal for pushing us in generative ways.