Building ace engineering teams is a matter of culture

SaaS is a sparkle in the technology world today, and a host of companies including Freshworks is riding the wave. While it is given that we’re being aided by a technological shift, it’s no mean feat to remain on the cusp of the wave—to maintain the trajectory and keep hitting milestones charted out many moons ago.

Among the factors that have helped us in this journey, one of the significant contributors is what we’ve built with our people: our culture. Running one of the fastest growing platforms for app developers, the Freshworks Developer Platform, I would say the journey has reinforced my original ideas about what great teams are capable of.

Let’s first start with a low-down on how we have built the platform as an Engineering Team. We track the performance of our engineering team with respect to its delivery using the DORA report’s recommended metrics (Check this link out.) We have been using this to track our performance for almost two years now. It primarily measures a team’s performance using the following metrics.

Let’s leap up a level to see how these metrics qualify an engineering team. In the narrow sense, the success of the engineering team is defined by how it delivers business value by solving business problems using software. In the broader sense, building and delivering value through a software product is more akin to running a marathon. You have one eye on the long-term, realizing that the road to success is a long one. The other eye is on near-term gratifications – fixing a nasty bug, shipping a cool new feature, launching a new offering.

Contours of success

To that end, an engineering team’s success is typically qualified by:

Predictably delivering changes and updates into the hands of the customers (deployment frequency and lead time to deploy metrics on the DORA report referenced earlier)
Providing a reliable, glitch-free experience to its users (change failure rate for the problems that degrade experience)
Identifying and quickly resolving nagging problems as they arise (mean time to repair)

How a team might achieve these outcomes often varies from team to team. The best teams however are highly likely to demonstrate the following qualities:

A sense of togetherness that enables the sum being greater than its parts.
A religious disposition toward efficiency and automation
An inclination toward optimizing for velocity, that makes change as well as learning from the change, easier.
A sense of pride in their work, that is deep-rooted in the humility to know where they were wrong about something.

Metrics are of great help in tracking and analyzing efficiency and progress, but they work better in an environment where human intuition is given a wider play, too. I would paint the success story of an engineering team on a much larger canvas, taking into account intangibles that do not necessarily lend themselves to metric-driven analysis but their presence, or the lack thereof, has a deeper impact.

How culture manifests in a team

This canvas could well be what organizations describe as their culture. Team culture is an unquantifiable entity that can only be observed in action. There are a few situations within a work environment where they tend to manifest themselves very clearly:

What do team members choose to do when no one is watching, and when a question of professional morality is presented to them?
How do they react to a situation where no precedent exists and no process or rules are defined?
When faced with a choice between a virtual “rock and a hard place”, how does an individual act? When do they make the choice themselves, and when do they escalate?
What situations require them to deliberate on their own and when do they feel the urge to sign off or get buy-in from a leader?

Culture is shaped on a daily basis through the acts of both individuals on the team and the team itself – with every choice, every outcome, every celebration, every recognition, every post-mortem. There are however a few that have a disproportionate impact on team culture.

The public actions of leaders or those perceived to be leaders, and the choices they make, especially the ones that require justification.
The new team members that are hired – the more senior the hire, the greater the impact.
The people and actions that are publicly rewarded and celebrated.

**Team culture** is an unquantifiable entity that can only be observed in action

In my experience, newcomers are the Hello Worlds to our team culture, in the sense that they test out all that’s laid out in gleaming words on paper. When a new member joins, invariably I put them through a process, one that’s been developed over years of try and fail.

When a new engineer joins, she/he inherently wants to feel like they belong and they want to start succeeding at work. Helping them feel like they belong often requires time and personal investment from multiple individuals, including the new engineer. When it comes to helping them succeed, they need to first understand what success even looks like on this team.

The newbie routine

They must also appreciate what we are all here to do – our purpose as a team, and what qualities define our work. To that end, the four things a new engineer might need are,

Understanding our purpose – the harder business aspects as well as the softer qualitative aspects about what matters to our users and us as craftspersons.
Each team is unique in how it goes about its work; we call this “ways of working” at Freshworks. A lot of how a team succeeds in achieving its goals is best understood by participating in and actually performing some of the work. It is nevertheless important to prevent culture shock by calling out the salient aspects of the culture of work to lay the foundation to explore, discover and embrace the finer aspects. Eg: “Deployments are the heartbeat of this team”, and “We take pride in clean interfaces between services.”
A list of people to meet, and particular stuff to ask them once one introduces themselves to these people. This not only helps break the ice, but also encourages deeper conversations and enables learning about important aspects of work, architecture, practices, and so on.
A set of 3-4 “Quick Wins” – work items that enable the engineer to start applying some of the above within a continuous learning experience, in partnership with a “buddy” to quickly experience how success looks like. The tasks are designed to help experience salient aspects of the “ways of working” in real life while delivering quick value to our end-users as well.

In letter and spirit

Now that we’ve encapsulated the form and content of culture, what are the principles and practices that make it work? There are a few principles that have defined our engineering and related outcomes over the years as a team.

Be proud to put your name on it (craftspersonship)
Perfection is the enemy of progress
Only the universe needed a Big Bang creation; most else can be achieved through iteration.
Innovation happens in the everyday
Team boundaries are defined not by how people organize themselves, or how services are divided between owners, but by whether each team can release changes to production independently

Here are a few practices that help us drive certain values:

Weekend work is appreciated only when it is required (dousing a fire in production, for instance). We try to be indifferent otherwise. How team members use their weekends is up to them. Having said this, some of our most creative work was shaped by prototypes that emerged from weekend efforts engineers put in—mainly because they had to scratch the itch. We celebrate the creativity and the outcomes, but try not to celebrate the perceived personal choices in this case.
Start with why: Each meeting (except the regular sprint ceremonies) starts with defining its purpose; each new project begins by describing why it is needed now, each deadline is preceded by its compulsions. The idea is to respect the intelligence of the team and have them sign up.
Speaking of deadlines, more often than not there are ambitious and aspirational goals, while deadlines are reserved for those rare occasions where aligning as a company or an organization is critical (new product launch, certifying compliance). Deadlines only encourage one aspect of work—timeliness. Other aspects such as craftspersonship, quality and scalability, which deserve equal importance, tend to get sidelined. Just because time is easier to measure, one tends to take the visible target as a challenge. We instead choose to treat time as a fuzzy and fungible metric of success, just like craftspersonship, quality and scalability.
Writing is thinking: We originally mandated documentation as a way to preserve and share knowledge through time. Leads on the team began to politely require a doc before reviewing any new proposal. Before we knew it, however, a proposal without a doc started to be perceived as half-baked. A number of champions emerged on the team who communicated their thoughts through writing. It goes without saying that this has started to become a superpower during times of remote work.
Innovation is not something you plan to do; it is something you incorporate into your everyday work. When you find yourself doing something mundane, ask yourself how you can do this without the effort. When you find something habitual is sub-optimally done, ask yourself if there is a better way to do this. Once you identify the opportunity, ask for the additional space and time to do this – most typically as part of an activity you were doing anyway. “That user story we wanted to complete this sprint? I will need a couple of additional days to improve how the data is fetched.” “Can I get a 3-day spike next sprint? I want to show us a new way of testing our services.”

In Part II, I will focus on some of the fears and challenges faced by leaders, and how I deal with certain pressures that keep me up at night.

Cover and inline images: Vignesh Rajan

Authors