How TeamBuildr Builds Software

Intro

Hi everyone, Kyle Miller here, VP of Engineering at TeamBuildr!

Over the past few years, we’ve grown from a tight-knit team of fewer than 10 to an incredible group of over 40. Along the way, we’ve honed our craft in building effective and efficient software. Today, I’m thrilled to pull back the curtain and share how we make it happen!

About Us

TeamBuildr is a bootstrapped software company in the strength & conditioning space. We are a small team, and we do not have any investors to report to.

The processes that we’ve put in place are tailored to those constraints (or lack thereof 🙂).

Inspiration

Our development process is largely inspired by Basecamp’s Shape Up methodology. Basecamp is a similar company in that they are also a small software business with no investors.

If you are curious about learning more about Basecamp, below are a few resources that we have used as inspiration:

• Shape Up book
• REWORK book

One of the key insights that we’ve leaned on from Shape Up is the concept of “Appetites vs. Estimates”.

Software teams are notoriously bad at estimating the amount of time and effort a project will take, as unknown challenges are bound to arise along the way. Instead of using estimates, we aim to use appetites instead.

How much time and energy do we want to devote to this project? As opposed to, “How long do we think this will take?” This means that the scope of the project may change along the way, to complete the project in the budgeted timeframe.

Now - not every project can operate from that lens. If we are rebuilding an old, legacy page into a new framework, then the scope of the project is likely fixed. When scope is fixed, it is more difficult to operate from the “Appetites vs. Estimates” mindset.

However, we do our best to use this approach when it is appropriate.

Core Beliefs

Over the years, we have been fortunate enough to pick and choose processes that work best for us. We aren’t beholden to a single approach, and we are always willing to change our minds.

We are firm believers in trying something, evaluating if it worked as intended for our team, and then deciding if we should implement it moving forward.

There is a quote that sums this up beautifully - “Open to anything, attached to nothing.” We aim to meet new ideas with curiosity and willingness to change.

The following is how we currently build software, but it could change in a year. It probably will change! That’s what makes it so fun to be apart of this team.

8 Week Development Cycles

All of the work on our product takes place in 8-week chunks. We call these “development cycles”. This 8-week timeframe orients our team and sets a boundary for all of the work we do.

As much as possible, we aim to keep the development team focused for the entire 8 weeks, without interruption. We believe in giving everyone the necessary time and space to complete their work. Once we’ve decided on a set of projects for the next 8 weeks, that’s all we’ll be working on.

Bugs do arise and we do have a dedicated support rotation on the development team. However, the goal is a relatively interruption-free 8 weeks for the team.

We also don’t believe in breaking up the work into 2 week “sprints”, and we don’t create hundreds of “stories” before starting on the work.

While the term “sprint” is commonly used in the software industry, it sounds unappealing and unsustainable to us. Why are we sprinting towards something? That puts an inherent, unspoken pressure on the team to rush and to go as fast as possible.

At TeamBuildr, we aren’t in the business of going as fast as possible. We want to move at a consistent, sustainable pace.

For this reason, we call it a cycle. 8 week cycles, where the team is responsible for delivering a complete project that we can ship to customers.

Planning Process

Before a development cycle begins, we run a process to plan all of the work that we’ll complete during the cycle.

The planning process takes place while the current cycle is in progress, and it typically takes a full 8 weeks.

Generating Ideas

The first step of the planning process is to generate project ideas. We call these ideas a “pitch”. Both departments in the company - dev (development) and rev (revenue - sales, marketing, customer support) have input into the list of pitches.

The VP of Engineering and VP of Operations are responsible for sourcing ideas from their respective teams. Additionally, both co-founders and our Product Manager/Head of Sport Science have strong input in this phase.

The idea here is to collect input from those that are closest to our customers (customer support, sales, marketing) on new features and product updates, as well as input from the development team on technical debt and code-related changes that need to be prioritized.

For the revenue team, a pitch might look like any of the following:

• New feature - our customer support team might notice a lot of requests for a specific feature, and the sales team may validate that it would help with product sales.
• Quality of life update - these would be smaller updates to an existing feature. Things like adding a new filter on a page, or expanding date ranges that a report is available for.
• Product pain points - our customer support team may notice frequent pain points in the software that need to be addressed. If these pain points aren’t necessarily bugs, then they belong in a pitch as input into a development cycle.
• Internal tools - we have a set of tools for our customer support and sales team to perform recurring, internal tasks. We call this our “Admin Panel”. If an update is needed for the admin panel, it also belongs in a pitch.

For the development team, a pitch might look like:

• Updating a feature to be more performant - we have a suite of tools that we use to track feature performance. We track metrics like server response times, server load, and database load. If we notice a feature isn’t performing up to our standard, then we need to fix whatever is causing the underlying issue. This has a direct impact on our customers and ensures they can continue to experience a delightful product. We recently did this with our Wearables integration!
• Code refactors - sometimes a feature might be working just fine, but our team isn’t happy about how the underlying code is written. It might be difficult to read, difficult to understand, and difficult to work with if we need to update the feature. Code standards and conventions change over the years, resulting in “technical debt”. We are firm believers in carving out space for technical debt. If our developers say that a given feature is hard to maintain, then we need to make the time to refactor its code.
• Architecture & infrastructure updates - outside of writing the code for a feature, we also have a set of tools to deploy and host the code within our testing and production environments. This is generally referred to as the infrastructure of the code. Similar to a code refactor, we may need to update the infrastructure that our code uses. There may be a more efficient way of deploying and hosting our code which could cut down on engineering costs and deployment time, while also increasing developer happiness (easier for the team to work with).
• Security updates - TeamBuildr is ISO 270001 compliant, and as a result, we are always evaluating the security of our applications and updating any security concerns as needed.

This idea-generation phase takes place during the first 2 weeks of a development cycle.

Decision Table

The next step is to decide which ideas we want to move forward. We can’t do everything, so we need to strategically consider what is most important to do right now.

We only get a handful of chances to do this per year, so the decision table is where the direction of the company and its products are shaped.

There are 5 players involved in this process:

• Both co-founders (one represents the dev team, one represents the rev team)
• VP of Engineering
• VP of Operations
• Product Manager & Head of Sport Science

This group is responsible for taking all of the ideas in the previous phase, carefully considering each one, poking holes in them, playing devil’s advocate - and ultimately deciding on what projects the team will tackle next.

The beauty in this cyclical approach is that if we bet on something that doesn’t pan out, we’ll have a whole new set of projects to bet on in 8 weeks.

Project Documentation

Once the list of projects is solidified, it’s time to prepare them for the development team.

We create a project document or “write-up” for each project. This write-up is intended to house all of the information that the team needs to complete the project.

Before we start on the write-up, we identify two key players - a “product owner” and a “project planner”.

The project planner is usually one of the following team members - VP of Engineering, Head of Product, or our Software Engineering Manager. This is typically someone who is familiar with how we write our project documents and has enough technical background to understand what is feasible for the team to accomplish.

The product owner is responsible for answering scope questions. This is a dedicated person to go to when asking the following types of questions:

• “How should this thing behave?”
• “What should it do?”
• “What shouldn’t it do?”

Our developers will often lean on the product owner during development for any clarifying questions on scope and intended behavior.

Once we identify who will wear those two hats for the given project, it’s time to create the document.

Each project document includes:

• Description and overview of the project - what are we trying to build here? What are the constraints? What’s in-bounds vs. out of bounds, and what are the boundaries and guard rails for the project? Why are we doing this and why is important to the business? An individual working on the project should be able to read the description and clearly understand what the desired outcomes are.
• Wireframes and rough sketches - the product owner and project planner will sit together and create rough outlines and diagrams describing what the feature needs to do. Shape Up refers to this process as “breadboarding”.
• Formal requirements - a detailed list of written requirements for the given project. What needs to be true for the project to be completed successfully?
• Technical details - what technical information and context does the development team need to know before they begin? Is there any code that is related to the project that already exists that we can reuse? Are there any ideas about how the code should be structured and organized? We don’t prescribe an exact technical solution for the team, but we do call out anything that is important to know ahead of time.
• Designs - if the project is user-facing, then it will require designs from our Product Design team. Our product design team does a great job of mapping requirements into high-fidelity designs for our engineers before the project begins. They have a separate design process - put together by our Head of Product - that we’ll dive into in a future article.
• Testing scenarios - our QA team will create a list of scenarios that they’ll need to test before the project launches. Oftentimes, this list is populated more thoroughly once development on the project begins.
• Marketing material - if the project is a feature that we are going to market, then we will need a section for any marketing copy and verbiage to be used throughout the project. For instance - what will the feature be called? Are there any marketing videos or copy needed? What screenshots and screen recordings are needed for the marketing team?
• Key performance metrics - what metrics and KPIs do we want to track as part of this feature to measure its usage and success? We will call these out ahead of time and loop in the necessary players to make sure tracking is enabled for the relevant metrics.

Putting together a high-quality project document takes about 5-6 weeks from start to finish.

Given that we put significant time and energy into the planning phase, one can see that it’s difficult to change course last minute before a development cycle begins. The result of a last-minute change is the planning team having to scramble accordingly, and a potentially unvetted project being handed to the development team.

It can be easy to fall into the trap of simply saying, “We need to go build this new feature” without considering all of its nuances. What does it actually mean for our product to have that feature? Those are the types of questions we are trying to answer here.

A team member should be able to say, “Ah, I understand what we’re trying to do here and I know what to do if I had to start building this tomorrow.”

Once the documents are completed, it’s time to kick off the project with the developers who will be responsible for doing the work in the next 8-week cycle.

Development Begins

At the start of every development cycle, we meet with each team that will be responsible for a given project. Depending on the project, there are anywhere between 1-3 developers, 1 designer, and 1 QA Engineer assigned to a given project.

We’ll read through the project document, designs, and requirements, and talk about any questions or concerns the team may have.

After the project is kicked off, the developers are sent on their way and are responsible for completing the project within the budgeted timeframe.

Communication Channels

Throughout the course of a project, it is important to have effective communication channels. All of the communication on a project takes place in a dedicated Slack channel. This includes coding questions, requirement questions, design questions, or marketing questions.

The developers, designers, QA engineers, managers, and stakeholders are all invited to the Slack channel. This central communication channel gives everyone shared visibility into the project.

Check Ins & Check Outs

Furthermore, each project team is required to have a weekly call together at the start of the week to check in on progress and roadblocks. At the end of the week, each individual is required to complete a written check-out describing what they accomplished during the week, any struggles they had, and what they plan on accomplishing the following week. This serves as input into the following week’s group check-in, and is also a great chance for individual team members to reflect on their week as it ends.

Project Launch

As the project inches closer to completion and QA gives its stamp of approval, we will start planning for a launch. This requires efficient communication with our revenue team (sales, marketing, and customer support) to ensure that all parties feel prepared for the launch.

Our Head of Product creates a handoff document for each project, and this contains all of the details that the revenue team needs to support the feature.

From there, our revenue team will review the documentation, test the feature, and make sure they are prepared to sell and support the feature.

As you can see at this point, a product update involves all departments in the company! There are no silos in our company. We need everyone to be on board and on the same page for an update to go out successfully.

Our development team also needs to prepare for the launch. Are we only launching to a subset of customers? Are we launching on the web? Are we launching on our mobile apps? Does this include breaking changes? Do any updates need to go out ahead of this one? We need to consider all of these questions before launching.

While on the surface it can seem simple to just push a button and launch a new feature, it requires careful and deliberate coordination across all departments in the company to be successful.

The Cycle Continues

As projects launch at the end of a development cycle, the planning team will be completing its next planning phase and getting ready to start the whole cycle over again!

In Case You Missed It

I wanted to introduce this segment as a way to highlight updates and features that may not necessarily make it onto social media or are BIG launches - but are nonetheless important quality-of-life updates to the software. 

What’s Next?

I hope this provided insight into how we work at TeamBuildr, and what all goes into a project from start to finish. It has taken years of evolving our process to reach this point, and as noted earlier, I’m sure we will continue to tweak the processes I’ve described today.