Posted 2020-04-10 22:00:00 GMT
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
There are many other roles, like product specialist. And in the end, people fit themselves into different shoes touching on different aspects.
Post a comment