My favorite change management approach (is totally not made up, I promise) consists of three main pillars.<p>It's also a well known fact that tripods and pyramids and triangles are mystically powerful, so my methodology is totally legit, obviously.<p>- <i>Pillar 1</i>: Every opinion counts, but only if you can do the work<p>This boils down to removing managers who are not individual contributors from the decision making process (and potentially from the teams). I hear that Facebook are trying this out after their endless money started drying out. My advice is to not allow engineering managers who are not individual contributors in the first place.<p>- <i>Pillar 2</i>: Working without distractors, aka let us work without poker cards (aka estimations) and micromanagement check-ins (also known as standups)<p>This boils down to removing positions not related to building software from the process of building software. Such actions can be mind blowing to some, because it's a well known fact that we, engineers, can't make any decisions for ourselves what to build and what is its priority, and we obviously need some non-engineer who knows better to tell us what to do. But I urge you to entertain the thought and make a mental leap to a world where software engineers are capable adults who can build a great product, prioritize their work, and ship with confidence without a person with a BA degree called Josh who is "overseeing" their work.<p>- Scrum Master (that can be a full time job, apparently). Just don't use SCRUM as a whole, and if you have to, try to only incorporate some stuff from it if the engineers see as useful (like retros, or some form of daily sync). Anything else that stipulates also a role/position or some weird ritual with candles or cards, just throw it out of the window and thank me later.<p>- Product Owner/Manager. In corpo world, MITM is not a type of attack, but an actual job description, a well respected middle man who gets paid for repeating things (poorly) from one group to another and gets to, for unknown reasons, decide what is important and what's not. Just don't do this to yourselves and allow your developers to talk to "outside" people.<p>- Agile Coach (yes, that exists as a full time job as well) from the process of software development. Motivate the developers by spending the savings from not hiring these roles into the engineering team's next salary increase.<p>- <i>Pillar 3</i>: It's done when it's done<p>The more management types are sniffing around trying to pressure you into release or how to build whatever feature, the more they are slowing the process of a good, reliable software with well thought of features. So they just have to be patient or hire a new development team. It's done when it's done, deal with it.<p><i>Conclusion</i><p>I call this approach to change management: "Great Tactics For Owning Management", in short <i>GTFOManagement</i>, and I fully intend to write a book about it and then not release it.