Stop Talking About the Work and Just Do It.

I'd responded to an email to the whole company. "Let me know if you're interesting in contributing in any way" it said. I was interested.

The context

There was a mentorship program was part of the Girls Can Code Africa project. It connected mentees to mentors, and it was being sponsored by our corporate overlords.

A few weeks after my initial email, I received an Outlook invitation for an hour-long meeting. I showed up.

The meeting

After an introduction nearly as brief as the one above, a variety of unintroduced fellow meeting attendees started listing features for the application they wanted to build. A tech stack and architecture was declared. Goals were assumed. Scope exploded as everyone coalesced towards a solution they'd seen work in other situations before: filling a backlog with user stories to capture requirements.

But nobody was capturing these verbal requirements. I took a handful of notes in my notebook before I realized that everyone was going to need them. I switched to a Dropbox Paper document and shared my screen¹.

For the features people described, I would have estimated a full-time team of three people could get it all done in 6-8 weeks.

This is when I switched from patiently listening to asking questions to clarify my understanding:

• Do we have any time constraints or a particular deadline?
• Are we tied to a particular architecture?

I wasn't expecting either of the answers I received.

We did have notable time constraints that would completely shape the way the project: we needed to have something to show the corporate overlords and another, higher-profile stakeholder at a meeting in less than two weeks. We didn't have a team to work on this. Most others joined this meeting just as I had. They were kind, curious volunteers with nothing in common.

We were tied to the architecture. But in asking about it, I found out why: my company wanted to showcase how quickly they could build a product with their own platform. We wanted to impress the stakeholders more than the mentors or the mentees with this one. I could build a Microsoft Form that covered 80-90% of what we'd scoped down, but that wouldn't meet this goal for the final product².

That's when I had to bring our heads out of the clouds.

• There is no way we can build all these features with the given amount of time and people power. What are the most important things to build first?

I acknowledged in a straightforward way that the scope needed to be cut, and redirected the conversation to what was still unclear. As a group, we spent some time weighing the pros and cons of delivering features in a particular order. It helped everyone become more comfortable with the idea that we could deliver what we promised sooner, but we would promise less than...well, everything.

Spontaneous ensemble

We were about 40 minutes into the meeting when everybody was ready to part ways, have one person write a set of user stories to populate the backlog, and then gather together again in a day or two to review and refine the backlog before continuing with any other work.

To me, that seemed like a big gap in time if we only had 10 days to deliver. People were about to start saying their goodbyes and waving at each other over the video call when I interrupted with one last question, by far my favorite:

• Could we start building this together right now? What if we spent the next 20 minutes getting as far as we can in setting up this app?

That turned this meeting around. We immediately went from having questions we could only guess the answers to ("How much time do you really have to work on it this week? How many of these features can we deliver in 10 days?") to gaining more information about the answers.

We spun up a blank application. We started setting up the domain model. People who had expertise on a topic chimed in when we were going in an untenable direction. We didn't have a working app in 20 minutes, but we set the stage for groups of people to have a common understanding about what needed to be built. Stakeholders who hadn't seen development work with their own eyes before had a glimpse into the nitty-gritty steps of starting from scratch on a project.

Way of working

I couldn't completely change the way of working of a hodge podge of people I had never met and had no prior relationships with in the course of a 60-minute meeting. We still ended up writing a backlog and assigning user stories. When we gathered at the end of the first week to review what had been done so far, most of the stories were half-done and very few completely finished.

But we had a clear understanding of what had been done, what was left, what was most important, and confidence that we could achieve our top priorities even with our tight deadline. Our constraints gave us clarity and focus, and the ensemble helped us stop talking about the work and start doing it.

Where can you do less talking about the work and more doing of the work? Have you been stuck in a refinement meeting where you wonder if it would be faster to complete the story while you have all the right people gathered together in that (virtual) room? What are you going to do about it next time you see this happening?