One of my fundamental beliefs is that how you organize your engineering teams to be as close to the customer and to the product development as possible will make a huge difference to the end product. And it’s not just the speed of development but also the quality and care of the product.
One of the first things I noticed in my startup era was that there was a real sense of purpose and understanding of everyone’s place in the overall success of the company or product, and the people on my team had the agency to make decisions from an architectural and implementation point of view that drives towards that success. Within the more established “enterprise” teams that I’ve worked with, they were given instructions on what to build and when it needed to be built but had minimal context in understanding the goals.
Have you ever heard people talk about how certain products feel well-designed and enjoyable? A common thread that I’ve noticed is that they are usually organized using cross-functional teams consisting of software engineers, product owners, designers, and QA members and the teams are given clear goals on how what they are building will solve a specific problem.
Compare that to the other pattern I’ve seen where teams are siloed and information is dropshipped or thrown over the fence in an assembly line. One group does the market research and identifies the top capabilities and needs, the next group takes that and breaks it down into epics and stories, and finally, the engineers are given detailed instructions on what to build – all the while no one really understands the entire end to end product development process. They just know their part, and context is lost along the way. This leads to constant delays as communication is stripped and all knowledge is siloed. Imagine the worst of the game of telephone and parable of the Blind men and an elephant.
Key takeaway: Keep engineering teams close to the customer, understand the why of what they are building, and give them a seat at the table. Install a bias for action along with strong communication, and a culture of openness and transparency. When fear of repercussions is removed, teams can avoid excessive process and focus on agile, flexible, and rapid product development. While some process is necessary for accountability, it should never become a barrier to innovation and quick decision-making.