Building strong collaborative development teams

Early learnings

In my personal life, I am a self-admitted me first person. Of course, this has evolved as I have gotten married and had kids so not as extreme as when I was younger. However, in my professional career, I have embraced the concept of “we first” approaches to collaboration and motivating colleagues to achieve team success that could not have been accomplished in a “me first” environment. The origin of this transformation started in the late 1990’s when one of my managers at a startup, educated me on the power of the term “we” and how to remove the words “I” or “me” from work conversations. We talked about how this could be applied to discussing product deliverables, demos and even the dreaded discussions around code defects and website crashes. This very brief but insightful conversation has become a foundational component to how I rate great teams as I have worked a companies ranging from about 5 employees to today at over 400,000 employees.

Approach to team building

One of my passions is cutting edge technology. IBM is famous for creating small incubator teams that eventually evolve into large globally distributed teams. The missions of these teams is to identify a market opportunity and establish themselves as market segment leaders. The goal for development teams is to deliver amazing technology with Subject Matter Experts (SMEs) that become industry thought leaders in this technology.

When we build teams, there is a strong focus on having well rounded developers. In our missions, we desire to form teams of developers that are all willing to present at conferences, willing to learn new technologies and also willing to work collaboratively with other teams (both local and remote). The idea is that these characteristics are traits that we see in strong teams and also allows us to give our team members the foundations to expand their skills.

We have often seen teams that are very focused on a single aspect of a product and not very aware of the overall product capabilities. In our model, we have a variety of developers with different experience levels that have demoed the end to end product to a variety of stakeholders including executives. The idea is that if we can demonstrate consumability and ease of use our capabilities by having all of our developers understand the overall mission, it becomes easier to show this value to our customers. As an added bonus, developers can empathize and understand pain points in user flows and can collaborate together to reduce friction between teams.

Pivoting mission and resources

Being part of an incubator is not always spectacular. If one follows the Lean Startup methodology, you will come to love and embrace the concept of pivoting. The teams I have been part of have definitely pivoted more than their fair share. In this “we first” environment, our teams focus on how we can quickly adjust to the market and move forward. In this model, team members that have embraced new technologies and are willing to collaborate always come out on top. As our teams typically start small and grow, we often rebalance teams and formalize leadership roles both within an existing component as well as establish new components. We have even quickly shifted to a completely different incubator with a target of having a demoable proof of concept in two weeks.

Technology choices

When it comes to technology choices, we have seen a bottoms up approach to technology gives the development team a much stronger sense of ownership and investment in any mission. In this model, we have implemented more of a decentralized adoption model where the developers collaborate across the given teams to determine best of breed technologies that can accelerate our development efforts the most. What we have found is that teams evaluate tools across a variety of criteria ranging from ease of use, code quality, and external adoption. By removing the friction that often comes when dictating solutions to teams (not uncommon for companies to dictate tech choices and this typically fails), our developers instead spend time educating teams on the benefits of these solutions and become promoters and SMEs of these tools throughout the larger organizations often acting as change agents for the company.

Agile approach

This past summer, our team embraced the notion of self organizing teams for the duration of a two week sprint. Typically our teams are segmented by components and the sprint deliverables within that component. This works great but we felt that we could embrace the “we first” model even more if we empowered our teams to identify the work items from the backlogs and size their teams appropriately. In the end, we found that developers gravitated to deliverables that were outside of their comfort area and in working with other team members with more experience in a given area, developers obtained completely different perspectives on the deliverable and we got amazing results.

If that was not enough to excite you, we also took a different approach to sprint demos. In the past, we had each component team demo their deliverables. What we found is that stakeholders often struggled with the end to end picture of what we were delivering and the value. In the case of internal deliverables, this was even more evident. In our new experiment, we expanded our model around everyone being able to demo to having volunteers each sprint demo the scenario we were targeting for the sprint. In this model, we only demoed the scenario and focused on the value of what we are looking to achieve in this deliverable.

In having a singular vision around a “we first”, developers understood that while every aspect of the sprint work was important, there are aspects that are better suited for external audiences. To emphasize this point, we allocated time at the end of the sprint to demonstrate internally all of the work that was done for a given sprint for a smaller audience that extended beyond the development team but not as large as the stakeholder demos.

Conclusion

In this article, we talked about one organization’s approach to building strong technical teams. The teams were well rounded teams with strong personalities and skills but all had a common vision on how to deliver first class solutions in the cloud. If you liked this article, please read our article “Transitioning to a startup mentality” detailing how we evolved a very large enterprise development team to act like a startup.