CTO Think Earl Morris: Recent Episodes
CTO Think
How do you choose the best hosting options for your product or firm? This week, we discuss the thinking in a choice between self-hosting, managed hosting, cloud options, and the new buzz word: "serverless".
Notes * Don is headed to Gainesville for the Gator 100 ceremonies where both of his firms are being recognized as top 100 firms for growth by University of Florida alumni * Randy worked as a substitute teacher for the Northwestern Coding Bootcamp full-time program for two days * AspirEDU went straight to Heroku for their hosting * Randy started with a desktop computer that sat in the middle of the room, to a closet rack system, to outsourced co-location * Some of the biggest negatives of cloud vs in-house is cost or lack of control/flexibility * When Amazon Web Services East goes down, everyone seems to be going down at the same time, but you can let AWS techs take care of it * Nobody seems to talk about the dev ops people required to run a system if you switch away from a managed provider * Everytime you need to go directly to AWS, there's a significant time investment to get things launched * The less work our team handled on-site or on-team always had benefits from an efficiency standpoint * Thanks to Jeremy Lasich for his contribution to our Patreon campaign to produce transcripts for each episode.
Links * Gator 100 recognizes the 100 fastest-growing Gator-led businesses in the world * Northwestern Coding Bootcamp * Amazon Web Services * Google Cloud * Microsoft Azure * Heroku - Managed hosting on AWS * Now – Realtime Global Deployments * Linode - Linux azure.server hosting * Netlify - app hosting * Wes Bos - tutorial producer * Don recommends a list called the Inc 5000 Inc 5000 Apply Guide * Randy recommends Stephen Grider, an excellent tech tutorial producer * Patreon: CTO Think Podcast is creating Episode Transcripts for Accessiblity
Closing Thanks for listening to the CTO Think Podcast.
Shownotes and previous episodes can be found on our website at www.ctothink.com
Reviews on Apple iTunes are always appreciated and help promote the show.
Patreon contributions help us to produce transcripts, which allow people that are deaf or hard-of-hearing to access the show.
For questions, comments, or things you'd like to hear on future shows, please email us at hello@ctothink.com
Show music is Dumpster Dive by Marc Walloch, licensed by PremiumBeat.com
Voiceover work by MeganVoices.com
You'll hear from us next week!
We discuss the importance of a work-life or non-tech balance for someone building a career in technology. Do folks need to set aside a specific amount of time, or any at all, not working on things related to their job?
Notes * We've launched a Patreon campaign to raise funds for per-episode transcripts. * Some people feel the need to adhere to a strict 9-to-5. * The source of the rigid 9-to-5 work-life balance theories are important to consider. * Wealthy folks, or folks that have already "made it" may have a different perspective than folks trying to now launch a company. * Do the people touting a balanced philosophy, now, did they follow that same philosophy when they were working their way up? * People that have mastered a craft may not have a lot more to learn. * The work/life philosophy out of Silicon Valley stems from the investor/investee relationship and expectations. * The strictly 9-to-5 philosophy can feel very restraining to some people. * If a person has the goals to be in an innovative field, to make more money, and to manage more people, and their philosophy is strictly a 9-to-5 learning program, good luck to that. * The life constraints that people face: multiple jobs, debt, family, health, all weigh on a person's ability to focus on learning outside of a standard workday timeline. * Don recommends a book named Shadow Divers, by Robert Kurson * Randy recommends a newsletter called SoftwareLeadWeekly, publised by Oren Ellenbogen
Links * Don's Recommended Read: Shadow Divers: The True Adventure of Two Americans Who RIsked Everything to Solve One of the Last Mysteries of World War II * Randy's Recommended Read: SoftwareLeadWeekly * Patreon: CTO Think Podcast is creating Episode Transcripts for Accessiblity
Closing Thanks 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 Apple iTunes are always appreciated and help us spread the word about the podcast.
Show music is Dumpster Dive by Marc Walloch, licensed by PremiumBeat.com
Shownotes and previous episodes can be found on our website at www.ctothink.com
For questions, comments, or things you'd like to hear on future shows, please email us at hello@ctothink.com
For notifications of future episodes, please sign up to the CTO Think newsletter on www.ctothink.com
We'll keep talking next week!
Transcript Intro: Welcome to CTO Think, a podcast about leadership, product development, and tech decisions between two recovering Chief Technology Officers. Here are your hosts, Don VanDemark and Randy Burgess.
Don VanDemark: Randy, what's going on in your world this week?
Randy Burgess: Nothing too big. I think my challenge of the week is dealing with APIs. What's more interesting is more on the human side of the API than it is on the tech. I'm working with a company on behalf of a client, and trying to get information about a semi-documented API that is not responding back consistently with what is expected. It's proving to be a challenge because the folks supporting it don't seem to have a clear technical leader or point person to talk to. I'm having to do lots of different email communications between the client and his contact.
What is more than clear to me with having a product that has to interface with outside APIs is that there are two facets of support, technical and people, that are still necessary, and that dependency is something that you really have to look at for how your product may depend on an outside company, product team, or whatever. That's just something that came up. I've also been learning a little bit about GraphQL, the new API, kind of paradigm approach. Even if I do like that newer system versus REST, like a RESTful API, there's still that people part that doesn't change. This week, it hasn't been hard. I've been making progress, but that's been the challenge of the week so far. How about you?
Don VanDemark: Sure. Sure. That's all interesting, because that doesn't necessarily flow into what I've been doing this week, but it's something that I've been having to look forward to, and I do mean having to look forward to. The work we do with Construction Specialties, we use a number of different systems. One of the systems we use has an API, or I've been told it has an API. I requested access for it, and the response back I got was, "You're not big enough. We don't want you to use it because you're not big enough." I'm like, "Wait a minute. I'm not sure that makes sense. Maybe it makes sense to you, but it doesn't make any sense to me."
Then one of the other systems, I had to ask a non-technical person to hook me up with their IT department, and I'm still having trouble getting that access in order to see if they even have an API, because if they don't have an API, then I can't tie the systems together, or the subject of screen scraping comes up and you have to decide whether … You have to look at the robots.txt file and all that to see if you can even do that. Anyway, it was interesting that you brought up APIs, because that's something I'm going to be wrestling with very shortly.
Randy Burgess: Well, it goes to show, just like I keep telling students of technology, people that I've taught or I'm being introduced to that are newbs to the whole system, this is a tech job. What you're trying to do is still technically-based, but people are still a huge part of it. I think what you ran into was policy, but it's still people that choose the policies and enforce them. You still have to be able to communicate with people, work with people, get past people to get things done. It's not just about zeroes and ones.
Don VanDemark: Right. We do a decent job here of talking about things we're going to talk about in future episodes. I think we might have to come back to this at some point and just wrap a whole subject around technology working with non-technical companies, because that's easily the case I've got here. I've got stories that I can bring from my past as far as that goes. We'll get into that another time.
This week, what I wanted to ask you about was, going back to the whole idea of anti-fragile and things like that, one of the ways I feel that I've made myself somewhat anti-fragile is I'm always out there learning new stuff, figuring out new things. I'm not an expert by any stretch of the imagination, but I make something work, and then I at least have the knowledge of, "Okay, I understand some of what's going on here, so I can speak above just a basic level."
There seems to be a call to movement. That's a strong word, but there seems to be a movement towards technical people need to stop doing their technical jobs after 5:00. They need to do nine-to-five technical, and then the rest of their life needs to be non-technical, away from coding, away from … I'm going to use my trademarked phrase here. It depends, because I find myself … I find it very hard for me to do that on a consistent basis. Certainly, we'll go off and do non-technical things, but I'm always drawn back to technical things. I'm not going to call it work-life balance. I'm going to call it tech, non-tech balance. What is your personal tech, non-tech ratio, and do you find yourself varying it from time to time?
Randy Burgess: Well, I guess let me back up a little bit to the actual argument, because I think some people take nine-to-five literally. I see people, whenever the debate comes up, they get worked up about nine-to-five. People are like, "I work better past 6:00 or 7:00." I'm like, "That's not what we're talking about." I think it's about self-awareness of your energy and burnout prevention more than anything else, and maybe knowing when you're at your peak, because there's people like I can … My personal wavelength of technical energy and learning can go for three days straight of just barely eating and drinking, and just being ultra-focused, and then I need definitely a day off. In the past, I didn't do very well. When I was younger, I didn't do very well regulating it. I think now I've started to notice when I'm not … Nothing's sinking in or I'm watching something or reading something, and I'm drifting off in a different thought pattern.
Personally, my focus levels for working and doing things starts around later in the day, like later to most people, maybe like 10:00 AM, and then can go usually to 7:00 or 8:00 if it's strictly work-related. If it's project-related, then I have to shut things down much earlier, because it's something I'm interested in trying to do. It doesn't stick to a daily routine. Last night, I remember I was working up to about 8:00, and I just yelled to Megan, "I'm done." I don't remember what it was. Maybe I just got something to work. I'm like, "I'm done with this," like, "I don't need to do anything else tomorrow, can take a rest." I think I start to feel the signs of, "I don't want to be sitting here anymore," and I really just need to get this done, or I just need to cut it so that I have energy tomorrow to keep going. That's how it works for me right now.
Don VanDemark: Sure. What I'm also talking about is the concept of improving yourself outside of work hours. We've got kind of what you talked about, which is kind of the circadian rhythm that you go in as far as work every day. It varies from day to day. I know just in the past week, there have been days I've been sitting here at 1:00 AM coding. I am one of those people that codes better from about 10:00 PM to 1:00 AM. I'm sitting here way after hours coding stuff, but the argument I think I see a lot of is, "I don't need to spend my personal time, my free time, improving myself. My job is what's going to help me improve myself."
I find that limiting. (A) You've got to have a super understanding job and management structure and all that that they're even going to give you time to learn stuff that's not related to your specific job. If you're not out there doing stuff that's not related to your specific job, you're not growing. It's that simple. I find the concept … I'd like to know where this concept is coming from that people feel they don't need to be growing outside … and I've met people like this. If that's the lifestyle they want to live, I'm not going to judge how they want to live their life, but it's just so different to the way I've been doing things. What do you see?
Randy Burgess: I think you got to look at the source of the statement, because I feel like when I hear it from certain people, there are certain well-known social media personalities that really do tout this stuff a lot. Philosophically, people burning out and taking a break, or taking a break to prevent burnout, is not a bad thing. I'm not going to say that these people have a bad philosophy, but if they are wealthy and have kind of made it in their sector, then yeah, of course, now you can start to sit back and smell the roses, so to speak. If you're driving to get yourself solid, build retirement, pay for kid's college, family, get your company, your startup lifted off the ground, making revenues, paying your employees, making payroll at the end of the month, you have a much different perspective than that person that has already gone through the process of doing that and is now talking about, "Oh, I don't work past 5:00."
Well, yeah, but when you built that product, were you really on that nine-to-five? That's what I want to ask that person, because if they were, then cool, they're speaking from the entire … from the day that they started the product or the company to now. But what I want to know is, knowing what I know in terms of how hard it is to build products that last, did you really follow that at the beginning, before you … Because there's one specific person. 37signals is a company who I do like their philosophies. I think the way that they talk to companies about this type of stuff is a big deal, but I don't know that they followed back then when they were starting what they follow now. It's just a matter of you have to take it with … You have to consider this philosophy from the person touting it based on where they were when … where you are in their time span, timeline, and where they are now, because I think it's really easy when you have all the money you need, and the company with the revenues and the employees doing things for you. That's a much different thing.
Going back to your specific point of self-improvement, if you've already mastered a craft, there may not be a ton more you need to self-improve on. You may be on autopilot, because you've done so much and you're the master of it. You're doing other things. Maybe you're racing cars. You're learning how to … Boats is your thing. I don't know. You got a hobby now, because you can afford to do that. You're not driving for something. I can say that, for me, I keep doing self-learning, because I see so many things I want to learn and I haven't made it in the sense of I don't have to worry about retirement, I don't have to worry about healthcare, salary is taken care of. None of those things are like … I'm managing them now, but they're not something that if I just sat back on a beach for the next year, I'd be like, "Oops, I should have been making some money." Who that person is saying that, I want to know where they are in their career, their timeline, and how far they've reached.
Don VanDemark: It all comes down to a balance as well, because I do not … I also don't subscribe to what's essentially the opposite of this argument, which is there is a segment of … I'll even say it's a segment of Silicon Valley that is if you're an entrepreneur, you live, breathe, eat, drink your product 24 by seven. You don't stop until you've made it. That goes to the other extreme, which I don't think is healthy and I certainly don't think is sustainable, and makes for poor decisions as well. I think there's a balance, and it is personal. There are people who want to do those things, just like there are people who want to be entrepreneurs and have the makeup to be an entrepreneur, and that's not saying that those that don't are lesser people. They just have different personality traits that allow them to be different type of business people, allow them to be stronger in other places.
Randy Burgess: The Silicon Valley perspective comes from venture capitalists. [crosstalk 00:16:11]. If you hand over a couple million or less, any amount of money you send someone, the philosophy in Silicon Valley is driven by, "Hey, we gave you a pile of cash. Now make us more money off of it." The thing is, instead of it being a philosophy from, "Hey, you had an employer who drives you hard," it's this entire community that represents Silicon Valley's money system saying, "Hey, entrepreneurs. If you take money from us, we want you 100% focused on everything. We don't care about family life, real estate pricing, anything. We want you 100% focused on what we hired you to do." No one considers it being hired, but you've been hired to make someone 10 times their investment. That comes from the source of that money, and so that philosophy, it's termed a philosophy but it's really just the age-old adage of, "You work for me. I don't want you focused on anything else." That's how I see the Valley's opinion of it, which if you sign up for it, great. Just know that's what you're getting into when you take that cash.
Don VanDemark: Yeah. This just buttresses your point about where people came from, because usually those venture entrepreneurs did that previously. Those venture capitalists are prior entrepreneurs who did live and breathe whatever product they grew to make their money, to be venture capitalists. They expect that same from whomever they're giving money to. Yeah, so I think we've come down to, (A) there's a balance there and each person has to find where their balance is, and I just come back to the point … What bothers me the most about that philosophy, going back to the original question, the philosophy around, "I don't need to do more than my job," is it's so constraining.
This is something I actually personally feel, because I have been the manager of really intelligent people. They know one or two things, and it's not like they're masters of those one or two things, which I even think, if you're a master of something, you need to go find something else to learn, because you need different perspectives. They know their thing. They're making a decent enough living that they're comfortable with, so they feel, and this is people within big monolithic enterprise companies as well, they feel they're safe. They've got their salary. They can just ride this out for the next 20, 30 years. That's just not the way the world works right now. That salary, that job, is vulnerable, and you have to control your own destiny. If you don't expand what you know, you're not controlling your destiny. You're letting it come to you. You're making yourself fragile-
Randy Burgess: Well, that's-
Don VanDemark: … so you're not being anti-fragile.
Randy Burgess: Yeah. I would say that my learning, what I choose to focus learning time on, which I do all the time and I always have, is in a way a hedge against the rapidly-changing environment of technology. If I was still doing what I started out doing 20 years ago, I would be doing ASP.NET, ASPX, or whatever the … I don't even know what they use now on the Microsoft side from back-end stuff, and/or PHP and Drupal was the content management system. Once I said, "You know what, I'm frustrated with these tools. This Rails stuff looks more interesting," that's when I started dabbling in Rails. Five years later, I opened up huge doors with better productivity and learning more development, because I was doing the slight hedge on the side of learning new tech.
Now, I'm at the same point right now with Rails that I was back then, because I look at these new tools, pretty much like Node and JavaScript-only back-end, front-end frameworks. I look at Elixir and Phoenix for another, like the kind of possible replacement for Rails, Go, all these different frameworks that are built more on modern tech … or more modern tech and speed is kind of their bigger focus. I'm not totally sure. Even when I'm building the new HOA Done prototype, I'm still using Rails. Why? Because I build really fast in it, but I'm still … To your point, things change so fast, and the whole industry will break.
Now, it's like I have to make sure I've got a backup plan. That's just my personality. I want to have the little things in the background of like, "Okay, the long-term for what I know now is not going to last, but I've been paying attention and I can quickly jump on the new trend." You have to be careful, because you can definitely jump on a trend that dies really quick, but for me, I'm only comfortable doing that. I'm not comfortable saying, "I'm just a Rails developer," and that's it. I can't do that, plus the fact that I have to manage people that know things that I don't. I have to understand something that they know, which is kind of where the CTO, the tech manager, responsibilities are in place. Sure, you can hire everything out, but if you don't have any knowledge of what that person's doing, they better be good. They better be able to deliver, because you are kind of hamstrung if they don't.
Don VanDemark: This kind of ties back to last week as well. There was a period of my career where I was handed an assignment to manage a group of technical professionals supporting a company's SAP instance. I knew nothing about SAP. It was foreign to me. All the technology was foreign to me. The methodologies were not something I was used to. It's a whole way of thinking that if you're not in that space, you don't have that knowledge. I did poorly. That did not go well. I managed the people as best I could. I identified once I got there, I was like, "I'm way out of my depth here, as far as technical. I cannot even have an intelligent conversation about the technical side of this, so I need to manage the people, see if I can figure out who I can lean on to learn things from, and make the best of it."
Fortunately, that was a short assignment. I was a transition manager in that case, so I did my three months and I was out. From that moment on, if they even approached me with an SAP assignment, I said, "That's probably not best for me," just because it … Yes, if you want me to go spend time learning it, I will go do that. It holds no interest for me though, so I'm going to be trying to learn something that holds no interest for me.
Randy Burgess: You did learn something-
Don VanDemark: I lucked out-
Randy Burgess: You did learn something about SAP. You don't ever want to do it again.
Don VanDemark: I'll tell you. I don't even know enough about the product or anything to even say it. It does wonderful things, I'm sure.
Randy Burgess: That's a nice way of [crosstalk 00:24:59].
Don VanDemark: If they're listening and they want to be a future sponsor, we'll take it.
Randy Burgess: It makes people money. I do know that. That's as much as I [crosstalk 00:25:05].
Don VanDemark: Oh, for sure, for sure. Really, I wanted to bring that up today because it's been gnawing at me. It's been gnawing at me for years, because like I said, I know people that I'm like, "You could be so much better. I'm not going to pass judgment on your life decisions, because you've decided that it is much more important at every stage of your career to only spend your eight hours of work. If that's what you want to do, go do that. I'm happy for you. I just know you can be so much more."
Randy Burgess: Well, so I guess the rub is, if this person that has that philosophy tells you, "I want to be a CTO. I want to be in a brand new, innovative technology system. I want more money. I want to have more responsibility," if those are the goals that that person has in our field, in a technology-based product company, whatever, and then they still have that attitude of, "I'm going to do my nine-to-five, my set amount of time, and I'm not going to invest time on my own elsewhere," I would say, "Good luck with that philosophy in our field," because our field is drastically changing so much. I'm not going to hire them for a role that I need innovative thinking and learning on the fly, so that's … I would say that you are limiting, that person is limiting their opportunities, based on what my knowledge of the industry is.
If their philosophy is, "I like to," for whatever my outside interests are, let's say family, raising horses, race car driving, what have you, and they're like, "I don't really care. I'll do what I'm paid to do, and that's all I really care to do. I'll deal with later if my position becomes obsolete or the tech I'm working on is obsolete," and they're fine with that, they can live comfortably and happily like that, that's great, because in some cases, I want to hire people. Just do this one thing for me consistently all the time, and that's all I need you for. I don't really have a problem with that. I don't relate to it very well. That's the difference for me, but it depends. So many times I hear from people, "I want to be in this cutting-edge, innovative space. I don't go home and learn things on my own," I'm just like, "Well, that's not how I've seen it work very well." It's about motivations and goals, I think, to some extent for some people.
Don VanDemark: For those who are younger than you and I, just a fair warning that as you age, your attention span, your ability to retain information, does go down. Your learning speed does go down. I know that it's certainly affected me to some degree is I'm probably not as fast a learner today as I was 20 years ago. Now, I can use some of my experiences to learn things faster. When I went back to get my MBA, I was a incredibly much better student than when I was getting my bachelor's degree. There is that sweet spot right there in, I think, the 30s that is probably your prime time for learning, maybe late 20s and 30s, which is your prime time, because you've got enough life experience to figure out how you learn, and you've still got the energy. You get up a little bit higher, and some of that starts to deteriorate. The synapses don't fire as fast.
Randy Burgess: I agree with you. Definitely from the physical brain power, mental retention side, I totally get that. The difference for me now is I think either experience, prior knowledge, what have you, I am more efficient with learning, because I recognize those boundaries, those constraints, and I don't pay attention or refocus or try to retain more than I can. I actually have been learning things faster, because I'm only focusing on the important parts, realizing I'm going to forget this part anyway. I just want to have the confidence, like on the GraphQL thing, there's a whole section of what I'm learning about the setup. I'm like, "You know what, by the time I actually start using GraphQL, this setup part is not going to be relevant," because they've already talked about the new version coming out in a few months. I'm like, "Okay, I'll understand what they're talking about, but I'm going to skip this as a 'I need to spend a lot of time.'" I've got the video that I'm watching going at like 1.5 or two times speed.
If you were to say, "Write out this config file right now as part of having learned this," I'd be like, "I don't know. I have to look it up again." But if I told you what this technology means for us to move forward with it, I've learned a ton in just the last few weeks on this subject. I think in the past, I would try to read every book, watch every video, retain it, practice it, all that stuff, and now, I think I've shortened my learning that I know what I need to do to a much smaller timeline, because I'm like, "The brain won't retain every detail. I need to have a very cursory understanding of this at this point. I should understand this more in depth at this point." At some point, I can say, "All right. Next time I need to learn this will be when I'm using it."
Being able to do that allows me to learn so many more new things, rather than think, "I need to do freaking three months of GraphQL to be an expert in it." That's where age and experience has changed the learning side for me is becoming more efficient at it. I would agree with someone that says, "Well, I do need to learn, but I don't need to learn as in-depth as people think I need to learn." I could totally catch on to that philosophy in a heartbeat.
Don VanDemark: Well, especially if you're not trying to execute right now. If you're doing it to learn the technology, learn the paradigm, you're absolutely right. You don't need to learn the setup and a lot of that stuff, because by the time you go to execute it down the road, you're going to have to pull somebody else's new config file or whatever to keep up with the times. I do want to add one caveat that I think we need to … Just to throw it out there, make sure that we see all perspectives, obviously this doesn't apply to everyone, right? Someone who's got to go out there and work two jobs in order to put food on the table for their family, absolutely, I've been there. I've been there where you have to be constantly earning money in different ways to just put food on the table. That was in the middle of raising a family, so you got to take your time out for your family and all that.
There are caveats, absolutely. I will say that the way I approached it, and this isn't possible for everyone, but the way I approached it is when I went and tried to get that second job or that second and third stream of income, I tried to make it in something that I was learning or growing in. To some degree, that's how you and I met, and because I was out there putting something out there, and it was something you needed at that moment. There are caveats around that, and not a one size fits all.
Randy Burgess: I agree with that 100%.
Don VanDemark: Cool. Thank you. I feel lighter. I feel I got all that off my chest, and the years of that weighing on me are gone now.
Randy Burgess: Well, it was definitely a good subject that comes up frequently in other people I talk to. I'm pretty sure the work-life balance issue in this industry will not change for a while, in terms of being a debate. There's so much going on in technology that focus and time management is going to be a challenge. Yeah, I think it's a great subject. We can wrap this up. We're going to try to do a new segment at the end. This is kind of common amongst a lot of shows. Recommendations, do you have a recommendation or recommended read for the listener that they can maybe check out? We'll put it in the show notes.
Don VanDemark: Sure. As you know, as you personally know, I consume a lot of books. For a few years, I was trying for 52 books a year. Some years, I would make it. Some years, I wouldn't. I don't believe in abridged books. I think if you're going to read something, you got to read the whole of it. What I'm trying to focus on this year is I may not make my 52, but my 52 is usually about 80 to 90% fiction and the rest nonfiction, which fiction's a lot faster to read. You can skim faster and still pick up all the points. Nonfiction is a little slower, so I'm going to try and pick up some nonfiction books.
One I was recommended to read was a book called Shadow Divers. It's by Robert Kurson, K-U-R-S-O-N. It's about wreck divers, so people who go and dive on wrecks. This particular one was about the set of wreck divers who happened upon a wreck that it took a little while to identify. They finally identified it was a submarine, and not only a submarine, but a German submarine in New England waters where there were no recorded battles of a sunk German sub during World War II.
A lot of the book was about the technical part of the diving. They were going to depths that were right at the edge of what humans can do with the equipment they had at the time. This was in the '90s. Some of it was they turned into historians. They went to Washington and dove into the Naval Archives. They went to Germany, talked to people over there, trying to identify this submarine, because it had no identifying markers. They couldn't get to all parts of the submarine and find things that could identify it. It was a fascinating book. What do you have?
Randy Burgess: I'm going on the business side of stuff. I like to use aggregators to bring me information. There's a lot of people out there that go out and harvest links to different blog posts of the week. I just subscribe to a ton of those, because I can go through their work, having gone ahead of me and finding articles that are worthy. It's faster for me to do that than to go through a feed reader and just find stuff on my own. The one that's very relevant to, I think, what we're talking about week-to-week is Software Lead Weekly. We'll put the domain in the show notes. It's by, I think, a guy that is in Tel Aviv. Oren Ellenbogen I think is his name.
All he does is he finds a bunch of more managements … technical management-related links, some humorous, some educational. A lot of them are very good. He also wrote a book that I can talk about in the future that is helpful for people moving up into the tech management role. I think Software Lead Weekly is a really good source of technical management-related posts out on the internet that people can read. I recommend it as something for people to subscribe to and check out in the future.
Don VanDemark: Yeah, that's really good. That's really a good, good choice.
Randy Burgess: All right. Well, I think we can wrap it up. Good talking to you, and we will talk next time.
Don VanDemark: Sounds good. Thank you. Have a good week. [crosstalk 00:39:00].
Closing: Thanks for listening to the CTO Think podcast. Show notes and previous episodes can be found on our website at ctothink.com. Reviews on Apple iTunes are always appreciated and help promote the show. Patreon contributions help us to produce episode transcripts, which allow people that are deaf or hard of hearing to access the show. If you have feedback, ideas, or want to be a guest, please email us at mcwny44@peerh.com. Show music is Dumpster Dive by Marc Walloch, licensed by premiumbeat.com. Voiceover work by meganvoices.com. You'll hear from us next week.
Randy is a CTO that codes almost daily. Don has found it difficult to string together multiple days where he's able to code for his current roles. Today, we tackle the topic of whether a CTO or technical manager needs to be able to code to be effective at their job.
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."
Links * Patreon: CTO Think Podcast is creating Episode Transcripts for Accessiblity
Closing Thanks 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.com
Shownotes and previous episodes can be found on our website at www.ctothink.com
For questions, comments, or things you'd like to hear on future shows, please email us at hello@ctothink.com
For notifications of future episodes, please sign up to the CTO Think newsletter on www.ctothink.com
We'll keep talking next week!
Transcript Don 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.
Don brings up the subject of chaos, based on a book he's been reading, Antifragile, by Nassim Nicholas Taleb. We discuss the merits of test driven development, unpredictability, and how technical managers can work towards a more resilient product in the face of inevitable failures.
Notes * Antifragile represents a system that improves under chaos * In a well-tuned org, with test cases and adaptive practives, software systems can improve under chaos * Netflix and Amazon built their systems with chaos in mind. Expect failure and build with failovers. * For a system to be antifragile, its parts must be fragile * To build a resilient backend can be very costly * Asking the executive team about what's feasible for downtime vs the costs of a completely redundant system is a good starting point * Understand what the business needs are during a failure event * Test-driven development can help a firm quickly visualize how changes made cause butterfly effects across a system * The conversation moved towards the subject of complacency, which will be expanded upon in a later episode
Links * Nassim Nicholas Taleb website * Antifragile: Things That Gain from Disorder (on Amazon) * Nassim Nicholas Taleb on Amazon * Chaos Monkey * Amazon Web Services EC2
Closing Thanks 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.com
Shownotes and previous episodes can be found on our website at www.ctothink.com
For questions, comments, or things you'd like to hear on future shows, please email us at hello@ctothink.com
For notifications of future episodes, please sign up to the CTO Think newsletter on www.ctothink.com
We'll keep talking next week!
Transcript * Transcripts by Rachel VanDemark
Randy: Welcome to CTO Think. I’m Randy Burgess.
Don: And I’m Don VanDemark. Randy, what’s been going on in your world this week?
Randy: Normal work for the most part. Nothing extravagant. Mainly for the two clients I am working for, getting their new projects kind of lifted off. One is adding a new nationwide shipping. I talked about that before. And then a different client is reestablishing their ability to push their product to kind of a third party distributor and hoping to gain revenues with that, so that’s a lot of communications with people more than code at this point, which is kind of part of the gig. So, doing that, and then I have gotten back to working on the HOA Done application, which is a small tool for small condo associations, homeowners’ associations, and so that’s kind of been the side project I have been working on. What about you?
Don: Same as you - same old, same old. We’re working through everything we have been talking about the past few weeks. Right now, for AspirEDU we’re in the middle of discussions with another developer, looking to bring someone on who is working his way into the development field. Been doing a lot of side projects, been doing a lot of small stuff. But his skill set that he is learning is right in with what we need, so been talking to him and that may be something we go forward with here in the future.
Randy: Cool.
Don: So, we’re going to do book club this week. So, I read most of - I am not going to say I read all of it and we’ll talk about that in a minute - read most of a book called Antifragile by Nassim Nicholas Taleb, who is the same author who wrote Black Swan. So, the term “antifragile” is meant to mean a system, a person, anything that gets better, that thrives under chaos. So, it is different than resilient, which can stand up to chaos and absorb it. Antifragile is the opposite of fragile in that it thrives under chaos. The problem I had with the book was essentially that he made the same point 10 different ways in the first half of the book and it didn’t seem to be progressing, so I didn’t finish the book, but the point came across just very clear in a very interesting concept. So, while I was reading it I am sitting there going “you can equate this to the software systems we build”, and it sounds weird to say that software systems get better under chaos; but in a well-tuned organization, where you’re writing a lot of test cases and when you’re adapting your system based on what is being thrown on it, software systems DO get better under chaos. So, I wanted to talk a little bit about that today. How do you improve your software systems when things come at it, and how much do you invest in testing and that is the general direction I wanted to go with this today, so talk a little bit about how you approach those things.
Randy: Well, I’m curious about the book. Does he bring up Netflix at all?
Don: Not in the part I read, no.
Randy: The reason I ask is Netflix - they’re kind of at the forefront, at least publicly, with chaos testing, chaos management, because they introduced a library called “Chaos Monkey” which actually takes down pieces of the production environment randomly, and it forced them - I guess it was one of those ideas of we expect for pieces of our production to go down randomly, and therefore we will build a system where it just happens naturally and we will cause it. We will be part of the cause of that randomness, in theory. So, I have not used this library, but it has come up a number of times on some other podcasts I have listened to and just other things I have read that the idea is expect things to fail in kind of what the book is talking about, I assume, is building a system that can handle that and at the same time build the most resilient system.
And I think Amazon built their EC2 platform on the same idea because at the time, before we got AWS and The Cloud going full steam, the approach of all enterprise was to build huge racks of very expensive servers and build their entire platform on that with the idea that these expensive servers wouldn’t go down, and Amazon came in and Google as well and said that cheap servers that are expected to eventually fail is the more cost-productive way to build a cloud or a large server back end. So, their approach, like they just started building out tons of cheap server boxes and they build a redundancy level system that would take over when one dropped or one failed, and the life expectancy of these servers wasn’t very long and they found it to be much more cost effective. So, without having read the book that’s the first thing that comes to my mind - are those two scenarios of Amazon and Netflix and how they have approached Chaos.
Don: And it’s like he did study them and I didn’t come across the mentions of them, or they read - Well, they couldn’t have read the book. The book is not that old. But, one of the core tennants is for a system to be antifragile, most of its parts have to be fragile. So, pieces have to be able to break and you have to be able to work around that and be able to deal with that in order for the whole system to survive. So, those were two awesome examples. How do you put this idea together in testing? You can use Chaos Monkey but how have you done it in the past, just with plain testing, and how much time do you dedicate to test cases and making sure you’ve got test coverage and is 100% test coverage what you aim for or what are you aiming for when you’re building systems?
Randy: Well, I am going to admit that I don’t spend a ton of time on failure management. I feel like I outsource that to Heroku, who handles it on the AWS side for me. But what I have done, and this is what I did in the past - one example was I was working for a company that had a client, and they basically said we are going to put up this very small, simple app that will run for the weekend, but if it goes down the entire thing will fall apart. You have to keep this thing up. And so I approached it with the idea that I was using Heroku for the hosting of this particular app, and my approach was I am going to build a second, use a backup platform, that I expect Heroku will fail. I have no reason to expect it, but I just said it is going to fail and I am going to randomly switch the domain name to point to this other server and have that take over, and I had it do that like three or four times, just kind of like within the next hour pick a time, transfer, and then I was watching both sides - the Heroku and I think I used Engine Yard at the time. So, that weekend everything ran smooth. Everything ran on Heroku. Heroku didn’t have any problems, and this is maybe like three or four years ago, but that was how I approached that one scenario, and if you were to say, okay now take that one scenario and now you’ve got a longstanding system you need to deal with, there are a lot of big questions that come out of that because what I did for a weekend with Engine Yard and Heroku hosting was pretty cheap, but to build a resilient back end that completely is failover and sitting there ready is a completely different question on the cost factor.
So, that’s I think, as everything does, it starts at the very top. I think you go to your operations team or the executive level and say, in the scenario that our platform goes down for a specific amount of time, what are our thresholds as a company for that downtime? And the first instinct of every non-technical person is, it has to be up all the time. You can’t have downtime, but that is when it is upon you to say, okay, if we build this entire second platform to back up the first one, these are the costs, and I have had this discussion with executives that I have worked with, and they immediately change the tone of, well, I don’t want to spend double all the time for what may be an hour of downtime or even a day. That doesn’t fit, so it changes the conversation to what is the backup plan? Do we have a website that just states “we are down. Here is how you can reach us manually to get business done.”? Very cheap to do that kind of backup. Do you have a system that only has half the features or doesn’t persist data but allows interaction. There are a number of ways to mitigate downtime or things that are going wrong and still keep business going, and that is the discussion you have to have at the very top, I think, versus the whole idea of, let’s just have two systems running all the time. But it changes based on the business. Emergency systems don’t have that same kind of leeway. They have to be running all the time for a large part of what they do, but that is how I would say that that discussion with executives is how I first approach it - before I touch any code, before we set up any systems. Understanding what the business needs are at the level of failure on the main product and the main line, what is the business’s ability to keep operations going without a completely redundant system? So, that’s my long answer.
Don: That’s great. So, I want to step back to the beginning of that answer, and you said you don’t do a lot of testing on your own, you outsource a lot of that, and I want to make sure we’re delineating here. The type of testing, and the discussion we just had was around hosting, back end, hardware, that sort of thing. The question is also relevant to the test case’s side of the code itself. So, how much do you commit to testing on the code side? And that is where we start to write test cases before we even write the code with test-driven development or behavior-driven development. How much of that do you do with your projects? How much do you invest in testing in order to build what’s essentially and antifragile system?
Randy: Let me just put it this way: I am a TDD guy. Part of that comes out of me now working in the Ruby on Rails community, which is really strong on that, but I actually have a complete contrast in my career. For the first seven years, when I did a lot more PHP.net type of development, I didn’t do any test-driven development. I didn’t write any automated test in my code. If it came to, like, having an automated process walk through the code, like a person on a browser would, and test things, I didn’t do any of that. And I wrote code that broke. It took me forever to build and it wasn’t very maintainable. A change I would make on one part of the system would have a butterfly effect through the rest and I had no idea of knowing unless I tested everything to go alone with it, so that is the contrast to what you’re talking about now, which is a more automated software approach to development. And so now what I do, and I pretty much feel - I don’t believe in 100% coverage. I think is it almost impossible, especially with the use of API’s, which are difficult to test, that you don’t handle. But what I definitely do is strive for like an 80% coverage, where if I am writing a method or I am adding a feature there is some automated process that makes sure that, and in most scenarios, this code keeps running. And then every time I push a change, we test. We run all the tests, like all of them, even if it doesn’t pertain to that change necessarily, the idea is to catch any butterfly effects that you may cause and then every time we push to our server to staging, same thing. All the tests run. So I am huge on that and it is still a big debate in the software community that I am a part of about the value of it and how hard it is, and almost every CTO, technical manager that is in a discussion about it, always if they haven’t come up in that world, the pain of starting learning how to do it is really steep.
Don: It’s interesting if you think about it, and I think this is where age, experience plays a factor, you and I both Gen X-ers, mid career, that sort of thing. So, we did come up in the development world before there was test-driven development, before it was as widespread as it was. Your early years are very much like mine. “I don’t write software that has bugs in it; therefore why would I test for it ahead of time, right?” We have the luxury of living in that world and going “wait, I see so many benefits out of this test-driven development, and I do understand the pitfalls of not doing it.” Whereas, developers that have come up and have learned in this world and don’t know another world, it is ingrained in them to do test-driven development, so in one way it is easier for them because they are not fighting biases, they are not fighting all those bad habits. But they also necessarily don’t have the battle wounds, the scars…
Randy: So What has been the philosophy with of AspirEDU and testing? Because you are not the one doing the development, so what is your team’s philosophy?
Don: We do the same thing. We have automated tests that we go out there and run every time something gets committed. We’ve got a code coverage robot that sits there and checks how much our code is covered, and you’re right, the 100% code coverage is unattainable, likely, because of all the external factors. And it comes back to what you were discussing earlier.
Randy: Does that bother you?
Don: It’s also a cost benefit ratio, right?
Randy: Does it bother that whole lack of 100% coverage?
Don: Does it bother me? I won’t say it bothers me. Certainly when you have something fail that was not covered you start to Monday-morning quarterback it a bit and go “well, should we have had it”? That’s an easy answer - yes, probably. There are the “should we have had it?” to where the answer is “we might have been able to foresee that and we might have been able to write a test for that, and then there are the ones that are like “I am not sure how we would have envisioned putting that together in order for it to fail in just that way.” So, I think we learn from every time we have an issue pop up, and it gives a different flavor to the test cases that are written in the future but certainly there is no drive to get to 100%, and no, I don’t know that I lose sleep that we don’t have 100% coverage.
Randy: So then, going back to the book. You’ve read it, so going away from test driven. In a way, test-driven development is to prevent chaos from happening. Which I think it does. I feel like I build the code that my teams have built since I have implemented TDD as a philosophy into the developments, product development has been huge. I have no measurable way to talk about it. I can just say the code quality that my teams have been able to build with it is immense, and problems on the back end, the chaos, has been minimized and tremendous amount compared to what I worked on prior. I don’t know. What else did the book talk about that happens; like, you can’t test for it, things still happen out of your control, what did the book talk about, and then what have you been able to gather that maybe you should do more of or - I don’t know - maybe you’re like “this is out of our reach” kind of thing? I am not sure.
Don: The book doesn’t talk about it because the book didn’t really draw the parallel between being antifragile and software systems. Didn’t really hone in on that a whole lot. But it was that revelation in my head that yes, test-driven development aims to prevent chaos, but the way I see it is, when we’re building these systems and we’re using test-driven development and we’re building these test cases that come up, we are making our system more antifragile as it goes because we start with a set of test cases, we believe we’ve got good coverage, something happens. A bug happens, we have an issue; therefore, that’s chaos has entered the system, we’ll say. We then go fix the problem. So that’s the resiliency part of it and just fix the problem and then analyze how the problem arose. Write test cases to cover that area plus maybe peripheral areas around that, and in that way the software system thrived from the chaos. So, as long as we didn’t have a hard outage, to where whatever the issue was completely took our system down and we’ve got clients that are unhappy because of all that, as long as that didn’t happen and it was more of a “Hey, we had this bug when we hit this little thing so it popped a 404 page” or whatever the issue was. As long as it’s a minor impact that is certainly a good example of a software system was in one state, chaos entered the system, and upon completion that system is now stronger. That’s the parallel I am trying to draw here, so you’re absolutely right that test-driven development reduces chaos, but that’s kind of the point. It also helps you react to chaos and helps make the system stronger in the end, so that’s what I was trying to draw from it.
Randy: Makes sense.
Don: So like I said, book club for this week. I wanted to introduce the book. I will pull a quote out of the book because I think this is a topic we will come back to. We can spend maybe five minutes on it here and then decide if it needs its own episode later. A quote out of the book is: “The three most harmful addictions are heroin, carbohydrates, and a monthly salary.” So, what he is driving at there is - and I have experienced this in my career - that monthly salary allows you to get comfortable. It allows you to not worry about improving yourself. Now, this is not necessarily the attitude you and I take towards things, but it does allow someone to say, “hey, I am feeding my family, have a decent lifestyle. I don’t need to worry about doing anything else. I do not need to worry about improving.” But when that monthly salary is under attack or you are a freelancer or consultant and you are having to earn every penny, you as a person start to become a little more antifragile because you sit there and you go out and you learn more things, you investigate more avenues. Like I said, this is probably something we are going to want to take a totally separate episode on, but I was sharing with you just last week - there was a sale on books from a couple of different publishers and I picked up five different ones and I shared that list with you, and it was a varied list. It was not five books of all the same one topic. It was five books about five very different topics. Because they were all things that interested me. They were all things that will make me better, make it better for me to understand different things that I have touch on in my jobs. But they were all very different. That’s just another way of getting away from software systems being antifragile, more to people being antifragile.
Randy: The term is complacency. That’s what the fear, I think - I mean, this is beyond technology. It’s leadership and management for a strong part. The fear of every manager or business owner is that their team gets complacent. Maybe it’s the result of the salary and the structure or the stability that comes as part of that, but the idea that people will quit pushing the limits that a business needs to compete and for a software team it would be, “hey you are getting used to these error messages coming through the log system and they are not a big deal” so you just kind of keep letting stuff go past until one day you just let a huge issue go through, and because you just quit paying attention or caring about “hey, the framework we are using is upgraded, but that is a steep task to upgrade to a new version every year. We’ll just let this one ride.” And I think people will knock a manager - I don’t manage through chaos. I aim for stability of people’s anxieties and stuff, but there are managers that their philosophy is a chaotic environment breeds, like you said, resiliency and innovation, and that’s when they promote an environment that fights complacency in that case. Like you said, I think complacency on an engineering team is a huge topic that we can definitely tack on the future. I think it’s a great subject that I have talked to managers about. I haven’t talked to really engineer peers about it too much, but I have seen it discussed at the management level of things many times. And sometimes it comes out in just a frustrated comment about “nobody cares. This week the energy is low,” and I am not always certain if complacency is a cause for that. Sometimes, well last week was crazy town. This week is, everyone is catching their breath. But it is easy for a manager to confuse those, so I think it is a pretty deep topic we can definitely hit in the near future.
Don: Yeah, let’s tease the listeners to say we’ll come back, because another angle I want to put on this, and it could end up being just too huge to even do in one episode, there has been - I won’t call it a movement, but I will call it a movement just for ease of use - there has been a mini movement lately among the people that I read and I follow towards not contributing to open source in your spare time, not working on your job in your spare time, to have different interests in your spare time, to get completely away from your job in your spare time. And that the idea is valid and there is validity to the point, but there is a balance there as well, and when we talk about this in the future I want to tie that into it as well because to me that’s a huge part of it as well.
Randy: Makes sense. Well, we hit the 30-minute mark. I think we have got some great things to talk about coming up next week too. What’s your next week looking like?
Don: So, haven’t mentioned this here yet, but I had shoulder surgery a few weeks ago, so next week I get to get out of the sling, so that’s what I’m looking forward to next week. That sling is a pain to sleep in.
Randy: I asked you about this yesterday through Slack because we had an Uber driver because, you know, you get in a car with a rideshare and sometimes the stories go all over the place, but this particular driver had rotator cuff surgery and he talked to us about all he went through, and I was like “Oh man, Don had this surgery two weeks ago. That sounds worse than even he said. I need to ask him about this.” So I definitely sympathize tremendously and look forward to you getting rid of that sling as well.
Don: Yeah, the physical therapist said that the rotator cuff would be a more painful one in some ways, but this one’s more difficult in other ways, so they are two different ones. So, anyway, enough medical 101 on CTO Think. So what’s coming up in your week?
Randy: I am going to the gym so I don’t have to have rotator cuff surgery in the future. That’s next week every day.
Don: Do it properly then!
Randy: Right now I am trying my best to reduce meetings and keep coding and working with the folks on my team that are doing coding in the sense that I do need to be doing networking and marketing, but right now I am in that mode of I am just getting things done really well and I want to stay as much as I can in the office, reduce as many meetings as possible and keep cranking out the work for people right now that I need to get done instead of doing that usual “oh, the holidays kind of keep you in. I want to go out and spread out and network.” Every January seems to be that whole new resolution of networking, and maybe it’s due to the cold too. I just want to stay inside, but I am really focused on kind of cranking out work without a ton of discussion if not necessary and then pushing that kind of network burst that I typically do at the beginning of every year to later. So next week, I think, I am just going to be managing and development and minimizing meetings. That’s the goal.
Don: That is a worthy goal, so let’s see how well you achieve it.
Randy: Alright, man, we will talk next week.
Don: Very good. Thank you. See ya.
Thanks for listening to the CTO Think podcast.
If you like what you heard, please share the link to the podcast with your friends.
The show music is “Dumpster Dive” by Marc Walloch, licensed by Premiumbeat.com.
Show notes and previous episodes can be found on our website on ctothink.com.
For questions, comments for things you would like to hear on future shows, please email us at advice@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.
Randy and Don discuss an item ripped from the headlines: What should a technical manager do about the recent Meltdown and Spectre exploits? They move into the CTO modes of research, understanding, translation, preparation, upgrading, monitoring, and, most of all, not freaking out. Randy requests a bobblehead or plush toy of the Spectre logo.
Notes * Ripped from the headlines: Part of Randy and Don's week was dealing with Meltdown and Spectre vulnerabilities. * What is a CTO or technical manager supposed to do when big-name vulnerabilities hit the press? * Try not to be the smartest person you know or you're doomed to have all problems brought to you. * Start with research! * Good and bad sources for information. * A CTO must be able explain the technical details at a business level to stakeholders. * Randy mentions that these problems were being worked on months ago. * If you have a laptop on your desk with Windows, you've outsourced a level of security to a big provider. * It's ok to admit you don't have all the information right this minute. * You should tell people to avoid new websites, downloads, and updates on your own, until later. * There are security consultants that can take a big load of work off firms, for a price. * A tactic for reducing anxiety: A crib sheet of all technologies (and contact numbers) used by the firm in the event of issues. * Randy wants a Meltdown and Spectre bobblehead. Don promises to get him one.
Links Online News * Official Meltdown and Spectre Websites: https://meltdownattack.com * Amazon Web Services: https://aws.amazon.com/security/security-bulletins/AWS-2018-013/ * Intel: https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ * Ars Technica: https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/ * Apple: https://support.apple.com/en-us/HT208394 * Rendition Infosec: https://www.renditioninfosec.com/2018/01/meltdown-and-sceptre-enterprise-action-plan/
Security Folks * @troyhunt * @briankrebs * @hacks4pancakes - Lesley Carhart
Security Alerts * Ruby Security Google Group * Rails Security Google Group * Snyk – Subscription may be required * Gemnasium – Subscription may be required * auditjs
Other Links * CVE * National Vulnerability Database * CVE Details * Focal Point - company that provides security audits for Don * Google Chrome: Security on Chrome
Closing Thanks 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.com
Shownotes and previous episodes can be found on our website at www.ctothink.com
For questions, comments, or things you'd like to hear on future shows, please email us at hello@ctothink.com
For notifications of future episodes, please sign up to the CTO Think newsletter on www.ctothink.com
We'll keep talking next week!
Don faced an issue at his education tech firm: When should you slow down forward progress on new features in order to spend time on festering technical issues?
Notes * Randy discusses his explosion of three side projects: An app for HOA board members, an open source project named CaptionPoint, and a marketing app for a service provider * Randy states that his two-week break is no longer viable * Don discusses the efforts needed to automate tasks for AspirEDU * Don throws out the topic "How do you go about making the decision to make the trade off of slowing down new development to tackle old code and inefficiencies" * Both Don and Randy agree this topic pertains to more-established firms rather than startups (the pre-optimization problem)
Links * CaptionPoint * AspirEDU * HOA Done
Credits Show music is Dumpster Dive by Marc Walloch, licensed by PremiumBeat.com
Closing Reviews on iTunes are always appreciated and help us spread the word about the podcast.
Randy was posed a question by a potential client: "I want to build an app. Who should I hire?" and he asks the same question to Don.
Notes * Don talks about AspirEDU being in a refactoring phase * Don's gigs, AspirEDU Construction Specialties & Design were awarded as "100 Fastest Growing Companies by Alumni" by the University of Florida * Randy talks about clients starting to make bigger business decisions that are affecting technology * One client is looking towards a Nationwide launch * Another client has a money-making platform that they want to ramp up for growth * Randy and Don discuss the topic of "A business person wants to build an app. Who should I hire?" * Don and Randy both come to the conclusion "Start with design before hiring a coder" * Randy alludes to his working on a side-project, causing Don to shudder in fear (for Randy)
Credits Show music is Dumpster Dive by Marc Walloch, licensed by PremiumBeat.com
Closing Reviews on iTunes are always appreciated and help us spread the word about the podcast.
Transcript Randy Burgess: Hey Don.
Don VanDemark: Hey Randy.
Randy Burgess: What has been going on this week?
Don VanDemark: Couple things for the two companies I'm working for. With AspirEDU, we're working through that scenario where you initially build a product and you're putting all the different pieces together, all the different APIs and you're building your own system. You build it one way, and as you gain knowledge of the platforms and as you gain insight into all the little stuff that can happen, you think of a much better way to do it, but you've already written the system.
Right now we're in that big refactoring phase where we're refactoring a lot of the stuff we're doing. That's going to free us up to eventually get to a whole platform, back in platform shift is where we can start to spread out the load even more than we currently do. That's with AspirEDU.
On the Construction Specialties side, we actually just received some great news this week. It's actually great news on both companies. The University of Florida Alumni Association puts together a list of the 100 fastest growing companies led by University of Florida graduates.
Randy Burgess: Nice.
Don VanDemark: Both Aspire Edu and Construction Specialties is on that top 100 list. We're absolutely jazzed over here at the moment. It's really exciting.
Randy Burgess: Congrats. That's pretty good.
Don VanDemark: Yeah it is. We're really happy. Construction Specialties, of course being the business that my father started many, many years ago. It's just so great that he's going to get to receive this award for that company after working for so many decades, hard at his business. Real excited about that. What's been going on in your neighborhood?
Randy Burgess: I've got two clients, we're at the end of the year. Both of them are, I guess, they're happy so far with the technology they have, but they're starting to make some really big changes on the business side, and it's requiring changes on tech. One of the firms is moving from a local delivery system of their product and they're moving it into, they're aiming for a nationwide type of launch. We're going through a lot of design decisions right now to make sure that this nationwide program is affordable and that it works.
They're kind of going through the debate of doing a new system without investing everything at the beginning in learning how it works. Kind of a MVP of their, of this new feature. Then the other client, they have an existing platform, it makes them money, but they completely want to change completely their pricing system, and they want to start producing more of their inventory the way they do it, it's like a media scanning, or they take film and they digitize it. They want to ramp that system up. We're working on different work flows and different pricing mechanisms to really ramp up their revenues.
We're kind of at the end of the year where we're not going to start a project right now, but we're aiming to do a lot of product management and technology changes starting in January. To me, it's great because both firms look like they're having some opportunity to grow, and I'm able to do product development and stuff that I really like.
Don VanDemark: Yes. Cool.
Randy Burgess: It's a good outlook I'd say.
Don VanDemark: That sounds really cool.
Randy Burgess: I think the topic for this week is something that came up in a question to me last week, end of last week, and I wanted to get your thoughts and have a discussion around a business person comes to you and they say, "I have a business idea. It involves building an app, a mobile app, on any number of platforms. Who should I hire? Who are the people I need to hire right now?" That's as much information as you really are going to get from me on this question. I want to know, and this is not necessarily someone you want a job with, so this is someone you're just giving straight CTO advice to. What's the first thing that comes out of your mouth to the question, I want to build an app and who should I hire right now?
Don VanDemark: Okay. I think the first place I'd start with that is I'd want to have some further discussion. It would be, Hey, let's talk about what your app's going to do. Let's talk about how well defined you think you have your idea. It's highly unlikely that the first thing you want to go do is hire a programmer. In my mind, the first thing you want to make sure you have is someone who can help flesh out at least some idea of what you're looking for in the app. If that person also happens to do some programming, that's great, especially if they can get you to at least a prototype phase, that's fine.
Really, the emphasis in my mind is on making sure you've thought through all the, you've thought through the initial features, you've thought through the initial use cases, and you've though through the initial data feeds, things like that.
Randy Burgess: Okay. I'm a wealthy guy. I mean, I know how to make money Don. I have a really good feeling that this idea, which I'll explain in a minute, is going to work. This is hypothetical by the way. I'm [inaudible 00:07:00] The idea is, the new Google Reader. I do know there's other Google Reader apps that have evolved since they shut that down, but it's Google Reader. What I'm going to do is go out and hire writers that are doing the best content, and I'm going to make their content exclusive to people that are using my app.
My idea is to build a feed reader, blog reader, application that goes on a mobile device, with exclusive content that will draw the eyeballs. I will get a subscription going so that people are basically paying to read the exclusive content articles on my app. With that idea, I've thought through all this enough for me to want to plunk down money. Now I need you to tell me who I'm going to hire.
Don VanDemark: Alright. We won't question the validity of the business idea.
Randy Burgess: I didn't say you couldn't. I mean, I know I make a lot of money and I feel like I know everything. You aren't trying to get hired. You're not necessarily trying to get hired.
Don VanDemark: Right.
Randy Burgess: I want you to be blunt. I'm not saying, don't repeat what you said before, I'm just asking, what do you say next?
Don VanDemark: The business idea itself has to get validated. That's a completely different direction than, No, the business, you're going to pay to try and get this developed anyway whether the business idea is good or not because you just like burning money. We're going to go with the burning money assumption.
Randy Burgess: Yeah okay. Then yeah, we're going to burn money, but what I want you to tell me is, what are my options? What should I be doing when I start out with spending? I'm assuming, as a non technical person, I need technical people. Let's go past the idea of validation. Who am I hiring? What am I trying to do first after idea validation has kind of, I know what I want to aim for.
Don VanDemark: It can go a number of different directions.
Randy Burgess: That's what I want to know. I want to know the directions you're talking about.
Don VanDemark: Off the top of my head, the types of people that come to mind is some sort of user experience designer. This would be a person that would help to flesh out what the users of your app want, what they're looking for and how that translates into the app itself. Your initial conversations with a UX or User Experience designer would be around the types of people and their motivations, and what they're trying to get out of your app. That's one direction you could go.
Another direction you can go is you can go to the sheer UI, User Interface designer, to say, okay, what's my app going to look like? I don't know that that's necessarily the right first choice. Sometimes user experience and user interface people, one person does both jobs, but those are two separate fields. I don't know that I'd go to User interface before you try and understand what the users are trying to do, and then depending on the idea, and I guess we'd have to dig in a little bit further onto the idea, is to, if everybody's providing original content, then we're not worried so much about pulling data from a myriad of sources. If you're talking about a curated feed reader where we're pulling in all these articles and things like that and we have people on the app end who are taking those articles, writing up summaries and saying, this is something you should read, then yeah, you need somebody on the backend to figure out how you're going to pull all that data in. That's right off the top of my head, that's three different places you could go.
A product manager, you're way too early for a product manager in my mind.
Randy Burgess: Okay.
Don VanDemark: The owner is the product manager.
Randy Burgess: Okay, that's a strong piece of advice right there. You're saying to go after the design side and focus on that first. What are the advantages, in your mind, of hiring that UX person or the interface person? Why? Why are you hiring them before you get a product manager, before you hire a technical person? What's the advantage of that?
Don VanDemark: I'm going with the assumption that for these first initial few iterations, you, I'm going to use the presumptive you being the owner, you are going to be the product manager, so to speak. You're going to be the one to make all the decisions on how things go. That's why I kind of went away from a product manager first. The reason I'm leaning towards Designer is the developer side of me is arguing with myself, but you don't build a house without blueprints.
Randy Burgess: Yeah.
Don VanDemark: When you want to build a house, you go to an architect. What is an architect but a user experience designer. They are the people who can go and say, Okay, your house sounds awesome, your all glass house sounds awesome, it's going to look wonderful. Have you thought about bathrooms? You talked about your house being all glass, but I'm not really sure you want to see through a bathroom. That's kind of … The architects also have lots of good engineering background, so they're not going to sit here and design a house that can't be built either. It all comes down to the quality of the person you're hiring. That's why I went for the design phase first. You kind of have to know what you're building before you go build.
Randy Burgess: Let me jump in because I really like your example of the house-building, and part of it is because I'm looking to buy a house. Megan and I are looking for a place. We've actually put our foot in the water on, what if we built our own place? Or most of the time, you're looking for an existing home. I want to jump in with what I initially told this particular, potential client, versus, person I scared off. I'm not sure which way it's going.
What I talked to them about was the buy versus build in the first place. They came to me and they talked all day about content. The strongest thing they talked about was, I want a blog reader because I'm going to go off and do hiring of talent, hiring of content production. Content is going to be great, subscriptions. They talked a significant amount of time to me about the fact that the content was the King and they would be putting significant investment in the hiring of the writers, the talent, to produce the content.
What they didn't talk about was that they wanted an app that beat the market on features, or that was better than other blog reading apps. I kind of said, let's talk about this app you want to build because you don't seem as excited about the app as you do about the content. They admitted it. They were like, Yeah, I don't. I just need this app to do what I need it to do. I don't really care to try to beat Feebly or Old feed reader or whatever they call it. I just want people to be able to subscribe through my app.
I proposed, there is a significant cost to building your own house in the sense that you have to pick everything from scratch and know all the issues with the land, with the team that's hired, with the design, the blueprint that you just talked about. You don't really care about the house that much. You just want it to work from day one, to do this other thing of bringing in this content and then delivering that. It's a mechanism for that.
Given the number of apps on the market, have you proposed with the money you were talking about spending over a time. They were talking about a five-month build or so. I kind of said, I think you may want to consider, going, reaching out to existing app producers or makers that have these type of apps and see if you cannot white label or buy a version of their software, just to use for your purpose, and then perhaps get a maintenance agreement with that. I see a whole lot of risk in you being a tech firm and a content producer, versus a content production company that utilizes existing platform that you're not even trying to compete on that much. You want the content to be the King.
That's how I approached it and that's why your home-building thing, that's what I'm going through on the personal side of, do we want to go through the eight or nine month process to build a house and the risk that comes with that versus buying an existing place and in theory, you have all the risk laid out in front of you and you're paying up front some money for that of course, but you also know the risk involved, versus I don't think a custom build is even something that this client wants. I, of course, am answering this question having talked to them a lot more than you did, but I think, your bringing up the house-building thing spoke a lot to how I talked to them about it.
Don VanDemark: That's an angle that I hadn't formulated thoughts on. I do think a UX designer might tease that out. Obviously if I had had the conversation with the client, it probably would have come up in conversation as well that they weren't necessarily looking to build something. You're absolutely right, buy versus build is one of those initial decisions you have to make.
Randy Burgess: To the point of the design thing, because I agree with you there 100% that Design is where you start. What I have said to clients, or anyone I've worked with, even my bosses as a CTO in the past, to have a designer to take an idea and put it on a screen, is way cheaper for a designer to do than it is for a developer. A developer does not have typically, a good amount of expertise and user experience, and conducting the research necessary. Even presenting what looks like a good idea on the screen.
You're going to be paying for significantly higher per hour rates with a developer than you should be paying a designer, to get that idea on a screen for you. I've always kind of, in addition to everything you said about the reason why you want that research conducted by a professional. I also feel like on an hour to hour basis, you get a much more efficient product that way, or design that way, versus having a coder just build it for you on the fly.
Don VanDemark: Sure. There are tools out there like Envision and other products that allow a designer to pretty much build a, if not a full prototype, at least something you can click through and play with and get a feel for.
Randy Burgess: Yeah. Let's just, let's say, client decides they want to do, they want to go with your idea of design. Where does someone that doesn't know, and this could be a whole episode by itself, but where would someone start to pursue that UX person?
Don VanDemark: You would start by looking, finding examples of things you like that are out there in the app world. Maybe in your own community because that makes communication a little easier. You would start with things that you admire other apps doing other websites doing. I won't go as far as to say ad campaigns, but that's the general idea. You're looking for things that make sense to your app. That allows you to go contact those people and say Hey, did you use a third party, a freelance UX designer for this? Did you do it in-house? Start to feel out where that UX designer network is. You can go so far as to look at local meetups for user experience design. You kind of have to be in one of the bigger cities for those to be well attended and to have a good amount to look at, but those are a couple places off the top of my head that come out as, where can I find a person to talk to about my app and how we can design it.
Randy Burgess: Cool. I think, my next question, which I think we'll save for another time, is about that person. What their talents are, what we're looking for while we're going, following in what you're talking about of the location, or the source of them.
I think we're going to run out of time today to cover all that I think starting with design, I think the whole theme of this discussion is really about making sure you know what you're doing before you invest in a build. Starting, I totally agree that starting at the design level and the design professionals is probably the first step that a non-technical person wants to do. It's certainly what I'd do, and I'm a technical person wanting to start a product. What were you saying?
Don VanDemark: I'll take it even one step further. The designers, both user experience and user interface designers, basically what we were saying earlier, they can build you something without there being a lot of backend back there. You can sit there and iterate on your idea a number of times before you've invested all this time in the development of it. This just goes back to your point earlier. I don't think there's, I think that's the way you have to start. We're both, at the end of the day, we both started as backend developer strong background people, as opposed to being designers. Neither of us are truly designers.
Randy Burgess: Yup.
Don VanDemark: Even coming from out background, we're like, yeah, you probably want to know where you're going before you … You need the map before you go on the trip. If you don't, you'll have an exciting trip, but you may not get where you want to go.
Randy Burgess: But Don, I have a lot of money. I just want an app.
Don VanDemark: Hey, you want an exciting trip, get in the car and go. Don't pull up Google Maps or anything. Just go, see where it takes you.
Randy Burgess: Alright. You have a good week. We will talk next week. We'll find a good, something else from the recent experience level to discuss as what would a CTO, what does a CTO think about in this scenario. It's good talking to you. Anything big, other than the marketing stuff, anything big coming up in the next week?
Don VanDemark: Not, business wise, nothing real big coming up. We're just, like I said, on the AspirEDU side, we're just heads down on the refactor. That's going to be a bit. That's going to take awhile. That's something you bite off in little chunks and still work on your platform and making it better while you're redesigning the backend that nobody ever sees. That's really where a lot of our effort is going. What do you have planned?
Randy Burgess: I'm working on a side project. I'll have to talk to you more about it. Uh-oh is the big statement.
Don VanDemark: The side projects are what get us in trouble time-wise.
Randy Burgess: Totally. Totally. I think this one makes sense. They all do, but we'll talk more about it in the future. This idea fits my experience in business quite well. We'll just have to see if the market wants the idea.
Don VanDemark: Awesome. That's great.
Randy Burgess: We'll talk about it soon. Alright man, have a good week and we will talk soon.
Don VanDemark: That sounds great. Thank you.
Randy Burgess: See you then.
Welcome to CTO Think, a podcast about how technology leaders think about business, tech, and people problems. Don VanDemark and Randy Burgess, two current and former Chief Technology Officers will discuss the various challenges managers face in a product development environment. We'll cover topics such as team-building, product management, scaling, and software engineering decisions.
Notes * Don is a University of Florida grad, Bachelors and MBA * Don is CTO of AspirEDU, educational analytics company * Don is Managing Member of Construction Specialties & Design, a commercial maintenance firm * Randy was a CTO for Horizon Cash Management * Randy worked as a hands-on developer * Randy was a CTO for Innovations for Learning * Randy is founder of All Aboard Apps, a consultancy * Randy is the creator of HOA Done, a startup
Links * AspirEDU * All Aboard Apps * HOA Done
Closing Thanks 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.com
Shownotes and previous episodes can be found on our website at www.ctothink.com
For questions, comments, or things you'd like to hear on future shows, please email us at hello@ctothink.com
For notifications of future episodes, please sign up to the CTO Think newsletter on www.ctothink.com
We'll keep talking next week!
Transcript Don VanDemark: Welcome to CTO Think, a podcast about leadership, product development, and technology decisions by two recovering chief technology officers. I'm Don VanDemark.
Randy Burgess: And I'm Randy Burgess. Don, tell us about yourself.
Don VanDemark: Went and got my bachelor's of computer science and my MBA from University of Florida. Spent 17 years in enterprise programming and management, places like IBM and have also worked at 5 different small businesses. A nice variety of experiences there. My current roles as I'm currently the chief technology officer for AspirEdu, an educational analytics company and I'm a managing member of Construction Specialties and Design, a commercial maintenance firm where I've been working with them to bring them up to speed using the latest technologies. That's one of the current projects I'm doing with them and with AspirEdu we're continuing to grow our product base and entering that phrase of refactoring. Randy what about you?
Randy Burgess: Let's see. Started hacking on computers as a kid, but really didn't get into technology until I got out of college. First real technology job was actually my first CTO job where I was CTO for 10 years for a small finance firm. Along the way I decided to work on side projects to actually learn how to code, [inaudible 00:01:47] hands on type of stuff. Once I got out of that, I worked for a number of companies in a non-CTO role just as a developer and then was CTO for a non-profit called Innovations for Learning for a couple years. Right now, I'm running a consultancy that is helping startups build their NVP new apps and I'm working on a product called HOA Done and working to move that to a launch in the near future. Don, what do you think folks can expect to get out of this podcast?
Don VanDemark: We can offer a few things. The vast experience we have allows us to talk about how technology affects different industries, we can talk about various technology decisions like hiring and product development, and choices like that. What do you feel Randy?
Randy Burgess: Well I listen to a lot of podcasts that other people put out there and the main reason I listen is that I can learn where other people are screwing things up or finding out the best ways to get things done. So I'm hoping that we can similarly share with people where we were ignorant or stupid or learning our way and you know provide some experience for, it might be a CEO that's looking to hire their first CTO, it might be someone that's new to the CTO role or it might be kind of like I've been at times, a CTO with no one to bounce ideas off of. And you know hopefully our discussions and some of the people we may bring on can just give some insight out there to folks in a technology leadership type of role.
Don VanDemark: That sounds great. I look forward to putting content together that people can listen to and hopefully learn from and I like how you used the past tense of our mistakes not implying that we have any future mistakes to come. So thank you Randy.
Randy Burgess: All right. We'll talk next week.
Thanks for listening to the CTO Think podcast. If you liked what you heard, please share a link to the podcast with your friends. Show music is Dumpster Dive by Mark Walloch, licensed by Premium Beat.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 advice@ctothink.com. For notifications of future episodes, please sign up to the CTO Think newsletter also on our website. We'll keep talking next week.