5 Ways Paperform Optimizes for a Remote Development Life-Cycle

Let’s face it: the majority of the product development teams nowadays collaborate remotely, one way or another. Some teams are “hybrid” (partially remote, and partially on-site), others are fully distributed.

And while a lot has been said and written about remote software development collaboration, the devil is always in the details and little things that make the teams “tick”.

For this post, we asked Dean McPherson, co-founder and CTO at Paperform, to share a few tactics and principles that he and his team leverage to stay productive in a remote environment.

Dean & Diony McPherson started Paperform in 2016 with a mission of helping people build bespoke online forms and automate business ops without writing a line of code. Almost 6 years later, Paperform’s a successful bootstrapped business, with a globally distributed team of 18.

Dean & Diony McPherson

On the product end, what started off as a simple form builder and a single developer (Dean), is now a Swiss Army Knife for SMB owners and a well-oiled team that consists of developers, a designer, and technical customer support specialists.

How does Paperform team optimize for remote software development lifecycle? Let’s find out.

6 Week Cycles

Dean says that having an explicit development cycle allows Paperform’s team to plan work in a structured way. This in turn improves their ability to collaborate and meet deadlines.

The whole development cycle consists of six weeks. This is long enough to allow significant work to be completed, but short enough to let the team respond to immediate user and market needs.

Weeks one to four are the primary feature development cycle. Weeks five and six and for planning, experimenting, refactoring, and improving tooling. Urgent bugs are fixed on an ongoing basis.

The full cycle works the following way:

• Week 1: feature development begins. By this time, the features should have already been spec’ed, with initial experimentation happening to determine how to approach building them.
• Week 2: hands-on feature development.
• Week 3: feature lock. By this point, the functionality should be built and ready for a final review and testing.
• Week 4: release.
• Weeks 5 & 6: planning, refactoring and bug fix phase.

At Paperform, the developers are usually split into pairs for a more efficient development workflow, with clear roles assigned to each. Internally, these roles are broadly called “Feature” and “Support” and primarily cover weeks one to four in the cycle.

“Feature role” covers the following responsibilities:

1. Primary feature development for the cycle. The feature developer is focused on new feature development and has ownership of the implementation.
2. Reviewing bug fixes for the support developer for release and being available to discuss technical or design challenges with bug fixes.
3. Being aware of places where the support developer can jump in and help push the feature development along. Reaching out directly when help is required.

“Support role”, on the other hand, is focused on:

1. Tech support escalations, maintenance, urgent bug fixes, as well as code review and releases.
2. Customer success will escalate tech issues to this developer.
3. Triage bug reports and minor features in Jira, fixing urgent issues in each week’s release.
4. Code review for new feature code and inclusion of new code in each weeks release where appropriate.
5. Assisting the feature developer where possible. This might include working on part of the implementation, writing tests, doing QA, jumping on calls to discuss a technical issue or design challenge.

Very importantly, the process gives Paperform’s product team enough visibility into the future for wider team collaboration (announcements, PR, blog posts).

Dean also says that down the road the team might consider shortening the cycle to 5 weeks, if the performance and other circumstances allow for it.

Default Async

Paperform’s philosophy (and the reality of work) is that coding is a deep work exercise. Thus, outside of scheduled meetings, the team members aren’t expected to be available for calls or reply immediately.

All the meetings are pre-planned, with dates and times set in a way that wouldn’t break the contributors’ days.

Group Meetings

Even though the group meetings aren’t frequent at Paperform’s product team, they are essential for staying on the same page and improving team collaboration. The team meets once a week to catch up on active projects, group solve problems, and make minor decisions.

There are also additional ad-hoc meetings during weeks 5 and 6 of the cycle that help with planning.

1-1 Meetings

Unlike many companies that have a set schedule for 1-1 meetings, Paperform schedules them as frequently (or as rarely) as needed.

Most weeks 1-1 meetings are just one or two additional calls. These are generally scheduled in advance, unless everyone is immediately responsive and available.

Dean personally encourages these over writing very detailed messaging back and forth. A 10-minute huddle is way more productive than typing back and forth asynchronously.

Tech Support Shifts

Paperform has dedicated Technical Support members who bear the brunt of the support. They talk to customers, solve problems, fix minor bugs, and even sometimes build dedicated on-demand customer solutions.

However, there are still inevitable edge cases and bugs which require being escalated to a developer.

To make sure that there’s always a developer who’s ready to jump on fixing bugs, Paperform’s team takes “on duty” turns throughout the development cycle. This ensures a smooth and predictable work-schedule for the whole team and provides the necessary support to the customer success department.

Key Learnings

Here are the key things that we’ve learned from Dean and Paperform’s team about their remote development process:

1. 6 week cycles: long enough to get work done, but short enough to respond to user and market needs.
2. Default async and well-planned meetings help stay focused and yet collaborate tightly within the team.
3. Taking turns for tech support distributes the load equally among the team members, while allowing them to interact with the customers.

How is your team managing this? Got any insights to share? Let us know!

And read our comprehensive software development life cycle guide to learn more.