The majority of my portfolio and story content relating to my time working on systems management software is about my time doing interaction design work. Most of my time at the company, though, was spent in other roles.
Most of my time was as a sales engineer, working with an account manager. My responsibilities were to show and explain the software and answer questions in meetings, demonstrations, and in multi-day on-site pilot deployments. This was exciting and gratifying work. I worked with skilled account managers (sales people) who could navigate complicated organizations and the challenges they placed in front of software vendors in the whole process from early contact through evaluation, negotiation, purchase, maintenance and follow-on purchases. I spent time with everyone from high-level executives at client companies to entry-level network administrators and lots in between. I was proud to be able to come in with software that worked quickly, was useful (even if it did have usability problems), and would make their lives at work better. I went from being nervous about how to do things in the early days and fearing that I wouldn’t be able to get the software to work in client environments to being able to go in routinely with confidence and have things working impressively, usually by lunch on the first day with “gravy” after that. I was also proud that I went from being the first full-time sales engineer covering the entire U.S. and Canada to being a mentor to my new colleagues to being sent around the world to do my work. I eventually got tired of the challenging travel schedule and wanted to try other things in the company, but I still reflect fondly on being able to bring useful software to people who needed it.
Alongside and leading up to my sales engineering work, I did a fair amount of training and our early curriculum design and documentation. In our earliest days, it was up to someone in the small company to write user documentation (and guide contractors’ work), plan and deliver technical training to new employees, new customers and new partners. I took on much of that work in my first year at the company, and while I make no claims to have been an expert in any of those areas, I’m proud of the work that I did. As we hired people to take on these responsibilities, my involvement shrank to on-the-job training for pilot users (like all the sales engineers would do) and some special training for our first Asian partners, much of it delivered in Japan. In my later time at the company, I was asked, along with a colleague, to develop and deliver training for customer-facing technical and sales and marketing new hires that would give them overall technical orientation to the domain we worked in as well as an introduction to the company’s product line and how the products met different customer needs. This couple of hours was often cited as the most useful part of a week of new-hire training.
When I first started at the company, I was hired as a customer support person (even before we had production customers). I had done support for years before and felt confident and competent, but I knew that I didn’t want to do it for long. As the company grew and other needs became apparent that I thought I could meet, I took them on, including those listed above, and even a few months of project management.
I even spent a brief period of time in the company’s marketing group, focused on explaining to technical people in the company that acquired ours what we did and how we showed its value.
With all these responsibilities working with so many different people in so many different places over the course of years, I was able to develop a lot of understanding and empathy for colleagues and counterparts, managers and executives and the challenges that we all face. It’s hard for me to imagine learning as much as I did during those years in any other way.
Carl Seglem Portfolio
Big Data, Enterprise, and Complex Systems
Lean & Agile