Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Dec 10, 2008 — Enterprise Agile Planning expert

(Tools != Community) && (Community != Tools)

Enterprise Agile Planning

Like any company in today’s world, CollabNet keeps pretty close tabs on sites or blogs which affect our products or our clients.  Recently, our CEO, Bill Portelli, forwarded along a link to the Department of the Navy’s CIO Office (DON CIO) blog.  This is related to the DISA project I blogged about previously, and the most recent post there (‘Trust: The Most Important Thing‘) contains a very telling quote:

"…while information technology affords us tremendous advances in transparency and information sharing, our organizational behavior and culture actually prohibit it."

This single statement struck a nerve in my mind about how organizations and the people that manage them sometimes equate the building or acquisition of tools with the building of communities and collaboration.  To most folks who have any knowledge of Open Source communities and their inner workings, this would seem to be clearly not true.  By the way, I beg indulgence of the non-technical folks reading this blog with regard to my title – the engineer in me still exists and the title above is a shorthand for ‘Tools do not equal Community, and Community does not equal Tools’.

In reading through DON CIO’s blog, it is clear that he comprehends that his organization needs to understand the path to collaboration, transparency, and information sharing does not go through which tools they choose.  It runs much deeper than that, and I’m thankful CollabNet’s senior staff and field organization generally understand that to be successful with a client, you need to take an approach advocated in the book Samurai Selling: The Ancient Art of Modern Service – specifically, making your client successful is the ultimate goal, and making them successful means considering how your tool/service is most beneficial to them.  In some cases, that may mean your tool isn’t the most appropriate, but maybe your service offering is, or maybe you have to integrate with a competitor’s tool to further develop the client’s community.  It also means you should be prepared to guide them in the best practices they can utilize to help steer their organization down a new path where the organizational culture/behavior can evolve to take advantage of the tools that enable better collaboration.

In the end, understanding you have to take into account existing company cultures, behaviors, and norms is critical to building a successful community, and making sure that is your primary goal as an organization, not the pushing of a tool at the expense of service, will help make you (and your client) more successful in the end.

Note – just found Richard Millington‘s Online Community Building Manifesto, which speaks nicely to some of the things I mentioned above. 

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us