A Business Technology Place

Using history to organize your teams

What does the history of man and the advancements of civilizations have to do with business?

I recently followed a recommendation to read Jared Diamond’s book Guns, Germs, and Steel: The Fates of Human Societies. The book was the winner of the 1998 Pulitzer Prize for general non-fiction and provides theories and supporting arguments for why some civilizations throughout history survived and conquered other civilizations. Diamond supports the idea that societies persist and spread based on geographical and environmental factors rather than racial genetics.

Do business organizations parallel human societies?

On page 457 of the book Diamond explores the questions he received from many business leaders after they read his work. He sets-up the question as:

“What is the best way to organize human groups, organizations, and businesses so as to maximize productivity, creativity, innovation, and wealth? …. Should your collection of people be organized into a single group, or broken down into a small or large number of groups?”

Ah yes, one of the classic modern business dilemmas. Businesses are in a constant see-saw between a centralized and decentralized organization. Centralization is pushed to provide more standardization, economies of scale, and reduction of expenses. Decentralization is pushed to provide more innovation and closer customer relationships.

In his book, Diamond suggests that some level of fragmentation (decentralization) helped European advances in history because it created competition which led to innovation. Contrary to this, the unification of China appears to be a factor why it fell behind Europe in innovation during the colonization period. But India, which had even more fragmentation than Europe, didn’t advance as rapidly as Europe with technological innovations and colonization. That’s a very simplified look at Diamond’s discourse on the subject, but it leads him to suggest that the most optimal organizations have some level of decentralization in them.

The trick is to determine the right level of balance.

I promote a balance in a number of areas in the IT organization that I manage. This includes the number of in-house developers vs contract and “off-shore” developers, centralized software tools vs solution specific tools, and centralized processes vs sub-department processes.

photo credit: Leo Cullum

photo credit: Leo Cullum

A few things are certain with any approach:

  • People will point out the faults of the current organizational design and suggest that a change to another model is needed (based on the other model’s merits and not faults).
  • There is usually some level of second guessing by team members as they experience organizational results and look for ways to tweak the team setup to perform better.
  • There is a natural pull (almost like gravity!) that says we should organize differently. It’s the “always a better way” and “continuous improvement” approach to organization and processes.

I believe the answer depends on what you need from each sub-group in the organization.

IT, like other business departments, is further divided into group based on the type of service provided to customers. I believe groups like desktop/voice services and networking are best setup with a more central approach. This allows them to set to standards for equipment, general office software, voice equipment, etc. I look for this group to provide a consistent and predictable service to the organization. Less variety in what they support allows them to scale better.

The software development groups are tasked with providing innovation and helping the company be more competitive in the marketplace. As such, I like to have the software develop teams setup in a more decentralized organization. This gives them freedom to innovate and compete.

The project management, business analyst, and quality assurance groups benefit from a centralized approach as it helps them to reduce their toolsets and simplify processes. But they also benefit from a bit of decentralization so they can better match their processes to the software development teams.

The problems of any organizational design are always in the forefront to discuss, break-down, and analyze. I’m OK with that. As I said above, I think that’s a natural activity as we constantly look for ways to perform better. It’s neat to see correlations between Diamond’s study of human organization through history and the modern business world.  If you haven’t read Diamond’s book, it’s worth your time at least to skim and take-in some of the main theories.

Onward and upward!

Cross Departmental Teamwork 101

Information Technology departments are often criticized for their lack of collaboration with other business departments. Is IT needed since technology equipment and software is a commodity? Everyone has access to buy equipment and software in the open market to help run their business electronically. But what you can’t buy in the open market is teamwork and collaboration. That comes from within the organization with people not with bits and bytes.

Mike Stiles, from Oracle, blogged about 5 Secrets to Marketing and IT Collaboration. The list includes “understanding the perspective of your peers” which is not something you can buy. Robert Thomas, of The Harvard Business review, calls collaboration an intangible asset.

For some workers collaboration comes natural. For others, it’s like pulling teeth! In my career I’ve learned three simple things about working together with others. I consider it a list of basics although it contains concepts that were not always apparent to me.

1. It’s not what you say, but how you say it that makes all the difference.

My goal is to talk in terms of ‘we’ and ‘us’ instead of “you’ and “I’ when working with others. Create a team feel from the onset of a conversation. Stay consistent.

About 16 years ago, during my first week of a new job, I sent an email to my new team members with some requests for information. I was working on a task from my new manager so it seemed harmless. But the email was not received well with others because it was filled with statements like “I need”, “I’ve been asked”, and “I will”.  That’s not team friendly! Thankfully, a team member worked with me offline to explain how the message was received. Lesson learned.

2. When reporting a problem, communicate with the person directly before sending an email and copying multiple people.

An easy way to put co-workers on the defensive and irritate them is by copying their manager and several other people on a communication to complain about something that needs attention. I’ve seen this approach repeated hundreds of times in my career. I’ve been an observer, a reader, and an initiator.

About a year ago I errored by replying-all to an email that did this very thing with me. Someone was complaining about services not given to them from the team and copied several executives. By me replying to all and acting a little defensive I only exacerbated the problem.  The good news is that I knew I had made a mistake as soon as I sent it. I called the recipient directly and apologized. It made a huge difference in reaching a solution.

In the book of Matthew (18:15) we find it written this way “”If your brother or sister sins, go and point out their fault, just between the two of you. If they listen to you, you have won them over.”

3.  Do you want to be part of the problem or part of the solution?

It’s easy to complain about something you see. But it takes a different level of commitment to offer solution ideas and to help solve the problem. A collaborative approach builds unity and teamwork, so offer to participate. Mike Stiles from Oracle recommends in his blog post, “Be the role model”. Be the one who reaches out to start communication. Be the one who offers to be part of the solution.

Here’s a good example: “We noticed that X is happening, can you help us to find out why” rather than “X is happening and your process to fix problems needs to change.”

Classic IT Challenges – Technology outside of IT

This is the seventh and final post in a series of writings to discuss issues facing Information Technology (IT) departments. If you have not read any of the first six challenges you can find them under project work vs production support, prioritizing work, operations vs innovation, estimating work, understanding complexity, and reducing costs.

IT shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group. My thoughts are more around framing the problem than presenting solutions.

Challenge #7- Technology outside of IT

It’s not uncommon in a business environment for departments outside of IT to make their own technology decisions. This might include the purchase of desktop software or subscription to a software service platform. The IT department, with priorities to take care of the day-to-day operations of the business, may not have the capacity to handle new growth initiatives on a timeline that is acceptable to the business stakeholder.  Additionally, IT may not really be qualified to evaluate the business processes contained within new solutions. How many team members in IT are qualified to evaluate software that automates marketing campaigns?

One challenge for IT is if they are asked to support the new technology in some capacity. It’s a tough position to be in because the new technology may require a new skill set or training. Business stakeholders want support work completed as quickly as possible and without prior knowledge of the tool the IT staff is not positioned optimally.

Another challenge is if the new technology creates a duplicate solution within the organization. An extreme example could be the Marketing department purchases a tool to help them with customer list management for campaigns. But the Sales department has already purchased a different tool for this same function. That increases costs in total spend for everyone and increases the support complexity for IT.

Perhaps the biggest challenge associated with the introduction of new technology into an environment without IT input is integrating the new technology with existing systems. One of the primary goals of IT is to drive out costs in the organization through automation. One way to do this is to integrate systems so that information flows between the two without requiring manual touches. Integration usually requires programming and configuration.


The operations department looks for a way to automate their quotes and job estimates to customers. The existing process they follow requires manual labor to deliver simple quotes for standard products. Management would like to eliminate this manual with a solution that allows the customer to find a price quote online. While the customer has to do work to find the quote themselves, the solution would greatly reduce the turn-around time of the quote. Operations purchases a solution in the marketplace and it does not integrate with any existing workflow programs within the company. Ultimately new project requests are created to integrate the quoting tool with the order management system.

The real challenge in all this.

Businesses must move forward to survive. For their part, IT departments must realize they have a finite capacity to produce work over a given time period and that often business leaders from other areas need to find solutions outside the IT service portfolio. On the flip-side, management should also understand that choosing technology without the input from IT can lead to difficult situations on the backside of the decision such as support, maintenance, and integration requests.

A technology solution is a means to an end, not the end. What’s the ultimate goal? It is to make money by providing a service that some customer is willing to buy. All departments share that goal. So the real challenge is creating a partnership to involve all departments during the selection process of new technology such that everyone supports the same objective.

Cast the bully out

We have a love-hate relationship with steering committees.

Do committees provide value that pays for the amount of overhead they create in workflows? If you are a committee member with voting privileges then the tendency is to support and agree with the both the decisions and procedural steps the committee follows. If you are a project requestor then your attitude about a steering committee is influenced by the amount of steps involved to get decisions as well as the amount of time it takes to reach a decision.

I have experience as both a committee member and a work requestor. I’ve observed both the value of a committee and the hindrance a committee can insert into workflow. A steering committee creates value when it buffers the amount of work that is given to a technology team to implement. The result of buffering work is protecting the downstream resources from becoming overburdened with too many concurrent tasks. Buffering work also prioritizes the backlog and technology team members want to work on what the business leaders designate as top priorities.

There is usually a bully, or two, that receives all of the attention of the committee.

But you’ve undoubtedly observed a myopic committee as well. There are usually one or two platforms/customers that usually receive top priority or seem get automatic approval. There is usually a direct correlation to the amount of revenue generated by the platform or customer and the committee decision.

Conflict arises when these projects take all available resources such that other projects or customers begin to starve for attention. A significant challenge exists for the employees who represent the smaller platforms and customers to be able to get work done. That’s not a good situation for the anyone. But the committee members feel justified because they have allocated resources to the work that tied to the most revenue.

Cast the bully out.

One way to remove the platform/customer that usually plays trump in the committee is to organize that work team around a hybrid technology model. In the hybrid model the business owner (product manager/customer manager) has day-to-day direction on setting priorities for the technology team. A centralized project management office can track the work backlog and work-in-progress (WIP). The business owner then reviews the WIP at the steering committee meeting to bring visibility and accountability to the direction and decisions of their group. So while the steering committee is not prioritizing work for the decentralized group, they do have visibility and the ability to influence work if needed.

This approach doesn’t work for all platforms and customers because that would mean that there are enough resources to have a dedicated technology team for each platform/customer. It does align the platform/customer work with the business line to promote a more agile approach to work. The business owners that used shared resources no longer get trumped by the bully projects. The bully projects are able to move more quickly because they don’t have the overhead of committee processing. It’s a win-win-win.

Steering Committee Bully

Getting IT outside the box

I think it’s safe to say that direct interaction between IT and Operations doesn’t happen enough. I’m talking about IT programmers, analysts, and project managers sitting with Operations and Manufacturing to understand their daily workflow with the intention of providing technology solutions to automate workflow and make it more efficient. Making that type of conversation happen isn’t easy. Team members are busy with tasks in their work areas. Many employees, by nature, seek solitude during the work day. Just look around your office and see how many of your co-workers eat lunch at their desk. (Are you one of them?)

It’s a good thing if the company IT group is close enough to the Manufacturing and Operations areas to make frequent interaction possible. Proximity provides opportunity, but it does not guarantee interaction among team members. Interaction requires initiative. Interaction requires boldness. Interaction requires an inquisitive nature. Interaction requires a desire to make the bigger whole succeed.

I recently organized a tour of the Operations Center with the VP of Operations for all new IT members. The objective was to show IT team members where and how their work output is consumed by the business. There’s only so much that we could cover in an hour, but I’d like to think that the participants found value in the hour. Many of them asked questions to the tour guide. A few of them made comments to me like “I never knew all this was here”.

But this tour isn’t enough. It needs to be the start of an ongoing communication and dialogue not just an event on the calendar. One of my objectives as a department leader is to bring people together to find solutions that benefit everyone. IT and Operations is one example. But the concept really applies to all cross-departmental relationships.

Note to self: Bring people together to find solutions to problems that make people successful and make the business successful at the same time.