Software Engineering, Project Management, and Effectiveness
I was white boarding and naming some team execution patterns the other day with a few colleagues. Here's what we ended up with:
Just because you're on a team, doesn't mean it's teamwork.
I've seen the good, the bad, and the ugly when it comes to leading teams. I've built new high-performance teams from scratch, every six months, for more than ten years. Even more importantly, these were high-performing, distributed Agile teams, where we had to rapidly go from forming and storming, to norming and performing. What I've learned is priceless, and I thank my lucky stars, that I had the opportunity to experience so many execution patterns, and really find out what works and what does not, but more importantly *Why* and *When.*
At the white board, I walked each pattern above and highlighted some key points and lessons learned …
Core Team With a "Core Team" model, you are funded or staffed as a team dedicated on the problem. You are a "team of capabilities." This is where the best synergy and focus can happen. It's also where people can find ways to spend more time in their strengths.
The most effective pattern I've seen here is "resource pools" that come together as project teams, with the right experience, skills, and capabilities. They are dedicated on the project, and they work the project as a self-organizing team.
“One-Man Band” + Best Efforts In the "One-Man Band" model, or "The Hero Model", somebody does a job, as a "team of one." The problem that often happens here is that the job actually requires a "team of capabilities." While the individual might be good at XYZ, the work requires being good at ABCD, EFG, and XYZ.
When the work truly is a one-person job, no problem. But often the pattern I see is that instead of having a few small teams of capabilities, teams are split into operating like "One-Man Bands." The “Best Efforts” part is where the “One-Man Band” spends a lot of their time trying to convince, cajole, and influence without authority to get others to contribute their “Best Efforts.” Depending on the nature of the work, while this can be effective, it’s not usually very efficient, and timelines stretch on (and on, and on, and on.)
A simple way to see the problem is that if there are five problems and five people, then each person gets a problem. The opposite approach would be five people work problem #1, then problem #2, etc. or split into two teams and divide and conquer. This is actually a big deal because when it comes to knowledge work or information products, people get bottlenecked all the time. It's rare to find the individual that has great project management skills, deep expertise on the problem, great marketing skills, great customer focus, great business sense, etc. But when you pair people or create focused mini-teams, magic happens.
The thing to keep in mind is that this is not about hiring more people, it's simply shifting the mix, and changing strategy in how the work gets done. It's SWARMing on the work, and building momentum, versus creating "One-Man Bands" with single points of failure.
There are exceptions to this, obviously, such as when it's "weird work" that's hard to streamline, or mature and optimize, or when you don't have the right mix of skills for even mini-teams. That said, if you have serious and significant bottlenecks, you might look at how the work gets done.
vTeams The majority of vTeam work that I see often fails. It fails when the work is not a priority. It fails when there are no rewards for people that contribute to the vTeam. It fails when the work is not valued. On the flip side, vTeams succeed when they find mutual goals. vTeams succeed when the work is a priority -- meaning, it's literally a commitment with a P0 or P1 priority rank.
One mistake I see is when people think that you can "buy" vTeam members. I've seen many, many vTeams where people's time was bought or paid for, and yet the work still didn't happen. It was not as high a priority as the person's day job, and it was a spare activity, that even though it was funded or paid for, they were not really committed where it counts. They were simply committed with dollars.
“Community Will Do It.” One way that people try to get work done is "Community Will Do It." There is a lot of truth in the saying, "You get what you pay for." Sure, the community will do it. They will do what they value, on their timeline, and what they are passionate about. You can't expect anything more. Well, you can, but at least don't be surprised when the work is not done the way you expected. After all, it was "best efforts."
A better approach than “Community Will Do It” is, “With the Community.” That’s the approach we used on the Microsoft patterns & practices team.
Matrix Projects Another common model that teams use to get work done is matrix projects. What I've seen this usually turn into, is a whole lot of status, and not a lot of results. The irony is, the matrix project turns into matrix spreadsheets and tracking. The overhead added per person, and for the team in general, creates a lot of below the line work, and very little above the line value. All the energy goes into coordination, updating, and tracking, and very little is left for working the tough problems, solving the key challenges, and flowing value. After all, now you have a collection of agendas that is more like a quilt, and less like a blanket. Sure there are exceptions. The funny thing is, though, I've never seen one.
How the Work Gets Done The moral of the story is that whenever I take on a job, or whenever I mentor somebody, or coach a team, I first find out, how does the work get done. Any time that there are serious and significant bottlenecks in the system, it's almost always a matter of how teams are structured and how work is planned and executed.
It's always a fertile ground for opportunities and optimization. So if you are bottlenecked or your team is bottlenecked or you just want to build high performance teams, look for ways to shift the mix.
You can always do a lot more with less, if you work smarter, not harder, and together, not alone, if you can put "just enough" systems and process in place to support smart people, versus break them, get in their way, or make their talent null and void.