Accelerating

This post references specific challenges that are unique to designing and building great software for businesses that depend on us to run day-to-day, but perhaps some of the learnings within can be referenced for other industries.

I love people. I love helping people. I love helping people do better at work. In order to help with a higher level of success, I’ve learned that I need to be able to communicate clearly, effectively, and without misinterpretation. As a leader of a team, department, product-line or organization, I’ve also learned that I’m 100% responsible when there are communication missteps.

Sometimes, there are fundamental issues in the way an organization is, well, organized, that prevent people from achieving optimal communication; and helping each other. When this happens, leaders can feel those issues, team members live them day-to-day, and unfortunately, customers often experience them first-hand. Simply put, things get a bit fucked up.

For most software companies, departments and teams are structured for convenience to match product lines or perhaps functional areas. For example, “iOS App Team” and “Web Engineering team” or “Version 1” and “Version 2” teams. Methodologies like scrum, kanban, agile and lean are overlaid on top in hopes to help with information flow and execution. Here’s an example:

V1 /V2 = separate product lines

This works well for some companies, while some others get lucky and it ends up working; against all odds. However, I’ve come to realize that most organizations tweak too much of those original methodologies for convenience and never achieve adequate velocity. I’ve actually come to learn these misinterpretations to be known as fauxscrum.

Not only does execution suffer in the above model, but team members often blame all things (including each other) for all reasons and never get to the bottom of the problem together because they are focused in the business versus on the business. You’ll likely have some or many of the CEO goals miss their deadlines, career path and cross-learning opportunities need to be improved or lack altogether and there’s some misalignment at various levels within the organization.

You’ll know if you’re stuck in the above cycle when communication becomes an issue, nobody truly understands why they’re working on a project, and team burnout becomes reality. Worse yet, the wrong things are getting prioritized because there’s just too much going on. Unfortunately, even Fortune 500 organizations will often part ways with good people during all of this.

Kevin Sproles and I took a step back after visiting with lots of amazing companies, reading about the perfect ways companies are organized, and talking to great leaders in the industry. The answer actually started brewing after a call with one of our board members, Joseph Essas, who articulated some of the ways he’s historically focused product and engineering teams around a metric. Here’s a summary about what he does, very well.

We then figured out that some of the greatest startups we’ve heard of participated in an accelerator to catapult their existence (Y Combinator, Mucker Lab, 500 Startups, etc.). Founders learned, and thrived, within these intense and immersive programs and came out stronger as a result. So what if we could combine a single-metric focus with an accelerator inside Volusion?

Introducing Volusion Accelerators

An accelerator is a cross-functional team (Product, Design, Engineering, Marketing, Customers, Advisors) with a mission to move a single metric. To define the core concepts behind our accelerators, we had to articulate what that hybrid model (metric focus + startup accelerator mindset) would look like. We ultimately formalized it to three parts (Goals, Rules of Engagement, and Measuring Success).

Most important, all of it had to match our Culture Code.

Goals

1. Operational alignment to the CEO’s goals.
2. Career path and personal growth for everyone.
3. High degree of learning and cross-learning.

Rules of Engagement

1. Small teams: We know small teams work. So each accelerator team will consist of 1 Product Manager, 1 Designer, 2–3 Engineers, 2–3 Advisors, ∞ Customers (absolutely critical).
2. Founder mentality: Everyone cuts through bureaucracy. No barriers, no impediments.
3. One metric to impact: Could be for a quarter, could be for the year. This creates focus.
4. Customer > Company > Team > Individual: This is our formula for keeping true to our culture and the mission. We take a customer-first approach in everything we do and put the team’s needs before an individual’s needs.
5. Test everything, and early (TEE): Customer want’s an Instagram integration? We do it manually, test the results, then automate, and test the results again. This is how we know we are building the right things.

Measuring Success

We care about impact. Impact is a combination of the accelerator’s ability to positively impact a metric, and the learnings they have along the way. Sometimes, the lessons learned are even more valuable. Here is the high-level formula and a sample dashboard:

Each accelerator is built around the team, they decide the backlog, they decide the fun stuff of how to work, how to organize themselves, what tools to use, and what name they prefer to go by. The metric is tied to the CEO’s goals, and every Friday, all accelerator leads meet to go through the metrics together and share tests, metric impact, lessons learned, impediments and wins.

Here’s a few of the over dozen accelerators we have at Volusion, each one having their own single-focus and team-defined backlog towards achieving success:

It’s our own way of working, but we’re ready to learn and improve it all with time and testing. While it’s still in early stages, we are already seeing great success and overall upward trending team engagement. We’ve also seen a shift from code-first to customer-first. In fact, here’s a memo I wrote to the accelerators after the first week kickoff:

I’m very excited for the future and the positive impact individuals will experience first-hand. Also need to say thank you to all those that came before us to learn about different ways to challenge organization design and methodologies to help deliver great software to customers.