Computer Systems Engineering
When asked what I do, my general response is that I am a Computer Systems Engineer. Unless I'm speaking to a fellow IT infrastructure type, this inevitably leads to blank stares or "Oh, I see" type responses. The conversation often goes back and forth a little bit before ending with a comment something like "so you work with computers". I have always found describing what I do a bit uncomfortable. Lately, I've been trying to connect with more people from my community. In the process of doing that I've had several of these conversations, and I've decided to try to solidify it.
Searching the web for the term Systems Engineer I found a few different definitions.
- INCOSE description of Systems Engineer
- I find this definition about as uncomfortable as my recent conversations. It's full of jargon. It describes a concept more that a real world role.
- http://www.calmis.ca.gov/file/occguide/ENGCOMP.HTM
- The first paragraph of this description (under "The Job") is actually fairly concise with regard to one part of the job. But it completely misses the mark going forward.
- Wikipedia
- Ok, this is taken primarily from the INCOSE definition, but it reads a bit better. It's still too long winded and generic to really use to describe what you do.
The term Computer Systems Engineer seems more likely to have evolved from the term Systems Administrator. In my experience, the terms are used interchangeably. The term System Administrator has acquired many bad connotations over the years. Changing the word to engineer is an attempt to overcome those connotations, and bring to light how the role has evolved in the modern IT world.
What's interesting is that the most successful Computer Systems Engineers that I've met are in practice Systems Engineers by the Wikipedia/INCOSE definition. They have learned, either by training or experience, to apply various levels of engineering methodologies to their work. Their success has put them in charge of increasingly complex systems and forced them to learn technologies beyond those expected of the Systems Admin. And their value in that role has brought others to them to help understand the interdisciplinary nuances of complex systems.
All of that is still very little help in telling my neighbor what I do for a living. So let's instead look at how other highly technical roles describe themselves. Most other types of engineers work in a much more physical world. Rather than describing what they actually do, they give examples of projects they've worked that their audience can relate to. "I helped design the Tacoma Narrows Bridge." "I ensured that new downtown apartment complex won't fall down in the next earthquake". Here is something that can be useful, given that you work on a project that your audience can relate to. I've explained to people in the past that I do engineering on the system that helps you track packages with DHL. That's probably the most appropriate answer in a social setting. But what if you're trying to establish a business relationship with someone?
In the end I think the goal is not necessarily to explain exactly what you do. Instead, it may be to provide a small insight, while opening an avenue for conversation. In that spirit, I plan to start offering tidbits of info that most people can relate to, and use to ask more detailed questions. Offering that I work on the computer systems that track packages and schedule pickups for DHL is a good example. Nearly everyone has shipped a package. If they know nothing of computers, they can discuss the shipping aspects. If they do know computer systems, they can ask for details about what they understand from it.


0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
Links to this post:
Create a Link
<< Home