Work life and personal life aren’t always “two great tastes that taste great together.” But in today’s workplace, it is inevitable that they will mix. A recent post on Management Issues asked how much personal time was allowable during the workday, as many workers confessed to spending up to two hours a day on maintaining their personal lives.
The gut reaction you seem to get from that is surprise at people spending 25% of their work day on personal distractions. But I think it’s important to challenge that reaction, for a number of reasons.
A colleague of mine, Fred Stock, recently wrote about “Security Advocates” in his blog over at the RSA blogging site. In short, he suggests supplementing your core security team with outposts of knowledge throughout your product development teams, who can evangelize security concepts, eliminate trivial demands on your core security team, and make critical decisions with product-specific knowledge.
He’s obviously writing about this from the standpoint of improving the quality of your code and your organization from a security standpoint, but I wanted to add another dimension to this: growth. Continue reading →
Peter Quirk recently forwarded an interesting post to me. It discussed the idea of creating a “User’s Manual” for a manager, based on the manager’s leadership style and personality traits, to help employees function under that manager. Knowing my interest in people management and transparency, he thought I might have some ideas on it. He was right.
Our high school guidance counselor used to ask us what you’d do if you had a million dollars and you didn’t have to work. And invariably what you’d say was supposed to be your career. So, if you wanted to fix old cars then you’re supposed to be an auto mechanic.
This line from Office Space cuts to the chase. What would you do, if you didn’t have to do anything? I’ve asked myself that question over the years many times, and in my youth I I sounded a bit like Peter when I answered it:
I would relax… I would sit on my ass all day… I would do nothing.
It’s ironic that it’s hard to answer the question until you’ve been around the block a few times. Here you are at 30 or 40, finally knowing what you want to be when you grow up, and you’re 10-20 years into something different. Continue reading →
Steve Todd recently wrote about the experience of building EMC Navisphere from the ground up. His discussions of the Connect Library and the Factory Classes really brought me back to the mid-late 90s.
While Steve talks about the technical aspects, I thought I’d talk about some of the other reasons why the product was successful, and why the development team that worked on it was so engaged in the product and its success. I had dinner the other night with a teammate from those years, and though we’ve both moved in quite different directions since then, we both agreed our team was something really special. So maybe there are some lessons we can take from it, a decade later. I apologize in advance for any rose-colored glasses involved in looking back at this time. I invite the other team members to come and correct me!
We all look to ourselves first, when trying to model the people around us. It’s not a bad start, doing unto others as we would have done unto ourselves. But it is just a start.
I have been reminded of this in the past two weeks, as I learned how differently my wife and I handle the stresses of having our sleep schedules disrupted by a new baby. My wife needs as many hours of sleep in a day as she can get, but has no difficulty interrupting them and spreading them out. I think she could live on five 2-hour naps a day if she needed to. I, on the other hand, need fewer hours, but I have trouble waking during those hours, and am groggy and difficult when I do finally wake. I can’t nap at all, my mind won’t let me fall asleep mid-day unless I am totally spent.
We aren’t the same, even if we have the same basic needs.
It was very early in my management career when I first realized I had to apply this to my team members, but it’s a lesson I have to relearn all the time. Continue reading →
After I posted yesterday’s commentary on decision-making, I realized I had a few more thoughts that should have made it into the post. That’s what I get for pushing for a post every day, I guess.
There’s a natural tendency among engineers to question decisions. We do it to ourselves, and we do it to our colleagues. We expect it, and value it. We need it, when we’re collaborating on design, or performing a code review. But this behavior runs counter to rapid decision making, though, and knowing when to suppress it is a valuable differentiating skill.
Yesterday, I wrote some of the reasons why people with a technical background might have trouble making decisions. Now imagine this person has finally made the decision (despite being deeply uncomfortable with having to) and the first thing you say is “Did you consider XYZ?”
Well, drat.
Maybe I did consider it, and judged it an unimportant factor. But the fact that you’ve brought it up causes me to second-guess that judgment, my instincts, and my decision. It’s like you came along and hit the reset button on my decision. It’s worse than that. You’ve made me gunshy about making future decisions. Clearly I’m not thinking all the factors through thoroughly enough.
You go back to your desk, happy that you “helped” me. I go back to my desk and continue gnashing my teeth. Neither of us think of what just happened as negative! But it slows the organization down, and negatively impacts future decisions.
This is probably not something your manager will praise you for or call you out on during a performance review. Your peers might not even notice you doing it. But you have the power to support a decision or to undermine it, every time you’re exposed to one. If your organization (like mine) values decision-makers, you have a responsibility to encourage decisive behavior.
Learn to recognize that moment of choice, and think twice before you exercise your ability to sidetrack a decision. I’m sorry to say that it’s unlikely anyone will thank you for it, but you will learn to appreciate the feeling of enabling success on your team. Not only that, when you do finally push back on a decision, people will know that you’re seriously concerned, not just exercising your engineering instinct of second-guessing everything.
It’s just another tool to keep in your chest and bring out when the time is right.
I am not naturally decisive. And yet every day when I look at the RMSG value set, “Empowered Decision Making” looks back at me.
The truth is, our educations often tell us to put off decision-making. Reference an object via its most abstract base type, use late binding, value generic over specific, and so on. How many design documents have you read which go out of their way to talk about the myriad of implementation options available, when the author knows perfectly well what the implementation is going to look like? We take Einstein’s quote to heart and mangle it a bit: “Put off every decision as long as possible, but no longer.” Scientists take pride in not making decisions. We’re happy when someone tears apart one of our hypotheses, spotting something we didn’t, ruining our tentative decision and forcing us back into analysis.
Integrity is one of the big name values that people like to say they hold dear. We all like to think that with our jobs on the line, or facing the temptation of a big score at someone else’s expense, we’d take the high road. But how about the little things?
Today marks our final dry-run of the “Getting the Value out of your ControlCenter 6.x Implementation” hands-on session. Problems are ironed out (hopefully!), handouts are completed, and we’re as practiced as we’re going to be. Sunday, I’m sure there will be some last-minute chaos, and then over the next four days we’ll deliver five sessions, each 2.5 hours in length, each with up to 100 attendees sharing 50 laptops. I’ve never been involved in anything quite like it.
Everyone I talk to outside the company about my “free trip to Vegas” regards it as a perk. And clearly it is. But like every other perk, it has plenty of baggage associated with it.
I have been with Dell EMC since 1996, developing the guts of various SRM products in both development and management capacities. My main focus is on thriving in today's workplace in the context of my experiences at Dell EMC, but I'll also write about other topics at times.
(more)
This is my personal blog, and the opinions expressed here are my own, not Dell EMC's. My posts are not read in advance or approved by Dell EMC. Though I am employed by Dell EMC and Dell EMC is aware of this blog, I am not compensated by Dell EMC for my blog posts, and all costs associated with this blog are paid by me, not Dell EMC.
