Those unfamiliar with what product engineers do could be forgiven for assuming that it’s all broadly the same job. After all, we all tend to work in code, use black text editors with luminous text, and stare at console windows with endlessly scrolling symbols.
But making the transition from consultant engineer to a product engineer was a revelation – I realized that working as an engineer in client services and working as a product engineer are essentially two completely different jobs, bridged only by the common use of technology.
Before joining Intercom, I worked exclusively as a consultant engineer, and got a broad range of experience first with an extremely large consultancy firm and subsequently with a very small client services based software house.
The shift from one type of job to another has highlighted for me the stark differences between different engineering disciplines. The role of a “product engineer” at Intercom involves a strong focus on the product, understanding our customers and how they use our software. By “consultant engineer”, I mean an engineer developing software for a client (which is again different from being an independent contractor).
Being a Consultant Engineer
Very often when working as a consultant, you will work on projects billed as either “fixed price” or “time and materials”. Both of these models can present challenges to the engineer.
The client naturally will be expecting detailed breakdowns of what they are paying for
A “fixed price” contract means that the price is agreed at the beginning, regardless of how long it takes. In this scenario, the contracting company will always aim to finish the work as soon as possible in order to move the engineer on to the next project. If a project begins to run over the time initially allotted to it, the engineer may be put under high pressure to deliver something that was initially underestimated. Either way, the engineer is under pressure to work fast.
In a “time and materials” billing scenario, the incentives are different – instead of agreeing a final price upfront, the contracting company bills the client for the work of the engineer, typically at an hourly rate. The client naturally will be expecting detailed breakdowns of what they are paying for. This puts an emphasis on reporting issue count metrics and milestone completion, while the engineer has to complete time sheets. This level of accountability can be a mixed blessing, often resulting in pressure to work on things that are less technically critical but more visible to the client.
The Fast-Cheap-Good triangle
In almost all consultant projects we have to consider the Fast-Cheap-Good triangle. The premise here is that you can only have two – and you will always face a trade-off as to which two.
This trade-off often leads to mountains of tech debt
From the engineer’s perspective, we almost always want it to be at least good. Fast is fine – we can spin up a large team, we can hire in top class people and get it done, but it won’t be cheap. Also, we can do good work with a smaller team, over a longer period, for relatively cheap; it might be slow, but that is also fine with us.
Unfortunately, there is a disconnect here for businesses. Businesses always want it at least cheap and almost always want it finished already. So you guessed it, it can’t be good. This trade-off often leads to mountains of tech debt.
Now, in reality, it’s not always this bad. Having detailed requirements and top notch project managers who shield engineers from the messy world of business politics can make consultancy work seamless for the engineer. Equally, you may get the opportunity to develop on green field projects with the latest tech and get to design some very cool things. Finally, this approach actually suits some engineers who don’t need to feel so invested in what they code, but enjoy the varying challenges of consultancy work.
Absence of ownership
Ultimately, however, a consultant will face the same underlying dilemma – you are spending your time working on a system that neither you nor your company own. You are delivering value for someone else. As a result, there is often no real sense of ownership in the work you do. You often will find yourself implementing features that you don’t particularly care about and might disagree with. You might be building something cool, but ultimately you can feel more like a billable asset than a valued contributor to the product.
Being a Product Engineer at Intercom
That is most certainly not the case at Intercom, where you feel an extremely high degree of ownership over your work. Without the external pressure contract agreements around deadlines and pricing engineers are freer at times to spend time figuring out the best way to do things and the best direction for the product.
The sense of sacrificing quality for expediency is rare to non-existent
This doesn’t mean there are no longer trade-offs in the Fast-Cheap-Good triangle, but the tension between the different sides of the triangle is very different – mostly, the balance is between shipping product fast and incurring tech debt. There are stresses and pressures, of course, but the sense of sacrificing quality for expediency is rare to non-existent.
Another element that makes being a product engineer special is that you are no longer just an engineer anymore. You are now also a product person. This might seem like hyperbole, but it does have a real tangible meaning and a defined impact on your job. Your main concern now has to be delivering a great product. You are not just tasked with building what designers have come up with, you are tasked with using your engineering knowledge to inform the design. With this voice in the development of a product, there is far more weight and scope given for the engineer to make incremental improvements.
Ownership leads to responsibility
Ultimately, it is this sense of ownership that really marks out product engineering from consultancy work. In general people will tend to care more about things that they feel they own. For the engineer, ownership can mean taking extra care to make sure something is done the best way possible.
Continued ownership means that iterative improvements are far more likely – nothing is perfect the first time it is built, after all, but engineers who feel a sense of ownership will actively strive to keep making what they have built better. The extra responsibility for the software you build marks the fundamental difference in being a product engineer.
All the different variations of engineering have their own rewards, and their own drawbacks, but having made the transition from consultant, I feel the satisfaction you can get from being a product engineer at a company like Intercom is unique.
Comments