Decentralize technology into the departments

1. The constraint and what graduates it

Information systems, called IT here, is how you gather, store, analyze and display information.

Item	At this stage
The constraint	Departments outgrow general software and need specific solutions. There are too many internal inquiries and no process for handling them, so you need policies by department
To graduate	A specialized stack for each department, an internal inquiry process, and service level agreements

You may have noticed this along the theme here.

2. Give each department its own stack

This is the first thing to focus on. In the beginning you get general tools that every department can use. Early on it makes no sense to have one platform for sales and another for customer service, because there are something like two people there. So you will deal with the one that works for everybody.

Once you get big enough, you start to notice that a given communication tool or email platform does not really work well for a given team. That is when each department gets its own specialized stack.

3. Move technology from the center into each department

The second thing is an internal inquiry process, and at this point the demand for one becomes really big. Picture the departments: product, marketing, sales, customer service, IT, recruiting, human resources and finance. Each now has its own technology, and each will also need a way to send tickets to the IT team, and, in effect, service level agreements with that team: how long things are going to take, and what turnaround times to expect.

So the function has to go from centralized to decentralized. It was its own department, serving all the others and spread equally across them. Now it has to become almost decentralized: there is an IT department, and there are many IT departments inside the other departments. The reason: if sales has its own platform, five platforms that together make its work run, it makes no sense for sales to wait a week for IT while that team is busy with recruiting's work. Each function needs all of these things to work properly.

Staff each department. Look at having staff who serve each department's specific needs: specific technology, and specific staff. In the beginning this might look like an IT director and a generalist or two. Now you get people who each specialize in one function:

• a marketing technology person;
• a sales operations person;
• customer service operations;
• revenue operations;
• financial operations.

Ticket each function. Those people then create a ticketing system for each of their functions. Before, you probably had one centralized ticketing system for IT; now you have to create an IT ticketing system for each person who owns a function.

The department is the product. The reason for all of this: at this point technology is essentially part of the product, the product being the department. For it to improve properly, each department needs almost a product-like pipeline, the kind you would run for software.

4. Why people hate it, and why you do it anyway

This is where a lot of things break, because people start to hate it. First they hate relying on the IT department, because it is so slow. Then they hate having to send inquiries to people, and the service level agreements being set up: what is all this communication, just build what I want and do what I tell you.

What has to be realized at this point is that you need technology that enables you to build the processes the right way. Each department really starts to become its own piece of technology.

5. Custom tools, and a caution

Sometimes you may find yourself with custom developers, brought in house or contracted, to build specialized tools, patches or integrations.

The caution: you may end up building something that works really well for you. Companies of this size do come asking about exactly that, in one practice here. They have built a tool that makes their salespeople far more proficient in their own industry, they have friends in this industry who want to pay for it, and they want to know whether to spin it off as a software company, or whether it gets them valued as one. The answer offered: stop. You built these things for yourself.

The objection raised is a chat software company. The answer offered: it had no revenue, was losing money and threw a Hail Mary; it was that or nothing. It was also a software company from day one. The type of software changed, but software is what it was built for.

If you run a solar sales business and find a way to make your reps significantly more productive, great: that is a competitive moat, and it is what you do to keep crushing your competition. So, no. The person who would write you a $500 million check, or a billion-dollar check, or whatever your goal is, is not dumb; he has the money to write the check. Do not try to get categorized as a software company, because you will not be. Those are just internal tools.

Long term, if you are in a service business, unlike that solar sales example, what you may end up with is a tech-enabled service: you have found a way to deliver to customers faster, you have automated a huge portion of the work, and that drives more margin. Would you shut that company down and start a software company serving others in the space, when your niche is really small? Probably not. Just run on having the advantage. That is the point.

6. Service level agreements, to size the team

The last piece is service level agreements with the technology teams. This is the point where you are starting to measure utilization, and you want standards for how long the tasks you repeat take. What that might look like:

• how long it takes to fix a server when it is down;
• how long it takes to onboard a new rep in the sales department onto a specific tool;
• how long it takes to build a funnel for marketing.

The reason to have them: to know how big your team needs to get and how efficient it can be. With the agreements in place you know how long things take, what the workload is, and whether you need to hire more people.

7. The summary

Departments outgrow general software and need specific solutions, and there is no inquiry process. So create one, with service level agreements, and give each department a specialized stack of its own.

8. Where this sits

• For a team of five to nine, the move was onto shared chat, password and project tools: SOP 149 — Prioritize and niche down at five to nine people, section 8.
• One stage earlier, data went into one backed-up place, hardware was centrally located, and each department named things one way: SOP 164 — Categorize the business at fifty to ninety-nine people, section 7.
• Company devices, security protocols, onboarding and offboarding: SOP 155 — Set up employee technology and security.

9. What this page does not decide for you

• Which tools each department should use. Not established on this page.
• What turnaround each agreement should promise. This page gives no figure for turnaround times.
• At what size a department gets its own technology person. Not established on this page.
• Whether custom developers should be in house or contracted. Not established on this page.

10. What this page does not cover

Enterprise software and data security are not covered on this page.