Our Team Grew 6x In 2 Years — Here’s How We Strengthened Our Culture & Collaboration Through This Transition

Tashfeen Ahmed
KeepTruckin Design
Published in
7 min readApr 19, 2019
All images by author unless stated otherwise.

This story was co-authored by my colleague, Awais Imran.

Our world today resembles a global village, powered by information superhighways of the Internet, and software tools made for cross-continental collaboration and communication. To thrive in this new world, fast-growing teams need to scale with care and intention. If you don’t, your team culture and collaboration will be at serious risk.

In the last few years, KeepTruckin has grown from 300 employees across San Francisco and Islamabad to 1,600+ in new locations like Nashville, Buffalo, Vancouver, Lahore, Taipei, and Manila. In this process, our design team has grown even more — from 3 people in one office to 19 across multiple locations. Besides the inherent challenges of fast growth, we’ve faced significant challenges in remote collaboration; some we’ve solved, some we’re still working out.

We’d like to share our learnings with the larger design community in the hope they’ll be useful to other similarly structured teams.

Before joining KeepTruckin 3 months ago, I was uncertain about the design team’s collaboration across San Francisco and Islamabad and Lahore: how do they collaborate effectively when cross-functional teams and sub-teams are separated by thousands of kilometers and a 12-hour time difference?

As I discovered: the team uses a suite of industry-standard communication and collaboration tools that’s bolstered by a robust workplace subculture, and self-driven team members.

But of course it’s not that simple. Let’s dive into the tactics that we used to build a high-performing cross-continental design team. This is based on interviews with colleagues, and my personal observations.

Create an inclusive design team culture first

Team culture doesn’t just happen. You have to cultivate it by intentionally moulding how members work, collaborate, communicate, think, and grow as a team. This is doubly important in a global organization where people come from diverse backgrounds.

Building an inclusive team culture means making remote team members feel like they’re (almost) co-located, and that you’re all part of the same group, gunning after the same, shared objectives.

The list below is a manifestation of the values we’ve informally built over the past two years of rapid growth:

  • Love your work, and working together. Each of us landed in design because we genuinely believe it is our calling. This love of craft is infectious, and we love sharing it with our colleagues. We hold off-site collaborative team activities that allow for informal, deeper conversations to happen. More structured conversations happen in 1:1 meetings that go beyond work, and cover career, philosophy, the good life, health, relationships, personal finance and everything else you need to be a better human. We also don’t hesitate to peek over each other’s desk to ask, “Hey, that looks cool. What are you working on?” which leads to serendipity at work.
  • Help each other grow. “When the student is ready, the teacher will appear” is a quote that applies well to our design team. Members are encouraged to communicate their personal goals; managers and leaders support them as best as possible. The company invests in our growth by funding online courses, books, and conference passes. Team members with specialized expertise provide mentorship and regular feedback when you need it.
    This is arguably my favorite bit about our design team’s culture. My colleagues constantly share their knowledge and wisdom; not only for design work but also for life in general.
  • Empower designers to make important decisions. Designers are paired with product managers from the very start of each project, and are empowered to make fast design decisions without waiting for sign-off from senior leadership. Autonomy is important for engagement at work, and this is central to it.
    Do mistakes happen? Yes, frequently, but they’re identified and fixed early because we practice open communication and proactively solicit feedback. We also keep getting better over time as we learn from our mistakes.
  • Practice open communication. We share our work early and openly to solicit feedback. Cross-functional feedback identifies feasibility and usability issues early, and saves major headaches later. We understand that feedback is for improving the design and a way to achieve better outcomes — it is not to be taken personally.
  • Celebrate success, and learn from failure. Giving shoutouts when your peers execute well reinforces this, as does impersonal group reflection when something goes wrong. This ties in closely with #2.
  • Practice async-first communication. Cross-office face-to-face communication is expensive for us because one group ends up taking meetings at odd hours. This isn’t sustainable, so we push for asynchronous communication that respects the other person’s time and timezone.
    Case in point: we’ve replaced synchronous daily standup meetings with asynchronous daily updates in a Slack channel, tasks documented and updated regularly on JIRA boards.

Maintain a well-documented, single source of truth

As design teams grow, so does the tendency for inconsistencies to creep into the user experience. Interactions that work one way in one part of the product, begin working differently in another. This was one of our bigger struggles early on.

Our design team initially kept all design resources on a central Google Drive folder. This worked while the team was co-located, but it became a bottleneck later as we expanded. It wasn’t obvious how the folders were structured, which subfolder had the latest files, and which mockup was approved for implementation — unanswered questions that slowed us down. You were out of luck if the team member who could answer this question was fast asleep on the other end of the globe.

As our team size expanded 6 times over across our existing offices, and we started operations in new cities, we felt the need for a better central repository that would serve as a single source of truth.

It was around that time that Abstract — the version control system for designers — launched publicly. We took a leap of faith and haven’t looked back since.

Today, all our work lives on Abstract: ongoing projects, archives, experiments, and a work-in-progress design system. Abstract supports an internal design culture, provides clear lines of control, and encourages a consistent user experience.

We’re also documenting best practices and our general design process on Confluence — our internal knowledge-base — so incoming designers can hit the ground running. Confluence also serves as a source of truth on project specs, our user research reports, organization charts, our long-term goals, and more across all functions of the business.

In the future, we want to simplify collaboration by reducing the number of design tools, and integrating our front-end design system across all our products.

Expand and organize design teams with intention

We grew from a team of three designers in 2016 — a lead, product designer, and communication designer — to twenty designers with expertise across the full spectrum of digital product design — research, interaction design, visual, and industrial designers, UI engineers and more.

Collaborating effectively with the rest of the company while staying in sync as a large design team was a core challenge. We tackled this by following the “Centralized Partnership” model championed by Peter Merholz in Org Design for Design Orgs.

Centralized Partnership is a hybrid model that combines the best of centralized and decentralized models. Team leads work with product managers to define projects, and assign a designer from a virtual pool. This pool has smaller sub-teams of designers, each centered around a certain business problem. After a project is finished, the designer returns to the larger virtual pool, available for other projects within their sub-team, but not unavailable for projects in a related product group. This model supports a strong design team subculture, encourages individual growth, leads to a more consistent user experience, while keeping cross-functional partners happy. You can read a deeper summary on the Centralized Partnership model here.

Organizational models are of course built to support people, and so its success depends largely on the calibre of people you bring into your team.

Hiring great people is a complex topic that’s outside the scope of this article, but I’ll share one tactic that has worked immensely well for us: hire for exceptionally strong self-management and communication skills. With designers, managers and cross-functional colleagues spread across the globe, team members absolutely need to be proactive at work, initiate and drive their own projects, and communicate clearly with the right stakeholders at the right time. Any lapses here can lead to days of lost work that startups cannot afford. My colleague Awais Imran wrote about hiring in more detail in “My first year as a design manager.

The KeepTruckin design team is only in year two of its cross-continental team setup, so we’re still learning, and experimenting. We have our ongoing struggles, but we see them as obstacles on the way to growth. Some of the goals include:

  • More effective asynchronous communication, so team members in Pakistan can take deeper breaks from work at night when colleagues in America start their work, and vice versa.
  • Integration of the front-end design system across all products to strengthen consistency in the user experience.
  • Stronger partnership between the designer, product manager, and engineer.
  • By sharing what we’ve learned, we hope we can start a conversation with the larger design community so we can all get better together.

Have you worked with a remote team? We’d love to hear your experiences, tactics, process and more.

--

--