RFC: Host one Hackathon per quarter in 2022 about readme HOT 8 CLOSED

@mdole my thinking on trying it more often was also knowing that this is a unique opportunity to create connections across PDDE and across Artsy as a whole. That feels extra important to invest in (and almost "overdo") given that we are remote! And, given our operating cadence as a company is quarterly, this could fit in nicely as a change of pace from regular sprint work.

And, the whole point of this is to learn. So I love the idea of checking in frequently and adjusting.

@anandaroop 's idea to "theme" the hackathons also seems like something we could try! I love the idea of interspersing hackathons with bug bashes, etc. The only downside I see to adding in some variability is that it makes the effort of running this event a little more complex. However, if the group running it for that quarter wants to try something new, I see no reason to not support it!

from readme.

Certified hackathon-lover here, but also just wanted to say that I hear the concerns about 4x per year being potentially a lot. I'd be content going from 1x to 2x, if we thought that would help keep hackathon vs FF distinction clearer or address other concerns.

If we do go with the more frequent cadence, I like the "theme" idea and I'd even nominate "bug bash" as one of those themes. We ran a formal bug bash a couple of years ago and it seemed (to me, at least) like a great success but for whatever reason we haven't tried to stage another one since. "Paper cuts" could be another theme, maybe.

from readme.

I guess it goes without saying that I LOVE IT 💜!

I do think its a lot, but I think with them being very very very optional, it will be ok. And I don't think that suggesting 3 instead of 4 per year would help much, because as you say it's a trial, and it is useful to explore with a number that is different enough from what we do now, and 4 seems like a good test with good information to give us at the end of it👍.

We have talked about this, I think one thing that could help is make some of these "themed", or just letting them happen and see what themes come up naturally.

In any case, I'm excited! Great idea to try this out, I look forward to the findings of this, and to all the things that will be built 🙌.

from readme.

Generally in favor if the team agrees to it, but having a hackathon every 6 sprints would probably wash away some of the novelty for me- for my personal taste I'd prefer less. I'm also wondering:

• How this would impact future friday, which already kind of feels like a biweekly mini hackathon?
• Would hackathon still be an all-company event?
• How do we anticipate the kinds of projects people choose changing with this cadence (for example- circumventing the PDDE prioritization processes to address requests within the company - versus - more ambitious spikes (or just technical debt)?

from readme.

I'm very supportive of doing more hackathons. This one was a great example of driving a lot rapid impact and generating a lot of ideas for our future roadmap.

The spillover effect is very real: for instance the legal & finance team have already been hit with 2-3 projects that have generated or could generate an extra 5hrs of work each outside of what was planned in the roadmap.

If we want this to be sustainable and continue to receive support from the rest of the company, I think we need to have a more explicit process to manage what happens post hackathon.

Probably something like:

• Agree explicitly on level of investment post hackathon (fold into team a backlog, save for future fridays or put on hold and gather learnings for now)
• If we fold it into the team backlog (and even more so if there's a need for cross functional alignment), then make sure we treat it like other backlog items, create a product brief for it, align with cross-functional folks on relative urgency etc. which leads me to believe that we'd need proper PM support for it.

from readme.

Certified hackathon-lover here, but also just wanted to say that I hear the concerns about 4x per year being potentially a lot. I'd be content going from 1x to 2x, if we thought that would help keep hackathon vs FF distinction clearer or address other concerns.

@anandaroop yeah, just to reiterate: I definitely hear where you + other folks are coming from on this! My initial response was also "4 is too many!", but then I thought about it some more and realized I liked the idea of going big and regarding it as an experiment.

One idea I just had: after the most recent iteration of hackathon, we sent out a one-question survey that just asked for broad feedback. After the next iteration, let's send a similar survey but add a question about how excited folks are about doing another iteration in 3 months. If we see very negative sentiment, then that's a good sign that we may wish to halt the experiment early or otherwise adjust our parameters. Something like:

How excited are you about the prospect of another hackathon in 3 months?

• Very excited; I will almost certainly participate
• Neutral; I may participate depending on my schedule
• Neutral; I likely won't participate but I support others doing so
• Anxious/stressed; I will likely not participate and would feel better if we stopped having hackathons
• Other: ...

@sweir27 as co-author of this RFC, curious if you have a perspective on "survey frequently and possibly exit early" vs. "commit to doing a full year and encourage people to set their own boundaries"!

If we want this to be sustainable and continue to receive support from the rest of the company, I think we need to have a more explicit process to manage what happens post hackathon.

@SamRozen thanks for the nudge on this! I'm happy to take on responsibility for this as hackathon DRI. Added the following to this RFC description:

Under "Communications cadence":

• [Matt to lead] 1 week after: 1-hour session with hackathon organizers + PDDE leads to discuss the next iteration and evaluate which ideas to ship/investigate/shelve

Under "Responsibilities":

• Matt as overall DRI:
  • Schedule post-hackathon meeting with PDDE leads to touch base and clarify followups as quickly as possible

Let's start there, and I'm happy to take further suggestions about how to make this sustainable for folks both inside and outside of PDDE

from readme.

@pvinis thanks for the enthusiasm and the comments! Quick thoughts:

I think with them being very very very optional, it will be ok

Yep 100%. We'll make sure to continue to be clear about that.

one thing that could help is make some of these "themed"

Definitely an interesting idea! I'm happy to discuss this with whoever ends up organizing the next iteration :)

@erikdstock good questions and appreciate the feedback! Here's my take - definitely welcome folks from PDDE leadership to chime in here as well.

How this would impact future friday, which already kind of feels like a biweekly mini hackathon?

I think we should leave future friday as-is for now, but keep an eye on whether we find ourselves making less use of the time (e.g. "I'm going to skip FF because I'll work on this stuff during hackathon...") or falling behind our planned projects/cadence as an org (e.g. "We thought we would have this done in April but because we spent a few days on hackathon + FF we'll actually finish in May").

While the plan for now is to fully evaluate this early 2023, I do think it's important to have brief touchpoints after each hackathon to ensure we're still feeling good about moving forward and to tweak our plans for the next iteration. I'm realizing now that this isn't codified in this RFC and should be. Here's what I suggest we change:

Communication cadence
...

• 1 week after: 1-hour session with hackathon organizers + PDDE leads to discuss the next iteration and evaluate which ideas to ship/investigate/shelve

...

Would hackathon still be an all-company event?

Yes. At present, the main way teams outside of PDDE participate is by suggesting ideas and providing context (e.g. Auctions ops asks for a change to Ohm, so the engineers who volunteer for that idea meet with the team to understand the need). While hackathon may still affect those teams' schedules, it does so on a smaller scale than for PDDE (a few hours instead of most of a week). I feel strongly that it's still a net-positive to give folks on PDDE a chance to meet, collaborate with, and solve the problems of other teams.

How do we anticipate the kinds of projects people choose changing with this cadence (for example- circumventing the PDDE prioritization processes to address requests within the company - versus - more ambitious spikes (or just technical debt)?

I think it's hard to know without trying it out! I hope that we will still have a balance of those different types. Having more hackathons overall may also encourage people to experiment more. For example, let's say I worked on a small-scale admin tooling project last time. Maybe I'll try something big and ambitious next time because now I understand the pace of the hackathon and how to get help and support from more senior teammates!

from readme.

Well-said, thanks @sweir27. We'd definitely discussed cross-org collaboration and connection as part of the rationale for more frequent hackathons, but I needed that reminder!

Let's wrap this up.

Resolution

We'll try this out and check in throughout the year!

Level of Support

2: Positive feedback

Additional Context:

Most of the concerns we heard were about this potentially being too many hackathons and having too much spillover (i.e. projects taking a long time to resolve, requiring lots of work from people both on PDDE and other teams). As hackathon DRI, Matt will try to keep post-hackathon followups quick and clear and disruptions minimal. We'll also get feedback from the team after each iteration to make sure we're not overdoing it.

Next Steps

Matt will find hosts for the March iteration and help them start the planning process

from readme.