A Problem-First Approach To Building Engineering Teams
Many people would say by the technology they use. That’s what most of us are used to: Backend on the right, Frontend on the left. But I think we can aim for something more ambitious: that tech companies should be split into teams by the problem they solve.
It is extremely difficult to meet deadlines. And I think that’s because information isn’t being channeled correctly. Expertise isn’t accumulating where it should, and feedback transmission is lossy.
In Designing Payment Applications, I made the observation that successful software teams are given enough and high quality context to do their work:
Savvy CEOs don’t veto technology they don’t necessarily understand. Instead, they provide access to the multiple and overlapping contexts on which that technology operates. It’s also access that engineers most often don’t have. Who are the stakeholders? What can they do with that technology? How is the company positioned in the market? How does it make money? Who is the user they cater to?
Though correct, I missed the opportunity to address another communication problem: what if the necessary context is something much more tacit, beyond what the CEO needs to be concerned with?
