Q&A with with Josh Siverson, Alluvial's Senior Solutions Architect

Josh discusses his background, what Solutions Architects do, supporting Liquid Collective's collaborative approach, advice for people with non-technical backgrounds, and more.

Hi Josh! Tell us a little bit about yourself, and your professional background.

Professionally, I graduated from university with a Business Administration degree in Economics. I would've considered myself very much a non-technical person post-college. I did a variety of roles that were customer facing, including Customer Success Manager, Enterprise BDR, Account Executive, all of those different roles. Through my work with those different customer facing roles I enjoyed a lot of parts of interacting with the customer. But there were some parts that were a little more challenging. So I was faced with the question of what I wanted to do, and at that time coding bootcamps were getting quite popular.

I determined that I wanted to try to go through a coding bootcamp to see if that would give me what I wanted in my career. I went to the program fully intending to become a Software Engineer. One thing led to another, and I ended up being a Technical Product Owner right out of the bootcamp at a pretty small team.

I loved that role for a lot of reasons. One was that it was good to have a job coming out of bootcamp. Another was that I was able to use my customer facing skills while deeply developing my technical understanding and experience by working with the backend developers at the firm. I learned a lot there. When that role wrapped up I was focused on finding other roles out in the world that were kind of like this, where I could still be technical and really grow that depth while still being customer facing.

A good friend of mine was a Solutions Consultant at the time. They said, "Hey, Josh, you should check out this Solutions Engineering/Solution Consultant role. I went for that and ended up at Twilio, which was the first time I was a formal Solutions Engineer. I really enjoyed the role. It was a great place for me to start to learn what it means to become a pre-sales Solutions Engineer, and it really solidified my passion for both the developer community and API-first companies. So I've been a Solutions Engineer or pre-sales professional for the past four years now.

Personally, outside of work, I have a little newborn who is just seven months old, so my spouse and I spend a lot of time hanging with him. My spouse is from South Korea, so we often travel through South Korea and try to travel internationally as much as we can. That's going to be a bit more of a challenge with the little one but we're excited to show our little one the big worlds out there.

Beyond that, I enjoy doing physical exercise. I've recently gotten into adventure racing with some friends of mine. It encompasses the multi-domain of trail running, mountain biking, and water sports, all in a map where you're left with a physical map to navigate areas.

What draws you to working in the technology industry?

When I started out my career working in a printing company I realized how much technology could shift the way we do things. I had seen the amount of creativity that folks could have in so many different domains, and the problems technology can solve when done correctly. After working in this very industrial area for a while I saw slivers of technology, but that's why I decided I wanted to work in tech full-time.

Being a part of this industry is really exciting for me. There's also a constant amount of change that comes with technology, that requires constant learning and keeping up-to-date, which I find really enjoyable. There's always something else you could be learning and growing in. Those pieces are really what interest me today about being in the technology industry.

Was there a turning point in your career when the value of decentralized technology really clicked for you?

Funny enough, I think one of the areas that struck me was during my time at Twilio. Twilio as an API company does SMS voice, video, and a lot of customer engagement communications. As I understood the SMS ecosystem, it showed me how much power the carriers—like AT&T, Verizon, all of these big telecoms—really have. They are the gates to folks being able to send and receive text messages.

Now, there are certainly valuable pieces they add, but in a lot of ways I saw them as really dictating what could and couldn't be done. There could be a lot of innovation, but, frankly, some of the technology at these companies just wasn't being updated and that really hampered innovation. That actually showed me how, if the technology is decentralized and it's public and open, then as a collective body we can move and update things together without being beholden to these large incumbents. So I think that was one of the first signs of where decentralized technology could happen and play a part.

“That actually showed me how, if the technology is decentralized and it's public and open, then as a collective body we can move and update things together without being beholden to these large incumbents.”

—Josh Siverson, Senior Solutions Architect, Alluvial

What does a Solutions Architect do, and how does that play out in your role at Alluvial?

Commonly, within the Solutions Architect (SA) or Sales Engineer role, there are two broad buckets. One is pre-sale, the other is post-sale. There's many ways to define this role, but one general description is that when customers are looking to onboard or work with the solution in the pre-sales phase, the Solutions Architect works with the customer to explore, to validate, and to help make sure that the business problems they're looking to solve can be solved with the company's solution.

The Solutions Architect will help think through the business values, map those business values into use cases, and then map those use cases to the products and services. Through that process they usually go through proof of concepts, demos, validations, and all kinds of things that go into de-risking a technology solution for the customer to ensure that the company's solution does in fact do what they need to do.

Then there's the post-sale, after commercials may have been closed and the deal is finalized, at which point usually the customer can transition to a Customer Success team. Then, you might have a technical counterpart that's helping with further implementation, or looking at helping with expanding other use cases that the customer might grow into.

How does this play out in my role at Alluvial? Well, Alluvial being a software development company that has APIs, customers want to integrate those APIs into their platforms. Having a Solution Architect helping to understand what customers need in terms of their use cases, from an API to technology, is really part of the technical validation phase.

Then, once teams decide that Alluvial is a good fit for them and they actually go through the integration they need somebody there to help them through the process. This helps make sure that they're thinking about the integration from a design perspective, from an architecture perspective, and also just providing support when they have questions as they're going along.

My role as a SA at Alluvial is working with those customers to uncover what they need to solve from a technology perspective that maps to their business. And then validating that, yes, Alluvial can do what they need to do. I then help them integrate the Alluvial APIs and Liquid Collective protocol parts into their technology stack so that they can then go and use the protocol, and have their customers experience it within their platform.

How does your work support Liquid Collective's collaborative approach?

One of the things I enjoy the most about being a Solutions Architect is that you're wearing two hats at any given time. These hats broadly are business/non-technical or engineering/more technical. You get to flow between these two personas at times. Because of that, we typically work with the business team, but also we work with the product and engineering team.

It's a really fun place to live in because you're at the intersection of a lot of things. It requires a SA to be able to work well with all different kinds of stakeholders, understanding what their KPIs are, how to help them, and then really how to take customer feedback that we may have about our product to share that with the team broadly. This is one really concrete area that SAs and pre-sales individuals generally help with a lot.

Given that SAs are working with developers a lot, the other piece is we get to create really good artifacts that help developers think about how to model and implement their architecture, or how to stick together different API calls. We collaborate with our marketing peers a lot on these sorts of artifacts, but also engineering, to make sure that what we're doing is getting signed off on from a technical perspective. So, it's a highly collaborative role in every organization, but certainly when supporting the Liquid Collective protocol where there's a lot of collaboration between all stakeholders participating in the network.

“Discovery isn't just a point in time. It's an 'always process' that the team is doing.”

—Josh Siverson, Senior Solutions Architect, Alluvial

You have worked across a variety of well-known companies and industries to develop solutions to solve customers' business needs. What themes stand out to you across this diverse background?

One of the few themes that stick out to me is that every customer that wants to onboard with a given solution should have a business need. If there's no business need—if they're just kind of looking for technology just for fun—then chances are that they won't ever really solve what they're after.

So, one theme across industries is to always ground exploration in looking at and helping to identify what a customer's business needs are. Then, one can explore what those use cases are to support those business needs. Thematically, what that means is that discovery is a really key characteristic that is always being done by Solutions Architects or other pre-sales individuals. Discovery isn't just a point in time. It's an “always process” that the team is doing.

The other theme is a constant need for good public information. What do I mean by that? In my career, at Twilio, then Coinbase, and now Alluvial (these are my three developer-first platforms), developers always need good information. That's documentation, that's artifacts, maybe blogs. Having the right information for developers makes it so much easier for them to take these APIs and stitch them together in their application. It helps them move a lot faster. I've seen where not having good documentation creates a lot of friction for the developers and the product team at the customer company, but also internally, where teams are onboarding, trying to learn, and they're also going through the documentation.

Where possible I try to default to a public-first option for these tools so that the information out there is visible, along with being maintained and refined over time. Because the other challenge is that once information is out there it can get stale, which can also lead to friction.

Both of these themes, of ongoing discovery and accessible documentation, have stood out to me in my work at various companies as themes that can be applied to any company looking to have an API-first approach to business.

Do you have any recommendations for other folks who have non-technical backgrounds, and are exploring working in technical fields now?

My first recommendation is that there are so many different hybrid roles at companies that are a great entry point to get in and start seeing whether or not you like it. For myself, going through the coding bootcamp, I really thought that I wanted to be a Software Engineer. Now that I've been in tech for a while I've seen what it's like as a Software Engineer (sort of, outside looking in). And I've realized that it's probably not the role for me for a variety of reasons; I'm sort of glad I didn't become a Software Engineer now. I wouldn't have known that if I didn't get in close to it.

The second recommendation is that coming from a non-technical background it can be intimidating to think about being a Software Engineer, a Technical Product Owner, or a Solutions Engineer, because you don't have that background of being a coder. But these are things that can be learned. It takes time and dedication, but these are concepts that can absolutely be learned.

I think I'm proof that they can be learned. I wouldn't have called myself a technical person before. A common story you'll hear from developers or technical folks is that they grew up as kids pulling apart toys. They took apart their computer and put it back together, you know? For me, that wasn't the case. A computer turned on and I thought, "Okay, it turns on. Great." I didn't even think that there was something in the computer running it—that wasn't a concept I even thought about. I didn't have that analytical-default-mind that a lot of developers do.

But throughout my life I've tried to learn how to be more analytical. Pulling things apart and thinking that that way is still a challenge for me, and I still have a lot of room to grow in that area. But I say that as a motivation to other folks who may be like me but who feel like they just can't get to that level. Fortunately, there are so many resources (free, paid, virtual, in-person) that can allow you to become more technical.

My advice for someone who wants to move toward a more technical role is to start with that exploration of how you operate best to learn. If you can do something like a Udemy course that's self-paced, that's great. There's so many good courses out there that can help you learn. But if you recognize that you need some more accountability, be that in-person or live online, a bootcamp may be right for some folks. But there's a variety of resources that provide different options. Starting that process and then continuing when you find a good way for you to learn is what I recommend.

“Always ground exploration in looking at and helping to identify what a customer's business needs are. Then, one can explore what those use cases are to support those business needs.”

—Josh Siverson, Senior Solutions Architect, Alluvial

What is your favorite part about working as a Senior Solutions Architect, and in the web3 space?

Much like working at other places, the web3 space is still a very API heavy domain. With that I feel quite at home, looking at API docs and reading what an RPC spec might look like. But, different from other technology companies, the web3 space is still very much in its infancy. As such, the models and architecture being created are so new that there's almost too much information to try to learn and keep up with, at times.

That said, it's fun to read about and learn about all these new companies and concepts that are coming. Some stick, some don't. I think that's all part of the space's continued emergence. But being close to these cutting-edge technologies is my favorite part. It's really fun to be a part of and learn about.

What are you the most excited about achieving in your time at Alluvial?

There's a few things that come to mind. The first is that I'm really excited to get to partner with some of the amazing Platforms that Liquid Collective has right now, with the likes of Coinbase and Bitcoin Suisse. But I'm also excited to get to work and partner with a lot of other Platforms that will join in the future. I'm really excited to see where the Liquid Collective protocol can be integrated to really get out to institutional customers.

The second is that Alluvial is a fairly new team, and I'm really looking forward to making an impact for the team. To help bring in new features, and discover what customers need to make their product the best they can for their users. To help explore how Alluvial can support Liquid Collective in helping to develop software that enriches the participation experience for our customers' customers.

I'm also looking forward to partnering with the broader team at Alluvial. Given that we have 11 folks it's still a very small team, so being able to partner so closely is really exciting to me. Working on a lot of initiatives is fun. I enjoy getting to wear new hats because it stretches me and expands my knowledge set while also increasing my empathy toward other folks on the team and what they have to do.

Thank you Josh!

---

Interview by Melissa Nelson

---