Forming, Storming, Norming and (Hopefully) Performing

One of the things that we’ve learned at TextNow is that as our business grows and scales we need to enable our team to scale alongside it. The latter, arguably can be more difficult than the former. There are many differing viewpoints on how organizations should be structured, like the Holacracy model practiced at Zappos, or the Open Allocation model practiced at Valve. Each model has merit to it, but we set out to find a model that worked specifically for our team at TextNow.

One year ago, our organization moved to what we call ‘the squad model’. It’s an engineering organizational structure that we’ve adapted based on Spotify’s views on engineering culture. I won’t go into the nitty gritty, as a lot of it is over the top for a company of our size, but some of their key motivations and values really resonated for us and pushed us to set our sights on what we next wanted to achieve — moving faster as a team, allowing growth for our engineers, and ultimately driving autonomy and trust throughout the team.

What Wasn’t Working

When TextNow was founded back in 2009 we were practically an overnight success, riding on the back of the iPod Touch popularity. We went from a handful of users to over 50,000 installs overnight on Christmas Day. This signaled to us that we had a product that people wanted and as a result we needed to build a team — FAST. At the time, we did what most startups do first — hired team members in each functional area of expertise. We built a small team of developers with Backend, iOS, Android, Web and QA experience (and we are still hiring!). Each team was responsible for delivering the best experience possible to our customers on their respective platform.

Our MVP offered free messaging to the United States and Canada. This was loved by our users, but research indicated that they wanted to not only be able to message their contacts, but call them as well. So, our product offering continued to grow as we added features such as: calling, in-app purchases for calling credit and ad removal, monthly and yearly subscription options for calling, etc. As a result, the demands placed on each of the teams grew. Mobile developers not only had to understand the product areas of each of our application (messaging, calling etc.) but they also had to understand all of the revenue levers our business relied on (advertisements, IAP and subscriptions). Holding a mental map of how everything worked together became increasingly complex over time.

In addition to the product complexity, delivering new features and coordinating releases between teams became increasingly difficult. For the majority of our product features, it required coordination between multiple teams to be able to ship to the end user. As our team started to grow past 20 engineers, this became almost a full time job to coordinate ‘who is working on what’ every sprint. Something had to change.

Defining Success

First, we needed to know how we were going to measure success. We already knew the values we cared about improving — moving faster, growth for our engineers as the business grows, and autonomy/trust.

Moving Faster

We measured ‘moving faster’ in a quantitative way using sprints, story points, features delivered and other agile methodologies. We also looked at it from a qualitative perspective inside the team and out. Does the team feel like we’re moving faster? Are there less roadblocks in your way?

Growth

At TextNow, we want growth-minded individuals. Not just in terms of the business, but also in terms of their career. Growth in one’s career can mean a number of things, but it can be generalized into taking on more responsibility. The metrics we used to measure our ability to drive engineer growth was the number of positions we created that contained additional responsibility as well as quantifying how many of those positions we filled through deserved internal promotion. Taking this approach has enabled us to create opportunities for our team to take on additional responsibility in both a people and technical capacity as well as measure our success.

Our philosophy is to provide engineers with all the tools they need to deliver the best product to the customer.

Autonomy & Trust

This measurement could have also rolled into the “Moving Faster” section, however, we wanted to call it out separately as scaling autonomy and trust across our organization is a value we hold dearly. Our philosophy is to provide engineers with all the tools they need to deliver the best product to the customer. That means not only the ability to ship features and bug fixes to customers, but also to be able to monitor and analyze how their feature is performing in production and the ability to decide whether or not changes are needed.

The First Iteration

Early into the planning of this structure one question became apparent: how are we going to tackle technical issues that do not necessarily directly impact the customer? During the brainstorming process, we realized that our teams actually had two types of ‘customers’. The traditional customer who uses the platform for the value it provides to them, and our own developers who deliver the value to the customer. In order to have teams hyper-optimized towards improving the overall user experience, we needed to have teams dedicated to improving the developer experience. The result was the implementation of Feature Teams and Support Teams. The former team being focused on the traditional customer, and the latter on the developer.

Lastly, we wanted to make sure that each team understood the goal of what they were trying to achieve. We communicated this by providing ‘missions’ about how we define success for each team. Each mission would be at most a few succinct sentences about the objective they were trying to achieve.This is what our first kick at the can looked like (teams in bold followed by their mission):

Feature Teams:

Calling & Messaging Reliability — Maximize TextNow’s calling and messaging reliability and quality.

‍Growth — Optimize user and revenue growth through maximizing user acquisition, minimizing churn, and maximizing user revenue.

‍Customer Experience — Give TextNow users the best quality user experience possible.

Support Teams:

Client Infrastructure — Maximize client developer productivity and efficiency. Maximize client code deployment reliability and efficiency.

‍General Infrastructure — Maximize back-end developer productivity and efficiency. Maximize back-end code deployment reliability and efficiency. Minimize back-end infrastructure capital and operational costs.

‍Wireless Operations — Support the operations of our wireless business. Maximize efficiency and minimize cost of our wireless business operations.

Any time you make an organizational change, you need to allow for the new team(s) to become acquainted with one each other and figure out their roles and their place among the team. We needed time to let the teams adjust to their new roles, and hopefully within a short time frame, they would start performing better than the model we originally had. We would measure the team over the next few months on the criteria we defined to determine if we were successful in our new structure or not.

Analyzing the Results

Over the next few months, we saw measurable improvement. There were less team inter-dependencies and they were able to drive (mostly) independent roadmaps. Teams were able to define the operational process that worked the best for them, whether that was Kanban, Scrum, or some hybrid approach. There were few rules on actual process as we wanted it to naturally form, rather than prematurely optimizing with our preconceived notion of what the process should be. We measured the productivity and ability to move fast from both an individual/team satisfaction component as well as the ability to ship on time and hit key deliverables that we as a business set. Multiple squads shipped flagship features throughout the year such as our Elastic Calling component. As well, this format naturally opened up opportunities for people leadership across each of the squads and technical leadership on different component platforms, most of which we filled internally (but we have some openings!).

‍This was not without it’s challenges though. In most cases, each teams mission clearly defined who was accountable for what, although there were some gaps. For a given product area, there were valid arguments on both sides as to which squads’ ultimate responsibility it was. We resolved these conflicts by clearly drawing a line in the sand and assigning accountability to a specific team.

Lessons Learned and Moving Forward

It has been over a year since we’ve switched from a functional structured model to this new squad-oriented model. Is it absolutely perfect? Definitely not. But it’s huge improvement over what we had before. We still very much believe in the idea, even for a company at our size of 40 engineers. It has allowed us to move quicker and grow the company to achieve our most successful year ever as a business. As time has passed, the structure outlined above has changed significantly, but the framework and values we initially set out to achieved remain constant. The biggest takeaway we’ve had over the past year is that not only did we need to be nimble and iterate on our product often in order to provide the best experience possible, but we also needed to apply these same principles to our organization. We are most successful when we empower our team to deliver on that amazing experience our customers expect.