CTO School Meetup: Options for scaling teams beyond NYC

Another month, another excellent CTO meetup. This month, the focus was on options for scaling teams beyond NYC.

To recap, the monthly meetup is a forum for startup CTOs, VPs of Engineering, Tech Leads, entrepreneurs, senior developers on the leadership path, and individual contributors to gather and discuss the challenges we face as leaders.

As I am currently exploring ways to augment the development and QA teams at my organization, I am very interested in the topic of scaling and curious to hear additional perspectives on the subject. Recently, I met with one offshore development company, extendedITArms, and this meetup was not only timely, but essential in identifying key areas for me to focus on and follow up on during my discussions.

Now that we have a little context, let’s jump in.

Contents

What was the discussion about?

Jean, the moderator and organizer, started off with one (simple) question:

Who is having an easy time hiring developers in NYC?

No-one raised their hand. Welp, that about sums it up. Hiring in NYC (and I assume other competitive cities) is challenging for one key fact - the demand is higher than the supply and the big companies can outbid the smaller ones. The market favors developers, good if you are skilled and searching for an opportunity and challenging for companies looking to hire.

There are many different options to tackle this problem of hiring and growing at scale. This discussion centered around offshore/outsourcing, satellite workers/offices, as well as additional options including hiring (and mentoring) junior developers. Each presenter had an opportunity to share their experiences and perspectives.

Before we go further, a quick recap of some different ways to scale:

  • Outsource: contract work to a third-party
  • Offshore: teams located in different countries (development in house or outsourced)
  • Distributed: teams in multiple countries/regions/timezones
  • Staff augmenter/partner: outsourcing strategy, extension of your team to leverage existing people and utilize additional staff
  • Note: Companies may implement a combination of one or more of these strategies

An apt analogy of offshore vs distributed, was that of architecture: e.g. monolithic vs microservices.

On the different ways to scale.

As software built is often a reflection of the team dynamic and communication, it is very important to organize your teams based on the intended system design. Having teams based in different locations requires an extra level of orchestration and monitoring. Jira and documentation were heavily stressed as invaluable tools to support communication and process within distributed teams (“If its not written down, it doesn’t exist”).

In addition, perspectives were provided on scaling through a staffing augmenter/partner. Ideally, a partner should be a true extension of what you do in your organization, from helping to knockout your backlog to providing additional expertise (e.g. looking to move from on-prem to the cloud? Need ReactJS developers?). A partner can help you on a project by project basis, but most success is in long term engagements.

So what’s the difference between a “vendor” and a “partner”? Well as eloquently explained in the meetup: A vendor is TGIF, while a partner is a restaurant that pairs your wine with your meal. Got it, I’d like the Merlot, please. Thanks!

Another approach to scaling that was raised by the presenters (and one I have personally championed at my organization) is to hire junior developers and train them. I have had great success hiring talented, hard-working, self-motivated developers in entry level positions who have rapidly transitioned into valuable and productive team members. The key(s) for this to work? Have an excellent onboarding program (training) and strong management/leadership.

Who were the guest speakers?

Each presenter provided a different perspective on scaling. Dmitry and Daniel discussed the challenges and opportunities with growing an organization based in NYC, while Jesse provided the partner perspective on supporting organizations as they scale. Each brought extensive experience and valuable insight to the discussion.

What are some challenges when scaling beyond one location?

  • Communication. This was often the key driver for success/failure.
  • Architecture is hard - cannot share a white board
    • As an aside, this seems like a great startup idea, why isn’t this solved?
  • It was observed that no matter what city, you can (will) run into a scaling problem
    • Price of developers overseas starts to rise
    • Eventually everyone has a bench and the bench might run out. The team may have people but not the people you need (e.g. no senior Node developers)
  • Working in different time zones (again, communication)
  • Hiring remote developers:
    • If less than 7 years, then do not hire
    • Hiring people without a strong CS background doesn’t work
  • Note: Never “try out” a developer, if they fail the interview, do not just try them out

On creating and maintaining a culture at scale

Furthermore, and worthy of its own section, is the challenge of creating a culture when teams are located in different countries, regions, and time zones. How do you create and maintain a culture at scale? The presenters offered multiple viewpoints on how to potentially address this difficulty:

  • As leadership, ask and determine: How do we align with the culture?
  • Determine what people think about and what they feel
  • Bring people out to New York for 1-2 weeks; fly people back and forth
  • Have video calls (make people put their camera on)
  • People are social animals - have the “water cooler talk over Slack”
  • Create a balance between people who smile and people who are great engineers
  • Find people who get and appreciate taking on challenges, specifically the challenge of working remotely
  • You can never talk about the why enough; people can lose ability to get excited without the why
    • Give people the what and the why, furthermore pitch the tech team like investors

A few keys to success (aka let’s make this work)

  • Design the teams first to create the architecture you want to build
  • Regularly have people meet in person (e.g. send people from NYC to Belfast)
  • Document everything (e.g. “If not written down, it doesn’t exist”)
  • Understand the local power structure, have a local partner
  • When distributed - learn local labor laws
  • Do your diligence, research the company, laws and the people you are looking to work with
  • Have good leadership in place (a must); need a partner you can trust.
  • Vertically align teams to areas of business and make sure everyone they need to communicate with is collocated. It is critical to get teams independent, avoid spreading work amongst teams
  • When a region is found that you like, hire a recruiter
  • When working in different time zones, align people in a time “band”; shift to teams based on time zones

My key takeaways

  • There are many options for scaling and leadership must determine the best approach that works based on project/company needs, budget, and team expertise
  • Communication is key
    • At times, you must over-communicate
    • When working with remote teams have video conferences, align squads in timezones
  • Document everything. If it isn’t documented, it doesn’t exist
  • Building and maintaining culture is paramount
    • Have remote teams visit NYC, have NYC teams meet their remote coworkers
    • Focus on the why
  • Understand the local labor laws
  • Do your diligence and research, ensure the partner you are working with is ethical

The great thing about these takeaways is that they can be applied to all teams regardless of size, location, and staffing strategy.

Updated: