Are you avoiding these negative reorg patterns? - Aaron Erickson, Cofounder @Orgspace & ex-VPE @New Relic

Hi There,

Reorgs suck:

  • more than 80% fail to deliver the hoped for value in the time planned
  • 10% cause real damage to the company
  • they can cause greater stress and anxiety than layoffs
  • over half of them lead to noticeably reduced productivity

“My favorite thing about this company is that I’ve had 4 bosses in 5 years”

- Literally, Nobody

Welcome to the CTO Connection Short Bytes newsletter - engineering leadership wisdom curated from the CTO Connection community. If you'd like to join us, sign up here!

This week I wanted to kick off with an article on “negative reorg patterns” summarizing the great talk by Aaron Erickson , Cofounder,@Orgspace from this years NY CTO Summit.

Before founding Orgspace, Aaron was VPE at New Relic and before that Senior Director of the Developer Productivity Platform at Salesforce. He has more than a little bit of experience with re-orgs (both those he planned and those that he was impacted by). Over the years he’s built up a collection of “negative reorg patterns” to avoid. Here are some to look out for the next time you think it’s time for a re-org!

Shaking things up - Team not meeting their metrics? Quarterly goals at risk? Maybe it’s time to rearrange the deckchairs on the Titanic :) As a senior engineering leader, you can’t ship enough code to move the needle, but you can reorg to show that you’re on top of things. Generally a reorg (and the stress and disruption entailed) slows things down even further (just like adding staff to an already delayed project). You might get an extra quarter of grace from your boss, but know that if you pull this trick, it’s probably time for you to prepare your three envelopes.

Chasing the trends - It’s important to learn from leaders in the industry and to be open to trying new organizational structures, but just because Amazon have two pizza teams, or everyone else seems to be adding a platform team, that’s not usually a good reason to reorg the whole department independent of a clear objective that can be better met by the new organizational structure you’re looking to adopt.

Killing bad projects - Sometimes it’s hard to admit that you’ve got some lemons and zombies in your portfolio of projects (especially if some of them were launched by you), but it’s far better to be honest about what isn’t working and to reallocate your teams off of projects that are not going to move the needle rather than trying to “stealth kill them” as part of a department wide reorg to avoid having the hard conversations about what’s not working.

Supporting a promotion - “Sue’s been here for a while, she’s critical to the org, and I don’t want to lose her - I think it’s really time to make her a VP”. That may well be a good reason to promote Sue, but it’s generally a horrible reason to reorg a big chunk of your department just to make sure she has 70+ people in her org or whatever the expectation is for a VP within your company. A good signal of this one is when your staff meetings are extremely boring because there’s no good reason for your direct reports to update each other - they’re working on very different initiatives.

There are lots of good reasons to reorg. Some good reasons include:

  • Major acquisition - Creating a coherent team structure after acquiring another business
  • Significant digital transformation or new product/initiative - Whenever you make substantial changes to your business model or the goals for your department, you may well have to restructure the teams to reflect your new priorities.
  • Fixing broken structure - When I (Peter) started at a previous company I had 5 product managers and one developer, and the goal was to hire one developer per PM and have each business unit ship their own code, even though they all needed broadly similar capabilities. A reorg was required.
  • Moving to multidisciplinary teams - If you currently have separate teams for dev, production, product and QA you’re going to want to move to cross functional teams to reduce the communications overhead and to allow your teams to move more quickly.

Do you have any opinions about reorgs? Please share them in the comments!

Happy Friday!

Zack Casey

Managing Director | Technical Presales, New Business Development

2 年

thanks for the excellent article.

回复
Dawid Wi?cek

So far, I’ve helped 726 overthinkers, leaders & overwhelmed job seekers ① communicate better ② boost confidence ③ get out of their own way & ④ land jobs ? Anti-Burnout Coach ? Executive Career Coach ? Communication Coach

2 年

Great (and realistic) examples of what can go wrong. The only person who always benefits from reorgs is someone external, like me: believe me, both on the executive coaching side (working with leaders who carry the heavy weight post-reorg, or employees who lack direction in their newly UNdefined roles) and on the career coaching side (supporting people who’ve been laid off), I welcome these tired “survivors” and weary “victims” and one of the first phrases to leave their lips is… “There’s been a reorg.” Thanks for sharing your insights and gifts, Peter.

Troy J.

President @ Evolve Softworks | Gaming Industry Innovator

2 年

Nice article. Business reorgs are often done unnecessarily. Many times in software companies, the reorganization is done based on revenue, saving money, and optimizing profits. This is often done as a last resort effort to increase profitability that the software should have increased. I took over a development teams and the company was on the verge of a reorg. I sat in a meeting where I listened to 500 business reasons why the reorg was necessary for two days. The 3rd day, they asked me what I thought about the reorg and if I had anything to add? My response made them stare at me and question why they hired me in the first place. I said "I see the benefits of the reorg but I can't justify it against the cost. Your system is antiquated and frankly unstable. It's high maintenance and the down time is unacceptable. Long story short, we stabilized without the reorg and took the company from 5 million a year to 650 million in a year. Reorgs are often done out of desperation by management to create change that they feel is not possible in development. Development must own what they built and not be afraid to raise their hand and say ... we are going to fix it. We should have done it better.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了