You might be interested in the way we work if you’re a customer of ours and would like to learn about our approach and priorities when building and maintaining the plugin.
You might also be curious to see how a little remote team asynchronously coordinates and communicates to build software.
To start, let’s talk constraints
Constraints are the biggest influencer of the way we work. Understanding, being realistic of, and working within your constraints is key to working effectively.
Here are our constraints
We’re a small team (just two people), so we can’t work on a hundred different things at once.
We’re constantly juggling priorities – Growth, profitability, user experience, stability, and feature requests. Priorities constantly shift, and hence constant alignment is necessary.
We work remotely and in different timezones. Everything happens via Slack and Notion. The quality of our writing and communication matters a lot. This is most obvious when a week of work goes wasted due to poor communication.
To manage all of this, we work in cycles and releases.
Cycles, releases and the magic that lies between them
What are cycles?
Cycles last between 2-3 months and act as goal posts for what we want to achieve in the medium term.
Each cycle has a theme. For example, here’s the theme from a recent cycle “The theme for this cycle is to clean everything up, make small improvements, debug. Overall, we want to make our plugin more robust before we add on any big new features.”
Beyond the theme, there are very few definite things that go into a cycle.
At the start of each cycle, I go through our backlog and see what fits into the theme. Most items are phrased as questions and bets. This is because we don’t always know if something is achievable. So we include finding out as part of a cycle. For example, “Should we integrate Advanced Custom Fields? How?”
Cycles last as long as necessary, but not longer. Since each cycle is phrased as a question, it can take awhile to figure out the answer. But once we do, we quickly scope work from that answer, and try our best to build simply and launch fast.
What are releases?
Releases are, for the most part, what goes into each plugin update. They are the tangible work that happens inside of cycles.
There’s no limit to how many releases a cycle might have.
Releases typically last 1-2 weeks. Each release is scoped out clearly, although bug fixes are packaged into releases on an ad hoc basis when we find them.
Sometimes, this means one release can have multiple plugin updates because of urgent bug fixes.
The magic lies in the space between each release
If you imagine each cycle as a ladder, and releases as the rungs, you’ll have a good idea of how we work.
Counterintuitively, it’s the spaces between each rung that matter most. That’s where we figure stuff out, scope work, and learn the best solutions to a problem.
Examples of the work that happens between rungs include trawling through forums, reading tutorials, 2am epiphanies, and asking questions in Slack channels.
The importance of this work is why both cycles and releases don’t have fixed timelines. But, as I mention above, once the intangible firms up, we try to move quickly.
Unspoken philosophy behind our work
Just as the spaces between each rung are important, so too is the way we approach the plugin.
This unspoken philosophy is just as much a constraint as geography is, and it shapes the work that comes out of our business.
Hence, if you’re a customer of ours, it’s likely you’d be interested to learn more about our approach!
Do a few things well
Ahmed and I care very much about making a plugin that’s intuitive and high quality. We’d rather spend an extra couple of days creating rich text editing in a block rather than using AJAX if we can help it.
But we can’t make every single thing perfect every single time – after all, we’re running a business.
To balance this, we scope down. We’d rather build a handful of things well. Rather than many things poorly.
It gives me a panic attack every time a customer messages me to say something’s broken or not working. And we try our best to avoid it, without sacrificing speed.
Quick, but not rushed
We try to be quick – I’m constantly asking myself and Ahmed how long a feature should take, and de-scope quickly when it seems like things are going to drag on.
At the same time, I don’t cut deadlines in half just to push us to launch faster. Nor am I a fan of working 20 hours days to get something done on time.
Burn out is real, and it’s much better to work at a sustainable pace than rush, burn out and be unable to work for awhile.
Work closely with customers
Working closely with customers is another main tenet for us. I chat constantly with users via Slack, email, Twitter DMs, Telegram, and more. By initiating and maintaining these one-on-one relationships, I’m able to keep close tabs on what customers want from us and whether they’re satisfied with the product.
A lot of what we build is based off problems our customers want solved.
If you’re a customer, never hesitate to reach out.
Work within WordPress, not override it
Although not always possible, we try to work within the WordPress ecosystem, not override it. That is, we don’t try to take over your site and pretend like you’re no longer in WordPress when you use us.
We’re aware of the millions of different WordPress builds that exist and try to work in harmony with as many of them as possible. I’d love to snap my fingers and make us integrate and work perfectly with every plugin, theme and page builder out there.
Obviously that isn’t realistic, but I think it’s helpful for you to know that’s our starting perspective.
In contrast, there are lots of plugins whose sole purpose it is to make you forget you’re using “old, janky” WordPress behind the scenes. We have nothing against those plugins (and would love to integrate with them), but the point is, that’s not us!
Forward-looking
Largely, we try to work based on the future of WordPress. There are so many cool new features and opportunities with Gutenberg and we’re excited to make the most of all of them.
While it’s important to us to also be backward-compatible (see above philosophy about wanting to work withWordPress), we prioritise new features based on what will work best for modern WordPress sites.
Tech stack
We work, largely asynchronously, in Slack and Notion.
Notion
This might be a little hard to see, but each cycle is a new database in Notion. Inside, we are organised with the following groups:
- Not started
- In progress
- Now
- Blocked
- Review
- Completed
- Killed
This makes it easy to see where we are for any given task card.
As for what makes up a task card…
This is split in two ways: We have key features task cards and release task cards.
We try to avoid orphan tasks that don’t fall under a wider umbrella, as that quickly makes the Notion board very messy.
Above is an example of a release task card. Mostly, they consist of line items of what will go into a release. This makes it easy to see what to focus on ght now. It also makes changelogs quick to write. 😉
At the end of each item, there’s a View task link to a more detailed description of the task to be done.
This links to the feature task card. All updates and work for a specific feature is kept within its respective task card.
I’m not going to show you a screenshot of a feature task card as it’s very messy! 😅 But you can imagine it’s the minutiae of fixing tiny bugs and making endless small adjustments.
This way of working gives us quick snapshot answers to two constant questions:
- What’s our progress for this release?
- What needs to be done for this feature?
Slack
There’s not much to say about our Slack set up since it’s just the two of us. We talk in an ongoing DM to clarify stuff that’s in Notion. We also talk about our concerns and priorities for the cycle.
Things we’re bad at
There are two sides to every coin.
Every company that says “we move fast” is also saying “we ship lots of bugs”.
Every company that says “we work remotely” is also saying “we’re drowning in a sea of documentation”.
I’m not calling anyone out. This is just the reality of any choice you make. There are always good and bad consequences.
In our case, working remotely and asynchronously on Notion means a lot of freedom and a single well-documented place to view all our work. Those are the good things.
On the flip side, Notion gets messy very quickly, and we’re in a constant battle to prune and make sense of the mess.
In addition, some urgent bugs take time to fix because different timezones made us miss each other on Slack.
There’s plenty of bad stuff, I could go on. I mention them because I wish more people would. Painting rosy pictures is unrealistic. Each way of working is a result of the constraints and philosophies of the person who dreamt that process up. Our way of working isn’t perfect, but it works for us right now.
Wrapping up
I hope you enjoyed this behind-the-scenes look into the way we work. If you use Newsletter Glue, I hope it gives you an idea of the team that’s working on the plugin, our priorities, and how we approach each new feature.
I love nerding out on work processes. The style of work here is loosely based off Basecamp’s Shape Up and Melissa Perri’s Escaping the Build Trap.
As I mention above, there’s good and bad to every work process.
Ours is fairly simple right now as we’re just coordinating between two people, albeit in different parts of the world.
If you have suggestions on how we can improve our workflow, or if you’d simply like to share your own, please comment below. I’d love to hear from you.
