Is Your Company Engineering-First or Product-First?

One of the greatest advantages I’ve had throughout my career was working in different types of companies, acting as a Consultant or even in Holding-type companies. I think these types of companies give you a type of exposure that is very hard to find in conventional companies (e.g., a business with a single vertical).

However, as much as these businesses had different dynamics, after a certain time acting in each of them, a very clear distinction in how these companies used engineering/technology began to appear.

These distinctions I saw were not only within the strictly technical field, but within the organizational cultural aspect.

And here when I say culture, I refer to the Wikipedia definition that uses the direct quote from Edward B. Tylor in which he states that culture is “that complex whole which includes knowledge, belief, art, morals, law, custom, and any other habits and capabilities acquired by man as a member of society”.

Transposing this definition to the corporate context, a company’s culture is determining in how people are hired, in the evaluation of expected behaviors, incentive structure, and especially in the way decisions are made and strategic directions are decided.

These approaches, which at first may seem like things with low relevance, have a very large weight both for organizations and especially for people.

By the end of this post, I intend to clarify the idea of companies with Engineering-First and Product-First approaches, talk a bit about their advantages and disadvantages, and why this is relevant in terms of career management [1], [2].

The idea here is not to say that approach A is better than B; but to make a parallel and show some of the distinctions between these approaches and the advantages and potential challenges.

Engineering-First and Product-First: Two approaches

Disclaimer: Different from what it may seem, these approaches are not mutually exclusive. That is, the adoption of one or the other approach does not explicitly mean that the organization only does A or B. In fact, the best organizations are those that manage to switch almost adaptively between these two approaches depending on the strategy and what is to be achieved.

I write this due to the fact that a common thing I have been noticing in some discussions with some colleagues is that the lack of knowledge of the type of company one is entering, along with the lack of self-knowledge, ends up leading to a spiral of frustrations over time where both sides are always dissatisfied, leading to inevitable boreout, resignations, corporate stress, and the like.

In one case the product side gets frustrated because of constant delays and complaints, while the engineering side is due to the lack of a correct conceptualization of the project or scopes. That is, a situation of eternal friction.

Thus, understanding the types of companies is the first step to get out of this spiral of frustrations and frictions. But first, let’s look at some characteristics related to each type of approach.

Paradigms and Characteristics

Engineering-First Companies

Engineering-First companies are companies that have their engineering and technological innovation capacity as their main comparative advantages. Generally because of these factors, some of these companies are very dominant, sometimes reaching the point of building almost invincible monopolies (e.g., Siemens, Airbus, Google, Facebook, Amazon) because these companies use new methods (or classic methods) of engineering and technology not to leverage their Core Business but as a form of survival.

Generally, they are companies that work with platforms/infrastructure as main services, or companies that have engineering at the center of the innovation process and product conceptualization. In other words, the business is geared toward the incorporation of cutting-edge technologies into products or more efficient ways of doing something via optimization.

In general terms, here the approach is engineering will build it and product will put it in a more attractive package and make the flavor more palatable. Some of the time these Engineering-First companies offer mission-critical platforms/infrastructure and products of high technological complexity that do not have a direct interface with the common final customer.

These companies have engineering/technology in their core business, and technological stagnation or obsolescence can be the difference between glory and bankruptcy.

Some examples of Engineering-First companies could be Honda and Mercedes-AMG in the Formula 1 engine part, Huawei in the telecommunications platform part, Amazon Web Services regarding the infrastructure part, and Airbus in the aerospace part.

These companies have an extreme engineering culture where optimization is taken to the extreme and small gains make all the difference in the final result, which in a certain way places a very large pressure on the degree of specialization necessary to make this happen.

Product-First Companies

On the other hand, Product-First companies are characterized by being organizations where technology enters more as an element of leverage, optimization, and scalability to facilitate business transactions that do not demand technology in a direct way.

Most of the time these companies are extremely pragmatic regarding technology due to the fact that for these companies they have a higher-order problem to be solved and engineering would be just a tool/means to solve that problem.

These companies generally work centered on the final consumer from conceptualization to the final user experience, and unlike the Engineering-First approach, here there is the inclusion of human factors in the final result.

In this case, engineering enters Product-First companies only to materialize the concept defined in the product vision in a way to either leverage or scale their business processes.

That is, technology can be used to leverage or optimize a process, but in the end, this must be part of a specific product that will satisfy a final user, and this is the company’s real Core Business.

Some examples of Product-First companies could be Apple regarding the personal computer part, Microsoft in its video game line, Netflix in the content distribution part, and Spotify as a marketplace between artists and music/podcast listeners.

Roughly speaking, Engineering-First companies are based on ultra-optimization, scalability, redundancy, and the focus on their engineering/technology components as core business; while Product-First companies generally work on how to put technology to solve some kind of human need through products that people like and use, that is, in this case these companies use engineering/technology as support for their operations and not as a main focus.

Now that we have a definition of what the companies are, I will try to put some points of what I have seen over time regarding the advantages and disadvantages of working in each type of company in a non-exhaustive way.

Engineering-First: Advantages and Disadvantages

· Advantages

• Generally, this type of company has a very large openness to Research/PoCs for incorporation of new technologies either as new ways to solve latent problems or to gain performance and scalability (e.g., Bell Labs).
• Fine-Tuning/Optimization in some companies is used as a strategy that, if well-defined, can become a competitive advantage. Here there is no secret: each small optimization can have very large scale gains (e.g., increase in throughput of a platform, efficiency of a new compression algorithm that reduces space needs, networks that have reduced latency, etc.)
• Tends to attract engineers with a greater degree of specialization in few aspects, but with a much greater degree of depth (e.g., here it would be the equivalent to the engineer responsible for the titanium alloy that is part of the construction of the blades of an Airbus A320 engine).

· Disadvantages

• Part of the work will always be invisible, and worse: This same work tends to move with a much greater degree of uncertainty and with a speed that can be much lower in terms of delivery pace;
• Working in environments focused on optimization gains can be frustrating for those who want to work with innovations focused on the final user or those who are saturated from working on the same subject for months with little or no result (e.g., spending 30,000% on research to gain the final 3%).
• Too much optimization can lead to technological stagnation given that while looking for the correct parameters for something, some competitor may be working on something completely new (e.g., Airbus passing Boeing with a totally different engineering paradigm)
• It can be a nightmare for Product-Engineers given that as the work sometimes can be to make something run better, the impact on the final customer may not be as perceptible;
• It can bring something technically interesting and in terms of execution, but it can be very unattractive to the final customer (e.g., Concorde, Windows Vista);
• Over-engineering here can be a very big problem and when there is no communication with product teams, it generally leads to waste and increases maintenance costs in a moment in the future.

Product-First: Advantages and Disadvantages

· Advantages

• It has an enormous attraction for Product-Engineers. For those who like to see the result of their work at the end of the day impacting the final user and having the real visibility and impact of what is being done, a Product-First company is the best place to be. I have already been in some and I can state that seeing something working and people using your application is something that is worth it.
• A Product-First approach manages to capture the market timing to launch new features and/or defend part of the Market Share, sometimes even at the same time. In some engineering scenarios this is not always possible, given that a Product-First company must be capable of adapting at a greater speed to market trends or following competitors if it is a case of a more intense competition for gaining or maintaining competitive advantage (e.g., using Swift instead of Objective-C in iOS projects, for data solutions to be accessible in real-time, instead of using a traditional DBMS use Redis, etc.);
• Here competition raises everyone’s game. This is a subject that in my view is little discussed, which is how dynamic competition can raise everyone’s game, and for a Product-First company, competition (and raising its level of operational excellence) is almost a question of who survives in the market and who goes bankrupt.

· Disadvantages

• In many cases, engineering optimization takes a backseat due to very full product pipelines or lack of visibility of what must be done. In a simple analogy, it would be like a chef asking for a kitchen renovation because of working conditions, but at the same time, the restaurant owner is satisfied that his business is generating profit despite the problems.
• If you like to go deep into a technical topic (e.g., resolution of world-class technical scenarios) perhaps being in a Product-First company is not ideal, because in the search for the ideal solution perhaps your company is already thinking about another product, another implementation, and many times technically better solutions lose priority due to the fact that new things need to be done;
• A continuation of the previous point is that if things do not have a priority from the engineering point of view in the initial conception, Technical Debt will be the law. This means that every project already starts with a technical debt to be paid and over time interest will start to be a real problem in case of potential improvements and maintenance. This is one of the most common blind spots in projects, given that the resolution of a technical debt many times does not appear in the product backlog; however, its execution can eliminate latent problems in the product that may cause a greater evil (e.g., downtimes, security vulnerabilities).
• And since Product-First companies deal with final users most of the time, when things go wrong, they will happen in the most tragic way possible and the pressure both for delivery and to fix something wrong is almost permanent when working in a Product-First company.

But does this really matter?

Well, within what I lived in the corporate environment, it matters a lot. Most of the errors I committed in my career are closely related to the fact of a lack of identification on my part of what type of company I was entering. This fact led me most of the time into a road of frustrations, boredom/boreout with extreme frictions within the corporate environment (all in a respectful scope).

Two situations to exemplify my point.

The first was when I was in an Engineering-First company with a Product-Engineer mentality. At the time I was a BI analyst where I was responsible for the database tuning and DWH part; but what I really wanted to do was to participate in the company’s asset pricing process and do a job less focused on operational optimization and monitoring routines, but rather perform mathematical modeling to predict the prices of the derivatives that I put inside my database.

The second was when I arrived in a Product-First company with a mentality as if I were in an Engineering-First company. While I was doing some more complex business analyses, consulting technical benchmarks, and even implementing algorithms from some papers in our platform, the company simply wanted to leave a very bad solution (in terms of technical debt) and move to the next project (and this with them totally satisfied with the result of the terrible implementation in technical terms).

And why am I putting this? For the simple reason that being in the wrong company at the wrong moment of your career can be something that will not just waste your career potential: it can literally escalate to mental illnesses with almost unpredictable consequences.

Obvious that in many cases there is no way for us to choose our job, but if I had to leave a recommendation I would say know the type of engineer you are at the moment and look for a company that has an approach that has the maximum intersection with your interests.

Final Considerations

Both paradigms have their advantages and disadvantages and these characteristics are not totally mutually exclusive.

However, it is very difficult to find organizations that operate well using the two approaches in parallel. Therefore, if I had to leave a tip, that would be something like the Greek aphorism know thyself as an engineer. This by itself will lead to better career decisions over time and hopefully avoid all kinds of frustrations.

Dedicated especially to Daniel “Oz” Santos who went through with me most of the hardships described in these two approaches (i.e., we lived the disadvantages of the two approaches for more than 3 years) and to Rodolfo Zahn for the conversations that gave origin to this post.

Useful Links

How to cultivate an engineering first culture — from a coders perspective

Product engineers

The Over-Engineering Problem (and How to Avoid It)

Notes

[1] - There is a third type of approach that I have been noticing which are Research/Experimentation-First companies, but that is a topic for another time.

[2] - This post does not have as its main point to talk about projects themselves or specific businesses, but to discuss these two approaches that in my view define well the market for engineers, data scientists, and other data professionals. This argument can be extended to other areas, but here I will speak specifically for the data and IT audience in general.

[3] - And as you already know I was made literate in the worst educational system in the world and my mind speaks much faster than my fingers and the desire to review this is as high as a lying piece of paper, so disregard all errors committed.