Management Team

Decision Log — May 2016

This is the Management Team’s Decision Log for the month of May 2016. 
75 Decisions were logged.

Wednesday, 11 May 2016

DECISION 1

Location: Specs: Playbook
Participants:
Francis, [Redacted]
Problem
We realized there needs to be one or more outputs columns.
— How should they work?
— What are the implications?
— Would it allow the bot to run instances?
Analysis
— Con argument: There is a cost to changing the master playbook template in propagation and training.
— Pro argument: This is easier to understand (improves CL UX) and makes the system machine functional. 
— Decision rationale: Ultimately, critical for MVP, and makes the system more elegant.
Decision
Create DATA TYPE, OUT-EX, OUT1-N columns.
Replace “templates” rows.
Allows for “instances” every time the playbook is run.
Requires “output example” (OUT-EX) column for reference use in line to guide responses.


DECISION 2

Location: Specs: Playbook
Participants:
Francis, [Redacted]
Problem
Should we add an inputs column to the master playbook template?
— What are the implications?
— Would it allow the bot to backtrace all requirements for any line or set of lines?
Analysis 
— Con argument: Adding two more columns is bad for CL playbook writing UX, and increases complexity of system.
— Pro argument: Without this, reactive tickets can’t be efficiently handled, CT UX and overall business model suffers, system is non-performant for MVP. 
— Decision Rationale: Ultimately, this is a necessary part of the machine, and the whole system doesn’t work without it.
Decision
Create Inputs + IN-EX columns
Yes, but it necessitates two columns, an input column and an input example column.
Input column: display format would be CY-MC-L, and it would link to the ouput cell in another sheet.
Input Example (IN-EX) column: format would pull from output example cell in another sheet.
Use1: The line cell could call the input example cell.
Use2: Allows CL to start at any line, b/c of BOT backtrace.


DECISION 3

Location: Specs: Playbook
Participants:
Francis, [Redacted]
Problem
What should we put in the OT-EX column, and do we need a second column?
— Do CLs need an example of data types?
— Do CTs (and other end users) need a generic or specific example of data types?
Analysis
— Con argument:
We’re biased against more columns.
Increases complexity of system.
— Pro argument:
Improve end user UX.
Reduce chance of creator error.
— Decision rationale:
Ultimately, end user needed specific examples, and we did everything we could to eliminate chance of a broken UX due to creator error.
Decision
Create DATA-EX and OUT-EX columns.

We could make CLs learn examples by heart, but they may be prone to error.
If they don’t get it perfectly right, it won’t be machine readable, and the sheet will break. We want to avoid “input invalid” even when end user complies with output example.

Generic examples are bad UX and confusing for CTs and other end users. Example of it being confusing is arrays… The specific array may be positions, or vacations, or… So we do need specific examples. Hence two columns.

Still doesn’t completely eliminate the possibility of CL error, but makes CL more culpable, and more unlikely to fail.

DATA-EX, wide width, b/c not represented in Line
OUT-EX, narrow width, b/c represented in Line.


DECISION 4

Location: Specs: Playbook
Participants:
Francis, [Redacted]
Problem
Column types were hard to understand.
Relationships between them were vague.
Magic wand waving, where one column was doing too much work.
Relationship between four different types of sheets (MPB1 + DS1,2,3, MPB2 + DS1,2,3) was confusing.
Analysis
Other decision makers might not have discovered the problems until later.
And even after encountering, might not have been able to diagnose the source, or solve.
We were able to solve because we:
— Shared context, and live interaction… [Redacted] interrupted Francis.
— Were patient with it and with each other, we got a room… we pushed each other.
— Broke it down into all its parts, and defined each part, and the relationship between each part.
— We used a diagram.
— We both had an unspoken objective of an elegant solution.
Decision
Merge DATA TYPE and DATA-EX columns into DATA TYPE.
Rename IN-L, IN-# and IN-EX columns.
Mirror IN and OUT columns.
Rearranged column order to be more logical.
Created color codes based on spreadsheet formula, engineer formula, or CL input.


DECISION 5

Location: Specs: Playbook
Participants:
Francis
Problem
Should we get rid of examples?
Should we backup the V0.8 template and example?
Should we backup the V0.5 example?
Should we update the V.0.5 template?
Analysis
Standards help keep everyone on the same page.
They are worth investing in.
We can’t be precious about putting old things in the backup.
Otherwise we’ll be hoarders… too attached to old things to create new ones.
Examples are too hard to maintain, and quickly fall out of date.
It is easier to update a template than to update an example.
For examples, people can just go to Upgrades.
Decision
Yes, backup the old files.
Yes, get rid of examples.
Yes, keep the templates up to date.


DECISION 6

Location: The Folder
Participants:
Francis, Keenahn, [Redacted]
Problem
Should we use a #CY-CT or #CT-CY naming convention?
Analysis
Underlying question is: should we put clients first in our mental model, or capabilities first? Putting clients first may sound nice, but in past experience that leads to unsystematic execution. Systematic execution is what will build a valuable company, so #CY-CT and #CY-CT-MC-ID.
Decision
Scheme #CY-CT and #CY-CT-MC-ID added to relevant Specs.


DECISION 7

Location: The Folder
Participants:
Francis
Problem
Type: Structure.
Should “Workspaces” be outside of Pending, in The Folder root?
 — Yes?
 — No?
Analysis
“NO” argument:
 — Pending forces people to map innovation to The Folder.
 — This prevents recurrence of a past problem: pet projects.
 — Still allows for creativity, but within a shared structure.
“YES” argument:
 — Easier access.
 — Makes people feel more independent.
Decision
No. Ultimately, this doesn’t deserve top-level priority.


Thursday, 12 May 2016


DECISION 8

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
Should we get rid of script numbers?
Analysis
Con:
Scripts allow us to do loops. But there is a better way.
Pro:
Original reasons it evolved no longer valid.
It was logical to see the alternations between from-to types.
Seemed simpler to just get rid of it.
Decision
Got rid of script numbers.


DECISION 9

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
To N/A or not to N/A?
Analysis
Easy work for writer. Sense of progress. Makes obvious when playbook is done.
Decision
N/A installed as a data type.


DECISION 10

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
How does the template handle expiration?
Analysis
Easily handled by counting down days from timestamp.
Decision
Create an EXP column with number of days.
3650 days (10 years) as our Y2K.


DECISION 11

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
Should we rename CL-CT to BOT-CT?
Analysis
Con: CL needs to monitor.
Pro: Original reasons it evolved no longer valid. Simpler. And implies more automation.
Decision
Yes. Renamed CL-CT to BOT-CT.


DECISION 12

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
How should the bot treat a line that contains conditional logic?
Analysis
If the output equals Y, then go to X line, else go to Y line.
Accomplished through columns:
IF OUT=
THEN
ELSE
Decision
Approved. Installed columns.


DECISION 13

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
Should we handle any other types of conditionals in the MVP?
Analysis
Con: No, because we don’t know what problems CLs need to solve yet.
Pro: Yes, because it would increase expressiveness. Meanwhile, can use phantom lines.
Decision
Only add new forms of expression when driven by business requirements. Tell CLs we will wait for them to make feature requests. If we can’t solve their requests with existing mechanics, it justifies a new mechanic.


DECISION 14

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
How do we support better counter functionality?
 — Can we add Count Down, Count Multiply, Count (Formula, Variable Intervals) to Data Types?
 — How do we prescribe the line content for counters, given it needs to be rigid (aka data validation for only one type of line)?
 — Do we need to solve this now or later (is it MVP-required or optional)?
Analysis
We can support better counter functionality.
We can add additional types of counters later.
We don’t know how to do data validation on only one type of line. But we feel like this is solveable.
Worst case scenario, playbook writers just need to rigidly follow lines laid out in a spec.
This is not MVP required b/c the only type of counter we need is a simple loop counter with X+1 and we can prescribe the line by direct supervision.
Decision
Added to backlog for playbooks.


DECISION 15

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
Can we add checkboxes and multiple choice data types?
Analysis
Yes, not MVP. Can express via other data types.
Decision
Added to backlog for Specs: Playbooks.


Friday, 13 May 2016

DECISION 16

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
Can we use Google Sheets as our Editor UI for Playbooks, at least as an MVP?
Analysis
Speed and cost advantage to not needing to build an Editor.
Technical analysis was uncertain at first.
But upon further review, edits, and problem solving sessions…
Able to upgrade V1.0 standard to machine readable columns.
Still working on standard and on writing guidelines.
Decision
Yes. Implementation in progress.


DECISION 17

Location: The Folder
Participants:
Francis
Problem
Should we call it “The Brain” vs. “Brain”?
Analysis
“The Folder”, “The Factory” and “The Brain” get special attention.
That’s because they are the “machine”. The rest is content.
Arguably “Company” could join this category, but we abstracted all the thinking docs into The Brain.
Decision
“The Brain”. For now.


DECISION 18

Location: #CLT-INV
Participants:
Francis, Kamron
Problem
Where should corporate records go?
Analysis
We thought about creating an “Admin” folder in company, but wanted to disambiguate.
“Records” made sense.
Putting all signed legal documents and templates there.
Decision
Created “Records” folder in Company.


DECISION 19

Location: Specs: Playbook
Participants:
Francis, Kamron
Problem
Can we not use Google Sheets as a Database?
Analysis
Yes. We can use a real database.
This increases elegance in The Folder.
Decision
Implemented.
Removed Client Data shell files.
Francis added to Specs: Playbook backlog.


DECISION 20

Location: The Folder
Participants:
Francis, Kamron
Problem
Should sales documents and funnel go in the Clients folder?
Analysis
There is a line between the operational and non-operational folders.
Company is non-operational. Clients is operational. Part of the machine.
That line should not be crossed.
No. They should go in the Company folder.
Decision
Added shells to Company folder.


DECISION 21

Location: The Folder
Participants:
Francis
Problem
Can we get rid of the Clients folder — and move the two files to Company?
Analysis
Yes.
We have already decided that the Clients folder will not contain sales materials, and thus will be strictly operational.
Operationally, there is a database viewer, which may remain temporarily, but ultimately will be a technology.
No work has been done on the database viewer, and arguably we shouldn’t encourage its existence.
And that leaves the RM Playbook. By definition, our model succeeds as it shrinks.
The distinction between “Capabilities” and “Clients” should diminish, as Capabilities are the service.
The best proof of this is looking at diagram of our database (#CY1, #CY1-CT1-MCN-IDN, #CY1-CT2-MCN-IDN).
Decision
Removed Clients Folder.
Deleted Database Viewer.
Renamed “Clients” Playbook to “RM” Playbook.
Moved RM Playbook to Capabilities.


DECISION 22

Location: The Folder
Participants:
Francis
Problem
Can we get rid of the CY shells in The Folder, now that we have Standards in place?
Analysis
Yes. The shells were originally there to make sure people could visualize the structure, and to reinforce an old standards concept.
Decision
Removed shells.


Monday, 16 May 2016

DECISION 23

Location: The Folder
Participants:
Francis
Problem
Should we fire [Redacted]?
Analysis
Hard decision because it is not based on a specific instance of wrongdoing, But rather a large set of observations gathered over time, As well as a gut instinct that this is not right, and best for both sides.
Consistent negative feedback:
 — [Redacted] in March raises patterns, recommend fire, wait-and-see
 — Francis in April raises patterns, recommend fire, [Redacted] and [Redacted] convince to wait-and-see
 — [Redacted] in May raises patterns, feedback given, continue to wait-and-see
 — [Redacted] in May raises patterns, Francis makes decision.
Intimations of:
 — Laziness. Doesn’t seem to accomplish much.
 — Selfishness. Doesn’t seem to care about the mission.
 — Blame. Mean with others. But deflects responsibility.
Lines crossed:
 — Hijacking meetings
 — Co-opting “supporters”
 — Spreading gossip
 — Stirring discontent
 — Sarcasm, destructive criticism, refusal to be managed
Negative patterns:
 — incites discontent.
 — incites gossip.
 — incites toxicity.
Instances of patterns on:
 — Private Calls
 — Private Messages
 — Team Meetings
 — Group Threads
Options:
 — Let it slide (sets bad precedent, toxic)
 — Stern warning, coaching (issues go too deep, not very receptive)
 — Terminate immediately (face it head on)
 — Terminate later (avoid unpopular decision, risk team sees as reactionary)
Rationale:
 — Ultimately, decide to terminate now.
 — FMA not aligned with INV.
 — Full disclosure with team.
Management mistakes made:
 — To not be uncompromisingly forthright
 — To not address earlier in the process
 — To let practical considerations delay principled ones
 — To not trust intuition, instinct
 — To not consider the ripple effects of attitude on a team
Principles in play:
 — Don’t wait. Don’t hold back.
 — Be as transparent as possible.
 — It is unfair to NOT fire someone.
Decision
Terminate [Redacted].
Offboarding effective immediately.
Kamron to assume CYL responsibilities for Admin.
Will share reasons candidly with the team.
Will integrate learnings into principles, hiring, management.


Tuesday, 17 May 2016

DECISION 24

Location: Principles, Agenda
Participants:
Francis
Problem
How do we expect greatness from ourselves as a team?
 — Ongoing sense of languor, confusion, inertia
 — Ongoing sense of fear, anxiety, depression
 — Ongoing sense of “job”, not enough volunteers to do the hard missions.
 — Feeling that I can’t delegate the unstructured problem-solving
Analysis
Options are to not raise it, or to raise it but not to make a big deal of it, or to make a big deal of it.
Downside with making a big deal of it is that it can increase fear.
Upside of making a big deal of it is that it resents the cultural attitudes at the company.
Decision
Wrote down culture and leadership principles.
Discussed with team. Bar raised.


DECISION 25

Location: Specs: Capability Codes
Participants:
Francis
Problem
Reshuffle CYLs given recent departures?
Analysis
So far, 2 seems like a magic number.
CYLs with only one CBY seem isolated and protected.
CYLs with more than two CBYs seem to not make progress on the third.
Spreading out assignments keep everyone aware of the system.
Corey has too many CBYs.
Corey is good at writing first drafts of PBKs.
Corey needs to take over tasks given [Redacted] departure.
Corey is best at CON.
[Redacted] doesn’t have any PBKs.
Decision
[Redacted] to take over EXP and ACS.
Kamron to take over ADM and VEN.
Changes made to codes.


DECISION 26

Folder: Specs: Capabilities
Participants:
Kamron, Francis
Problem
Where should policies live and how should they be structured?
Analysis
Seems sensible to start with a spec document and reassess after it starts to take shape. Arguments could be made for The Brain or Company.
Hunch that it will end up in the Brain though as we think of more use cases.
Decision
Moved to Specs: Capabilities.
Write a first draft of Specs: Policies, then re-assess.


DECISION 27

Location: Technologies > Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
On what level should we store datafields?
Analysis
Client.datafield and .datafield (CT level and ID level) are the only logically necessary.
Because the question turned out to be logically equivalent to:
Are there some kinds of data that are reused in more than once instance,
And some kinds of that are not?
If the answer is yes, then those datafields should be stored at the CT level.
The others at the ID level.
This does not preclude the need for an expiration column.
But for UX reasons, and to avoid the possibility of a collision,
We decided that it would be helpful to have fully broken down datafields.
So we’re going with this format:
CT level datafields will be: CT.datafield.
ID level datafields will be: CY.MC.datafield.
Decision
Added to Specs: Playbook.


DECISION 28

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
We don’t know what kinds of logic our standard does NOT support.
Analysis
Ex. We can’t express this: “Reduce number of openpositions by 1.”
As we discover expression limits, we should systematically resolve them.
Decision
Add to Specs: Playbooks.
Assigned to [Redacted].
Added to Specs: Playbooks.
Create a list.


DECISION 29

Location: Specs: Automata
Participants:
Francis, Keenahn, [Redacted]
Problem
How does the BOT know where to start, if lines have prerequisites?
Analysis
The BOT:
 — looks at all datafields in the range,
 — and maps their origins, and expirations,
 — and if necessary, starts with the prerequisites before starting the range.
Master script can help with the UX.
Decision
Moved to Specs: Automata.
Francis to write master script in Specs: Automata.


DECISION 30

Location: Specs: Automata.
Participants:
Francis, Keenahn, [Redacted]
Problem
How can we report value props to client, in real time and in summary?
Analysis
Revise /.done specs to prevent freeform text, just provide timestamp and move on to the next step.
When /.done executed on a line-type “Report”, PRINT immediately. PRINT again after /.complete.
Revise /.complete specs to complete MC instance and print /.reports to CT.
Decision
Added to Specs: Automata.
Francis to update from there.


DECISION 31

Location: The Folder
Participants:
Francis
Problem
Can we deprecate Upgrades?
Analysis
Yes. The original reason for it was that there was multiple documents per CY, and we needed to separate the chaos from the order.

Because we have consolidated the old auxiliary documents, and we have standards in place, and there are multiple real playbooks in The Folder written to standard, the original reason is no longer valid.

Everything that is approved has (APPROVED) next to it. Everything that is being upgraded has (NAME) next to it. Everything that is ready for review has (REVIEW) next to it.
Decision
Removed shells.
Added to Specs: Capabilities.
Created [0] Workspace standard to allow for temporary working folders.


DECISION 32

Location: Specs: Capability Codes, Specs: Capabilities
Participants:
Francis
Problem
Time to start the “badges” process?
Analysis
Disadvantage is that it is a training cost.
Advantage is that it forces CYLs to see holes in PBKs.
Advantage is that it reinforces “nobody is irreplaceable” principle.
Decision
Asked [Redacted] to build into Specs: Capability Codes, as a first step.
Added to Specs: Capabilities backlog.


DECISION 33

Location: File: Problems
Participants:
Francis, [Redacted], [Redacted]
Problem
Can [Redacted] and [Redacted] help Francis populate “Problems” with CYs?
Analysis 
In the review process, we’ll discover CY specific issues related to the content itself. Anything structural needs to be surfaced and moved to a Spec or Standards conversation.
Decision
Shared with [Redacted] and [Redacted].


DECISION 34

Location: File: Reports
Participants:
Francis
Problem
How can we install a better reporting system?
Analysis
Output file “Reports” in #LDR-INV
Inspect what I expect.
Discuss with team.
Decision
Added to Specs: Capabilities.
Need to build spec in TNF and playbook in CBF.


DECISION 35

Location: Specs: Playbook.
Participants:
Francis, [Redacted], [Redacted]
Problem
Should we create a data-validated line type column?
Analysis
Con: Adds complexity with extra column. Pro: More explicit to declare upfront. Helps with playbook writing. Useful data.
Decision
Added to Specs: Playbook.
[Redacted] to research other playbooks, propose a line types scheme to Francis and Keenahn.
Yes. We should create a data-validate line type column: “LINE-TYPE”.


DECISION 36

Location: Specs: Automata
Participants:
Francis, Keenahn, [Redacted]
Problem
How do we handle loops?
Analysis
LOOP START, LOOP END, TIMES columns solve the mechanics.
But the line itself interferes. Should it come at the start or finish?
Decision
Keenahn to think.
Report back to [Redacted] and Francis.


DECISION 36

Location: Specs: Automata
Participants:
Francis, Keenahn, [Redacted]
Problem
How do we handle response errors?
Analysis
There should be a standard response error for each data type. Those should be in the playbook spec. And then if the CL feels it is appropriate, they can use osmosis to intervene.

Edge case 1: if the CT responds with a valid response before /.resume, /.resume reprints the question, and they have to reply again.

Edge case 2: if the CT responds with a datavalid but content invalid response, the CL needs another power tool, in addition to osmosis, to rewind the script, erase the previous response, and start again. /.rewind will pause a script if it is running, print the last five questions, and “which line do you want to go back to” and they can just use the line number. They have to answer quesitons again even if they are valid.
Decision
Added to Specs: Automata backlog.


DECISION 37

Location: Specs: Automata
Participants:
Francis, Keenahn, [Redacted]
Problem
Where does playbook writer look up datafields?
Analysis
A spreadsheet would be harder to maintain than a feature in the bot.
Decision
Add bot commands to Specs: Automata as a conversation.
Added to Specs: Automata backlog.


DECISION 38

Location: Specs: Playbook Codes, Specs: Playbooks
Participants:
Francis, Keenahn, [Redacted]
Problem
Can we get rid of FROM-TO because of line types?
Analysis
Cons: It’s so clean! So logical! Easy dropdown!
Pros: Line-type is as expressive, and more.
Within BOT-CT we have subtypes.
[Redacted] to research existing playbooks. Propose a list of line-types.
Decision
[Redacted] solved.
Moved to Specs: Playbooks backlog.


DECISION 39

Location: Specs: Playbooks
Participants:
Francis, Keenahn, [Redacted]
Problem
Disambiguate rows and columns.
Lines are rows, and then there are two columns LIN-TYP and LIN.
Can we find a better word?
Analysis
Keenahn in favor of “Steps” and STP-TYP, and leaving the body as LIN.
In favor of keeping it as “Line” is the theatrical metaphor.
Decision
Keep LIN/”Line and then change LIN-TYP to STP-TYP.
Change rows to “Steps” (S1, S2…)


DECISION 40

Location: Specs: Playbooks
Participants:
Francis, Keenahn, [Redacted]
Problem
How should we name data fields?
Analysis
Keenahn written guidance in Specs: Playbooks.
CLs write data field names for their PBKs.
Decision
Added to Specs: Playbooks.
Added to File: Agenda.


DECISION 41

Location: Specs: Playbooks
Participants:
Francis, Keenahn, [Redacted]
Problem
How should we maintain data field names?
Analysis
CLs select from a data validated list in the template.
There is an option for “new data field”.
After the PBK content passes self review, peer review, and leader review,
The last step is automated technical review.
Then data fields get added to the database.
Decision
Added to Specs: Playbooks.


DECISION 42

Participants: Francis, Keenahn, [Redacted]
Problem
Should we keep using 3 letter codes?
Analysis
Downsides are collisions and expressiveness.
Only using 1% of 2⁶³ possibilities.
Decisions
Apply to columns.
Create an index of all codes.
[Redacted] and Francis to create a lookup tool.
Added to Specs: Playbooks.


DECISION 43

Participants: Francis, Keenahn, [Redacted]
Problem
What should our approval process be for CLs to upgrade PBKs?
Analysis
Send to [Redacted]. Upgrade no more than once per week.
Technical review will be an automated test to check data fields.
Merge master (Keenahn) to manage the switch process.
Nothing but approved files in the directory.
Read only access to approved PBKs.
Decisions
Added to Specs: Playbooks.


DECISION 44

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
How does Handoff logic know to return from CL1 to CL2?
Analysis
When we reach a line of line-type report,
And when we complete that line with /.done
We check to see if we are currently in a handoff,
And if so, we go back to the capability that handed off,
Otherwise go to next.
Decision
Moved to Specs: Handoff.


DECISION 45

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
How does CY1 pass datafield-id to CY2?
Analysis
Solveable but needs to be explicit.
Decision
Moved to Specs: Handoff.


DECISION 46

Location: Specs: Playbook
Participants:
Francis, Keenahn, [Redacted]
Problem
Can we eliminate IN-LINE, IN-TYPE, IN-EX, IN-#?
Analysis
Same functionality can be accomplished by code.
Read in OUT-NAME and store as datafields name (ex. client.passportName). Con: No cons. Pro: Eliminate columns, increase simplicity and increase power (elegance), increase specificity.
Decision
Approve Keenahn’s proposal. Added to Specs: Playbook.


DECISION 47

Problem
When doing a handoff, should it spawn a separate instance of CL2, or bring CL2 steps into CL1?
Analysis 
Spawning a separate instance is cleaner UX for CL2 and also better system-design. New instance means new channel. CL1 channel will have a status message “currently in a handoff”. Every /.done posts a status back to CL1 channel “you are at this many steps”.
Decision
Moved to Specs: Handoff.


DECISION 48

Problem
For loops, how to determine which step to jump back to, and how many times?
Analysis
Deleting LOOP-END column, and expressing that logic in TIMES. PBK writers need to specify which step to jump back to. On the last step of the loop, specify which step to jump back to, and how many times overall you want to loop. Times can be a variable or a constant.
Decision
Eliminate LOOP-END column.
Added to Specs: Playbooks.


DECISION 49

Problem
How do we specify conditional logic in playbooks?
Analysis
What types of conditionals are we going to have? If we only have bot conditionals that covers everything, logically, but suboptimal UX for PBK writer. And for MVP, we’re okay suboptial UX for the PBK writer, as long as reasonably intelligent people can do it. If we have a conditional, what are the things we are testing?
Decision
Added to Specs: Playbooks.


Wednesday, 18 May 2016

DECISION 50

Problem
How can we improve code files?
Analysis
Confusing file names.
Not intuitive to read.
Decision
Changed file name convention to Specs: Codes, COD format.
Put CST columns first, MBY columns last on CBF.
Asked [Redacted] to create an Index in Specs: Codes, FLD.


DECISION 51

Problem
How can we improve the CBY lineup?
Analysis
Missing key CBYs.
We know this b/c we can’t operate #INV just with current CBYs.
Decision
Added 4 CBYs to LDR.
Added 1 CBYs to PRD.
Added 2 CBYs to PJT.
Moved ADM and CON from PJT to PRD.
Changed assignments due to biz changes.
Changes made to Specs: Codes, CBF.


Thursday, 19 May 2016

DECISION 52

Problem
How can we rename Slack channels to mirror The Folder?
Analysis
Kamron proposal for CBY channels: 
CBY example Ex. #3–5-HIR-INV
MCY instance Ex. #3–5-HIR-INV-POS-1
MCY max instances Ex. #3–5-INV-HIR-POS-99999
Keenahn approves.
Francis approves.
Decision
RENAME
#general > #0–0-the-folder
#random > #zeno
#feedback-clients > #3–0-clients
#capabilities-unite > #2–0-capabilities
#tech-engineering > #1–3-ENG
#cs0-reading > #2–1–3-CRE-INV
#cs0-playbook-design > #1–2-AUT-PBK
#sync-leadership-team (LOCKED) > #3–1–1-INV-MGT (LOCKED)
ARCHIVE
#radio-invisible > archive
#cs0-coworking > archived
#feedback channels > archived (moving to different system)
#radio-complete > archive in future but not yet
#tech-random > archive (belongs in #zeno or #technologies)
#tech-standups > belongs in #technologies … or private (doesn’t exist in folder structure)
#tech-taut-logs > archive or private w/ eng team (doesn’t exist in folder structure)
#guides > archived
#learnings > archive
#clients-oldclients > archived, cmon!
#clients-x-strat > archived, omg!
#inbox-madness-tbd > archived, OMFG! AYKM?
#km-security-confiden > ya. Kill that shit.
#internal-work-retreat > so dead.
#cs0-communication > what the heck is this? Archive
#cs0-offboard/onboard > archive, part of adm-inv
CREATE
#0–0-the-folder
#1–0-technologies
#1–1-CDT
#1–1-CDT-MTA
#1–1-ICT
#1–1-ICT-OSM
#1–2-AUT
#1–2-AUT-CHS
#1–2-AUT-HND
#1–2-AUT-BUF
#1–2-AUT-PBK
#1–3-ENG
#1–3-ENG-BUG
#1–3-ENG-LOG
#2–0-capabilities
#2–1–1-MGT
#2–1–2-DSN
#2–1–3-CRE
#2–2–1-INB
#2–2–1-INB-MVH-LBL-19
#2–2–2-CAL
#2–2–1-CAL-MVH-BSC-26
#2–2–6-LIF-MVH
#2–3–5-HIR-INV
#2–3–5-HIR-INV-POS-1
#2–3–5-HIR-INV-POS-999
#3–0-clients
#3-CLT-INV
#3-CLT-MVH


Friday, 20 May 2016

DECISION 53

Problem
In Kamron’s Vendor playbook there is a lot of CL to CL talk…
How can the bot facilitate internal human interactions…
What new line types does this require?
Analysis
We had this in FROM-TO but somehow we thought Handoffs covered all CL1-CL2 use cases, 
It does not.
Decision
Discuss w/ Keenahn and [Redacted]
Resolved! Elegant solution via Forward emoji.


Thursday, 26 May 2016

DECISION 54

Problem
Version 0.9 not achieved on time.
Analysis
CYLs confused.
 — Structural: move from text to sheet format.
 — Behavioral: didn’t proactively get answers. Just communicated vague “unhappiness”.
 — Cognitive: didn’t understand explanations and instructions provided.
Management:
 — [Redacted] assumed [Redacted]’s responsibility; [Redacted] assumed [Redacted]’s responsibility.
 — Neither [Redacted] nor [Redacted] made actions to uncover, communicate, or align above assumptions — responsibility is circular and symmetrical
 — — Missed opportunity to uncover: [Redacted] should have pulled [Redacted] when he realized he did not know the detail to support CYLs
 — — Missed opportunity to uncover: [Redacted] should have called [Redacted] out on not reporting more specific progress esp after doing deep dive herself
Address behavioral: [Redacted] & [Redacted] sync on how to manage CYLS: check work, escalate questions, set deadlines.
Address cognitive: [Redacted] & [Redacted] sync on how to upgrade to V0.9: write guide, have 1 on 1s, have process to loop in Keenahn.
Management learnings:
 — [Redacted]’s learning: call [Redacted] out. Do not assume others have the same mindset, do not expect your standards and views to be held by others.
 — [Redacted]’s learning: make sure everyone is clear about who is doing what. Make sure to detail responsibilities upfront to both management and CYLs.
 — Francis’s learning: plan sprints on paper. Less talking, more writing — discussion anchored on a screen, with words. Words keep people on the same page.
Decision
Eliminate group-wide discussion of playbook issues
Eliminate CYL calls
Establish on-going co-working sessions between CYL and [Redacted]+[Redacted] present.
Establish on-going daily syncs between [Redacted] & [Redacted].
Co-create a guide document for writing playbooks
Start documenting sprints.


Tuesday, 31 May 2016

DECISION 55

Problem
Francis has to switch into heads-up mode ASAP.
Francis is currently CYL on 5 CBYs.
Francis needs to use those CBYs every day, and can’t be on both sides of the table.
Analysis
Francis has completed V0.5 documentation (GDEs, SPCs, PBKs, FILs) for MGT and DSN.
Francis has not yet completed V0.5 documentation for CRE and STR.
Francis trusts [Redacted], [Redacted], Kamron, and Corey — and wants to spread the work intelligently, against perceived strengths and synergies.
Francis perceives [Redacted] gifted at MGT process, and synergy with CTL responsibilities.
Francis perceives [Redacted] gifted at STR, and synergy with CTL responsibilities.
Francis perceives a synergy between RLM responsibilities, NTS and CRE.
Francis perceives a synergy between RLM responsibilities, TSK and DSN.
Decision
Francis delegating MGT to [Redacted], effective immediately.
Francis will delegate STR to [Redacted] after Francis has completed documentation.
Kamron is CBY for NTS. Francis will delegate CRE to Kamron after documentation is complete.
Corey is CBY for TSK. Francis delegating DSN to Corey, effective immediately.
Tasks
Francis to finish CRE and STR by Thursday EOD.
[Redacted] to schedule time with Francis tomorrow AM PST.
Corey to schedule time with Francis tomorrow PM PST.
Kamron to schedule time with Francis Friday AM PST.
[Redacted] to schedule time with Francis Friday AM PST.


DECISION 56

Problem
Here’s a problem we haven’t yet solved: How exactly do Playbooks generate output Files?
Analysis
I wonder if we just write the Google Doc output files as if the machine could fill the variables.
For example, how do the client’s responses to SYN’s principle lines turn into a document?
It could just work like this…
{{principleName}}
{{principleBody}}
If so, where do output files go in the database? Are they an Output Type?
Decision
Added to Spec: Playbook backlog.
Discuss with Kamron and [Redacted].
Tasks
[Redacted] to schedule 15 minutes with Kamron and Francis on Wednesday AM.


DECISION 57

Problem
How do we name Files in the Clients folder?
Analysis
How do we avoid confusion in Google Drive search, and in the files themselves?
Right now, Files in The Folder are named “Template (File: FileName)”, 
And Files in Clients are named “File: FileName”… 
But this doesn’t disambiguate “File: The Log” for JNL and “File: The Log” for Invisible.
Decision
Added to Spec: The Folder backlog.
Solve with Kamron and [Redacted].
Tasks
Kamron and [Redacted] to generate brainstorm discussions, generate a proposal, and get second opinions only if blocked.
Kamron and [Redacted] to schedule 15 minutes with Francis on Wednesday.


DECISION 58

Problem
How do we make it easier to access The Folder in Slack?
Analysis
We keep pasting links to the same documents over and over again in a channel.
Slack has a “Pin” feature. We can pin documents to that channel.
In every #CBY and #CBY-CLT channel we can pin the relevant documents.
This would make it easier to access The Folder in Slack.
Decision
Pin relevant documentation to each channel.
Add to Admin and Playbook documentation.
Propagate.
Tasks
Francis has propagated to #…DSN-INV as an example.
Kamron to oversee propagation BY EOD, and further delegate as necessary.
Kamron to update Admin documentation to review and police Pinned documents. (EOW)
[Redacted] to update Playbook documentation as necessary, to ensure this is always up to date. (EOW)


DECISION 59

Problem
How do we make sure balls don’t get dropped in Slack?
Analysis
Because The Folder is a networked system (a “brain”)…
It is only natural that there are many situations in which…
Messages are posted in one channel that relate to another channel…
We are constantly delegating to each other, and it is easy to lose track of a message…
Emojis are a fun and effective way to mark a message…
Emojis are searchable across all channels… (Ex. search for all open tasks)
It is easy to create emojis…
Decision
Create a unique emoji for every CBY and MCY.
AND for every TMB and CLT.
Code each emoji with the code of the CBY and MCY. (ex. :CAL: and :calendar: both delegate to Calendar. ex. :BSU: or :bruno: both to delegate to Bruno.)
Team members are to remove the emoji after they’ve actioned the message.
Should discourage use of delegating to people as opposed to CBYs. Hints that the CBY system isn’t working.
Update Communications Policy.
Explain to team in The Meeting.
Tasks
Kamron to create the emojis. Kamron to update File: Policy with guidance: “Only delegate to a person when you can’t delegate to a CBY”. Added to File: Agenda to discuss as part of Operation: Spider-Man.


DECISION 60

Problem
How do we discourage policy violations, bad practices, sub-par work?

Analysis
When we see a typo or a mistake or a bad practice of any kind…
There should be an easy to way to address it on the spot…
Asymmetric dynamic should put the burden on the offender…
Emojis are a fun and effective way to mark a message…
Emojis are searchable across all channels… (Ex. search for every instance of :joy:)

Decision
Use the :shit: emoji.
Update Communications Policy.
Explain to team in The Meeting.

Tasks
Kamron to update File: Policy with guidance:

“You are encouraged to use :shit: as often as possible: we all want to improve. When you use :shit:, explain why.”

Kamron to update File: Agenda and explain during The Meeting.


DECISION 61

Problem
How do we encourage best practices?

Analysis
When we see excellent work…
There should be an easy to way to encourage it on the spot…
Emojis are a fun and effective way to mark a message…
Emojis are searchable across all channels… (Ex. search for every instance of :joy:)

Decision
Use the :star: emoji.
Update Communications Policy.
Explain to team in The Meeting.

Tasks
Kamron to update File: Policy with guidance:

“You are encouraged to use :star: as often as possible. When you use :shit:, explain why.”

Kamron to update File: Agenda and explain during The Meeting.


DECISION 62

Problem
How do we minimize chasing?

Analysis
It is better to chase than not to let a ball drop. But it is better not to need to chase in the first place. (See: Responsibility principle)

Every time we have to chase, the chaser saved the day, and the chasee dropped the ball. We need a way to encourage the chaser, and discourage the chasee.

Emojis are a fun and effective way to mark a message…

Emojis are searchable across all channels… (Ex. search for every instance of :joy:)

Decision
Use the :dagger_knife: emoji.
Update Communications Policy.
Explain to team in The Meeting.

Tasks
Kamron to update File: Policy with guidance:

“You are encouraged to use :dagger_knife: as often as possible. When you use :dagger_knife:, explain why you expected it sooner.”

Kamron to update File: Agenda and explain during The Meeting.


DECISION 63

Problem
How do we confirm receipt of a delegation message on Slack?

Analysis
Best practice should be to confirm receipt every time we receive delegation.
The burden is on the delegatee to confirm, and the delegator to make sure it is confirmed.
Emojis are a fun and effective way to mark a message…
Emojis are searchable across all channels… (Ex. search for every instance of :joy:)

Decision
Use the :white_check_mark: emoji.
Update Communications Policy.
Explain to team in The Meeting.

Tasks
Kamron to update File: Policy with guidance:

“You are required to use :white_check_mark: every time you are delegated to.
When you don’t use :white_check_mark:, you may be chased with :dagger_knife:.”

Kamron to update File: Agenda and explain during The Meeting.


DECISION 64

Problem
How do we standardize File descriptions for Specs, Guides, and Playbooks?
 — Should we discourage descriptions longer than one line?
 — Should we discourage customization of descriptions by the CLT?

Analysis
Francis’s File descriptions are somewhat standardized… but they aren’t perfectly consistent.
 — How do we standardize descriptions for Specs?
 — How do we standardize descriptions for Guides?
 — How do we standardize descriptions for Playbooks (pre-sheet)?
 — How do we standardize descriptions for Template Files?
 — How do we standardize descriptions for Client Files?

Decision
Solve with [Redacted] and Keenahn.
Update Spec: The Folder.

Tasks
Kamron and [Redacted] to generate brainstorm discussions, generate a proposal, and get second opinions only if blocked.

Kamron and [Redacted] to schedule 15 minutes with Francis (schedule at your discretion).


DECISION 65

Problem
Design problems with Forward:
 — 1: Can we replace the script with an Emoji?
 — 2: Do we really need to delete the message?
 — 3: How is Forward different than Slack’s “Share” feature?

Analysis
 — Emojis are both better UX and easier to code.
 — Open question of whether to have 2 emojis or just 1.
 — We don’t need to delete the message.
 — Forward re-routes the thread from Meta. “Share” doesn’t.
 — We are experimenting with CBY emojis. Learning…
 — Forward doesn’t need to be finalized for two weeks.

Decision
Postpone so we can think and learn.
Update Spec: Messages and Diagram: Technologies.

Task
Francis and Keenahn discussed on JUN 1, WED.
Francis and Keenahn to revisit next week.


DECISION 66

Problem
We don’t have a process for backing up The Folder?

Analysis
Backups are important. Example: Toy Story 2.
The Folder is our most important asset.
We need a process for backing it up regularly.

Decision
Update Spec: The Folder.
Update Admin documentation.

Task
Delegate to Kamron. Report back by JUN 3, FRI.


DECISION 67

Problem
How do we archive and name Client output Files?

Analysis
Francis initial proposal:
Each directory to have an “Archive” folder.
Previous months get saved as “FileName — May 2016, TeamName Team, IncShortName.”

Decision
Propagate.
Update The Folder documentation.
Update Admin documentation.

Task
Delegate to Kamron. Report back by JUN 3, FRI.


DECISION 68

Problem
Is it necessary to have Osmosis for Francis internally?
 — How do we keep Francis out of #…CBY-CLT channels for CLT=INV?

Analysis
Aside from the fact that the CLT experience is not exactly the same for Francis as for other CLTs… Which doesn’t just affect Francis’s experience, but affects investor demos and decision-making…

It is also a major burden for CYLs to have to log in as Keats every time they would normally use Osmosis… (CYLs have complained)

After reviewing Spec: Messages — it does not seem like a major change to spec or code would be necessary to support this edge case.

Decision
 — Modify the Osmosis spec (Update Spec: Messages)
 — Alter code as necessary to accomodate edge case
 — Create #keats-CBY channels in INV Slack for Francis.
 — Francis will leave #…CBY-INV channels…

Task
Keenahn to review with Kamron and revert to Francis with proposed final decision.
Keenahn approved.


Tuesday, 31 May 2016

Decision 69

Status
Approved, Pending Implementation
Problem
How do we make Slack more inspiring for our CLTs?
Analysis
Take inspiring quotes from the CLT’s notes and set up on Slack as loading messages.
Decision
Update Admin documentation.
Implementation
Task: Delegate to Kamron. Report back by JUN 3, FRI.


Decision 70

New Support “Shifts” System
Status
Approved, Pending Implementation
Capability
[03] Projects / [02] Support
Problem
What technology should we build to support our shifts system?
Analysis
Corey to write analysis
Decision
Update Spec: Shifts.
Implementation
Task: Corey to synthesize input from multiple parties.
Task: Corey to write the spec.
Task: Corey to get Francis signoff.
Task: Corey to get Keenahn signoff.
Task: Corey to merge Spec: Shifts into Spec: Automata.
Task: Corey to update Diagram: The Folder.


Decision 71

Organize Product Roadmap Backlog
Status
Approved, Pending Implementation
Capability
[03] Projects / [01] Product
Problem
How do we organize our technology backlog?
Analysis
After reviewing the entire backlog…
Francis analysis is that there is value in old ideas…
That Trello needs deep organization work…
That Workspace (Technologies) needs work…
That certain policies and principles can prevent sprawl in future…
Decision
Make sure Trello and Drive are in sync. Clean up Trello.
Create a more rigorous Backlog and Sprint planning process.
More closely integrate the Technology team and Capabilities team, through this system.
Tasks
Francis to go through every card (done)
Francis to pull down cards into Drive (done)
Francis to integrate cards into new system (done)
Kamron to check Francis’s work for completeness (in progress)
Francis to review 100% of cards with KTJ (to do)
Francis to refactor 100% of cards with KTJ (to do)
Target: complete by JUN 3, FRI.


Decision 72

Data Architecture To Support Multiple Client Output Files Per Micro-Capability

Summary
The Notes Capability forced a data architecture upgrade to generate more than one Client Output File per Micro-Capability.
Status
Approved, Implemented
Participants
Francis
Kamron
Capability
[03] Productivity / [04] Notes
Problem
How do we propagate multiple Client output files for the Notes CBY?
Analysis
Kamron initial proposal:
Each Default List to have a folder.
Each Default Draft to have a folder.
Any List with a Sub-List to have a folder.
Archives to exist as appropriate.
Decision
Update The Folder documentation.
Update Admin documentation.
Update Notes documentation.
Implementation
Entry — Thursday, 31 May 2016
Original task was as follows.
Task: Delegate to Kamron. Report back by JUN 3, FRI.
But was ultimately implemented organically by Francis’ design and implementation of Learning and Creativity Capabilities in July 2016.