Catch up with Part 3 (which has back-links to previous installments) if you’re not up to speed.
In the previous installment, I shared some of the common characteristics I’ve seen at companies who are really excellent at making learning one of their ordinary, day-to-day production outcomes. In this article, I want to share some specific “lessons learned” for leaders.
I’ve written a couple of dozen traditionally published IT books. I’m super-proud of like four of them. If you’re considering setting out to write a traditionally published book, know that it’s hard. Here’s why.
PowerShell for Sysadmins, by Adam Bertram, is a new book published by No Starch Press, with a tagline of “Workflow automation made easy.” The publisher asked me to write an honest review of the book, and provided a copy for me to read.
I’ve decided to embark on what will doubtless be a months-long project: a book that covers the history of PowerShell, from its earliest inception to the shell we all know and use today. But I want to do more than just document the dry facts: I want to capture the impact.
I’ve been in a lot of recent discussions with people who work in tech within medium- and large-sized business. There’s been a common – by no means ubiquitous, but certainly common – thread that I want to spend some time pulling.
I’m a tier 3 Systems Engineer in a room of my teammates, tier 1 & 2. Informal discussion, tech meeting. I ask them what they want to learn or teach the team, and no one has response. What are we missing? What can I and other tier 3s do to inspire the others?
There’s a lot to unpack there, actually. Let’s begin.