How Olark Overhauled its Communications to Preserve Autonomy

THIS LESSON BROUGHT TO YOU BY...


As a team of four co-founders, we started as a democracy of sorts. Like Rob said in Lesson 1, the good old days when two pizzas, or in our case homebaked bread and hummus, could feed our entire company :)

We wanted Olark to be an organization that would foster a sense of autonomy and shared ownership. Inspired by organizations like Github and Valve, we relied on flat structure through five, 10, even 20 Olarkers.

 

 

 

 

 

 

 

 

 

 

 

Something surprising happened though.

Even as we added teammates and gained more diverse skillsets, we noticed a few projects slowing down. Some projects failed to start at all, and many others staffed with just a single Olarker struggling mightily to move the needle.

When we realized this, I felt a bit disappointed and at a loss. Flat structure empowered us in the past. Why were we suddenly slowing down, especially with such a promising team?

In this week's CommunicateBetter.io lesson, I'd like to share how we've overhauled our communication system to emphasize productivity and autonomy as we shed our adherence to "flat" structure.

 

 

 

 

 

 

Why flat in the first place?

We first re-examined why we were pursuing flat structure in the first place.

 

"The single worst reason to continue doing something is because you did it before."

William Allen, Director of Strategy and Operations, Behance.

 

It came down to a few things:

 

  • Bottom-up ideas - We wanted good ideas to flow from many places besides the top.
  • Direct communication - We wanted very few layers between any two collaborating Olarkers.
  • High autonomy - We wanted to give Olarkers the freedom to rally teammates and "Make It Happen."

‚Äč

All good intentions right? Sure, but we started discovering issues cropping up as our team grew: our flat structure was turning into lack of structure.

With a better understanding of our goals, we took the following steps to begin mindfully organizing ourselves to do a better job actually achieving these intentions.


How we now facilitate communication


Make ideas 'concrete'

Bottom-up ideas are great because everyone can suggest a project at any time. But with an ever growing number of communication channels in our organization, it became easy to lose a good idea amidst emails, Google Docs, JIRA, Hipchat, Skype and more.

So, to help Olarkers capture and clearly articulate their ideas, we developed a basic information gathering template for any proposal. Have an idea? Fill out a brief Q&A style proposal.

The current template asks for the following information:

What is the problem? Describe what is broken, or what opportunity you're seeing.
Why should we solve this now? Gather evidence and feedback to motivate us.
Who are the stakeholders? Identify the "right" customers and Olarkers for input.
How might we solve the problem? Sketch out possible solutions.

Here's what our proposal "template" looks like in Trello:


 

 

 

 

 

 

 

Key Takeaway: Formalize a process for capturing good ideas.

 

Systematize idea flow

With a means for capturing ideas, we then created a systematic approach to turning ideas into projects.

We created a Trello board. Within that board, each idea gets a card containing the aforementioned Q&A, and then moves from left to right across columns that represent the different phases of a project.

Our current phases look like this:

  1. Articulating Problem. Agreeing on the root problem and motivations.
  2. Exploring Solutions. Brainstorming a solution to that problem.
  3. Resourcing. Waiting for Olarkers with relevant skillsets to join the project team.
  4. Doing. Project team actively working.
  5. Reflecting. Project done. Collecting feedback on both results and process.
  6. Done. Time to celebrate!

Here's what it looks like in practice:


 

 

 

 

 

 

 

Key Takeaway: Create a clear, visual path for turning ideas into projects into completed projects.

 

Identify 'experts' who can help

Although we strove to minimize "vertical" layers of hierarchy between Olarkers, our growing team made it harder to minimize "horizontal" layers.

Without clear structure, it can become difficult to figure out who to talk to among your teammates.

So, to help better facilitate direct communication and seek advice from Olarkers with relevant expertise (similar to Buffer's advice process), we started daylighting current experts for different product and organizational areas of Olark.

For example, each of our Github repositories now has a clearly documented primary and secondary expert. Any Olarker can reference this and speak directly to the right engineers.

Our marketing team also has a quick reference spreadsheet with roles and sample scenarios of who to talk to about what. "Someone drove the Olark Ice Cream truck off a bridge? Talk to Laure about crisis comms."

(For your peace of mind about our driving prowess: we do not own an ice cream truck)

Key Takeaway: Make it easier for employees to get help.

 

 

 

 

 

Establish clear leadership

Improving structure and transparency is great, but we still wanted project teams to be as autonomous as possible, similar to Task Forces at Buffer and Squads at Spotify. But we realized projects lacked clear leaders.

Here's a perfect example: a seemingly straightforward redesign went weeks with no significant progress. After stepping in as founders (doesn't sound so "flat" does it?), we found serious issues: chronic trouble with vendors, unclear goals, and an inconsistent cast of contributors. With so many Olarkers touching the project, nobody knew who was leading the project nor did anybody fully commit to the project team.

We learned project teams need a clear lead who has authority to make decisions around scoping and prioritizing. Project teams now appoint a lead responsible for:

  • Representing the business.
  • Informing the rest of the company about progress.
  • Helping the project team execute well.
  • Making tough decisions.

Having authority to make tough decisions is key to autonomy, and also much more difficult than I originally thought.

Another example: despite good intentions, opinions from founders carried enough weight to derail decisions from project leads. As founders, we needed to become more self-aware and remind project leads they have the freedom to make the final call and still be supported.

Key Takeaway: Identify the project lead; don't assume leadership. Delegate final decisionmaking power.

 

Explicitly identify committed team members

We also realized projects were suffering from team members switching to other projects.

This is probably an all-too-familiar symptom for engineering resources (it was for ours). For example, our All Hands Support Month and Chat Ratings projects lost engineering teammates as new projects cropped up needing their skills elsewhere.

To ensure project leads were supported with the people they need, we began asking Olarkers to explicitly commit themselves before joining a project. This prevents our project teams from losing "passive" contributors who are actually key to the project.

For example, a project team should get commitment from an Olarker in Business Development if they want autonomy to negotiate partnership deals.

Key Takeaway: Identify key stakeholders; don't assume guaranteed participation.

 

Give projects more transparency

The final step to identifying leaders and committed members was giving these projects, project leads and committed team members organization-wide visibility.

Each Trello card has a project lead attached to it, along with the key contributors involved. Revisit our Trello board from above, but this time notice the key contributors identified on each card:

 

 

 

 

 

 

 

On top of that, we ask for verbal project updates during our weekly all-hands. Each project leader provides a short update on where the project stands and has the chance to ask for help and volunteers if a project is stalled.

Our weekly updates agenda looks like this:

 

 

 

 

 

 

 

 

 

Collective awareness at weekly checkpoints gives stakeholders a chance to directly identify themselves,

remove roadblocks, and keep projects rolling. This awareness also creates interest and support throughout Olark, which can be a strong motivator for completing projects.

Key Takeaway: Make projects and contributors visible. Doing so will also make teammates more accountable.

 

Continuing to Build Positive Culture

In a lot of ways, we are still iterating on our organization. At the beginning of 2014, I felt uncertain about changing a flat structure that worked for us in the past.

Today, I recognize flexibility is more important than flatness for maintaining autonomy and effective communication. Gracefully adapting our structure as we change prevents Olarkers from getting stuck doing things that no longer work. Most importantly, I feel we are more free to focus on our core values and culture, rather than idolizing a flat structure.

Receive 1 actionable lesson in your inbox each week. We will never SPAM you!

 

CommunicateBetter.io

THIS LESSON IS A PART OF...

CommunicateBetter.io is a 52-week course to help you level up your company's communication one week at a time. Get providen advice, case studies, and resources to unify your teams, convert more customers, deliver amazing customer experiences, and create product people love. Sign up now, it's free!

 

Olark live chat enables business and customers to honestly hear and understand each other. Olark helps you start talking to visitors on your site, strengthening relationships, and closing sales. Learn more at www.Olark.com

 

Matt Pizzimenti is CTO and co-founder of Olark live chat. He enjoys cooking, porch-sitting, and yeasaying. Reach him on Twitter @mjpizz or email him directly matt@olark.com

Welcome to Lesson 9 of CommunicateBetter.io!

BROUGHT BY:

AND WRITTEN BY...

CommunicateBetter.io is brought to you by Front

Learn more at http://frontapp.com

Please correct the following errors: