Tl;dr: What you should take away from this post
- How you should conduct yourself as a CC of the IFT, and how that behavior translates to the work we all do
- What the hell is the “Insights team” and what is the hopeful result from their work
- How to stay up to date on what’s going on within all the IFT’s projects
- The (incomplete) history of “project reporting” and where it’s headed, and how that impacts you
We are a Public Institution - Act Like It, It’s to Your Benefit
Privacy for the Individual and transparency for the Institution
- Someone other than me
Let’s start with something I want to make very clear.
We are an institution, and as such, everything we do should be as transparent as possible. You, as a contributor, should conduct yourself accordingly. This means if you don’t want personal exposure, come to the table with appropriate individual privacy protections. If that means you dawn a pseudonym and don’t ever turn on your camera, so be it. As long as the Finance team knows how to pay you for your services, then we’re good. Maybe you need to “quit” and “come on” as someone new. We can figure these things out if need be. Leads, you need to be able to effectively work with people like this. These are supposed to be community projects, you’re going to need to work with a community of people where you don’t necessarily know everything about them or control their schedule. Having a community does not simply mean “have users.” It means having people involved at every meaningful step of the process research and development to getting users and growing.
It should be emphasized that this is a cultural shift that is needed by every single person who contributes to projects within the IFT. When you’re working on something, anything, your mentality should start with “everyone can see this.” If that isn’t the case, then there should be a very solid reason as to why. It’s easy to not do this (I fall prey to it myself), but we have to continuously make an effort to default to public, and have strong reasons to not for any specific case. It takes humility to be able to do this, opening yourself to critique on “unfinished work.”
As head of the Insights team within the IFT, a good portion of my effort is to surface the work we are doing and make it understandable. I want every single piece of work that is done within this org to be easily found and watched. No secrets, no waiting “until it’s ready”, no protection from “competitors”. If this is something you don’t agree with or like, then maybe this isn’t the place for you.
There are few things we need to keep relatively private:
- Individual’s personal information
- “Unofficial token related” work (I’m still iffy on this one, even)
If this is done correctly, then we (as Insights) will be spending VERY little of our time tracking and surfacing materials, and MOST of our time trying to help push things forward towards your goals. Ya know, providing insights. The more time we have to spend tracking things down and ensuring that what is planned is what is done, the less time we have to add resources to help get things done.
If done correctly, anyone in the world can easily see what a project is planning on doing, how they plan to do it, and how well that execution is going relative to the plan. This opens up a number of benefits to the IFT and the Projects it funds.
- Developers/Researchers in the broader ecosystem can contribute at any point of the process. They can see exactly where they might fit in, and come to the table with how they’re going to help.
- Communication overhead and redundant work goes down significantly, giving people much more time to focus on the things they came here to do: building things that matter. Additionally, there’s way more opportunity to learn and work together on things that make sense to do so.
- Everyone stays on the same page of what the goals of the IFT are, how they’re being pushed towards, and where they’re contribution fits into the grand scheme of things.
- many, many more.
Transparency is a NEED, not a WANT.
The Logos Reporting Process - A Start
When I started working as the Logos Program Lead, my task was to understand the plan of the projects within it (Codex/Waku/Nomos) and make it clear to the IFT such that we could start conforming to the new “Milestone Budgeting Process,” i.e. the IFT saying to a project: “we agree to pay for this work for this amount of time, go.” It was supposed to also help understand how “efficient” the money we were spending was on the individual projects. The first solution I came up with was defining what a “Milestone” was and creating a (what I considered) very lightweight weekly update process on those milestones. These would all then be published publicly on the roadmap website for anyone to see. Leads/PMs for each team would also indicate when they did this by posting in the Logos Discord’s #leads-roundup channel in case anyone across the org wanted to watch these updates.
This provided a few things:
- a lightweight way for the org to keep track of what’s going on within all Logos projects, delivered in a single place so they didn’t have to go searching around for things.
- a publicly available way to have a backlog of updates on the planed (and approved) milestones that projects were focused on.
Projects have quite a bit of freedom to work the way they feel is appropriate, granted they conform to IFT requirements on the Milestone-based Budgeting Process. This leads to a very diverse set of tools and places that information exists. If we don’t have something that brings it all together, any level of global understanding becomes basically impossible. People simply don’t have the time or mental capacity to keep up with where things are stored for each project and then figure out how to understand what they’re doing or how it’s going from that documentation. In some cases, that documentation doesn’t exist at all. As the IFT grows, this problem grows with it.
This attempt got a reasonable outcome for a first try. It received a varying degree of conformity but, if desired, you can see what’s going on by watching either the #leads-roundup channel in Discord or each Project’s weekly-updates section within the roadmap website. Some of that Milestone and Roadmap info is updated directly into the website itself, others is updated in some other tool (Github Projects, Notion, Miro, CodiMD, etc) and is linked to.
Additionally, it ensured that at least one person within every project was regularly thinking about the plan, how it’s going, and what happened each week that “moved the needle.” Someone (hopefully more than that) needs to be making sure that they’re delivering what they said they would, within the budget they were given, on the timeline that was agreed upon. This process helped all projects get more organized than they previously were, as well as being more transparent to the entire org about all of this information.
Whether or not people actually use these resources is a very different story. Turns out, most people don’t, except me and a few others. I think Waku and Vac use it thoroughly for their own work and the rest do it because they’re asked to. I use it extensively to try and keep track of things I’m not directly focused on at the moment so that I can properly report the execution of Project’s roadmaps to the IFT committees. It also helps me tremendously in shifting priorities when I need to.
This current process lacks in a number of very meaningful ways:
- It does not provide enough benefit to the projects themselves, and in some cases is seen only as a burden and redundant work.
- It does not give as up-to-date and detailed picture of the project’s roadmaps and execution progress as we should aspire to.
- It is not easily consumable. Meaning looking at the website, it isn’t easily digestible to understand the global scope of projects, what they’re focusing on, and how well that’s going.
- In order to fix these things (and stay with the current process), it would take a lot of manual labor from the Insights team to track gaps and get them filled.
- People who could plan around execution progress didn’t use the resource and plan accordingly, they still usually asked me.
- The “insight” material was never faithfully produced for projects and teams as I wanted it to (and was responsible for). Monthly summaries didn’t get done, visualizations of progress (Gantt charts) were not produced, risk analysis wasn’t performed, etc. I could go on and on as to reasons why, but in the end, this was my failing.
- The updates aren’t necessarily easy to understand w.r.t. how progress is meaningfully made against the planned roadmap.
NOTE: If I’m wrong here, please be explicit in how so I can update my perspective of things.
Expanding into All of the IFT - A Continuation
I’ve since shifted roles again to be the head of the Insights team within the IFT. This expanded my role from watching only Waku/Codex/Nomos to now be across all projects within the IFT. This is quite an expansion of responsibilities, but one that is (in my opinion), incredibly useful to the organization’s success (if done well).
We’ve even started seeing weekly updates across the org in the #leads-roundup channel as Arwen has pushed for since she has joined us as Chief of Staff, thus making it an even more valuable place to keep high level track of progress for everyone. It is not in the same unified format, but they are on-going updates none-the-less. This marks the first time we have ever had such a thing since expanding from just Status to a multi-project Organization.
But we can improve things much, much more (see list of failures above).
Backfilling my role within Logos, and with the additional roles we have within Insights, we are now in a position to start improving things. The new solution needs to:
- Clearly define the plan and expectations around deliverables of that plan
- Enable the ability to track progress by anyone who wants to
- Be useful to the Project for understanding agreed upon expectations and delivering them
- Allow for Projects to organize themselves the way they see fit to execute
- Not produce redundant work for projects in the name of “reporting”
- Be structured in a way that doesn’t require manual translation in order to get understanding on the same set of information
- Facilitate identifying deviations from the plan and those deviation’s associated risk/reward
In order to do this, me and Leonard are rallying around the concept of FURPS. More specifically, we will be assisting teams in defining the functional and non-functional requirements of what they are delivering, bucketed into the categories defined by the acronym: Functionality, Usability, Reliability, Performance, Supportability. The IFT is an institute that is building software; it makes sense to rally around a standard of software quality, aiding in setting the target of what we can safely consider “good.”
Alongside this effort, we’re rolling together most of the tasks of Insights into this. meaning that the resulting output will provide a visualization for anyone to see, key target metrics to watch and monitor that help the Project understand what they’re working towards, a roadmap that elucidates what’s coming around the corner, and associated risks that pop up and how they’re mitigated.
I look forward to working with you all in this effort. As always, we are available for comments and critiques along the way. we’re all in this together, and no one here is building in a vacuum. The better we understand what’s going on across the org, without undue burden, the better we can work together to achieve the IFT goals and make software that could make a real impact.