Efficient team collaboration is the secret sauce of successful teams. As a founder, you need to set up a process where you often get updates and provide feedback on everything your team does.
That will help you:
- keep the team aligned on the company vision
- stay on top of your roadmap and release on time
- measure progress & results of the team and each team member
You can go ahead and book a bunch of meetings with your team, and set up weekly 1-on-1s, but this alone is not going to help.
Engineers tend to overestimate their abilities. You might have bad hires and other obstacles that will push you back from creating the features you need to sell the product. Showing results is the best way to evaluate the abilities of your team and individual team members.
Knowing the progress is important to compare it against your product roadmap, make adjustments, and plan the next big launch. On the other side, you want to know what features and changes your team has done and actively provide feedback.
What is the best way to talk about progress? I believe this is a demo. A demo is the fastest and most simple way to show results. You can meet with your team for online demos or request them to record offline demos using tools like Loom or write updates.
Let’s explore these options.
Shift towards offline demos
I absolutely love the ‘Maker’s Schedule, Manager’s Schedule’ essay by PG of YC. If you haven’t read it, it’s here. It’s a good idea to keep at least half the day open to focus on working on some project or writing.
Offline demos keep you and your team’s calendars free. They save a lot of time, while you stay in the context of the project and can provide feedback and request changes.
Offline demos are also great when your team works in multiple time zones. Anyone can record a demo once some changes are ready and just continue working on the next changes. Others can come later and provide feedback on the work whenever they have time. There is no need to wait for someone and schedule meetings.
Demos bring transparency and encourage competition among your team members while giving flexibility and improving the work-life balance.
I don’t think 100% of your demos should be offline, because you still need to meet with your team, build relationships, and solve challenges one-on-one and together as a team. But shifting at least 50% of your demos offline will have a huge positive impact on the success of your startup.
Record 4 demos for each feature
tl;dr;
- Create a public channel for product discussions in Slack
- Ask everyone on your engineering team to record at least one demo per week to showcase their work.
The more advanced approach includes teaching your team how to use demos to improve the feedback loop and increase the quality of the product.
Below is a more advanced process that includes:
- Start every new feature from the prototype demo. Ask your team to build the quickest possible version of a feature. If the feature involves changing UI — ask to build just a UI prototype without even thinking about the rest. So you can share and actually see the way a certain feature will work, while you only spent 5% of your time.
- Ask engineers to publish a developer preview demo. This demo is published when the developer just finished the feature, but their code changes are not yet reviewed by other developers. That gives you the ability to request changes and adjustments before even getting the feature to the testing phase. Such demos also encourage your engineers to think about the process as a whole and find missing parts.
- Record a beta demo. Usually this happens when the feature is released to a test environment, tested and feedback from previous demos was already implemented. This is your last chance to provide feedback before the feature will be shown to the end users.
- When your feature is finally on production and available to users, it’s a good time to record the release demo. This demo is great to align all of your teams (support, marketing and other) on how the final version of the feature works and looks. A lot of feedback implemented as you were building the feature could have changed it a lot compared to the original plan.
If you did great work planning features and they’re small enough, all the demos above could be done in a week or even faster. They give you and the rest of your team visibility and a chance to provide feedback before too much work is done.
You might not use all demos and adjust the process according to your needs, but I am very sure that at least one demo per week can improve everything your company does.
Use written updates
In some cases, written updates are also efficient to improve your team collaboration. If structured well, they’ll help your team:
- better plan their work and request designs or changes from other teams required to complete work more quickly
- detect blockers and notify the responsible people
So you can ask your team to share three things every morning:
- Plan: Include 1-3 things each team member plans to work on today.
- Results: Share what team members completed yesterday and compare it against the plan.
- Blockers: Something that slows down or blocks you from completing the work.
Written updates should talk about specific things your team works on. If they get too generic (= no value for others) your team will stop writing them.
Written updates can help replace online daily standups a few times a week, but not completely. They’re also a great way to sync with team members who can’t attend standups.
Start with this simple plan
A demo is a great way to share results and I’ve seen many teams successfully using them to improve collaboration. Shifting offline could free up some time and improve work-life balance.
Multiple demos for every feature will improve quality and UX for end users. Written updates could be used to coordinate teams a few days a week or when they can’t attend the standup.
It might take time for you to find the right mix that works best for your product team, if you are still unsure — start from this:
- Request 1 offline demo from every engineer on the team
- Meet once a week to see the results and compare them against the plan
- Optionally: request offline updates on other days if you’re going to read them
Written by Andrew Orsich. Thanks to John McTavish for reading drafts of this.