We’ve previously shared about how we work as a remote team and about our product process. We even took a look at how we built a bot to help us collaborate and communicate with one another more efficiently. I wanted to dive deeper into how we’ve managed expectations and communications as a distributed team and an early-stage startup.
Being a young startup with a lean team, there’s a lot that can go wrong. I’ve learned some hard lessons that surely won’t be my last. But I’m proud of where we are now and how we’ve gotten here. A lot of it can be credited to hiring people who’ve worked remotely and with early-stage companies in the past. That was critical for us at this stage; we needed to be able to hit the ground running.
However, we’ve still designed our own, new processes that work for us as a unique team. Here’s a look at the processes we’ve built to be an open, transparent, and efficient team.
I find that it’s best to keep a streamlined and optimized approach to everything in life and business, using as few (high quality) tools as possible. (I’ve been on a bit of a Marie Kondo kick lately.) Finding the right mix of a few or a handful of channels takes a bit of trial and error.
We don’t want to have meetings for the sake of meetings but we also don’t want long, drawn-out Slack conversations. Sometimes it’s faster to pick up the phone or have a quick video meeting. Below, I break down how this works with different types of team members. First, here’s a quick overview of our go-to channels:
We already detailed how we communicate as a product team in this article. In a nutshell, we rely on quick, 10-15-minute daily video syncs to ensure we’re on the same page as a team and that everyone knows what we’re working on together and individually.
We also have weekly “lock plan” meetings where we go through our pipeline on Github. This is when we tackle any roadblocks, assign tasks, and prioritize what needs to be done first. These meetings help us keep our daily syncs short and to the point.
Everything the entire team does is tracked on Github using Zenhub boards. Expectations are kept super clear when everyone can see exactly what everyone is working on and its status. This may sound like a simple process but often times, simple is best.
Our core, full-time team is all technical (product engineers), while our marketing and accounting team members are currently contracted. Although they’re not full-time, they’re still very much a part of the team. But that doesn’t mean they have to be at every stand-up or daily sync.
Rather, they share weekly status updates with the team on Slack detailing what they’re working on and what they accomplished the previous week. They also use our #general channel to share any content they’ve published or relevant work to the team.
They also manage their tasks on Github. This helps the rest of the team understand why we’re working with someone and how their individual goals align with our broader vision. We’re lucky to have a product team who enjoy contributing to our blog as well! They’ll jump in our editorial calendar and add content ideas they can collaborate with our content lead on.
And our contractors can see what the technical team is working on at any given point, which helps with generating content ideas, including things like product updates for our newsletter.
I have bi-weekly calls with each contractor to discuss the status of current and upcoming projects. We use this time to look at analytics, brainstorm new ideas, and catch up personally as well. It’s important for them to know that I and we as a team are invested in them as people.
I like to have a clearly defined scope of work for all team members but especially short-term contractors. Before agreeing to work together, I ask potential contractors to outline a basic three-six month plan to ensure they’re aligned with our goals and expectations.
However, we are a young company and things change. It’s equally important to make this clear up front. I clearly communicate this with our contractors and ensure they’re up for that type of working environment. We use our bi-weekly syncs to see if what we’re doing is working or not and to discuss any experiments if it’s not.
The same goes for full-time hires.
After team members are onboard, we create an action plan together. Each team member owns their own tasks and plan of action. They create it and I weigh in until we have something aligned with our priority pipeline and broader company goals. We break this plan into tasks and put them into… you guessed it… Github. During our weekly 1:1s, we cross-check with these action plans to ensure they’re on track and if there’s anything I can do to set them up for success.
No one is perfect and every young startup has its own special set of challenges. We feel pretty good about how we communicate and collaborate as a team but that doesn’t mean we don’t run across a few snags here and there.
Here are the ones we’re facing now.
Although everything is in Github, looking at our product boards can be a little unclear without context for a non-technical person. And sometimes our contractors can’t make our daily syncs due to time zone conflicts. We could be a bit better at re-capping our individual and team priorities as they relate to our product pipeline on Slack after each quick daily sync. It’d probably be best to have one point person for this to save time.
We’re lucky to have a passionate team who cares about everything we do. That means they care about how our brand communicates with our audience. We want our entire team to align with and buy into our marketing efforts. Not everyone is going to contribute to the blog all the time, but we do like to tap the talent and expertise we have to share with our readers. For us, this is a matter of answering “why?” for every piece of content. So far, we’re doing ok in that department.
On the flip side, because we’re still growing an audience, we ask the entire team to share every article we publish, which is typically every week. This became a lot of asks, fast. We haven’t found a solution yet but hope to ease up on them as we continue to grow.
Again, because we’re a small team, sharing our vision openly has come easy. It’s just a matter of sharing it on our weekly and 1:1 calls. But that’s not scalable. I know that as we grow, I’ll need to keep our vision front and center for all team members and stakeholders. I and the rest of our team leaders will need to make a habit out of tying every objective to our larger vision. If you have any suggestions on how to do this, I’m all ears!
Sharing user/customer feedback is important for any business, but especially for an early-stage startup like waldo. But because we’re so busy building the product, sharing user feedback on a regular basis is tough. Worst case scenario, we’ll end up building a product our users didn’t ask for. If you’re sitting on any secrets (workflows, tools) on how to make this a part of our product process, I’d love to know.
When you’re a small team, your role is always fluid. It has to be! The (overused) “many hats” concept definitely applies. For us, it often means that team members have to put their customer support hat on and make sure that our customers get the help they need. But team members don’t always have the time, training, or availability to do this. But the most important thing for us is always to communicate to the customers that we’re here and we’re aware, even if we can’t help right this second.
Juggling an evolving business, a growing team, and a product in beta isn’t always easy. I’ve found that the clearer I communicate and set expectations early on, the better off the entire team is. The best advice I can give to fellow early-stage founders is to hire people you trust and overcommunicate until your team can finish your sentences for you.