Software Delivery: Getting it Right

Wade Erickson (00:00):

Welcome to another episode of Tech Leaders Unplugged. Today we're going to be getting unplugged with Joseph Shorter, CTO at Fluid Genius and a few other companies that we'll talk about in his current list of things to do. And we will be topic's going to be software delivery, get it right, and we're going to talk about, see software development teams, team management, and especially in this remote world we have of remote working. It can be particularly a challenge to bring software development teams together. And we've, we're a couple years in and I think things are getting smoothed out, but we'll have Joseph share a little bit of his, his experience in, in working with distributed teams and and trying to get delivery and keeping productivity up. So thank you very much Joseph for showing up today with us. Appreciate your time and your experience that you'll share with the, the team here. Let's talk a little bit about your background and then a little bit companies that we'll be talking about today that you work with.

Joseph Shorter (01:20):

Sure. So, hello everyone, Joseph Shorter. I started, I taught myself software. I started teaching myself how to code at age of 11, and that's what kicked off my love of, Hey, this is really cool. I can tell the computer to do a thing and it'll just do it. So that started my journey. I am a software engineer, software developer by trade. And my career has been along that path for quite a bit of time. And then I got into doing large, large implementations for Fortune 500 companies. When I joined PricewaterhouseCoopers the consulting side, I was there for the first eight to nine years as a senior engineer. And then I switched and started doing management consulting and leading, implementing large systems with big, big, big teams across industry types of things, from healthcare to logistics to travel and airline. Just a lot of topics. So that's how why ended up getting here through, through cons. At that time, I didn't want to travel as much as it was. I decided to find something a little taking me away from my family. And I ended up a digital turbine four years ago. And at Digital Turbine, I came on as the, the enterprise architect and the VP of Platform Architecture. I, while, while there I did a few things, I, but what's important is I had under me a couple of different departments that's not typical of the role description. One was I took on product owners under me. I took on data engineering and security. So I was, I was responsible for a pretty large portion of the technology organization for a time there. But now I am the CTO of Phil Genius. We are a digital publishing company, and I do that with my, my, my wonderful wife that we're kind of relaunching now. So that's, that's a kind of a quick, quick go of, of my background there.

Wade Erickson (03:44):

Great. Great. So let's talk a little bit about the, the topic in hand software delivery getting it right. And obviously this is a very broad topic. There's so many aspects to that can go wrong, when you're trying to release software, whether it's technical aspects or identifying good resources, all kinds of things that can cause a projects to have delays and, you know, very, very high percentage of projects do struggle to meet their financial goals and, and quality goals and, and meet scope. So tell me a little bit about your thoughts in this area and yeah.

Joseph Shorter (04:24):

Yeah. So, so I want to, this is a topic that, that's near under to me. As a, as a software engineer and someone who has played almost every role in the delivery process throughout my career what I have noticed is that it's not done right quite often, more often than not. And when you are on a high performing team, it seems to be very exceptional. And, and in today's world, you can't be a company that doesn't rely on some type of software platform that either you build or sell yourself, or you at least rely on to run your organization. So this, this has become more and more important, and especially in the world of artificial intelligence and machine learning and everyone wanting to figure out how can we make the machine code for us? 'cause would that be better? All of this is more relevant than it probably has ever been. So what are my thoughts? I have to lay a bit of foundational context here. So again, I told you how I became an engineer, what sparked my, my journey. But I, I, there are two words that I often use software engineer and software developer, and they're used interchangeably these days because I don't think it really started off as an engineering per with an engineering perspective. You know, back in the day when everyone decided, Hey, I can be do software development. I don't have to go to school. I can earn great money, I can just jump in and if I can figure out how to do this thing, it's awesome, right? But there's a lot, when you think about engineering, you think about very strict outcomes. It, there, there's, there's a lot of rules. You know, precisely what you're doing, precisely what the outcome should be. And if you don't have it, you don't hit those outcomes. The engineering failed, not necessarily has been the case in software development. There's a bit of art that has been injected in it, and because of the art, there's been also a bit of chaos. How do we do it right? How do we, how do we take a feature description from the business of, from the product and actually give them what they ask for? How do you even translate that we even know, or they know what they're asking for. All of these complications begin to, to seep into this, this, this this industry that we all love and affect the outcome of the features that we build. And so, so that's what's, that's what I want to talk about those foundations, why it's important. Hopefully you understand now a little bit more why it's important to get it right. Because everything we do today basically relies on software. So it's more important now for business outcomes, profitability, quite frankly, safety that we start to get this, we, we do better at this,

Wade Erickson (07:14):

Right. And so I, what I'm hearing here is the I come from a mechanical engineering background, so quite different, but then I moved into software 25 years ago or so. So you know, within the physical realm of creating things, that's why engineering, whether it be civil engineering, electrical engineering, all of these things often include safety. And so that being first and foremost when you build products and then secondly, the science that goes behind that. Originally, you know, engineering was really the, that as a practice is really applying science to solve, you know, problems for mankind, right? And that's really what the tie in is for engineering. And if you just jump into software development, although it's a great need and a skillset there is a piece of rigor to the engineering for the safety aspects. And I think, you know oftentimes you'll have civil engineering projects where you have a few professional engineers, but you have many other engineers that never took that extra exam, right? So there is that kind of scenario as well in the physical world of creation. And when you're, of course, cutting metal and making things, there can be scrap in the, you know, the corner of the room where the garbage and the screw up was. And in the intangible with the software, you don't have quite that same physical scrap pile when you screw up. So I've, you know, I just bring that in to the context that, that, 'cause I played in the physical world for a long time. Yeah. And when I moved to the civil software world, I was like, Hey, where's the idea of defects and scrap? There just isn't. But in the physical world, it's a huge problem. I mean, when you're running stuff off the assembly line and you missed some parameters, quality assurance parameters, you got to melt all that stuff down if you can't even do that, you know, so.

Joseph Shorter (09:06):

Right. Anyway, so, well, it's, it's funny, it's funny. Wait, it's actually funny because that's changed now, right? Think about self-driving cars. Think about the, how, how software operates our physical world now more than it has ever done. So, so now to your, to your point right? That the quality aspects of the software that we build are much, much more important. They, they literally, it's the software that now operates the door on a airplane particularly potentially, right? It's the software in, in your, in the, the Tesla or the other EV that you're driving that does a lot of scanning around and, and under and applying brakes automatically for you, or speeding up a car or changing lanes based on software. Sure, it uses instruments, but the software is in control. So the quality of the stuff that we build is so much more important than it used to be, because, you know, you, you say, well, you know, it's not rocket science. No one's going to die if I mess up this piece of code. Well, not necessarily true anymore. So that, that's why I say this is important. And there's a lot of organizations that don't, that, that haven't gotten the understanding that software building, high performing engineering teams is as tied to what is the culture of software delivery in their organization as much as the quality of the output that comes. Meaning, if you are a, if you're a company that happens to be lucky enough to get all the best engineers in the world together, and they just are just awesome, they don't make many mistakes. Every company, every executive in a company wants that company to out outlive them. So how do you replace that talent? How does, how do you recreate that type of proficiency, that type of skill and leadership and, and delivering software that's going to continue building the products of the future for your organization? It's the culture. And the culture has to be a culture that is zeroed in on, we're following the best practice of software. We have actual metrics that we produce, that we measure to say we're doing good or we're not doing good. There's a lot of you know, and I, it's interesting because a lot of startups will say, well, we just need to get the thing out there. We don't need to do as much testing. It's not as important exact, except for when do you ever get the chance to actually do it the way you would do it if you were an engineer? cause You're rapidly growing. So that's just a lack of planning. It's not that the software cycle, the delivery cycle is too slow for what the business cycle. It's, it's the lack of planning. You need to think about what are you building and if, and, and what you put out, is it going to perform the things that you actually want it to do? And no more, because it becomes more and more important, especially as the pace goes faster. If you don't have that culture, if you don't have that mindset from the beginning, it's extremely hard to get it later. So anyway, take a pause.

Wade Erickson (12:10):

Definitely agree. Definitely agree. Well, let's move into some questions around some of this development process. And I get, get your thoughts around this. So you know, how do you prioritize the, the features? So that's obviously early in the development process you know, with you know, product roadmaps cut, cx, cx, all of those kinds of things that figure in, you know, what factors play a cr crucial role in your decision making process that helps drive that team?

Joseph Shorter (12:42):

Sure. So there's this concept of we want to be a product led organization for people who are producing product. There's, there's essentially two opposite poles of thinking here. Well, I shouldn't say of thinking of, of where priorities come from. One is, you built a platform that platform must be maintained. It it, it is, it is because as the business, every day the business exists, the software oftentimes has new requirements that were never designed in initially. So you have to maintain, you have to ensure that the technical fit of the thing that you built last year, two years or purchase from a merger, is it, is it a good technical fit if, is it part of a critical system that actually runs your business? Because if that critical system goes down or it's problematic, what does that do to your business? How much does it hurt you? Right? So there's this, there's this idea of, of priorities have to come from maintaining the platform and ensuring that it is actually performing, it's scalable, it's doing all the things we expect to do until in, in terms of su supporting our business. And then there's the product side where if you have customers out there that rely on your product you should be a an expert in the industry of the thing you sell. You should know what features your end users, your stakeholders want before they know to ask for them. Because if you don't, basically you're failing your company in a, in a pretty big way because you should know the product, you should know the industry in ways to, to, to get, gain that knowledge and become more of an expert is to build like a cl a customer advisory board where you're seeking that input constantly and getting ahead of the co the, the curve. Understanding what emerging tech is out there that could complement what you do so that you can be ahead of the curve and say, I, my, my, our company, our platform is superior. It, it's, it's desire because we really focus on what works, what the users want and, and, and, and the outcomes that we expect are the outcomes, outcomes that we actually get. We outperform what, where our own expectations. So I know that was a very long answer, but hopefully that answered your question.

Wade Erickson (14:58):

Yeah. And, and so, you know, I know we talked about, you know, products that are actually released from a company to a customer base, but a, you know, huge portion of the software that's built is never sees a customer base. It's internal apps. Exactly. And, you know, maybe talk a little bit about your experience of the attention or lack thereof of those early phases in building software for your internal employees to use.

Joseph Shorter (15:27):

That's a good that I'm, I'm glad you mentioned that because that is, to your point, often neglected. We build crappy user interfaces. We just focus on does it function or not. And when it, I, we, we, you have, I think everybody who's listening to this, yourself included, you've met that employee of a company that works on a spread this very, very complicated spreadsheet because they had to export data from all these systems to get functionality that did not exist Yep. For them to operate. And they become a critical resource that because they know, have all the knowledge and to make the, the cogs in the wheel continue to go, right? That that is a symptom that you're probably not paying a lot of attention to your internal platforms. You should treat them the same way, with the same rigor around are you happy? And the, the real point here is, is that, are you asking your stakeholders at all? Does it work? Are they happy with it? Are there features they would want? Again all of this culture that I'm talking about, this excellence toward, I'm going to build a thing and I'm expected to perform the way I built it. There's a, there should be a pride in, in doing that. And that pride should lead you to say, I want to make sure everything I produce the person using it, consuming that is getting the best experience outta it, whether it's internal, external, because oftentimes those internal systems are just as critical in operating your organization as a product is to be sold. So you can't ignore it. And, and oftentimes that's exactly what happened. So I'm glad you brought that up.

Wade Erickson (17:05):

Right, right. And that's been, I I've built a lot more systems for internal business use than external customer facing and platforms, although I've built both. They've I've found that, you know, when I've usually come in, I worked for Accenture for many, many years. So much like you managed services, consulting services, you come in to enterprises. I think I had a hundred applications that I was managing, and they were every kind of application for the last really 30 years and had to keep them maintained ad functionality where we could. And it was clear that the UIs just weren't given the same attention that, 'cause there's not a G two or some other site for people to complain, you know, or Yelp to complain when it's an internal app. You know, it's just people just, you know, curse under their breath about, you know, the application not doing it or being slow or all those things. And yeah, it's an unfortunate part of sometimes the way things are built. All right. So can you share a little more insights about the team handles challenges about scalability? A lot of the platforms we built, they're built with a certain size in mind, and if they become very successful, you can't just always throw hardware at it. So tell me a little bit about scalability and some of the platform decisions you've had to make over, over the years.

Joseph Shorter (18:25):

Sorry. That is a great question because that brings in another aspect of software delivery that oftentimes organizations don't see the importance of, they feel like it's built into the engineering discipline and it's not. And what I'm talking about is architecture, and oftentimes enterprise architecture, the reason why I'm saying enterprise architecture is because the goal of enterprise architecture is to understand the objective, the strategic objectives of the company, and turn those and connect those strategic objectives into what are the long-term architectures required to support the technology that we're going to build to meet those objectives. So we have to build tactical execution plans to get there, right. Oftentimes interim architectures along the way to that path. But the point here is that all of those, when you think that way, you're thinking about, wow, not just the scalability today, but I based what I, my architecture on the five-year roadmap of the plan of the north star of the company has, what are we trying to achieve? I need to ensure that my architecture, the scalability, all those things can be, can be at least refactored easily to get there if not needed right now. Right. You have to think through those processes. And the reason why the architecture point is, is really important is because as an engineer, I'm not as, I'm not concerned about the future. I'm concerned about today, I'm concerned about the scalability today. I'm concerned about creating the feature that I was asked to create on time. And, and hopefully perform it the way that it's expected to perform today. Because they don't they there, there's just not a lot of time on your plate to think about anything else when you can get it. You have probably a senior engineer as a technology a kind of a technology architect as your senior engineer, and that's great that they can build some of that in. But that's, that again, should be done on purpose. It shouldn't be done by accident. So that's how you build for scalability in the future. Also, the architecture of your systems should be changeable and modular in a way that if you need to scale a part of your platform, it doesn't require that you have to scale everything at the same time. Right. That you can attack those things in, in a autonomous way, so to speak.

Wade Erickson (20:52):

Right, right. And then, you know, to the architecture, you know, that's obviously the growth of the microservices architectures over the kind of the more monolithic service oriented stuff where you're, you know, maybe have a lot less interfaces, but more complex, those become much more harder to scale from a performance standpoint, obviously.

Joseph Shorter (21:12):

Yeah So, sorry, go ahead. Go ahead.

Wade Erickson (21:15):

I was just going to say, so, you know, for, for architecture that's critical in the scalability part, so I'm glad you brought up the enterprise architecture piece. Okay. So we talked a little bit about teams and cultures in, in this you know, post covid world we live in, I think a lot of companies experienced remote teams at huge amounts for the first time in the Covid era. You know, I've been dealing with offshore teams for 20 plus years when India started to kind of build out that capability. I think that was around late nineties for me. And so, you know, I wanted to, you know, see how you've been, you know, working with the cross-functional collaboration of teams and trying to work that cultural aspect, especially with geographic, you know, geographically as teams. You, you're bringing in cultures from, you know, Asia, you know Europe, Eastern Europe, Latin America. You know, it's very common now to have five or six cultural regions of the world that are very different on how they respond and talk to each other and communicate you know, things that need to improve. And sometimes, you know, tell me a little bit about how you tried to work a common culture across those geographically dispersed teams.

Joseph Shorter (22:35):

Sure. So this is less of a technology problem and more of just a general management thing, leadership problem. And it's a problem because just again, for setting context, it's, it's, it becomes a problem mostly because managers are not great at managing people. We're, man, we're good at managing projects and hopefully deadlines, people not so much. So we don't on purpose talk to them. We don't on purpose build this collaboration. So I believe collaboration should be on purpose. We should schedule it. It shouldn't be just assumed it will happen. So you take light disciplines, you put 'em together, you have them purposely meet on a regular basis to talk about what are you doing, what am I doing? What are cool things to share? So, because that, that's the point of commonality across cultures no matter where you live or the thing that I'm actually interested in and I can talk about. So that's one way to connect different cultures into we're doing software delivery, so let's talk about this thing. We're you're Java engineer, developer, let's talk about the Java. Right? So those, so first build those, build those things on common respect the times, right? Because oftentimes you're in different time zones. So you got to find a way to work around and be, and share the load. You can't be, say everyone has to walk, work on you as temp all the time. What you'll find is that that causes a strain for others. And, and it, and it doesn't, doesn't even feel right to them. So we have, you have to figure out how to create a balance there. But again, the, the, the other thing is understand what I, one of the things I learned, 'cause I also had to work with some of the same, all the same regions that you talked about on my teams all at the same time. What I, what I had to learn was that if you, if if my engineer is in India, they have a different approach to their career than, say if it's in, if the engineers in China, China or in Argentina or in in the European Union somewhere, right? So understand what my, what, what, what are they, are they here to be an engineer? Are they just happen to be good because they want to go do something else? And I'm, I'm only going to have this much time, so I, I need to figure out how to maximize that time. Are they the type of engineers that say, if you tell me to do a thing, you got to gimme very explicit directions on exactly what you want, because I'm not going to put a lot of imagination into it. As a manager, as a, as a, as a, as a manager, you need to understand that for every person that works for you so that you can effectively manage the outcomes of the things that you're asking them to get done. Does that help? Does that make sense?

Wade Erickson (25:27):

Yes, yes. Great points. Yeah. And yeah, I, I agree with all that. You know, the, not only the cultural aspects, but even within those cultures, there's, you know, individual aspects and, you know, if you've had more than one kid, you, you know that every kid in your family's different. And, and they do. Sometimes they require different, not that I'm trying to equate software developers to kids, but it is a very, you know, emotional tie that that we have to have that we can actually extend those experiences into the workplace and understand and appreciate the differences and, and, and, and actually use them synergistically to where some people are more specific in their outputs and others want to be more creative. In fact, they don't want to be told what to do, you can't apply the same thing. And you got to understand each of those work elements. Alright. So I wanted to take a quick pivot away. Like, I like to talk about a personal journey of each of my guests. You know, when I noticed as I was going through your resume and we've been talking very technical about software development, I noticed that you pivoted away. We talked about your digital media product, you know, tell me a little bit about, you know, I mean obviously you do this with your wife so there was that aspect, but tell me a little bit about what is in the digital media world that really kind of drew you to, to spend time over there. And I know the other company, the digital turbine companies about ads, so it's still a little bit more on the, you know, media and advertising side as well. Tell me a little bit about that shift away from the hardcore stuff at pwc.

Joseph Shorter (27:09):

Yeah, sure. So if you ever take, taken, taken one of those personality tests like the Myers Brigg, it'll tell you what type of personality are you usually contained two, right? Or they'll tell you, you are more logical and or, or this much logical, this much creative. For me, I'm, I'm literally 50-50, right? So I've always been that way. And which what I mean by that is I'm a painter, I'm an artist, I'm an author of a book. And it's always been a part of things I also like to do, right? The reason why I like, liked software engineering is cause I got to create thing, a thing that people thought was valuable and used. It's the same way with digital media or art. I get to create something that people appreciate on the other side, and it gives me, it makes me have a self value and worth for that and seeing that. So how did we, how did that whole thing start? It's actually been there for a while. In fact, my wife she's a dancer and, and when we started moving around doing consulting a lot, she had to close her dance studio down and she wanted to not lose ties to dance and fitness. So we created digital publication, it became global. She got to meet some really cool people from the fashion industry, the entertainment industry actors. And, and it was a great way for her to build a brand around those specific spaces. Since we had come to Austin four years ago, we kind of shut all that down. My wife's, we spent more focus on our kids as they were getting older and things like that. And now we were like, you know what? There's, there's, there's a need here that we could see this, this platform, what we do has a lot of different use cases. We like producing creative content, so let's go do it in earnest. At the end of the day, you know, I work for my wife and, and you know, cousins out there, you know exactly what I mean. It's a hard job. But it's also fulfilling. And it doesn't take up all my time. So, so is it is the full-time thing I'm doing? No, you can also see I volunteer as a CTO of Veterans Matters, a nonprofit organization. And, but for now we are going to, we're going to launch this, we're launching this business now we're going to scale it and see, you know, how far can we take it and see if I really want to get back into the hardcore stuff. And I kind of haven't left that either. So just for clarity, I just passed my cloud, Google Cloud Architect exam. I am now doing studies in artificial intelligence and machine learning. I actually have, I'm a part of the UT program, the six month immersive program for doing that. So I haven't left the technology world cause I, it's, it's as much of a love to me there as it is art and, and things that are creative. But yeah, hopefully that answered that question.

Wade Erickson (30:10):

Yeah. You know, I think I would probably fall in line very much with the way You exam did that came, you know, out to California originally for music and came across you know, web programming in 1995. It was all by hand, couldn't even play an audio file in a browser at the time. But as a musician producing artists and fighting the music industry to get people produced and signed the labels and stuff, I basically shifted out, you know, of the traditional music industry and put all my passion into technology for the arts. And it is a it, well we all know how the music industry and the effects of the internet to that went, it completely restructured the whole distribution and delivery and marketing of music. And so but yeah, that's the thing, you know, when you're an artist you never lose that. And when you can apply the two and become that much more efficient and diversified I think it's just more satisfying as well for both sides, right?

Joseph Shorter (31:15):

Yes. Yeah, absolutely.

Wade Erickson (31:17):

Alright, so I think we're getting at the top of the hour here. Thank you for your time. I wanted to just announce that next week's guest is Lane Campbell, principal of GovSoft topic's going to be AI enhancement. Coming to the DMV, we all want to have the DMV get a little bit faster. So we're going to talk a little bit about how we can apply software particularly into that space. Alright, thanks again, Joseph, for great conversation. I always love talking tech and software development, always learning something new and appreciate your time. Definitely.

Joseph Shorter (31:52):

So thank you so much Wade. I appreciate being on look forward to maybe we'll, we'll pick another topic next time. I have plenty to talk about.

Wade Erickson (32:00):

Right. And I'm just up in the Dallas area, so maybe I'll just swing down there to Austin and see what you got going on down there too.

Joseph Shorter (32:06):

That'd be awesome.

Wade Erickson (32:07):

There's always some good bands playing there on sixth Street, you know. Okay. Have a great day and we'll talk soon, everybody next week.