Startup Week

If you are someone like me working on internal platforms, it can be easy to keep iterating. You want to find time to try an innovative idea, to experiment. Come up with some wild ideas that might add significant value to your product. I want to share an activity that can help frame the experience to try new ideas.

This exercise originated from the project manager on the initial dev.lab project. We were spinning our wheels on a couple of weeks of limited experimentation and big up-front design. He pitched the idea as a start-up weekend. You can think of this as an internal hackathon conducted over three days to create a prototype to validate an idea. To limit confusion, I am naming it start-up week. The activity led to the initial version of our internal developer platform back in June of 2020.

Design Sprint

An alternative to a start-up week is the design sprint courses from AJ and Smart based on the Design Sprint book. You can read my notes on the design sprint course. The original version focused on a team working in an office over four days to prototype and try an idea with users. They also released a remote version of the course since we’ve been working remotely for seven and a half years since 2020. The difference in the remote option is that the sessions take place over four weeks.

The format and structure of the design sprint will work for most people. The “Startup Week” is a slightly abbreviated version of a design sprint over three days. You might find it preferable when you have a well-defined problem that you need a broad set of engineers to help solve.

API Design Startup Week

To frame the problem, I found an experiment canvas that could help me communicate the boundaries of the challenge. With my API Design experiment canvas filled in, I gathered the two teams of developers together. I explained the mission and structure of the next few days.

Day 1

  • Gather everyone together and level set on the scope of the problem and desired outcome.
  • Assign the two teams to separate breakout rooms in WebEx.
  • Resync in the main breakout room midday to share each team’s progress.
  • Resync near the end of the day to share progress and feedback from our key stakeholders.

Day 2

  • Separate teams in each breakout room.
  • Heads down focus.
  • Encourage the teams to not worry about the difficulty of implementation.

Day 3

  • Separate teams in each breakout room.
  • Resync after lunch to share progress and set expectations on end-of-day demos.
  • Share the presentations of proposed solutions.
  • Set the expectation that we will discuss the ideas we like best and start putting work in the backlogs.

Outcomes from the event

One of the unexpected occurrences was some pushback on some of the constraints of the initiative. Improvements to the code generation process were off the table for this exercise. Since the whole point of the exercise was to experiment, I relented after the team challenged that idea. Everyone walked away with a broader shared understanding of the problem space and possible solutions. As well as the common challenges software engineers face when presented with creating a new API from scratch.

Recommendations For Improving API Design

  • A dedicated workflow to guide API design.
    • Move code generation to a later part of the process.
  • Open source tools to guide and enforce better style guide consistency.
  • A long list of self-service portal UX improvements to make resources more discoverable.