E-commerce Innovations, and Decision Engines with Andrew Guldman of Fluid

Transcript

Ledge: Andrew, great to have you, man! Thanks for joining us.

Andrew: Thanks, Ledge. It’s good to be here.

Ledge: Can you give your two- or three-minute story ─ you, your work, and what you’re doing and where you came from?

Andrew: Sure, absolutely! I’m leading the development of Fluid Configure online product configuration platform right now. The idea is that we take these product definitions which consists of the data that sits behind the configurator as well as the imagery associated with it and have a platform based on it that allows the quick iteration and implementation of a wide variety of different online configurators.

For example, we work with Oakley doing glasses. We work with Fender doing guitars and Louis Vuitton for luxury goods. It’s a platform, so the underlying code is basically the same; and then, the implementations provide the differences in just the details: the look and feel, the branding, and the way it’s all presented.

Ledge: So there’s got to be hundreds of different types of variables that you need to pull together, like metadata, for any given type of product that has many different dimensions: a different pair of glasses. Is that all built in like a big metadata engine?

Andrew: Exactly! As you’ve said, it is quite encompassing and complex. There’s the surface level. As you’ve said, if you’re configuring a guitar, it’s like the color, the material, the body, the tuning pegs have different options; the pickups have different options ─ things like that that are specific to a guitar.

For glasses, you’ve got different frame colors and different lenses and different types of lenses and so on.

That’s at the surface level but, then, there are also these configuration interdependencies. Some of these are based on many factory constraints; some of these are brand specific.

For example, if Oakley didn’t want to you to be able to put the little Oakley logo on the side and make it the same color as the frame because they want it to pop a little more, you have to build that kind of logic into the configurator to say, “The choice you make here constrains the choice you can make there.”

Ledge: There’s a big decision engine as well. What does the technology look like in solving a problem like that?

I know that you have done that over the course of a number of years. Technically, there’s probably some kind of evolution and sort of legacy up to modern standards.

Take me through the story there.

Andrew: You’re absolutely right. This technology has evolved a ton. It started out in Flash back in the day; this is going back over ten years. And then, Flash fell out of fashion at the same time that HTML was getting more capable than JavaSpirit, so we moved from Flash frontend into a React-based frontend.

Similarly, the back-end technology that we used to manage the metadata ─ we started out using Flex for that partially because we were tied into Flash on the frontend and Flex on the backend. And the urgency to change that has been a little lower but we are also moving that over to React as well.

The server technology on the runtime part, the consumer-facing piece, is written in Node; and for the metadata management, it’s written in Java. The ORM capabilities of Java using things like Hibernate ─ I cannot really predispose to using Java so much but just the JPA and Hibernate still make Java a great choice for thread-type backends.

Ledge: Are you guys all cloud now?

Andrew: Yes. We’ve been on the cloud for years. We’ve worked primarily with Amazon; and that’s been awesome. We’ve had really great experiences.

Going back several years, we had been working with Chef and CloudFormation tied into AWS. As I’ve said, it’s been great.

In recent years, just in the last few years, we had started to move into the Docker and Kubernetes worlds allowing for more efficient use of our resources. Being able to have sort of lighter-weight microservices and kind of existing in this cluster environment give us more flexibility and the scale of our deployments more efficiency and also faster boot-up time so no horizontally scaling.

When we were in this old Chef world, you’d detect and hit the wheel. Five minutes later, you’ve got it but, in the meantime, you’re application stack has been struggling.

With Docker, it’s just faster. The process of adding nodes is simpler than the process of provisioning a server used to be. And, in many cases, you can add new pods without even having bad nodes which is dramatically faster.

Ledge: Off-mike, we were talking about how your near-shore teams in Argentina; you’ve got U.S. teams. And you’re in the microservices type of pattern which tells me that you have to organize in some ways, at least, your dev teams around different services.

So, obviously, you have a DevOps infrastructure that’s important there and, I’m guessing, some of, at least, CI, if not, CD. What does that look like and how you do organize across the multi-location teams?

Andrew: This part is awesome. The vision is really that we have this infrastructure setup and anybody can work on any part of it as needed. We’ve seen numerous advantages of that approach like one person leads the organization; you’re not screwed.

Whereas if you divide it up and get people more specialized with the team ─ we have a relatively small team right now; we’re half a dozen. We’re in the process of expanding but it’s still real small. And so, making a deliberate investment in people being able to work on different parts of the system is good for the organization, as I was saying.

I also prefer to attract developers who enjoy that kind of thing, people who thrive with learning new technologies. I think it does wonders for the culture of the organization creating a culture of innovation.

Innovation takes some kind of this microlevel on the individual developer level like, “Alright, man, today, you’ve got to learn Kubernetes.”

That’s innovation even though it’s been done many times. But for that person having to get their head wrapped around it requires that same of expansion of knowledge.

And so, getting your team working that way on a daily basis creates an awesome culture.

Ledge: So you’re really pushing the skills out sort of in the T-shaped employee. I imagine, they’re deep in something but they’re wide in many.

Did you have any issues selling out of the chain?

I don’t know what your leadership structure looks like but, sometimes, there’s this idea of “Hey, it’s very expensive to learn on the job. Specialization is cheaper.” How does that fit into a cultural and budgeting standpoint?

Andrew: That is not about what I had trouble with. I think part of it is that I’ve been in this leadership position at the organization I’m at for years and years and developed a pretty high level of trust; that’s, more than anything, what it is.

But I think they also kind of understand the risks associated with having I’s instead of T’s. And we’ve been burned over the years by that despite our best efforts. Sometimes, there are people who are really indispensable to the organization.

We’ve had a couple of situations where those folks have left abruptly. I think the T is pretty well understood, the advantages of that approach.

Ledge: That’s great. I talk to a lot of leaders especially in not as mature organizations where they’re trying to really stretch that budget and demonstrate “Hey, we should allocate 20% of our time to making sure that there’s redundancy and making sure that people are cross-trained instead of just hammering around on this backlog over and over again and more features and more features and more features and no focus on either the training or education or on the technical debt implications of going that fast; and that budget management is really what starts to take shape as an organization matures.”

Can you remember back to the old days where some of that was more prescient because I think that does seem to happen but it happens at a certain maturity level?

Andrew: The older days were more of kind of an agency model where things were a little more project based; and even when we were working on software as a service platform-type stuff, we still had kind of inherited the agency mindset and that just gets awfully painful. You tend to fall into the hero pattern too easily which plays directly against the kind of T distribution. It just makes that problem worse.

You’ve got a couple of heroes, and heroes get burnt out predictably; and you kick the can down the road a little bit but you still have the same problem.

Ledge: And that happens to every startup when they’re newer. We think of it as an agency mindset if you’ve been in that world. That’s really happening with every new founder-based plus one other guy. That happens and learning how to that work and become wiser about the utilization of your key players is a real maturity point for a lot of organizations.

I ask everybody this question. We’re in the business of evaluating and bringing on the absolute best sort of A-plus unicorn, super senior ─ whatever you want to call them ─ software engineers. And we have a pretty rigorous rubric for doing that in the heuristics that we use.

I like to ask all the tech leaders we have on the podcast, “How do you evaluate all the world of senior engineers that you could bring on? How do you know the best ones? How do you measure that so that you pick the right people?

Andrew: For me, the way that I try to look at it is there are elements of the work of a developer that are easier to train and there are elements that are very difficult to train.

So the characteristics that are the most important to me are people who just, first of all, have the ability to code well. It’s more of like a logical approach. You can toss them a funky problem and they’ll break it down quickly in the course of an interview, in real time, and make it simple.

Their brain simplifies complex problems. That doesn’t seem like something to teach. That’s probably the single most important thing. You can give them like a database modeling exercise ─ more old school ─ or you can give them an astronomy exercise, whatever it is. You just give them a complex thing and ask them to write it down.

I think the next most important thing is a combination of a thirst for learning like they just really want to get more knowledge combined with a social sense of that ─ people who can give feedback in a constructive way and receive constructive feedback.

There’s been a handful of developers I’ve worked with over the years who are truly brilliant and who were worth the trouble, most of the time, but they failed to ascend through that tier of truly superb engineers because it was just like, “Man, it was like this awesome race car that keeps breaking down.”

And the care and feeding was kind of onerous.

But if you can find people with that kind of horsepower who are also ─ they don’t have to be going out to the party but they have to be able to interact constructively and professionally.

You get that combo. I don’t care if they’re fresh out of college. I don’t care if they have any work experience. I don’t care if they’re working on a different technology. All that stuff is like a piece of cake to get people up to speed.

Ledge: That’s really a great summation. We hear a lot about problem solving. We hear a lot about communication abilities. I love how you just put that. I may go back and take notes from that one.

Andrew, I appreciate having you here. Anything you want everybody to know about Fluid? Make sure that you get a little plugin for the company.

Andrew: Thank you. Fluid is doing really groundbreaking work with both our agency work. Actually, before we talk about Fluid, I should say that Fluid is now a part of Astound Commerce.

Astound Commerce is a company that’s been on for a long time. They’ve really mastered the offshore model of gaining more leverage and more throughput. Now, we’re combining kind of the design and strategic expertise of Fluid into the scale of Astound. It’s been really exciting to be a part of that.

And in Fluid Configure, in particular, we’re in that same position where we’re now in this incubator with this infrastructure that’s Astound where they have development offices in Colombia and Ukraine. So all the kinds of things we were just talking about which is super exciting.

On top of all that is this fertile ground for development and we’ve got an awesome client list. I already mentioned Oakley, Fender, and Louis Vuitton; the list goes on and on.

It’s really an exciting time to be part of Astound, the merger with Fluid.

Ledge: Cool! It’s good to hear about that. It’s good to have you on. Best of luck with that big client list and new product. I appreciate the connection.

Andrew: Thanks, Ledge. It’s a pleasure talking with you.