Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: How To Teach IT To Senior Management?

timothy posted about a year ago | from the first-there-were-the-dinosaurs dept.

Businesses 159

New submitter gagol writes "I recently took a position at a small industrial equipment manufacturer. We are looking to buy a new ERM software package and my boss, who is looking forward to buy the thing, knows nothing about computers or software. I will be providing basic IT training to the senior management and I am looking for your input on the scope and content of said training. I am thinking: basic components and architecture -> networking -> software -> proprietary vs open source. What do you think?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Focus on what they want to know (4, Insightful)

rsilvergun (571051) | about a year ago | (#43634713)

to get what they want done. My experience is adults learn best when a clear reward is in sight. Also, don't forget the tried and true method of adult education:

1. Tell them what you're going to tell them.
2. Tell it to them.
3. Tell them what you just told them.
I know, it sounds silly and redundant, but it's effective.

Re:Focus on what they want to know (-1, Flamebait)

Anonymous Coward | about a year ago | (#43634739)

1. Tell them their IT purchase decisions are infallible.
2. Tell them they can do no wrong. (They will think this already.)
3. Tell them they are truly gifted in making IT decisions, and the proof is how they made smart decisions in running the company.
4.. Tell them to hire another company to review their infallible decision, just to be on the safe side, and to give them cover if there are any problems.
5. Tell them to take full credit for the IT decisions they make, clearly making you the poor guy who has to go by the boss' decision...this provides you with cover when the decision backfires.

Example of focus (5, Insightful)

Okian Warrior (537106) | about a year ago | (#43634987)

Here's an example of how this works.

Suppose you are trying to sell a new computer to a company - an older machinist's shop whose office is still using Dos.

You *could* say "these new computers are dual core, 3 GHz, running Windows XP and Office suite". Their eyes will glaze over and you won't make the sale.

You *should* say "these new computers will save your company $2000 per month. Here's how:" ...and list the ways that the new computer will save them time. An hour here, an hour there - it adds up.

Present things in ways which are important to the listener. The big three are 1) Saves money over the long run 2) Saves time over the long run, and 3) Saves effort over the long run. Frame your information in those terms.

Re:Example of focus (3)

roman_mir (125474) | about a year ago | (#43635709)

It would be even better if the new machine actually made money, though yes, a penny saved is a penny earned, if the new equipment helps to earn some new money that wasn't earned previously, then you will definitely get attention.

Re:Focus on what they want to know (1)

Sulphur (1548251) | about a year ago | (#43634995)

Teaching is selling. Take a cue from the salesmen with the benefit of your well functioning B.S. filter.

Re:Focus on what they want to know (5, Funny)

jamstar7 (694492) | about a year ago | (#43635025)

4. Use a large club. Remember, first you have to get their attention...

Re:Focus on what they want to know (0)

Anonymous Coward | about a year ago | (#43635905)

4. Use a large club. Remember, first you have to get their attention...

Axe surely? (it's management, taking one of these beasties to IT spending is something they're familiar with)

Re:Focus on what they want to know (1)

Anonymous Coward | about a year ago | (#43635889)

Just the place for a Snark! I have said it thrice:
                What I tell you three times is true.''

None of the above (5, Insightful)

GerryGilmore (663905) | about a year ago | (#43634719)

If you are going to be training senior management, focus 100% on the ERM software and how they can use it for their business needs. They could likely care less about the underlying plumbing and it would take much more time and effort than they'd be willing to undergo, plus it's not in their interests to do that. That's why they hire smart IT guys, right?

Re:None of the above (1)

That_Dan_Guy (589967) | about a year ago | (#43634765)

Yes and no.

They care about ERM as it is what they see IT as doing for them. But don't forget that they need to be aware of the things that impact their ability to use it. Getting all 10 meg Hubs and running it on an old white box P3 will destroy their ability to do anything with it at all.

So things like the network and servers need to be described as important for it to function up to expectation. Doing this up front so they will be prepared to listen down the road is important.

Connectivity, availability and performance are dependent on things other than the software itself. You might mention them and tell them to expect they may need to upgrade certain part of the network to get this up and running. Disaster recovery is important as well.

Don't waste your time (3, Insightful)

Anonymous Coward | about a year ago | (#43635003)

None of those issues matter to them at all. Unless you get to lead the requirements discovery process, odds are the decision will be finalized in haphazard manner without much thought about the technical details or the final desired outcome. As the technical guy, they'll leave it to you to sort out the details, so beware of becoming their scapegoat or janitor later on. They have a hope that this software will provide value to the company. Your job is not to squash that hope, but bring expectations down to realistic levels and make sure plans and commitment for the future is peroprly in place.

The best thing you can do, is demand to be in charge of the full requirements gathering process. If you are only technical, it should be in cooperation with someone who knows the functional requirements of the company, which will and should be given higher importance.

Point is, the more you take initiative early on, the more you get to shape the process and highlight what is important early on. On the other hand, if you come off as a techy smart-ass, that'll backfire sooner than you can say "sorry". There's very little that can substitute loads and loads of experience with clients here, so if you're not that experienced, better play it humble and try to seize opportunities only where you are sure you can make an impact.

As a spur: Who will support this software when it comes live? If it's you, you have every reason to tackle this as early on as possible. However, if you're going to get them to listen to your technical details, you'll have to leave out the details and come to the gist of it in 2 minutes. That's why they hired you, not to be taught lessons.

Imagine giving those lessons to your grandmother. What use will she make out of it?

I've been there. (0)

Anonymous Coward | about a year ago | (#43635113)

But don't forget that they need to be aware of the things that impact their ability to use it. Getting all 10 meg Hubs and running it on an old white box P3 will destroy their ability to do anything with it at all.

They won't have a clue.

See, knowledge that we take for granted, like Open vs Closed source, has been accumulated over years. We have seen the pros and cons, the abuses, why it's good, etc .... They won't even be interested or willing to take the time to read the WikiPedia entry for it. All they want is something that works and will give a decent ROI.

Try explaining all that and everything else in a 15 - 30 minute presentation - because that's all you're getting, if that.

The GP is spot on. I've been there and I can tell you if you get technical at all, they will tell you to move on. Occasionally, you'll get a geek in Sr. Mgt and they'll ask you if they want more info.

To us, tech is our lives. To them, the tech is just to solve a problem. They have other things to worry about.

Re:None of the above (2)

smash (1351) | about a year ago | (#43635607)

None of that is senior management level decision making. All they need to know is "this program can do this, requires this level of spend to make work". The lower level technical shit should be abstracted away from them, all they need to know is something like "we'll need $50k to upgrade our hardware to run this properly". That's all that is relevant.

Re:None of the above (4, Insightful)

Ravensfire (209905) | about a year ago | (#43634767)

This. Focus on what they need to know for this decision. The part part about proprietary vs open source? ONLY if you're considering a proprietary package and an open source package. If they think you are wasting their time, they will tune you out and you will all be wasting your time.

underlying plumbing (1)

oneiros27 (46144) | about a year ago | (#43634873)

There might be a valid reason to explain the plumbing, and that's if what's being proposed might have problems. Then you'll want to explain just enough to them so they can understand what the issue are, so that they can decide if it's an acceptable problem, or something that needs to be dealt with.

Of course, if they've already decided on the ERM software, and all you're doing is criticizing their choice, this might not be useful.

This is *not* a time for proselytizing about open source software ... that's just going to make you look like a nutter and might ruin your credibility. Establish yourself as an expert first, and sometime down the road you can casually mention those sorts of things.

Re:None of the above (0)

Anonymous Coward | about a year ago | (#43634893)

If they could care less then your advice is the wrong thing to say. (Hint: You misplaced a 'not' in there. The reason is irony, so you wouldn't understand, but you aren't forgiven.)

If one is teaching senior management it is probably a good idea to remind them that people with clue, not managers, should do most of the selecting. But managers need to know they can safely delegate all that.

This then results in about three options (the expensive, the good, the cheap) about which you can explain in detail in what ways they can benefit the company, and any other question they care to throw at you, and if dear sirs would pick one of the three please?

Of course you shouldn't include options you wouldn't want to run and if they ask about them you can explain why. For you did your homework, didn't you?

Re:None of the above (1)

Shavano (2541114) | about a year ago | (#43635363)

If you are going to be training senior management, focus 100% on the ERM software and how they can use it for their business needs. They could likely care less about the underlying plumbing and it would take much more time and effort than they'd be willing to undergo, plus it's not in their interests to do that. That's why they hire smart IT guys, right?

No, they could not. Remember that they COULD NOT care less about the technical details. (Most of them anyway.) They bought the system for a reason. Focus on that reason. It had nothing to do with open source or software architecture. You will not be preaching to the choir on your favorite software topics.

Re:None of the above (0)

Anonymous Coward | about a year ago | (#43635839)

The poster is likely to be living in North America, and as such, never got corrected because people believe this makes sense. You'll hear it daily on TV (as well as "lookit"). English (UK) now write "could of", "would of" etc, in the same illiterate manner.

Re:None of the above (1)

smash (1351) | about a year ago | (#43635603)

100% that. Teaching senior management IT is a complete waste of fucking time. They are senior management because they should be spending their time making business decisions in the best interest of the company. Leave teh IT nerd shit to those who are actually qualified in it. IT is a profession, you can't teach it in a couple of sittings. All you'll achieve is give them something half-assed that they can use to make bad decisions with.

They presumably have specialist IT staff to advise them on decisions of a technical nature. If they don't they should do. Having management make IT decisions is like getting the work experience kid out of filing and asking him to close a joint venture deal. It's fucking retarded, and will not end well.

Re:None of the above (0)

Anonymous Coward | about a year ago | (#43635995)

Correct. For the parts that you do need to describe to them, learn their language. 'The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win' gives you a really good idea.

/snark (0)

o_ferguson (836655) | about a year ago | (#43634727)

Why? If that's your job, you could get a better one. Like, one of their jobs. It's 2013FFS. Anyone in senior management who doesn't want to learn about IT all on their own is just legacy dead wood. Recommend their termination and be done with it.

As Little As Possible (0)

Anonymous Coward | about a year ago | (#43634731)

Give them as little training on IT stuff as possible. There's a reason they don't already know it by now (either they don't want to, they don't care or they can't grasp it).

Make yourself available to anyone in management who may have questions or the desire to learn more, but for the most part train them on the software but not on things that they don't need or want to know.

Re:As Little As Possible (1)

Runaway1956 (1322357) | about a year ago | (#43634915)

Talk as far over their heads as possible. Give them the facts, but don't waste time dumbing it down for them. Leave them as clueless as they started. Make sure the "executive summary" states your goals clearly.

You're going to dazzle the clueless. But, they won't admit to being dazzled, they'll be mimicking your words to sound intelligent. The guys with a clue might ask you a serious question or two, but they'll probably just agree with you, because it's outside their area of expertise. You'll find that they don't mimic you so much, as they try to explain what they know so that idiots can understand it.

When they approve of your planned course of action, just work extra damned hard to ensure that they don't have problems at THEIR end of things.

Re:As Little As Possible (2)

smash (1351) | about a year ago | (#43635643)

The reason they don't know it by now is because it is totally irrelevant to their job. They employ nerds to handle that shit, and all they need is a "yes, we can run this", a "we will need to spend $X to run this" or similar.

All you're doing by trying to explain the technical side of things to them off the bat is offloading YOUR JOB onto their shoulders. The technical stuff is none of their concern. As far as management are concerned, IT stuff should be like magic. They don't need/want to know the details, they have other things to worry about.

If they want to know the technical details, they will ask for more detail, e.g. "Why do we need to spend 50k on hardware?" and even when explaining that, be brief and non-technical. E.g., "our current storage capacity is insufficient" or "our hardware was never specced for this kind of workload and needs upgrading".

If and when more details are required, go into more detail. But likely, more detail will seldom be requested because the details are supposed to be handled by the IT guys.

Tough job ahead (2)

whizbang77045 (1342005) | about a year ago | (#43634733)

What do I think? Lots of luck!

Re:Tough job ahead (1)

pswPhD (1528411) | about a year ago | (#43634847)

What do I think? Lots of luck!

I agree. I think your project is doomed without a lot of luck or divine intervention.

I feel I can speak on behalf of the slashdot community that our thoughts are with you at this difficult time

Re:Tough job ahead (1)

whizbang77045 (1342005) | about a year ago | (#43634911)

It seems to me that this is the typical task of trying to explain technical issues to people without the background and education to understand them. The chances for misunderstanding far outweigh the chances for understanding.

Well (0)

Billly Gates (198444) | about a year ago | (#43634745)

You can start by not buying one that only works with IE 7 and XP after blood, sweat, and tears, getting off IE 6 and XP to Windows 7 only now to reverse a whole years worth of work to downgrade because the CFO read about it in skymail on his flight to Brussels!

Trust (1, Informative)

RenHoek (101570) | about a year ago | (#43634753)

Tell them to trust IT to make the right decision for them.

Just research the best option and present that. Don't give them a choice between the ideal solution and a runner up because it will just make them argue and possibly select the wrong product.

The only thing they should bring into the decision making process are the business requirements. You set the technical requirements and then find the package that covers them both.

Re:Trust (0)

westlake (615356) | about a year ago | (#43634921)

Tell them to trust IT to make the right decision for them.

Just research the best option and present that. Don't give them a choice between the ideal solution and a runner up.

Concealing choices does not build trust.

Re:Trust (0)

Anonymous Coward | about a year ago | (#43635017)

Concealing choices does not build trust.

Management can not be trusted.

Re:Trust (0)

Anonymous Coward | about a year ago | (#43635107)

By your logic, every decision ever made in the company should only be made by the CEO...

after you graduate high school and get a job, and you'll see how it works in the real world. And upper management doesn't have time to consider every minutia and detail. That's why they hire people to do that for them.

Re:Trust (1, Insightful)

smash (1351) | about a year ago | (#43635667)

Exactly. In reality, it is YOUR JOB to insulate the CEO and other upper management types from having to deal with this sort of bullshit. This is why Apple sells a shitload of gear to people like your CEO. They just want stuff to work and don't care about the implementation details. Window colours? Irrelevant. Theme on their phone? Irrelevant. Ringtone? Irrelevant.

Bringing petty technical decision making bullshit to upper management level types is failing at your job. Unless they ask for more detail, abstract it away into dollar figures and man-hours required.

Re:Trust (0)

Anonymous Coward | about a year ago | (#43635229)

Tell them to trust IT to make the right decision for them.

Just research the best option and present that. Don't give them a choice between the ideal solution and a runner up because it will just make them argue and possibly select the wrong product.

The only thing they should bring into the decision making process are the business requirements. You set the technical requirements and then find the package that covers them both.

Except that this is ERM we are talking about. It will have a pervasive impact throughout the operations of the business, including in many areas where the IT staff have no actual knowledge or skill. Would you be happy about moving the accounting database to MongoDB because the CEO talked to a salesman at the golf course and decided that the business's IT needs to be 'web-scale' and 'in the cloud'? Then why should the warehouse manager accept ERM software that can't keep track of inventory in a way that works for that business, because the IT manager who selected the product didn't understand that requirement, or didn't give it sufficient weight?

Re:Trust (1)

smash (1351) | about a year ago | (#43635685)

Whether you (in IT) are "happy" about it or not is irrelevant. The cost to accomplish in terms of $ and hours may or may not be worth the trade off for other benefits that particular package provides to the company. It all comes back to time and money. If the IT side is going to be a prick of a job, work out how many hours, how many dollars worth of hardware and software and consulting (or additional staff required), and give them the figures.

They will either balk at it (in which case you go into details as to how those figures were achieved when requested) or re-evaluate the cost to implement.

Re:Trust (0)

Anonymous Coward | about a year ago | (#43635965)

Whether you (in IT) are "happy" about it or not is irrelevant. The cost to accomplish in terms of $ and hours may or may not be worth the trade off for other benefits that particular package provides to the company. It all comes back to time and money. If the IT side is going to be a prick of a job, work out how many hours, how many dollars worth of hardware and software and consulting (or additional staff required), and give them the figures.

They will either balk at it (in which case you go into details as to how those figures were achieved when requested) or re-evaluate the cost to implement.

Which means that IT are only providing details on their own specialist area to senior management, rather than making the decision on their own which was the original proposal.

Re:Trust (1)

Antique Geekmeister (740220) | about a year ago | (#43635519)

Thank you for espousing this approach. A great deal of my income comes from the cleanup when management wasn't presented with the available options, and IT chose the wrong ones due to concealed biases or unawareness of other requirements. The result is software churn, and large projects that soak up the entire resources of a company but miss a critical requirement that one side, or the other, didn't even know was available.

The reverse, of course, also happens as well. But since management usually does the consultant hiring, and allocates the budget for it, they're the ones who hire my group. Making peace between IT and management is a huge social part of our work.

Re:Trust (1)

Nerdfest (867930) | about a year ago | (#43635977)

Strangely, a large part of my income is from cleaning up when management *was* presented options and picked based on their biases, back-room deals with vendors, and outdated 'knowledge'. Mistakes will be made regardless, but at least let the people with the most applicable knowledge and experience make them.

Don't look at the software yet. (2)

Max Romantschuk (132276) | about a year ago | (#43634769)

Your first priority should be to interview people about their needs. Try to get one-on-one face time, and talk about what kind of challenges your company faces. By going to the end users you'll be better equipped to both help management select a suitable package, and motivat people to use it by being able to say: "Remember that problem we were talking about? You can use this software to solve it now, let me show you how."

Another very important thing is to do regular follow-up on how people are using the software. A common mistake is to provide the tool only to realize months later people aren't using it.

Far too much in IT is techology-centric. Techology should be people-centric. By going users first I can practically guarantee you'll have a greater chance of success.

Don't teach them general IT stuff (2)

Freddybear (1805256) | about a year ago | (#43634783)

Stick to the particulars of the software. What are the technical requirements (hardware, network, etcetera)? What level of support staff (DBA's, data entry, etc). What, if any, changes to work flow? Keep that to a minimum if possible. And how does all that affect the bottom line?

Wrong question. (1)

monzie (729782) | about a year ago | (#43634789)

"How to teach IT to Senior Management" - I think the question is wrong.

You cannot teach anything to people who call themselves "Senior Management" or in a company where such terminology is used.

If people in executive level positions are not genuinely interested in what you do or don't have a technical bent of mind, I think one should look for a change of job..

Seriously guys, don't waste time fighting bureaucracy or reading documents written by 'architects'.
If CXO/'senior' level people walk by your cubicle/desk/hole and seem genuniely interested in what you do , work for the company or quit.

No point increasing your stress levels for people who do not want to understand what their employees do.

What a bullshit job, bad luck. (0, Redundant)

magic maverick (2615475) | about a year ago | (#43634801)

OK, start with the file system, possibly explaining with real-world files.
Next, move onto what each part of the computer does (the CPU is the brain, the RAM is a scratch pad, the long-term storage is like your filing-cabinet, etc.)
Then move onto turning the machine on. Then explain WIMPs, and (if you want) the differences between GUIs and CLIs.

Look at word processing and spreadsheets (be sure to explain styles, and the difference between look and semantics). That leads into HTML (but briefly, so they don't get scared when they see it), and the web and networking more generally.

Explain the Internet, and how it's made up of various things, such as email, the web, IRC (and other chat systems) etc.

Explain the specific concepts related to the software you are going to be using.

Finally, teach the ins and outs of that software.

Most of all, stay clear of focusing on a particular piece of software. Don't teach MS Word, teach word processing. Don't teach MS Windows, teach WIMP and GUI. And only once they grasp the basics, do you teach specifics of software packages. Test them, make them produce a document that looks identical (when printed) in two different word processors. Have them provide a balanced budget for a trip, in two different spreadsheets. Etc.

And sucks to be you, to have gotten the short straw.

Re:What a bullshit job, bad luck. (0)

magic maverick (2615475) | about a year ago | (#43634817)

Oh, and you can explain "open source" and stuff if you want, but leave it for the advanced course. They don't need to know to merely use the damn infernal machines. Similarly, while bits and bytes are essential for computer operations, they aren't really necessary to use. Teach them only in the advanced course (perhaps as part of the "no you can't stop copying, and you're a stupid fucker" subcourse).

While many people make decisions that really require knowledge beyond the basics, without that knowledge, trying to teach it will result in failure if you are too early.

Keep in mind... (4, Insightful)

ExRex (47177) | about a year ago | (#43634803)

...that when most people ask, "How does it work," what they really mean is, "How do I work it?" i.e., they really only want to know which buttons to push to get their desired result. It's like the Automat: you put a nickel in the slot, turn the knob and pull out the sandwich. How the sandwich got there in the first place is of no interest.
Computers are magical objects to most people, inscrutable machines which perform mystical tasks if the propler incantations are performed. And most people seem to like it that way.

Re:Keep in mind... (3, Insightful)

egcagrac0 (1410377) | about a year ago | (#43635317)


An engineering student asking "what's a clutch?" may want to hear about pressure plates, friction surfaces, and throwout bearings.

A driver's ed student asking the same question wants to hear "put your left foot down".

Re:Keep in mind... (0)

Anonymous Coward | about a year ago | (#43635727)

Haha, except in Automerica.

Re:Keep in mind... (0)

Anonymous Coward | about a year ago | (#43635761)

The driver's ed. student wants to hear the answer to a question he didn't ask?

Re:Keep in mind... (1)

DeeEff (2370332) | about a year ago | (#43635811)

This is clearly a driver's ed. student. They're probably some dumb teenager, you can't expect them to expect answers appropriate to the topic or subject matter.
They don't know anything about the world!!!

Same way you teach Accounting, Sales, HR,... to IT (4, Insightful)

obarthelemy (160321) | about a year ago | (#43634807)

you don't.

Fair warning: these people don't want to be taught about IT. They want a powerpoint presentation about why the choices they have made (ie, you have made for them) are the right ones (other hint: "our competition is doing that" is the best argument, by a mile). That's a good place to sneak in a few limitations you anticipate to cause issues too, so you have an "I told you so" fallback.

Re:Same way you teach Accounting, Sales, HR,... to (0)

Anonymous Coward | about a year ago | (#43635499)

Sort of. What they really want is a presentation about why the choices they made are the right ones, and what they DON'T want is any suggestion that they may have made a wrong choice. That applies even if the choice was so bad that it threatens the company's future. Modern MBA type managers suffer from this delusion that you can change reality by wishing, and it has already otherwise been shown that for most people incapable of critical thinking (that is, most people) showing them why they might be wrong in their beliefs using actual facts often makes those incorrect beliefs stronger. When you couple that with the absolutely insane levels of ego and paranoia in your typical executive suite, you have the utter madness that is modern American business.

Re:Same way you teach Accounting, Sales, HR,... to (1)

smash (1351) | about a year ago | (#43635707)

Exactly. Getting technical is pushing your job onto them, and that's what they pay you for. If they wanted to learn about IT and get involved in that side of the decision making process, they could quite easily take the pay cut and be doing your job instead.

The important thing (0)

Anonymous Coward | about a year ago | (#43634845)

Is to frame the whole thing from their perspective, i.e. businessmen competing in a certain market, who need access to timely information and to have data stored in a reliable fashion. They don't want to know too much about the technical details, just enough to give them a warm fuzzy feeling that their money is being well spent. And an elevator spiel on each of the important buzzwords.

Tell them they will be graded. (1)

dicobalt (1536225) | about a year ago | (#43634849)

Then tell them grades will be posted on the bulletin board. Then tell them if they get less than a B they need to take the class over again.

First, get their attention and commitment. (1)

leftover (210560) | about a year ago | (#43634891)

A shock collar might not be sufficient. Seriously, in my considerable experience with this situation the biggest problem is their expecting a quick sound-bite to tell them everything they want. When that fails, as it must, they will blame you.

A second issue is their weak math/logic skills for mentally organizing complex new information. Your one-sentence syllabus is already far too much information for any C-level person to absorb in one sitting.

Rather than trying to be complete and accurate, you should identify a list of simple facts you want them to know. Express each fact in a simple sentence with visceral impact. Emphasize it with a physical prop. Example: "Real-world software is more complex than most people realize." Related prop: Source listing, on paper, of software they can relate to their own work life. (Strap it onto a dedicated $25 hand truck for easy re-use.)

Do not try to paint a big picture, it will just annoy them and they will direct that annoyance at you.

Start by having them watch the entire "IT Crowd" (3, Funny)

mark_reh (2015546) | about a year ago | (#43634947)

series on Netflix, then demonstrate that you know what the letters "IT" stand for.

Don't Prepare a Course (4, Insightful)

OG (15008) | about a year ago | (#43634963)

They care about three thinks: cost, results, and risk. Don't waste time talking proprietary vs open source. They don't care about software ideologies. They need to know what infrastructure upgrades may be required (in both networking and hardware). They need time estimates. Get their requirements first. Then do your homework and put together a proposal. Then go into pitch mode, not instruction mode. Be ready to defend your decisions, but don't spend alot of time upfront explaining your decisions. Focus on what the software is going to accomplish, not on the details of how it works. Focus on asking what they want. Perhaps you can already tell that a major network upgrade is going to be required. Fine. Be ready to speak to that, but have ONE high-level slide ready to describe what they need. If you make it into a seminar, then you've already lost your audience and your project is off to a horribly rough start.

Re:Don't Prepare a Course (0)

Anonymous Coward | about a year ago | (#43635329)

I agree with everything you've said, but open vs. closed source is a worthwhile risk in enterprise-scale ERP. Closed source means you need to actively develop a plan to transition out in case relationships sour. Open source, you can move to being supported by an independent vendor or find a contractor to do the data conversion to a new system.

rofl (0)

Anonymous Coward | about a year ago | (#43634983)

I hope you get paid a ton.

Teaching IT to managment... Your job just got 1000x harder..

Bet your pay didn't go up even 2x.

What do they need to do to make ERM successful (1)

Anonymous Coward | about a year ago | (#43634985)

What you really want out of this is these senior management people will do their best to make this ERM a success. So you can start with what do they feel as success for the ERM, and then ask them to see what must happen to make it a success, and then what they need to do to to to ensure that it is a success. During this discussion, you can tell them the features of the system that will help them to make ERM a success, and what IT can do to help them.

It is important for them to realize that it is their job to make it a success. It is their system, and not IT's.

Thinking back over my career (0)

Anonymous Coward | about a year ago | (#43634993)

I realized that in almost every job I've had, there was one person (OK one guy) who was an absolute genius at this kind of assignment. They were socially dominant and socially aware (i.e. not video game addicts) talkers, who often took it upon themselves to give training to the newbies.

The funny thing about it is that if you transcripted what they said and read it back, it would look terrible. It wasn't because they didn't know anything - they did know something, but were hardly experts on the subject. None of them were star engineers. But somehow these guys had confidence and presence and made people feel like they were getting something of value, even if that was an illusion. If someone asked a question about something they didn't know about, rather than look puzzled or admit they were stumped, they would segue into a topic on more comfortable ground, like a politician.

BTW you might guess that these guys were fast trackers to senior management, but for most of them I've look up in linkedin, it hasn't turned out that way. After they turn 40 or so they have to start scrambling to stay employed, like a lot of us I guess.

Focus on results. (2)

voice of unreason (231784) | about a year ago | (#43634997)

I'm a business guy with an IT background, so I've worn both hats here. The key difference between you and the people you're teaching is that they are almost entirely results oriented. As IT people, we like computers. We want to know everything about them. We like tech oriented solutions to a problem that are fun and cool even if they're not that practical. Execs are different. They want to know things that will make their company run better and improve the bottom line. Understand this, and plan out the course accordingly. Focus on the key stuff they need to know, and explain why it's important they know it. If you can't explain why they need to know it, they probably don't. Also understand with regards to Open Source that they aren't interested in ideology. They want to know what the advantages are for open source, and how to make it work for them. If there are drawbacks, they want to know them too and how to get around them. Also understand that they don't want to know really low level detail. They've got developers to handle that stuff. They don't need to know how to code, just like you don't need to know how to write and analyze a cash flow statement. What they want to know is the information they need to make informed decisions.

Need to Know (1)

Aguazul2 (2591049) | about a year ago | (#43635021)

They don't need to know most of the details. You need to present it as an assortment of rectangles on a diagram with lines between them. Make sure everything that will need funding or time spent on them is represented by a rectangle. You can then do the entire discussion at this level (if you've got it right). If really necessary then you can drill down to the details of what is inside the rectangle, but that shouldn't be necessary if you've presented it right. If their job is to manage, they don't want to know details, they just need to know that everything is covered or planned for. If it looks like you've got everything covered, they will be happy. You may need to learn their way of thinking / talking in order to translate your requirements into a form that they will understand.

You Don't. (1, Interesting)

VortexCortex (1117377) | about a year ago | (#43635027)

I recently took a position ... I will be providing basic IT training to the senior management

You might think that's what you're doing, and you might even make a spectacular job of it, but there's a reason why they're where they are and still don't know anything -- That's what they do. If they knew anything they wouldn't have those jobs. Good luck.

Whatever you do. DO NOT TEST THEM to ensure they know what they've been nodding their heads and agreeing with.... That's why it's you, the new guy, who's tasked with this job. The folks they'd actually listen to are wiser than to risk their job by showing just how dumb the management is. When they come and ask you questions about things that YOU JUST "taught them" about yesterday, just grin and politely show them how. Enjoy your life at the bottom of the totem poll. If you survive the ordeal, maybe you can convince HR to find you an underling you can feed to the wolves one day too.

Set expectations (3, Informative)

michaelmalak (91262) | about a year ago | (#43635037)

The most important thing to do at this stage is to set expectations:

1. What ERM will streamline (including headcount that could possibly be eliminated)

2. The investment required: the customization needed to match the current business process (or even more complex: taking the opportunity to streamline the business process at the same time). The investment is not just $, but also time for requirements gathering, UI mockups, etc.

3. Most importantly, the problems that can be expected: downtime (and whether there is any fallback plan to paper?), and kludges due to failure to capture all requirements (e.g. putting critical information in the "Notes" field).

In short, management needs to know ERM implementation lifecycle, not nuts and bolts.

Re:Set expectations (1)

RobertLTux (260313) | about a year ago | (#43635631)

also include what RISKS using a non opensource ERM solution creates.

If making the package work for that business can be solved with an open account to the local JimmyJohns (on top of what is already being paid to the workers involved) then this could be a Good Thing.

i would put together a Block Diagram of Whose(server is) On First so that they understand that skimping on Tommorow will prevent anybody getting Paid, Today prevents The Company from being Paid and I Don't give a [bleep] just annoys the lawyers.

How To Teach IT To Senior Management? (0)

Anonymous Coward | about a year ago | (#43635051)

With a cluebat.

Grandma has no idea what's under the hood of a car (4, Informative)

walmass (67905) | about a year ago | (#43635067)

but she drives it quite well and she DOES not need to know about how engines and transmissions work. Yes, it would be nice, but it is NOT necessary
You are going to lose your audience if you give them the "basic components and architecture -> networking -> software -> proprietary vs open source".

Without knowing your product, I am betting most people will use it using a web browser.

Here is an outline:

What the ERM will do for the company (I presume they already know this, so no more than a few minutes on this.
To run the ERM, we will need:
new server? (why?)
new computers? (why?)
new network? (why?)
This is how you will use it:

Assuming He Can Read (0)

Anonymous Coward | about a year ago | (#43635071)

This book [barnesandnoble.com] is all you need.

what is in it for them, and what do you need them (0)

Anonymous Coward | about a year ago | (#43635079)

There is good description on Nestle's SAP - Implementation around, it talks about how they approached the project (review and simplify business procedures, 'why do we need 10 different ways to write a PO?), how they picked the project team (that could implement the changes AND keep the business on board), and what is in it for them (Nestle earned a considerable investment back in just a few years). IT stuff yes, but preferably in the form of decision support ('go open source because flexible/cheap/transparent, alternative SAP possible. More established, but usability/cost/integration make it less preferable. Or the other way round, if that is your recommendation)

Idiot management. (1)

johnnys (592333) | about a year ago | (#43635087)

Run away now. Run far! It will save you grief in the long run. Managers who know nothing about IT are never going to learn enough about IT to make a decision: If they had the ability or inclination then they would have already done so and if they think they are then they are incompetent. There's nothing worse than a senior manager who knows just enough to be dangerous. Also known as "does not know what they do not know."

Should they ask a lawyer to teach them enough about the law to make a decision about a legal matter? No, they should understand that Law is a complex and difficult field that they know nothing about and it takes many years to master before they could possibly make an informed decision.

Should they ask a doctor to teach them enough about medicine to make a decision about a surgical procedure? No, they should understand that Medecine is a complex and difficult field that they know nothing about and it takes many years to master before they could possibly make an informed decision.

Should they ask a CPA to teach them enough about high-end accounting to make a decision about a compicated financial situation? No, they should understand that Business Finance is a complex and difficult field that they know nothing about and it takes many years to master before they could possibly make an informed decision.

So why do these "senior managers" think that they can somehow learn enough about IT to make informed decisions about complex IT matters? Do they really have so little regard for the professionalism and depth of knowledge of senior IT practitioners that they really believe they can learn all there is to know in a few short lessons? That is the apogee of hubris!

What you should do is:

1. It's much easier if you put together a list of possible solutions with a cost/benefit analysis of each, then they can make the decision. They get to stick to what they know and aren't required to think outside their comfortable little boxes.

2. Always give them several solutions to choose from. Then make sure that the solution YOU want has the best cost/benefit outcome.

Have Nothing to do with Each Other (0)

Anonymous Coward | about a year ago | (#43635101)

I don't know how many of these types of projects you are going through, but the short answer to what you're asking is the business you are working for is already failing before it starts. IT should not be driving these projects, nor should you be training any stakeholders or managers on what it's about. This is the quickest way to cause any of these projects to fail.

You are quite literally doing this backwards. They need to be involved up front, with a champion from any relevant department. If you're "training them" on what to know, you should expect IT to be blamed in the absolutely normal period of frustration after any large project is rolled out.

For both the sake of the business, and for the sake of your own career, I would highly recommend that you back up, go through the research of how projects like this should go, including looking at successful and failed ones, and attempt to emulate the successful method. You'll discover quite quickly IT being in the position you seem to be in -- even if the IT person is the greatest IT person on Earth -- is one of the immediately precursors to the project failing. The only thing that will make it worse for you is if both IT and Accounting are in that position at once.

Quit (0)

Anonymous Coward | about a year ago | (#43635133)


If they already think of IT as an 'expense' and not anything that adds value to the business you're wasting your time there.

Or you can waste five years of life trying to "teach them," and become frustrated and disgruntled over their bad decisions.

Speak their language (2)

FuzzNugget (2840687) | about a year ago | (#43635169)

As in dollars, quarterly earnings and PowerPoint charts. Product X will cost Y to purchase and take Z amount of time for configuration, training, etc. Here are some charts showing the projections of each of option in pretty colors. Communicate everything in dollar amounts, time and direct visual aids.

Power relationship, Authority, Chain of Command (0)

Anonymous Coward | about a year ago | (#43635185)

"Teaching" implies a teacher-student relationship, where the teacher has the authority. This is not that.

You don't "teach" your boss anything.
You "advise" your boss. But only when they request it. And then they choose to ignore the advice, or not.

If your boss actually gave a shit what you have to say, he'd be talking to you one-on-one in person. He wouldn't be asking you to give him and his coworkers a formal class.

So basically you're fucked. But at least you're getting paid for it, right? Here's what you do about it:

Go through the motions. Present material, answer questions, but don't test anyone. And at the end, give everyone a certificate stating that they have attended the class. Expect no one to learn anything. Hold no on accountable to any kind of standard.

Don't spend more effort on this than it's worth - focus on other, more important, parts of your job.
Run down the clock.

Its all about the screens... (2)

SuperCharlie (1068072) | about a year ago | (#43635193)

We upgraded a dinosaur legacy system for all the functions..yes.. ALL.. at the University I worked for.

Give a brief how great the software is schpeel then teach the boss-appropriate functions/screens (reporting mostly I would assume) and expect to live a life of "whats this?" and "I need a special report".

Teach them the Value & Risk of IT (1)

Xlylith (846092) | about a year ago | (#43635209)

Senior Management won't listen to IT people unless they are told the Value of what you're about to tell, and the Risk of ignoring it. The more you can relate to the moneymaking process, the better. Keep the more technical stuffs brief, and if possible liken them to the business process they understand. Other important thing I learned, never make Senior Management looked stupid, no matter how clueless they are, especially in the company of their peers. Good Luck!

Tell them the truth (1)

minstrelmike (1602771) | about a year ago | (#43635219)

The truth about management is this: Whatever you pay attention to seems important to the rest of the workers
Management decides what the company culture is.
If management decides IT could provide a competitive advantage, then it will.
If management decides IT is a cost center, then it will be.

The actual technology has nothing to do with how a company uses it.
Teach them that.

BAD approach, grasshopper (3, Insightful)

adosch (1397357) | about a year ago | (#43635241)

It sounds to me like you're trying to sell them on how 'well rounded' and 'IT-intelligent' you are versus actually knowing the business you were for that your IT department supports to make the business successful. If you want to get them comfortable, then perhaps you are the one that needs to be educated in 'suit/business talk'. IMHO, all you're asking for is two things that will totally work against you:

1) Loss of interest after about 10 minutes because you're either in the weeds too much and you eventually work you way back to the IT closet you came from

2) That 'one' management component that slightly cared about your teaching tutorial, has an internal epiphany, and now uses their scratch-on-the-surface knowledge to contract all your future ideas, decisions and pitches.

I think it would be your best interest to figure out the cost savings, increased productivity, product improvement, upgrade/growth/implementation strategy, ect. ect. ect. and maybe go back and find out the mission statement you are working for to begin with as well. You seem to only be concerned with getting that new, fancy IT toy at your place of employment and less about how it helps the company that employs you.

Re:BAD approach, grasshopper (2)

DigiShaman (671371) | about a year ago | (#43635583)

This has always been true. But it finally looks like the IT industry has matured to fully understand it's not about the solutions, but the results. IT people need to be more MBA oriented and last technical. And as BYOD devices and cloud based services become more predominate, there will be a need for less and less specialized hardware folks. And if you need them, you outsource the problem like you would a phone vendor.

Keep this in mind (0)

Anonymous Coward | about a year ago | (#43635297)

If the company is small, then you probably have the original owner of the company as a part of senior management. If the company is successful, then you likely have the founder. Founders are great. They are usually willing to learn new things, work hard and listen to what you have to say. If the company is run by professional managers, then you are hooped. All you can show them are a bunch of widgets and gadgets and dashboards. They don't want anything else, don't care about anything else. They aren't interested in growing the business or improving its dynamic with the use of computers and software: they are interested in making their next quarter by whatever means. And if these computers can help them do their job, then they will get computers that help them do their job. With the founder, the focus is company. With pro-managers, its paycheck (and indirectly quarterly returns). Having said all that, if it is a founder then you can introduce the concepts generally, tell them that computers are tools that aid, but cannot lead a company (yet). They can find optimal solutions provided they have all the information required plus the software. It all depends on what you want to do. Open Source is an optimal solution for a green field. Its much less expensive, more reliable, and doesn't lock people in. (Run out the clowns who shout "I need feature X", and I reply "Its in there already!, and if it isn't, since its open source we can add it easily, and you can't. Even things that yours doesn't have, we can easily add, and you can't!")

app (0)

Anonymous Coward | about a year ago | (#43635359)

hmmm...tell me how to use IT to make money

Re:app (0)

Anonymous Coward | about a year ago | (#43635417)

hmmm...tell me how to use IT to make money

and how to contact their grandchild :)

my input (1)

doginthewoods (668559) | about a year ago | (#43635381)

I recently took a position at a small industrial equipment manufacturer. We are looking to buy a new ERM software package and my boss, who is looking forward to buy the thing, knows nothing about computers or software. I will be providing basic IT training to the senior management and I am looking for your input on the scope and content of said training. I am thinking: basic components and architecture -> networking -> software -> proprietary vs open source. What do you think?" This has less to do with tech, than it does with salesmanship. What you are selling here is information - you have to teach them in a manner they will "buy" it. To start, in order to be successful, you should learn who you are "selling" to. Some SM's will want to know everything, some just want to know how much it will cost and how much trouble, other may want to know how it will improve the company. Know your audience is the first step to successful "sales". Save your tech jargon and KISS, and keep your pitch in terms a 7th grader can understand. PP is a good idea, but I think it would be good as a simple back drop, if you use PP, then PP should serve only to reinforce your points. Don't be the guy who puts up a PP slide, then reads off of it - you'll lose them quick that way. My suggestion is to build your presentation and allow for a Q and A, maybe as you go along, or maybe at the end, but I think it is a must that you allow them to ask questions and then answer in front of all of SMs. I suggest a step by step response, so you can make sure they understand it as you go along. One SM may not want to see it the way another does, or may not know how to ask the right questions, biut another does, so this will help you make your case without risking blowback, like "you never told us that in presentation."

Dont bother. (0)

Anonymous Coward | about a year ago | (#43635405)

Senior management? They don't give a shit about you or what you do or how it works. Nor do they want to know. All they want to know is you are making things work and that they aren't bothered.

If you think they actually care about what you do then youre stupid.

They don't need to know that. (1)

Karmashock (2415832) | about a year ago | (#43635421)

Look, how much does the IT department know about accounting, sales, marketing, or a dozen other features of a company? Get real. We specialize.

Management's specialty is management. Yes, they need to understand their business and if senior management doesn't grasp core business services then they're not fit to hold the position. But if the company isn't an IT service business then they don't need to know that stuff. That's what they pay you to know.

What you need is respect and/or trust from management. So that when something happens or you need something to work a certain way they listen to you. Possibly not just blindly do whatever it is you said but treat your recommendation with a high degree of weight.

Zero-Cool (0)

Anonymous Coward | about a year ago | (#43635449)

First things first, ask all the adult learners to give themselves a 1337 handle (N00b4L34rn is a good example), then make them watch Hackers the Movie, and later quiz on the correct ways to disable a Trojan from a Gibson (as shown in the movie)...

All seriousness, I would just walk through the program step-by-step on a whiteboard and give them notes printed out for later study. They can always bring up issue they have with you later on.

Why? (1)

holophrastic (221104) | about a year ago | (#43635511)

Why does anyone, outside of the computer industry, need to know any of that?

The basic components of a computer are the computer, and the keyboard. There may be a box under the desk somewhere, about which no one cares. They have a gas pedal, and a steering wheel. The car goes, and it goes in the direction that I steer. Everything else is optional -- including the gas itself.

Networking is a term that's meant nothing for decades now. The same document can be viewed from multiple computers. That's networking. That's it. No one cares about the speedometer networking with their brakes. No one knows what ABS means.

Software, unless you're creating it, buying it, selling it, or testing it is meaningless. Computers can do things. They can be upgraded to do more things. No one cares about the software in their car.

Proprietary vs open source is industry jargon. There are six types of each, and unless you understand all twelve types, the only thing you can do is get screwed by someone who does. This coffee maker takes coffee. This coffee maker only takes little cups and no one knows what's in the cup. This coffee maker takes these puck-like things. This one has more buttons. This one filters your cheetah-anal-coffee through tampons and the flavour really comes through -- by the way, that exists, seriously.

Just teach them how to read a computer screen in general, if they don't already know how two-dimensional rectangles can overlap -- it's a "three-dimensional-surface", a cool physics paradox. Then teach them that each rectangle is a scope, and how to determine which one they're "in" at any given moment, so they don't always start reading from the top left of the monitor, instead of the window. Then teach them how to explore any random interface, so they feel comfortable browsing drop down menus and lists of links and right-click menus. Then you're done. Let them explore. As long as they don't take out their credit card for anything ever, they're good to go.

You Don't (1)

mordred99 (895063) | about a year ago | (#43635529)

Sr. management have a limited amount of time to devote to this and they want to be trained in the system and will allow them to do their day to day tasks better. Take one of them aside (after asking for a volunteer, or who ever the project sponsor is) and run them through your training, exercises, reports, etc. and validate it is what they want. Based on their feedback, you can deploy that training (with tweaks from feedback) to the rest of management. You don't want to spend your time telling them superfluous information, just the facts as they want to know what it will do, what buttons to click, and what it will do for them. If they want more info, say you can be reached for info about this or any other IT questions.

What? (1)

blue_teeth (83171) | about a year ago | (#43635571)

What on planet Zapata is ERM software package? Having worked on large backend ERP business systems (mostly SAP) for past 15 years, I am hearing ERM for the first time in my life.

Maybe make an AMA? (1)

YoungManKlaus (2773165) | about a year ago | (#43635611)

because everyone hates boring presentations and also people generally already know at least a little pro: 1) you don't have to pick them off from anywhere because they will naturally ask questions starting at their own horizon 2) similarly, you will not by accident kick them into the deep end because you skip stuff that "everybody already knows" 3) probably better participation and rememberability then when doing a lame presentation con: People have to actually prepare, i.e. think for 15 minutes before the meeting about what they might want to ask. Really depends on what is usual in your company, eg. I am sadly used to people showing up for really important meetings pretty much unprepared :P

Say again? (1)

Kjella (173770) | about a year ago | (#43635705)

I've never heard of senior execs that want to learn basic IT, they're not planning to staff the helpdesk. If they want training in anything, it's either

a) Basic use of the ERM package, what it will do for them, where they can find things and such or
b) To better understand the pros and cons of the ERM packages, if the selection hasn't been made yet.

Under no circumstances are they interested in the IT plumbing, so talk to your boss again and figure out what he really meant.

My experience (hardware side to be honest) (1)

servognome (738846) | about a year ago | (#43635717)

Any change is very complex. When creating a design agreement, there are inputs from many different groups (not just engineers). You have to take into account legacy systems which interact with the system. One of the biggest eye-openers, was because the old software we used was great at data acquisition, other groups started to usurp that data for their own business groups. Suddenly any change as much as it makes sense breaks those kludged systems and management started pushing a roll back because the headcount and training no longer made it commercially viable

Take a tip from Ethernet ... (1)

hey! (33014) | about a year ago | (#43635835)

LBT -- Listen Before Talk.

I have always found it best to understand users' problems first before trying to teach them what they need to know. Part of that is to learn their language. I spent a number of years working with environmental scientists, and after a few years it was quite common for scientists to assume I was a biologist who happened to do information technology, because I learned to speak the language of biology fluently. In an earlier job I worked with accountants, and learned their language too, all the way down to the in-jokes accountants tell.

I'll give you two really good reasons why you want.to do it this way, rather than try to teach management to be IT experts. First, success in this approach depends entirely upon you: your patience, your motivation, your thoroughness. It doesn't hinge on the eagerness of management to learn about software architecture. The second reason is that you don't want management to think they've become IT experts and mess around with stuff that's over their head. Understand the asymmetry in your relationship with your management: your boss can stop you from acting like you're an expert in his job, but you can't.stop him from acting like he's an expert in your job.

I'm not saying to keep your management in the dark, or not to teach them what they need to know. But first *understand what they need to know*; they've got their own work to do. What they need to know is what they need from you (or your successor), how to get it, and what is reasonable to expect. If you've got the balls to do it, teach them how to hold you responsible -- that's the most important thing they need to know and it shows you're confident in your competence.

The fact that you're contemplating this means your employer is not in some kind of IT field. That means you, as IT guy, are in a support position, not a "line" position. Your job is to take care of other people's needs, just like the janitor is, only you're much, much better paid and so a higher level of professionalism is expected. I know this, because I've been in that position. Take it from me, if you want to be happy in that position, embrace your role as support for the main show. You wan't be happy otherwise. If you want to run your own business, then start an IT business, but if you're doing IT *in* a business, your job is to help the organization do its thing. Your job viz the management is to get them out of trouble, steer them away from trouble, and provide them with the tools they need to succeed.

If you're smart, one of the most things you'll teach them is how to recognize what an amazingly good job you're doing. But teaching them to do your job? It's a waste of their time and asking for trouble.

ERM for a small company? (0)

Anonymous Coward | about a year ago | (#43635913)

Are you talking risk management? Or did you mean one of ERP or CRM?

management (1)

Frontier Owner (2616587) | about a year ago | (#43635927)

I've gone thru a few managers in the engineering field.

the worst ones are the managers that get too bogged down in the details and don't trust their subject matter experts. The best know to let the people they hired do what they were hired to do and provide an opportunity to expand what they do best.

Managers need to know just enough on a subject to know when they are being bullshitted. Other than that, all a manager is good for is signing vacation requests and approving expenses.

As far as training managers, put together a presentation of what you're doing, why your doing it, two or three options for other ways to do it. the benefits to each option, and have a meeting on it. Smaller companies seem to be a bit tighter on money for somethings, other times not so bad. as long as there is a benefit. Everyone runs an ERP of some sorts whether its SAP, or Excel. They have to have a way of planning and tracking what is being done.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account