November 29, 2006 | Comments: (0)
I HAVE A QUESTION I HAVE A BOSS WHO IS SO FRUS-TRADED ALL THE TIME AND WHEN I AM AROUND HER SHE MAKES ME THINK. I AM DOING MY JOB INCORRECTLY I AM NOT AS FAST AS SO AND SO, I DO'NT BELONG IN THIS DEPARTMENT. I TELL HER BOSS ABOUT HER BEHAVIOR AND ALL SHE TOLD ME WAS TAKE HER COMMENTS WITH A GRAIN OF SALT I CAN'T TAKE IT ANY MORE I IT'S REALLY STRESSING ME OUT. PLEASE HELP.
- AGITATED
Dear Agitated ...
There are two different aspects of your question, and I have to deal with them independently. The first is how your manager is interacting with you. The second is how you should deal with what you're experiencing.
Your manager should not be expressing her dissatisfaction in emotional terms. One of the core rules of effective communication is that if you don't control your emotions, they'll control you. There are effective ways to provide employees with guidance about how they are performing and how they should be performing. It appears your manager doesn't know them.
She should, but she doesn't. That means it's up to you to make the communication between the two of you more productive. Your first step in doing so is to recognize that your manager's frustration is coming from somewhere. If she behaves this way with everyone, then it's probably an external source, like upper management, and she's unable to keep herself from venting.
It happens.
If, on the other hand, it appears to be focused on you then I'd recommend taking a good, hard look at your performance - both your formal performance, and what you're like to work with. This is difficult under the best of circumstances. When someone feels like they're being attacked, as you are, it's even harder for them because the instinctive response to an attack is to either defend or counterattack.
Try this: Filter out the emotion and frustration and concentrate your attention solely on the information content of her message. Is she telling you something about your work that you need to address?
Try this, too: The next time your manager expresses frustration, respond by taking responsibility for it, as if it was legitimate and you really are the cause. For example, "It appears I've done something that's frustrated you. I apologize - it certainly wasn't what I had in mind, and I need to know what it was, and what I should have done instead. Right now I don't have a clear picture of it - can you help me understand it better?"
You need to make it an okay subject to talk about. Perhaps then your communication can be more productive.
On a related note, reading your note to me it's clear you would benefit from improved writing skills. The combination of all-capital letters and errors in spelling and grammar create a poor impression of your abilities. If you can find a course in business writing at your local community college I'd advise taking it. If not, get hold of Strunk and White's The Elements of Style. Read it cover to cover (it's quite thin) and follow its guidelines.
You might even find that as you become a more effective communicator, your boss will become less frustrated with you.
- Bob
Posted by Bob Lewis on November 29, 2006 05:13 AM
November 28, 2006 | Comments: (0)
Dear Bob ...
I want to open an e-store but I don't know the first thing about building websites and maintaining them. I would like to find a company that does this kind of work. How do I find a good one and approximately what kind of expenses am I looking at?
Thanks for your help - your advice is always good reading.
- eBuilder
Dear eBuilder ...
The answer to the question you're asking is pretty simple, so I'll answer it last. Before I do, I'll answer the two questions you should have asked first. You've probably asked and answered them both already, but just in case ...
Imagine your e-store is up and running. That means you're presenting and describing your products, accepting orders, and processing credit cards. That leads to the possible missing question: Have you set up all of the systems and processes you'll need so you can keep track of the orders, ship products, and manage your inventory? None of this is part of your website, but it's emphatically part of running an e-store.
You'll make your life a lot easier if you get all of this up and running before you put up your website than if you decide to muddle through for awhile, for a very simple reason: Once you're selling product and handling your backoffice the hard way, you won't have any time left to set up your operation. The result: You'll pray for failure so you can get some sleep.
Here's a second question: Once you find companies that do this kind of thing, how do you screen them to find the right one? Here's a shortlist of criteria. It's far from complete, but it should get you started:
* Does their system let you easily add and edit content, add and replace pictures, and update prices?
* Does their system use standard, off-the-shelf shopping cart software, or do they custom-code? (Custom coding is the wrong answer - a warning sign.)
* Do they provide a full merchandising toolkit that includes searching, the ability to assign products to multiple categories, and to associate different products so your website can suggest "upsells"?
* Do they support multiple shipping methods and handle the calculations for shipping costs?
* If you're planning to ship internationally (and remember, Canada isn't part of the United States), do they support international credit card processing?
* What kind of testing facilities do they have, and what kind of testing methodology do they use? Remember that you always test your website. The only question is whether you catch bugs before your customers find them, or whether your customers do your testing for you. (Having customers find your bugs for you is the wrong answer.)
Now it's time to answer your question: Visit the websites of every e-tailer you can find that's located in your vicinity. Keep track of the ones you like. Somewhere near the bottom of each homepage you'll generally find the name of the company that put it together. Those are the companies you want to call.
And you do want to work with a local company. The ability to drive to their location and discuss what you want face to face, drawing diagrams on their whiteboard and marking up layouts with markers is invaluable - far more effective than even the best remote collaboration tools.
There's certainly more to think about ... you are, after all, starting up a complete business from scratch (I assume). For example ... how you plan to provide customer support ... but this should get you started.
- Bob
Posted by Bob Lewis on November 28, 2006 09:06 PM
November 28, 2006 | Comments: (0)
Handling another interview question
Dear Bob ...
Since we're on the topic of interview questions ...
What's a good way to answer why you're leaving your current position? In my case, it's new upper management starting down a path that IMO leads to outsourcing the department. But in general, you're always leaving because of something you don't like about it. How do you answer this without looking like you're going to leave the new position as soon as you disagree with the current management?
- Ready to leave
Dear Ready ...
"Why are you leaving your current position?" is another example of a disqualifying question - one where even the most brilliant answer won't help you, but where an inept one will hurt. Answer it quickly and inoffensively and move things along to a more productive subject.
So:
"I'm ready to take on a new opportunity - one that will offer more responsibility. Right now my employer appears to be pursuing an outsourcing strategy. It's probably the right direction for the company. I don't see it taking me where I want to go, which is to ..."
Or:
"I've been doing the same work for a number of years and I'm ready to take the next step. Luckily for my employer, the whole management team is stable, very competent, and works very well together. It makes it a great place to work - but the result is that there really isn't anywhere to go there."
So long as you provide a short response that doesn't say something negative about your employer and doesn't open the door for a longer conversation, your answer will have done its job.
- Bob
Posted by Bob Lewis on November 28, 2006 05:07 AM
November 22, 2006 | Comments: (0)
At the risk of being uplifting, here's a quick thought in honor of Thanksgiving:
More than two billion people have no access to basic sanitation. The same number figures a bowl or two of rice a day means they've fed well.
For much of the world, malaria is a fact of life, as is losing children to curable diseases. Hunger isn't something you experience because you're trying to lose weight, and trying to lose weight is a baffling concept.
So as you put up with the bugs and security holes in Vista and Internet Explorer 7, or with annoying end-user requests, or conflicting design requirements in your next software development project, keep in mind a distinction made by Robert Fulghum: The difference between a problem and an inconvenience.
Enjoy the holiday - your life is better than you know.
- Bob
PS: Don't worry. I'll return to being sarcastic and easily annoyed next week.
Posted by Bob Lewis on November 22, 2006 08:11 AM
November 21, 2006 | Comments: (0)
Dear Bob ...
Recently my office partner of 15 years retired. His replacement comes
from another department and will be bringing along a software system
that requires after hours support.
Firstly, I don't much care for the replacement that was hired--I voiced my
objections but ultimately had very little say in the matter. Second, it now
looks as though I'll have to have a part in providing after hours support
for this software system that the replacement worker brings with him.
Pretty much, I am now quite resentful. I realize that after hours support
for systems is a fact of life in IT, but the way in which this particular situation
presented itself has me bitter.
What are my options? Just refuse to do any after hours support for this
software, regardless of the consequences? Demand additional compensation?
Spread the misery (I'll do it if the staff who hired this guy also does it)?
- Unhappy
Dear Unhappy ...
Generals make decisions. It's the troops who live or die. That's how it works. Soldiers who pick and choose when they follow orders based on whether they agree with them or not end up in the brig ... if they're lucky. (The situation when orders are immoral is more complicated and not parallel to your situation.)
You voiced your objections. Management disagreed with you and made its decision. I'm sympathetic - it happened to me any number of times in my career, and I had the opportunity to say "I told you so" after many of them. Unwisely, I took advantage of the opportunity far too often.
But while I'm sympathetic with your situation, I'm not sympathetic with how you're responding to it. Do you expect management to always agree with your analysis of a situation? If so, it's time to recalibrate. They won't, and if they did it would just mean they're disappointing someone else whose analysis disagrees with yours and who is just as eloquent in expressing it.
What are your options? You have three. You can live up to your new responsibilities with grace and professionalism. You can find another job.
Or you can give yourself a reputation as a prima donna. I don't recommend it, though. It's a reputation that's hard to shake once you acquire it, and will do you far more harm than the occasional inconvenience of having to provide after-hours support.
- Bob
Posted by Bob Lewis on November 21, 2006 10:16 AM
November 17, 2006 | Comments: (0)
Improving a small IT organization
Dear Bob ...
I've only been with my current company for about one year and have tried to influence change around verbal commands. I have traditionally worked for large organizations (100-500 developers) and now sit in a small organization (5 developers). OK back to my point ....Verbal Commands. A typical day in the office starts out with someone in the hall or over the phone requesting something from IT. I respond back to them asking that they write it up so we have a record, etc., etc., and guess what? I never get anything. But sometime later my manager says you didn't deliver this or that and I'm caught in a trap.
Now to my development team. When I do get something in writing instead of wanting to drill further into each item they go start development in the back room. Ouch I say. When I walk into the back room there are no design diagrams, no code reviews, no strong architecture leadership, no task assignments, etc. All I hear from my developers is "well it works like this ...," the old tribal legacy being passed on.
If you can pull something out of the archives that would be great. Or is this new content? Thanks for listening I feel better. No one here listens.
- Trying to help
Dear Trying ...
You aren't going to like what I have to say about this. You are right about something. At the end of your letter, you say, "no one here listens." The statement is truer than you realize, because "no one" includes you.
It appears you're operating under the common perception that a five-person IT department is just like a 500-person division, only smaller. That simply isn't the case.
When you work in a 5-person department, there are exactly 10 pairs of people. That's easily managed informally, by just talking with each other. A 500-person department has 124,750 pairs of people. It's the single most important reason a department this size relies on well-documented processes: It's impossible for this many people to understand each other well, anticipate how each other will react, and organize their work informally.
Working informally through relationships is far more efficient than working through well-defined processes when the number of people involved is small. Process imposes overhead but it scales better.
You also raised another point which is a hot-button for me: The idea that the documentation should be the primary communications channel. Whether you're working in a 5-person department or a 5,000 person department, this is one of those consultant-driven ideas that's ideally suited to covering IT's backside, but poorly suited to getting useful work done. When someone shows up at your cubicle with a request, have a conversation. Interacting with someone face-to-face, where you can both sketch ideas on a whiteboard or piece of paper while seeing each others' expressions and body language, is a far more efficient way to communicate than in written documents.
Once you've finished the conversation, you can document it so you have something to remind you of what you agreed to in the conversation.
I certainly agree with you that design should precede coding. It's an important improvement, which you should introduce to your colleagues. If you want to succeed at this, the first step is to become one of their colleagues. Very few ideas have ever been successfully introduced to any organization by an outsider.
So your first step is to adapt yourself to the organization as it is. I suspect that once you do so, you'll never want to go back to big IT, because small IT is usually a lot more enjoyable and rewarding. Once you're part of the team, you'll be in a position to suggest some better ways of operating.
Assuming, that is, that you still think they're better.
- Bob
Posted by Bob Lewis on November 17, 2006 10:27 AM
November 15, 2006 | Comments: (0)
I don't normally post twice in one day, but I didn't want to lose the thought.
The past three Keep the Joint Running columns have been based on Jared Diamond's Collapse: How Societies Choose to Fail or Succeed (see "Collapsible business lessons," 11/6/2006). A friend, reading them, suggested that usually, negative feedback loops will act to prevent collapse.
That's when it occurred to me: The mathematics of negative feedback covers the Collapse effect nicely. It works like this: If you take the basic logistics equation (x at time (n+1) = max(rx(1-x),0)) and play with the parameters, you'll find that for a wide variety of conditions (so long as x is a fraction and r is less than 2.2 or so) you'll end up with a stable system.
Now, delay the feedback (make it x at time (n+2) or (n+3) = the formula). The result is that the system destabilizes - it grows unpredictably and wildly, then crashes to zero.
This is exactly what happens in Collapse situations: The factors that should lead to moderation of population growth don't happen immediately, and so they go unrecognized. The feedback is delayed, and the result is chaos and collapse.
The lesson is clear, really pretty obvious, and applies to a wide variety of situations: Make decisions based on current information, not what was true a year or two ago. Situations change, and if you don't notice the change, what you "know" is what used to be true, not what's true right now.
- Bob
Posted by Bob Lewis on November 15, 2006 06:42 AM
November 15, 2006 | Comments: (0)
Dear Bob ...
I'm wondering what the best way is to get a website removed or banned from the Internet. I believe that is it not only offensive to me, but it speaks about things that it says my lifestyle agrees with. Which in fact is not true.
Thank you for any help you may provide.
-Offended
Dear Offended ...
I'm not sure what, exactly the issue is. Also, I'm not an attorney. In general, to the best of my knowledge, the situation is like this: If the site is defamatory and you feel personally libeled by it, then you could contact an attorney and file suit. If you think its content is illegal for some reason you can contact your state Attorney General.
If, on the other hand, you find it offensive but aren't personally defamed by it and don't think it breaks any laws, then the solution is to not visit the website.
So far as I know, the only way to ban a website from the Internet is if its domain name infringes on another company's brands or trademarks. If that's the case, the infringing site generally has to cede the domain name to the company that owns the trademark. Even in that case, the site can be moved to a new domain.
So unless the site mentions you by name or shows your photograph, I'd recommend ignoring it. The good and bad news about the Internet is that it allows everyone to find whatever path to perdition they want, without anyone else telling them they can't.
I figure that's a good thing.
- Bob
Posted by Bob Lewis on November 15, 2006 05:07 AM
November 10, 2006 | Comments: (0)
Holy cow! as Harry Carey used to say. My last post - about voting machines ("A post-election rant,"Advice Line, 11/8/2006), that asked how it's possible that such a simple problem has been turned into such a collosal fiasco - led to more response than anything else I've written here, with the possible exception of the time I brought up birthday parties and Jehovah's Witnesses ("Handling an employee who refuses to celebrate," Advice Line, 1/4/2006, and please ... no more on that one!)
To those who disagreed, complaining that I oversimplified a problem that really is complex, I have three things to say:
- I'm completely unencumbered by facts, and plan to keep it that way. That's why it's called a rant, and not a well-reasoned critique of the situation. Hey, sometimes a guy just has to have fun, and what can be more fun than criticizing the hard work of people you don't know and will never meet? (Please - don't post any comments in response to that question either. I have to filter out enough spam comments as it is.)
- Scope creep: I bet that a big reason for the unwarranted complexity is that we're asking these systems to do more than record and tally votes - probably, some well-intentioned system designer or sponsor figured out that since we're going through the trouble, we might as well ask the system to keep track of voters, their registrations, where they should vote, whether they already voted someplace else, what the exit polls said, traffic conditions, and a bunch of other useful things to do that have nothing to do with recording and tallying votes. Put all that stuff in future releases and the problem becomes much more manageable.
- "Simple problem" is a relative term. I'm well aware that in IT, "simple" means pretty durned hard, "difficult" means "if we make quite a few design compromises we might deliver this before we all retire," and "hard" means "finishing this is what purgatory is for." Unencumbered by the facts as I am, I actually am pretty confident that the main design challenges for a voting system fall into three categories: scaling (ideally, there are a lot of voters to tally), exceptions (for example, one commenter pointed out that some polling places handle multiple precincts, and that different geographic classification systems - for example, counties, cities/townships, and zipcodes - don't always fit together nicely), and security.
Which gets us to security. The solution to this is to stop trying for perfection, and instead be happy with good enough - in this case, the prevention of large-scale fraud. There is no way to prevent fraud at the individual polling place. The old Daley voting machine (of the political, not technical, variety) demonstrated this: Daley had precinct workers accompany voters into the booth to help them make sure they voted for the right candidates.
Set up a system that requires on-site presence for fraud and fraud won't scale enough to be much of a problem. Add a simple audit trail (I'm far from the first to suggest this) and the solution really is good enough.
For all of those who suggested that mark-sense paper ballots will do the trick just fine ... they probably will. They also chop down an awful lot of trees.
- Bob
Posted by Bob Lewis on November 10, 2006 05:09 AM
November 08, 2006 | Comments: (0)
So here's what I wonder:
I read recently that in the primaries, and during the absentee balloting that preceded the elections, touchscreen voting machines proved to have serious problems, frequently failing to properly record and tally votes. Over the past six years or so I've read all manner of experts weigh in on this subject, and haven't yet read one who has pointed out what I think is obvious to readers of this blog (and anyone competent to read any blog): We're talking about an awesomely simple programming task. Here's what it takes:
* A table listing the candidates, the office for which they are candidates, and their party affiliations, which can be downloaded into a server located in each polling place.
* A cheap web server in each polling place that stores the candidate table and renders it into a ballot.
* Voting machines equipped with browsers, touchscreens, and printers.
* A program that runs in the server that records the results for each voter into a votes table that can be uploaded when the polls close, and that prints out a "receipt" for each voter, to verify their vote and to be used in a manual recount should one be needed.
* A dial-up modem, attached to the web server, to provide a temporary connection to the central system before the polls open (to download the setup) and when they close (to upload the results).
* A central server to accept the votes tables, consolidate them, and run a simple SQL query that tabulates the results.
* Pollwatchers alert for voters who covertly approach the site server with their own mouse and keyboard to try to hack the system without anyone noticing.
There is, to be repetitious, nothing remotely complicated about building a voting machine system. There are those who would claim that calibrating the touchscreens and maintaining the calibration is a challenge. I certainly sympathize. As anyone knows who uses a Palm PDA knows, you have to calibrate your screen ... oh, wait. You have to calibrate a Palm PDA touchscreen exactly once, when you take it out of the box for the first time. After that, it holds its calibration approximately forever.
Conspiracy theories abound about why touchscreen voting machine systems are so unreliable, most swirling around the sordid connection between the president of Diebold's voting machine division and the Republican party. I have a different theory:
The companies that sell these puppies have persuaded the agencies that buy them that the technology involved is difficult and complex, so as to raise the price beyond the $350 per voting machine and $1,500 per site server that should be the maximum for hardware and software that is, in every respect, less complicated than the market survey systems provided commercially and inexpensively by any number of providers for use on the World Wide Web.
- Bob
Posted by Bob Lewis on November 8, 2006 05:03 AM
November 07, 2006 | Comments: (0)
Dear Bob ...
I had a phone interview with an HR screener a few months ago. She said: it's been a while since you've worked for a large company - I don't think you can do that any more. She went on to say that the five staff members have been working for large companies for the past five years. I'm not the kind to raise my voice, but I DID ask: What is it that you think I'm lacking when it comes to working for a large company?
She got 'REAL' defensive at that point: "I don't have to explain myself to you..." Well, needless to say I don't think I backtracked very well out of that one!
No to be fair to these employers, all I have is several years of experience (I leave off the military stuff so I don't see TOO experienced (
How do you think I should have handled the comment?
- HR-challenged
Dear Challenged ...
You describe an interview situation that comes up over and over again - the interviewer assuming a disqualifier. I don't know why they do this. I think an inference about it is reasonable: They wouldn't be talking with you if they really thought the issue was a deal-breaker, so they must be raising it to see how you'll respond.
So here's how you respond. In general, do your best to anticipate what they're likely to be. Most ad libs are rehearsed, after all - they aren't spontaneous acts of brilliance. If you are caught off-guard, memorize this phrase: "I get that a lot. I don't really think it's an issue, though. Here's why:" That gets you going in the right direction without putting either of you on the defensive.
So: "I get that a lot. I don't really think it's an issue, though. Here's why: I don't put my years in the military on my resume, because it would add a lot of length without adding a lot of value. As I think you know, the military is a pretty big organization, and I did pretty well there. I also worked in a couple of big companies before starting to work in smaller ones, and what I discovered is that most big companies act just like a collection of small ones. Either way it's about managing the right relationships, and that's something I've focused on throughout my career."
If that explanation doesn't fit your experience, figure out another one that does. Whatever it is, also remember the first rule of handling disqualifying questions: Answer them as briefly as possible, and then redirect the conversation to a qualifying subject. So here, you might finish by asking a question of your own that points things in the right direction. For example: "Not all big organizations are the same, and I'm guessing you had something specific in mind about your company when you raised the point. What, in particular, do you see as the biggest organizational challenges associated with this position?"
And in case you didn't recognize the phrase, "organizational challenges" is a nice euphemism for "political landmines."
- Bob
Posted by Bob Lewis on November 7, 2006 04:38 AM
November 02, 2006 | Comments: (0)
The question of keeping spare PCs on the shelf, which I mentioned in a recent post ("Budgeting when there aren't any budgets,") Advice Line 10/31/2006) seems to be more controversial than I'd expected. Especially, some readers expressed concern that they'd be chewed out by the CEO for having them.
This brings up the issue of persuasion - how do you present your decisions in ways most likely to get them accepted. There's no magic formula for this. There are some guidelines, though. Two are: (1) Always work within your audiences' experiential framework, not your own; and (2) explanations that are simple and direct work better than those that are complex and subtle.
Here, these guidelines lead to a simple solution: Include the spares in your business continuity plan. Business continuity plans aren't always about losing an entire building and the surrounding city block. They're also about how to handle an unexpected snowstorm.
And the loss of a single PC or server.
If you include your spares in your business continuity plan you'll find they turn into a rounding error that's of no interest at all to your CEO, except to the extent that they identify you as a pragmatist who knows how to deal with real-world situations in a practical way.
- Bob
Posted by Bob Lewis on November 2, 2006 04:22 AM
November 01, 2006 | Comments: (0)
More about winning the budget game
Dear Bob ...
As usual, thanks for the great discussion (in "Playing stupid games to win ... or at least to not lose," Keep the Joint Running, 10/23/2006).
Per your comment: "In practical terms, this means agreeing to whatever cuts in your budget are proposed by the other side, making two points clear in the process: (1) the business will have to do without something as a result of the cut; and (2) you won't be the one in the headlights -- the standard governance process will be the mechanism through which the company decides exactly what the business will have to do without. That's what it's for."
My concern is a repeat of the client/server era: If we don't acquiesce to the line of business' demands they may go out and build/buy it themselves circumventing the process and cost of governance. We have to work with the lines of business to ensure that they see the value in the added costs of governance (complying with standards, documentation, disaster recovery backups, keeping an eye out for audit gotchas, etc.)
And yes, you can use my name.
- Veronica Sanford
Dear Veronica ...
Make that part of the discussion: If the budget process results in cuts to IT's budget and the governance process allows each line of business to pay outsiders to do the work if IT lacks the budget to handle it, then the IT budget cut won't result in less total corporate spending and will result in islands of automation that don't fit into the company's systems as a whole.
And ... your job is to make the risk clear. If the company wants each line of business to contract externally, bypassing IT, that's fine with you.
Another point I'd make to you is this: If the company's governance process is so onerous that it's easier to go outside, you should provide leadership to the company to improve the governance process.
If, instead, the problem is that the governance process sometimes results in results that are the right results but are inconvenient to various people in the business, then you should provide leadership to the company to clarify the level of authority associated with the governance process. If it's just the first store for LOB directors to shop in, it probably isn't worth the effort and should be abandoned in favor of a governance process that more accurately reflects how the company leadership wants decisions to happen.
There is a deeper challenge in the departments-go-shopping scenario that's very difficult for IT to deal with, and that's the cost of ongoing support. It takes two forms. The first is when the contracting department tires of supporting its application internally, and wants IT to take it over. That's relatively easy to handle: Feed these requests through the governance process as well. It's just another chunk of spending for value maintenance. IT should be delighted to take it on, so long as it gets the right budget increment to pay for it.
The second form is the cost of interface maintenance. Most systems developed independently by departments won't have any automated interfaces. Re-keying data is king. But there are some where the department heads aren't completely bone-headed, and recognize that integration with the existing IT environment, or at least some basic batch interfaces, are the right way to go. With all the best of intentions, IT will easily and frequently break these interfaces - not through malicious intent, but by accident. They aren't part of the applications inventory; aren't part of the standard regression testing suite; and aren't accounted for in the change control process.
To solve this, work with the outside developers, informing them of the process through which they can register the interfaces they build with change control. If it costs more ... explain the facts of life to whoever signed the contract, and make it clear that you don't care either way. They have to make a business decision, and if their contractor isn't willing to give away service for free ... huh. Imagine that.
- Bob
Posted by Bob Lewis on November 1, 2006 04:48 AM
|
Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account. Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them. Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline. ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings. Order your copies today! |
TOP STORIES
Top 10 stories of the weekA new place to hide rootkits
Sun exec on OpenSolaris, Linux
AT&T: No free iPhone Wi-Fi info
MS to appeal E.U. fine
XP SP3 causes endless reboots
Vista as insecure as Win 2000
Google grilled on human rights
Java ubiquity an edge in RIA battle
The InfoWorld news quiz
ADDITIONAL RESOURCES

- Virtualization: A Step by Step Approach to Success
- Dialing up Agility with Business Transformation
- 5 Things You Need to Know About Storage Virtualization

- Virtual Test Lab Automation: Manage development infrastructure
- Improve Resource Utilization and Lower Operating Costs
- Protect Your Data with SSL


