Podcast: Brett Sanders on Platform Development and Evolving Technology

 

Highlights from the Conversation

On this episode we’re going to get a little geeky and talk about platform development.

Brett Sanders has been leading the platform development team here at Requis since the beginning. He wrote the first line of code for Requis. He has many years of experience with software engineering and development.

We’re going to discuss the role of platforms and how they relate to supply chains.

So, in keeping with tradition I always like to ask, Brett Sanders, who are you? How did you get into coding and how did that lead you to platform development?

• I’ve been around technology since I was young. My grandfather was a software engineer since the 1950s and my uncle is in information technology (IT). So I heard a lot about technology through them. Then my brother got into IT in the late 1990s.
• I was exposed to Ruby on Rails and became proficient enough to be able to recognize the differences between the different versions.
• In high school I took a coding course in Visual Basic. It was before the time of the modern Internet. It wasn’t at all like how coding is today.
• Once the Internet really took off and you started to get into synergistic effects with platforms, it became a totally different world. It’s not really about the software, it’s more about the ability to unlock value.
• In the early 2000s I got into some Flash development. At the time everybody thought that Flash was going to take over the world. Clearly that didn’t prove to be true.
• The way I really got into tech was by initiating my own startup. If you want to get into tech most people will tell you to go and do something real.
• My background is in music and I wanted to create a startup based around music gear. That’s when I got serious and decided that I needed to really learn how to code, and then how to build something real.

You aren’t the first musician that I’ve met who is also a coder—is there some kind of connection between coding and music? What’s your take on this?

• I think there is a connection and people have asked me about that before. I got into music through writing. I didn’t get into music for music, I got into it to express ideas, to tell stories.
• There are structures in music. Once you learn the structures you can then express yourself in different ways with different structures.
• There is also a dimension of that in coding. After you get past the basics, like syntax, you can start to see certain patterns emerge. For example, the data layer versus the presentation layer.
• Music is similar in that there is music theory, and once you grasp the rules, and begin to see the patterns, you’re free to manipulate them and build things.
• This ties into platforms. When we talk about product management and development… I think about these things as tools. And that’s because there are certain rules and properties.
• When I learn about something new I want to understand the essence of how it works. This ties back into music. It takes a really long time to become proficient in music. Think of the 10,000 hour rule, that says it takes 10,000 hours to master anything. This applies to coding as well. You can’t just sit back and create something powerful when you’re a beginner. Only experience will let you see the whole picture and how everything fits together to solve real world problems.

What did you expect when you first started coding almost 20 years ago and what was the reality you learned about coding when you became experienced?

• So, in music, things have been the same since about the 1600s. Music hasn’t changed much since Bach was writing. Tech, on the other hand, is a whirlwind. Things change very quickly.
• When I got into tech it was before the JavaScript frameworks took off. From that time, about 2007, until now it has been an endless flurry of change.
• Senior developers are aware of trends, similar to the fashion industry. Something new will come into popularity, dominate the scene for a time, disappear for several years, and then return in a different form.
• So when you’re learning coding it will seem like you’re learning about the best way to do something, but if you give it three years you’ll see something new. Then again in five years something new again. By the time you’re 10 years in, you’ll start to see the recurring trends.
• There’s a lot of hype that you need to be aware of, but when you’re just starting out you don’t need to worry about it.
• Most people who ask me about learning how to code are people I actually advise to stay away from it. They need to be sure that they enjoy sitting for 8 hours a day. I’m the type of person who is able to sit at a computer for long periods of time. There are tons of roles in IT and you need to play to your strengths.
• If it turns out that you are the type of person who can endure the long periods of sitting at a computer, the best way to begin your journey is to start coding actual projects as quickly as you can.

Software development has changed quite a bit in the last 20 years since you started. Not only have trends emerged in the actual programming languages used but also in the different design paradigms used to guide development.

People used to write software that would be “owned”. Now, the trend is platforms, which nobody really owns. How has your experience guided you over the years in this transition from single-owner software to platforms used by many people who don’t own the platform?

Also, how does this tie into your work on a supply chain platform?

• From my view, things haven’t changed much. What does change though is the dominance of certain companies.
• When I first got serious about tech there was a lot more competition. Larger companies would come in and subsume the smaller companies. They either integrated the smaller company into their whole, or they would just squash them. That’s something that has changed.
• Something that’s great about being a part of Requis is knowing that the supply chain is very far behind the rest of the tech industry and this gives us an opportunity to bring real change to a massive industry that needs it.
• I think my friends who are getting into software engineering would be surprised at the difference between tech and supply chain.
• If we think about supply chain, it’s still stuck in the 1990s compared to the rest of the tech industry.
• The situation with supply chain is similar to how I got into tech before Myspace and YouTube. There was no way for me to share my guitar music the way we are able to now. I sometimes wish I had been born 10 years later. I’ve written hundreds of songs. It was very hard to get your music to people back in the late 1990s. It would be so easy now.

Let’s click on that. Think about the context of writing code for a platform versus writing code for a finished product. How does this affect the design stage of development?

• That’s an interesting question. For me, it ends up in the Agile software development methodology territory. I don’t really differentiate between a modern web platform and software that is a finished product.
• I listened to the podcast you did with the guys from Maersk and that really resonated with me. You could tell that they are focused on solutions for the real world, for example, the problem of standardization.
• I take a similar stance to theirs. The platform, and how it solves real world problems like standardization, will evolve over time.
• Software can’t solve all of the obstacles. It’s only a piece of the puzzle.
• For me a lot of the challenge in developing a platform like Requis is that things look easy from 10,000 feet above, but when you get down to the details the real work begins.
• Issues like standardization isn’t something that I can solve in my role. There is no platform that can solve the riddle of standardization.
• My “get it done” attitude is what has brought me success in this field over the years. I don’t want to talk about getting it done, I want to get it done.
• This comes from my experience with initiating my startup and is critical when you’re trying to affect real change.

The mentality in the coder-world is often “let’s just jump into the deep end, get started, and figure it out later”. That is very contrary to many enterprises and their mindsets. Enterprises want to be thoughtful so they don’t make a mistake.

So there’s a contrast between what enterprises want in a platform and how you develop that platform. Can you talk about the learning curve that bridges this?

• When I joined Requis and started interacting with people who were in the enterprise mindset I didn’t understand it. I had to meet some people to get a feel for this mindset.
• In the software world I would attend meetups and meet other software engineers. You can’t build software and be a paranoid person at the same time. It’s too complicated. You can’t be overly concerned about a lot of things. It took me a while to understand this.
• We may not be able to get to the perfect solution but we are able to make sure the worst case scenario can’t happen.
• What helps with this is transparency and auditability.
• Auditability helps avoid overcomplication. If you have a trail of auditability you don’t have to worry about excessive rules and permissions, which ultimately enterprises will need to track who’s doing what on the platform.

OK. So the idea here is platform adoption by enterprises. We can mention Geoffrey Parker and Peter Evans, and others, on the work they’re doing at the Platform Strategy Institute.

Not only are we in the decade of supply chain, but also in the decade of platforms. And that means a lot to different people.

As the lead of platform development for Requis, what does it mean to you to be in the middle of its development and adoption of platforms by enterprises? Does this impact how you think and feel about what we’re doing?

• I wanted to make sure I referenced this book: Escaping the Build Trap by Melissa Perri. That book helped me articulate how I think about things. Her main point is that you need to focus on the value as well as the problem.
• If you’re going to deliver real value to companies, and solve real problems, they will use your platform.
• If you’re just keeping things at a high level and not solving real problems why would anybody want to sign up?
• Focusing on value and solving real problems is something that we do well at Requis, and we’ve become better over time.
• This ties back to the two fellows from Maersk who started Project Aviato who pointed out that many startups are only focusing on high level solutions and pretty web pages. What we need is to solve real problems.
• When you find real people with real problems it can guide you before the first line of code is written.
• I am under pressure from many different folks to overcomplicate the platform, from the UX, to the design, to the requirements, but I know when to say no.
• What helps to cut through all of this is to have a clear sense of the outcome and value.

Identification of the real problem, and articulating it clearly, is not an easy thing for many people to do. Enterprises have a tendency to overcomplicate and overengineer.

It’s the opposite in supply chain where nobody wants to get complicated.

How do you balance these two contrasting viewpoints and help the enterprise adoption of platforms? How do we get them to start using it and not waiting until it’s “done”?

• The enterprise needs to find the right people who are more collaborative and ready to get to work.
• I have a bit of a hybrid role here at Requis. I am both a part of product management and coding. To do my job I have to know both areas.
• If you want to get into my role you have to get used to saying no in different forms.
• I don’t write complicated code. To unlock the value of the platform it needs to be simple.

When people think of platforms, they think Facebook, Twitter, etc. These are consumer oriented platforms.

There seems to be some pretty big differences between enterprise platforms and consumer focused platforms. What does it mean to be a business-to-consumer platform (B2C) versus a business-to-business platform (B2B)?

• That’s been an interesting thing that we have learned over time by doing it. The main difference is the psychology of the end-user. When you’re coming into a B2B platform both sides are there to do their jobs. Whereas on a B2C platform only one side is there to do their job.
• One platform I worked on in the past was B2C and it was mostly for musicians. They created their content. The presentation layer was there to try to please the end users whereas in B2B applications the presentation layer is designed for both sides to get their work done and this must be kept in mind when designing the user experience/user interface (UX/UI).
• It’s not about making aesthetically appealing UIs. It’s about creating value by delivering a well-designed UI that improves workflow and efficiency.
• Every role in development has the potential to overcomplicate the platform, especially the UX/UI designer.
• I would go out somewhere like a coffee shop, and I would watch the business people doing their work. They mostly work in Excel, doing a lot of business data manipulation and analysis, so a lot of what B2B needs is just that.
• The goal is to empower people to do their jobs efficiently but this is challenging. It seems to be second nature for us at Requis because we’ve been doing this for a while, but I think if you’re getting into this space that there is an adjustment period.
• You can waste the time of coders by focusing on things that don’t matter like colours and button size. The user doesn’t really care about these things if they’re looking to get their work done.

Let’s expand on that a little bit. When you’re building a team of coders do you express the difference between B2C and B2B to them? Is this usually an adjustment for new coders joining the team?

I mean, you don’t want them necessarily creating shiny UI elements instead of getting them focusing on what enterprises need to get their work done efficiently.

• I would say no because for most coders who have been in the industry since about 2010, when Twitter Bootstrap came out, are already experienced with creating quality UIs.
• The problems happens when we don’t translate the requirements to their absolute essence.
• There are important differences between UI/UX and UX. I think this is an interesting topic and is especially important if you’re getting into the supply chain platform space.
• The toolkits are great for getting up to speed, but at this point, at Requis, we need to create our own UI.

I think you’ve touched on that a little bit. You’ve also spoken of UI/UX and how it applies to “consumer land” (B2C). For example, B2C UI is a more mature space and has different requirements than B2B platform UI/UX.

Can you expand on what these differences between B2B UI/UX and B2C UI/UX and how differences relate to us as a B2B platform?

• The one thing that we’ve encountered at Requis, and I think this would apply to other supply chain platforms, is that the user may be somebody who has been in the industry for awhile and who may not be a tech-savvy individual.
• An example would be the difference between somebody who grew up using websites and other applications and somebody who didn’t. People who are accustomed to YouTube, getting an Uber with their smartphones, etc., would be able to use a platform much more efficiently than somebody who didn’t grow up with these technologies.
• I’m not really fond of the term “UX” anymore since I find that the term is abused. If we think about what it means—user experience—then you have to think about who your users are.
• To use this term with its intended purpose you have to get actual users of a certain persona and go through the site with them.
• Once you do this enough you can start to see certain patterns. For example, using pretty icons versus text…

Wait, let’s not glaze over that. The use of icons versus text is an important detail. Some users may not be used to navigating a platform with icons, while others are, and this speaks to the persona using the platform.

• Yes. It’s the difference between being literal and being symbolic. Some users need to see text to navigate the platform while others are more accustomed to the symbolism of the icons.
• We also need to use very clear messages that pop up to keep the user oriented.
• We don’t need to be very sleek and clean and beautiful. Those aren’t the principles that we’re adopting, like on Etsy or Airbnb.
• There are always UI/UX aspects that are transferable to everything but if you lose sight of the UX it is very difficult to build a platform.

I’d like to expand the aperture a little bit and discuss what it means to be an enterprise platform and where enterprises are going with the usage of these platforms.

Let’s face it, enterprises are moving in the direction to use platforms to run their entire business.

Salesforce is already there in the sales and marketing group, Workday is already there in the human resources (HR) field, and other supply chain platforms are starting to move into those sectors.

What does it mean to be a platform in the enterprise space? How do you plan for integration of the platform with other platforms?

• To return to the main point made by those guys from Maersk: you first need to deliver real value.
• If it’s possible to achieve a form of standardization, we have to get there first. Then everybody will be speaking the same language.
• However, we can’t just come out of the gate with that. Open application programming interfaces (APIs) are the first step.
• What I do—and this is what I advise people to do—you need to get really good at short-term thinking. For example, what can we deliver in 3 months? Then focus on the goals for the next 1 to 3 years.
• The reason this is important is that you don’t want to make short-term, short-sighted decisions but sometimes you have no choice to do this and when this happens you should try to keep the bigger picture in mind as best you can.
• Then your short-term decisions can be made to be flexible so you can figure out where you need to go.
• We’ve had many integrations at Requis which I suspect are probably more short-term but we need to get the data so we can figure out the UX and what’s happening there. The next step would be the open API but that’s not the final step.
• The final step is making the whole ecosystem as simple as possible and that’s where standardization takes time.

So are we talking about the standardization of data? Or the standardization of something else?

• Just everything really. Let’s use Facebook as an example. Let’s say that since you were born you were storing data about your life somewhere and every family’s data was different.
• Then you wanted to move that data to Facebook but your legacy data was all over the place. This is a lot of work to convert the legacy data to something that is usable and storable by Facebook.
• Facebook had the luxury of being the standard of storing and processing people’s “life data” out of the gate. That’s why they’re so powerful. They had that standard upfront, so when people began to inject their data into it everything was already in place, and there was nobody before them.
• I think that the data needed to be standardized first.

The forcing function you’re describing is not dissimilar to when Salesforce began. Salesforce went ahead and told everybody that they were going to make it easy to get their data into the platform. That was step one.

Once the data was in the platform they could then begin to grow the platform into what it is today.

Now, the supply chain industry is today where Salesforce was all those years ago. We’re at the stage where we need to get the data into the platform, into one place. We need this step to be well underway before the platform can really begin to take off.

As challenging as it is we have to get that legacy data into the platform first.

• This is where the short-term, mid-term, and long-term thinking is really critical. For example, a short-term goal may be to integrate with a new company. Then the open APIs will come into play to ease integration.
• Enterprises, mid-sized companies, and startups will have their own priorities regarding what is needed now and what to plan for down the road.
• A startup or mid-sized company can be the accelerator of standardization since enterprises usually have their own thing going on and way more legacy data than smaller companies.

We’ve had an open API since the beginning but I don’t think that many people are even ready to use it. I think their data is so messed up on their end that they have to put it in an interim form, which 98% of the time is a comma separated value (CSV) file. We’re back to Excel…

• Yes, we came out of the gate with an open API and we realized that we had to do a lot more hand-holding and proactive collaboration with the folks at these companies and I don’t see that changing anytime soon.
• I think we are at the point where our API will start to get more use.
• Ideally, what you want to have in the long-term is standardized data. It’s one of those problems that if you brought it up to coders they may interpret data standardization as buzzwords.
• Studying how Amazon does things has really helped me. It is amazing what they have done. Their cataloging structure is very impressive.

What is it about their cataloging structure that has made them what they are today?

• From what I’ve observed there’s a site called Seller Central and a site called Vendor Central. If you want to get your products onto Amazon there’s a lot of work involved. You have to apply by category and register all of your universal product codes (UPCs). They will then send you product templates. Everything is standardized and robust. It’s very impressive and it takes a long time.
• They used CSVs with macros built in.
• You can’t just automate everything. There is a human element to it. You have to make sure that you have quality data.
• It depends on the domain and what kind of standardization is important.
• The ability to customize so people can input their specialized data is important.
• We want Requis to be the standard. Back when I first started with Requis I was in the software engineer mindset, and at that time I thought the idea of standardization was too far-fetched. As time went on I began to see that it could be possible if we spread that goal across short-term, mid-term, and long-term planning.
• Since platforms are all the buzz now I want to ask if there is anything that’s different about how you approach the development of a platform compared to what you’ve seen before?

Secondly, is there any advice you would give to people entering the platform development space?

• The first platform I developed for the music space was much less complicated than what we’re doing. The functionality required for what we’re doing is much higher.
• It makes it easier for a coder to work for a company who is developing a solution to solve one really complex problem.
• When I started at Requis I began to work on the problem of getting data out of the hypervisor (cloud platform) and it was really challenging.
• Platforms will continue to develop over time. New modules will be added over time for a long time.
• My advice for software engineers would be that they start thinking about coupling and decoupling: how are you going to have boundaries within these interacting modules over the short-term, mid-term, and long-term?
• If you come out of the gate with the amount of complexity that you would have after 5 years you will become paralyzed with how hard it is to code a large system.
• I used to go to meetups before COVID. If you’re a coder, and you’re trying to build a platform, it is really helpful to start gaining as many experiences as possible. Attend meetups that are focused on different programming languages and constantly learn new ways of doing things. This will give you a big-picture thought process.
• We need to get project managers into the right mindset to get things done quickly and efficiently.

Is there anything that you see in the future coming for the development and upscaling of platform adoption?

• We want to have a wholistic platform and so we’ve focused on coupling and decoupling. This is the ability to integrate or separate various parts of the platform into separate apps and setting boundaries as to what each module is permitted and not permitted to do, thus affecting how the modules can be coupled or decoupled.
• It is my approach to ask questions and voice my concerns right from the beginning.
• We can make our platform modular so each module can act as its own app but then we’re adding complexity. We have preferred to keep Requis wholistic.
• If Requis blows up like Amazon we’ll have some challenges down the road.

The day and age of writing discreet applications seems to be winding down. Most software these days aspires to become a platform and enterprises are not much concerned about using custom solutions anymore.

Where do you see this going?

• I think many companies who are considering moving into the platform space tend to look for a Salesforce or SAP type of platform where customization is possible.
• If we can get past the critical adoption phase, standardization becomes possible.
• What I’m curious about is regulation and compliance. I think more compliance rules and regulations will kick in the bigger we get.

Any final thoughts?

• You must be a part of an effective working group. When we need to get things done here at Requis we form a working group. Then we hit the problem hard for a few months. This focus helps us to move us forward.
• At Requis we use Trello and GitHub. We need to maintain open communication at all times to keep everybody on the same page.
• We also use a lot of video to share code. This helps to accelerate the development process since the coder can explain what they are doing in a clear way.

Connect with Brett Sanders

Brett is ready to connect on LinkedIn.