John Fremlin's blog: Roles in tech

The Google and post-Google generation of Silicon Valley technology companies force a conflicting position on skills. We want software engineers to be able to think about product choices and product managers to be able to design systems. But then we prohibit some roles from pushing code and stop others making product decisions.

A product designer who can write code is more productive than one who can't, other things being equal, as understanding the system end to end and being able to make small tweaks without asking for help is valuable. However, we generally decide it's not a requirement. Ideally, everybody could do everything.

Of course without maturity, knowing how to do someone else's job leads to snide remarks about how easy it is and overly prescriptive advice — removing agency and the feeling of ownership. In our imagined ideal world, everybody could do everything but also trust and respect each other.

Suppose we were in this ideal world. Would there be specialisation of roles? One day a product specialist negotiates a timeline for migrating off a backend system. The next day a data scientist draws out the screens for a new application flow. They could do this in our imaginary situation where everybody has all the skills, but specialisation is still useful for two key reasons: individuals are bad at multitasking, and if everybody is doing everything everybody has to be in the loop. That imposes inefficient communication overhead.

It also sets up difficult incentives. A backend engineer would love the business to be simple and in fact should advocate for simplicity as the cost of complexity is born most heavily by this role. A product manager must achieve a compromise and so should not too strongly weigh towards one avenue.

In deciding how to split work there are three considerations to trade off.

Context switch cost

People are proud of their ability to multitask and feel pleasure in thinking they can hold the overall picture as well as master details. However, studies consistently show that this proficiency is overestimated.

Different responsibilities have naturally different quality and timeliness tradeoffs, feedback loops, activities and tools. In my experience the highest context switch disturbance comes from changing from an uncontrolled task where the feedback cycle is long (e.g. a pitch deck to powerful people) to one where it is short and there is limited control like debugging why an error is thrown unexpectedly from a backend system.

The context switch is also paid by everybody who interacts with the person multitasking, and is especially confusing if the multitasker is trying to play coordinating roles.

Cost of involving multiple people

Correcting a spelling mistake on an unimportant untranslated webpage is my example for a simple task that should achievable by anybody on the team. Inventing process where a task like this flows through different disciplines and is prioritised by many different people is a waste of time.

A typical structural problem is that few people are familiar with the analytics systems. To answer straightforward questions like, how many customers bought products last week multiple roles have to be involved. This is very damaging as the high cost means people end up with wrong pictures of how things are going.

Sustainable allocation of work across team

Typically more effective people are paid more than their coworkers but not as much as the difference in effectiveness so it's objectively cheaper for the firm to give them all the tasks. But their time should be prioritised to concentrate on more impactful tasks and other people need the opportunity to learn.

Given that and if we take as an example that we're working on a typical consumer facing web virtual goods storefront project, what are the roles and expectations for them? Fundamentally, it is necessary to decide on the purchase and refund flows, etc., pricing of items on the store, and then reliably implement that.

We therefore need product designers to think through the user needs and lay out a broad view of how someone should experience the storefront. Frontend software engineers are responsible for making the detailed choices and implementing a system that works well for customers using the most popular devices. Backend software engineers are responsible for reliably ensuring that datastores powering the customer accounts, shopping cart and purchase records are reliably run, easy to audit, and easy to use for the frontend engineers. Prices are set by the data-scientists.

These roles are absolutely essential and cannot be dispensed with. This does not mean that other roles are not valuable or critical to the longterm success of a business. It's just that one could still make a website without a payroll department.

They also are hard to combine into a single person.

Product designers

lay out how users will interact with the software produced and fit in into their activities. The product designer might use storyboards or Photoshop and need to wait for months for objective feedback, that very often focuses on implementation details out of their control. Therefore design critique and subjective feedback is very important.

The closest essential role is frontend engineer but the work is very different in terms of immediate feedback and tools. The frontend engineer might be experimenting with ways to make scrolling smooth.

To further separate the role, some companies employ UX researchers to orchestrate customer research. This usefully separates a very different set of tools (running surveys and studies).

The output of a designer is a story of how the software should interact with customers. Bad designers miss major consequences, produce impractical incoherent workflows and confuse customers by misprioritising functionality. Great designers lay out a happy relationship between customer and software, simplify or remove workflows altogether, and surface functionality that is so obvious to customers that it feels like it is natural and there is no design.

Software engineers

design, write and operate the software. There are many specialisations, from Software Reliability or Production engineer to Machine Learning Engineer. It's not realistic to switch someone between these specialisations and expect the same level of output but there is a common cycle of implementation, testing and measurement.

Frontend engineers, working on user interfaces measure marketing and interaction funnels, latencies and reliability. Backend engineers measure uptime and latency for their critical workloads. Machine learning engineers measure precision and recall. The work is detail orientated, can get objective feedback quickly and has deep domain specificity.

The output of a software engineer is sustainable improvements to how the software meets its business goals and measurement of that. Bad engineers increase complexity, aim at the wrong level of automation, or make changes that simply do not improve goals, e.g. by crashing the system, and pick uncoordinated tools that will cause problems going forward. Great engineers measure obsessively and innovate to reduce complexity and pick tools that obviate entire classes of work going forward.

Data scientists

measure complex effects and estimate the size of future opportunities. While software engineers run experiments and measure simple interactions like a dollar increase in sales, data scientists measure nuanced effects like customer retention.

It is often hard for engineering managers to adapt to managing data scientists. In contrast to software engineers, where projects may last for months or years, data science explorations typically last days or weeks. Data-quality fixes are easy to describe but hard to discover, and most issues are out of the control of the data scientist who must beg for logging fixes and improvements to data query and ETL pipeline systems.

The output of a data scientist is improved decision making. Though the decision making process may involve other functions, the quantified measurements and opportunity sizing from data-scientists guides what should be worked on. Bad data scientists run experiments that depend on broken data sources to produce misleading, inaccurate statistics and miss major effects. Great data scientists identify the most valuable data sources, obsessively debug and cross-validate to get accurate statistics, and run experiments that indisputably identify long term opportunities and risks.

Product managers

bring all the functions together, build agreements on the compromises needed to ensure good business outcomes are delivered. They set up swimlanes and parameters, so there is trust that each group, with its necessarily different priorities, will not cause trouble for others.

Knowledge workers work better when they are bought into and understand the rationale behind their efforts. So everybody needs to have a say in the goal setting and prioritisation of projects.

Product managers are responsible for finding and then articulating a compromise between all the competing interests and pressures. To be effective at this and trusted they must avoid insisting on an agenda themselves — inspiring end goals are good, but, crucially, pushing a vision that people disagree with is the opposite of compromising.

The person responsible for driving these compromises might hold different roles depending on the nature of the project. Business facing projects typically have a product manager in this role. However, most tech companies do not have product managers in infrastructure teams because high technical skill is needed to understand the compromises, and people will not trust a generalist, so this role is played by tech leads, TPMs and engineering managers. The product manager has to be enough of a domain expert to be trusted by everybody, and therefore must be able to write queries and code and clearly articulate back an understanding of their partners' difficulties.

The output of a product manager is a working agreement between the other functions and shared expectations around a common plan. Bad product managers try to bury disagreements, fail to find compromises, and seed distrust so everybody wants involvement in every decision of every other, and each group articulates different goals for the broader effort. Good product managers broker compromises, let everybody feel heard, and foster trust so that decisions can be devolved to the right group of experts who can excel in these swimlanes, and everybody articulates the same goals for the broader effort.

Line managers

are responsible for balancing the needs of projects against the needs of the people available to work on them and advocating for scope changes and people allocations as appropriate.

They need to balance career growth, the business need for basic tasks to be completed, and likely hiring needs.

To do this and by trusted by their reports, they must be able to understand not only the immediate tasks but also have ability to look ahead, as moving people or hiring or firing take many months.

The output of a manager is the quality of employees doing useful work. Bad managers lead to people doing irrelevant tasks and failing to address important ones, potentially keeping people superficially happy but losing better employees and retaining the worst. Great managers inspire people to achieve business results, set the right size of team for the future, quickly manage people into places they will be productive and happy, and retain and attract better employees.

Tech leads

ensure the software components work together to deliver business value. They evaluate the technical quality of contributions and contributors, helping managers understand who is performing well, who is stuck, and where there are gaps in planning that need to be addressed. The tech lead identifies and communicates a prioritisation of problems and opportunities and the plan to address them.

Tech leads need to be trusted by the engineers they are working with, and when implementing engineers are stuck the tech lead is often expected to jump in and unblock the problem.

The output of a tech lead is the quality of the whole system they are responsible for. Bad tech leads do not balance between investment and quick results and skew to extremes either late or very buggy, and ship uncoordinated components that contain unnecessary duplication (e.g. multiple login systems), and cannot explain clearly how major business problems will be solved. Great tech leads allow innovation while shipping reliably, help all teams use similar vocabularies and build trust and encourage re-use of the right components, and clearly communicate how problems should be addressed and why priorities were chosen.

Technical program managers (TPMs)

make life unsurprising. They communicate with all stakeholders, surface issues early and share timelines. Bad TPMs continually cycle through new spreadsheets and JIRA projects, are unaware of the shadow structure of decision making in the organisation, allow people to escape accountability and ignore red flags. Great TPMs constantly update one clearly communicated system for long periods, dig deep at the first sign of trouble, know exactly what's going on, and leave have everybody feeling like they own their timelines but somehow they all fit together.

There are many other roles, like product specialist. And in the end, people fit themselves into different shoes touching on different aspects.