(This post is a review and expansion of material from the book that didn't made into the final edition)
The hardest problem of a product engineering organization is to define return of investment, productivity and grade autonomy of a team. You will find waves of processes and frameworks and their evangelists investing time and energy into them in the same company. In organizations that are growing fast, the distance between people that worked close grows faster and what would be a matter of settling over a pizza become a metric in a dashboard and hours of meetings.
To help address this ancient angst of our industry, we resort to methodologies and frameworks. In the decade of 2010, one of the most common path companies took was getting something like SCRUM and interpret roles as hierarchy. People were moved into these new positions with the “manager” title along the way, without teams, budget and commitments towards the main company goal. A yellow flag at this time was to spot people that you didn’t knew the job in the company becoming “product owners”.
It also happened with ITIL and its “change managers” or “incident managers”. Every time a new process came in, you gotta have people to take care of it and the process becomes what keep their jobs. Heavily invested companies had cycles of more than weeks to release software and so much burden if you made a mistake that people opted to not take action.
Right around the corner, "Design Thinking" came in: teams and cross companies meetings to collectively chalk up new ideas in a brainstorm setting, followed by SAFe - a humongous enterprise agile thing that dragged everyone around work to maintain the framework running - more than to ship code. You can chalk KANBAM into that too, huge boards with living backlogs and no end in sight.
OKRs are not so new but started to drift in: companies would evaluates, and sometimes mistakenly changes, what seems to be promoted backlog items each month|quarter|year. OKRs that were supposed to be dreams hard to be achieved slowly became tasks, and the process to deliver them, a communal agile waterfall.
If you look to team organizations, the same happened: The Spotify model, BUs, Focus Areas, The Facebook and The Google models are still going around, sometime not used in their original companies but overly sold by consultants.
All the above are not bad or faulty by themselves. To adopt a framework entails a learning phase as with any new technology: you gotta get hurt and learn what work and what won't work for you. But unlike technologies where your audience consists of somewhat similar people - engineers, these frameworks affect the life of people you may not completely understand, in corners of the company you may not have visibility.
A common side effect of constant changing frameworks, organizational layouts and unclear product engineering direction is to start product oriented teams hoping for full rewrites or a new cash cow that end up preventing the current team to work in the elephant in the room. And with the current market, that weights to increase churn of people leaving, low morale and the same or worse results than before.
You may notice a dead silence in the middle management, hear about isolated clusters of people lost on rituals as Discoveries thinking they can do it and later accused of slowness or engineering digging their way on obscure languages and frameworks. You will also hear about it as a root cause analysis of why the metrics are not good and if you heard that, probably the team heard about it too and it feeds back into a vicious loop. Stuffing a big framework over it is the last thing you need.
It is all about people, technology and products are a side effect of context and understanding them.
I've released a new book at https://ctofieldguide.com - and it got featured on Product Hunt. If you liked it, I'd appreciate a review or upvote ! If not, what are you waiting for ?