The longer technical communicators stay with an organization or field, the more they become “subject matter experts,” if only through repeated contact and growing familiarity with the subject. That’s part of it. Another question one might ask, though, is what do I mean by engineering? Often the image one conjures up is someone sitting in front of a computer, developing CAD (computer-aided design) models, performing stress calculations, or doing hands-on work “bending metal.” Those are or can be aspects of engineering, but they are not the only ones. For instance, I wouldn’t trust me to develop a CAD model or handle machinery. I used to cut myself on a regular basis just working with box cutters as a stock clerk. I’ve flooded bathrooms and blacked out rooms. No, I am not the one you want touching the machinery. Fortunately, there are other aspects to engineering. One type of engineering in particular is a good fit for liberal arts majors–at least as a way to broaden one’s career choices–and that’s systems engineering.

Systems engineering, as I’m learning on the job, is all about understanding how complex machinery or software or processes fit together. And when you look at engineering through this perspective, it makes perfect sense for someone from the liberal arts to get into it. For starters, technical writers often get tasked to write content about multiple aspects of an engineering business, if only because a lot of engineers hate writing. So one week you might end up working on the production end of things, the next you might end up in software design, the next you could be supporting a program manager with a technical paper. Writing is often one of those underrated transferable skills that causes one to bounce around a company (or industry) a bit, learning useful content as one goes.

Tech writers–especially proposal writers–often have to tell stories to get their products sold. That means explaining how things fit together, what their meaning is, and communicating the meaning to uninvolved audiences. All of those skills can lead the writer unexpectedly into the role of an engineer or, barring that, a “subject matter expert,” a title I actually held prior to my role at Zero Point Frontiers.

Here’s another ugly little secret about systems engineers: a lot of their work involves simply making sure that Group A is sharing information with Groups B, C, and others. “Hey, they just changed the power in the space station from 28 volts to 120 volts. You might want to make sure all the avionics are compatible with that.” Or there’s the one that someone missed: “You guys are measuring descent speed in meters per second, right?” Incorrect assumptions can be corrected very easily just by asking what some might call an obvious or “stupid” question. If someone asks the stupid question and it saves $125 million, it’s not a stupid question.

There are other things engineers do that do not require mathematical skills but simple language, such as describing organizational, production, testing, operations, or risk management processes. And–here’s an advantage, English majors–the more clearly a process is described, the more likely it is someone else can repeat and use it later.

I won’t kid you: there are things in the engineering business might forever elude me and for which I must trust my properly schooled technical peers to understand, do, or explain for me. But my balderdash is getting better, which is to say: I actually speak Engineerish pretty well and don’t have to stop someone a dozen time to explain something while they explain it. Now it’s more like half a dozen. Or less. The trick is to maintain my ability to communicate clearly–not to “go native” and write like an engineer too much. I have products and services to market, after all. I am learning enough to consider supplementing my sporadic education with some sort of formal training in the systems engineering discipline, but my math could still use a little work. And my knowledge of tools. And many, many other things. But if you work as a technical communicator in a small-business engineering firm, the odds are good that eventually you will find yourself writing content that usually would be written by an engineer. It’s not a bad thing, just a sign that you’re learning to speak the language.

Student Feedback

Since I am not returning to teaching in a university setting (explanation later), I feel I can respond to these anonymous comments with a certain amount of freedom.

“Excellent background to be teaching this course. Offers real world constructive feedback.”

Not much to say here besides, “Thank you.” So: thank you!

“Instructor is obviously intelligent, if even equally spacy at times. Would have likely benefitted from creating own syllabus rather than modifying pre-existing EH 300 syllabus. Highly informative w/ constructive feedback. Will likely only improve w/ additional semesters instructing.”

Guilty as charged. I used someone else’s syllabus for this class, partly because I was required to for content’s sake, but also because I’d never done this before. My moments of spaciness came when one of the following situations occurred:

• My due dates conflicted. To be fair to myself (and my students), if there was a conflict, I gave them the later date.
• The inherited instructions on the syllabus were unclear. This usually resulted in a five-minute interrogation session by my students, who wanted to know “What do you mean by X?”
• I just flat-out gave the wrong lecture. This only happened once. It didn’t do the students any harm, though I was embarrassed when it was pointed out to me, as we were to go over an assignment in class and I ended up covering something else entirely. My apologies. I was not nearly as prepared as I could or should have been for every class. Personally, I give my teaching efforts a C+ for the semester.

“Some of the in-class questions were too vague to find a ‘correct’ response.”

I’m flipping a coin on whether this was a bad thing or not. There were times when I would ask a question and hear the equivalent of crickets from the class. In fact, on a couple of occasions, I actually played a cricket sound effect on my iPhone in class. After the second or third time I did this, one student asked, “Are those the ‘uncomfortable silence’ crickets?” I responded, “That’s exactly what those are, thank you for noticing.” Later in the semester I played the “Final Jeopardy” music from the game show. They can’t fault me for trying to make things interesting.

But returning to the topic of vague questions and “correct” responses, I guess I’ll say this: Most of my work consists of vague directives or uncertain assignments. It’s an environment in which I thrive. Most of my “cricket” moments dealt with real-world situations, where I’d ask the class, “Given X situation, what do you think might be of most interest to the customer when it comes to content?” As the semester wore on, I started saying, “Look, there’s no wrong answer here. Just take a guess.” More crickets. But really, the workplace–for which I was trying to prepare my students to write–is often amorphous and vague. If you don’t know the answer to a question, you have a couple options: 1) Ask. 2) Make up your own answer. I’d have settled for either.

*

Why I’m Not Teaching Anymore

The hardest part of the class for me came about halfway through the semester, and I have only myself to blame for it. For one assignment I asked the students to write a business letter to the department chair offering suggestions for improving the content (not the presentation) of the Business Writing 300 class. “You can gripe about my personality all you want in the student evaluations at the end of the semester.” The letters were decent–nobody in my class got lower than a C–but some students couldn’t resist venturing beyond the content-only mandate and making comments about how I conducted my class. The bottom line was that nearly everyone was dissatisfied with how I graded things. So I took the time to explain my grading scale, which was structured as follows:

• 50% Content
• 35% Mechanics (Spelling, Punctuation, Grammar)
• 15% Aesthetics (Formatting)

My logic here was that this is how I’m “graded” on the job: 1) Is the content correct/does it answer the mail? 2) Is it relatively free from egregious errors? 3) Is it neat/pretty on the page? Usually I have the luxury of handing off my stuff to a graphic designer, so I didn’t gripe much about aesthetics. However, I did get some gripes about my multiple markdowns for formatting consistency or instruction-following issues.

The feedback that hurt the most was, “None of us here wants to be a professional writer.” Fair enough. But the implication of the comment was, “…so go easy on us.” Like hell! My response to this comment was a bit frustrated. I said, “Look, last week I gave you guys a 14-point list of things I asked you not to do on your papers. If you don’t do those things, you won’t get marked down for them!” Mirabile dictu! The next week they read the list, didn’t do the things I asked them not to do, and everyone’s grade shot up.

I really can’t complain about the quality or intelligence of my students. I did have a couple students who just didn’t do the homework on occasion. They didn’t even do me the courtesy of making up a clever or dramatic excuse to win my sympathy–not even “The dog ate my homework!”

One student got upset with me for getting solid and very respectable “B.” They wanted extra credit. I explained that there was plenty of time left in the semester to bring up that grade. The one day I did offer extra credit, I offered it to everyone. It was the review for the final exam, and suddenly the crickets were drowned out in a raucous chorus of class participation! Education for its own sake? Not much of a motivator. Education with the possibility of reward? And chocolate in the classroom? Activity! Engagement! And much to my happy surprise, the answers I heard in the session–I’d set it up more or less like a game show–were the right ones. Well, that was an eye-opening class, and actually pretty fun, but by the time I learned that lesson, I’d already made my decision not to return to teaching.

Lastly, and this is not a reflection on the students at all, but on me. As I’ve gotten older, I’ve gotten more introverted. Now it is entirely possible to be in a public speaking, teaching, or other profession and be an introvert, but you’ve got to have a passion for the work. Part of the problem is that I lack that passion. There are other things I can and do enjoy doing with my allegedly copious free time. Part of the problem were those damned crickets.

Lessons Learned

So if you’re gung-ho to teach at the university level and would like some advice, here’s what I can offer:

• Don’t make the entire class (or, God help you, the semester) a long lecture. It was painfully obvious to me that just because I enjoyed listening to a learned and witty older person, that is not the preferred learning style for many or for Generation Y.
• Find ways to get the students engaged in some sort of participatory, group activity where they can work together.
• Set expectations: yes, there will be X activity, but they have to absorb the content before they can start applying it, yes?
• Make the activities semi-relevant or semi-realistic.
• If you can find engaging, group-related ways for students to absorb the content, go for it. I wish I’d been more creative on that score, but sometimes the only way to get the content out there is to read it, listen, and apply it. You try to make MLA citation standards exciting!
• If you solicit feedback, expect that you’ll hear things you don’t like. I’ve had some excellent professors over the course of my education, but that doesn’t mean everyone in my class liked them. They were excellent professors for me because they taught in a manner that appealed to me.
• Don’t teach unless you’re serious about it, committed to it, and love doing it. Most likely you don’t need to be told this or you wouldn’t have taken the job. However, I went into teaching as an experiment. I didn’t know if I’d like it, but it was on my “bucket list” of things to try (not everyone wants to run a marathon). Now I know. I’m glad I did it, and I appreciate the indulgence of UAHuntsville and my students for putting up with my off-kilter sense of humor last fall, but from here on, I’ll stay here in the blogosphere. I’m a writer, I’m passionate about writing, and that’s why I do what I do for a living.

When Working with SMEs Goes Badly
I began my talk with a couple of Subject Matter Expert (SME) horror stories from the tech writing trenches. If you’ve done the job for any amount of time, you no doubt have your own. These are mine.

Example #1: Battle of the Egos
So when I worked in the Disney IT department, I needed a programmer to give me some information for a software development document. I kept asking (name changed to protect the guilty), “Hey, Mike! Where’s that info I need?” After a sufficient number of inquiries of this nature, Mike got irritated with me and snapped, “Why are you pushing so hard on this? No one’s going to read what you write, anyway.” To which I replied, equally impolitely, “Why are you working so hard on that code? No one’s ever going to use it.”
Okay, not my most diplomatic moment, but he did get me the information.

Example #2: The Genius

A few years ago, I was assigned to help write an internal proposal within NASA. The SME was a bit put out that he was sent a writer at all. “Look, I’ve got a Ph.D. in astrophysics, and I’ve taken a seven-day course in proposal writing. I know everything there is to know about this business.” Or words to that effect. I bit my tongue on this occasion, but I found it amusing when a proposal reviewer complained about the language in a section the SME had written and wouldn’t let me touch. “This is dry and a bit condescending. Did your technical writer read this?” For what it’s worth, that proposal did win.

Regardless of the horror stories, the bottom-line lesson here is that these conflicts arose out of a lack of mutual respect. It’s important to respect the value that your SME brings to the table, but it also helps if that respect goes both ways. Sometimes that takes a while.

How Should We Work with SMEs?

Americans tend to be very informal, and it’s tempting for us to just walk into someone’s office or accost them in the hallway and ask them something. However, if you work in large, formal, bureaucratic organizations, it is good to remember a little etiquette and protocol. Protocol means you follow the official chain of command to get to Subject Matter Expert X, via formal email/Outlook invitation or via appointment made through their assistant. Etiquette means you approach such matters politely.

What this means in practical terms is that you set a formal meeting with an agenda (topic/context/questions stated up front) so the SME knows the reason for the discussion. You need to show up on time for the meeting. You need to stick to your agenda and end on time–basic rules of the road, just as Mom always taught. Their time is as valuable as yours–probably more, depending on what they make per hour. In any case, this protocol-based approach will not guarantee that the SME won’t get into the weeds on their own (“Back in ’67, when we were working with von Braun…”). The side stories are often a bonus in my work because I find the history of the space business fascinating, but there are times when you might need to interrupt (politely, of course) and say, “You know what? This is an interesting story, and I’d like to hear the whole thing sometime. But right now, I really need to now more about X.”

At the conclusion of the interview, ask the SME to review the content (proposal, press release, white paper, etc.) that you wrote based on the interview. This is a good time to set some expectations regarding the easiest way to give and receive feedback–phone call? Track Changes in Word?–as well as when you need the SME’s inputs. And, as always, thank them for their time.

How Should We Communicate with SMEs?

Technology now offers us many different ways to communicate with each other, some with differing levels of engagement and effectiveness. Some people prefer Post-It Notes. Some like text messaging, which to me is the worst method for getting things done, but suffices when you’re in a hurry. Email is a little better because people are more likely to type better and more formally in front of a grownup-size keyboard than typing quickly on those little-kid keys on their smart phone. The next method of communicating is that old standby, speaking on the telephone–you know: what we used to use our phones for before we started playing Angry Birds with them. The most effective method for human beings is still in person, face to face. Usually. There are some people who don’t like a lot of people around and are more comfortable conversing by email. I usually look at this as an opportunity to apply the Golden Rule to communications: communicate with your SME as they would prefer to communicate. You should be a little more obliging to their style of doing things since they’re helping you.

What Questions Should We Ask?

Before we start asking a SME questions out of the blue, it’s worth considering when we shouldn’t bother them. I needed to learn this the hard way when a manager at Disney got frustrated with my constant inquiries and asked me, “Bart did you try looking it up first?!” Having learned that lesson the hard way, my sanity check now is to ask myself, “Can I Google this or look it up in an internal document somewhere?” If the answer is yes, don’t bother the SME. This is a matter of doing your homework to some extent: learning the nomenclature, the flow of technology in your area of work, and the ever-present (at least in the space business) list of acronyms. It took me a good six months to fully absorb the acronyms used at NASA. But the effort is worth it because learning the basics of your SME’s language helps you in several ways:

1. It prevents you from asking stupid questions (“What’s an engine?”).
2. It enables you to understand the answers the SME is giving you.
3. It allows you to get past all the little questions, and get to the more important and interesting questions your SME can answer best.
4. I thought about this one just now: Your SME is more likely to take you seriously because you’ve taken the time to learn his/her business and to get things right.

So what are those more interesting questions?

• The how or why behind particular technical decisions.
• Localized knowledge: how do they do or think about things at Marshall Space Flight Center differently from how they do them Kennedy Space Center?
• Networking/referrals to other sources: “Hey, Phil! Who worked on the aerospike engine for the X-33?”
• Sanity checks/clarifications of content you’ve written based on their work/interview.

Concluding Deep Thoughts

I love my job. Technical writing is a constant opportunity to learn things you never knew from some very interesting people who are a lot smarter than you. They aren’t always as nice as they could be–and actually most of them are happy to share their knowledge with you–but if you can stay humble enough to admit that you don’t know everything, working with SMEs is pretty easy. They add value by providing depth and context to what you write. You add value by translating what they share into the clearest, most effective prose you can so that your work can go forward. And if you can get past some occasional conflicts of personality, technical writing really is the most interesting job in the world.

Summary

My current employer’s primary method of communicating is to call me up or drag me into a room with a white board and do a brain dump for an hour. I then go back to my desk, translate what I’ve heard, and email the document to him for a sanity check. It’s a good system for him, and he appreciates my ability to translate Jasonish into English. Jason also doesn’t like me to use any more than five major points (which reminds me: he mentioned in passing yesterday that he wants me to write a white paper on the “rule of five” when I get a chance). In that spirit, allow me to close with these final five reminders when dealing with SMEs:

• Give and expect respect.
• Establish and follow protocol and etiquette.
• Communicate with them as they would like to communicate.
• Do your homework first so you can ask better questions.
• Listen to your SMEs – write clearly and correctly with the best words possible so that you’re both adding your best value.

Since I started at ZPFC, I’ve found myself covering everything from business correspondence to proposals to white papers to organizing actual engineering deliverables for our customers. I didn’t realize how unusual my job had become until a couple days ago, when I found myself taking an insane amount of notes while the CEO gave me verbal and mathematical lessons on the rocket equation and I was actually getting it. I needed all the theory, math, and background so I could work on the next project. The overlap between engineering and technical writing has become a bit blurry for me. As the boss says, “You’re really a systems engineer at heart, you just have a math deficiency.” Well, maybe.  

Another thing that’s quite different in the world of small business is business development. When you’re small, it’s everyone’s responsibility to look for business. Mind you, I have a direct role because I’m doing proposal writing, but the ZPFC team is aware of the importance of keeping money flowing in the door. There is no large Marketing Department apparatus responsible for bringing in money. You can’t say “That’s not my job.” There is no room for stovepiping.

One thing I’ve discovered is that my previous experience doing specific (one-task-only) jobs in large or medium-size businesses now serves me well in a small business because I understand how those jobs fit into a larger whole. Being part of larger teams (10-20) for things like proposal writing makes it easier to keep proposals with half a dozen contributors on track. The same tasks need to get done, there are just fewer people available to do them. Who knows? Eventually the next personal “frontier” might be forming my own business. 

As I’ve gotten older, I’ve sought out smaller companies for employment. I won’t kid you: the workload gets larger in smaller companies because I’m responsible for more things, but the sheer variety of work allows me to expand my capabilities much more than if I were still a line employee in a large organization. Mind you, that line experience has been critical to learning specific, defined skills, but the freedom to do more things is more available in smaller organizations. Of course if you’re the sort of person who can dive right into a small business, good for you! Just be prepared for a lot of work because there won’t be a lot of people around to help!

Generating Requirements

Ever heard of requirements decomposition? The idea is this: you start out by establishing the top-level requirements for a product. Say you want to build a fighter jet. Great! What are the top-level (“Level One”) requirements for something like that? Well, they might be something like these (completely making these up, by the way):

• Fly at Mach 2 for up to 1,000 miles
• Have a flight radius of 500 miles
• Be able to carry up to 2,500 pounds of bombs
• Be able to land on an aircraft carrier in all types of weather
• Be able to detect and engage intruder aircraft at a range of up to 250 miles
• Et cetera

So what would Level Two requirements look like, and how would those requirements tie back to Level One? As I understand it, the “Level Twos” would be broken out by the aircraft’s subsystems: structures, powerplant/engine, weapons, radar, landing gear, etc., and technical requirements would then be assigned to those subsystems, with the engines having one set related to performance, durability, etc., the weapons systems having range requirements, etc. Take this craziness down another couple levels and the problem for the English major becomes obvious: what am I supposed to put here? I don’t know how to build jet fighters, I’m just the marketing guy who can explain why the fighter’s cool.

So anyhow, thanks to the help of several engineering peers working through the process over the course of a couple late nights, the requirements were put back in shape. But this did require me to have a chat with the program manager about thinking too highly of my ability to “speak geek.” Maybe I can learn more in the future, but under a deadline is probably not the best time.

Designing an iPhone App

This project was a little more fun, since I have some daily familiarity with my iPhone and what it can do. And apparently there are now apps to help you design apps such as App Cooker, which was the assigned tool of the day. Well, let’s start with the basics: App Cooker doesn’t have a user guide or a help function, both of which would have gone a long way toward keeping me from cursing at the bloody thing for 15 minutes before I decided to write a complaint note. That produced a result: the owner-developer, no less, emailed me and offered to talk me through the app on Skype so I could actually use it. He was a nice young man (sounded younger than me, anyhow) from Nice, France and his English was a heck of a lot better than my French.

The real trick for me was using a finger/touch-based interface. The late Steve Jobs might have felt he knew better than consumer “what we wanted” when it came to user interfaces, but he’s dead wrong with some of us. What’s my biggest gripe with iPad and iPhone touch interfaces?

There’s no way around this, folks: I’m a klutz. Fair to poor fine (and gross) motor skills, iffy eye-hand coordination, a long history of failing physical education classes, cutting and pasting, furniture assembly, plumbing repair…okay, you get the idea. So when Mr. Smooth is introduced to a computer interface that requires careful placement and movement of the fingers around small lines or buttons, hijinks are likely to ensue, along with a steady profusion of less-than-cordial language.

The fun part for me on this app thing has been brainstorming the organization and functionality of the interface. I know how I want it to work, but I appear to lack a lot of the patience or basic abilities to make those ideas a reality. We won’t even discuss my two- or three-course “adventure” in C++ programming; I’ll save that sad story for another day.

The point I’m trying to convey after a rather challenging week is that I am bumping up against the limits of my abilities, real or assumed. That’s to the good, I suppose. The problem is that it’s always frustrating and humbling to not be able to do something easily right out of the box. I remind myself that I’d rather be challenged than bored, but “challenge” can equate to “frustration” until competence arrives.

Keeps the brain fresh, anyway. Peace and happy thoughts, y’all.

Did I learn anything from the two-day experience? Yes.

Conference Content

On the technical side of things, we have a long, long way to go before we’re able to approach anything like the Starship Enterprise, even one that went slower than the speed of light. We haven’t even gotten very far into our own solar system yet, so we’ve got to learn a few things first. Second, a lot of the technologies that would enable humanity to travel to other stars is incredibly powerful–so powerful that a lot of them would qualify as weapons of mass destruction if put in the wrong hands. Which ones are the right hands? Your guess is as good as mine, but it might not hurt to start building Starfleet Academy now to start instilling a little logic and discipline into the human race.

Lessons for the Technical Communicator

From a professional perspective, a high-level conference like this is an excellent opportunity to observe technical communications in action before a live audience. For instance, were these folks talking about science or science fiction in their presentations? I would make the case that (for the most part) they were talking about science and technology rather than science fiction, even if the science or technology hasn’t been discovered yet. Regardless of what you want to call it, the content was still technical in nature and required a certain acquaintance with (or interest in) the subject matter to be fully appreciated. And if the ugly truth be told, I didn’t get all of it myself–liked most of it, but that doesn’t mean I understood it.

For instance, I am utterly lost when people start speaking in or displaying equations. As my boss puts it, “You’re actually a good systems engineer, you just have a math deficiency.” Using that same logic, some of the engineers in my company would make good writers if they didn’t have grammatical or stylistic deficiencies. No, when it comes to advanced mathematics, calculus, and statistics, I am nearly helpless, hopeless, and bored, and I’m happy to leave that stuff to the professionals.

That doesn’t mean I can get away from equations forever. The “good” news about the mathematically challenged tech writer is that equations are human expressions, not entirely esoteric, alien objects. They are human constructions meant to convey a particular real-world process or value in terms understandable to other humans. They are, in fact, sentences with subjects, verbs, objects, and outcomes, and if you leave something out of them or write them incorrectly, just as with the written or spoken word, the result is often gibberish. However, if you’re really lucky, you can get a subject matter expert to explain what an equation is doing or describing. You still might not be able to do the math (“Do not attempt this at home, we are professionals”), but you can at least explain its function in non-mathematical terms. Zero Point Frontiers has at least one engineer–a computer programming genius, for the most part–who has the patience and vocabulary to translate mathematical operators into practical expressions for the layman. And thank goodness, because I’m not exactly wired for eigenvectors and the like.

Unfortunately, sometimes a conference speaker does not always take the time to explain the math to the English majors in the room. In such situations, I’m forced to write notes about the words around the equations in the hopes of getting a clue. It can be done, but I end up with a two-Advil headache at the end of the day.

This is also a lesson for science communicators, even mathematicians: if you are speaking about complex technical subjects to lay audiences or audiences where you are uncertain of their familiarity with your subject matter, it is best to keep the number of equations in your presentation to a minimum unless you’re willing to take the time to explain them. Okay, shame on us for not knowing this stuff, but really: not everyone has an abiding interest in or passion for those complex squiggles that look like hieroglyphics. Of course, I can send an engineer running for cover by discussing Shakespeare, sentence proofreading, or worse, diagramming, but I try not to do so. 

As usual, it comes down to your audience and their interests and needs. You could discuss the various mathematics of your theory in all their elaborate detail, or you could show a couple equations and then focus your attention on what those equations mean to your audience. The ones who are really into the math will ask you more in the hallway afterward. I’ve gone on and on about this, and perhaps I’m being ungracious. Only two of the multi-dozen speakers over the two days used equations extensively, and one of them was a very kind Italian gentlemen who was speaking in a second language (or third, if you include the eigenvectors). The other was American and probably should have known better. If I understood the Signore Maccone, he was trying to use mathematical expressions to explain what types of creatures we are to alien races (he works with SETI). The other gentleman might have been trying to explain how to use mathematical expressions as a way of improving our ability to receive signals from alien races. The math and the technology just soared over my head at about warp 9.

Another challenge for the non-scientific audience is to understand the implications of a particular result. If you are unfamiliar with a subject, then having someone tell you A+B+C+D doesn’t necessarily mean you’re going to know what E will be–or why it matters. While it might sound corny or condescending, it is not giving things away or spoiling anyone’s surprise to explain to them that “If you get E, the world’s going to be destroyed,” or something equally direct.

So if you find yourself attending a high-level, tech-heavy conference, dare to be the one who asks, “What does your conclusion mean in layman’s terms?” You might not be the only one who wants/needs to know, and that sort of question puts the responsibility for communicating back on the person who wants to share something important. It might be important, but if it’s not communicated effectively, how will we ever know?

The FIRST competition has a whole set of referees who make sure the students’ robots–which are paired up in random two-robot “alliances” during each match–follow the rules. Prior to the robotic chaos of the matches, the teams have to give presentations to a panel of 2-3 adults explaining their machines, how they were built, and what they’ve done to demonstrate teamwork and FIRST’s watchword, “gracious professionalism” toward other teams. The judges (this is where I come in) evaluate their performance and ask questions along the way.

The panel I was on talked to three of the nine(!) teams from the Mississippi-Alabama-Georgia region and then spent the rest of the day watching the matches. We were fortunate to have talked to the Robot Programming Guild (a riff on “RPG,” which also can stand for “Role Playing Games–these kids were geeky and proud of it–one kid wore a chain mail helm he’d made himself). Their machine had a sturdy-looking scissor lift with a double hopper at the top so it could pick up two rings at one time. The most useful aspect of their machine was its set of offset, multi-roller wheels that allowed the robot to move forward, backward, and sideways directly. They found the wheels online, but couldn’t afford to buy them, so they downloaded a design and made the wheels themselves.

What I liked about this group was their general attitude. It was a group of five boys ranging from a high school freshman to a freshman in college, and they were all enthusiastic about talking about their machine with the confident, proprietary air of experts because they had built the thing themselves. Working with engineers on a daily basis, I recognized that enthusiasm easily. They would be working on hardware in the adult world soon enough. As it turned out, Team RPG not only impressed with their presentation but also on the playing field. Their rugged, highly mobile machine (I don’t think it had a name) was able to get around the field easily and survive a lot of collisions with other robots without much harm until just before the final round when a wire came loose. All hands were put on deck, with the adults talking with the students about where the problem was and how to fix it quickly, and the repairs were done. Team RPG went on to win the competition with the most overall points and the FTC Inspire Award for overall performance and teamwork.

It’s fun to watch these kids (sorry, I’m 43 years old with a grey beard–I’m using the word). I’m guessing they’re not typical of kids their age, but there were enough of them to give me something akin to hope for the future. My employer, Zero Point Frontiers, is very much about helping bring an advanced technological future into being and kids like these will be needed. Lots of them. The trick seems to be to get them working on real-world projects as soon as possible and getting them to think through problems. The teamwork and “gracious professionalism” aspects of the FIRST competition are likewise good training for students who hope to work in the adult world at some point. They are required to help other teams prior to the competition, encourage one another during the competition (while still working to win, of course), and work well with each other as a member of an “alliance” because this match’s competitor could be the next match’s partner. I don’t recall this sort of thing growing up. There were science fairs, but they were very static and not necessarily practical in their focus or outcome. All I know is that I was lazy at that age and not particularly interested in science as a career, and the system didn’t seem set up for anything resembling teamwork.

So the good news is, we’re starting to grow a new generation of engineers out there. If cars have become too complex to work on, robots are there to give students something they can bend and shape with their own hands. And along the way, they might learn how to work better in the professional world. All to the good, because I want the future to be cool, and that means having bright people around who can do the cool things. I’m just the writing guy.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 6,000 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 10 years to get that many views.

Click here to see the complete report.

So I’m a little shy of four months into my sojourn with Zero Point Frontiers. There’s no getting around it: I’m having a great time. We’ve been quite busy doing work across the space field, from NASA to Virgin Galactic to Department of Defense to (our latest partnership) Golden Spike. And when we’re not looking at that, the CEO has me researching anything from energy to nanotechnology. It’s fascinating work, to be certain.

The challenge I face is that I’m a science fiction reader. Why would that be a problem? If anything, SF has given me an advantage when it comes to understanding and explaining the various projects I research. Here’s the problem: since Mary Shelley first wrote Frankenstein in 1818, SF has had a strong current of technological pessimism. The subtitle of Frankenstein, for those who haven’t read it, is The Modern Prometheus. In Greek mythology, Prometheus was a Titan who was punished for giving humans the use of fire by being chained to a rock and having an eagle fly up each day and feed on his liver. The liver would then grow back the next day. The lesson, of course, is that the gods sought to punish Prometheus for enabling humanity to advance their tools.

The exemplar of modern technological SF pessimism is probably the late Michael Crichton, who wrote books such as The Andromeda Strain, The Terminal Man, Airframe, and most famously Jurassic Park. But Crichton was hardly alone. Pessimism in SF takes multiple forms:

• Unintended consequences: What sorts of problems are likely to arise from a specific technological advance if it is used in ways unintended by its inventors?
• The problem of evil: What sorts of problems are likely to occur if a bad person gets hold of a benevolent technology? (See Star Trek II.)
• General stupidity: What sorts of problems are likely to occur if a new technology is handled badly (see nearly anything written by author Frederik Pohl)?
• Accidents: What sorts of problems are likely to occur if a wondrous new technology breaks down?
• Reductio ad absurdum: What happens when a technological advance or social trend is taken to a ridiculous extreme?

All of these problems happen today, resulting in anything from jokes to entries on America’s Funniest Home Videos to horrific headlines. Many, but not all, of our problems with today’s technologies were predicted by SF writers 30 to 70 years ago. Some things the old “Grand Masters” called, some you could argue that they prevented, and some things they missed entirely. They weren’t trying to predict the future as prophets–they were trying to make a buck by writing engaging, believable, scientifically informed stories. And quite frankly, if they didn’t include some sort of “dark side,” they wouldn’t have anything for their heroes to overcome and the stories wouldn’t have sold.

Star Trek covers both sides of the technology coin. The starship Enterprise visited worlds on a weekly basis that faced one of the above problems and then tried to find humanity-improving solutions.

Which brings me back to my day job. Space, energy, nanotechnology, biotechnology, and robotics are all technological arenas that will affect our lives on an ever-increasing basis in the future. So if you’re working on these things, do you worry more about what the bad guys are going to do with them, or do you just expect that the technobabble solutions to those challenges will be found? It helps to be an optimist. Read enough history or SF, however, and optimism does not come easy–it’s a trained response. You start seeing problems before the design has even come out of its first iteration.

My pals D2 and eCurt suggested that I try a different approach to my work: rather than focus on the potential problems first, go with the brainstorming for a bit. Make a positive contribution. Once things move into a more detailed phase, then worry about the downsides, and make sure the engineers are taking them into account. Sounds like a plan.

And I have to remember my favorite quotation from Star Trek II, by James T. Kirk, of course: “I don’t believe in a no-win scenario.” As long as we keep that attitude alive, our technological future will remain a bright and wide-open frontier.