
An Alternative Approach to Re-Orgs - baxtr
https://caseyaccidental.com/alternative-approach-re-orgs/
======
jtonz
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.

~~~
maxxxxx
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.

------
cannonedhamster
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.

------
oostevo
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.

~~~
meristem
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.

------
SamuelAdams
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.

------
meemoo
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/](https://www.reinventingorganizations.com/)

~~~
meemoo
Found this somewhat-cliackbaity take: The Most Dangerous Notion in
“Reinventing Organizations” [https://medium.com/@jessicajprentice/the-most-
dangerous-noti...](https://medium.com/@jessicajprentice/the-most-dangerous-
notion-in-reinventing-organizations-9032930295e2)

... TLDR: the dangerous notion is that "teal" organization is something new,
when in fact we have millennia of history to learn from.

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

------
bane
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.

~~~
navaati
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.

