December 31, 2018 Comments Off on Sales engineer career path #3: Product development
It’s time for the next installment in the ongoing series about career paths for sales engineers seeking new opportunities. This time around, I’m going to talk about the pros and cons of moving into product development. Before I begin, it’s important to understand that this is one of the more challenging transitions, largely because the skills necessary to be an effective SE can be so different than those that characterize the most productive developers. With that said, here goes:
- Sense of ownership. SEs flit between opportunities; product developers stay involved throughout the lifecycle of the technology they’re building.
- Better base salary. In general (but not always), product developers earn a higher base salary than SEs.
- Less travel. If you’re tired of those 6 am flights to remote client sites, product development might be a welcome relief.
- Less variability. There are fewer subjective factors – such as client whims and sales representatives who can’t sell – that can block your achievements when you move into product development.
- Technically demanding. If your skills aren’t up to par, you’ll really need to put in the educational effort to meet the requirements of your new job.
- Less upside. While product developers may have a larger base salary, thanks to commission SEs can really hit the jackpot if they have a particularly good year.
- Risk of outsourcing. Don’t kid yourself: if your employer can save one dollar a year on your salary by moving your job offshore, they’ll do it. In contrast, it’s nearly impossible to outsource SEs.
- Less interaction with customers. Plenty of SEs really savor the opportunity to meet with prospects and clients; product developers rarely get the chance. Some SEs find being ‘chained to a desk’ to be too confining.
Making the transition
It’s a big leap to move from the sales organization to the product development team. Here are some steps that can make this migration less painful:
- Find one or more champions in product development
- Discretely meet with them to learn more about what it takes to succeed in their group
- When ready, approach your manager and express your desire to make the change
- Once you get the go-ahead, work with HR to find a position in product development
- Work on a mutually agreeable timeline to switch roles
If you’re interested in being notified of future editions, subscribe to the blog or follow me on Twitter: @RD_Schneider. You can read other sales engineering-related posts here.
November 30, 2018 Comments Off on Five great starting points to transition into a Sales Engineering career
For years, I’ve been describing the numerous advantages – and minimal drawbacks – of a career as a sales engineer:
- I’ve written about traits that one should possess to increase the likelihood of success
- I’ve discussed follow-on career paths
I’ve even told you about bad behaviors that will curtail (or abruptly end) your sales engineering career
What I haven’t yet talked about are some of the jobs that lend themselves to transitioning into a sales engineering role, so that’s what this series is going to be all about. Here, in no particular order, are five of the most logical starting points to becoming a sales engineer:
- Technical support. You’re charged with answering customer questions and/or resolving product issues
- Marketing. You design, own, and/or promote the product or service
- Customer success. You ensure that clients have a positive experience when deploying the product or service
- Product implementation. You’re responsible for moving the product or service from concept into production for the customer
- Development. You build and/or maintain the product or service
I’ll be writing about each of these roles in more detail. If you’re interested in being notified of future editions, subscribe to the blog or follow me on Twitter: @RD_Schneider. You can read other sales engineering-related posts here.
October 31, 2018 Comments Off on Informative article about Microservices vs. Service Oriented Architecture (SOA)
I really enjoyed participating in the recent 2018 SmartBear Connect conference. After some of my talks on designing good API tests, several people came up to me to get my opinion on the differences and similarities between Microservices (a very hot topic in the past couple of years) and Service Oriented Architecture (SOA) (which dominated software architectural discussions about 10 years ago).
Rather than rehash what I explained at the event, I thought it would be better to point my readers at a very concise, helpful article published by Ima Miri on Dzone. Check it out if you’d like to get a better handle on how these two approaches are related.
September 30, 2018 Comments Off on Advanced SoapUI Training Agenda at SmartBear Connect 2018
I’m looking forward to presenting a series of eight advanced SoapUI API testing talks at the upcoming SmartBear Connect conference in Boston on October 29. Here’s what I’ll be covering:
- Determining if your API is behaving properly requires examining the contents of the responses it returns. This session will showcase some of SoapUI’s most powerful message evaluation assertions.
- Automating your API tests means avoiding hard-coded, rigid message response evaluations. This session will teach you how you can apply flexibility when examining what your APIs return.
- Using XPath expressions in your SoapUI assertions offer tremendous productivity enhancements versus writing Groovy code. This session will show you how to create powerful and flexible XPath.
- Many applications incorporate multiple APIs. In this session, you’ll learn how to use the SoapUI data sources that enable feeding the output of one API to subsequent API calls.
- It’s important to use diverse data when testing your APIs. SoapUI includes robust data generation features, which we’ll explore in this session.
- Testing APIs means coping with ever-changing endpoints, security credentials, database connections, and so on. As you’ll learn in this session, SoapUI’s environments greatly simplify this vital responsibility.
- API testing responsibilities are often shared among multiple people. In this session, you’ll see how easy it is to utilize composite projects and Git to boost your teamwork.
- SmartBear continues to significantly improve SoapUI’s integration with the entire software development pipeline. This session will highlight just one example by demonstrating how to link your API testing efforts with Jenkins’ continuous integration/continuous delivery features.
August 31, 2018 Comments Off on Integrating RDBMS and multi-model databases Webinar
Multi-model databases offer tremendous advantages for deriving meaning from your enterprise’s complete data collection. However, to realize these benefits it’s necessary to coordinate your RDBMS with your multi-model database. This is often a time-consuming, tedious task, but there are some exciting new technologies out there that make it much easier.
- Carry out a one-time migration from a legacy RDBMS into the multi-model graph database
- Keep all of your existing systems synchronized on an ongoing basis with your multi-model database
- Conduct sophisticated analysis to extract actionable intelligence from your graph, document, and relational data
You can register here.
July 31, 2018 Comments Off on Participate in SmartBear’s State of Testing Survey
SmartBear provides a highly useful, well-integrated set of software design, development, testing, and management solutions. Once again, they’re polling the marketplace to get feedback on how enterprises are testing their vital software resources.
It’s definitely worthwhile to participate in this survey, because it provides critical insights that helps guide product direction and thus deliver more accurately targeted tools to the market. We use the survey results as well when enhancing our ReadyAPI and SoapUI training classes. You can find the survey here.
June 30, 2018 Comments Off on Bad Sales Engineer Behavior #6: Stagnation
Ageism is absolutely real in technology companies. However, in my experience it’s much more predominant for developers. Companies want to squeeze as much code as possible from people for as little money as possible. Younger people are more likely to tolerate this, while older workers are far less idealistic and can see right through the scam.
On the sales side of the organization, ageism is less prevalent because all that matters is hitting quota. In fact, older professionals bring some unbeatable skills and experience to the table, and a 60 year old sales rep that consistently exceeds her revenue quota will continue to hold her job; the 30 year old who only closes on excuses will be shown the door.
It’s important to note that for older sales engineers, the ability to land and keep a job only holds true if the individual takes the initiative to remain current with the latest relevant technologies. It’s unfortunate, but I’ve personally encountered far too many sales engineers whose technical education stalled sometime during the Clinton administration. Unsurprisingly, prospects and customers pick up on stagnation, which diminishes the likelihood that the sales engineer will be able to make a compelling case about the technical merits of their solution. Managers notice it too.
There’s no excuse for this: there are ample resources online – both software and tutorials – for any kind of new technology that you can imagine. We’re not talking about a major investment here – a few hours should be all that’s necessary to at least speak intelligently about a new trend, particularly one that is a major factor in the product or service that’s being sold. As an added bonus, this will help not only when talking with potential customers, but will be invaluable when changing jobs.