I catch some good-natured and well-deserved ribbing from my co-workers and colleagues about this precept, but frankly, I take it in stride. It’s true that sometimes the new hires don’t understand it right away, but once explained and demonstrated, I don’t generally get much push-back.
Stated simply, “Broken Everywhere” means:
A single device or installation should never stop working as a result of a change to (or near) a similar device or installation somewhere else. Continue reading
Let’s ban the word “interesting” (at least for a while). Think about it for a moment. When was the last time you used the word when it actually[1. Let’s ban “actually” next.] meant something?
“What did you think about the incident management presentation?”
“Oh, it was interesting.”
Does that tell you anything? It’s a cop-out answer, a filler word Continue reading
We’ve got a rather large project going on at the moment and a shrinking window to get it done. The deeper we dig into this mound of work, the more and varied things we pull out. What started as a “you’re almost there already” project is now starting to look rather daunting.
My strategy? Limit the scope and focus solely on that scope. If it’s not in that scope, it gets left out and doesn’t get done. Continue reading
We moved offices this past week, relocating the IT department (and one other) into a new space. The new space is light and airy and is laid out on the open office plan.[1. I believe that the only fans of the open-plan offices can be found in the workplace design profession. However, they simply cannot back up their claims of productivity increases. As Tom DeMarco and Tim Lister wrote many years ago, “The only method we have ever seen used to confirm claims that the open plan improves productivity is proof by repeated assertion.” (emphasis in the original)
DeMarco, Tom, and Timothy R. Lister. Peopleware: Productive Projects and Teams. Addison-Wesley, 1987, p 53.] Initially we were skeptical but we’re making the best of it and it appears most everyone is settling down and adjusting well.
We have two new conference rooms, a large dedicated IT workroom, lots of community (but very little individual) storage, an awesome kitchen and a very welcoming lunch space. Continue reading
After a frustrating day at work dealing with a repeat of a problem from this past spring, I related some of the situation to my crew of hecklers advisers at the dinner table:
.jpg)
By Matthew Paul Argall [CC0]
A software package common to all our endpoints has a third-party plugin that only half of our users utilize. The package incorporates some templates that—in our situation—were created in a different version of the package on quite a different platform. The package and plugin relationship is complicated: only a particular version of the plugin will work with any given version of the package.
Of the users that utilize the plugin, only a few are in the same workgroup with another user. And, of course, there’s not a user group or a communication mechanism. The only common point of contact is the workgroup that takes the output from this package and does some massaging, formatting and editing before sending back to the users.
The IT workers on my team started with each user of the software package and plugin—and blaming the templates. Or the packages. Or the plugins. (Or the users!) Very soon we had a mashup of instructions with every known mixture of package/plugin/installation possible. I was hearing things like “UserA says that it’s the templates” and “UserB says when they reboot it works” and “UserC deleted their cache, reinstalled the plugin and now it works”.
Whatever. Sure, keep developing individual solutions for each of your installations. How’s that working for you?
A Leader “shares the vision” with the Team
We spent a good part of a day at the GCC National Youth Leadership Training course last week talking about “Sharing the Vision”.
There was so much presented throughout the week that I doubt many of the 48 participants got more than a high-level introduction to this topic, but it was one of the ideas that struck me pretty hard.
Here’s what I took away from that afternoon. Continue reading
From my 2016 NYLT notes:
Day 3
Adults frequently try to start at Performing while still actively Norming. So when Storming hits, it can be quite explosive.
Team individuals (vs true team members) who are accomplished (practiced? mature? aware?) at being team members can navigate these stages faster than those with less experience being on teams.
Navigate, but not always completing the stages. Not fully transformed to the stage.
(Actors with really good script writers can do this well, too.)
[One] role of the Leader is to guide the team through [the stages of team development] quickly and sufficiently [for the situation]. Not always thoroughly, but sufficiently.
A short-lived team doesn’t need to be completely stormed out. Masking conflict (for a time) can be acceptable.
Introspection can help move the individual along, but it’s largely masking the true stage or growth/progression of the individual.
The whole team needs to reach the [Storming phase], together. Otherwise, there are cells of quiet, with flare ups all around.
Read an early post on the Stages of Team Development. More than five years later I find that it still holds up well, but could use an update.
Rod of Alsclepius, from Wikipedia
As a manager, I occasionally hear variations on the “I’m sick and not coming in today” statement from my employees. Sometimes it’s a simple cold, other times it’s not.
Sometimes it comes with much too much information.
I’m not sure if it’s a need to prove that they’re really sick, that they’re not slacking off at home binge-watching Sherlock, or if it’s some form of exhibitionism.
I used to tell my employees I didn’t want to know. But they told me anyway. So now I skip that and just nod, express whatever awkward sentiment seems appropriate and let them know I wish them the speediest recovery.
Once in a rare while, it becomes important that I’m told. Those chronic things that start impacting performance. That’s when it’s very important because I can then refer my employee to Continue reading
Superhero or Villain? (from OpenClipArt.org)
As the lead IT guy in a small engineering firm, I get to deal with a lot of vendors. Vendors fill in my gaps: things like knowledge, skills, tools, hours and expertise. Really good vendors become my partners, my superheroes.
I have a rule of thumb about vendors—I just about always call them back. As distasteful as it can be to talk to a salesperson (if you’re a vendor or salesperson and that offends you or you don’t understand, just quit your job now), I call them back. Vendors and salespeople are in the business of selling stuff but some employ tactics that I just don’t enjoy.
Continue reading
