Some thinking out loud here. (Don’t want to confuse things by saying this is the new direction, just sharing WIP.)
With some help from @aliyajypsy here’s apotentially easier way forward than the single big hackathon, and without all the MVP metholodogy.
While the learning principles still apply, and our questions are useful here, this let’s us “layer up” different parts of the block as separate events, and if we launch those events in sequence, we have time to adapt each or respond with surplus time available in case we need to change something.
As we add the next event, we can track more things to see how the overall shape works.
WIP Wednesday
WIP Wednesday, followed by forum threads for any async help we might connect
Inviting: current fellows
Relationships
~ do they reach out to others to help them?
~ what questions are they asking, are they authentically exploring them in paper parties, research clinics, WIP wednesdays
# of contacts with other fellows (so, who attended what?)
Will Matrix work?
# sign up rate
# join rate
# week-on-week active users
# week-on-week active users in #mempool rooms
Will the unconfs work?
# Attendance rate
# % of participants achieving learning goals
Will fellows from across blocks participate?
# Attendance rate from fellows
Will Guild Leaders shift to new roles?
# Guild Leaders signing up (esp early signups and ideas they want to build)
# Guild Leaders participating to the end
# Guild Leaders running unconf sessions
# Invite acceptance rate
~ asking them about their current goals and how their contributions to kernel fit in
Learn Track Remix
Applications run through #defense going into responsive weekly Learn Track juntos. (with access to Paper Party when that’s running)
Inviting: new applicants and current fellows
Diversity filter
# of highly participating mempoolers & their demographics
# of non-participating mempoolers & their demographics
~ Steward outreach to non-participating mempoolers to attempt to troubleshoot & guide
Will the Learn Track get enough engagement in the Mempool?
~ Observing how random applicants affect junto calls - will they feel empty or crowded? will people ask questions and make space for others?
~ noting which junto sessions had disruptive behaviours
~ asking fellows for feedback on new joiners
# of fellows attending learn track / week
# fellows returning to juntos (vs dropping out)
# joiners asking questions to stewards
Will Buddying Up work?
# of invitations
Paper Party
Research Clinics leading to forum posts and Paper Parties
Inviting: fellows and Learn Track participants
Will people engage on the forum?
# Active fellows / week
# % of participants on forum / week
# difference between active forum and active slack users
Will Clinics work?
~ learning path created? what is the quality?
Big Huggy
Organise a big huggy (curated by stewards, seeded from Kernel News)
Welcome Squad
Once ~50 invites have been sent, run a welcome squad
# of people following up with others afterwards
# of people reading other fellows’ bios
# of invitees attending
Hackathon
Run a small, casual hackathon with some guild leaders (more in-line with the monthly idea in the program)
Will the hackathon work?
# team formations
~ catching up with fellows to see if anything interesting happened during Learn Track for them
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!
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.
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.
This was a question for you and @aliyajypsy . Can you outline a ritual or do a prototype? That’ll give me a sense of what to test and where’s a good place for in the MVP
It was great for a Kernel hang, but I don’t think this went well for the goals of WIP Wednesday. Thinking through the root causes, I think there’s already a case for a return to WIP Wedneday tech-only origins (though maybe keeping a different one that’s more inclusive.)
First my feedback with my fellows hat on:
I care about learning to build blockchain things, hyperstructures, smart contracts, apps with more decentralisation than web3 login. I’m mainly focused on getting to shippable solidity.
What I got out of that hour was learning what slither is, and seeing some kind of API call to GPT-4 with a temperature parameter. That was interesting, but not enough to make the hour worthwhile.
From this experience, I honestly wouldn’t return regularly. I’d pop in occasionally to see if builders are around and doing something interesting, but would look elsewhere for creative, product and buildery sharing (rather than pitchy and businessy, which is mianly what I vibed here.)
Here’s my take with my stewards hat on:
Overall, I thought it was really energetic, more than previous WIPs. It also felt a lot more like Andy/Vivek interviewing someone in firesides which has upsides and downsides. Previous WIP Weds felt much more like open mics for people to ask and chat as the code was being explained. So good to have the guidance, but more hands-off in comparison. We had a good result I look for: people picking up useful tools and tips that wouldn’t normally be mentioned in presentations or prepared content.
The first session was good – solid code to see, a tour of SSDD’s worksapce.
Only 0xSSDD really shared code. Shan jumped around from project to project, and only talked about a static site generater without showing his code. (just his repo’s file directory on github)
The remainder were pitches, just with a live demo. And they weren’t on anything particularly timely, mainly showing stuff that’s already been built and deployed a while ago. (In a few cases, by other people.) The last one was Armie explicitly trying to pitch his product to Vivek.
A few observations on facilitation:
At the start:
We didn’t introduce or show the figjam
We didn’t introduce the timer
We didn’t ask who feels like sharing today (though I asked when the floor was handed to me)
@cryptowanderer could you maybe next time introduce your co-host at the start? I would have jumped in with these things.
The pitch sessions:
I didn’t manage to get anyone to actually share code
I fumbled the handover. I tried to pass to Dhruv, since he was the only one I knew that had WIP to share.
@vivek, you then invited people to present. (and this is right after we talked twice about not using that term!) I guess you thought you were being helpful, but everyone just looked to you as the facilitator from that point on. You’re a steward they recognize, I’m not. I got the impression you were naming the people you’d personally invited to present because it almost instantly became the same format as showcase. Char didn’t even share her stats dashboard when I asked. People didn’t respond to me whenever you pulled in a different direction.
In spite of the sessions being pitchy, I actually had a lot of good questions to ask them, that I think would have helped with their MVPs and fund-raising goals, but I couldn’t get in without interrupting or contradicting Vivek. That would have been too weird. So ironically, even those non-builder goals I felt went unserved. It really bothers me to miss these opportunities to help them - and I feel (ir)responsible.
At the end:
What worries me most about this is I’ve never seen a room empty out so quickly and completely at the hour in a WIP Wednesday or Debug Day. My impression is it got so pitchy that everyone was waiting patiently for the end to leave. We’ll see next week how many builders return.
I wanted to ask people for feedback, especially if the video feeds were good enough for them, but didn’t. Vivek was in mid-conversation with Armie about tracking users on the Kernel website, and I just managed to let people off at the hour, while Vivek wanted to continue with Armie, and also even invited KD to present. By this point, Vivek, you were completely overriding me as the host. If you were a fellow, that would have been out of line, and I would have more forcibly pushed back.
My suggestions:
We make it clear the focus is on WIP this week. This way we insist on the in progress part of WIP. That should keep it more real. (I’ve also modified the figjam intro text, which I think should be displayed in a screenshare at the start of each session so it sinks in.)
We move WIP Wednesday back to tech only, or separate a broader version of it somehow. I still think that coders will want feedback from coders, product managers from product managers, researchers for researchers, etc. which is why I suggest this as the way to do breakout rooms. If not, we risk losing the coders.
We decide which steward actually runs WIP Wednesday and makes the decisions. I don’t feel I have agency over it, and Vivek, seems you have different designs for it (Andy, maybe you too?). By now I know it doesn’t work out for me to put energy into resisting either, so I’ll bow out. I’d be happy to take responsibility for a builders-only version, and share/delegate hosting with Andy and maybe a few other fellows who build.
Sadly, it crossed my mind during this that I wanted to just reach out to the actual builders privately, and host a Super Shadowy Coders separately. This isn’t a good sign, since the idea of putting WIP Wednesday into the Kernel program was to make it builder-friendly. And I recognize the contradiction there, since I advocated for making WIP more inclusive! Doh. I just think this has already swung far too general, and not actually about the week-to-week of creating new things.
So that’s why I think we should take it back to its roots. We can serve researchers, writers and “info products” with Paper Party. And the fundraising/product stuff is a better fit for the Fellows Track imo.
Some thinking out loud here. (Don’t want to confuse things by saying this is the new direction, just sharing WIP.)
With some help from @aliyajypsy here’s apotentially easier way forward than the single big hackathon, and without all the MVP metholodogy.
While the learning principles still apply, and our questions are useful here, this let’s us “layer up” different parts of the block as separate events, and if we launch those events in sequence, we have time to adapt each or respond with surplus time available in case we need to change something.
As we add the next event, we can track more things to see how the overall shape works.
WIP Wednesday
WIP Wednesday, followed by forum threads for any async help we might connect
Inviting: current fellows
Relationships
~ do they reach out to others to help them?
~ what questions are they asking, are they authentically exploring them in paper parties, research clinics, WIP wednesdays
# of contacts with other fellows (so, who attended what?)
Will Matrix work?
# sign up rate
# join rate
# week-on-week active users
# week-on-week active users in #mempool rooms
Will the unconfs work?
# Attendance rate
# % of participants achieving learning goals
Will fellows from across blocks participate?
# Attendance rate from fellows
Will Guild Leaders shift to new roles?
# Guild Leaders signing up (esp early signups and ideas they want to build)
# Guild Leaders participating to the end
# Guild Leaders running unconf sessions
# Invite acceptance rate
~ asking them about their current goals and how their contributions to kernel fit in
Learn Track Remix
Applications run through #defense going into responsive weekly Learn Track juntos. (with access to Paper Party when that’s running)
Inviting: new applicants and current fellows
Diversity filter
# of highly participating mempoolers & their demographics
# of non-participating mempoolers & their demographics
~ Steward outreach to non-participating mempoolers to attempt to troubleshoot & guide
Will the Learn Track get enough engagement in the Mempool?
~ Observing how random applicants affect junto calls - will they feel empty or crowded? will people ask questions and make space for others?
~ noting which junto sessions had disruptive behaviours
~ asking fellows for feedback on new joiners
# of fellows attending learn track / week
# fellows returning to juntos (vs dropping out)
# joiners asking questions to stewards
Will Buddying Up work?
# of invitations
Paper Party
Research Clinics leading to forum posts and Paper Parties
Inviting: fellows and Learn Track participants
Will people engage on the forum?
# Active fellows / week
# % of participants on forum / week
# difference between active forum and active slack users
Will Clinics work?
~ learning path created? what is the quality?
Big Huggy
Organise a big huggy (curated by stewards, seeded from Kernel News)
Welcome Squad
Once ~50 invites have been sent, run a welcome squad
# of people following up with others afterwards
# of people reading other fellows’ bios
# of invitees attending
Hackathon
Run a small, casual hackathon with some guild leaders (more in-line with the monthly idea in the program)
Will the hackathon work?
# team formations
~ catching up with fellows to see if anything interesting happened during Learn Track for them
@cryptowanderer Not true. The $200 cost I referenced was for single server management from Green Olive Tree. When I first suggested we might host things ourselves, you said you didn’t want us to manage servers, so all this stems from that constraint.
The $1000 cost includes Matrix and other things we’d want to host (forum, chat, video, whatever else we might need). It’s the same cost as I’ve always said for a Matrix as a Slack alternative. Once we pay for server management for one thing, it makes sense to put others on the same system. The case here is for a fixed cost for hosting services, and it costs little more to stick something else on the same server as long as it can handle the load.
For $1000 / m I’m thinking ahead for a powerful enough server to host multiple things on Docker that can handle peak loads we’d throw at it, a hot fail-over, and outsourcing server management, backups, etc. These all serve a purpose, and we can cut these costs if you want, but they hurt the fixed cost case (vs the growing $3k+ / month for Slack, Gather, etc) because without them, we don’t have the same reliability as SaaS.
Of course, we can just go to Digital Ocean or Google Cloud and do a one-click install of Discourse for $30-40 / month. But then we have to maintain that server instance just for Discourse, and we’re exposed to downtime, data loss and server ops distraction. (And speaking from experience, servers always command attention when we have other things to focus on. )
How will we know when they make the decision, do we pre-emptively announce, ‘hey in case you’re thinking the mempool isn’t for you,
For the MVP, yes I think we plan on reaching out to everyone when we notice they didn’t return. Ideally, we’d have them all in DMs somehow (on their platform of choice, not on our servers)
My question: what will the technical capacity of the forum be?
It’ll be like this one or Discourse. Standard stuff. Using it to seed discussions will be on us, and our hypothesis is it’ll stem from threads we start in the Research Library / Clinic. We also expect the juntos and in-person events to be meaningful contact surfaces for people to meet each other.
This was a question for you and @aliyajypsy . Can you outline a ritual or do a prototype? That’ll give me a sense of what to test and where’s a good place for in the MVP
Are these ‘teams’ groups that are explicitly making something together, or are they intended to be support structures to one another as they answer questions? A bit of both?
Making something together. The emphasis is on shipping something of value to others, doesn’t need to be software.
Regarding teams & team formation, where do we see that happening?
The standard way for hackathons is a find-a-team chat channel and some kind of listing, like in Airtable. EthGlobal also does a live event for team leads to shill. Those are all mediocre.
Meowy shared that Web3con did way better than other hackathons, with 2 f/t facilitators manually connecting people to each other (between 400 hackers!) They have a channel for each sponsor (so you can pop in and ask for help with their tech or get feedback on your idea) and a channel for each team (so people can pop into team channels to offer help) The facilitators basically respond to people looking for teams, connect them to others, and offer to create a team channel as a semi-official way to launch the team. It’s good, old-fashioned match-making.
This makes sense for our hackathon, though doesn’t directly inform the Buddying Up hypothesis for the Kernel program.
While a buddy brings you into Kernel, need they be on your team?
No. The Buddying Up hypothesis will be tested separately from the team formation. Fellows may invite non-fellows to the next block. We’ll give them each one invite, and not mention Buddying Up. Then we’ll see how many naturally invite others, and can follow up to ask why or why not.
This is quite different from doing the buddying up in team formation (which isn’t how the program is designed either)
) and also the Franklin Circles toolkit, and simmered them down to a 
Can you outline a ritual or do a prototype? That’ll give me a sense of what to test and where’s a good place for in the MVP
)