Components of a Technical Organization


I've worked for many years in the technical/software industry and over that time I have frequently pondered the question of what makes one technical team so good and so effective while other seem to constantly struggle. What is that secret sauce? Is there one particular thing that certain teams have that others don't?

The answer is, of course: No, there is no one silver bullet that magically makes a team effective.  Rather, with a high performance technical team there is delicate balance of a variety of pieces all coming together in just the right mix.  An efficient, effective and successful technical organization consists of great people working within a set of processes using appropriate hardware and software with access to the right data/information in order to accomplish their goals.  If one or more of these elements is out of balance, the team and the ultimately business as a whole will suffer.

In the following sections, we’ll take a very quick look at the all the various components, what their characteristics are and how they all fit together.

People small 

People

The people are the most obvious and clearly the most important component of any organization, regardless of whether it is a technical organization or not.  Without the people nothing gets done.  That is, of course, blindingly obvious.  Every other component of the technical organization is focused on making the people as efficient as possible.  However, when all of the other components are lined up perfectly, the business must not lose sight of the softer side of staff management.  For instance, arm a technical organization with all the tools, process and data it needs to succeed but fail to provide them with a vision and a clear direction they can relate to and you will likely find that the team fails to reach its potential.  One must also take the motivations and needs of the individuals as well as those of the team itself account.  To keep any team working well, leadership must always keep the needs of the individual, the needs of the various teams and the needs of the organization as a whole in mind.

Process small 

Process

We've looked at the people in an organization and how they are the force that actually makes work get done. The processes in the technical organization define how things get done and the rules by which everyone must play. Think of the processes as the rules of the road that the organization and the business itself use as it goes about accomplishing its goals. Process, in my opinion, should be as fluid as possible. The stewards of the processes (typically the technical leaders) must constantly monitor the processes making certain that the processes serve the needs of the organization rather than the business being a slave to the processes. If a process is found to be a barrier to accomplishing the goals of the business, that process most likely needs to change.

An additional aspect of process is its role in capturing the collective knowledge of the organization. Organizations that lack appropriate processes tend to depend heavily on what can be referred to as “tribal knowledge”. While relying on “tribal knowledge” often appears to be the easiest and seemingly most efficient way to do things in the beginning, it leaves the organization and ultimately the business itself open to significant damage when critical knowledge disappears.

Defining and evolving the processes that run the organization is no small task. Too little process and the organization will be in a constant state of chaos. Everyone has seen the damage that lack of process can cause to even the smallest of projects. Too much process and the organization will be paralyzed by rules and unnecessary bureaucracy. Finding this balance and maintaining it over time, while one of the more difficult tasks, is critical to the long-term success of the organization itself.

Tools small 

Tools

People make the work happen and process defines the rules by which that work gets done but the organization needs tools to do that work. Every piece of software an organization or the business itself uses is a tool for accomplishing work. Tools allow a programmer to write his/her code. We use tools to track the defects that are found in our applications. Tools monitor the hardware and alert the operations staff of potential issues.

A healthy organization will maintain an inventory of the tools that the business or organization is using and how those tools add value. This inventory allows you to see the overall landscape of your technology tooling and understand if it is meeting the needs of the business.

Obviously, selecting the correct tool for a given job is crucial. This is as true in technology as it is for anywhere else. You can use a screwdriver as a chisel and it might work but...its not what you want to do. Using the wrong tools for the job can be (and usually is) just as disastrous for a project as having the wrong people or a poor process. Also, just like process, the tools a business uses will constantly evolve. A growing business will invariably outgrow one solution and need to move to another. Retooling is inevitable. Keeping the tooling functional and relevant to the business is a constant task.

 Infrastructure small

Infrastructure

Infrastructure is probably one of the most neglected pieces of the equation. To some extent that’s not too surprising given that the infrastructure is often also a component that’s only understood by a relatively small group of people. Frequently a significant portion of the infrastructure lies behind a locked door (or in the cloud) where no one can actually see it. However, arguably more than anything else, the infrastructure is what ties together all of the other components of the organization. Without it, nothing works.

Give some thought to what happens when proper attention is not paid to this piece of the puzzle. There are the obvious problems like aging hardware causing team members to lose time but things go far deeper. Consider how much time the team spends maintaining and configuring infrastructure components. A tool can fail, an individual staff member may leave the company or a single process may not serve the business but often a single infrastructure failure can cause multiple other components to stop working all at once. Infrastructure failures can and will impact the entire customer base more frequently than any other sort of issue. If not carefully considered and carefully maintained, failures in the corporate infrastructure can stop the entire organization dead in its tracks.

 Data small

Data

The data that surrounds the business is, quite simply, the lifeblood of the business. Analysis of this data is what allows people to make informed decisions when doing their jobs. Its what drives the feedback loop for your processes. The tools used by the organization create the data as well as feed on the data. If the business doesn’t have the right data and quick/easy access to analyze that data then how can it possibly make informed decisions?

Give some thought to what data your business absolutely depends on and what sorts of insights you could gain from that data if the right analysis tools were available. Are there questions about the state of the business or the organization you work in that you’d like to be able to easily answer but can’t because the data you need is not available? Are people making decisions based on intuition because the data necessary to make informed decisions simply isn’t available?

Also consider that your corporate data is one of the only truly irreplaceable assets the business has. It must be protected from theft as well as from accidental destruction. When businesses talk about the importance of disaster recovery it is often not an inability to access the software and/or processes that drives the urgency it is the inability to get to the critical decision-making data. Careful thought must be put into understanding how to protect this critical resource without simultaneously restricting access to it to the point of making it useless.

 Spheres 2.0 small

Tying it all together

In this article we’ve walked through what I believe are the 5 primary components of any technical organization. However, we’ve just barely scratched the surface in terms of what those components mean and how they interact. The purpose was to provide a high level view and make it clear how important each of these components is. I also wanted to highlight how important it is that a balance be found amongst the 5 components. Its that balancing act that is the essence of strong technical leadership and it is a never-ending task. It requires a dedicated team with a clear vision of what they are trying to accomplish as well as an understanding of how each of these components plays its part.

If you are interested in talking in more depth about the 5 essential components of a technical organization and how those pieces interact I’d love to talk with you. Its something I’m passionate about and something I love to discussing with others. I'd love to help you understand how to find the balance inside your particular organization.