A World Without Email - Follow-up
Chris Petersen
Do-er of the Difficult, Wizard of Why Not, and Certified IT Curmudgeon
This is a follow-up to https://www.dhirubhai.net/posts/chris-petersen-a5213719_bookreport-bullshitjobs-deepwork-activity-7257186557424451584-AHoS?utm_source=share&utm_medium=member_desktop since I just finished reading Cal Newport's "A World Without Email".
As usual with this author, I found a lot to like in this book, and it keeps getting better as the chapters go on. I'm not dissecting it for a paper, thesis, or dissertation; so I can only claim a medium-deep reading. Like all knowledge work, your mileage will vary.
Something you may or may not like about this book is the lack of industry buzzwords in some areas:
There's a discussion of a 5-day super sprint for process improvement, but it's not called a Kaizen or couched in Lean terms. There's relatively explicit talk of single-piece flow and reducing switching time, which are core Lean principles, but they're not couched in Lean terms. I'm not sure if the word Lean appears in the book at all. It's not in the index, and yet, reading the book with a particular mindset makes the comparison almost impossible to ignore.
It's nice to see an explicit rejection of creating "bullshit [support] jobs" to make high-value knowledge workers happier or more productive (see above). One might be tempted to read in echoes of Gartner-style "bimodal IT" in places. Whether it's an actual support staff, an automated/AI support staff, or just dedicating some hours/days of the week to being your own support staff; those roles cannot become some permanent, rotating "epsilon minus" class of drones and drudges. Literally everyone deserves better!
领英推荐
Some of the discussion of being (or simulating) your own support staff seems to echo ideas from Dev[Sec]Ops, another term that doesn't appear in the book. Sometimes, you're the "dev" doing deep work for hours at a time (and the shout-outs to pairing and extreme programming in the book were welcome), and sometimes you're the "ops" keeping things running for yourself or your team. Making those rotating duties in a merged team might be a big win for some environments.
There are job roles that are effectively knowledge work but probably can't get away from the hyperactive hive mind kind of work flow. I'm reminded of a junior colleague who asked me back in 2013 whether I thought "UNIX system administration" as a profession had any future outside the service providers and hyper-scalers of the world. My answer then as now is that there will probably always be places where that niche exists, but it's not a growth field. It was already past time to increase our value via focus and specialization. Don't do! Automate!
All-in-all, I'd call it a solid book on its own and a distillation of a lot of trends and ideas in the knowledge work (not just IT) industries over the past few decades. It probably benefits from not calling out specific frameworks and mindsets by name. That may increase its general applicability and shelf life, even if it shouldn't be treated as shelf-ware.
#RecommendedReading