“Have you considered a role as a solutions engineer instead?”
I was in a coffee shop in early 2019, one of Jetstack’s co-founders sat across from me. I’d applied a few days before for a role as a software engineer with Jetstack before it became a Venafi company, and this was the informal interview stage. We’d spent the past 20 minutes or so talking about Jetstack’s history and my experience in software. While I’d seen Jetstack was hiring for both a “software engineer” and a “solutions engineer”, I’d not thought about it — and I admitted as such to Matt.
“You should consider it, I think your background would be a great fit”. I wasn’t sure what he meant, I’d never been a consultant or even done freelance work. I’d been a software engineer my whole career, working on internal teams building products with roadmaps a year long. Not a customer engagement spanning a few weeks or months.
“As long as there isn’t too much travel…” I asked, mulling over just how my wife might react if I told her I was going to be away often.
“Oh no, some consultancies have staff on-site with a customer day-in day-out, but we don’t do that. Maybe on-site once every couple of weeks for a day, or an occasional overnight trip.” I must have seemed apprehensive, because he continued after a moment “It’s up to you, I think you could do either. But you can always transfer internally if you don’t get on with it”.
Two interview stages (and one reassured spouse) later I became the company's newest solutions engineer.
What is a solutions engineer?
The job spec defines it like this:
Our solution engineers work to architect, design and implement Kubernetes-based integrations for a range of customers. They work directly with customers, onsite and remote, and are as comfortable in front of a whiteboard explaining concepts to a customer as at a Linux terminal implementing highly-automated and scripted solutions.
If that sounds vague, it’s because it is. The reality is that our job is changeable. Sometimes you’re writing YAML to configure a CI/CD pipeline. Sometimes you’re advising a customer as to improvements to their production environment. Sometimes you’re helping them write some truly novel software.
One common concern is if we’re just “YAML Engineers” who spend all day configuring things and doing no software. I don’t code for every project, if you don’t count YAML, but I’ve certainly found value in my GoLand subscription.
The real advantage is that we get to work with some truly cutting-edge technology. As a consultancy we only get hired to fix hard problems, so much of our work is truly fascinating. Not every project is going to be great for everyone of course, but that’s the advantage of consultancy work — you’re not stuck doing one thing for too long if you don’t want to be.
We dedicate time and effort to staying on the cutting edge too. We only do billable customer work four days a week at most, with a whole day a week dedicated to a wide range of internal activities. Anything from self-directed learning, participating in internal projects or contributing to open source. Plus five conference and ten personal development days a year we can book like annual leave.
What’s the average project like?
It’s hard to pin down average. But every project starts with a Statement of Work. This is a document written by us and negotiated with our sales staff and the customer. It lays out, in effect, what we’re being paid for. How many of us will be present, how long for, and what we’re there to achieve.
Solutions engineers like me help review and build these documents, and they form the basis of our engagements. Once everything has been agreed and the legal formalities have been signed, we can begin work. Again this varies per customer. For some we’re given credentials and can begin very quickly. Sometimes they prefer to ship us their own hardware. Some that work in highly regulated areas of business require more comprehensive onboarding and orientation. But once we’ve done what is required of us we can start work.
What’s a “day in the life”?
Different team members will give you different answers because we’re trusted to manage our time effectively with the customer. Some will be online at 7am every day because they like that routine. I respect those colleagues very much, but I’m not one of them. At a recent project I had a 10am daily customer standup, so I started work with enough time to prepare for that rather than at a fixed time. This varies depending on the customer and their needs and expectations.
In general, we embed into the customer’s existing team and match their practices. Often this is a morning standup or sync video call meeting, and maybe further meetings as needed. Most teams use Slack or something like it to talk internally. Quite often you’ll be treated just as any other team member by a customer, especially in longer engagements or in companies that often use contractors.
Then it’s on with the work. Coding, helping a customer’s engineer debug an issue, interacting with a Kubernetes cluster, whatever the engagement has me there to do. But I’m still a team member. I’ll give my colleagues on other projects advice or be a sounding board for ideas, or bring back interesting things I’ve found to our internal community.
Then there are Fridays. We tend to put all our internal meetings on a Friday (we’re pretty good at not having too many of these here, though) so at least a couple of hours will be calls there, and the rest of the time is for me to decide what I should be focusing on. Usually this has nothing to do with my customer project: research, side projects, or blog posts (like this one!) are all great examples.
When our experts are your experts, you can make the most of Kubernetes
Conclusion
No role is perfect, nor is being a solutions engineer. I’ve had difficult or frustrating customers in the past, but I’ve always been happy to talk with my colleagues about it, and I’ve always been supported by them.
It’s a different role to being a software engineer for sure, but no less technical, and no less interesting.
If you’d like to join us, we’re hiring now.
The best way I can sum it up is: I’ve never felt the need to ask about that transfer.
Cover photo by Fahmi Fakhrudin on Unsplash