Giant Swarm’s solution architect versus account engineer guide

A Solution Architect and an Account Engineer walk into a bar…

What’s the punchline? Well, if you asked us a couple of months ago, we wouldn’t be quite sure — we were still trying to work out the minute differences between the two roles, let alone the humor in them. Now, since we’re proud to report that we’re growing and so our teams are growing, we have a different (and more developed) perspective. 

But let’s go back to the beginning. 

When all is said and done, we’re kingmakers and not kings. Making our customers happy, makes us happy. Making our colleagues happy, also happens to make us happy. And, as far as we’ve seen happy colleagues have a knack for sharing their happiness with customers. To this end, we first started with the Solution Architect role. This role is team-based and this dictates the philosophy of the role — architecting solutions within the team, around the team’s focus area, and thus improving the solution for the customer. 

Then, we grew, our customers grew and so if the individual teams were separate huts in a village, we needed a (wise) leader to take care of them all while remaining focused on the wellbeing and happiness of the village as a whole. Enter the Account Engineer and the Solution Architect roles, in unison, the old Solution Engineering.

“I see the Account Engineering role as a customer-centric role that focuses on what’s needed while being pragmatic, but keeping the envisioned future in mind, while the Solution Architect role focuses on pragmatic technical implementations matching the here and now needed by customers and the team’s roadmaps. The two roles are indivisible; to reach what’s possible, you need someone dealing with what is.” — Oliver Thylmann 

With the distinction clearer, let’s dive deeper into the symbiotic relationship between the two roles. To continue the analogy of the huts (Solution Architect) versus the village (Account Engineer), no matter how amazing the hut is, if the village around it is burned to the ground, the hut can’t prosper. Inversely, if the village has an innovative and ambitious roadmap but the huts are barely holding on day-to-day then it’s unlikely that the village will reach its goals. The success of the village depends on the success of the individual huts. The success of the huts depends on expertise and attention to detail. 

Our Solution Architects are subject-matter experts that focus on the technical details. If a customer needs a solution for a specific problem, whether it be AWS or Kong-related, for example, our Solution Architect is perfectly positioned to provide a holistic solution that is informed not only by their subject-matter expertise but also supported by the team they are in, e.g. the team dealing with AWS or the team dealing with applications (among them Kong). Additionally, they have experience dealing with customers in general. A win for one customer is a win for all customers as our Solution Architects apply their knowledge democratically. Our Account Engineers on the other hand are customer experts. Where the Solution Architect drills down to try to find water, the Account Engineer dares to dream of moving closer to the river. We’re talking about immediate solutions versus long-term benefits. Account Engineers are only invested in a particular topic insofar as it directly impacts the customer. They’re curious but not committed to any particular way of doing. What they are committed to, is the customer’s success now and in the future. Should the customer try one of our managed apps, talk to another one of our customers about security, get training, look at changes to parts of our stack, they are not bound to take care of the hut but benefit from knowing about the capabilities of the village.

Spelling out the distinction between these two roles helps us to solidify what makes us different — and hopefully, special — too. We have evolved to require these two roles because we're an evolving business that seeks questions as much as we seek answers; how can we improve our customers' lives? Where are the areas that we can improve? Better questions result in better answers, and while we still don't know the punchline to the joke at the beginning of the article, we'll let you know when we do.