By Hal Howard

People are social creatures. We need to belong. We use all sorts of descriptors to describe that belonging. I was born in that town or country. I went to that school. I live in this neighborhood. I work for this company. This list goes on and on. For the most part, it’s a simple way to describe who we are.

In the workplace, we create similar groupings. For the organization I lead, the most common groupings are product, location, feature area, and job discipline (developer, tester, program manager, …). These labels describe us and give a sense of belonging. Every person on the team can be described in part using these descriptors. Jane is a developer working on core finance in Fargo on GP. Carl is a tester working on inventory costing in Copenhagen on AX. And so on.

Unfortunately, they sometimes also define walls that can become a barrier to successful teamwork and limit our overall effectiveness.

If Jane and Carl draw too hard a barrier around any of those attributes then they may never find a reason to work together. It could very well be that Jane is also an expert on testing systems involving the validation of complex datasets; a problem for which Carl is currently trying to find a better solution. If Carl erects barriers that say I’ll only ask other testers for their opinion or I’ll only ask people that work on AX or I’ll only ask people in Copenhagen then he’ll lose the opportunity to get Jane’s input. That could well result in a suboptimal solution or costly reinvention.

As the managers of a large organization, my leadership team and I are constantly faced with situations like the one above. We can’t simply say please solicit input from everyone on everything. Nothing would be accomplished. Individuals would be overwhelmed with requests, a large percentage of which they should and would ignore. Our task becomes understanding the capabilities and experiences of our team members in a much more granular way than their current assignment, staying open to input from across the organization, and connecting the dots; then enabling team members to get credit for helping each other and for accepting help. It sounds easy, but it’s not. It requires constant vigilance and constantly re-examining our own definition of the barriers.

The other problem created by hardening these barriers is limiting the organizations ability to take on new challenges. When we plan the next wave of development in our organization, it could well be that we’ll need fewer developers in a particular feature area on a particular product. That means that the developers on that feature area/product combination could be needed to do a number of things: test the same area on the same product; develop the same functional area for a different product; or learn a completely different task, in a completely different area, on a different product working closely with people from another location.

Again as the leaders of a large organization, we are faced with the situation above on an ongoing basis. Customers prioritize their needs without regard to the capabilities of our teams. We are required to grow new capabilities, reorganize work, and ask individuals to take on new challenges. Supporting a learning culture and hiring and rewarding team members on their ability to adapt is required. Maintaining the right balance of expertise and flexibility is important. Assessing organizational and individual capability and bringing in new talent and expertise is also a must. Having a strong system for on-boarding new team members and making them productive is critical.

In our case, having a strong engineering system that spans products, common metrics for measuring success, and simple things like common terminology for describing the state of a project enable people to adapt to new challenges without losing all sense of belonging or productivity. We are constantly working improve these systems.

I’m sure teamwork is also required in your day to day work. I hope the above examples give you cause to examine the barriers your organization creates and what you can do to manage them for good of your organization, your team members, and your customers.

Best Regards,

Hal Howardd
General Manager
Microsoft Dynamics R&D