Engineering teams: what and how

I’ve recently been traveling and speaking with engineering teams in different organizations. These organizations are some of the top technology companies in the world with relatively mature development processes. Occasionally I’ll run across teams full of smart people and regardless of the company they’re a part of, they’ve forgotten some fundamentals. In my experience, if you have the fundamentals, just like with most things in life, the details will get sorted. In this instance, I’m not talking about the technical details of architecture, testing, etc. I’m talking about team dynamics and the ability to get things done. Team-based software engineering (the only way to build products, not just projects) is made up of two main areas: What you build How you build it I’ve seen teams be so consumed with one that they forget the other — in either case they don’t succeed. How you build it is as important as what you build The most common case is teams become so busy foc

Scaling distributed teams

The idea of distributed teams is nothing new. Over the past decade, having remote workers has become commonplace. While it used to be a co-located team with a couple of remote team members, it’s now common to find entire teams being distributed. Often organizations manage distributed teams in the same way they manage co-located teams. They pick a development model that fits with their organization, substitute a work tracking tool for face-to-face accountability, and hit the ground running. For a small team, this works fine. They’re self-organized enough that inefficiencies bubble up and just a little bit of process and organization smooths out the rough edges. The problem comes when you try to scale. Typical Even though an organization may be fine with distributed teams, they typically try to scale just like they would if the team were co-located. This usually involves: Generating documentation around the project for new team members to read Establishing an on-boarding pl