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.
I've been on the short end of re-orgs. I get that for the good of the business that some of the changes needed to happen, but where it really hurt was it came across that management didn't know what we were doing, and made it seem unimportant/useless. They shifted the focus of the team to a thing that literally every single member of the team the previous week said they didn't want to work on, and in a few months realized someone needed to focus on the original thing and tried to shift back. The company prides itself on internal mobility, by that time every person but one had quit or transferred.
I don't read it as self-organize, cause then everyone would choose to work on the new shiny, but there should be some amount of discussion that happens as input to the reorg, rather than too late when everyone is gone.
A few other reasons reorgs can "almost always make some people unhappy, cause employee departures, and stifle productivity": A. Most orgs have multiple unmapped communication channels that smooth operations. With reorgs those get broken and have to be reformed and operationally remapped, which creates mayhem in day-to day productivity B. Change is unsettling even when welcomed; C. The view of how work gets done and why is highly localized. Reorgs often clean up only certain hierarchical levels of this how/why coupling.
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.
The lack of involvement is generally a problem in companies. Not only with reorganizations but also with things like remodeling of the workplace. Instead of getting feedback from the people who eventually have to sit in that space management usually closes itself off and doesn’t explain the reasons. Once it’s done you will see a self congratulatory email how great things will be.
> it segregated a team of developers off to work on 'cool' things while the other half is left working on legacy projects
Ouch. Everything I've read about re-orgs is usually centred on not letting that happen. We went through one last year and any remotely interesting tasks absorbed by teams were shared around (along with the not so interesting tasks of the people who were bumped).
We were luck we had quite an inclusive consultation process and the radical transparency had both negative as well as positive effects, but can imagine something like that being somewhat hidden would just kill morale.
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.
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.
Congratulation, you've just killed ownership. My current org is like that (a "Linux team", a "Network team", an "Ops team", a "Windows team that's also in charge of user management because AD", an "Info sec team". It's hell. Having a team by product, with various skills and a person clearly in charge of that product from the draft to the after sale, would be so much better.
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/
13 comments
[ 3.6 ms ] story [ 42.3 ms ] threadThe 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.
I don't read it as self-organize, cause then everyone would choose to work on the new shiny, but there should be some amount of discussion that happens as input to the reorg, rather than too late when everyone is gone.
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.
Ouch. Everything I've read about re-orgs is usually centred on not letting that happen. We went through one last year and any remotely interesting tasks absorbed by teams were shared around (along with the not so interesting tasks of the people who were bumped).
We were luck we had quite an inclusive consultation process and the radical transparency had both negative as well as positive effects, but can imagine something like that being somewhat hidden would just kill morale.
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.
> 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.
... TLDR: the dangerous notion is that "teal" organization is something new, when in fact we have millennia of history to learn from.