Your tools affect your organization, and your organization affects your tools

I do a lot of work with technology companies and divisions, which makes it ironic how I often weakness in tool selection. Tool selection is generally viewed from either a vendor-relationship perspective determined by the C-level in larger firms, or technical features determined by a niche specialist in smaller firms.

Tools are meant to be used by individuals in concert with others, i.e. an organization, which means that tools have a significant impact on organizational workflows. Yet it is surprisingly rare that I see tool selection on the basis of organizational impact.

To highlight, I will give two examples, one from software management today, the other from financial management in the coming days. In order to avoid endorsing any specific tool and later being told, "you said this would be good," I will discuss principles, not specific solutions. If you want solutions that work for your organization, reach out to me.

You have a software development organization with 20 people. If this is one of these hot Web / mobile firms, then you have two main components: the server, written in one of the hot server-side technologies such as Ruby or Node, with a well-defined interface; and the user interface (UI), either Web or native mobile client (iOS or Android). In order to allow each element to develop at its own pace, you have at least two teams: UI and server. The teams may be further subdivided by components or products. Finally, you have quality control / engineering / assurance (QA), either embedded within the teams, or as a separate team. Even if embedded, it is likely you have (or should have) a QA "tools team" to provide tools to the development teams. Alternately you may be organized around product, having one team working front-to-back on one element of the product, and other teams on different parts.

Your organization's ability to succeed will depend on leadership, of course. It will also depend on how your software is designed, whether or not there are well-defined modules and interfaces between server and UI, and between elements of the server and elements of the UI. But it will also depend on the tools you use to manage software development, primarily your build system and your version control system. Do they allow different groups to work on the same project at the same time? Where are the boundaries between projects / repositories? Can you build part of the system which is ready from one group, and combine with an earlier part of the system from another group? How well can the teams work without coordinating?

Since your organization and management are much greater determinants of success than specific tools and technologies, these elements are far more likely to determine your success than whether or not it runs on Windows vs. Linux, whether it integrates with this or that login system, and whether or not it provides reports in Excel or PDF.

Always determine how your organization should run, and make those workflows a requirement of your tools.