‘Inside the Mind of a Fractional CTO’ with Marc Adler, Fractional CTO for Startups

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special and an interesting guest. He has super experience and has super nice thoughts to share with you today. He has 20+ years of engineering and leadership experience as a CTO and a Chief Architect. He has worked with companies like ADP, MetLife, Citigroup, British Petroleum, and whatnot. He has also been working with a lot of startups these days as a fractional CTO. Welcome to the show, Marc. Great to have you here. 

Marc Adler: It’s a pleasure to be here. Thank you for inviting me. And, I’ve seen some of your other podcasts with some other guests. And, so I hope that this will be as interesting as the other ones. 

Kovid Batra: I’m sure about it. By the way, pleasure is ours. Let’s get started. 

Marc, so, in our podcast, if you have already seen those, we have this format of talking to our guests through a fireside chat, wherein we ask you a few questions to know a little bit more of you outside of work, right? So, I hope, you’re ready for that. Let’s get started from there? 

Marc Adler: Okay. So, outside of work? Is there an outside of work? I hope there is. So I have, I, I am, uh, somebody who you say is a doer of all, master of none. So, I actually have a musical background. Way back when I went to college, I actually had a double major in Computer Science and classical percussion performance. So, I played in many orchestras and wind ensembles, and my speciality was an instrument called the marimba, which is like a very large wooden keyboard instrument, and played timpani, and all that stuff. And right now, I’m teaching myself how to play classical guitar, so that is my one passion right now, it’s learning how to play classical guitar and trying to play some of the pieces that I used to play on marimba on the guitar now. 

And, I’ve also been a private pilot. So, I used to fly all over the place in the New York area. And so listen to strange avant-garde music. And, yeah, I think that, yeah.

Kovid Batra: Yeah. That’s very interesting, actually. All right. I think I still have a few questions for you. I think we would have some interesting answers there. Let’s get started with my questions, okay? 

All right. So, this is a hypothetical question, of course. Let’s say, if I give you a time machine, where in your life you would want to go back or go forward, maybe, I don’t know, if you have a time machine, where would you want to go? 

Marc Adler: Well, of course, everybody wants to go forward. Everybody wants to be a thousand years from now to see what interesting advances have actually happened in Computer Science and AI and, and just engineering in general. I mean, I’d love to see what the iPhone of the future could do in a thousand years. I mean, there probably won’t even be iPhones. But, going back to the past, boy I think I would have maybe going back to New York to, like the 1964 World’s Fair or the 1939 World’s Fair where there was a lot of excitement and new inventions being shown. I remember, there was this Futurama exhibit, this is where the cartoon Futurama comes from, if you know that. They had an exhibit where they were showing what life would be like in the future. And so, there was, like such an excitement around there. So, yeah, I’d love to kind of go back and, and revisit some like great historical moments that happened in New York City. 

Kovid Batra: That’s nice. That’s an interesting thought, by the way. All right, my next question. So, if we are talking about going to the past, do you remember your first functional code that you wrote? Like, your experience? 

Marc Adler: Mm-hmm. 

Kovid Batra: Describe something about it. 

Marc Adler: I do. So, I mean, way back, I got my master’s, so my education is I got my Bachelors in Computer Science and Music from State University of New York at Albany. And then, I got my master’s degree from the University of Arizona, which is a really great school for software. And then, I went to New York University’s Courant Institute of Math for one year in a failed attempt to go for my PhD and did the whole story around that. But, I think the first really good code that I wrote was a music editor in a language called Y, which was a very C-like language that the professors, some professors at the University of Arizona created. So, I did a whole graphical music editor at a time when really graphical music editors didn’t exist. So, that was fun. But, my very first commercial product was I wrote one of the very first word processors for the UNIX operating system. And, I actually showed that at the very first UNIX Expo in New York City in 1984.

So, when you said I have 20 years, yeah, I have 20 years of experience as a CTO and Chief Architect, but I actually have been in the industry for a little over 30 years. 

Kovid Batra: That’s nice, man. 1984, you’re writing on code there, and doing the commercial code, I think that’s really, really amazing, man. 

Marc Adler: It is. And, you know what the interesting thing about those times were is that we had to optimize every little piece of memory. I mean, there was not much memory in these machines compared to today. So, I used to print out printouts of my code on an old Epson dot matrix printer and take them into work on the New York City subway and look at every line of code and try to get, try to optimize even a little end clause. One statement, if I can get that millisecond or nanosecond of improvement, it really made a big difference. 

Kovid Batra: Yeah, I understand. You have seen a big transition, I’m sure about it. Cool! I think that was a very good question to ask. 

Marc Adler: And, the funny thing is that you don’t see many people doing that anymore. You know, languages and environments are just so high-level, people will just code and not pay attention to how efficient the code is. And, the only place where I’ve really seen that level, you know, people paying attention to efficiency is in the high-frequency training world, which, of course, I have a lot of experience in as, you know, both in terms of CTO and Chief Architect for various financial institutions, where you have developers who are looking at aligning structures on certain kinds of boundaries and they pay attention to every single nanosecond that their code takes up. And so, that’s a discipline which is lost on most developers now. 

Kovid Batra: Cool! I think that was great knowing you, your passion for music, and where you want to travel in time. You’re writing code since 1984 and I think maybe before that. So that’s, that’s amazing, Marc. 

Cool! Let’s move on to something our audience is awaiting. Moving to our main section where we get to know about your experiences in your career, how many challenges you have seen, how did you overcome those. And so, let’s get started on to that. Are you ready?

Marc Adler: Yeah. Yeah. Yeah. Go ahead. 

Kovid Batra: Yeah. All right. All right. So, you mentioned your role as a fractional CTO, right? Like, recently from past five to six years, as we know, you have been running this organization, part of this organization where you are working as a fractional CTO.

How is this role of a fractional CTO more challenging or less challenging, maybe I don’t, I don’t know, I would love to hear from you, as compared to a full-time CTO who is working with a company? So, just tell us about the challenges that you see and how do you overcome those, and how is it different.

Marc Adler: Okay. So, there are less challenges and more challenges with the roles. And, I’ll kind of mention some of the less challenging aspects. 

When you’re involved in a large company, like Citigroup, or I just came off of a CTO role at XP Investimentos, which is a very large, I think it’s the largest brokerage in Brazil. And, when you are dealing with large companies, unfortunately, you have to deal with lots and lots of politics. It’s not easy to get things done. I always say that you know, it’s a struggle to turn the battleship five degrees because there’s just so much that you have to go through with paperwork, with politics, with people who are pushing back against you and want their own agendas. So, that is not the part that I miss with being a CTO or Chief Architect in a large organization. You don’t get that when you are dealing with startups. And, in my fractional CTO practice, I like to deal with startups. The newer the startup, the better. My sweet spot is dealing with a founder that has no technical background or very little technical background where I get to make all of the technical decisions, right? So, you get very little pushback, there’s no politics. And so, that’s the advantage of being a fractional CTO. The other great thing about being a fractional CTO is that you get exposed to so many different domains out there, even domains that you’ve just never experienced before. 

So, since I’ve been a fractional CTO, doing my CTO-as-a-Service, that’s the name of my little consultancy, I’ve had clients in education technology, in real estate technology, in almost every field right now, one of my customers is a big university in the United States that is coming out with something very, very new and unique as far as material sciences go. And, I don’t know much about the domain of material sciences, but as a fractional CTO, you get to learn some of that stuff. That’s what’s really, really fascinating is the fact that you can just go to all these different domains instead of being just, staying with just financial technology or training systems all of the time. 

So, that’s why every day when I wake up and I deal with my clients, it’s like a breath of fresh air because I always feel that I’m learning something new and I could always have forward progress every day. Whereas, in a large company, you have to deal with politics. But, the good thing about being with a large company is that you have an unlimited amount of resources and development and developers. So, unlike dealing with some of these startups, you don’t have to worry about costs as much as you do when you’re dealing with the startups. 

Kovid Batra: So, are you trying to say that the fractional CTO role is probably more suitable in a scenario where you are dealing with a startup, or the large-scale companies or even medium-scale companies should hire fractional CTOs for certain jobs?

Marc Adler: From what my experience is, large companies are not set up to deal with fractional CTOs. I mean, if they have a gap, if their CTO leaves, they’ll usually either fill it internally, or they’ll go outside to the market. They’ll want a full-time person because with a large company, there’s a lot of processes to deal with, there’s more intellectual property to deal with; and as a consultant, as a part-time fractional consultant, you’re not going to get the buy-in from the organization that much. It’s much easier to be a fractional CTO for startups because depending on your pricing model, you could be very, very affordable to a startup. So, for instance, if you consider what a full-time CTO earns in the United States, most startups cannot afford that. They can not afford to have a full-time. 

Kovid Batra: Absolutely, yeah. 

Marc Adler: For my clients, they’re getting a person with 30+ years of experience, with leadership experience for a small fraction of the price that they would have to pay for a full-time CTO. And, if you’re an experienced technical leader, then you can usually have a higher bandwidth, meaning that you can make more correct decisions upfront, you know, rather than kind of you know, maybe having a few false starts.

So, I think that for my fractional clients, they like to have that level of experience at something that they consider it to be an extremely affordable price. 

Kovid Batra: Makes sense. Tell us more about what kind of initiatives, responsibilities you take up as a fractional CTO with these startups and how does it work out with the teams also, like how do they take you as a leader in the team; because even if it’s a startup, I’m assuming there are 5, 10, 15, 20 folks who are working with you in the team. So, tell us about some of specific experiences that you have had and the initiatives that you have worked with. 

Marc Adler: Right. So, with almost every company, with every startup founder that I deal with, the thing that I like to see and that they help them with is getting all the product specs together, right, to know exactly what you’re building and to have documentation about what the product is supposed to do, all the use cases, all the error cases, all the edge cases, because I think one of the common mistakes that a lot of startup founders do is they just will take some ideas, they’ll throw them over the wall to some remote development company, and they’ll just say, “Build this.” Most developers, they don’t have a good idea of what to build.

So, what I’d like to make sure is that my startup founders have all their product requirements and use cases there. And sometimes, it could be Figma wireframes, or it could actually be in text, but I want to make sure that the developers actually know what they are building. So, that’s the first step.

And then, once you get all the product requirements, then you have to create the technical architecture, which is something that I do for my clients as part of my job, right? So, you can’t create an architecture if you don’t know what the product is supposed to do. You can’t build an architecture if you don’t know the scaling and resiliency requirements.

So, one of the common things that I see is that non-technical founders will throw their requirements over the wall to a dev shop and get back a system that is totally complex, right? So, something that uses Kubernetes, for instance, for a very simple web app, right? And, you have to guard against what I call resume-oriented development; that is a dev shop who is using technologies that might not be totally appropriate for a system, but they just want to learn those technologies, right? So, I help my founders with that. 

So, with the product requirements, you’ll do the technical architecture. Then, what I’ll do is I’ll hire the development team. So, I’ll interview a number of dev shops. And, when we have a short list of candidates of as far as dev shops go, I will get resumes from the dev shops and I will interview every single developer, right? I will make sure that I have the best possible development team for my clients. And then, I’ll work with the founder to come up with the project plan, right, the backlogs. And, I will then run the development team. I’ll do that. I’ll set up the cloud, I’ll do the cloud administration, I’ll face off with the CTOs and CEOs of third-party vendors that we have to deal with, and I’ll basically design the whole system, and I’ll give them over to the developers. And, as far as how is it to work with the developers? Well, I’m the one who hired them, right? So, I’m the one throat to choke as they say, right? I am the technical authority. So, I like to have a development company that will have some good opinions and might push back on some of my designs and for good reasons. But generally, I think that because I am a very technical person, I can still code a lot that the developers usually have some respect for me because I know what I’m doing. 

Kovid Batra: Yeah, I get it. Cool. I think the setup is pretty suitable for a startup also. But, one thing that didn’t come to me right as per your opinion was that you have to have all your documentation in place. I mean, that’s the hardest thing to get when you are working with a startup. So, how do you deal with that friction? I’m sure with almost all the founders, you would have some friction there or at least some to and fros there where you would be pushing to get the right documentation and getting it done. So, how does that scenario come up? 

Marc Adler: Well, even founders do not like to write documentation, right? Nobody likes to sit there in Google Docs and write lots of documentations. And fortunately, because I’ve been around for a lot of years, I actually have a lot of templates that I give to them. I say, you know, sometimes I’ll give them existing specifications, and I’ll say, “Okay, here is the format it should be in. Here’s some sample use cases. Just tailor this to your needs.” Right? So, almost every system has to have user registrations. Users have to be able to sign up, change their password, have certain permissions, et cetera. A lot of the startups have to have some sort of payments integration with things like Stripe or Plaid or Venmo or PayPal, whatever. So, they can use my pre-existing documentation to kind of tailor things. A lot of startups have to have some kind of alerting or notification system. What I’m mainly interested in is workflow, right? What should the developers be doing? How does somebody navigate through the whole product? So, sometimes the developer, the owners just do not write the documentation, but they’ll have very, very comprehensive wireframes and the workflow on something like Sketch or Figma. And then from that, I could actually take that and write the technical specifications. So, when I write the technical specifications, I’ll say, “Okay, this is the way this service should operate. Here’s the API. Here’s some suggested data models or class diagrams for this service. We’ll do a little bit of eventstorming, right? So, here’s the events that should get generated from this. Here’s the other services that these events should be communicating with.” So, given some kind of either complete workflow or documentation, I’ll be able to then go and create the technical architecture and the technical documentation and specs that I can give to the developers. The more you give to the developers, the less you leave up to chance, right? You don’t have to be worried that a dev shop is gonna come back with something totally inappropriate. 

Kovid Batra: Makes sense. Let’s talk about something that is very important, and I think critical also in a way at the initial foundation-level of a startup itself which is around the culture, like engineering culture that is there. Do you involve yourself to that extent where you try to build the right culture for a startup at that early stage?

Marc Adler: All right. Well, for the startups, since I usually use remote development shops, I will always talk to the owners and the managers of those development shops to make sure that they are the ones who are promoting the correct culture, right? It’s not like when I’m CTO at a large company that has my own developers, where I do try to promote a very good engineering culture with continuous education and lunch & learns, and sending people to conferences, things like that, and getting guest speakers to come in. When I’m with a startup and I’m using a remote development team, I will make sure that the development shops are promoting a good development environment, you know, the same kind of principles, continuous learning, things like that. And so far, a lot of the dev shops that I use will do that. They have really great cultures. Some of the ones that I’ve used in the ex-Soviet Union countries, they send me videos of parties that they have and outings that they have, and they are bringing in guest speakers. And so, I’m quite confident that they’re showing love to their developers. 

Kovid Batra: Yeah, that is taken care of that way. Perfect. 

Marc, I am really amazed with the kind of experience you have had, working with MNCs and then working with startups. So, this is quite a diverse experience. But, do you see in last 30 years or 20 years of your experience, some patterns which make you feel that these are one of the biggest challenges of engineering teams and these should be changing how the world perceives, or I should say, the engineering world perceives few things to be done in a certain way, but those are not in the right direction? Some counter thoughts, some anti-patterns that you see could be the real patterns, actually. 

Marc Adler: Yeah. So, I’ve seen moves to complexity and back, right? So, I see that there are developers who hang on the words of certain tech industry acolytes. So people who like, for instance, the whole move to microservices; and I’m a fan of microservices if done right. But, I just saw when microservices were introduced, everybody made a mad rush into microservices without realizing what the complexities are. And now, there’s this whole movement to unwind those and go back to the monoliths, right? Same thing with Kubernetes, which seemed to be the flavor of the month for a long time, but people got into a lot of problems with actually administrating Kubernetes. So, I think that one of the things that I’ve seen is just new technologies being introduced and people just rushing to them. And, as I mentioned to you before, resume-oriented development, right? So, you know, it’s funny, my wife, she was a developer from long back, she worked for some of the big New York financial institutions. She used to work in a system called CICS, which basically ran the entire world. I don’t think it’s really used anymore; maybe it’s legacy now. But, she made an interesting comment. She said, “Marc, everything that you’ve been doing for the past 20 years, CICS did back in the 1980s. And everybody’s just trying to reinvent that stuff.” And so, one of the things, one of the anti-patterns that I’ve seen, again, is just is taking something that should be simple and rushing to introduce more and more complexity. And, for the startup founders, that’s a real concern because whatever a startup founder gets back as a product from a development company should be maintainable. It shouldn’t be written in some esoteric language that it’s very hard to find development resources for. It shouldn’t be using infrastructure up on AWS that is extremely expensive. 

Applying my past experience to my startups, I think one of the things I want to make sure is that stuff is built as simply as possible to do the job, right? That people should not be following the word of one tech acolyte or another and rushing into a technology that might not be appropriate for a startup. 

Kovid Batra: That makes sense. I think that’s very interesting to hear. And, it’s common, like a new technology comes in and people think that this is the best way to go forward, not much of analysis is done on how the business vision looks like or what the business needs and you just go out implementing what’s trending right there. So, it makes a lot of sense what you say. 

Great! I think that was an interesting topic to touch on. Now, one last thing, and then we will wrap up. When you’re working with these teams, we touched on the cultural aspect, but then, how do you as a fractional CTO, make sure that these teams are being efficient, like they’re producing what they really need to, and what are those success criteria that you put forward to the team, to the developers that, okay, this is something that you need to look forward to?

Marc Adler: Okay. So, I do things the old-fashioned way. And that is, I will have Jira boards, I will have sprints, I’ll have a Project Manager tracking velocity, things like that. And, I just get a general sense. Because I’m working with smaller teams, I kind of have in my head where the developers are at. Sometimes I will put myself on pull requests and I’ll look at the code, and I’ll get a general sense of where developers are at, if there’s developers that are giving me any trouble, if there’s developers who are billing eight hours, but it only looks like they’ve worked for one hour, right? So, I’m very good at detecting that kind of stuff, which my startup founders do appreciate. But, I would just say it’s the old-fashioned way of actually maintaining close touch with the developers and the PMs, knowing where things are, looking at code, seeing where we’re tracking against timelines. And that way, I’ll know if a team is efficient or not.

Kovid Batra: Can you just tell us those small tips and tricks that you really apply? When you say that somebody’s working eight hours, showing eight hours, but actually working one hour. So, how does that work out?

Marc Adler: I know that lines of code is usually not a great measurement, but you could see if somebody did a check-in and they changed two lines of code in an ‘if’ statement and they billed eight hours, you know that. Yeah, maybe there was some debugging time involved to find something, but, yeah, you could usually tell. It’s just a built-in sense that I’ve developed working with hundreds and hundreds of developers and being, as I said, being a coder myself, you just know when something doesn’t take that long, but it’s being, it’s being billed. And, you know, one of the interesting things that I do is, with my founders, when I’ll help them go over the monthly bills from the remote development shops and I’ll say, “Hmm, this isn’t right. Let’s get the owner or VP of the development shop on a call. And have them, you know, say, hey, why did this take eight hours when it’s a, you know, it looks like it’s a one-hour change?” So, and then, more often than not, my founders will get a little bit of a credit from the development company, which a startup always appreciates. 

Kovid Batra: I’m sure all your clients are loving you for all the money saving and the right technical strategy being implemented from early on.

Marc Adler: Yeah. Well, the interesting thing is with ChatGPT and all these large language models, it’s going to be really easy to write substantial blocks of code in no time. 

Kovid Batra: Yeah. 

Marc Adler: And so, it’s going to be interesting to see where developers start using ChatGPT or a large language model to write entire classes or entire apps. And then, seeing them bill a lot of time for that to ChatGPT. Basically the whole thing. 

Kovid Batra: But, I’m sure like after GitHub Copilot, things have changed already. Like, a lot of people are using it. Every person to whom I’m talking to, like earlier they were using ChatGPT, and now they have completely shifted to GitHub Copilot while writing code. So, do you see that adoption happening? And like, do you prefer that happening? 

Marc Adler: Yeah. Well, this kind of goes back to my prior comment about developers not paying attention to efficiency anymore and not knowing if their code is taking up more nanoseconds than it should. I think you’re going to get the next generation of that with ChatGPT, that these large language models, Copilot or whatever are going to be generating large blocks of code, but no one’s going to understand the logic behind it and the architecture. And, you’re not going to know if ChatGPT or the Copilot generated blocks of code, which are not efficient, right? Because you know, it’s the nature of it, right? You have to really take a close look at that code that’s being generated. 

Kovid Batra: Makes sense. All right, Marc, that brings us to the end of this show. Lovely having this conversation with you.

Before leaving, any parting advice for the technical founders, the non-technical founders? Your success mantra, maybe?

Marc Adler: Well, I would just say that a non-technical founder should always have a senior technical person by their side. Never just trust throwing stuff over the wall to a development shop.

Kovid Batra: All right, Marc, it was really nice talking to you.

Marc Adler: Thank you.