This is the last week I had in mind to get us to final designs. Still lots to do.
A few more shapes to explore:
Fractalise everything: mini-accelerators, weaving learn track explorations, etc.
and it’s opposite, to lean into centralization where it’s happening and take advantage of its possible efficiencies
A shape without any special roles (other than Stewards) which effectively means turning Guiding and Guild Leadership into a learning track or topic
A shape with no applications, just guest passes and headhunting requests
Then circling back with all the learning to:
Progressive improvements on the 8-week block
There are a few deeper prototypes I expect to open up more useful configurations: sponsor-guided research, Guest Passes, Mentor Impact (ask-orient-respond), getting into specific versions of mini-hackathons…
Going to try to keep my head down to designing for the next 2-3 days. So if we have calls, I’ll try to keep them short and shipping something specific. Crunch time!
By now, we should have had our hard conversations and have the dependency graph locked in.
So, we can start assembling our various Options into potential Shapes of programs.
That said, as we continue to explore Options, I encourage you to ground them to reality by making prototypes with actual content, and ideally based on personas with specific learning goals.
I changed the categories in the forum to a new structure and moved some posts around.
I’d like to lean on something I picked up from indigenous knowledge in KB5 - that sufficient dialog of a certain character better serves the same goal that voting does – especially in small groups. Put another way, the chiefs know that with enough conversation around the fire, empathy and understanding is given space to emerge, and there’s no need for voting or adjudicating. Everyone already knows what to do. It’s evident.
So with the Shapes category, l’ll take the lead with one thread per Shape being explored, in the same style as “updates from the kitchen.”. Under each thread, can I ask that you follow and engage in the same type of dialog with each other as before? These expose needs in actionable ways – inputs and constraints to design for.
You’re welcome to follow my lead and suggest shapes of your own too, but I still need your feedback in the form of this kind of dialog.
We’ll modify the concepts from the design feedback that emerges from our discussions.
Good to see your thinking exposed - thanks for that.
Trade-off curves
The trade-off curves will be much better with numbers, to really see where the important ranges are for us to manage. Without them, they’re a useful expression of opinion, but not that actionable for designing options. For example here, if there are clear answers to how many notifications per day become too many, we can design around that.
Personally, I think we’d see that a lot of the linear, up-to-the-right graphs are more likely to be bell curves. Specifically, actionable info and steward damage control would go up in cases of too few notifications or too little or unfindable information.
Decentralisation in our comms
Stepping back to the main concept, it would be useful for you to show which use cases you see depending on Comms, and how you distribute them in those two categories.
One thing I’ve noticed is that tools that require “admins” force centralisation. Tools that give agency to people without them needing permission don’t. (Vitalik explained this at a high level which is relevant to us here.) That’s a salient issue for me when thinking about what Comms tools and modes I need for Topic Tracks and Juntos – and tbh any type of education that’s peer-driven – since we want our tool choice to “slope down” towards more agency rather than depending on permission.
Started thinking of a “program set” or shape, based on an outlying starting point.
I didn’t want to start with the 4-month learn track, saving that to do together with whoever wants to join.
And then I thought 'What if Learn Track and the Firesides weren’t the driver? What would we do?"
I was thinking about progressive layering and calmness, both of us and the fellows.
I started down the middle, with the fellow’s view of the experience. The rest of the structure was added after, and a few things moved around. I’ll walk you through.
So, without Firesides and Learn track as the main drum, that leaves Guilds, Guides and Juntos (using KB7 terms to just group the resources, though I think of them more as parts to be reassembled.)
I started with this idea that fellows could ask questions to Guild Leaders, and they’d respond with pointers, like ‘to learn that, go check this and that out.’ Then realised that guild leaders have questions too, and we’d need something like guides, but more a dedicated group of mavens like one of the Peers options.
So, we can help each fellow turn their questions into guided explorations that turn into a short reading list. Those reading lists can then be opened as event tracks in convo. We can add guardrails to that with the paper party format. Now we have convo filled with fellow-led convos based on a literal ‘paper trail’ co-created with maven assistance. Cool.
This didn’t feel technical enough in a few ways. Firstly, non-techies shy away from looking at the technical, and get stuck in a layered maze of hype and metaphor, when actually just looking at the technical would be easier and clearer in the end. Most of the big defi mechanisms are explained in just a few pages of a long paper, and most solidity contracts are really short. Seeing a coder walk you through one or two, and they don’t feel like unreachable magic. Plus coders themselves learn from looking at other people’s code. So Contract Safari does that – just an idea to look at a contract together, and cruise around the on-chain data to see what it does in practice.
Now I came back to Learn + Firesides, and saw that the convo events listing was a way for @cryptowanderer and @vivek to orient around the topics and directions of exploration that are of interest to the active fellows. I think they’d be able to see where they’re headed, and anticipate topics of interest. With that, choose a relevant cross … to be continued
This is a long post, but just to take the pressure off, here are the takeaways:
The process will change now to take responsibilities for design off you for the next phases, effectively relieving you of participating so intensely in the design sprint.
This is intended as a kindness, to let us off the hook of a few things that are proving difficult and responsibilities that are unwanted, but still to get us to the end result we wanted.
We’re facing a combination of unfamiliarity with design techniques, erosion of commitments and coordinating through an uncertain process- we’ve now taken this design sprint approach as far as it can comfortably go this time, if we want to be certain to have usable designs by end of Jan.
There are too many distractions and external obligations to juggle right now, and we’ll just strain to hit the next gate together this week.
To be clear, Convergence continues, but no longer as an intense, sync sprint for the coming weeks. I’ll focus now on turning the work we’ve done into program designs with less complication.
I’ll still need you to spend the next week on a few things:
Take time to think about and have the ‘hard conversations’ - to surface trade-off curves from them.
Think about the Options you want to take responsibility for stewarding during Kb8, and if there are any conditions.
Those, and the options you’ve created, will be my inputs to produce a set of two final designs (main and fallback). This work will be done openly with more “updates from the kitchen” and maybe you’ll be inspired to work on convergences of your own, but it’s not required.
This post walks you how I made this decision step by step. Jump down to the bottom section called ‘checklist’ near the bottom if you want to cut to the actionable stuff I need from you.
It’s time to speak some truth with love.
Please take your time with this post, knowing you have relief from the intensity of the another heavy design sprint this week.
It explains a few things, and meanders into various deep explanations about remote collaboration and observations about steward communication that are more broadly useful, and build on our baby async muscles.
I’ve been trying to work out how to move us forward with a new timeline, considering how the first week of this process has gone. A familiar sight, and honestly stressful: goalposts are moving, and I’m trying my best to be accommodating. But I think I’ve already let things slide too far, and we’re sliding down a familiar slope of collaboration unraveling.
But there’s a silver lining. We can double-down on the new muscles and other wins from the Convergence process so far.
It doesn’t serve us well if I absorb these issues silently, so here’s the long process I’ve gone through and how these issues affect us. Sharing it in the hope can all learn from this and improve for next time.
Kindness and improvement
Since Thursday, I’ve been trying to solve the process puzzle with two themes in mind.
Kindness - If there’s something that isn’t working, feeling hard, or creating resistance, let’s be kind ourselves and not push.
Systems thinking - a system emerges between us based on how we individually choose to work together. It’s just what happens, and rather than blame, I prefer to just say what happened with acceptance, and respond with an improvement to the system.
Why such disengagement?
When we tried to design things together in KB7, like Adventure Time and the Application Review process, it didn’t work out. I thought the lack of engagement was because we were in a block and you were all so busy. After the block, it was clear we were all tired. Now, these aren’t the case, but there’s still a noticeable level of dissent and resistance in the air. Similarly there’s a death by a thousand cuts thing happening.
I’ve been trying to bring care and understanding to this, to hear people out when they take shots at me or others.
On the other hand, we have to be responsible for the results, and look not just at participation, but what was produced during this phase:
Option counts: there are few options for the Learn Track or Firewides (all of them were prompted, not proactive explorations ),
Prototypes and sense-checking artifacts: there weren’t many explorations around personas, timelines, or any other prototypes that I’ve introduced so far, which are part of phase
We’re not all proactively exploring new ideas, or seeking better options.
Why? One reason is we have a lot on our plates, and even though we said we’d clear these two weeks to design the program together, we had trouble doing this. Why again? How did the calendars get so full, when it was just in December we were looking forward to this dedicated time together?
Self-compassion
There are plenty of reasons to feel anxious about this strange process. We like the idea of building these new muscles, but there’s still need for constant reminders (like to read a short paper on a process we’re about to commit several weeks to), or stepping in the firing line between two people to remind them to turns “noes” and “I don’t want tos” into exposing constraints and counter-proposing new options. In terms of learning design skills, it’s clear there’s no proactive learning beyond workshop times, even when homework is assigned. To me, there’s a strange disconnect between “we’re a community of care” and “we want to design this with the fellows in mind”.
On the other hand, we’ve now got some baby async muscles, and we have momentum! We’ll gain a lot more if we keep going with those practices.
Empathy towards our anxieties is something I’ve come back to constantly over this weekend, with a lens of Kindness.
I see a kind of peer pressure here - to say we want to build these muscles - but that’s opposed to the comfort we all have from sticking to the status quo, or ignoring it and turning to independent projects. It’s like a body-building club but not being sure if we actually want to lift yet. (Like, bro, do you even?) This peer pressure creates anxiety, and that needs to be said out loud for us to get a handle on it.
These patterns are noticeable all our steward collaboration:
constantly deferring conversations
filibustering meetings
filibustering meetings then complaining that they take too long
questioning the process like Larry Flint: ‘I don’t recognise the authority of this court!’
I’m joking around a bit here, but these are all avoidance behaviours usually rooted in some kind of anxiety. I say this as a form of self-compassion.
We’ll gain from reflecting on why this is, but that requires time, care and a low-pressure environment without a looming deadline.
Back to the work to be done, I have to accept this is the level of contribution we have to work with right now, and figure out how to bring us all through a process that gets us to a design in January.
Figuring out the new timeline.
To get practical, we’ll start with my current task, to update the timeline with the delays and retro feedback.
Seems simple at first, but there are actually a lot of constraints to work around, starting with the time limits, then working with the externalities that affect our productivity.
The genesis agreement
In December, we made an agreement to dedicate time on focus this for a two-week sprint, some time in January. Vivek wanted it earlier in the month, and we agreed. But when we got to January, we remembered MLK Day. (Systems thinking here. No blame, just looking at how we were being accommodating, and how we accepted commitments without sufficiently considering our own calendars.) So the combined constraints (the superset of two weeks bocked minus one day removed) reduced me down to 9 days.
After we saw we’d miss the first gate, we said we’d extend to the following week, but this actually conflicted with a trip I planned based on our original agreement from December. Combined with KBK taking Friday’s Nemawashi time off the table, this leaves us with 2-3 days per week for the following weeks.
2-3 days per week, with 8 days remaining require an extra 2-3 weeks.
But there are cascading factors that need to be anticipated.
Ability to focus affects our speed
These two weeks were originally proposed to be focused creative time for deep work, with other obligations cleared from our calendars. That hasn’t happened, and it’s shown in both our results (so few options, trade-off curves and almost no prototypes) and in the stress level since you’re all trying to juggle other things.
I should have re-explained Surplus Time when we came back together in January, but it’s still worth recapping this now.
No context switching
Almost all successful creatives know they need to block off long chunks of their calendar to properly get into the right head space. (Blogger Cal Newport popularised the idea of Deep Work, also defined by its absence of context switching, but there a range role models who came before, like Twyla Tharp and Paul Graham, who live by this. ) This principle is axiomatic.
Redesigning a complex program like Kernel requires a lot of thinking, not just writing and prototyping. It’s writing or prototyping, then going for walks (literally) to think and going for wonders (figuratively) to see what possibilities lie around that corner. This requires a clear mind.
These explorations can’t be done if you bring a task-completion view of productivity, trying to clear off one task as quickly as possible to move onto the next. Especially if that next task is a different context from the design work.
Surplus time
There’s a completely different quality to our creative work when there is surplus time available, rather than when there are other obligations waiting in the wings, making you feel your time is scarce.
Instead of getting it done quickly, you know you have the rest of the day to think about it, and play out possibilities. That type of exploration produce the real break-thoughs and benefits in genreative design.
So it’s a requirement to create Surplus Time in your calendar. To-dos and external expectations need to be deferred so strongly that they don’t cloud your head-space.
We’ve loaded our calendars with a bunch of other commitments, creating time scarsity. Andy has a set of other projects from KBK, to the book to writing another syllabus module, plus personal admin errands. Vivek’s loaded up his calendar with what looks like fundraising/endowment meetings. Those make for bad deisgn days, and force you back to the minimising habits of todo-completion.
(I wonder what made everyone else’s overlaps so urgent that they had to be scheduled during this reserved time. On a more personal note, I canceled meeting my uncle and aunt from Canada who were passing through Istanbul this week. I did this to honour our December commitment to dedicated time to this work together. Seeing nemawashi cut down for pottery class is honestly a tough pill to swallow in comparison, but it’s not about that specifically - there’s a general imbalance in how we treat our time commitments and how these things signal to others. More on this - Domino Disengagement - below.)
Longer time chunks means less on-ramping
Context switching at the weekly scale has another time cost attached. There’s so much information and nuance to hold in our heads, we have to rsetart after a break. Coming back to a all these complex options and trade-offs after a few days requires time: re-reading those threads, rethinking through the permutations and nuances. Or it turns into misunderstood replies, and more back-aand-forth for people to reiterate.
So we need to account for on-ramping time each week we restart. Call that a half-day - or if you’re still trying to juggle other things at the same time, then a day.
That cuts our throughput down by a day per week.
Calendar Crunch
Since we’re all trying to balance different types of work with this, those types of work have different rhythms.
Think of those different patterns as the teeth on gears turning in a clock. Some cogs have teeth that space a day apart, some weeks, some are irregular. You’d see visually how they can’t all turn together. There’s lots of slipping and starting and stopping. One gear turns until its tooth moves across the gap to connect with the other tooth on it’s contacted cog, then that cog waits for the slip of the next one. By the time the last cog is moving, the first is slipping again. A lot of energy is wasted through a thousand small delays.
This shows in our work in terms of delays waiting for each other, and in the forum post backlog that seem to build up all of a sudden. The stress from the unread notification isn’t from the process or because it’s a forum, it’s from the calendar crunch. The mix of external calendars everyone is imposing causes the gears to slip and grind, and that creates spikes of activity and backlogs. Hurry up then wait.
The clearest example here is that KBK conflicts with Nemawashi time, and on a Friday at that, creating a 3-day gap with the weekend. But it’s also hidden in the days full of meetings, which is a different calendar pattern to writing. So any day one of us added some meetings, we’ve introduced disconnects and stress to the group process.
Calendar Crunch costs us delays compared to the altdfnative - reserved time where we’re all 100% focused on the same project. What might be lost in waiting around individually is made up in Surplus Time explorations and being available to each other without externalities causing delays. That costs us 50% of our speed easily.
Now, even though we say we’re doing this in 2-3 days per week, blocking and investing that time, we’re actually working at the pace of less than a day per week compared to focusing together.
Eight days of work left (which was already a bit of a stretch goal) now takes 8 weeks to complete.
Domino Disengagement
This also appears another way, this habit of just opting out of a day here or there or without notice. Doesn’t seem like a big deal at first, but it’s a crack in the dam.
Vivek wanted to take off a local holiday. I said okay, we can still work around it. But a few days before, Aliya also said she’d take it off. That’s a bigger hit, to lose half the group now, but why should she not take if off if Vivek did? When we reached that day, Andy knew we’d be light, so might as well use that time for some personal errands. We lose a whole day.
This isn’t specific to this case - it’s a regular thing among Stewards. As we’ve seen with Peer Jeopeerdy, building a Guides dashboard, working on application questions, usability testing Kernel Wallet. Somebody opts out of a small commitment, and the domino effect collapses it within a week or two.
This explains difficulties we have in scheduling more than a few weeks into the future, but also inconsistency at keeping meetings even a day ahead.
In Convergence, it has another compounding effect. If we’re working at such an inefficient pace as a group, and schedule keeps getting longer, people have to let other things impose. So there are bound to be more of these Domino Disengagements. So it’s a race to the bottom, more disengagement turning into less commitment turning into more disengagement.
This causes the end result to slip farther and farther away, in unmanageable and unpredictable ways.
Yet the expectation still falls on me to steward the process and get us to the end result. So I have to take this into account in the plan.
That means anything longer than 2-3 weeks is dead in the water.
All process, no design
All this puts me in an unrealistic situation, because this forces all my attention onto management and facilitation, and away from actual design work. And this process, while collective, needs me to be focused on actually designing things.
So if there’s a way forward, it has to free time to design, especially mine since I’m the one who’s done this before.
The engine is stalling
So we can’t extend into 3+ weeks, we can’t keep this work in parallel with other work, we can’t coordinate enough to get it done in the next week, or block off 1-2 days of sync focused time per week. We need everyone to still participate but it can’t require so much management that I don’t have time to push the designs forward. Fun puzzle, right?
The engine is about to stall. So we need to change something now, not at the end of this week, after the stall happened.
Being kind to ourselves, there’s no point pretending this isn’t the case and trying to power through another week. There’s little to be gained from asking for a renewed commitment, and asking you to clear your schedules (especially seeing how much you’ve loaded up for this week alrady.)
If there’s resistance to do some of these things, let’s listen to that and accept it. I also don’t want to be the cat herder and make you do things you don’t want to do. So let’s not.
It seems there’s a path forward in making this process almost fully async, but that will take much more time to conclude. That might be a good motion for KB9, but not KB8. For KB8, something else has to change.
Taking the load off
I can keep Convergence going to get us to its promised outputs, but not with this design sprint carrying everyone along.
So we’re dropping that.
Instead, I’ll just need you to expose trade-offs and other contraints that only you can surface between you. That means having the hard conversations, but easier to just schedule them one on one if this specific Nemawashi time doesn’t work for you.
We still have a bunch of useful options to work with, so I’ll just take those and start to work them towards a final set of two.
Anxieties about the hard conversations
More kindness, empathy and self-compassion please!
I think another cause of anxiety are old conflicts between you that have been avoided.
To wrap up this long post, here’s a story.
This one time when I wore big jeans and listened to Korn, after cleaning the parking lot of my dad’s strip mall, some guy in a truck drove in. He kicked about a week’s worth of fast food trash out his door and drove off.
My dad and I were in our car, about to leave, and we caught up to him at the traffic light. My dad commanded this fat-necked Whopper to go pick up his garbage, who wondered what was the big deal. Of course, that form of dialog worked amazingly well and turned into a hand gesturing game, then to to drag racing their shitty towncar and shitty pickup. After a cutting each other off a few times, they finally stopped blocking traffic both ways. The guy got out of his dirty Chevy - a CFL pro footballer it turned out – and came running. This guys mistake was to throw a punch first into the open car window, and stepped back gape-jawed when he saw the blood on the windshield. My dad’s mistake was to then get out of the car. This turned into a fist fight, and I jumped out and tried to break them up. I was scared, I was scrawny, but I was also a Karate Kid at my school and man enough to have a fuzzy moustache. I ended up standing between these two men, holding them apart with arms outstretched, while they tried to windmill punch each other, Popeye-style.
This cartoon fight lasted quite a few minutes, with me in the middle but I never actually took a hit.
How did a little kid keep them apart? Neither wanted to escalate but neither of them wanted to back down.
Still, my dad ended up with a broken nose, the footballer with a criminal record, and I got this strange story to tell you about latent conflict.
Thank you for your patience. I hope the payoff was worth it. Now to the the moral of the story:
It’s time to just get through our hard conversations. These things have been sitting for too long, they aren’t going anywhere but aren’t serving us. We have some new tools for this dialog , from trade-off curves to the mirror game. We have better understanding and empathy about each others’ needs. We have a clear common goal. We have a good, immediate reason to face these issues: direct improvements on the next block and our own individual experiences of it.
We just need to get over the need to keep holding onto these conflicts without either deescalating or facing them. Also Old Sal would love to stop doing cartoon Karate.
For me to take this design forward, I need the trade-off curves from your hard conversations, otherwise the output of this process will simply avoid them. That’s not going to lead us to big wins, and will persist the problems we’re here to solve.
They can be done by learning about each others context, and explicitly describing ripple effects, trade-offs and other actionable dynamics – stuff that can be used to understand where these underlying repellents come from so they can be addressed or mooted by design. Then writing them on the forum for reference.
Checklist:
Think about your ‘hard conversations’ and list them out. Maybe go for a walk.
Have your hard conversations. Try to schedule the hardest ones first. Turn them into trade-off curves and other actionable explanations
Think about the conditions that make you really happy and in flow during a block, and share those too
Update the dependency graph with options you truly want to steward and believe you should
Momentum to build on
Stepping back, there are a few wins to celebrate and build on from our week of Convergence:
We’ve got momentum using a forum, which is big pillar of async collaboration
We have deeper understanding of effects on each other when running a block
We’ve started seeing new options that offer incremental improvements
We’re starting to be more accepting of strange new ideas that can open new doors
There are issues we’ve made progress on, but still need some elbow grease:
Difficulty managing time and deferring commitments
Figuring out who’s really up for upskilling in user-centric program design
I’m spending too much time on cat herding and writing dumb stories (mainly cat herding), not enough on actual design
The new timeline
So we finally arrive at some kind of workable timeline:
This week - having the hard conversations. Output: trade-off curves and conditions for running your options (needed by next Monday)
I’ll be heading into the mountains for a long weekend, probably back Tuesday, then I’m going to just dig into this like a linebacker at McDonalds. Rather than impose a gate, I know it’ll take me a week or two, but doing it alone will be more predictable.
Next week, I’ll be working on combinations for Kernel shapes. To save everyone’s sanity, I’ll work on this solo, sharing “updates from the kitchen”. Maybe this will motivate some of you to permute and design some shapes too. It basically starts with picking options from the Depdendency Graph and seeing how they work together in prototype form. It’d be great if you want to play along, but it’s completely optional.
This will take me a few weeks tops, and during that time, I’ll need you to be available and responsive to me.
I want to express thanks again for the trust you’ve put in me so far, even if its been hard and done with some reluctance. I wish I would have called out these issues sooner, because you would have had a calmer experience of deep work and async, but overall I hope you’ll agree that our chipping away is getting us to a better place.
We’ve talked about Friends Of Kernel and Guest Passes before, and a rough outline is described at the bottom of Magma. (the 3 blue arrows that cross the big ring diagram)
The Levered Pipeline will be based on this design for Polygon but designed for the levers also described at the bottom of Magma:
what type of project-support do our fellows need more of now? which skills and attitudes?
what % do we want to allocate between in-bound vs referal?
what types of adventures do we want to see more of?
who do we want to attract who’ll intrinscially be role models and shape kernel culture block-on-block?
This is largely because of the activation energy required to get people just to use convo + organise an event,
I see this kind of “convenience” axis as quite important. The easier we make it on people to propose conversations, the more we’ll have. Arguably, we’ll also have a wider range too, both in terms of topic and quality, but also adding more diversity from interests and motivations that ‘comortable hosts and organisers’ tend to share.
So from this POV, all I was getting at was that Weekly Open Space actually extend into the more convenient end of that spectrum, where the open space session’s host doesn’t even need to think about scheduling or promoting (even facilitation). The Open Space structure provides for that. If that’s an option for fellows, then Convo doesn’t need to cater to those use cases, and can focus on catering the “more serious” hosts.
This is something we should copy to the Convo or Unconference thread, once we get there.
Alrighty then, for the next 2 weeks, it’s go time!
First, just some quick vocab. I’ll start to use “module” as any part of Kernel we’re taking on within this convergence process. So far, we’ve been thinking about these as puzzle pieces or timelines but let’s add some structure to that.
A module can be a fellow-facing set of events (firesides, learn track, guilds…) , or some service we offer to other stewards (convo, weekly email).
While modules might overlap in functionality, each module only has one steward designing it.
Each module has multiple Options, the first being the “Fail-safe” or last known working version from kb5 or kb7. The idea with Convergence is to start by creating other Options, usually exploring a new concept, and optimizing for a single need or performance measure.
Modules will start as low fidelity “napkin sketches” exploring wide variations and possibilities, and as we progress, will become “production ready.”
Tue Jan 17 - 2-3 full option sets chosen, Learner-centric dry runs, Primary option set chosen with fallback options
Fri Jan 20 - Primary or fallback options ready to roll
These are set-based convergence phases, which is a different approach than spec-first, which is what most of us are used to. To avoid some assumptions that might lead us astray, pleaseread this short paper (14 pages) on SBCE, particularly the section on principles (p. 73 - 80).
Phase 1 - Dependency
Phase 1 is about framing these Options and is divergent.
Modules Options have dependencies on other module options. For example, Guilds and Juntos depend on the Convo app. But others will be emergent. For example, we may learn that some Guild Leaders have target personas that depend on the Application process, or explore inverting the planning dependencies between the Learn Track and Firesides.
The goal of Phase 1 is a Module Dependency Graph. Basically, this is a master list of all Modules, their Options, and which Module Options depend on other Module Options.
This will allow us each, as Module Stewards in Phase 2, to have a definitive list of which other Modules depend on us.
At this stage, we’ll be “low fidelity” sharing timelines, high-level content plans, participant criteria and major user cases or user journeys – for each Option.
We’ll also want to start to think about Trade-Off Curves that affect the performance of our Modules, as a headstart for Phase 2.
If it feels right, you can advance to more elaborate artifacts from future Phases – maybe to explore the viability of your idea with a prototype, or as a way to illustrate your concept.
The important constrain for this phase is to aim for 3-4 Options for each Module (including the Fail-safe).
The “convergence event” here is freezing the Dependency Graph. After this point, if you have a dependency on someone else that’s not documented here, that’s a problem. We’re saying to each other at this point, “the future range of possibilities I’m putting forward will be within this known set of options with this known set of dependencies on you.”
Phase 2 - Fit
Phase 2 is about converging on good combinations of Modules.
For example, working out that Fireside Option B works really well with Guild Option C, any Learn Track Option, but works poorly with Convo’s Fail-safe.
The goal is to arrive at 2-3 “full sets” or alternatives for complete Kernel programs. This will give us a few options for “Shapes” that work well together.
To do this, we’ll elaborate on our various Options, sharing more detail like deck outlines, UI flows, event formats. and test content.
Ideally, feedback isn’t given as a “no, that idea is poop” but instead responding with the trade-off curves that are causing negative ripple effects.
As we learn which of our Options are not ideal fits for others, and can start to voluntarily eliminate our own Options if we see fit. (Keeping in mind they maybe resurrected in the next block.)
Our convergence event here is to Dry Run but differently from how we’ve done it the past – this will be done as a Fellow Role Play, where some of us will act as various personas, to “user test” the experience at a high level and give feedback.
Here we should be able to prioritize which Shapes we want to elaborate on first in Phase 3, and which become “Fallbacks”
Phase 3 - Feasibility
At this stage, we have an idea of which overall shape we’re aligned towards, but since we haven’t fleshed them out completely, we still need a margin of error.
So here is where the Module Stewards get their leading Options ready to roll. If we find something that doesn’t work as well as we thought, we can switch to one of the Fallback options, since it’s still within the agreed range.
The final convergence event is a classic Dry Run, where we run through everything together (and quickly!) just to get an overall feel from a Stewards perspective and prime ourselves for the overall Shape we’re ready to deliver.
Rhythms
Daily
Every day, let’s start our Nemawashi time with a quick Agile standup (todo, doing, done in 2 minutes or less) explicitly flagging people we need to talk to. The rest of that call is in breakout rooms, mainly for 1:1 checkins and feedback.
Sometimes we may need group workshops, but I’m hoping those will be limited. Ideally, most of the communication will be Module explanations and feedback in forum threads, and when more fluid conversations are easier, that happens as needed with the next Nemawashi time being a stop-gap to prevent waiting longer than 24 hours for a needed conversation.
Phase rhythm
Each phase ends with an integration event, followed by a team retrospective.
The retrospective is focused on process, combining perspectives on what parts to keep, and parts to change. We’ll make changes for the following phase, and record Lesson Learned to remind us before the next Convergence process (KB9).
There’s a version of this from The Africa Prize, where the Challenger delegates to the A-Team up front, and can’t speak for the whole session except for having 2 “yellow cards” they can play, allowing them to interject for a 90 seconds each time. That prompts them to plan in advance, to make sure their team has the background info they need (with the help of a Delegation Canvas ) It also makes it feel a bit more like a sport, and funner to watch.
This version is on a monthly loop, where the A-Team members pick 2 challenges for the coming month. Though we could change this to have a bunch of challenges come in before the start of a block, and schedule them through the block from there.
Thinking through some guiderails on how to help make the current juntos better, particularly the weaker ones.
This fits in the “last known good” option for juntos for me, just a small iteration to the current way we do things. Though, it could apply to several of the options.
One issue I see is that most juntos are set up where the host is the teacher, or where the host has a horse in the race on a topic. (The behaviour quickly changes when Andy or Vivek drop in, largely because they get the floor and naturally reset the tone.)
I read our junto guide (didn’t even know it existed ) and also the Franklin Circles toolkit, and simmered them down to a Figma template. (Not sure if we want to make Figma a default for this type of thing, but just wanted to prototype)
This a kind of fill-in-the-blanks guide that’s also participatory, the idea being:
it’s more likely for people who don’t read the junto guide to still have something that guides them into the type of convo we’re aiming for
participants see this, so can also help steer the convo towards the Franklinian model.
I can imagine a set of formats for the host to select from, each with a starter kit like this that gets them running quickly, and in the right direction without too much prep.
Some easy wins coming up at the intersection of convo, guilds, and juntos.
Convo + Unconference =
A weekly unconference serves the use case of easy-to-host conversations, with scheduling, even faciliatating, taken care of by us.
So that leaves the more serious event hosts using a separate event scheduler, which makes them more likely to want to choose their own registration/management tools.
Destructured guilds
A lot of the great guild sessions would be better attendended if they were stand-alone events, like firesides or juntos. (GVM, Timshel, Eva Beylin etc.) Promoting them as Gaming Guild #3 prevents fellows from noticing them and partipating, and also counters the guilds’ goals of helping other fellows see the value in their subjects. So ‘destructuring’ or elevating the individual conversation topics and guests above the banner of the guild, is useful.
A simple way to think of this is that we take all the guild sessions, and just put them in Convo as stand-alone events. No more ‘guilds’ but all the same content.
(This is a more general pattern I think of as ‘atomic federation.’ Remove the artbitrary groupings, and reveal the ‘atomic unit’, in this case a single event, and federate them with a single group, allowing the end user to select according to their needs.)
This relaxes the guild leaders, who now can focus on individual, great sessions, and not all the admin and obligation of creating some kind of syllabus and coordinating repeat schedules (as domain experts, neither creating edu content or cat herding are their strengths, so let’s take that off their hands)
It also then lets us separate introductory topics from deeper explorations of practice, which we can do with different structures (arguably also stand-alone events that just get listed in our events listing)
All together now
I’ll have to write this up properly for the convegence process, but just wanted to share a link between juntos, event listings and guilds. Simpler versions of each, combined, can end up plugging togther more meaninfully and being more powerful.
daily namawashi time in the calendar, where we’re available to getting/requesting feedback without needing to set meetings
Stage gates
As a foundation for each module, try to make explicit:
capabilties, tolerances & trade-offs
internal checklists
variations and modules
Our final stage get should be to dry run 2-3 complete options
Artifacts to communicate options (increasing in fidelity as we progress and get feedback):
timelines
content plans
user interfaces
rituals
decks
Fellow needs that we’re all designing towards:
navigate blockchain by the stars
hear from luminaries to be inspired and know what matters
get (weekly) feedback on their project
get (weekly) feedback on their topic exploration
confidence in knowing the terrain / zeitfgeist
feel connected and supported (tribe)
anything else?
Option Examples:
1- last working version (what we did in KB5/7)
2 - improvement X (pick one: need, flexibility/modularity, performance measure)
3 - improvement Y (pick another)
4 - hybrids
We’re off to an energetic, but slightly wobbly start, so here a few guide-rails that will hopefully help:
Starting module assignments
Propose only the parts of the program you are committing to design and run yourself.
This refers to the parts of Kernel already in various people’s hands:
Firesides: Vivek and/or Andy Learn track: Andy Guilds: Andy Celebration: Aliya Adventure Time: Vivek and/or Aliya Application/Reviews: Andy Services: Simon and/or Andy
If you have any changes you’d like to see to Kernel, the idea is that you first propose what changes you’d make to your area of “custody” or proposed custody, then the deference feedback also relates to the modules you’ve taken responsibility for.
This is useful as a filter in a few ways:
It makes sure that proposals are made with enough consideration to how they’ll work (they’re not just outcomes but designs)
The feedback loops are limited to the people who will take responsibility to see those things through to execution.
Suggestions to someone else’s section
Anyone can propose how they’d like someone else to do their module, but then these are either just suggestions that you’re asking the module owner to consider (in which case they’re not a proposal and I’d suggest those happen 1:1 before being posted here, or at least clearly marked as a suggestion in the subject, like “Suggestion for Guilds: shorten them to 3 weeks” ) You can also propose your own idea of an alternative to their module (or more realistically an overlap in some of the functions), provided you’re willing to deliver them.
Forum conventions for Converging
I think some forum conventions might help too. Let’s start with a few things:
When submitting a design for convergence feedback, make the subject line a descriptive label of the proposal. ie “Timeline: 2-month version with 1-week breaks” or “Adventure Time with Office Hours” That way, we can stay on topic to that idea, plus find and link to relevant threads.
It helps us all stay on-topic to the subject thread, and start new topics if necessary. (You can link and cross-quote to connect ideas.)
) and also the Franklin Circles toolkit, and simmered them down to a 
