What do you love about your job?
If you have something you do, and do well, you're in a good position. However, dream jobs only come when you discover that you actually enjoy what you do. If I could do anything I want and get paid, it probably wouldn't be what I'm doing now. But I said, "Probably." Because I do love this stuff. And I'll take a moment to indulge my ego and point out that people love the job that I do, too.
The problem is, what if you don't love your job?
I'm not talking about a job that you hate: if you hate the job, you're long overdue to move (and believe me, others will most likely be happy to help you to the door).
No, I'm talking about a job you don't hate...but you can't find anything to love about it.
I've been in a place where this was a real problem. People were no more excited about their jobs than they would be unclogging sinks, or washing dishes.
A recent study found that loneliness is contagious. We know that when people feel lonely, they withdraw. What the study noticed is that before they withdraw, they invariably communicate their feelings of loneliness to others. When they leave, everyone remembers their feelings and starts to echo them.
Remember this, because the same is most surely true of the work you do. If your heart's not in it, if you can't find anything about your job to make you happy, you are contagiously gray. Your lack of passion does not go unnoticed: it spreads to other hosts. You don't have to be the head of the Cheer Squad, but if you must share something, look for the positives.
(Lonely link: http://www.sciencenews.org/view/generic/id/50200/title/Loneliness_is_contagious,_study_suggests )
Tuesday, January 19, 2010
Tuesday, December 1, 2009
Madness to the Method
My division is one of many. Ours is currently the only one putting method to the madness, hiring Analysts and Project Managers, documenting all the work that's done, ensuring all the code gets tested, and making sure the customer is happy. We've learned the hard way that when Timmy wrote Our Beautiful Code, Our Beautiful Code is bricked the moment Timmy walks out the door. Too many shops rely on Timmy keeping it all straight in Timmy's head, and there are many developers who thrive on this idea:
"Documentation is nonsense, and asking people questions gets in the way of writing software."
"They'll like what I build because it's not pen and paper."
"They'll use what I give them because they have no choice."
"...And they'll see that I Am the God of the Code."
There's an argument for this approach: it usually starts with, "We haven't got time..." and ends with, "...because everything's on fire!"
People love "the quick win." Developers love it especially because they get bored. They are creative people, and having to labor at the same thing day after day requires a patience and mind for tedium that most other humans lack.
Management loves seat-of-the-pants solutions because they solve a problem quickly. They don't love them when they break. Often another rickety contraption is rolled out while the broken one is trundled backstage to be dismantled.
No one in technology plans very far ahead: that would be silly. Isn't it amazing that Windows XP lasted for 6 whole years? I can tell you now that while it is a nice idea that a software application might still be in use 6 years from now, 10 would be absolutely out of the question. I know without consulting my crystal ball that a user trying to use today's system a decade later is going to curse my name and start casting aspersions on my ancestry.
So why document? Why bother writing it down?
- To get it right before you start down the road
- To build something useful
- To fix breaks without having to track down Timmy
- Because like it or not, you and yours will be supporting this
The Project Manager faces a balancing act between customers and development: imagine your Project Manager going about her daily routine as somewhat like The Cat in the Hat, teetering a goldfish bowl atop an umbrella whilst unicycling. In the midst of this, two important Things must not run amok:
Thing 2 is that the customers must not be bored while you're getting ready for The Great Show that is their product. Don't make them re-read all your use cases and have meetings because you think meetings make your project seem important. Don't use technical jargon to make you seem smart, or go on about this great new feature that Technology X is going to offer the developer.
Thing 1 is that the developers have to be given something of value, then shown--by way of your documentation--that the streets ahead have been paved with gold. I've had more than one developer fuss and struggle with my methods, only to suddenly see, right towards the end of development, that I've magically given the customers training materials and user guides that cut down on the number of phone calls and e-mails...and at the same time I've given the developer a road-map to get back into their system if things go wrong. Or--better yet--hand it off to Junior Developer without having to sit behind him and do half the work using only the power of speech.
The next step I wish to undertake is to empower the client: the more changes to their application that they can apply without putting in a support ticket, the better life gets for everyone.
Without documenting how the machine works, none of us would ever be able to sandbox the client so they don't get themselves stuck.
"Documentation is nonsense, and asking people questions gets in the way of writing software."
"They'll like what I build because it's not pen and paper."
"They'll use what I give them because they have no choice."
"...And they'll see that I Am the God of the Code."
There's an argument for this approach: it usually starts with, "We haven't got time..." and ends with, "...because everything's on fire!"
People love "the quick win." Developers love it especially because they get bored. They are creative people, and having to labor at the same thing day after day requires a patience and mind for tedium that most other humans lack.
Management loves seat-of-the-pants solutions because they solve a problem quickly. They don't love them when they break. Often another rickety contraption is rolled out while the broken one is trundled backstage to be dismantled.
No one in technology plans very far ahead: that would be silly. Isn't it amazing that Windows XP lasted for 6 whole years? I can tell you now that while it is a nice idea that a software application might still be in use 6 years from now, 10 would be absolutely out of the question. I know without consulting my crystal ball that a user trying to use today's system a decade later is going to curse my name and start casting aspersions on my ancestry.
So why document? Why bother writing it down?
- To get it right before you start down the road
- To build something useful
- To fix breaks without having to track down Timmy
- Because like it or not, you and yours will be supporting this
The Project Manager faces a balancing act between customers and development: imagine your Project Manager going about her daily routine as somewhat like The Cat in the Hat, teetering a goldfish bowl atop an umbrella whilst unicycling. In the midst of this, two important Things must not run amok:
Thing 2 is that the customers must not be bored while you're getting ready for The Great Show that is their product. Don't make them re-read all your use cases and have meetings because you think meetings make your project seem important. Don't use technical jargon to make you seem smart, or go on about this great new feature that Technology X is going to offer the developer.
Thing 1 is that the developers have to be given something of value, then shown--by way of your documentation--that the streets ahead have been paved with gold. I've had more than one developer fuss and struggle with my methods, only to suddenly see, right towards the end of development, that I've magically given the customers training materials and user guides that cut down on the number of phone calls and e-mails...and at the same time I've given the developer a road-map to get back into their system if things go wrong. Or--better yet--hand it off to Junior Developer without having to sit behind him and do half the work using only the power of speech.
The next step I wish to undertake is to empower the client: the more changes to their application that they can apply without putting in a support ticket, the better life gets for everyone.
Without documenting how the machine works, none of us would ever be able to sandbox the client so they don't get themselves stuck.
Monday, November 30, 2009
Making "Dysfunctional" Fun Again
My house has many masters:
I manage my projects
My boss manages my division
His boss manages all our divisions
My boss keeps us organized. He makes sure we don't waste our time or spin our wheels. Rather than the tried-and-true "carrot vs. stick" method, he applies a middle-of-the-road approach that's more like gentle goads. Prods to keep one on the path and away from the dropoffs.
His boss doesn't ask for much. It's an odd mix: she is laissez-faire most of the time, but occasionally gets hit with a spark of innovation. I'd call it "management by magazine" if these ideas weren't driven by a healthy dose of smarts: she's brilliant, she's driven, and she wants to keep all the ducks in a row.
Where the flock starts to scatter is when it comes to the direction. "Now, go forth and do," she says. Imbued with all the great faith that one could ask of a super-boss, off we go to fulfill that vision.
Each of us in separate directions.
I've seen every division head clumped together in the same room with her, raising the Go Team mentality to a full head of steam...and then seen them go out the door wondering what's for lunch in the cafeteria across the street.
It's a shame, really. Some of it is family feuds, but most of it is a lack of whatever "glue" an organization needs to make everybody pull together. I don't think they're jaded about Yet Another Clever Vision so much as they figure getting things done today is more important than making life easier tomorrow.
Tired of fireworks shows that fizzle (and no doubt wanting to put a gold star on the resume before planning an exit strategy), she's done something rather Machiavellian:
She's sidestepped her own managers. She's asked me to be part of a team of leaders. I can't tell if that means we're Vision Evangelists or Next-Gen Management, but either way, it puts as all in an interesting position: whom do we serve?
"ABDICATION, n. An act whereby a sovereign attests his sense of the high temperature of the throne."
--Ambrose Bierce, "The Devil's Dictionary"
(sourced from Project Gutenberg)
I manage my projects
My boss manages my division
His boss manages all our divisions
My boss keeps us organized. He makes sure we don't waste our time or spin our wheels. Rather than the tried-and-true "carrot vs. stick" method, he applies a middle-of-the-road approach that's more like gentle goads. Prods to keep one on the path and away from the dropoffs.
His boss doesn't ask for much. It's an odd mix: she is laissez-faire most of the time, but occasionally gets hit with a spark of innovation. I'd call it "management by magazine" if these ideas weren't driven by a healthy dose of smarts: she's brilliant, she's driven, and she wants to keep all the ducks in a row.
Where the flock starts to scatter is when it comes to the direction. "Now, go forth and do," she says. Imbued with all the great faith that one could ask of a super-boss, off we go to fulfill that vision.
Each of us in separate directions.
I've seen every division head clumped together in the same room with her, raising the Go Team mentality to a full head of steam...and then seen them go out the door wondering what's for lunch in the cafeteria across the street.
It's a shame, really. Some of it is family feuds, but most of it is a lack of whatever "glue" an organization needs to make everybody pull together. I don't think they're jaded about Yet Another Clever Vision so much as they figure getting things done today is more important than making life easier tomorrow.
Tired of fireworks shows that fizzle (and no doubt wanting to put a gold star on the resume before planning an exit strategy), she's done something rather Machiavellian:
She's sidestepped her own managers. She's asked me to be part of a team of leaders. I can't tell if that means we're Vision Evangelists or Next-Gen Management, but either way, it puts as all in an interesting position: whom do we serve?
"ABDICATION, n. An act whereby a sovereign attests his sense of the high temperature of the throne."
--Ambrose Bierce, "The Devil's Dictionary"
(sourced from Project Gutenberg)
Monday, September 14, 2009
The Cultural Victory
As the dominant software company across the industry, Microsoft has done both good and bad. In the past, they've been investigated for anti-competitive practices. There are times when the Microsoft Way seems to be "steal it, or buy the company and own it...or steal it then buy it if they sue".
Lately I'm beginning to think that Microsoft isn't trying to succeed by putting down its competition: it seems to be succeeding simply by building a better product. If you can trace how technologies like SQL Server 2008 and SharePoint have grown, you start to get part of a bigger picture for them that more resembles the American Dream: ideas, innovation, and energy.
On the other hand, Microsoft's Hall of Shame probably won't have a Vista wing that's as large as, say, the Aisle of Windows Me or the Microsoft Bob Exhibit. The biggest mistakes with Vista were, in my opinion:
1) taking 7 years to build the product, and still having it be so buggy and incompatible on launch; and
2) vendors having 7 years to learn how to write good drivers, and failing to do so.
Both are more shameful if you believe in the "Microsoft was just copying the Mac OS" philosophy: copying someone else's idea means a chance to outdo the competition by learning from their mistakes.
At the end of the day, if you're a company as far-reaching as Microsoft, impacting as many people as you do, youre best-case scenario is to celebrate your successes, own your failures, and learn from both.
Regardless, I'm now hopeful that hope Windows 7 will be less "Copy the Mac" and more "Build a better product."
Thursday, August 20, 2009
Computerworld magazine columnist Paul Glen posted an article about how passionate employees aren't a good thing ("Hip-hip hooray for the Passionless", Aug. 10, 2009). In it, he states that employees who are passionate about their jobs can be bad: they wax and wane and that makes their productivity inconsistent and their passion unpredictable. He also suggests that talk of "Passionate employees" is usually the work of managers trying to brag about their leadership skills.
It's easy to peg "passion" as bipolar when you're using a sliding scale. Humans have good and bad days, productive and not-so-productive ones. That doesn't make them dispassionate.
If you define passion as, "Enjoying what you do," it's a lot easier to recognize that passion in the workplace is not about going above and beyond: it's about enjoying what you do, just enough to care about what you do.
The last thing you're going to want in the technology game is passionless drones. They seem to accomplish consistently, but the truth is they barely get by. In IT, it's dangerous for your shop to have people who would be no more excited creating code or helping others than they would be throwing newspapers or mopping floors. I'm seeing that problem now, and morale and productivity are in the tank because of it.
The Computerworld article:
http://www.computerworld.com/s/article/341344/Two_Cheers_for_the_Passionless
It's easy to peg "passion" as bipolar when you're using a sliding scale. Humans have good and bad days, productive and not-so-productive ones. That doesn't make them dispassionate.
If you define passion as, "Enjoying what you do," it's a lot easier to recognize that passion in the workplace is not about going above and beyond: it's about enjoying what you do, just enough to care about what you do.
The last thing you're going to want in the technology game is passionless drones. They seem to accomplish consistently, but the truth is they barely get by. In IT, it's dangerous for your shop to have people who would be no more excited creating code or helping others than they would be throwing newspapers or mopping floors. I'm seeing that problem now, and morale and productivity are in the tank because of it.
The Computerworld article:
http://www.computerworld.com/s/article/341344/Two_Cheers_for_the_Passionless
Friday, August 14, 2009
The Wheelbarrow of Cash
Cost Analysis does not turn anyone's crank. The word itself is dry and flat.
Most people don't realize that Cost Analysis is not only a necessary evil, but it's also seldom done correctly.
The best justification for an expenditure is that it sits smack in the middle of the needs pyramid: it's cheap, it can be done fast, and it can be done right.
The worst justification for an expenditure is the phrase, "Because we've always done it this way."
Either way, the most important question to ask yourself is, "Do we really need it?"
If you're renewing licenses that don't help you, or you're paying contracts that barely meet your needs, it's time to look elsewhere. The looking costs time and money too, but in the end, cost analysis is all about ROI. And ROI is never a one-time snapshot: it's an ongoing look at what you're getting back for your commitment.
Most people don't realize that Cost Analysis is not only a necessary evil, but it's also seldom done correctly.
The best justification for an expenditure is that it sits smack in the middle of the needs pyramid: it's cheap, it can be done fast, and it can be done right.
The worst justification for an expenditure is the phrase, "Because we've always done it this way."
Either way, the most important question to ask yourself is, "Do we really need it?"
If you're renewing licenses that don't help you, or you're paying contracts that barely meet your needs, it's time to look elsewhere. The looking costs time and money too, but in the end, cost analysis is all about ROI. And ROI is never a one-time snapshot: it's an ongoing look at what you're getting back for your commitment.
Thursday, August 13, 2009
Climbing Aboard the Starship Enterprise
If you are a large organization, you breathe a huge sigh of relief when you adopt technology.
Then the headaches kick in.
A new version comes out. One upgrade broke another system...until you bought that upgrade too. Now your employees need new machines: the old ones are just so slow.
By the way, the good news is, there's a new Operating System to buy. The bad news is, it's full of bugs and security holes.
Uh-oh--security! I bet you didn't give IT Security a second thought when you put all this together back in the '90s. You slapped McAfee on everything and called it a day, right? Oh, dear--you need firewalls. And countermeasures. Hrm...but you also need to make sure the guards don't punish the peasants: let the right people pass in and out of the gates, and keep the wrong people out. Don't forget to keep an eye on everyone so no one's sneaking your goods through the gates: your enemy pays a high price for your intellectual gold.
What to do with all this growth? "Go Enterprise", they say. The word "Enterprise" signifies a bold business venture. It's both Star Trek and an aircraft carrier--sounds pretty robust.
Enterprise IT is robust. The simplest explanation is this: it manages big systems, in a big way, by thinking big.
And requires you to chuck everything out the window and start over. Really, when IT scales to the Enterprise, it's a good idea to build out the entire infrastructure for an Enterprise scale of operations, and it's a bad idea to try to get there by just bolting on pieces-parts to an existing system.
This is when you start to realize that the NASCAR way is not your way: you don't need a ton of stickers on your Formula One, you just want a couple. No, I don't need Microsoft, SAP, HP/Compaq, Cisco, Symantec, IBM, and some third-party vendors to wander around tinkering with things: just Dell and Microsoft will do. Maybe some Cisco to tie it all together.
Time for another huge sigh of relief: the system is done. It's out there for everybody--Intranet, Internet, Extranet.
So now what? Time to sit back, and reflect. No, really--reflection is good for the soul. Amidst that hive of activity, there are a lot of busy bees bumping heads. You need to turn your gaze inwards. Work that Enterprise system to build a better Enterprise. Use Reporting to tell you what everyone's doing, and how it's working out. Use Analytics to uncover how they're doing it, and see if maybe they could be doing it better.
Are you ready for the challenge? Because the last thing you want to do is outsource it. Vendors will line up at your door if you say you need Business Process Reengineering, and they'll eagerly drop all those buzzwords that got you into IT in the first place: "out of the box", "robust", "turnkey", "integrated" and of course, the twins: "zero configuration" and "high ROI".
At the end of the day, nobody cares about your company like you do. Care enough to find good people who'll commit to the Enterprise. Bring them in, put them to work, and treat them well. You'll find that everything you do isn't as disposable as it once seemed. You'll see that there's a price for dumping developers back in the ocean and fishing around for more. It costs time and money to jettison Project Managers and have the new one rebuild political bridges. And no one knows your systems like your Analysts do. They're the ones who understand your users, and figure out how your IT can serve them.
More headaches? Well, yes and no. More of a brief aftershock, followed by an epiphany. You'll know that an Enterprise-level company deserves a system to match. And you'll see that everyone being on the same page will always serve the Emperor better than a land of fiefdoms.
Then the headaches kick in.
A new version comes out. One upgrade broke another system...until you bought that upgrade too. Now your employees need new machines: the old ones are just so slow.
By the way, the good news is, there's a new Operating System to buy. The bad news is, it's full of bugs and security holes.
Uh-oh--security! I bet you didn't give IT Security a second thought when you put all this together back in the '90s. You slapped McAfee on everything and called it a day, right? Oh, dear--you need firewalls. And countermeasures. Hrm...but you also need to make sure the guards don't punish the peasants: let the right people pass in and out of the gates, and keep the wrong people out. Don't forget to keep an eye on everyone so no one's sneaking your goods through the gates: your enemy pays a high price for your intellectual gold.
What to do with all this growth? "Go Enterprise", they say. The word "Enterprise" signifies a bold business venture. It's both Star Trek and an aircraft carrier--sounds pretty robust.
Enterprise IT is robust. The simplest explanation is this: it manages big systems, in a big way, by thinking big.
And requires you to chuck everything out the window and start over. Really, when IT scales to the Enterprise, it's a good idea to build out the entire infrastructure for an Enterprise scale of operations, and it's a bad idea to try to get there by just bolting on pieces-parts to an existing system.
This is when you start to realize that the NASCAR way is not your way: you don't need a ton of stickers on your Formula One, you just want a couple. No, I don't need Microsoft, SAP, HP/Compaq, Cisco, Symantec, IBM, and some third-party vendors to wander around tinkering with things: just Dell and Microsoft will do. Maybe some Cisco to tie it all together.
Time for another huge sigh of relief: the system is done. It's out there for everybody--Intranet, Internet, Extranet.
So now what? Time to sit back, and reflect. No, really--reflection is good for the soul. Amidst that hive of activity, there are a lot of busy bees bumping heads. You need to turn your gaze inwards. Work that Enterprise system to build a better Enterprise. Use Reporting to tell you what everyone's doing, and how it's working out. Use Analytics to uncover how they're doing it, and see if maybe they could be doing it better.
Are you ready for the challenge? Because the last thing you want to do is outsource it. Vendors will line up at your door if you say you need Business Process Reengineering, and they'll eagerly drop all those buzzwords that got you into IT in the first place: "out of the box", "robust", "turnkey", "integrated" and of course, the twins: "zero configuration" and "high ROI".
At the end of the day, nobody cares about your company like you do. Care enough to find good people who'll commit to the Enterprise. Bring them in, put them to work, and treat them well. You'll find that everything you do isn't as disposable as it once seemed. You'll see that there's a price for dumping developers back in the ocean and fishing around for more. It costs time and money to jettison Project Managers and have the new one rebuild political bridges. And no one knows your systems like your Analysts do. They're the ones who understand your users, and figure out how your IT can serve them.
More headaches? Well, yes and no. More of a brief aftershock, followed by an epiphany. You'll know that an Enterprise-level company deserves a system to match. And you'll see that everyone being on the same page will always serve the Emperor better than a land of fiefdoms.
Subscribe to:
Posts (Atom)