One endless meeting
We made a list on my team at Retool the other day of all the things we’ve done, everything we’ve shipped since the team started back in November. And it’s a lot! Plus, I realized that we’d shipped more in the last four months than I had in the prior three years. So what gives?
Was it the folks I was working with? Was it 10× engineers? Am I a 10× designer? (Lol no.) Or perhaps it was the environment? The snacks at the office? The app that we’re building? Were we all just running as fast as humanly possible and shipping a bunch of garbage? (Well, no. I think we’re all proud of what we’ve built so far, so that can’t be it.)
I think there’s a few reasons why we’ve been productive:
1. The team is small
Like, tiny. So tiny that most folks would scoff at us. Two people making things and shipping 1% improvements to the app every week? How can that be effective? But small teams are often way better than larger teams because there’s less bureaucracy, fewer meetings, and more time for actual work. There’s no tickets. Why do you need tickets? Is this thing important? Great, do it now. If it’s not, kick it to later. You can only do one thing at any given time and most big teams try to juggle ten thousand projects and that’s really what slows em down. So focus is more important than anything else.
2. The hard part is building stuff, not making decisions
Decision making is what slows down most teams. The endless slide decks, the pitch to leadership, the lack of trust in what they’re building. They’ll go round and round in big circles trying to convince everyone in the entire company that this is the right thing to do. (I have done this before! Never again!) Or they’ll spend weeks debating about whether we should be doing ticket 1 first or ticket 2 and 99% of the time that doesn’t matter in the slightest.
This is the most obvious thing to say in the world, but: the hard work should never be the bureaucracy, it should be designing things and solving technical problems. If the hard work ain’t the hard work, ya gotta bounce. Don’t kill yourself trying to tell people that.
3. Feedback every day
On the design front, I try to break up my week into work days and feedback days. On work days, I’m grinding out iterations of a design or polishing the final one. On feedback days, I’m just talking to people, getting their opinions and notes on how things should work, what the real problem is. When I joined Retool and started doing this I realized that one thing that had held me back from making design decisions in the past is that I would hide my work, not share it with others. I would wait for the big unveiling and only get feedback once every couple of weeks and that...is a terrible way to design things.
If I just show everyone the mess all the time then they’ll guide me in the right direction. They’ll show me the way.
4. One endless meeting
This one is harder because I believe in it and also I strongly don’t. But working in the office again, where an engineer can just turn to me and say “hey, what should I do here” and we can riff on things together, it just saves us so much time. Plus it helps me think more deeply about the design when I get their eyes on something quickly. I’ve worked remote for years and some people are super effective about learning when to communicate in slack, when to setup a meeting to chat through things, but man. Just turning to someone and pointing and saying “that’s not right” is better for me, I think? I hate the commute but the work is easier.
Someone on the team called this “one endless meeting” and I think that’s right. We should always be talking, always be iterating and not working in isolation. But I think this has more to do with the communication style of individuals than some big important lesson to take away here.
Anyway, this is all simple stuff. But sometimes the most simple thing is the least obvious thing when everyone is telling you otherwise.