Engineering Culture at Tech Companies
Engineering Culture (“Culture”, ostensibly a subset of a broader organizational “Culture”) is a term often referenced in the Tech industry and self-referential descriptions of engineering organizations. Interestingly, it surfaces throughout the entire span of job descriptions for most jobs in Tech, from entry-level software engineers all the way through to the top job, the CTO. For those not in Tech nor otherwise exposed to this turn of phrase before, it comes across as a tribalistic linguistic affect that, in the absence of any other meaning, gives off a subtle yet unmistakable whiff of pretension. For those in the fold, it is well accepted that one must understand, internalize, and align oneself with the unique expression of a company’s Culture; engineers are customarily interviewed/screened for “culture fit” and senior leadership are expected to embody and champion Culture as physical avatars, so to speak.
Background
Culture permeates nearly every aspect of engineering organizations (which largely exist within larger corporate entities that include other, non-engineering, functions), while at the same time being, for all intents and purposes, intangible except through the macro effects it enables and engenders. It’s the gravitational force that coheres the panoply of interests, responsibilities, roles, functions, priorities, teams, departments, product/business lines, individual abilities, and personal aspirations within an engineering organization.
Command-and-Control
Traditional management practices are rooted in command-and-control structures of strict hierarchy where employees are viewed as fungible cogs (i.e. “resources”) and are expected to carry out orders with little to no questioning. Strict control of decision-making and adherence thereto is an absolute requirement for organizations that demand complete alignment in the face of moral/ethical ambiguity where swift action is necessary and information flow must be tightly controlled to minimize exploitation by dangerous adversaries. This model is intrinsic to the effective operation of military forces. The “command-and-control” (aka “top-down,” “authoritarian,” “paternalistic,” “old-school”) leadership philosophy has been (and is) the de facto standard in most organizations, big and small—even families—since time immemorial.
However, when we look outside of organizations whose primary, unambiguous functions are to combat adversaries that pose existential threats, the use of this model is not the faintest bit an imperative, and even more importantly, it is ineffective in managing highly-skilled, independent individuals to achieve desired results.
So, if not command-and-control, what?
(Engineering) Culture Club FTW
Small startups are famous for small, agile teams with individuals required to wear many hats (e.g. software engineer also does technical infrastructure). Though these companies also have a culture (e.g. fun, collegial, dog lovers), it is not the same as the Culture that helps a company scale and succeed, and is therefore not the topic of this post.
Larger engineering organizations in all their myriad forms primarily exist to produce technical output that advances product development while fulfilling business needs. Highly effective teams within these engineering organizations are able to, on average, consistently deliver high-quality results on-time. In the absence of militaristic recourse (i.e. court-martials, capital punishment) for failure to adhere to directives, how can an engineering organization achieve this tight alignment?
This is where Culture shines and requires deliberate thought to implement the right way to achieve the right benefits.
Cultural Foundations
The basis of Culture relies on another domain called Organizational Design which is fundamentally the codification and implementation of “roles, processes, and formal reporting relationships in an organization”1. we’ll break these components down in more concrete terms specific to engineering.
Roles
This is often taken for granted since most companies begin their journeys as scrappy startups that must eschew siloed responsibilities given their limited staffing, and are too small to think about leveling and career pathing as a result. However, after a certain size (say 40+ engineers) and growth trajectory, careful thought is needed to ensure a smooth transition beyond what I call the “inflection point to scale.”
Clear roles and a well-defined career framework in a company is necessary to attract talent (i.e. few seasoned, mainstream engineers want to work in a place where they can’t see or validate their career growth through increased titles and responsibilities). As such, beyond the inflection point, it becomes critical to think about how to transition the company to a high-growth model where it is implicitly able to support growing the organization while providing existing engineers clear insight into their career development.
That being said, there’s a non-trivial cohort of engineers who work at early stage startups that abhor structure and narrowing their technical jurisdictions, so there is almost always attrition of existing talent when a company undergoes this transformation.
Extended detail of one implementation can be found in a prior post.
Processes: Bad Process Sucks, Good Process Liberates
[G]ood processes reduce unnecessary duplication of effort and produce outcomes that are quantitatively better than they would be without them.
People either hate the notion of process or they understand and crave the deep need for it. In my personal experience, those that chafe under the mere notion of process are those that have been subjected to bad processes in their past; processes that were overly cumbersome and that did not provide obvious value to anyone. The processes that support Culture are entirely different than that stereotype; good processes reduce unnecessary duplication of effort and produce outcomes that are quantitatively better than they would be without them.
When we think about scaling teams, there are a few key aspects that need to be addressed:
is there a well conceived organizational structure in place to support team growth?
are proper career tracks (and roles) in place? (covered in the prior section)
is the recruiting process (sourcing, vetting, interviewing, evaluation, onboarding) uniformly calibrated across all teams
Organizational structure can simply be thought of rational reporting lines with clear delineation of managerial and individual contributor responsibilities. At the same time, reshaping amorphous teams into clearly targeted teams with specific remits (e.g. front-end, back-end, infra, security, data science, etc.).
The recruiting process is absolutely essential in getting right. Once divided into teams, there is what seems to be a tribal instinct to think that their own needs and specific requirements means that their recruiting process should be different than another’s. That’s a dangerous fallacy that can lead to internal perceptions of inequality, objective miscalibration of skills across the organization (which then leads to an inability to seamlessly implement internal mobility), and the expression of both conscious and unconscious bias.
The backbone of a strong recruiting process is based on the foundation of a strong, well-defined leveling framework that emphasizes the same sort of expectations around impact and behaviors of candidates. These inform every part of the recruiting process and allow teams to make minimally-biased hiring decisions that stand up to scrutiny. I will write another post about detailed hiring processes that have been effective.
Formal Reporting Relationships
This simply means that reporting lines are sensible in the context of the organizational design, and often they are conceived as two sides of the same coin. There should be no ambiguity about who reports to whom, who is responsible for what, etc. Pretty basic stuff that I don’t think I need to drill into more deeply.
Other Aspects
Then, there are the less obvious aspects of Culture. These are usually expectations around interpersonal behavior, approach to work, alignment with a company’s mission, the nature of relationships between teams/stakeholders, etc.
I strongly believe in an organization that believes in and expects strong collaboration based on trust and mindfulness.
Another strong model of Culture driving behavior is Amazon's Leadership Principles as they clearly articulate what everyone should internalize in their daily work and inform how they go about execution.
Conclusion
Culture is a multi-faceted, complex, and loaded term that is an absolute requirement to build, sustain, and strong engineering organizations. You may not get it right the first time, and that’s totally fine—the key point is that Culture and processes must be perceived as things that evolve over time as the business, the product, and size of organizations change.
“Organizational Architecture”, Wikipedia, https://en.wikipedia.org/wiki/Organization_design