An Alternative Approach to Re-Orgs

My company recently went through a re-org and placed one of the senior developers in a new lead engineer for R&D projects. He certainly is an excellent developer and quite a competent communicator however it really was a sudden move to shift this position into the company.

Under the surface I couldn't help but note that the lack of internal advertisement of what would be a very desirable role must have annoyed several other senior members. Additionally, it segregated a team of developers off to work on 'cool' things while the other half is left working on legacy projects.

I would agree with my companies perspective that something like this was necessary however as the author notes, the lack of involvement outside of C-level discussions was quite surprising and is likely going to backfire.

I'm going through my third re-org in less than a year and a half. This is my 6th new boss in 3 years and I've no faith that my new boss even understands what my teams job is as the re-org stuck us in with people openly hosttile to our job. Looking for the door is right.

The author doesn’t spend much time on _why_ re-orgs “almost always make some people unhappy, cause employee departures, and stifle productivity,” but I’d claim it’s organizational politics. Every re-org has winners and losers, almost by definition: there can only be so many people in charge, and likewise not everyone can work on that cool new feature. This is particularly true in relatively stagnant organizations: your best chance to move up the hierarchy as a manager might be during the once-in-a-blue-moon re-org. _Of course_ zero-sum shifts in organizational status of a bunch of imperfect human beings are going to be political.

The central thesis seems to be that by “involving the team members that would be effected from the beginning and making it their decision,” the discomfort around re-orgs will be avoided.

I might be missing something obvious from the article, but I have a hard time believing that adding more imperfect humans (in fact, all of the imperfect humans the organization has!) into the mix and letting teams self-organize would reduce awkward politics rather than making them worse.

This works for small companies that are scaling up, but fails when larger orgs need to scale down / reduce expenses. Particularly:

> Inform the teams affected that the new objectives create an opportunity for them to re-organize to be more effective at achieving these objectives.

In the US, reduction in force requires companies to file a WARN statement with that companies state. There's a few other legal requirements as well: almost all of them require c-level staff to absolutely say nothing to all employees until the day they announce it.

If an employee catches wind of a layoff early, there could be a leak to investors, which leads to insider trading and a whole host of other legal battles. As a result, CEO's and other decision makers typically cannot "inform the teams affected" until all the details have been set in stone.

What about something more fundamental? Do we really need layers of management? There are interesting examples of more-agile organizational structures examined in https://www.reinventingorganizations.com/

At a certain size, a company re-org essentially amounts to pushing the deck chairs around on the Titanic

For some organizations, their business reality changes constantly. The general approach is to reorganize the labor force to match the business reality. But this can mean that organizations can end up reorging many many times. Because the folks at the top of even moderately sized organizations don't really understand the day-to-day life of those most affected by the reorgs, the effort is usually something of a waste and can often produce "curious" movement of staff into positions that make little sense. But ultimately, the real problem is that a reorganization is supposed to introduce some semi-permanent shape to the workplace, and constantly changing that up becomes counter productive and pointless. One thing that also gets lost in reorgs is that an organization is not just an arrangement of people, but also the mechanisms and processes by which those people work together.

One way of handling this is to organize in such a way that assumes flux and then organize around that basis. There's lots of ways to do this, but one of my favorites is to group functional areas into labor pools with a lead (and maybe a deputy or two depending on the size of the pool). The lead's job is to match people to needs based on requests from project leads, manage work load on staff and ensure nobody ends up overtasked.

The project leads come from a pool as well. When a project arises, determines the roles, percentage of time, length of engagement, and skills they need filled and requests the staff from the functional labor pool leads. The project lead and the pool leads negotiate and if there is somebody who can do the job they're assigned to it. If not, a hiring event is triggered.

After that point projects are run by the project leads with their staff until completion. Once completed, the staff and their percentages are returned to the pool. Assignments and end-of-assignments must occur on a weekly basis as it simply makes planning easier. Starting projects in the middle of a week simply aren't allowed.

It takes careful tracking of time, usually a weekly meeting between all of the labor pool leads to ensure people aren't over/under tasked, staff issues raised, hiring needs and so on. A big matrix of people vs. projects with percentage of time and duration is usually all that's needed to track things reasonably well.

There will inevitably be a few people who are basically "permanently" assigned to certain projects and that's fine. Just track them as 100% and "indefinite" or "end of FY" for duration and they become very simple to track.

Source: I've run organizations of up to 70 people in ways similar to this and it was considered to be very effective in both productivity as well as stopping the constant reorgs. While I ran those orgs like this, the reorgs effectively stopped and many people who were on their way out stayed around and were ultimately quite productive. When I left those places, they usually assumed a more traditional line-and-block org structure and the reorgs started all over again, shedding staff and losing productivity.

Downsides were that not all staff can handle having multiple projects and be matrixed out this way. For many people though, they thrive in it.