RFC: Host one Hackathon per quarter in 2022

[mdole]

Proposal

Try hosting one hackathon per quarter for 2022 and review how it went in Q1 2023

Reasoning

• Excitement: hackathons have historically been good for morale! People enjoy having agency to work on exciting projects, help out their coworkers, and learn new things
• Impact: high-impact things happen when we get to dream up projects. Good for the business too!
• Innovation: they help us trial new technologies!
• Camaraderie: Artsy is mostly remote these days, which has made it hard to build connections across the organization. Hackathons give us a forum to connect with people both within PDDE and on other teams, and doing them every quarter would mean we have more of these opportunities for connection
• Prioritization: hackathons help inform product team priorities and work. Learnings from a hackathon project might result in us prioritizing or deprioritizing an upcoming project, for example
• Return on investment: hackathons surface low-lift, high-impact improvements to admin tools and team workflows. While we’re working on addressing these issues within regular PDDE teams, sometimes things slip through the cracks or just don’t get surfaced at the right time! Hackathons can help keep Artsy running like a well-oiled machine

What might this look like?

DRI

Matt Dole → Responsible for driving this initiative (a year of hackathons) and the retrospective with proposed next steps, though not necessarily organizing the individual hackathons

When would they take place?

March 29 - April 1
End of Q2, ~ June 28 - July 1
End of Q3, ~ September 27 - 30

Hackathon schedule

Tuesday

• 30-minute Kickoff meeting (12 PM for NYC, 6 PM for Berlin)
• Pick projects, form teams, start hacking!
  Wednesday + Thursday
• Hack days!
  Friday
• 1.5 hours for Presentations! (11 AM for NYC, 5 PM for Berlin)

Communication cadence

• 1 week before: email to team@ with Notion board for suggestions
• 1 day after: send survey for feedback
• [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
• 2 weeks after: wrap-up. What did we learn, celebrate outcomes

Responsibilities

• 2-3 volunteers per hackathon
  • Responsible for:
    • Sending intro email
    • Creating the board
    • Running the kickoff
    • Running the presentations meeting
      • Share an empty deck with copyable slides on Friday. Could use last time’s deck as a starting place
    • Pinging PDDE Leads about followup steps edit: assigning to Matt instead
    • Sending follow-up email to the team!
• Matt as overall DRI:
  • Schedule post-hackathon meeting with PDDE leads to touch base and clarify followups as quickly as possible

Next steps

• Get feedback on this proposal
• Put these recurring meetings on the calendar
  • 3x kickoff, hack days, presentations
• Find volunteers for organizing future iterations
• Schedule retro for beginning of next year to evaluate
• After the next hackathon (end of March), we will check in with Sam to see whether the cadence is working

Risks

• Hackathon projects can sometimes require follow ups that spill over into subsequent sprints. There is a risk that this can delay sprint priorities and quarterly goals.

  • Potential mitigation: Make it explicit that we should wrap in-progress work up quickly. If possible, loose ends should be tied up by end-of-day and any next steps should be understood and taken into consideration by a suitable product owner who can prioritize against other projects. PDDE Leads will help to evaluate next steps and delegate the relevant in-flight hackathon projects to teams, and those teams can then drive the prioritization of these projects as part of their sprint work.
  • The spillover can also trickle down to stakeholders outside of PDDE, we’ll follow up with them too to ensure that it’s not too disruptive to their workflows.

• Doing quarterly hackathons is overwhelming.

  • Potential mitigation: Participating in the hackathon is encouraged (because of the benefits outlined above), but it’s not required. This is one aspect we will definitely want to check in on in the retrospective.

Additional Context

Hackathon hub in Notion - click into individual events for idea boards, emails, and more!

[pvinis]

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 🙌.

[erikdstock]

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)?

[mdole]

@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!

[anandaroop]

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.

[SamRozen]

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.

[mdole]

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

[sweir27]

@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!

[mdole]

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