The Failed Commodification of Technical Work

I feel I have to respond to this, as the Phoenix Project is probably the cringiest book I ve read in my life, and I've read The Effective Executive...

I just don't understand why we have to veil common sense practices (like continuous improvement, good communication, shared goals, etc) in this vaguely culty, vague Japanese kind of dev ops propaganda.

My biggest problem with the book is the same problem I have with scrum and all its hellspawn variations: it preaches how a method is special and if you only follow this method, everything will be okay. Well, guess what, if your team is full of people who don't communicate well, no management method can bring them up to be geniuses or to be suddenly a star team. On the other hand, if you have a team/teams of good devs, then you don't have the problem that The Phoenix Project/DevOps/Scrum are pretending to solve.

If anything, what you get out of blindly following the scrum recipes and people who fetishize The Phoenix Project, is mediocrity. We need to have value delivered on 2 week intervals, we need to always pester clients for their opinion, we need Friday demos each week to show how much we centered this div, and how much value this new button gives...

If you think you can chop value on small little chunks week by week blindly following the first thing that gives value, because long term planning is waterfall, and waterfall is bad, then you are a dummy and deserve your scrum and card estimations, and cringe standups. And you deserve it cause you gobble that bullcrap that those books and methodologies preach.

Card estimations with Fibonacci numbers?

Scrum masters?

Product owners?

Product managers? (that is somehow different from Product owners)

Sprints?

Standups?

Just take the retrospective, add some standups, kick all all non technical people from the tech meetings, add a sync or two with other teams, and you are done. But please don't write a book about it cause I will absolutely hate on it.

The key decisions of a manager entail when and where to collapse complexity into simplicity (and inversely expand a simple system into something more complex). So you can pick out a foolish manager by their unwillingness to work with complexity in areas core to their business/craft/discipline, and you can find bad ass collaborators by examining what sorts of complexity they're enthusiastic about.

(Note: I'm using the term "manager" broadly. It could be an executive, a team lead, an entrepreneur... basically any contributor making choices.)

I personally love being around people who are willing to get dirt under their finger nails, smell the soil, ask questions, and read the documentation (ie, willing to step into complex systems). It's inspiring. It also is a good indicator that the environment I'm in is being well-cared for.

Think of a human caretaker – those with empathy (a beautiful example of willingness to engage complexity) far surpass others in both ability and impact. Think of a barista observing details like humidity while adjusting their process. And now keep this analysis while moving to higher levels of abstraction.

(BTW, this is a phenomenal essay. I love how the author left it to the reader to realize all the lessons contained in the McDonald's anecdote.)

Are all of those proprietary products? I can't speak on your experience, but if linux was created in 1991, seems like in another angle you're bemoaning the rise of OSS and web.

I'm just a web developer that learned everything from online resources. So i think we are both biased on different ends on the spectrum.

I don't want to make an impact in any organization where experienced engineers are treated like children.

So Timmy, what did you do today? Ah, cool, make sure to raise your hand if you make a boo boo, and involve your little buddy Mike, okay? Mhm, thanks.

Hey guys, let's theorize how difficult it would be to make a tree house? Would it be 1 candy? 2 candy? 11 candies? No, that's too much, let's agree on 5, parents are eagerly waiting for the tree house to be built. Okay? Thanks. Well, 2 hours passed, time to tuck you in bed.

Hey children, this is Jake, he is a bit slow in the head. He can't read yet but I have decided to make him the one deciding what is most important in your reading curriculum. I also have decided to talk only with Jake and check only with him what is your reading progress. If you haven't read all the books in the curriculum by (deadline made up by the first number which comes to Jake, and he can count max to 3), it's your fault, not Jake's cause let's be honest, he is a tool and he can't read. But if you all read your books, Jake gets cake.

I believe all those methodologies were invented because manager types are terrified of depending on people who are different from them and who they don't understand. So they decided to embed one of their own business types (who also has 0 qualifications to judge whether the engineers are doing a good work) to make sure the engineers are not playing ping pong all day.

There's a lot of ways to take this, but just to clarify, you mean automating your work, not your self, right?