Some thoughts on using AI for org design
This post was inspired by a mentoring session I had here on Practi. As we always say: mentoring relationships are two-way, and both parties receive something to think about.
So, I’d like to share a use-case for HR professionals on how to apply AI to org design, what the limitations it has, and how to handle sensitive data.
I’ll start with data security because we deal with so much sensitive and confidential information in HR that it’s worth it to begin with managing it properly.
My steps:
Define what info I’m going to share with AI
We don’t have an AI policy yet in the company (and this is a huge push to have one). So, I have to double-check data handling, access conversation history, uploaded files, data processing and storage place with IT guys
Anonymise and aggregate everything that won’t affect the result (remove names and irrelevant personal data, replace identifiers with neutral IDs).
Now, moving on to the use case. Often we think about org design when looking for reserves for budget cuttings. A brief analysis of the org chart can reveal some inefficiencies in span of control, chain of command, team size, team grouping, duplicated responsibilities. During a year, the org structure may evolve from what was originally planned and budgeted last December.
I won’t share any particular prompts because I believe it’s so individual and different AI assistants may provide other responses than mine did. Instead, I’ll share my logic.
What to feed: org chart, headcount data, job descriptions, business process documentation (especially where we have handovers between different business units), RACI matrices.
What else it needs to know: the context. The more detailed the company is described, the more accurate answers we get:
size, industry and business model
products or services it provides and the markets it operates in
stage of development: start-up, scale-up or mature business
degree of centralisation or decentralisation
role and relative importance of different business units
were there any big changes recently?
current priorities and the rationale behind cost optimisation
Next, I ask to examine the org structure from several perspectives.
Management layers and span of control
Are there too many management levels? Are some managers responsible for very small teams? Are there opportunities to remove an intermediate management layer or adjust reporting lines?
I ask to show me the findings and then analyse whether they are OK or go deeper. E.g. having 30 subordinates in a client support team is fine, while 2 engineers reporting to one team lead requires further investigation.
Combining small units
Are there small teams performing similar activities that could operate more efficiently as one unit? Are there opportunities to consolidate support functions or bring similar responsibilities together?
Merging units is a tricky exercise but it may be justified by economies and less complexity. So, the assistant provides me with the findings based on JDs, BPM docs. Its suggestions may be naive or even silly. My task is to filter what is worth going further.
Identifying duplicated roles and responsibilities
Are similar activities performed by different departments or business units? Are there roles with overlapping responsibilities? Are there activities that could be consolidated without losing necessary expertise or control?
The assistant is good at this kind of job, especially with a headcount of 500+ employees. I suppose I could cope on my own with less headcount, but my human capacity is not enough when it comes to analysing millions of data points.
Reviewing the balance of managerial, expert and operational roles
Does the organisation have an appropriate balance between managers, senior experts and execution-focused positions? Are there too many managerial roles relative to the actual management workload? What is the cost of management?
I observe 2 types of managers: managers-drivers and managers-administrators. And usually, the latter have to leave the company first in tough times. Of course, a soulless machine 🤖 can’t evaluate who is who in the spreadsheet, but it’s interesting to compare its suggestions with reality.
My brief analysis pointed to complexity and duplications due to the matrix structure within the product team. Some people are responsible for getting the product exactly as it was designed and other people ensure the technical quality. It may seem that they do the same job - quality control, but in fact, they do very different jobs. Other findings were related to the disproportionate number of subordinates and teams of 2-3 employees with the dedicated supervisor.
Anyway, identifying potential inefficiencies is only the first step of the work. And here, the assistant has to take a break and the human being proceeds: analysing the findings, going deeper with investigation, collecting more accurate and updated info, doing a lot of communications.
Now, turning to what the assistant cannot do or is limited:
Data security, ethical, and disclosure risks. E.g., I can’t be sure that the results of my analysis won’t be visible to the corporate AI assistant administrator 😅
Even when provided with deep context, the assistant doesn’t know what is missing from the data, e.g. informal rules, discrepancies between the described process/ JD and reality, outdated docs and data. So sometimes, doing myself is easier and faster than explaining everything to the assistant.
Technical limitations: keeping the long context within the dialogue, processing large files, the cost of our cost-optimisation exercise😄
In particular, large organisations may run into technical limitations when trying to process all their data at once. What can they do? Split the data into departments or other logically stable segments. Analyse them one by one. Then compare and combine the findings at different levels. It's also important to preserve cross-functional connections so that potential overlaps and dependencies between departments aren't missed