Defining OKRs for Q3 2018 - Understanding what we are optimizing for && Leverage the growth and teams #654
Comments
|
Really appreciate the thoughtful summary, David. You've captured an
element that has been under-emphasized in our OKR planning - how to best
deliver benefits to internal and external stakeholders is *the* critical
lens to have. As a side note, KPIs can also be useful here. (KPIs are
measurable values that capture how effectively a project is meeting its
long term objectives.)
…On Sat, Jun 30, 2018 at 8:16 AM, David Dias ***@***.***> wrote:
Hi everyone, kicking off this thread to create an index of each teams OKRs
and their prep location + create a lever to help everyone define their best
OKRs yet.
OKRs Index
- OKR Final Locations
- IPFS & its subteams
<https://docs.google.com/spreadsheets/d/19vjigg4locq4fO6JXyobS2yTx-k-fSzlFM5ngZDPDbQ/edit>
- libp2p
<https://docs.google.com/spreadsheets/d/1HTXfgR5FyPTFhsTkFPRThkeMvHvCgJOaAs7BSl_vQ_0/edit>
- IPLD
<https://docs.google.com/spreadsheets/d/1Lfd91hi3nFlLRS1r-FHvK2ip2Ll6ukraufCgepw43bw/edit>
- OKR WIP Locations
- js-ipfs <ipfs/js-ipfs#1409>
- js-libp2p <libp2p/js-libp2p#207>
Understand what we are optimizing for
One of the things that is crucial for continuous healthy growth of the
project and nailing the right OKRs is actually understanding what needs to
be achieve to fulfill use-cases and user needs.
We've done some work in the past to document a share understanding of what
these needs and users are (applications of IPFS
<https://github.com/ipfs/ipfs/issues?q=is%3Aissue+is%3Aopen+use+case+label%3A%22applications+of+ipfs%22>
& Design IPFS Roadmap by use case
<ipfs/ipfs#314> & IPFS User Registry
<#626>). However, most of the actual
needs continuous to be tribal knowledge, only know by a few of the WG
Captains or the more active and public facing contributors of IPFS. We need
to change that.
Me and @steverichmond <https://github.com/steverichmond> are working on a
rubric to help WG Captains and Participants document it in a standard way.
Meanwhile, there are already a set of questions you can answer and share
with the rest of your team. These are:
- What are your top users/applications on top of the part of the
project you contribute and/or lead?
- What are their next goals? How can your project help them be
successful?
- What are the main blockers for adoption of your project?
- What are the main blockers for contribution to your project?
- Name the most important thing you and your team need to achieve?
What is the timeline for that? What could be done to achieve that in less
than three months (Hiring, Partnerships, Drop other tasks, etc)?
In the past, this information was propagated because we had the chance to
write the OKRs together in the same location. Now that we do the planning
Async and Distrbuted, it is up to the teams to gather this information
proactively.
Leverage growth - Communicate to each team what are your needs
In the same way, there are now dependencies between IPFS/libp2p/IPLD
teams. Examples are: js-ipfs needs js-libp2p and js-ipld; DDC needs
GraphSync from IPLD; Web Browsers have needs from js-ipfs.
Consider the dependents as consumers/users of your project and gather
their needs as well. You shouldn't be planning something that requires
something that is impossible to achieve this quarter by another team.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#654>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AlD--HFG_uylXeJPo9yUHKljXkSOfUYWks5uB5Y1gaJpZM4U-ASf>
.
|
|
@diasdavid @steverichmond you might be interested in the workshop I just proposed for the Berlin dev meetings around matching IPFS work to user journeys. This is a very effective technique, and can be done remotely (though works best to kick-off a first draft in person together). An observation: conducting actionable user research, collecting user feedback continuously to guide products, and creating documentation around this on a project as big as IPFS is several full-times jobs. It isn't necessarily fair (and will not produce the best results) to ask our dev team to do this on top of delivering features, and in any case, it is a distinct specialization. If we are basing OKRs and KPIs on user needs (which I fully support), can we hire a UX team to get those inputs for IPFS? We talk a lot about how we are committed to user experience. This could be a great opportunity to take that to the next level. In the future, can I please be included on anything related to IPFS user research and user needs coordination? I've been doing this work separately, and didn't know you were also working on this in parallel. Thanks! (PS: I also didn't know where I should share updates and track my work to make it more widely known. Perhaps this repo is the place!) |
100% Agreed. Just to not confuse folks, the ask on this issue is not to create fully fledged user journeys and user research, it is rather to ensure that the team working on the project does some knowledge transfer and at least the knowledge that already exists on people's heads gets shared.
Of course. We will do it in the open as always. You can see the urls I shared above to some of the points where that information has been gathered.
Yes, please do share it through an IPFS repo. Consider even creating one just to gather all the User Journeys. Share pointers to the work at the IPFS All Hands. |
Done. https://github.com/ipfs/user-research (thanks to @hsanjuan for creating that for me, and suggesting a good location for it). I haven't had a chance to write a README and other basic docs yet (soon), but at least it exists. User research is broader than user journeys, so we named it in the more general sense. The thing I would specifically like to be involved in is this @diasdavid :
|
Hi everyone, kicking off this thread to create an index of each teams OKRs and their prep location + create a lever to help everyone define their best OKRs yet.
OKRs Index
Understand what we are optimizing for
One of the things that is crucial for continuous healthy growth of the project and nailing the right OKRs is actually understanding what needs to be achieve to fulfill use-cases and user needs.
We've done some work in the past to document a share understanding of what these needs and users are (applications of IPFS & Design IPFS Roadmap by use case & IPFS User Registry). However, most of the actual needs continuous to be tribal knowledge, only know by a few of the WG Captains or the more active and public facing contributors of IPFS. We need to change that.
Me and @steverichmond are working on a rubric to help WG Captains and Participants document it in a standard way. Meanwhile, there are already a set of questions you can answer and share with the rest of your team. These are:
In the past, this information was propagated because we had the chance to write the OKRs together in the same location. Now that we do the planning Async and Distrbuted, it is up to the teams to gather this information proactively.
Leverage growth - Communicate to each team what are your needs
In the same way, there are now dependencies between IPFS/libp2p/IPLD teams. Examples are: js-ipfs needs js-libp2p and js-ipld; DDC needs GraphSync from IPLD; Web Browsers have needs from js-ipfs.
Consider the dependents as consumers/users of your project and gather their needs as well. You shouldn't be planning something that requires something that is impossible to achieve this quarter by another team.
The text was updated successfully, but these errors were encountered: