Integrating reading assignment 1: Introduction

Unedited Notes from the US Discussion: Intro

Notes from Today's Meeting

L:

• "we shape the work before giving it to a team, small group works in parallel to the cycle teams"

• triggered negative reactions:

• its not open

• it assume we're working in an agile (not waterfall) process

• if we shape the work based ont hew ay we've been working, then we might make assumptions about what to build that are incorrect

• if stakeholders arent involved in the shaping,... theres tension

• N:

• the agility of having a small group making decisions

• the potential stregnething t& corerecting that can happen efficiently when gathering stakeholders opinons

• when its not done well

• theres some balance there, its depends on how its executed

• they also said "this book is not about risk of building the wrong thing"

• there are choices that increase/decrease the risk - if we use this process

• the rules of agile: the stakeholders have to be involved

• the stakeholders are no longer involved

• N

• we are multiple teams who operate at different paces

• software devs need a separate space to be able to work on things where they are separated from the reactivity

• the reactivity is operational

• define operational:

• operations:

• things dependent on outside systems, that need to remain in outside systems

• invoicing/accnts receiveleb/payable/ issuing vcs, processing expenses

• not developing software

• e.g. marketing is not ops

• the services provided by the organization

• the softward development

• the day-to-day

• external work

• Lauren: agile vs waterfall

• agile: doesnt work with physical

• good for small, incremental fixes

• waterfall: you have to do each one of these before moving into the next

• shape up as a tool within the greater development process

decide:

• who the user is?

• who the focus is?

• then when product decides what to work on: is this benefitting the 1st party hosts?

support

• small group of ppl between engineers and customer service

• an issue that isnt a bug, isnt a product feature, need to be able to escalate to somewhere

• our revenue model is too lean

• holding the business decision-making with the tech-decision-making

• when building software, we are building software for operational users

• very bespoke

• builidng software for users like this is shit; building something for clients with dfferent needs

• building something with flexible

• meet the base needs, even with different biz procedures

• e.g. if we build something that builds 40% of the needs, its ideally would be 40% for all the entities

• it felt like the process was exclusionary:

• the ball rolling without any input from other people

• within the 6 week process

• the "shape up" is this process

• the product manager not involved in the shape up phase

• requirements

• the devs doing the shape up process with the r

on the spectrum of user design to team design, Nathan is more on team design

• its more important that theres a space for the parallel "shape up" time is there, with full attention

• this person can choose whether or not & who to engage with feedback

• e.g. for UX experiment

• wants to provide someone with tools to build a proposal

• in favor of them using their expertise to gather feedback

• theres still too much involvement in the day-to-day to contribute

this is the responsibility of prodcut dev team:

• how to incorporate feedback and get the signoff

• we know its hard for them to get that feedback (especially when ops ppl are so busy in the day-to-day) , but it is their job to get it

• it will take different tactics with different groups

• "its hard to be involved in building something while you're using it"

"smarter not hard" "less is more"

• thinking about:

• virtual cards & the approval process

• how it ideally would work in the product, but that would create more work for everybody

Agile for internal processes & policies

• a separate internal process for things arent software-related

• we're our own product managers

• deploy/review is when you decide if it goes back into product/design

• we need more blocking mechanism

• we need more planning time before engineers even see it

• more internal structure & policy

ATTENDEES Nathan Hewitt, Lauren Gardner, Kayla E

Impressions from product&design team conversation

1. How "copy" (wording) can be used as a low-cost leverage for making improvements to the platform ... until we get better at the overall process.

2. This is not just a "product process" shift but a cultural shift as well.

3. Visibility is an issue:

   1. How to get an overview of the product, of what others need from it, of what I need from it ... and where I and the needs I represent fit into the "bigger picture"?

   2. How can everyone see what "we" are currently working on?

   3. How can everyone see what we intend to work on next?

4. Making changes to Friday-demos:

   1. Expanding the limited "feedback window" from an hour conversation into something more in depth and continuous.

   2. Upgrading the conversations around demo's from talking about what is being shown to talking about the assumptions that are driving what is being show,

   3. Considering moving the demo's to Monday because Friday afternoon is not a good.

   4. There is a richness to sync feedback that doesn't happen in async feedback.

5. Process - we have been pushing for a process that look beyond "the next deliverable" and this is still fresh ground for us ... we need to remain vigilant and continue to hold this direction while responding to, but not getting overwhelmed by immediate needs.

NZ Reading Group - Shannon & Alina. We discussed the current Product and Engineering process. How many Fiscal Hosts are at capacity with the day-to-day tasks (Operations and Support). Fiscal Host input shaping Open Collective is key and would reduce and optimise workloads in the long term. We discussed a culture of care and how many team members haven’t felt heard in a long time, leading to disengagement. We then delved into burnout, how we are working towards having clearer boundaries surrounding who is holding particular work and how this has led to more hires. Since most of our work is held in long-term employees’ minds, we face issues where new employees are quickly overwhelmed and struggle to land comfortably. 

These elements lead to product and engineering building tech that isn’t fit for purpose.  How do we stay connected as a team? How do we ensure people feel heard, and are we building impactful and meaningful software for those using it? We are excited to see the gems within this exploration of the product and engineering process and feel grateful for being brought along for the journey. To more connection across the team and a deeper understanding