2022 W50 - A different kind of Hackathon
Rows is now "Building in Public". Every week I'll post about one thing that happened! Check them all here.
The Rows team loves hackathons.
Building a spreadsheet is hard work. There are thousands of features to pick from, incredibly demanding users, and no shortage of ideas of where to take tables, data and sharing next. That's why it makes sense to try out ideas unencumbered by process.
We have done about 2 hackathons per year, ranging from 2 days to 2 weeks. This week we discussed the idea and format for our next hackathon in early Jan.
Are they successful? yes.
We have shipped several impactful features from hackathons:
Conditional Formatting feature;
A system that generates deploys for any particular pull request;
Collapsable sidebar;
The Quick-command menu (Cmd+K);
XYLOOKUP();
Exporting Charts as images;
Cool Chart types (Pie, Scatter, others yet to be shipped);
Grids (like the one we have now in the editor).
Other things that appeared in hackathons didn't see the light of day yet but have informed us how we should build them:
A function =PYTHON() that runs Python code;
Multiple iterations of user-created functions.
Rows API;
Several incarnations of desktop Apps for Rows;
All kinds of macros and scripting languages;
A webhook function;
Many technical projects involving WebGL, web workers, and whatnot.
We had incredible fun in the demos too.
The best Process is No-process
Waterfall is a bad idea for software startups in general, and a terrible idea for hackathons.
You should give engineers as much decision power as they can/want to take, and align that with outcomes. Engineers are the builders of software, but they are also its architects, designers and users too. The more they use these powers together, the more they deliver amazing products. This applies to big tasks like building your product and small tasks like hackathons.
Our quarter process follows this approach, and Rows planning is quite straightforward:
The team comes together and creates Challenges to be solved;
We discuss which Challenges are the most interesting and lay them in an ordered list (no sizing);
We pick projects and solve them iteratively. The best I've seen it done is to to understanding where the bottleneck is.
Is it that the engineering problem is complex? Give it to engineers.
Are we facing a critical consistency problem in UX? (that is, is this something that requires deep user research?). Give it to designers.
Only a small fraction of projects should land directly in business specs and such (say, pricing and billing). Typically for those projects that have critical business requirements in them.
The most interesting challenges usually have some engineering problem within them, so you almost never miss out by starting to hack away at the goal and start with engineering. Code will always be rewritten, engineers with 2-3 years in experience understand common design patterns, and you can always iterate details. That is an oversimplification, there's exceptions, but you can see how we think about it in the processgram below (image). In practice, we follow this intuitively and without much boundary.
Same for hackathons - just more so
For hackathons, though, you need to cut process to the bone.
Come up with interesting ideas.
POC the shit out of them.
When the testers (the team) think it's looking good, start iterating finer design consistency with the rest of the product, then colorize and push the fucker out the door!
It is probably a mistake to start with specs, approaches or designs. So, you know, don't do it.
Innovating the next hackathon: call in the suits.
Seeding ideas is an important part of the hackathon, and that's where the innovation is.
Historically, all the ideas were floated from the team at large and engineers picked whatever the hell they wanted. More than 50% of ideas were straight out of engineers minds; and that worked out well.
This time around, given that our product is mucho ready, we are going to experiment ideas on the frontier of business. So it'll be us, the (boring) Managers, who will seed many challenges, and engineers will pick the ones they like from that big list.
There's a Trash can, there's colors, there's functions, there's Charts. See the temp list 👇.
I am very confident we will write about it in the January.
See you next week.
Humberto
PS: For those who ask, yes, we give out a small prize to the best ideas, voted democratically by the team at large.
