lystn

Notes Thanks to our first patron, Matthew Bivins, for contributing to the production of the full transcript for this episode. We've launched a Patreon campaign to raise funds for per-episode transcripts Don's AspirEDU team chose to hire a developer that knew Python/Django, which was not in Don's programming skillset It's normal for a manager to lose "closeness with the code" as the firm and product scales Should a company founder hire a CTO even if they have zero background in the tech stack? Focus and available time are huge factors regarding the time a technical manager has for hands-on coding After a manager gets past 3-4 developers on their team, having time to be in the code is a struggle In the scenario of a non-technical company, an owner should focus more on a manager that can manage Buy vs Build properly. It's vital that as a product requires "stitching together" disparate parts of the technology, someone on the team can build and maintain the in-betweens. Giving a non-manager the title of "CTO" can be a big problem down the road as the company and product grows. There ain't no thang called a "Senior CTO" unless you're calling them "old." LinksPatreon: CTO Think Podcast is creating Episode Transcripts for Accessiblity ClosingThanks for listening to the CTO Think Podcast. If you liked what you heard, please share a link to the podcast with your friends.Reviews on iTunes are always appreciated and help us spread the word about the podcast.Show music is Dumpster Dive by Marc Walloch, licensed by PremiumBeat.comShownotes and previous episodes can be found on our website at www.ctothink.comFor questions, comments, or things you'd like to hear on future shows, please email us at hello@ctothink.comFor notifications of future episodes, please sign up to the CTO Think newsletter on www.ctothink.comWe'll keep talking next week!TranscriptDon VanDemark: Welcome to CTO Think. I'm Don VanDemark.Randy Burgess: I'm Randy Burgess. Don, what's going on?Don VanDemark: This week I'm doing a few things. Talked a little bit last week for AspireEDU how we were looking to bring on a developer. Looks like we're going to go ahead and go through with that. Lots of new work going to be generated. It's always good to get somebody on board who can help push the product along. Really looking forward to that and I'm sure that'll be the subjects of something in the future. How do you onboard a person?Randy Burgess: Onboarding. Yes, no doubt. Definitely a good topic.Don VanDemark: With construction specialties, we also brought on a person. That's a different flavor of person. That's more operations than technical. This is more the onboarding of getting them an email address and setting them up on the company systems and things like that. Two completely different roles, but very similar things. Then I'm working on a couple little side projects as well, which we'll probably get into later. What have you been up to?Randy Burgess: Well on the CTO Think side, I just launched a Patreon account page for CTO Think. Something that's important to me is accessibility in technology.Don VanDemark: Sure.Randy Burgess: Transcripts are one of the things that podcasts … Some do, some don't. A transcript is just you send a video file to a professional that takes it all word for word and types out the written version of the podcast. It's not a big audience. It's interesting. I talked to a podcaster last week and their attitude was, "I have no idea why you care about the small audience that cannot listen." I guess that's just not where I approach technology. To me, there's a number of reasons outside of accessibility why transcripts could be helpful, but I do think that promoting your product or promoting technology for a wider audience is always a good goal.The Patreon goals … A listener can go to our CTOThink.com website and find the Patreon account in the Contribution section. It costs about $30 an episode or $1 a minute for professional transcripts. Our goal is to have basically a podcast a week. It comes out to about $1,500 or so at the end of the year. Our goal is to reach that. If we double that goal, we will find other podcasts out there that we can offer transcripts for their episodes. We'll see how it works. It's the only major expense we have running CTO Think besides time. I'm hoping we can get some supporters that will help us make the podcast more accessible in that case. The other projects, HOA Done. I'm resisting the urge to over-engineer before I launch a product. I've done a lot of backend controller testing, TBD, stuff that we were talking about last week and trying to get some of the very basic features working on that. In terms of client work, can't go into too much detail, but we are pushing forward a project we put on the back burner and hopefully we'll have a system that allows for greater distribution of the company's main product. That does take a lot of API interaction, having to build a lot of … A lot of back and forth between an API of some of the distribution systems. That's kept me pretty busy for the week.Talking about today's topic, this goes into our side project discussion somewhat because you and I were talking through Slack earlier in the week and you made a comment that you have been coding every day for the last seven or so days a week, which is abnormal for you based on your current roles and what you've been working on. That was interesting to me because I feel like the last six months, I've been … At least six months, if not more, I've been coding every day or every working day for awhile, which is not the case for myself. My history is that there were a good 10 years of being a CTO where I didn't code for work much at all. The question today, the question for you right now is should a CTO, should a technology manager, is it necessary? Do they need to be a coder? Do they need to be a programmer? This comes up a lot in questions from recruiters to me where a company is like, "I want a CTO that codes. I want a hands-on CTO." My question to you is how important is that for a CTO to I guess, one, be able to code, have experience hands on, and two, to be coding right now for either the job or just in life, doing some project? How important do you think that is?Don VanDemark: Right. The easy answer is it depends. We'll walk through what makes up that part of "it depends."Randy Burgess: Yeah.Don VanDemark: For AspireEDU, when we first started, when we were building the product, we made a very conscious decision to program in Python and Django, even though I had zero experience with either. The reason we did that was the programmer we were bringing on board to do a lot of the heavy lifting, that was his language of expertise. It was much more important to me that the person who be doing the heavy lifting was the one who we put in their comfort zone. We certainly could have done PHP JavaScript, where I was a little more comfortable, where I had experience, but that would have been … That would have meant either finding somebody else or a learning curve for the person doing the lifting and that didn't make any sense.In the early days, I jumped in and started learning Python and was starting to learn Django and did some of the work, but my role at AspireEDU is not as a coding CTO. It's not to be hands on on every line of code. Certainly I do look at all the whole requests that come through, take a glance at each of those. Certainly have discussions with our developers around the direction. We're right now talking about … We're hosted on Heroku. Part of the whole refactoring we're doing is to get off of Heroku, potentially, or reduce our costs in other ways.Randy Burgess: Yeah.Don VanDemark: Part of that discussion is, "Okay. Do we go to Kubernetes? Are we going to use something which …" It's a service called Convox, which is a Heroku like platform, but it's not as opinionated I guess would be the point to make there. I have those types of technical discussions. We talk about technical direction, but just as important into my role is taking all that technical discussion and language and taking it to the business side. My role at AspireEDU is to be that liaison.Randy Burgess: On that point, do you think that having coded at all in the AspireEDU code base provides you an advantage over if you had never touched the code, didn't even know Python now? Are you enhanced or is your effectiveness better because of the fact that you have done something?Don VanDemark: I think the answer to that has to be yes. I certainly can read the code better, just having had some experience with it. I don't even want to pretend like I contributed a large portion of the code. That wouldn't even be close to true, but because I did some work in Python and some work in Django, I'm able to look at full request, look at what's going on and have an idea. I'll be the first to admit nowadays, the code base is beyond me. The majority of what's in that code base is beyond my level of expertise in Python and Django. We've got so many pieces going on. It's not all captured in my head as far as every single piece as much as the developers who are in the code day to day. That is a disadvantage-Randy Burgess: But I'm going to say that's normal. As a manager, that's not really … If you're a small business still, but as a company gets bigger … You say it's a disadvantage, but I also think it's normal. I don't really consider it a disadvantage. You can still have the conversations you need to have with the builders and the executives and some of the other stakeholders about technology.Don VanDemark: Right.Randy Burgess: If I were to use that term, 'disadvantage', in your case at all.Don VanDemark: That's fair. It's a disadvantage in a perfect world.Randy Burgess: Yeah.Don VanDemark: In a perfect knowledge world. There's just no such thing. There are only so many hours in a day.Randy Burgess: Let me throw a hypothetical at you then because the scenario that I see a lot is … This is on the smaller business level. A founder of a startup wants to find a CTO. One of the big prerequisites that they give the recruiter when they talk to me or talk to someone else is, "I want a co-founder or someone in the ranks that codes as well. I don't have enough money just to have a manager." AspireEDU really is an interesting story because you all set out where you are not the main developer at the start of the company. I think of that approach as a money-saving tactic more than anything else because co-founding executives don't tend to get paid. They tend to take equity more. All of a sudden, you've got this manager-level person doing what a developer would get paid to do.I guess the biggest question as a hypothetical is if I come to you, Don, and I … Everything about you and my startup or my small business is great. The only factor is that I'm going to be using … I'll pull this out because I don't think you know it. Elixir Phoenix Erlang as my code stack and I'm going to be using Azure, like Microsoft, for the back end, which I don't think you have to have op skills in. I've already chosen this platform where we've built the [inaudible 00:13:20] and I want to hire you. Should I just eliminate you altogether? If you want to work at this startup I'm doing, what is your pitch as to why you still have relevance as a CTO, as a tech leader in my company, despite the fact that you don't initially know this code base? The stack.Don VanDemark: Yeah. That's going to be tough without fully flushing out the hypothetical.Randy Burgess: Sure.Don VanDemark: The factors that come into play, and you made some decisions there that influence that, but the factors that come into play is how many people does this startup have to begin with? You're absolutely right. You didn't come out and say it. I'll come out and say it. What we did with AspireEDU is a little bit rare on what the CTO does as a founding CTO.Randy Burgess: Yeah.Don VanDemark: That's fairly rare. Usually the founding CTO is usually your first developer. I keep throwing the word 'usually' in because exceptions abound. It's usually not even necessarily someone who has managerial experience.Randy Burgess: Yeah.Don VanDemark: It's usually a developer who's been developing awhile and may have even been a lead developer on teams, but not hardcore managerial experience and all that entails.Randy Burgess: Yeah.Don VanDemark: When I've came in, it is a rare thing to not have your founding CTO code. There were circumstances that made that work out for us and I think it worked just fine. It was actually more a matter of time commitment at that time too because during the founding days, that was a case of, "Don, why don't you lead our technical direction while you have a full-time job elsewhere?" That almost precluded me being real deep in the code, because yes, you can code outside of hours. We'll talk about that a little here and we're going to talk about that a lot in another episode.Randy Burgess: Sure.Don VanDemark: You can code outside of work hours, but not to build a product. Not to get that product to market. You need a lot of good focus. We made the decision that I'd come on board, lead the technical direction, answer the technical questions, but not necessarily do the bulk lifting of the coding.Randy Burgess: I'm going to grab a word you just said because I think it's a big key to what I want the listener to understand about a CTO coding and a CTO's job for a company. You said 'focus.' In the hypothetical situation, what I didn't provide you was what do I want the CTO role to do?Don VanDemark: Right.Randy Burgess: The idea that you can take a person, like a technical manager, a CTO role, which typically is framed by person that has to be communicating with several different stakeholders in a company. Sometimes it's outside the company. A CTO can be talking to investors about the technical risk of the company. Definitely all the executives, talking to the marketing team, product development if that's even that big, but a CTO's role is to be communicating. Almost every executive turns into that role, even at the small level, is about communication. A developer role is much more about focus. Definitely developers have to talk to people and communicate, but when you sit down and need to knock out a bunch of code to solve a bunch of technical problems, there's a tremendous amount of focus and that involves quiet and less talking.Remove a lot of the audibles, a lot of the talking and discussion when you sit down … When a developer sits down and starts coding. Even in a pairing situation, if there is talking, it's strictly about the code in front of you. It's not typically talking about business issues and non-relevant subject matter. The idea then if you have your CTO coding is how are you having them split up your day or their day, I should say? There is a tremendous amount of difference in what the role requires from technical manager to technical implementer. Going back to your word, disadvantage, maybe the advantage was there's a technical person on this team that is communicating more than anything else and not heads down coding because that takes away from the other role. At least that's how I've had that discussion before with people asking me, "Do you code as a CTO?"Don VanDemark: Yeah. Another piece of it and another decision point of it is AspireEDU is all self-funded. We didn't take any venture capital. We didn't have any outside investors who might be asking those questions and who might have more experience with coding CTOs, because again, that's the norm. That will play a factor as well is what are your investors expecting?Randy Burgess: Yeah.Don VanDemark: Now I can make the argument that both work. You can be a coding, you can be a non-coding, and I can give arguments for either one. I'll give the argument for the non-coding right now. That again is the focus, as you said, can be on the communication, can be on having those discussions. You don't want the person doing the bulk lifting of the coding to then have to turn around and go sell the company to investors. Go pitch the company to investors. That's a lot of what I was able to help with and participate in because I wasn't the one doing the heavy lifting.Randy Burgess: Yeah. The other issue is time management, I think. We will talk about this in the future, I think. I think providing focus for your developers, the time to focus and understanding how a developer's timeline works is a big CTO … Something that CTOs need to know to the point of when I got hired by Innovations for Learning in a CTO role, I started out with one other developer on the team, which happened to be the person who was the CTO before me. It was a really good relationship, which is kind of uncommon for that trade cover, but I had a lot of time to develop things and to work on it hands on until I brought on more people.I found immediately after bringing on more developers and designer and building a team, more and more, my time was consumed by meetings with different stakeholders, my own team, project prioritization, task prioritization. I was like, "Whoa. I just went in a span of three or four months from 75% coding, 25% management to 25% coding, 75% management." By the end of my timeline there, I was doing barely any code. Now we were very productive because I was making things move along on the management side, but I don't know that … It's not very clear, and maybe you have an opinion on this, how many people would you have do you think working under a manager turns that technical coding manager into, "Hey, you're just running meetings and [inaudible 00:22:21] boards and agile processes and you're no longer coding"? Do you have an experience with numbers where that starts to change for you?Don VanDemark: Oh, gracious. Yeah. I would say that once you get probably past the four or five developer mark, it's going to be hard to be doing the bulk lifting and the code just because you do have to be managing the … Unless you've got a separate project manager, which you may choose to do. You may choose to continue to do the heavy lifting and hire a project manager who can coordinate all that work. You do that, you can probably get a bit further, but not a lot because then you're going to start getting into how much are you involved in the different code reviews? That depends on your process as well.Randy Burgess: Yeah.Don VanDemark: It's a tough question to answer and I would say you're in that four to five developer range when things really start to flip. Now let me throw a complete curve ball at you.Randy Burgess: Sure.Don VanDemark: We're talking about technical managers and what they do, but usually when that is stated, what we're talking about is technical companies as well. They produce technical products. They produce software products. They produce technical hardware products. What about non-technical companies? Let's talk about construction specialties in which I'm a COO as much as I am a CTO. I'm in charge of the day-to-day operations of the company, but I'm also the only one who can do anything significantly technical.Randy Burgess: Yeah.Don VanDemark: That goes back to your first CTO role, I think, which is one of those where yep, we brought on a new person. Okay. I've got to go set up the mail account for them. I've got to make sure their computer is set up properly. I've got to go ahead and install Office and all those various sentry things for a non-technical company. This is really where we start to talk about the time outside of work too. As we're adding people there … We're adding people because myself and the other person who do a lot of the operations work, that's the bulk of our day is making sure that work that comes in gets passed back out to the proper people and finding new people to do work in new areas. That constitutes the bulk of our day. I don't have the time in eight hours a day to build a better system. We're [inaudible 00:25:35] things together using Trello, using a couple different …We stitch it together and it works, but in my head … I think we've had this discussion on the side in the past. There are a thousand project management solutions because everybody has their own way of doing things. That's the exact case we have here.Randy Burgess: To the scenario you just brought up, let's say … I've got a hypothetical. I am running a company. It's non-technical or technology is not its focus. It's delivering a service. A computer system, custom app or whatever is not how they make money. I don't want a technical manager that is building things from scratch for my company. Now this goes into the buy versus build discussion, which I'm sure we'll have in a future episode, but most likely, in the majority of cases, you're not going to do a build. You're going to do a buy. That's what you're talking about, stitching together different systems to make your own business process work.In that case, I don't want my technical manager to be a pro at hands on coding. I want them to be a pro at looking at outside solutions that are affordable. How are they affordable based on our budget and the return on investment of that outsourcing? Be able to take the stitching together is huge because if you're able to take two disparate systems and make them work together, no matter how … It may not be that difficult. It may be a little janky, but if you can get that done without doing a build, it's a humongous win for your company.Don VanDemark: Let me stop you right there for a second.Randy Burgess: Sure.Don VanDemark: I think you're on the thread of something and I just want to capture it before we go further.Randy Burgess: All right.Don VanDemark: You're right. If you buy the systems, you don't have to be spending the money building something new. I do think there's a very, very important distinction here though is whether it's the CTO or whether it's someone you hire, it's also vitally important that as you stitch together these different systems that you're buying, you have someone who can truly stitch them together using APIs and get them talking to each other. That's the problem we face right now is we have a number of systems that we're using to manage our work. None of them work together. That's where I've got to spend some time stitching it together so that they truly flow better.Everything we use works great, but we end up … When we take in a new piece of work, someone, either me or usually the other person who works with me on operations, we literally sit down, type up the information of the work in one system, turn around and type up that same exact same information somewhere else.Randy Burgess: Yeah.Don VanDemark: That right there is a loss of time that hopefully over the next three or four weeks, I'm going to be able to at least put those two pieces together. Once I've got those two pieces together, we only have to type it once. Then once I do that, I think I'll be able to tack on other things. Yes, I don't need to go build Trello. I can use Trello to hold all our work items, but I do need to build or have someone build something that stitches it to everything else we're doing.Randy Burgess: You don't need a CTO to do that. You need a CTO to hire someone to do that.Don VanDemark: Agreed. You need someone … I won't even say a technical manager. You need someone who's aware that those things exist. Okay. Again, we're talking about a non-technical company. We're talking about a construction company, okay? A construction company that if you hire construction managers may not get exactly how all that works. There are some that would. There are some who are very technically savvy and they get all that, but certainly understanding that it's even possible is sometimes the real issue.Randy Burgess: Let me jump in with one last point to make about … Something for a manager or CEO hiring their first developer or someone on their team to do a build.Don VanDemark: Sure.Randy Burgess: If you hire a developer and you want them to be hands on at the beginning and not doing much managerial stuff, you probably make your determination to hire them based on their technical skills in development and all their time is focused heads down on building. Down the road, when you grow and if that person does not exhibit developments or management skills, communication skills, but they're great at code, you've top-leveled their title, which maybe not … May not be a big deal in a small business scenario, but it does matter to people.Don VanDemark: For sure.Randy Burgess: One of the big concerns that people should think about is is the title a hindrance for future growth if that person doesn't actually end up being a management candidate?Don VanDemark: Right. I do think you see startups not hire their first developer as CTO in title. You will see them as Vice President of Development or Lead Developer or they will use some other title to give themselves that room to say, "Okay. Now we can bring somebody over to do the management or if everything works out great, we'll promote the person from within."Randy Burgess: Yeah.Don VanDemark: You're absolutely right that that first … You have to be real careful with titling that first person, first technical person, because if you title them CTO and they can't grow into the management part of it, you're going to have to give them a different title, probably lower their title, which may cause them to leave.Randy Burgess: Yeah.Don VanDemark: Or you're going to have to just completely throw out titles and do something funky.Randy Burgess: There ain't no thing as a senior CTO unless you're just calling them old.Don VanDemark: Exactly.Randy Burgess: I'm not there yet, but I'm looking on the calendar. It's not too far off.Don VanDemark: No.Randy Burgess: All right. I think we're at a good stopping point for today. Good conversation. I think this is something that definitely comes up in the smaller business space and still comes up in the bigger companies. I still have people ask me … They're trying to hire for a big company and they still want a CTO that codes. I'm like, "You have 30 people on your team. How are they going to have time to talk to anybody?"Don VanDemark: Certainly. I've certainly faced that issue of when moving jobs, having that discussion of, "Okay. Yeah, we've got a 20 person technical staff doing java," I'll say. I'll just pick something that I'm not real strong in. Doing java. "We need a senior technical manager." Not even CTO. Your technical manager. That person has to be in the code. That was always my question is what are the job responsibilities? It sounds like the job responsibilities are managing the team. Why do they have to be in the code? Do they have to be able to read the code, understand the code? Yes. Do they need to understand all the corners, nooks and crannies of the code on their own? Probably not. I can certainly have one of the developers walk me through the issue and with the background that I have, certainly understand what's going on.Randy Burgess: Yeah. All right. As we finally wrap this up, how is hands on your development going with your newest project?Don VanDemark: Yeah. It's just a little fun side project that I'm using to learn, right? That's the other part is learning new technologies is always a good idea, too. It's coming along fine. I'll probably be able to get it out there doing its little thing here in the next week or so. Then everything I've learned from that, I'm going to turn around and use to help build that stitching together that we were talking about for construction specialties.Randy Burgess: Yeah. Sounds cool. All right.Don VanDemark: What are you coding on this week? Is it going to be more of the HOA Done?Randy Burgess: HOA Done and I am working on that side project for Caption Point. The open and closed captioning nonprofit open source project. I've got to learn Electron as for one of the components. Dabbling in new tech is the fun side thing. The problem is always the time available to do it is fleeting.Don VanDemark: Sure.Randy Burgess: That's what I'll be working on next week. All right. Good talking to you. We will talk more next week.Don VanDemark: Sounds great. Thank you, Randy.Randy Burgess: Later.Thanks for listening to the CTO Think Podcast. If you like what you heard, please share a link to the podcast with your friends. Show music is Dumpster Dive by Mark Waller, licensed by PremiumBeat.com. Show notes and previous episodes can be found on our website at CTOThink.com. For questions, comments or things you'd like to hear on future shows, please email us at advisors@ctothink.com. For notifications of future episodes, please sign up for the CTO Think newsletter, also on our website. We'll keep talking next week.