Every Function in a Company Should Have Embedded Software Engineers

Prototyper

Earlier in my career, I did a short stint in the UX team, reporting to a design manager. I worked as a Prototyper. It involved helping the design team understand technical tradeoffs better. Or build demos to explore UX concepts. I used my engineering skills, but in service of design goals, rather than engineering goals like launching features.

This is an interesting job because a Prototyper isn’t burdened by all the things frontend engineers are: edge cases, error-handling, latency, responsiveness, internationalisation, security, privacy, performance, reliability, supporting different browsers… You just build the core of the product, the 10% that’s interesting and novel, and forget about the rest. For example, you don’t even need a Log Out button — users can reinstall the app to log out. After all, it’s a prototype, not a product to be shipped to real users. In any product, only 10% is the innovative stuff, and 90% is obligatory stuff. Freed of this obligatory work, you can go 10x faster. For example, you could have something ready for a user study by tomorrow, not a month from now.

Sales Engineer

Similarly, the sales team could have software engineers whose job it is to achieve sales goals, such as implementing features that the sales team cares about more than the product team.

For example, if only one customer wants something, albeit a high-paying customer, the PM may decide that that’s not important to work on. But sales may feel otherwise. Ultimately, prioritisation is a matter of opinion, and rather than this situation becoming a conflict, it would be good to defuse it by empowering the sales team to implement things. Every team should have the resources it needs to deliver its goals.

Another situation is one in which the PM picks one or two high-level priorities for the team for this month or two. For example, improving the first-run experience and the UX. From one point of view, such high-level prioritisation is critical — if the team tries to do everything at once, it’ll achieve nothing. But let’s say a customer has made a bunch of requests, many of them useful to other customers, which should have been in place to begin with. The team doesn’t have a chance to implement these requests, because these are out of sync with the higher level priority. So the customer threatens to leave. At this point, if the sales team has a software engineer embedded within it, they can pick some of these requests that are quick to fix and fix them, to retain the customer.

If the sales team does not have an embedded software engineer, and they’re told to wait for two months, it will lead to a conflict, because both sides are right from their point of view.

Another situation is one in which the sales team’s request does fall under the current team priorities as decided by the PM. But if the request comes midway through a sprint, sprint discipline does not permit disrupting the sprint, so the request will have to wait for a couple of weeks. The request can get implemented in the second sprint, but it may turn out that that’s not exactly what the customer wanted, so a change may be made, in the third sprint. Now the customer has waited a month and a half for what they perceive to be a trivial change, producing an impression that the startup is slow and unresponsive.

In all these situations having a software engineer embedded within the sales team can help the sales team (and thus the company) achieve its goals better.

Marketing Engineer

In addition to design and sales, marketing could also benefit from having a software engineer, say to build a standalone tool whose only purpose is to introduce customers to the main product and hopefully drive traffic.

Hiring Engineer

In a big company, the hiring team consisting of a hundred recruiters could also benefit from a software engineer to ease their workload, such as automating repeated manual work. If an engineer can make 100 recruiters 10% more efficient, that more than pays the engineer’s salary.

Benefits of this Model

When you’re multi-disciplinary, sitting at the boundary between two functions, new opportunities open up for you to do valuable things that nobody else can do, because they look at it through only one lens — engineers from the lens of building production-quality systems, and designers from the design lens.

People often don’t understand what it’s like to perform a different function from theirs. This lack of empathy causes criticism, like “Engineering is taking too long to do such a simple thing!” This, in turn, causes collaboration to break down. Having people work at the boundary between functions helps create this empathy.

Practical Aspects

For this model to work, the following aspects should be taken care of:

First, an engineer embedded in a different team needs to report to that team, not to engineering. That way, the engineer won’t be pressed into service to do regular engineering work when things are tight, which is always. And this reporting ensures that engineering skills are applied in service of the other function’s goals, such as design, rather than overpowering the respective function’s way of thinking.

Second, for this model to work, you need an engineer who’s senior and mature, who understands that his job is to deliver business value, not build cool stuff. Many engineers in the first five years of their career have a rather rosy, intellectual, academic view of themselves.

Third, the manager of the engineer should be cross-functional enough to understand engineering. They should understand that for this arrangement to work, they should cross the bridge and go half the way to becoming engineers themselves. The onus can’t be entirely on the engineer to adapt to their way of thinking. In fact, because the manager is more senior, the onus is more on the manager to adapt to the engineer rather than the other way around.

If you’re in doubt whether someone is cross-functional enough to manage an engineer, ask them to buy a Linux laptop and use only the command-line such as apt-get to install apps. Ask them to set up and administer a server in AWS to host their web site, coded up from scratch in raw HTML and CSS, without using any WYSIWYG tools. Ask them to learn SQL and use it to analyse the product metrics using something like BigQuery.

If their reaction is “Why are you telling me all this? I’m not an engineer!” or “This is interesting, and I want to learn it, but I can’t take time away from my marketing / sales / whatever priorities” then they should not have engineers reporting to them, because they won’t do a good job of managing them.

Fourth, an engineer committing to the codebase should follow the same standards as the core engineering team, irrespective of which department he reports into. For example, if the engineering team requires code reviews, or unit tests, or documentation, or whatever, a sales engineer can’t bypass these, say because their manager asked them to get something done today. They shouldn’t create more work for others. They shouldn’t do work that conflicts with work already planned. Engineering should sign off on the person’s skills before hiring them.

Fifth, Many engineers don’t like reporting to a marketer, salesperson or designer, for valid reasons. To assuage this risk, a plan B should be put in place, namely that if reporting to a different function doesn’t work out, the engineer can report to an Eng Manager and become a normal Software Engineer, working on implementing features and other regular engineering work, rather than working as a Sales Engineer or Marketing Engineer or Hiring Engineer. That’s better than the engineer leaving the company. Or not even joining in the first place.

Consulting CTO. Earlier: Google | Founder | CTO | Advisor