Driving digital transformation with Chief Architect at Altimetrik, Ignacio Segovia

In this episode, David is joined by Head of Product Engineering and Chief Architect at Altimetrik, Ignacio Segovia. From revolutionizing product engineering to harnessing the power of cloud technologies, Ignacio breaks down the themes of digital transformation in today's rapidly evolving landscape, and how Altimetrik fosters cultural alignment and innovation on their engineering teams.

Join as we discuss:

• How Altimetrik approaches modernization and product engineering efforts across industries including financial services, payments, and more.

• The importance of user satisfaction and how it drives technical decision-making across every architectural layer.

• Insights into building high-performance teams, including Ignacio’s hiring principles and interview questions

David Joy:

What is up everyone? And thanks for tuning in. In today's episode of The Big Ideas in App Architecture podcast I speak to Ignacio Segovia, who is the chief architect and head of product engineering at Altimetrik. Ignacio and I talk about his journey to becoming a chief architect as well as Altimetrik and the way they are approaching product engineering that focuses on driving a delightful product experience. We also get into his leadership philosophy and talk about his approach to building great teams. So pump up the volume and get ready for an intriguing and fun episode with Ignacio Segovia.

Ignacio, how are you doing today? Welcome to the Big Ideas in App Architecture podcast.

Ignacio Segovia:

Thank you so much for having me, David. It's a pleasure.

David Joy:

So we are really excited to have you here. For everybody listening in, if this is your first time chiming in or listening in on the Big Ideas podcast, we talk about big ideas in tech and some really cool things that our guests do. Today I have Ignacio who is joining us from Altimetrik, and without butchering his intro, I would let Ignacio you tell the people a little bit about yourself or tell us a little bit about your background and what you do at Altimetrik.

Ignacio Segovia:

Absolutely. Thanks, David. Yeah, so my name is Ignacio Segovia. I am Head of Product Engineering and Chief Architect for Altimetrik. I've been with the firm for about 12 years now and I've been working on very interesting projects all while very much software driven. Altimetrik is a digital engineering services company and we focus on creating very high value products and platform monetization and software monetization efforts for our clients across multiple verticals. And yeah, it's been a journey of growth. For me personally, I was born in Spain. I traveled the world quite a bit. I spent some time in France and England before I landed in the US almost two decades ago at this moment. So it feels like a significant portion of my life now, almost basically half of my life here in the US. And again, very much dedicated to growing my career in software and always been extremely engaged with new trends.

Again, I'll tell you a little bit more about my career in a little bit, but just from a personal standpoint, it's been always a passion of mine and tinkering with computers and software since I was probably 11, building some of the early software versions of Snake video game in some of the Visual Basic back in the day with a 386 or 486 computer. So really kind old school stuff and always been extremely curious about technology digital world and moving the needle forward in whatever contributions I can make there.

David Joy:

Yeah, that's awesome. It's always great to meet individuals who obviously have been in tech for a while, but especially having the experience of travel along with it, especially if you grow your tech career across multiple countries, you get to acquire some best practices that different people follow in different countries that you adopt. So I myself, I grew up in India, I did work in India, was in Europe for a bit, was in England then I was in the US. So I got to experience the way people in tech work over there and it's like amalgamation of experiences and we kind of bring that each day, that work ethic as well. So really excited to talk to you about all of that, Ignacio.

So for everyone listening, and obviously you've spent a considerable amount of your career at Altimetrik where I was actually stalking your profile on LinkedIn, you've been there for about 11 to 12 years taking multiple roles and now you're doing a very important role for the company as a chief architect/head of product engineering. Tell the people a little bit about what Altimetrik does and what are the core services and things that you guys bring to the world.

Ignacio Segovia:

Altimetrik is a leading pure play digital business and digital transformation organization. We have about 6,000 employees across the globe. We operate globally across multiple industries, financial services, payments, life sciences, pharma, automotive, consumer packaged goods and retail and e-coms. So we are quite active in the payments and financial services industry. Some of our leadership team comes from that background, PayPal, Visa and other companies as such, as well as big financial services and big banks as well. So we are heavily invested in modernizing platforms. We're a pure play product engineering shop. We can do end-to-end delivery end-to-end execution. But we also have ability to design and conceptualize new products from inception. So we do everything from product design, ideation, prototyping, we call competitive analysis or competitive design. We can also do human centric design initiatives for multiple initiatives within organizations.

And we then also execute, we actually build that software that we co-create and we co-design with our clients. We create multiple solutions across the omnichannel spectrum, all the way from consumer user experience layer. As well as we can start thinking about middleware back-end capabilities, cloud native capabilities. And as we traverse down the stack into more of infrastructure, SRE, DevOps, we also have capability centers that help out with those areas. So again, end-to-end engineering and software shop. We are growing quite rapidly. Last few years have been fantastic for us. I think we also have something called digital business methodology and digital business platform, which basically articulate a way to get business ideas and get businesses very quick revenue generators in form of software products. And sometimes we help our customers get unstuck, if that makes sense. And take them out of that bifurcation of this is business, this is IP. Well, we kind of come right through the beginning of the engagements right through the middle of those two tracks basically. So enabling businesses there.

David Joy:

Yeah, that's awesome. I like one of the things you said that you help enterprises get unstuck, because many times, and this is from even when we were first talking to each other, what I really liked about some of the things that you guys are doing is that not many companies are great at ideating and prototyping and building that early product and testing it out for the market. And some of the things that you said was your company does really well at handling that and figuring out how to get a customer unstuck. And we have an idea, we don't know how to do it. So you guys have that expertise to bring in and your team helps there. But about 12 years ago, how did you get into Altimetrik? You were doing some really interesting things, your career, what segued life took that you ended up at Altimetrik and what attracted you to some of the things that you have been able to accomplish here?

Ignacio Segovia:

Thank you for that question because sometimes I ask myself how did I end up in the position that I'm at? And I'm very privileged. I work with amazing teams globally and it's really fun. Travel the world and meet clients. We solve really interesting problems and always with software in mind and always with digital capabilities in mind. But at the end of the day, it's all human interactions that matter. So what brought me to Altimetrik, it was a little bit of a series of evolutions in my early career. I started my career, I went to school in Spain. I also went to school in England. And then when I moved to the US I went to school again because I wasn't done being at school for a few years.

So I got my major in computer science and math degree here in New Jersey. And then when I got my first job in New York City, it was for a firm that was doing trading software for Wall Street and they were doing some consulting work as well, software consulting to the side with some of the... They used to call it the media practice. So I immediately felt connected to the media. Not that I didn't enjoy the trading platforms built in C++, that was fun and it was earning my badges of honor in terms of building some subroutines in C and implementing those into class structures and C++ and other things that were fun. But at the same time, I enjoyed multimedia. I enjoyed the fact that digital medium can reach multiple channels, it takes multiple shapes in multiple forms.

So at the very beginning of my career and this particular role, I was helping companies transform from print media and you can go all the way from Hearst, [inaudible 00:09:20], Car and Driver, ELLE, all these multiple... Women's day. I believe one of the biggest things that we did was for Oprah magazine as well. And we were working in the Hearst building in New York City, and that was early days of my career, very exciting. Met a lot of really interesting people all the way from executives to media publishers to models to actors to singers. It was actually really fun because they were having us in these multiple engagements and they would bring us sometimes into a full party and software engineers were in the same floor as Martha Stewart was. It was really, really cool, really cool time, very exciting.

So yeah, I grew my career building up those platforms. A lot of Drupal at the time, WordPress implementations as well. So earned my... Again, my developer batch is there. Learned a lot of... The full stack engineering. What does it mean to build full stack capabilities? All the way from here's what you see, HTML, CSS layers as well as here's the API calls, here's how HTML interacts in the presentation layer of a website for instance. How does that portray all the way down to creating a template or blocks or whatever it's that you were doing with WordPress or Drupal and some of the other presentation solutions.

So with that experience, I moved to my next role, which was I would say very interesting innovative company working almost technically almost as a subsidiary of Apple if you will. We were building some of the subsystems for Apple's iOS, early iterations of iOS if you will. Some of the files application that you are still using today in iOS 18 were built in some of the subroutines, some things that we were doing for them. Discovering... I remember building up subroutines with Objective-C and C code that were discovering folders in a web dev environment and bringing those files and manifests and architecting that into a reconstructible file format, all with metadata. So it was really fun. It was actually really engaging.

David Joy:

Was it the early days of trying to do those kind of projects I feel, 2000.

Ignacio Segovia:

Oh, absolutely, yeah. It was early days iOS. Early days mobile development, early days Apple. Growing into something meaningful with that, with obviously the backbone of Objective-C in the backbone of macOS behind it. Back in the day it was just OS X, not macOS, right? So again, a lot of fun stuff early in my career. And then again, using the technology that this company was building to deploy a lot different capabilities for publishing sales solutions, engaging sales reps with pharmaceutical companies, for instance, would come to this company to create 3D models of molecules and model them in 3D capabilities. So we would have to tinker with 3D Studio or Adobe Solutions or 3D Macs and things like Composer, Blender. It was really awesome. A lot of different tools, incredible learning.

And then I was basically a year there and it felt like 10 years compressed into one and then Altimetrik came along. They were looking for a leader to grow their capability center in mobile development in India. It's a very young company. Altimetrik was a remainder of another company that came out of a sales source practice. They had acquired a small development shop in Uruguay, South America that only did sales force at the time, and it was a sales source implementation shop. So what we did is I joined the company with a challenge to grow the team globally, set up some teams in India, set up some teams in the US, grow the team in Uruguay, and started getting going. And one thing led to another, I started working very closely with the leadership of the company, developing the business from pretty much from scratch I would say. Meeting with clients, engaging... Again, if I had done the full-stack development journey now I was doing the business full-stack development journey.

So business development. Exactly, business development, what it means to actually develop relationships with partners and businesses and growing portfolios and landing accounts. So it was really fun. I combined those two roles quite a bit in terms of the practitioner, very much software-led leading teams, trying to get teams to adopt best practices, scaling the teams with not edge capital, teaching some lunch and learns, traveling quite a bit and spending a lot of time with the clients and as well as with the teams and co-locating with them, building software together, making sure that we were building the right things.

And again, that mobile role evolved into something a little bit more enterprise like. I call this the second draw of duty at Altimetrik, like the military where I was called up to lead some of the transformation engagements with our banking partners. So we work very closely with Bank of America and JP Morgan, some other big initiatives, PayPal, et cetera. So we did a lot of good work for them. I then transitioned my role into something a little bit more startup-oriented, where we did a lot of work for good startups. We co-create entire platforms. I called myself as a CTO for hire, almost like in a way...

David Joy:

Like a fractional CTO, but from Altimetrik?

Ignacio Segovia:

The OG fractional CTO role. Exactly.

David Joy:

Completely makes sense. Yeah. One of the things I really enjoyed when I was researching Altimetrik was like I was surprised by the kind of brands you've worked with, because for me it was new learning about the company, but you've been working with some really interesting brands. You've been, as you said, JP Morgan, you've mentioned Bank of America, but you've also worked [inaudible 00:15:05] BSFI, PayPal, Citizens Bank or Citi into it. These are brands that I experience on a day-to-day basis. You've also worked with eBay, Lululemon, and Morgan Stanley and so many more. So tell us, if you could go and open up a few things that you've done with these companies, maybe a few example, especially you mentioned the modernization story. What kind of challenges are these companies that you interact with come with, and what kind of problems have you kind of tackle for them?

Ignacio Segovia:

Industry level challenges are quite common, David. Actually, interestingly enough, there's a lot of things that we do. I say for one client that comes to us with, "Hey, I'm a big bank. I've been trying to put this product into market to talk to, let's say more of a retail kind of investor solution, self-directed retail investor solution." And interestingly enough, we come across to the next client that is looking for institutional investor solutions and they need to have a wealth management planning solution for institutional investors. Completely different subset of personas, completely different set of users. Extremely similar, what we call the inner herbal problems. What I mean by this is when we walk into enterprises, we see challenges just to pick up on BFSI, banking, insurance, financial services, challenges. They're extremely focused on the financial needs of our users. And sometimes the kind of software that they've built is built for solving for a problem, but not for a problem within a persona vertical or for a, again, small investor, retail investor, institutional investor.

They might be solving for investors. They may not be solving for small investors or retail investors. So we see that. We also see a lot of products, services requiring constant separate onboarding processes. I need to do KYC for one investor on one product because I'm a small investor. I come into money, I go to the next level of products within JP Morgan or within Morgan Stanley, within Bank of America, Merrill Lynch, and I have to do another onboarding with that. Those are challenges that we see quite a bit. So servicing two different channels with basically bifurcated experiences, that's also a problem. We also see tremendous amount of silo and siloing between these organizations. So when we walk into these kind of big solutions, big banks or big insurance companies, big payment companies, tons of siloing, some of the work that they charted over to Altimetrik and particularly to my team, is to break through those siloes and become almost like the team whisperer.

So we go across and say we'll talk to the architecture team about some of the changes they might need to make and conceiving some flexibility on their Kubernetes strategy, deployment strategies. While we talk to the UI teams and say, "Hey, you guys have a programmatic design thing?" "No, we do not. How do we solve this problem?" So we don't want to solve for too many problems at the same time, but as we solve for a business problem, we always come in with an impetus, a momentum to change the way they work. It's a huge value add for me and my team as well as for Altimetrik at large.

And the last thing that I noted, and I think we've noted this I think not just within Altimetrik, but also my observation around the industry is a lot of folks just tend to build everything. And these big corporations, they try to own it and build it and I want to run it this way and run it this way. Very opinionated software design patterns and software choices that sometimes live in an ivory tower. They may be answering to solutions and technology decisions for two years ago. Enterprise architecture teams make decisions in years or decades sometimes or at least five years at a time. What we try to do is reassess that decision and rationalize it and giving them a reason to go faster and giving them the solution to do so and actually executing on it. That's the value add that I bring to the table with the team. So that's some of the areas that we're seeing.

David Joy:

That's great. I agree with you. I have observed some of the same challenges when I've interacted with customers, but not from a product design point of view, but we have to talk about our product in the context of their modernization story or their story to the cloud. And I've observed these practices that have been in place. One of the things that I've actually seen in software design that I feel is interesting to highlight, and I learned it in my old company, was that many times in software design process, people are so driven by objective that they don't look at what the outcome needs to be. So the outcome is gone. We're like, "Oh, we want to build this button and this button should be yellow or orange color," or whatever that is for the [inaudible 00:20:09]. Nobody cares about what outcome it's driving.

And what happens is you do this entire cycle for a year and you go through testing everything and you release it, and then you realize the outcome is kind of missing. And that's where I feel like expertise from your company, consulting firms can come in to help enterprises understand what the overall objective is and how that should be driven towards an outcome. And I think that's a mess sometime in software development life cycle. Developers are so narrowly focused on, "Okay, this is my code, I can develop this, I can put this together." But they're not thinking about the bigger story. And sometimes somebody like you who's in a chief architect position as well along with product can help guide that. So tell me a little bit about that. Have you observed other funny experiences or any similar stories?

Ignacio Segovia:

Well, with all due respect to both our past and future clients, hopefully they're listening to this podcast at some point, I've seen it all, David, we have seen it all. And there really is an incredible, to be honest, both a joy and an experience that is built up over time to see some of these companies to your point, forget about the actual outcomes for the customer experience. We are incredibly focused on human centered design capabilities, customer experience above all. How do we make somebody's life better by the products that we're building with our partners and customers? And again, not everything has a UI. Not everything has a UI. Not everything is touching customer experience, but everything leads to that, or at least it should in spirit.

Even when you're building an AI app or a data pipeline, you're always thinking, okay, who is going to be the consumer of the data analytics pipeline? Who's going to be on the Tableau side of the things? Who's going to be on the ServiceNow workflow orchestration side of things or little horse orchestration side of things? There is a bunch of things that people don't think about in terms of business outcomes. And that's exactly what we do. And again, we're not a consulting firm. I really want to make that clear. We're an engineering services company and we implement, augment and make your teams better at what they're doing in digital transformation and digital platform and digital business. And digital business is a new term and relatively new. We're working with Gartner very closely to implement some of the messaging and trying to make it a little bit more of an industry driven thing that's more standardized. We're working together with some publications as well to make that known with our marketing team and other teams and our practice teams.

But back to your point, David, I think it's important to remember we build software for our clients and our clients, meaning are big banks for Fortune 500 or startups of the [inaudible 00:22:57]. But those folks are solving problems for customers. And sometimes again, those enterprise soups of logos and justifying cost centers. And again, just when we got to the cloud native era, some of the folks working over to Kubernetes and they didn't even have a really good reason or a workload to put on Kubernetes, they just spent money in Kubernetes. They hired three or four people that were good at Kubernetes coming out of Google Cloud platform workshops and certification processes with no use cases. So we focus on the use case. We then implement technology that rationalizes the use case and makes it real for users. And if that implies a multi-year contract and a multi-year roadmap and transformation or architecture modernization or platform modernization effort, so be it. That's what you're going to do. And we doing that for our clients.

But again, we always start with a use case. We always start rationalizing it, making sure that it's solving a business problem. And by the way, the business problem could be a trivial thing. That could be huge impact in the bottom line of a company. Things that are even actually unearthed or unseen from a C-level executive or even director level roadmap view. To your point, they may be too worried that kind of miss the forest for the trees kind of thing. The big objective is being missed because they're worried about the everyday need. So we come in and solve that problem. And again, my personal motto is trying to solve problems that delight users. That's my goal. I keep telling the team, if you use a mobile app or a web platform or a data pipeline with modernization capabilities and analytics capabilities, if it doesn't delight the user and if it's not a joy to use, it's not meeting the mark.

David Joy:

Yes, I agree. And that goes back to what you started off was the customer experience is so critical to the overall product, and that's essential as well. I wanted to go back to a few things that you were talking about with respect to digital transformation and product engineering. How have you seen the landscape change really in terms of in the last five to eight years? Obviously there are so many different trends that have come up and people have adopted, we went from the cloud, sorry, on-prem to cloud journey. We have seen a stack of people trying to move from monolithic to microservices based architecture or adopting distributed systems and things like that. When you go engineer these for different problems, are you seeing any patterns that are similar across multiple domains?

Ignacio Segovia:

First of all, we have practice capability centers, practice-oriented capability centers, and they're global. They organize themselves around best practices. So we have multiple capabilities that we focus on. And again, I can go down the line, but I'll just focus on my area, which is digital engineering and digital product engineering, where we basically worry about, let's put it this way, six swim lanes of work. One is product lines and product management and technical product management capabilities, co-creation, competitive analysis, accelerated product workshops, human-centric design, et cetera.

What we do is we try to evaluate where the customer is and we map out are you in a bootstrapping effort and if so, what part of that bootstrapping capability you're at? So we kind of attack the client, we meet the clients where they are at and we attack the problem at their comfort level. Doesn't make sense to come in into organization that is not thinking of product-driven business strategy or creating agile product funding and giving projects funding based on the need of their users and the competitive analysis or the A-B testing of the latest reviews if you're not equipped to even operate as an agile organization or a semi-agile organization. So that's one.

David Joy:

100%.

Ignacio Segovia:

Yeah. The second thing we do is product design. Again, if you look at the digital engineering continuum, we think about product design, user experience design. We look at personas, we look at static design systems. Okay, this company is ready for a static design system, but it's not ready for a programmatic design system. And if you're not familiar with that, programmatic design system is an evolution that Altimetrik has been quite at the forefront of that. But overall, it's part of my passion as well to make sure that when you have a Figma file and you have a UI and you get some, again, typical HTML developers or React developers or Vue developers or anybody working on the presentation layer, they're going to be expecting CSS, they're going to be expecting some react props. They're going to be expecting HTMX renders and layouts or bootstrap templates. Programmatic design systems takes that to the next level.

So it almost literally, as you could imagine with a data engineering pipeline where you have all these ingestion patterns, transformation patterns, et cetera, et cetera, cleansing, et cetera. Same thing can be done with a UI. And this is a fantastic opportunity approach for a lot of companies that are very moving into product and design thinking and human-centric design capabilities, evolving that. So that's the second track. And again, we're very actively in the industry as well working with folks. I belong to a couple of thinking partners and think tanks around that area as well. We work very closely with Figma as well as strategic group. And the third layer is what we call channel engineering. And to your point, you're serving multiple clients across multiple channels. So you're going to have to manage a website, you're going to have to manage a mobile app, you're going to have to potentially manage an AI app, which could be either a bot or some other solution that utilizes AI or potentially a RAG-enabled LLM that could be customizing a data set into a chatbot that goes through a website.

So it overlays. It's a little bit complex sometimes to think of web development or mobile development. Well, it's kind of a little bit of everything. Channels have become a little bit almost commingled between them. You cannot have a very good mobile app without a good web experience and web engineering behind it. And conversely, you cannot have a very good web experience if you don't offer any kind of mobile number one, responsiveness on the views and the viewports, secondarily the offering to the mobile app and expanding to that too, and handoff between them and all that fun stuff. So we really think through that. We think through cloud-native applications as well, the entire cloud stack. We're partners with CNCF, Cloud Native Cloud Foundation. We're refer partners, developers for AWS as well as GCP. We are experts in Kubernetes. We do amazing deployments with frameworks like Nest.js or Next.js View.

We are in the Council for React development framework as well. We work together with Apple sometimes and their Swift reference group to put in our advice. And now that they've just opened source the Swift code actually, and they've made it an independent body outside of Apple. So I'm kind of excited to be a little bit more aggressive about my feedback on Swift routines and things like that. Anyway, the channel engineering part for us is massive. And again, we pair that with Cloud Native engineering capabilities, looking at automating CIC pipelines, creating huge believers in backend for front-end methodology. We believe it's decoupling a lot of the technology burden that companies have had to deal with. Which is, "Hey, I have 50,000 data sources going in my enterprise ecosystem. I can't just give you an API to solve for this problem. How are you going to solve that problem?"

Well, the answer usually is backend for front-end creating a subset of APIs that solve the business problem, customize the user experience, create something to decide whether it's with a micro front-end or a mobile app or whatever it is, or an AI chatbot and talking to a specific custom data sets or APIs. Sometimes using GraphQL, sometimes using REST, sometimes using gRPC, sometimes using socket IO or web sockets to do other bit more of a streaming pipeline. Or if you're looking at a trading platform, that would be the choice data platform capability. So yeah, it's a lot. David, I know I'm throwing a lot the kitchen sink in here, but...

David Joy:

No, I mean this is very interesting. Honestly, it's good for me to also understand how you guys operate and obviously I've been seeing some interesting trends as well, as you said. I know Swift is getting open source. I've been... A few days ago, one of my friends called me, he's avid React guy. I use React as well myself. Whenever I get to quote something, I prefer to use React. And he called me up and he's like, "You really need to start using Next." I'm like, "I don't know, man, another bandwidth." I'm not a full-time developer. I'm not anymore, but he was telling me, he's finding some really interesting trends in Next, and I think we spoke about design thinking as well, what it means to have a product that people feel delighted to use. And I think you made a good point around, at the end of the day, products and applications have to make sense, and then enterprises have to also have an easy way to manage that across multiple channels because not many people think about that, especially in the startup space.

One of the functions that you said you're working with is also startups. And many times somebody has a great idea and they're like, "Well, we need to build something like this." But they don't think about, "Oh, well I have to start managing this on mobile. I have to start managing this across multiple regions or across multiple user groups, and we have to scale. The app has to feel different, maybe change a little bit here and there." So these challenges come up a lot. So it's good to know that you guys are tackling it and you have a very clear vision on how to tackle that.

Ignacio Segovia:

Yeah, so interesting that you mentioned this because just last couple of months we've seen a proper a snowball effect of clients coming to us exactly with that challenge. "Hey, I'm running a SaaS platform." "Hey, I'm running a payments platform." "Hey, I'm running a small startup doing self-directed financial advisory capabilities." All of them have the need for no code updates. Two, they have a need for content management capabilities that require no developer, no design code, no design time. So they want the business to own that. They want the CIO or the CFO or the chief advisory officer for the platform or the startup in this case to come in and change the value of inflation because it's varying. So the calculator that they have on the front end that's calculating interest repayment rates on a loan for instance, or a house or a student loan or whatever, they want to be able to inject that into the code without developer interactions and the engineering requirements and requirement type, because obviously that costs money.

So what we do is, to your point, we bring headless CMS capabilities to the forefront of everything we do. We try to bring in the Strapi's of the world, the Contentful's of the world, and there are others. Adobe experience manager would be another one. But these things are decouplers we try to de-risk at every step of the way and the layers that we put together for our clients, they need to be de-risked and they need to be decoupled properly. So we look at that challenge as a fantastic challenge, and a lot of clients are like, "Wait, you're going to use a headless CMS as a backend?" It's like, "Kind of, yes. I mean, you can." There's no point. You can maintain state of the application and state of your data and your regular data engineering pipelines and data lakes and databases, but you absolutely could run super lightweight, front-end taxonomy for an entire SaaS application on something like Contentful or a Strapi. So it's actually really cool.

David Joy:

Yeah, I've seen some really interesting things happen in that space. Obviously from a development point of view, CICD over the last few years, there's some really interesting products that have come up. I do not know if your teams use Netlify to deploy applications and fast CICD, and one of my favorite ones is LaunchDarkly, which I feel is a pretty interesting product for making changes in production and things like that and prototyping. Tell me a little bit about that you guys use and recommend that product as well.

Ignacio Segovia:

Yeah, so we love Netlify. To be honest I think our stack of solutions really varies on what the client wants to see sometimes. Sometimes we come in with recommendations of our own. We are seeing a lot of movement. Netlify is one of the examples. Gatsby and XJS, those kind of static generator solutions have becoming become quite trendy because again, you can generate this static content for a website. You can deploy that and package it together, do a lot of server-side rendering and just call it a day. We are seeing... Again, we do everything. So we literally see folks that need content pre-generated and server-side rendered for knowledge basis or developer portals, just to give you an example, a use case that would use that.

Another one is, "Hey, if you're running an advisory firm and you really need to be on top of some of those calculations and financial outputs." You'll be looking at something a little bit more dynamic with a socket IO and potentially Kafka in the back end and running some of those messaging cues and topics. So again, depends on the use case, but to your point, in web development world, we are seeing massive traction for, again, specifically on the stack, folks want to see micro front-ends being applied cogently not as a spaghetti code as they have been so far. For the most part I think micro front-ends are a good idea if executed well. If not, they are well a pain. They literally are. Similar to microservices. I mean, there are good microservices and bad microservices.

David Joy:

It's like a trend. You wear jeans in the seventies, you ditch them in the nineties and you start putting them back in 2010. So it's cyclical because I feel like this is my opinion when you're, especially building early on products, I've learned this over the years, you can over complicate it by creating a very complex architecture while doing nothing to solve that actual problem. But there are also places where I've worked where we've very kept the architecture really simple and solve the problem, and it traded over time to scale and kind of resolve the other challenges that come with when the product goes into 2.0 version or 3.0 version.

So it's really interesting how I've seen all of that evolve. But coming back to early you spoken a little bit about what you guys do at Altimetrik and know your work there. Tell me a little bit more about... I know we have to be cognizant of the time. Now as a chief architect, you've been with the company for a while and taken this role. Tell us a little bit about how your day is as a chief architect. How does that day look like? How crazy is it for you to go talk to your engineers and talk to products? And tell us a little bit about that for somebody who's listening and who wants to get into be in a position where he can be a chief architect as well?

Ignacio Segovia:

First of all, it requires a lot of troubling and going to see customers and discussing really interesting problem statements and spending some time workshopping solutions, whiteboarding, designing entire systems. Again, sometimes probably distributed for multi-hundred millions of requests per month coming through or $2 trillion transactions coming through every year, which is a hard number to even wrap your head around sometimes. So a lot of travel in a good measure, it's a good thing. Putting aside the meeting of the clients or workshopping on a day-to-day basis with the team, first of all, lots of best practices counseling. We have an entire setup of practice engineering and practice modeling within my particular team, which is the digital product engineering team. And now we're in a little bit of a mix of a rebrand or/go-to-market upgrade. But the idea is we bring all of these teams together, run basically a staff meeting type of meeting where lots of folks report back from particular client problems or client issues.

We try to imply, okay, if this is a pain point or an engineering velocity or a pain point or an architecture choice or a pain point on stack choice, we better go and research or try and incorporate that. And if it's already part of our practice, then apply that in a good way. So that's part of it. Kind of shepherding the teams towards good decision-making around architecture choices, stack choices, pattern choices, looking at software engineering practice, almost basics. Sometimes it really does come down to algorithmic solutions, good applying application of modern patterns. And then just using that, basically that thinking and guidance. The second part of my role, I think it really has to do with compiling compelling stories for clients to understand that we're not just building a solution architecture for them. We're not just building a technical definition of a payments portal or a transactional system, but rather we're creating something that's meaningful to the business, that's meaningful to the consumer.

And as I was mentioning earlier, we put together a beautiful solution, architecture decks and deck work that's involved there, but that's just the very beginning of the story. The second part is proactive work. How do we go ahead and say, "Hey, we can put together this user experience in a matter of hours and start switching together a user experience based on your personas." And we start driving some of these onboarding journeys and utilization journeys and activation journeys, retention journeys, et cetera, based on the personas. And then we jump out of the Figma's, as I call it, into more Miro product. We kind of overlay all the Figma's technical architecture decision requirements and then start putting the solution into a POC and then POC that into an MVP. That MVP usually evolves into product market fit. If we're talking about a startup, if we're talking about a mature company, usually goes into UAT or pre-production release and staging.

So there's a lot of that guidance, shepherding the teams. So through that, and I carry... My team carries significant number of products and significant number of projects concurrently. So I'm a little bit exposed to a lot of these projects at the same time. So sometimes it's about choosing what project to work on and focus on given the best push you can to the team, helping them make good decisions. And then the last thing is obviously a lot of hiring, a lot of making sure that we're hiring top talent, that architects are coming into the team are occurring with technologies that are exposed to really amazing previous experiences, but also amazing experiences within Altimetrik and giving them that the power to evolve and do great work. And again, that's just on the architecture side, but again, there's multiple other areas that we worry about as well, like product management or user experience design, web developers, mobile developers, SRE developers, et cetera.

David Joy:

Well, that's awesome because honestly, it's very difficult to condense what you do on a day-to-day basis and explain to somebody like me, it was like, "Hey man, this is what I'm doing on a day-to-day basis, but let me give you the bullet points." So you did a great job. Thank you so much for doing that.

Ignacio Segovia:

Thank you. No, I don't think I did. I think I rambled a little bit, but I will say this and it is very interesting, and if I had to give advice to my own self from 10 years ago is just don't expect repetition is the best advice I could have given myself is about flexibility. Having a construct of goals, having a construct of a vision, being rigid on the vision, flexible on how you arrive to that and on the goals that basically come to you every day. And again, the role that I run is extremely amplified by amazing teams that work with me. I'm privileged to work with really top world-class talent, both inside Altimetrik as well as with our clients because again, my role and particularly my practice gets exposed to really amazing talent on the client side. It's not just what we bring to the table, it's what they also have. So it's really, really empowering and really enriching, very, very, very fun.

David Joy:

I think one of the biggest understatements in history of software development is how good a leader needs to be when it comes to hiring a great team. It's so critical and I'm glad that you mentioned that as one of the key things that you have to do because I feel like if you don't get... It's not just about the talent, it's also about building... Getting the talent to work in an ecosystem [inaudible 00:44:20]. It's like integrating the right tool for the right team. How do you approach that part of the process where you're like, "Well, I need to first get somebody who solves this but also works in a great team?"

Ignacio Segovia:

That's a great question. And number one, the first rule of hiring for me is if it's a direct report or somebody who's going to work really closely to me, I'm looking for somebody that would be hiring me. Number one. I think it's an unwritten rule, but I want to make sure that if I hire somebody, I would like to be hireable for them. And I play a little bit of a reverse interview sometimes where I literally say, "Hey, listen, why don't you tell me what kind of role you're playing and what kind of role do you think you could be offering my own capability." Because I see everybody that we hire as a potential number one, Ignacio's replacement, number one. Number two, somebody who's better than you, somebody who's more capable and has more potential.

If you hire for that, if you go after that, it may not be something you achieve every time. It's not something that you should be afraid of looking for in terms of, "Hey, I want to surround myself with people that are better than me." And I think there's this whole saying from Steve Jobs, you don't hire people really good, talented people to tell them what to do. You hire them to tell you what to do. It's exactly my motto. Now that comes along with a couple of other things, cultural alignment, I think to your question, how do you put together big producing teams and effective teams and happy teams? That's an important part of this.

David Joy:

That's critical thing, yeah.

Ignacio Segovia:

I think a lot of people think about, "Oh, let's just do this high-performing team." And they hire these high-performance and the team kind of falls flat or ego starts playing into it. I think the leader sets a tone, understands that the team is bigger than the sum of its parts, and it's about, again, cultural alignment. It helps to be aligned in more than just work principles and what drives you. Meaning, okay, what drives you outside of the office? What is it that causes you joy? What kind of travel do you do? What kind of things do you like to do outside of the work place? That does bring a significant amount of synergy to the teams, and again, not necessarily from my perspective, but from their own.

It's the network effect of relationships that improve each other performances and they enjoy seeing each other. They enjoy going into a workshop or traveling to Europe to do workshop with a client. That should not be done with somebody that you're basically not compatible with. You're looking for somebody who can be very good at understanding all of those aspects. And again, of course, looking at the high performance. So the contributions. You can also tell how much people can absorb, and I always look for that. If I give again one more time advice to my own self when hiring people is how much are they willing to learn and to change their mind and change opinions?

David Joy:

Yeah, no, I agree. I think I couldn't disagree with any of those points. These are essentially critical and I love Steve Jobs's perspective as well on that as well. How do you personally keep up with all the madness in the tech world and what's your method to keep up and always be aware of what's going on so you can actually pass it on and build on it with your companies? And as well as what's your advice to anybody who is getting started in the tech space and wants to get to a point where he can lead product as well?

Ignacio Segovia:

Yeah, I'm a multichannel guy when it comes to news and updates on tech world. So obviously Hacker News, Techmeme, those are my first things that I open up in the morning looking at what's happening in the valley and with startup drama and Silicon Valley drama. It's always fun to track Twitter and Mastodon really good engineering assets and engineer blogs do deploy into those two social networks, particularly Mastodon is a good one. So I do follow quite a bit of publications and startups, engineering blogs.

I follow our own colleagues at Altimetrik and our own clients as well, which also, it's a wealth of knowledge. Altimetrik has a very powerful developer community as well globally. So we have global hackathons where we come publish these things internally as well. Some of them are external as well. So it's really always interesting to look at the new tech or the new Kubernetes runtime or workflow restriction engine, and it's always a pleasure to sometimes even track down some of the founders or CTOs of those organizations that actually engage with them and say, "Hey, can we use your product? Can we POC it here?" We've done that actually a number of times. I think LinkedIn is also a pretty good source to keep track of things overall.

David Joy:

Yeah, actually LinkedIn in my opinion, is probably the last place where I learn stuff. It's probably... I hate to say this, but as much as I like... LinkedIn is a great tool, but I just feel like many of us don't use it optimally.

Ignacio Segovia:

You know what I do? I inform the AI algorithmic a solution to take away the viral stuff that LinkedIn puts in front of you, and then resurface things like, for instance, CockroachDB. You guys have an incredible solution, and it's really, really cool. And I've actually, I'm looking at exploring some alternatives with the team to deploy into solutions with some of the things that you guys are doing is really interesting. But the idea of using LinkedIn to find these things. So I inform the algorithmic solutions like, "Hey, please don't give me any more of this, give me more of that." So I try to curate it my own, but you're absolutely right, and I do agree to some extent, LinkedIn has become a little bit of the Facebook of the business world, and it's been a little bit bastardized in its original sense in some ways.

David Joy:

Yeah. That's awesome. I really enjoyed listening to your perspective. It seems like me and you can talk for a couple of hours, obviously. There's so much to get into. It's very difficult sometimes to get into all the amazing things that one person is doing. But you did such a great job of explaining to us Altimetrik and your career as well as some of your engineering philosophy and leadership philosophy. So thank you so much for coming on the podcast, and I hope we can have another conversation down the line when you've probably implemented CockroachDB somewhere and you tell me are you ready to do this.

Ignacio Segovia:

That's a deal.

David Joy:

Yeah. But once again, thank you so much, Ignacio. I hope you had a great time.

Ignacio Segovia:

Thank you so much, David. Likewise. Thank you for having me.