Scaling Engineering at Harness

By Jyoti Bansal, Sri Ramalingam

As a startup, a bittersweet yet significant advantage we have is speed. Speed gives us the ability to deliver and meet our customer/market expectations rapidly, and the possible reality of crashing and burning when scaling isn’t properly executed. Adding to that challenge is how to lead and scale teams across multiple geographies and time zones.

Harness is experiencing breakneck growth in every dimension. So mid last year, Jyoti and I embarked on a strategic exercise centered on planning and organizing the growth of R&D at Harness. To ensure the maximum success, we laid out a few goals:

Access To Major Engineering Talent Pools to Serve Our Growth Needs

We are currently at about 240 engineers/designers/product managers/writers across our four R&D locations and we are looking to expand the team to about 500 in the next 3–4 years. With this team, we intend to create a dynamic workspace by hiring the foremost engineers to cultivate a Silicon Valley cultural identity in the other geographical locations. But at the same time, we want to keep our engineering costs competitive by being very careful to not to hire engineers from regions with the highest costs of living.

The Covid-19 pandemic has inadvertently shifted how we work and collaborate. With this in mind, we wanted to create not merely a work from home, but a work-from-anywhere culture. Highly aware that time zones vary we still wanted to ensure our teams are able to perform to the best of their abilities.

A hybrid work environment

A remote work-from-anywhere culture can cultivate a strong dependency on formal/written asynchronous communication across the board. We want to avoid that and foster a bespoke style of communication by juxtaposing synchronous communications (slack, zoom) and asynchronous communications (google docs, confluence for specs, Jira for tracking issues, and emails for standard announcements) dependent on tasks being performed.

We want to allow everyone the freedom to work from home if they desire. However, based on our employee surveys, we can safely posit that 35–40% of our employees want to come to the office. We want these employees in these cities to have the option of going into the office. We want to guarantee that team members in all geographies experience equal growth opportunities. No geography should be behind or in front compared to any other geographic region.

To make this ethos a reality, we need to cement our remote employment in a country that can seamlessly accommodate our ability to provide legal/HR/employment support in that country.

While most of these are growing pains faced by any fast-growing company, there is no one-size-fits-all approach to address these challenges. We want to foster a culture of complete transparency, and so after having extensive discussions with our internal teams, we have come up with a tailor-made model that suits our growth and culture.

We made this announcement six months ago and have since been operating on this model. Our teams are now more self-sufficient, our cross-time zone meetings have gone down more than 50% overall to individual contributors and we have opened two more R&D centers helping us scale robustly and effectively. We continue to fine-tune the model as we go along making minor alterations and fine-tuning to accommodate geographic specific needs.

What We Have Done

Let’s Start with Some Key Definitions We Came Up With:

● Region: A Region is a geographical area where we will hire engineering employees. All employees in a Region will be within a three-hour time zone difference of each other.

● Office Bases: Each Region will have 1–2 Office Bases where we will have a physical office where employees can work from if they like or use it to collaborate. About 50% of employees in a Region should be hired within driving distance of Office Bases.

● Legal Countries: In any Region, we will have a list of allowed legal countries where we can hire and support employees.

● Dev Squad: is a team of 3–8 engineers (8 maximum with few exceptions) led by an Engineering Lead. Dev squads have the following constraints:

• Every member of a Dev Squad must belong in the same Region
• Dev Squads work on well-defined segments of a product. One squad might own more than one entity within the product unit
• Dev Squad owns both the development and testing of their work. Some Dev Squads can choose to hire dedicated Quality engineers as part of their squad. Squad owns the entire product /component/micro-service lifecycle — from design to production including operating production pipelines

● Product Units: A Product Unit is built of 1–6 Dev Squads (30 ppl maximum) led by an Engineering Director. Dev Squads within a Product Unit will typically be in different Regions. For example, one Product Unit can have 2 Squads in India, 1 in North America, and 1 in Europe. UI engineers are assigned to product units

● Product Division: A product division is built of 3–6 Product Units (100 people maximum)

With these definitions in place and by looking at our 3–4-year headcount growth, we created 3 regions.

Region1: North America (we have expanded our engineering presence to Canada, and so it’s Continental US and Canada)

Region 2: India/Singapore

Region 3: UK/Ireland/Serbia

Future Regions: LATM, Japan, AUS/NZ, and Southeast Asia

Each of these regions has a VP of Engineering or Head of R&D leading the teams. We have eight product divisions:

• Platform (Foundation engineering, Build Engineering, Authorization and Authentication, Developer Experience, Agents/Delegates, Pipelines among others)
• Continuous Deployment
• Continuous Integration and Test Intelligence
• Change Intelligence and Machine Learning
• Cloud Cost
• Feature Flag Platform
• Security Test Orchestration
• Site Reliability
• Systems Engineering (scale, performance testing and scoping, Release management)

Each of these product divisions has anywhere from 1 to 5 product units, and each of the product units has anywhere from one to six dev squads). With the model in place, we have swiftly expanded into the EU with the opening of two new R&D centers, hiring the top engineering talent, and aligned the skill with the product unit and squads in the brief period of a few months once the legal process of setting up the entity is complete.

Streamlining Communication Within and Across Time Zones

In Pre-COVID times, most of our teams came into the office, so the communication channels were more synchronous and near real-time. As we moved into a hybrid working model, even a 1–1 conversation between our engineers became a “zoom” meeting. The question became how many meetings are too many? and how many are really needed when you have good specs in place ? [By the way, Startups are not that focused on creating and maintaining good engineering specs and so we have to start growing a culture and a mindset of writing specs and adding comments in the code.] We came up with few guidelines:

• A vast majority of the communication within a Dev Squad (within engineers and with their direct manager) can be synchronous (slack, zoom calls, etc.). Most of the communication outside the Dev Squad should be asynchronous (specs, emails, Jira). There will be some synchronous communication over zoom calls etc. But it should be minimized for the most part. These meetings will likely happen within the region.
• Synchronous communication outside of working hours in each region should be restricted to production incidents or to address escalation customer issues which are classified as P1’s

With these guidelines in place, the expectation is that the individual contributors will spend less time in synchronous communication, and the rest of the leadership and management team will naturally end up spending more time over Slack and Zoom.

These structural realignments have helped us streamline Harness engineering without losing speed and efficiency, improving (less) real time communication across regions, fewer meetings, and more collaboration without frustrations. We made some exceptions to the squad sizes as needed but kept the larger framework intact. We still have few gaps and will continue to focus our efforts on perfecting the model to meet our growing needs.

The hybrid working model has thrown some challenges to the operating model for software companies, and we need to continue to evolve how we organize and lead our teams within and across the time zones. We have realigned our organizational structure to the changing demands of our teams and the meteorite growth we are experiencing. While this is an ongoing journey, we see the benefit of the hybrid structure daily with improved work/life harmony, quicker turnaround times on deliverables, and all-round more joyfulness around our employees.