Good I.T. Manager, Bad I.T. Manager

Good Manager: Understands that developers are on the critical path: nothing "is" until someone writes some code.
Bad Manager: Thinks that developers are no different than business analysts, admins, or envelope stuffers, and treats them that way.

Good Manager:  Understands that formal process, while invaluable, is not infallible and must be augmented by the performance of excellent people.
Bad Manager: Forces creativity and determination to take a back seat to process.

Good Manager: Wants people to be "intrapreneurs", to feel as if they're running their own little "business within a business".
Bad Manager: Thinks that being "part of the team" is more important that getting work done, no matter what it takes.

Good Manager: Listens.
Bad Manager: Talks.

Good Manager: Strives to understand customer issues deeply as a basis for all technology decisions.
Bad Manager: Forces customers to fit into his vision of technology.

Good Manager: Prototypes and iterates in order to learn "what".
Bad Manager: The specs are the Bible, at least until Version 2.0.

Good Manager: Ready, Aim, Fire. Or when super speed is needed: Ready, Fire, Aim. 
Bad Manager: Fire. Fix. Fire. Fix. Fire. Fix.

Good Manager: Prioritizes "why"; facilitates "what"; accepts "how".
Bad Manager: Dictates "how". Blames when "what" doesn't match "why".

Good Manager: Daily interaction.
Bad Manager: He works here?

Good Manager: Leader.
Bad Manager: Politician.

Good Manager: Encourages customers to provide input and feedback.
Bad Manager: Depends upon training and documentation when customers don't "get it".

Good Manager: Encourages developers to identify their needs and is eager to satisfy them.
Bad Manager: Blames developers for missing deadlines when they lack the resources they need.

Good Manager: Offices or war rooms.
Bad Manager: Cubicles.

Good Manager: Intense interaction as needed.
Bad Manager: Meetings.

Good Manager: Has finger on the pulse of the organization.
Bad Manager: Needs town hall meetings and web conferences.

Good Manager: To foster moral, always strives to do the right thing.
Bad Manager: To foster moral, cheerleading and gimmicks.

Good Manager: Developers love coming to work.
Bad Manager: Developers love their work in spite of their company.

Good Manager: Googles you.
Bad Manager: Wants you go Google him.

Good Manager: Watches the project plans and schedules.
Bad Manager: Watches the clock.

Good Manager: Stays for years until our baby grows up.
Bad Manager: Moves on just before the smoke and mirrors clear up.

Good Manager: Worries about 2 things: Getting our work done and keeping our people.
Bad Manager: Worries about 2 things: How he looks and how he feels.


Bad, Better, Best in IT

Bad: Cubicle
Better: Office 
Best: Whatever works best for you.

Bad: Meetings without agendas. 
Better: Meetings with agendas. 
Best: Meetings whose need is so obvious to everyone that no agenda is needed.

Bad: Specs, waterfall, Systems Development Life Cycle. 
Better: Prototyping, agile, scrum. 
Best: Developers with enough domain knowledge to just build it.

Bad: No documentation. 
Better: Documentation. 
Best: No documentation needed.

Bad: No formal process. 
Better: Formal process. 
Best: People so much bigger than their jobs so that process is rarely relied upon.

Bad: Theory without experience 
Better: Experience without theory 
Best: Both

Bad: Help desk without programmers. 
Better: Programmers available to customers. 
Best: Code that just works.

Bad: Phone calls 
Better: Emails 
Best: Application software that encapsulates required communication

Bad: Code with early exits. 
Better: Code without early exits. 
Best: Code so simple because of the underlying data structure that the early exit debate is moot.

Bad: Bugs 
Better: Fixes 
Best: Enough 9's to never notice.

Bad: programmer error 
Better: user error 
Best: What's an error?

Bad: Missing deadlines 
Better: Hitting deadlines 
Best: A track record so good that deadlines are never given

Bad: Complex org chart 
Better: Simple org chart 
Best: Technology so sophisticated, less people are needed

Bad: Non-technical boss 
Better: Technical boss 
Best: No boss

Bad: Management 
Better: Leadership 
Best: Self-motivation

Bad: Best practices, with a Capital "B" (industry standards) 
Better: best practices, with a small "b" (what we figured out) 
Best: Just do your job.

Left-Handed Baseball Gloves

A local Sporting Goods retailer that had just acquired a Baseball competitor. Their ecommerce system had a clever database structure to make ordering easy from either the website or the call center. For any given Product, there could be hundreds of Stock Keeping Units (SKUs) based on Sport, Size, Color, Number, or other attribute. The database was easy to use but difficult to load.

Jim was brought in to build a one-time application that would build all the data base records needed from Excel spreadsheets from the old system. In addition, every SKU in the system had to be "smart"; that is, anyone can tell everything needed to know just from looking at the SKU. For example, a Wilson A2000 medium left handed female softball catcher's mitt might be: WIL-A2000-M-LFSC-01.

Jim wrote the application to build and load all the SKUs, Sales Orders, Work Orders, Inventory Locations, Boxes, Bins, history, and supporting indexes. He had 10 users log in to the new fulfillment system and update all the activity not on an Excel spreadsheet. This took 2 days.

Then a strange thing happened. The owner of the acquired company asked why they coded all of the left handed SKUs as right handed and vice versa.

Huh? Apparently the people from the acquiring company who encoded the Excel spreadsheets didn't realize that a left handed player wore their glove on their right hand! Every data base record was wrong.

The choices to fix this were:

1. Make L = Right and R = Left forever.

2. Jim could add one line of code to his load application to reverse the bad data on the Excel spreadsheets, rerun it, and then redo 2 days of data entry.

3. Jim could write a "quick and dirty" one-time program to fix 500,000 bad data base records. It would take a day or so to write, test, and run, but no one could do anything until he finished.

They chose Option 3, sent 5 people home, and had the other 5 do other work.

BIG QUESTION: Why didn't anyone in a Sporting Goods company know that a baseball player wears their glove on their non-throwing hand?

BIGGER QUESTION: Why didn't anyone from either company review any of the plans, specifications, or data BEFORE work began?

BIGGEST QUESTION: Why didn't a Sporting Goods company that had made 9 acquisitions in the past 3 years have any standard methodolgy to do acquisitions? Why did they even need Jim?


Famous Last Words by Bosses I've Had

Sorry to say, none of these were made up...

Me, 124 Monday lunches in a row: We need an adequate disaster recovery plan.
Boss: We do. We back up every day.
Me:   What happens when we try to restore one of those backups?
Boss: I don't know. Why?

Me:   Where's the test plan?
Boss: Jerry will make sure Fred's program works.

Me:   Where's the "Expected Results" section on the test plan?
Boss: What?

Me:   I don't have access to the production server.
Boss: I already emailed you your password.
Me:   I know, but I don't know my login.
Boss: What's a login?

Me:   That doesn't make any sense. Have the auditors approved it?
Boss: No, but we can't have everything.

Boss: I'm really upset that no one has updated me on Project 127.
Me:   I cc'd you on all 9 Project 127 emails I sent this week.
Boss: I haven't had time to get caught up on my email.

Me:   You've been invited to a meeting with 3 department heads to hash out their differences on Project 249.
Boss: I hate meetings.

Boss: Why haven't you started the Accounts Receivable project yet?
Me:   Because management has not yet decided whether customer credit limits should be per division or companywide.
Boss: What difference does that make?

Boss: We have hundreds of past due orders.
Me:   No, we have 22 past due orders.
Boss: I'm not going to argue with you.
Me:   Good, because you'd lose.

Me:   We're meeting with the customer at 8:00 a.m. tomorrow.
Boss: I hate mornings.

Me:   The server crashed. IT Services is working to bring it back up.
Boss: Don't confuse me with all these technical details.

Me:   The customer didn't receive that information because that product is not on our computer.
Boss: Give me a list of all products not on our computer.

Boss: Why haven't you started Project 193 yet?
Me:   Because the customer has not yet committed to the specs.
Boss: What difference does that make?

Me:   The program was written with 3 SQL selects inside a loop. It ran OK when we had 500 parts. Now that we have 10,000 parts, it runs real slow.
Boss: I don't understand.

Boss: What are you working on?
Me:   Project 432, which you said was my top priority. Remember?
Boss: No.

Boss: Why aren't you working on Project 387?
Me:   Because you said not to work on anything else until Project 432 was complete. Remember?
Boss: No.

Boss: I'm giving you only enhancements. I'm outsourcing all of the bug fixes.
Me:   But this is a bug fix. It says so right here on the ticket.
Boss: Oh, I didn't have time to read the ticket.

Boss: Amazon is threatening to shut us down because we ship too many orders late. How do we fix this?
Me:   Ship every order on time.
Boss: No, I meant, "How do we fix this with software?"

Boss, on December 31: Write a program to close every work order so we make our year end numbers.
Boss, on January 3:   Why is the database so screwed up?

Boss: You did great this year. I'm giving you a 2% increase.
Me:   I hate you. I quit.
Boss: Then I'll give you a 4% increase.
Me:   I still hate you. I still quit.