What makes an engineering culture not just good but great? Today on Engineering Together, I sit down with Joel Turkel, Chief Architect at Salsify, to unpack exactly that.
Drawing on nearly a decade of shared experience building at Salsify, we’ll explore the architectural decisions, cultural principles, and team dynamics that underpinned the company's technical evolution and sustains it today. This conversation is a deep dive into how intentional design – both in systems and in culture – can power product innovation and organizational resilience.
The following transcript has been edited for clarity.
Adam Ferrari: Hello and welcome to Engineering Together. This is my little corner of Substack where we talk about engineering leadership topics. I'm really excited for the conversation today. We've got Joel Turkel with us. Hey, Joel.
Joel Turkel: Hey, Adam, great to see you.
Adam Ferrari: Great to see you. Just to set a little context for the discussion today, I often get asked, what does a good engineering culture look like? What is a good engineering environment made up of? And the example I love to point to is our experience at Salsify. Joel and I worked together at Salsify for, I think, close to seven years. And it had a lot of hallmarks of what I think were a really strong engineering culture. I try, whenever I get asked about that, I try my best to recount the stuff we did.
Joel is the chief architect at Salsify and had a huge amount of influence on the technology strategy we took and the engineering culture we established. So I think a lot better to do this as a conversation with Joel will get, and I think, get deeper dive into some of the stuff we did. So yeah, looking forward to diving in.
Maybe just for starters, Joel, you could just do a little intro for yourself so folks listening can know your background and a little bit about how you got to Salsify. And then we'll talk about Salsify and what it is and we'll get into the whole environment. But we'll start with you.
Joel Turkel: Yeah, definitely. I've been working in the engineering space and enterprise software for 25 years now, really ever since I graduated college. I've really been drawn to the complexity of it. I just love how every business operates a little bit differently and you've got all kinds of interesting challenges you need to tackle.
Prior to Salsify, I was at a company called Endeca with you, Adam, and the three founders of Salsify. We were a search platform powering a lot of the top eCommerce sites at the time. One of things we noticed is that you can have the most amazing search technology, but if you've got bad data, you're going to have a bad shopping experience and really, that was the genesis of how Salsify started. The three founders left Endeca and founded Salsify. I'd worked with all three of them really closely, so I would have jumped on an opportunity to work with any one of them again. The fact that I could get all three in one go was kind of a no brainer.
I told my wife at the time that, you know, it's a startup. Had no product, no customers, no revenue, nothing and it would probably go out of business within a year, but I'd learn a lot and have a lot of fun. We had two small children at home at the time and surprisingly she was okay with it. 12 and a half years later, you know, here we are and the company's been a wild success beyond really what I could have imagined at the time.
Adam Ferrari: I remember using a similar talk track with my wife when Endeca was starting out. Now, Salsify is a great example of what they call the Endeca diaspora effect of some of the great startups like Toast and Sprout Social and others that came out of Endeca, including Salsify.
That's a great transition. You hint a little bit about Salsify. In our experience at Endeca, one of the big things we did at Endeca was powering a lot of the eCommerce sites of the day and their search experience in particular.
Maybe you could talk a little bit about Salsify, like who are the customers, you know, what problems does Salsify solve for those types of customers?
Joel Turkel: If you've ever shopped online at Amazon or Walmart or any top tier retailer or long tail retailers for that matter, you've probably interacted with Salsify managed information. What we do is we help brands manage all the information they need to manage about a product in order to be able to sell online across all their different retail channels. Things like the marketing attributes for a product name and a product description and the features as well as technical attributes like the weight and the length and various dimensions, as well as logistic information, and then really provide a rich platform for being able to get that out to all their different destinations and transform their data to meet the unique requirements and format of each retailer.
Then on the flip side, we're also helping retailers who have the same problem in reverse. They're trying to ingest lots of data from different suppliers and harmonize it and then power those rich shopping experiences.
Adam Ferrari: Yeah, my experience with it was you start out looking at it, it feels like a SaaS application for creating and managing content. But it really is this network thing where it's trying to adapt that data throughout the whole retail ecosystem. Which, by the way, I think if you haven't worked in eCommerce or retail, it might not be obvious how complicated the data models are. But when you start to think about M&Ms and the different packaging and the different way they get bundled into that Halloween mix, right?
Like it actually gets super complicated. And so it's a network where inherently the information is pretty complicated. I think that's useful. Like as we dive into the tech stack, it's not an easy problem.
Joel Turkel: Yeah, every retailer manages things differently too so not only is the data model inherently complex, you've got differences with each retailer that just explodes out that complexity.
Adam Ferrari: Yeah. You know, I was always super proud of the product at Salsify. And I don't think we could have built it without a really strong engineering culture and strong engineering environment. Maybe like, I know we'll get into some deep dives and specifics of what we built, but like maybe you could do a flyover of what the tech environment was like and what the adjoining culture was like at a high level as we dive in.
Joel Turkel: Let's start on the tech side. Cloud-native application. We're primarily a Ruby shop, but we do have some other languages in the mix. We're running in AWS with parts of our workload in Azure, too. We do have a really strong DevOps practice, which is really necessary to have the quality and the reliability that we need. It is an enterprise application, so along with that brings a host of security challenges, as well as really a level of configurability and customization for our customers, as well as being able to enable integrate into their entire IT ecosystem. Some of the key technologies we'll get into in more detail later, are things like Postgres, Kafka, GraphQL, Elasticsearch, Kubernetes. Those are the kind of super high level technical details.
I'm glad you touched on the culture because I do think that is such a key part of Salsify and really what's made it such a special place. We've been very intentional about the culture from day one. I remember, I think it was my first or second week there, Jason, Jeremy and Rob, the three founders, and I and the other founding engineer sat down and we had a long meeting talking about the culture. I thought it was crazy at the time. I was like, guys, we don't have a product or customers. We got to get going. What are we doing here? But in hindsight, that was so important being intentional from the very beginning about the kind of culture you want to build, because it's really hard to change later. With respect to engineering in particular, some of the things I would call out about our culture, one it’s incredibly customer focused.
When our customers win, we win and really we need to understand their problems and bring technology to bear to make their lives better. We love technology, but we don't want to just do technology for the sake of technology. It's really important that we're actually solving real problems for our customers. We have a very high technical bar and we put a big emphasis on quality, but we also really value shipping.
You know, having something perfect that is just sitting on the shelf doesn't do you any good. You really need to get stuff out there, incrementally improve it over time, and really marry the needs of the business to the technology. I'd also say we've got a culture of continuous improvement, which ties in with that. You're not going to get everything right out of the gate. That's fine. We're going to learn. We're going to make mistakes but as long as we continuously improve, that's a good place to be. Then finally, the thing I would call it is we have built a very empowered organization. It is not run by top-down mandates. We definitely are a firm believer that people closer to the technology problems have a really valuable perspective and often know the right way that the technology should be taken. It's really important that we're listening to that and enabling people to make the decisions they need to make.
Adam Ferrari: Yeah, I think that's a great capture. And by the way, I think so often there's this false choice between customer centricity and technical excellence. I think if my overwhelming experience with Salsify was that they actually worked, they were actually inseparable in a lot of ways. Solving for the customer problem didn't mean that you were going to just be reactive or not look more deeply at what the architecture should be. It was actually very much kind of in unison.
Actually, maybe that's a good place to dive in. It's like, I thought maybe we'd talk about some of the, I definitely want to come back to the culture and how it operated, but maybe we'll start out with some of the technical architecture, because that plays a big role. And there's no unique solution, but I mean, I do think it matters. And maybe the place I'd start asking you about is just because it's kind of topical. Like we did build over time, not initially. It started out as a Rails monolith.
Joel Turkel: Totally.
Adam Ferrari: but we did adopt microservices. It's topical because I'm seeing more and more stuff kind of, it's surprising because it's an old topic at this point, but there's some backlash, people being like, it's just complexity. And it wasn't my experience at all, you know, with us at Salsify that it was very valuable. And I think we took a, not, you know, not an extremist approach to how we did it, but so like, maybe you could talk a little bit about like the microservices architecture, both like where we went, but maybe also like you can talk about how we took it on, how we built it out incrementally.
Joel Turkel: Yeah, definitely. As you mentioned, we didn't start out with microservices. We very intentionally started out as a Rails monolith and that enabled us to iterate really, really quickly. We did that for two or three years and that enabled us to quickly find product market fit and begin scaling the business. I don't think we could have done that if we had gone right to microservices. Interestingly, folks on the business side were asking us, should we go to microservices? Because there was so much talk about it in the industry at the time and we wanted to make sure we weren't getting left behind. But it was a very deliberate decision not to go there yet because we weren't ready. We needed to really figure out the product that we were trying to scale. Then we found product market fit, we just raised our Series B a few months earlier, we were rapidly scaling both the team as well as the platform. We started hitting a lot of the challenges that you hear about that push people down this road. It became harder and harder to onboard new engineers because you've got this big code base. Even if you onboard people, you've got a lot of people trying to work on a shared code base together and they're stepping on each other's toes and it can lead to quality issues, but it also leads to a lot of coordination issues that slows everyone down.
Similarly, we were adding lots of new customers and we had a pretty robust system at the time with lots of bulkheads, but there's only so far you can take that with a monolithic application, especially when you've got central bottlenecks like the database. So really, it was the combination of wanting to scale different parts of the application differently, as well as really wanting to scale the team and allow people to work more independently than they could.
So that was the motivation. In terms of the journey that we took after that, we were not going to do a big bang rewrite of the application. I am definitely a firm believer in incrementally improving things, and especially for something like this, we had a million decisions that we're going to have to make from a technology perspective, so we wanted to start as small as we could.
Joel Turkel: Even when you start small, you still need to figure out things like, how are we going to handle service to service communication? Are we going to use synchronous communication between services or asynchronous? If we go asynchronous, what technology are we using in terms of the transport and the protocol? So we carved off a team of three of us to really go and start factoring out that first service. By design, it was not
a new area of the product but ratheran area where we felt like we understood it well, so we knew what the boundary of that service would be. Then we basically worked on carving it off. We did factor in a bit of customer love work while we were doing that so there was customer benefit beyond just the technical work. It really started fairly small. At that point, we built a lab for all of engineering to walk through, which even you went through, Adam, if you recall.
Adam Ferrari: Yeah, I remember proving that it was dummy proof.
Joel Turkel: It was pretty cool though, because it basically got everyone in engineering standing up their own service and using the technologies that we'd chosen to go with. We got a ton of valuable feedback from that in terms of things we could improve about the framework. It was also a great way to really start enabling people for this journey, because it was really something we were going through as an entire organization.
In terms of the technologies we picked, there's definitely a temptation to throw your old tech stack out completely and adopt all new languages, all new frameworks. We didn't do that. We were actually very happy with the Ruby on Rails and Postgres and some of our key technologies. There were only so many variables that we wanted to change at that point in time. Since then, I would say we've got over 100 services now across the entire platform, so it's definitely been a journey. We didn't get there overnight. It has not been without its challenges, but overall, I think it's really been a huge benefit to Salsify and I don't think we could have scaled to the size of the org, company, or the customer base without it. I think it was absolutely the right call.
Adam Ferrari: Yeah, that was my experience. mean, it was a disciplined approach, a disciplined architecture to true services with their own data store and their own infrastructure. And that really did lead to better modularity. You could go in. It's like the delightful thing when you move from a monolith and suddenly you're on a more narrow service and the test suite runs pretty instantly and you're developing in a context where you can kind of keep it in your head. It's easier and you're going to get it right more frequently.
And it did really help us deploy stuff with better velocity. It wasn't magic. I think people like there's maybe, you know, some unrealistic expectations, like services, you know, there's that Amazon style of like just giving patches of real estate on the page as if these things are completely disconnected. It's just not true in an enterprise stack. Like these things are going to have semantic dependencies of some unavoidable relationship. But if you're disciplined, you can kind of like beat down that, that
incidental complexity and hone it down to what's the inherent complexity of the problem space, you do end up with something where, and I think it was a testament, I remember there were years where we were shipping new features every quarter of substance, and I don't think that would have been possible if we hadn't made that investment. So when I see some of the backlash these days, I'm like, it's a bit of the baby going out with the bath water.
There's benefits, they're just not magic. Like you got to put in the sweat that you put in and the team put in to like actually rounding it out. And then like you mentioned in the culture, continuous improvement, the services architecture evolved over time and got hardened in various ways. It wasn't like we shipped the framework and like, you know, good luck everyone. It was, you know, improved and refined over time.
Joel Turkel: I do think some of the backlash has been because of the granularity of services that people have factored out. You see these architecture diagrams that look like a Death Star with thousands of services that are impossible to understand. Then if the economic climate changes and you've got a smaller engineering team attempting to support that, it's really challenging. I feel like we did a good job of getting the granularity right on services
and we didn't go too small. There were fairly meaty services that did really allow teams to operate independently.
Adam Ferrari: Yeah. You mentioned some of the supporting sort of architectural decisions that I think were pretty meaningful. One in particular early on, I thought the choice to go with predominantly async communications wherever possible was pretty important. And I think if you're going to have a complex services architecture, that's pretty essential to being reliable and something you can reason about. Maybe you could talk about what we did there and what the journey there was.
Joel Turkel: Reliability was one of our major concerns out of the gate. We didn't want a distributed monolith where if one service goes down, they all go down. The way around that for us was to really lean in hard on asynchronous communication and in particular, making things more event driven.
We opted for using Kafka and there was a lot of eventing between services. For example, a lot of what we do is managing product content, right? When a product changes, an event fires off and then different services can react to that. It can trigger workflows. It can trigger webhook notifications that go out or email notifications that go out. But you've got Kafka sitting in the middle there as this buffer, right? It can handle one service being down. It can handle huge surges in traffic and allow services to churn through that backlog at a reasonable pace without bringing down the application due to overload. It's really powerful. That coupled with Avro, which is what we chose for the message format, gave us a really strong contract between services where we could confidently evolve our message format to add new things and make sure that we weren't breaking them. Each service could be tested fairly independently because you've got these strong contracts. There's also a whole bunch of rich machinery that we had to build around Kafka to really make it reliable and fit our use case. One of the things that we were particularly concerned about was ensuring that we were actually reliably propagating events throughout the system.
Adam Ferrari: Yeah, it's an enterprise application and so you can't drop stuff.
Joel Turkel: Yeah, so like, I mean, a great example back to that example of a product changing is we fire off an event and then we have to capture that as an audit record because our customers want to know, show me all the times this product change and who changed it and what changes they made. You end up in this state where you're going to write the product change to the database, but then you also need to publish a message to Kafka.
Adam Ferrari: Huge value. Yeah, absolutely.
Joel Turkel: Those are two systems and you're not using distributed transactions to make that happen. So what do you do? It wasn't a well-known pattern at the time, but effectively what we did is a transactional outbox where you write events to the database in the same transaction where you're saving things for your core entity. Then you've got a background process that is pumping that event into Kafka.
That gives you reliability on the producer side and then on the consumer side, we needed similar reliability guarantees around ignoring duplicates and ensuring that we had message ordering. What we found with Kafka was that their model for parallelism was a little bit too limiting because you get a whole bunch of different events from potentially different organizations and different entities and they're shared by the same consumer,. so you can end up with head of line blocking and failures. If one message is bad in that group of partitions, then it pauses the whole process. We built a rich framework around that that allowed us to get finer grain parallelism than what we got out of Kafka out of the box. We call it the actor framework, modeled off actors. For all this, we were kind of building these patterns and maturing them as we went and really the key thing there is we wanted to get leverage out of our investments. We didn't want to just solve it once, so as we were building this stuff, we were building it in the context of a particular use case, but building it in a reusable way and putting it into shared libraries that could be shared across services.
That really enabled us to scale up the architecture a lot more because you have this rich set of primitives that you could be building services on top of.
Adam Ferrari: Yeah, that's a great transition. I know there's other technical aspects to the services architecture. Maybe we'll head on stuff like our adoption of GraphQL. But actually, I'd love to pause on what you just said about the shared libraries model and the fact that it was a very opinionated services architecture. If you went to build a new one, I remember this even from the get-go with that lab, but then more and more over time, there was a Rails template and there were all the supporting libraries.
So stuff like, you know, how are you going to interact with Kafka? That was largely packaged up. Maybe you could, I mean, it's probably worth talking about like kind of what our model was there and how it operated. And also it just kind of speaks to like, it starts to get into the culture of like, I mean, I always, I'm always careful with Salsify to talk about like, you know, as much as we had incredibly strong individuals, it really was the way that the team function, we had contribution from so many people and, you know, that was what made it strong. You hire more smart people, you know, but it's worthless if they're not empowered to do stuff and make the thing better. So somehow it like balanced, this is an age old problem of balancing sort of centralization where you end up with something coherent, but also empowerment where, you know, you can apply people's brains. like maybe you could talk about the model for that sort of shared, I call it, it's not really platform the way we talk about it today, but it's like our shared code that made building a, took all the commonality out of a service and kind of packaged it up.
Joel Turkel: We definitely had a big focus on making the golden path enjoyable to work with. We wanted to make the common things easy, and that involved factoring out all this stuff into a set of shared libraries, whether it's how you interact with Kafka, how you build GraphQL APIs, how you consume GraphQL APIs, our job processing system, service-to-service communication, a whole host of things that really form these rich primitives.
That's great and useful in and of itself, having that stuff but then the question is, how do you actually go and build it? We opted for an internal open source model and that worked amazingly well for us because it's really the people working with these libraries day in and day out that have the best intuition and the best view for how they should evolve over time. Having it isolated off on a separate team, is one, disempowering to the people who actually need to use it. But two, I think it doesn't result in the same level of quality necessarily because the folks working with this stuff have really great opinions and they really know how these libraries should evolve. They're also really intelligent, talented engineers that we wanna take advantage of in building this stuff out, right? It has not been without its challenges, but in terms of the level of quality of these libraries, it's really been amazing and we've gotten contributions from all over the organization to all of these libraries that has really made them so much stronger.
Adam Ferrari: One of the examples I think of in that area is you were talking about the actor framework and our need to have sort of message reliability. Obviously that comes at a cost to throughput. we hit stuff where the search indexing was so important to us because we wanted to, one of the hallmarks of Solisify was giving kind of a consumer experience to these enterprise users so there was less of a cognitive gulf between what you're experiencing and what the actual end sort of consumers seeing these products. I think it was a very powerful concept.
It meant we wanted to have really excellent consumerized search. So you want to have search indexing keeping up. This was no small task. So like, you know, but the team was empowered to say like, Hey, that actor framework, it's not one size fits all. not some tops down mandate. We need to keep up with the volumes of search indexing. We're going to, we're going to customize it and improve that and make something suitable for that harder problem.
Joel Turkel: Yeah, for sure. The happy path or the golden path is not mandated. I mean, the goal is to make the common things easyand if you've got an exceptional use case, you are completely empowered to bring a different technology to bear on the problem. I think that is super important too, because otherwise you wind up with a framework that isn't really working for a lot of people.
Adam Ferrari: Right, right.
Joel Turkel: That's just, as an engineer, that's not fun, right? You don't want to be told what technology has to be used. It should be something that is actually enjoyable.
Adam Ferrari: It's like that dichotomy with decentralization and sort of like, you know, innovation at the edges. There's also this thing of like, you want to amortize your investment in shared technologies, but you also don't want to preclude using the right tool for the right job. And I think by getting that people's ownership of the infrastructure, you get a much more healthy relationship to that kind of thinking. I think that's playing out right now. Like I think when I was there, we were still pretty much purely Ruby, but I think that these days, like for more of the performance sensitive stuff, you guys are adopting Go.
Joel Turkel: Yeah, for sure. I love Ruby and it's grea, but for some really low latency or really high throughput use cases, it's not the best tool for the job. It started out with an individual team that had a use case and Go was a good fit for that and Ruby was not, so they went with that. As we've been adopting Go for more and more high throughput, low latency use cases, we've similarly started building out the golden path for Go and starting to factor out shared libraries and we have a whole community of practice around it. It's absolutely a great thing because I think it enables experimentation with new technologies, but in a more disciplined way than you get if you just have no happy path and now every team is using their own technologies and that just makes it really hard because you're not focusing your resources on making a few things good.
Adam Ferrari: Yeah, yeah. So that kind of innovation, it reminds me, the one thing I wanted to talk a little bit about, I think was such an essential ritual. And one that we didn't have at the get go was the use of sort of architecture decision records, so ADRs. And like, just build on what we're talking about, like the team taking shared responsibility, not being like some, like, you know, not.
Not to say that all the stuff you do isn't awesome, but you're not some dictatorial chief architect who comes and tells everybody marching orders, what they have to do. People take ownership. And ADRs, I think, were the perfect manifestation of that. The architecture can be emergent, yet responsibly collaborated upon. And I think that created an actual concrete way to do that. How did we get to ADRs? Certainly, as the engineering VP, I didn't say, hey, we're doing ADRs. That was a grassroots effort.
Joel Turkel: Yeah, as we scaledas a company, it became apparent that when we making really important decisions, we needed to one capture them as a historical record, because we were onboarding lots of new engineers and in order to onboard them effectively, they've got to understand why the system is the way it was. Having that historical record, which we didn't have from the early days, would have been useful and helpful.
But also, as you're making key decisions, it's really important to align people around those decisions,. and depending on the type of decision and the magnitude of the decision, that's going to be a different set of people, right? There's some things that are more localized and you're really just trying to align your own team around them,. but there's some things like the decision to adopt GraphQL, for example. You know, that's a big decision that impacts a lot of people and it's important that you do that in an open and collaborative fashion.
So as part of that, we wanted to start writing things down and that's when we first started rolling out ADRs. It actually came out of a team making a decision. There was an engineer who was really passionate about the topic and he wrote the first ADR. It was great. We had a lot of engagement on the ADR in terms of the actual decision itself. Things have kind of taken off since there and as we've gone fully remote, writing things down has become even more important because you can't have that face-to-face communication at scale like you could back in the early days.
Adam Ferrari: Yeah, I thought even the medium, the fact that like ADRs were done in Markdown in GitHub with that kind of, you know, commenting and, you know, they're basically like textual PRs, right? And there was something about it that just led to sort of an elevation of the discussion around these kinds of ideas. And like, you know, it's hard. Engineers are passionate about what's the right way and the wrong way to do stuff. And they don't always agree.
You kind of want there to be some way to hash that out in a thoughtful way and get to the best answer, even if people have to disagree and commit like happens sometimes. And I think that they've really accomplished that.
Joel Turkel: Yeah, and I think that's where empowerment comes in. Because I don't think empowerment is making whatever decisions you want to make without any input. I think it's putting things out there, getting feedback from stakeholders, then it ultimately being your decision to act responsibly based on all of that feedback that you've gotten. All of our ADRs go out to all of engineering.
Adam Ferrari: Right.
Joel Turkel: Typically there's a smaller review that is explicitly tagged for feedback, but really anybody can comment on them. I think that's definitely improved the overall quality of our software because you do get people who have unique skills and thoughts in a particular area and you may not have realized that. They see an ADR go by and they'll offer really insightful comments and that's great. We're learning from each other and getting better.
Adam Ferrari: Yeah. The other thing I want to hit on about the culture, I remember in the early days, I thought it was a real strong point and then it became sort of established best practices. But from the get-go, there was a good culture of DevOps, really sort of declarative infrastructure, infrastructure as code. Like all the practices that you read about in the Accelerate book, like there was really early adoption. Although it meant, like, you know,
You know, we were evolving with the sort of the best practices and also like, let's face it, it was a startup. So we had to be practical and it was a scale up and then your, you know, your resource constraint. like, you know, maybe you talk about sort of our journey on DevOps. I think we got some of the best practices from the DevOps world. Maybe it didn't always manifest exactly by the textbook, but, but I think our heart was in the right place. And then we did reap a lot of benefits from that perspective.
Joel Turkel: Yeah, I think we've landed in a very mature spot where we can really safely and reliably release an incredible amount of software. We didn't start there but I do think it really started on day one with this mindset of you build it, you run it. That means you're on the hook for all the monitoring, all the observability that needs to happen in order to be able to run it, SLOs, making sure code changes are made so that this thing is actually operable, and doing things like feature flagging new features so you can roll them out safely and gradually. We didn't have an infrastructure team when we first started out. Everybody was doing everything. I think that really captured within our culture from day one.
Over time, though, as we grew and our needs matured, especially in the enterprise space where security is very important. We were on Heroku initially, a platform as a service, and moved to AWS. We had a complicated Kubernetes setup with Kafka in there and a complicated Elasticsearch setup. We did build out an infrastructure team that manages that stuff, but they manage it in a DevOps style. A big part of their focus is actually making sure that the engineering teams can self-serve. Our infrastructure team is on the hook for running our production Kubernetes cluster, but they're not on the hook for running any of the actual services in it. That's on the engineering teams that own those particular services. The infrastructure team has the Terraform set up so teams can manage things as infrastructure as code, all their S3 configuration and their database configuration. I think it's a good split between what we push down into the platform or infrastructure team in terms of supporting the golden path for infrastructure and what we enable the engineering teams to do.
Adam Ferrari: Yeah, there's a people thing there too. I always felt that if you can, and there's a bit of magic to it, but like there was a good relationship, personal relationship between sort of the more senior, you know, technical leaders on the feature teams and that infrastructure team. They were really pulling in the same direction. And if those relationships can be strong, then it's really then you're like getting specialization, just different, different sorts of depths of knowledge in different areas, but you're working together on a common thing. And that's probably the most effective picture you can get.
Joel Turkel: Yeah, and there are just so many things that having that strong understanding of both the infrastructure side as well as the application side just unlocks so much more in terms of optionality. So we've got tight collaboration between our infrastructure team and the product engineering teams that really unlock that.
Adam Ferrari: Yeah, there's probably a million more technical areas I'd love to talk about, I don't want to go too long on here. Maybe you could talk a little bit. I know probably some folks listening in are in, either are operating in or aspire to be in technical leadership roles like the one you occupy. You mentioned, we've talked about a couple of times, continuous improvement.
It was always, you to me, I felt like you had great taste in terms of, know, you'd be thinking about the right stuff ahead of time and such that when like, you know, the board would start needling me about something, it wasn't like, you know, was news. We were, we were on top of the right, you know, topics and challenges and getting ahead of stuff. I'm curious, like what.
Do you have advice or can you talk about your MO for how you operate? Because it's not like there's not a cookie cutter backlog of chief architect topics. It's something that I think takes some creativity. I'm curious how you go at it.
Joel Turkel: Yeah, for sure. It's a role that has evolved quite a bit too as the company has grown. I’m not hands-on keyboard, everyday churning out code like I was back in the day because that's not where we are as a company in terms of what is needed out of my role. In terms of the problems that I tend to focus on, a lot of it starts with what are the most pressing needs of the business and making sure that I'm focused on the problems that are going to deliver the most value. Often those are things that are going to happen over a broader time horizon. They're not things that need to get done today, but things that we're going to have to do six months a year, two years from now. So definitely looking for things that are valuable to the business. Looking for problems where there's leverage. If it's solving a problem in one particular area, that's one thing, but if it's solving a problem that is going to help us in a whole broad array of areas, that's a lot more appealing to me because there’s more leverage out of it. There's also an element of when there's a problem, what are the stakes if we get it wrong? How hard is it to reverse our decision? If it's high stakes, then I should probably be more involved. If it's low stakes, then I don't need to be involved. Also, the people come into play too.
It's a great opportunity for me to work closely with various engineers on the different teams and I can learn from them, they can learn from me. We can establish those personal relationships as well as make each other better.Depending on the problem and the team involved, sometimes the best thing that you can do is not actually get very deeply involved. You've got a great team of
people working on it, they're well staffed and just get out of their way. Let them do their thing and yes, you should be checking in periodically and providing feedback at the appropriate times. But as tempting as it may be, you can't inject yourself in every really interesting problem nor should you.
Adam Ferrari: Yes, the long view. You have to have the long view. So actually, speaking of, you hit on some hallmarks of the problems you go after, like longer time scale, value orientation, and sort of multiplier benefit, like what are the big swings. So I don't think we could possibly have a conversation like this without talking about the impact of AI on software engineering.
I'm curious, that's, that is you. mean, it's all anybody talks about pretty much anymore. I can't believe we made it this far in this conversation and we haven't talked about it. It's kind of crazy. I'm curious as to what, your take is on that and like, and also what you're doing, like, like what's, what's, what actions are, are you taking there at Salsify on this?
Joel Turkel: Yeah, there's two parts on AI that I've been involved in. One is using AI internally to make ourselves more efficient and the other is figuring out how to deliver AI-powered features for Salsify.
Adam Ferrari: Yeah, being in content, it's super relevant. Like AI has, I think, a lot to offer there for sure.
Joel Turkel: Yeah, so on the DevTools front, we've rolled out GitHub Copilot to everybody. We're trialing different tools like Cursor too as alternatives to that. Also, we made Gemini available to the entire company. We're really doing a lot of experimentation and trying to get engineers the right tools and , but not mandating it. Engineers are incredibly smart.
They are very good at optimizing their workflow. If they think Copilot will make them more efficient, then they'll use it but if it's getting in the way of what they do and how they work, then they're not going to use it. I think that's okay. The technology is going to continue to get better and improve over time. Sometimes it makes them more efficient, sometimes it doesn't. It's an area where we're doing more experimentation too. There's a new announcement everyday about a new coding agent and that’s going to be able to just fix a GitHub issue for you. I don't think the technology is quite there in terms of being ready for prime time, but we're constantly evaluating that and trying to figure out what is it good at? What is it not good at? How can we effectively apply it to make ourselves more efficient?
Adam Ferrari: Have you personally been like doing, like, does it like, you're, you're, this like classic example, seasoned, experienced engineer completely, you know, like, you know, you don't need AI to write code, but like, I mean, at the same time, I know, I know for myself, even just doing small tasks, it's like, it's, it's kind of crazy. It's really good at predicting and like some of the agentic stuff. It's like, yeah, it's like frame me out of class and here's the state and here's the methods I want to start with. And it gets it like 80% right.
It's kind of cool. As a top level engineer how is it playing for you?
Joel Turkel: Yeah, when it works, it is magical. It's like it's reading your mind and you can give it a succinct description of what you want and it'll go and do something great. But when it doesn't work well, you're spending more time trying to coax it to do the right thing or it's popping up suggestions that are just a distraction and they're wrong. I think it's going to continue to get better and it's going to continue to improve. I think overall it is very much a net positive. I'm really excited and really bullish about the technology.
Te product stuff has been really, really fun, to be honest. We've been in the industry for a while, and we've seen these major shifts in technology with the rise of the internet, cloud-based computing, mobile. This is that happening all over again.
Adam Ferrari: Yeah. And you're doing product stuff as well.
Joel Turkel: It’s a really, really exciting time to be involved in the technology space. And a lot of the techniques that work for deterministic computing don't really apply anymore. How you assess quality is a great example of that. In, quote unquote, regular coding, you write a bunch of unit tests, you write some integration tests, and yeah, you'll have some flaky tests occasionally, but they pass orfail. It's got a very easy to understand definition of right or wrong. It's so much squishier with AI and the non-deterministic nature of it and how things that are under specified. If I've got a feature to write a marketing description, how do I assess whether it actually gave me a good marketing description for a product or a bad one?
There's this whole set of techniques around doing evals to assess the quality of AI features that we've been going deep on as we've rolled out more AI features across the platform. I've been heavily involved in that, trying to figure out what kind of infrastructure we need to support this, but also figuring out what are the best practices that we can be sharing? What do we need to push down into a golden path and package up? Also making sure that we have the right base level of infrastructure necessary to handle things like fine-tuned models and rate limiting of models. It's super fun, super exciting, and also I think it's going to unlock a tremendous amount of customer value too.
Adam Ferrari: Yeah, I can't wait to see. I mean, this is for folks watching. They probably aren't aware of the impact of Salsify in their daily lives. But like, you know, if you're on a page on Amazon and it feels better than it felt maybe five years or if you can think back like eight years, if it feels better, like a lot of that's the features that we put in the hands of manufacturers like Coca-Cola and L'Oreal Paris and, you know, 3M to do a better job with that content and get that stuff live.
It changes the experience. And so I think about the power of AI and how much better and faster it's going to be able to help do stuff like that. I can't wait to see what you guys come up with. I think we're at 10 minutes. And yeah, sorry, go ahead.
Joel Turkel: I was going to just completely agree with you that our customers, they've got a tremendous workload in terms of trying to manage these product assortments on a huge number of digital shelves out there and it is impossible to keep up with that. AI can make them so much more efficient to do that and make the platform so much more accessible, so it's really exciting.
Adam Ferrari: That's awesome. I can't thank you enough for coming on and doing this. I wish we could take three hours on this. I think we wouldn't run out of cool stuff to dive deep on, but I think hopefully that kept it to a good length. Thanks everybody for listening into this and hope to do more of these soon. Thank you.
Joel Turkel: Thanks Adam.
Share this post