All Posts By


Launching Your Startup With As Little Code As Possible, with Kelly Abbott

By | 7CTOsTV, The CTO Studio | No Comments

Audio Version

Can you be an effective CTO without coding? You can and the man to prove it is here for today’s show, Kelly Abbott. Kelly has held a variety of roles in the tech sector, including his current position of CTO of Tablecloth.

Today we’ll talk about what career decisions led him to that role, why he suggested we work together the first time we met and whether or not we actually did! You’ll also hear what it’s like to be a non-coding CTO and what he has learned from letting go of business ideas that weren’t working. It’s all part of today’s CTO Studio.

In this episode you’ll hear:

  • What was a painful yet important lesson Kelly learned from a VC?
  • Why does one idea work and another does not?
  • What would he do differently if he were starting over with Great Jones Street?
  • What is the complexity paradox?
  • Do CTOs always need bigger teams?
  • And so much more!

Our conversation begins with talking about Kelly’s first few endeavors. They include a social biography network, a project we did together and Realtidbits, a data analytics venture in the commenting space he created, grew and later sold.

From there he created the Netflix of short stories: Great Jones Street. He comes from a family of writers. His dad is an accomplished short fiction writer who has taught fiction writing throughout Kelly’s life. His mom owned a children’s bookstore and so books were the center of their lives.

As an adult he was addicted to reading fiction on his phone. He thought he and others would be best served by bringing short fiction because it’s so difficult to read a novel on a phone. He traveled a lot and didn’t want to bring books with him, and he didn’t like Kindles because he thought it was just an extra piece of hardware to carry around.

He couldn’t find a resource for buying short stories and adding them to his phone, so he thought there was a Netflix model possibility. If he could acquire really good content and offer them to a user base for a nominal monthly fee the idea could become a sustainable business model. So Kelly went out and bought a lot of really good stories, made great artwork for them along with audio versions of the stories read by the authors themselves.

Are you a technology professional looking to connect with like minded people?  Sign up to get connected with 7CTOs!

But despite his best efforts, people didn’t download the app and they never gained traction. As a result, they are in the process of shutting down the app now while the content is still available online.

Never one to be slowed by adversity, Kelly started a new project called Tablecloth. Today Kelly is the CTO of that company. At Tablecloth, they provide technology services to help non-profits, their funders and their corporate partners determine the impact on society from the non-profits efforts and funding.

Tablecloth also reports on that impact, something that is typically part of the information non-profits have to supply to their funders and corporate partners after receiving funding. Typically this information is not well-organized and can even be messy, so Tablecloth created a better way. It combines the many streams of impact-tracking data these organizations create and streamlines this data into a single dashboard that can be used by a foundation.

As they’ve evolved, the biggest pain point is to provide better communication tools between the different entitites. So today they have tools that look like Survey Monkey, databases and the reporting dashboard shows data visualization and business intelligence on top of layers of data.

But it gets reported like a Facebook stream: one day you’ll see a video showing what the organization has done with the funding provided, another day you’ll see charts of data. So the funders are getting a steady stream of information and input, and not having to wait until the end of the year.

Today he explains how non-profits work with Tablecloth, even when they aren’t tech savvy. He also tells us the future of Tablecloth, and how he is building his team going forward. Join us for that and more on today’s CTO Studio!

Please rate and review our podcast!

Click for Here iTunes

A Conversation With Mel Gordon, Founder & CEO of TapHunter

By | 7CTOsTV, The CTO Studio | No Comments

Audio Version

On this edition of CTO Studio, we meet Melani Gordon, CEO of TapHunter, a company she co-founded with Jeff Gordon, who is CTO.  She tells us how she and Jeff have been successful at work and at home, what  TapHunter does and what the current state of women in tech is.

In this episode you’ll hear:

  • Why you should set boundaries with your founder.
  • The importance of body language, especially for women in tech today.
  • How can you stop comparing yourself to others, and why should you do it?
  • Why you need to pick up the phone to prove your idea.
  • Is having self-serve customers really possible?
  • And so much more!

Also on this episode, we get into the details of what their business is and what it does: TapHunter is a tech start-up in San Diego. They are a premier company for bars and restaurants that want to drive foot traffic and boost profits.

It was an idea her husband had and about 7 or 8 years ago she thought there was something valuable in it. The craft beer scene was exploding, some of their friends were in that scene and she knew they needed the most help. Their vision from day one was to help local businesses and they started in the niche of specialty beverage locations.

It’s always been clear from day one who would do what in terms of roles. And that’s because they’ve worked together before TapHunter. They ran an agency and they met at a tech start-up in early 2000. She was the marketing director and he was the technology director, they loved working together and soon expanded to working freelance gigs. It’s what they’ve always known, so it comes naturally for them.

Are you a technology professional looking to connect with like minded people?  Sign up to get connected with 7CTOs!

Because she’s been a tech leader for so long, I wanted her input on what it’s been like to be the female CEO and how the tech scene has changed regarding women at the helm of tech businesses. Mel was brought up to believe gender didn’t matter so it’s never mattered to her that she was female, she was going to work just as hard and earn everything she deserves like everyone else.

However, throughout her career she has experienced some poor treatment because she’s female, and she’s had to deal with some misogynistic men. Although progress has been made, it is nowhere near where it needs to be in this industry. Mel says women bring in different perspectives, different approaches, and different life experiences and all of those things matter when growing and scaling a company.

In my personal experience with the hack-a-thons I run, there are differences I see when the pairings are only male, only female or a mix. The most unsuccessful teams are the mixed teams because the men usually dominate conversation where the females don’t feel they have a voice. The male teams typically get a lot done with low quality, and the female teams get very little done with supreme quality. Those are my observations.

Next she shares advice she gives to female tech leaders today along with how to know if you are really passionate about the tech you are building, and how she negotiates disagreements with the CTO. We finish with her thoughts on the current start-up culture – hear them and more on today’s edition of The CTO Studio!

Please rate and review our podcast!

Click for Here iTunes

How to Ask The Right Questions, with Bryan Hall

By | 7CTOsTV, The CTO Studio | No Comments

Audio Version

Asking the right questions is crucial to almost everything we do, especially in our careers. When it comes to data this is also true. Rather than collecting as much data as possible and then looking for the stories within, start by asking the right questions and then gathering your data.

On this edition of CTO Studio, our guest Bryan Hall will explain exactly why this approach is the most effective. Bryand and I will also talk about the due diligence involved with selling a company and how he made the hard decision to not be the CEO of his own company.

In this episode you’ll hear:

Why trying to figure it out on your own is a bad strategy for entrepreneurship.

  • How did Gmail help keep email alive?
  • Why to figure out your questions before writing down all your data.
  • What are the differences between data science and machine learning?
  • How do you know if you are ready to hire a data scientist?
  • And so much more!

We start our conversation today by talking about Bryan’s origins: he grew up in Medara, California and went to college at UCSD. He fell in love with San Diego and stayed after graduation.

Down the road he had an idea for a startup and went to the Founder Institute to find a CEO. Specifically he was looking for someone who could outperform him in every aspect of the role of CEO. Originally he wanted to be his own CEO, but when he saw Al was better at everything from pitching investors to talking with people, Bryan changed his mind. He knew Al was a better fit as CEO so he put his ego aside and they became the co-founders of the company.

Are you a technology professional looking to connect with like minded people?  Sign up to get connected with 7CTOs!

This company would go on to focus on email deliverability, a topic we talk about in-depth on the show today. Bryan explains what deliverability issues can crop up including wrong DNS entries or entries that are broken, a declining reputation from a handful of companies, the quality of the mail sent and making sure your customers have a good experience receiving your emails. He also tells exactly how the company helped their customers with any issues, spotting them before they became big problems.

Bryan’s career course changed later when they sold this company. The team part of the company went to Seismic as an acquihire, and the technology and product went to a different company because Seismic doesn’t work with email tech or products.

Which brought me to my next question: what was the due diligence involved in this two-part sale of the company? Bryan said the diligence piece of the acquihire was really just talking about how their team would plug into Seismic, what things Seismic was looking for, their vision and what working with the newly-acquired team would look like for the first year or two.

The diligence on the product side was much heavier, they went deep into the code and the data, explaining why they solved the problems they did and why they did what they did. They spent a lot of time with the acquiring company’s data team and development team, both before and for six months after the sale. 

That sale to Seismic means today he is the Principal Architect for Data and Analytics for Seismic. Seismic is a solution-for-sales enablement, which means they handle all the content for big companies’ marketing and sales departments. Bryan gives more details on the show today, along with what he does on a day to day basis.

Next we dig into the topic of good questions and how that applies to your C-suite and your data. His advice is to tell your C suit about what is possible and what is not. Figure out what questions you want your data to answer. If you are starting from there you are starting with the right frame of mind. Help your C-suite understand that having data doesn’t mean anything, but by knowing what questions you want your data to answer you’ll add value to your business.

Lastly we touch on the discipline of data science (versus machine learning) and how they manage the hiring process at Seismic. You’ll hear those topics and more on today’s episode of CTO Studio!

Please rate and review our podcast!

Click for Here iTunes

How to Solve Problems With Technology, with Chris McCann

By | 7CTOsTV, The CTO Studio | No Comments

Audio Version

Chris McCann has always been interested in how to solve problems with technology and help people in the process. Growing up he had a penchant for technology from his early days of self-taught programming in high school. That love led him to the Air Force which led to him to become a test pilot, a career he had for over a decade.

On this edition of CTO Studio, Chris explains how his love of technology and helping people has led his professional path over the years, what his latest project is, why he created and how.

In this episode you’ll hear:

  • The correlation between building the U-2 and software development.
  • Is Ruby on Rails still relevant and in demand today?
  • What is it like to fly a plane over enemy territory?
  • The tech that is like QR code on steroids.
  • And so much more!

Today one of the subjects we talk about is the similarities between building the U-2 plane and modern day software development. Back in the 1950s, Lockheed Martin had a group run by Kelly Johnson (father of the U-2 plane), and that group had a list of requirements from the CIA for a need to get intelligence over Russia for the missile fields and bomber bases. (This was before satellites).

The team had to innovate in order to come up with solutions. In the end, they developed a single engine airplane with a glider-like structure, there was no ejection seat and only bicycle landing gear to keep the plane as light as possible.

They had to factor in weight because every pound equated to 2 feet of altitude. So if they shaved 1,000 pounds of weight off the plane it could go 2,000 feet higher. The higher you get the harder it is for other aircraft or surface to air missiles to hit the airplane. The intention was to get the plane high enough – 70,000 feet – so the Russians couldn’t hit it, and it could successfully gather intel. For a comparison, most airliners cruise at 35,000 feet.

Next we transition into a discussion on his career in the tech world. His first CTO stint was at a start-up. This start-up was based around the idea that takes a stenographic approach (which means to hide information within other information).

Are you a technology professional looking to connect with like minded people?  Sign up to get connected with 7CTOs!

The CEO had developed a kind of technology that could take a digital image and embed information into that image in such a way that it could be extracted back out visually or digitally. For example, you could have an image on a package with an app that had a camera. You could then take that image and decode the information buried within. You could have a thousand items all with the apparent same image on them, but each one (of those images) would have a different ID or code or message embedded within them.

After that role, he worked at Fairway Technologies before jumping into his current project: an app called Airnoise. There is a huge project going on nationwide by the FAA called NextGen, it’s their next generation plan for the airspace over the continental US. They intend to make it more efficient, to get people to where they are going faster and to pack more planes into the same physical confines while also making arrivals and departures more efficient.

The problem is the FAA’s implementation of NextGen has concentrated air traffic noise over some small areas, often areas that never had any noise overhead previously. The people who are dealing with this constant air noise had no way of getting it fixed aside from filing a noise complaint with the airport authority, which was an onerous process in itself.

Having heard about this problem from his neighbors, Chris’ solution was to use technology to do the hard work, use technology to identify the airplane that is bothering someone and to file a complaint for them.

We dig into exactly how it works along with how this app helps the airport authority, too and all of the cities where this app is being used. Join us to hear those details and so much more on today’s edition of CTO Studio

Please rate and review our podcast!

Click for Here iTunes

When To Be Monolithic and When Not To Be , with Phil Borlin

By | 7CTOsTV, The CTO Studio | No Comments

Audio Version

To be or not to be monolithic, that is the question. Here with the answer is Phil Borlin of PluralSight and Veyo. Phil and I met a few years ago when he moved to San Diego to work with PluralSight.

On this episode we discuss when to break up a monolithic app, why you should start that way but not stay and when self-contained systems are a good solution. Join us to hear the details on those topics and more on today’s edition of CTO Studio.

In this episode you’ll hear:

  • How does he define self-contained systems?
  • When should you break up a monolithic app?
  • Why you should have your front end and back end developer on the same team.
  • Are they doing mob programming? Why or why not?
  • What does a healthy exec team provide, according to Phil?
  • And so much more!

Although he grew up in southern California, Phil went to Salt Lake City for his undergraduate degree and then to Colorado State for his master’s. Both degrees were in computer science, with his master’s focused on software engineering.

After talking about his background briefly, we get into the monolithic discussion. Phil says we should be doing things two or three times before breaking things out because we don’t understand where our abstractions should be until we do that. So if we are starting out start as a monolith, the reason to break out is to lower communication costs between teams.

The time to do this is when you’ve grown to your 10th or 12th developer and can split up into three teams, then you should start thinking about this. And the reason is because it’s more about team efficiency rather than scale.

We also talk about self-contained systems as a subset of service-oriented architecture. Phil advocates keeping your front end and your back end and your databases close to each other, giving teams their own code bases and their own databases and then using some kind of data replication or some kind of calling into other people’s APIs in order to cross those boundaries. By doing so you can have small communication boundaries between other teams and lots of room to innovate on your own team.

Are you a technology professional looking to connect with like minded people?  Sign up to get connected with 7CTOs!

I was curious to know more about what Veyo does exactly. Phil explains that

Medicare and Medicaid programs are two fantastic programs that give certain groups of people access to healthcare, people who may not normally be able to afford it.

These groups of people often struggle with getting to their appointments, they may no longer drive or they may not have someone who can take them. This is where Veyo steps in and provides transportation for those people to their medical appointments at no cost to them, Medicare and Medicaid pays the fees for these people.

While it might sound like a gig economy type of service, Phil says it’s a more holistic approach than lyft or uber. People can use public transportation and be reimbursed for it, for example. In Connecticut Veyo mails out the bus token to the person and the person then uses it to get on the bus and go to their appointment.

The point is to not have these people pay for their transportation by pooling federal and state funds to cover the fees. Of course these are non-emergency medical transportation needs only, typically for appointments like follow-ups, dialysis, etc.

Next we get into the actual app experience and more of the “geeky” details. Phil has been the Director of Engineering for about 5 months or so. it was a dot net shop when he got there, much of the code stil is today.

Also on today’s show we talk about which aspects of the Veyo app he has identified as monolithic and what he’s done as a result, Kubernetes, Azure and Google cloud, and why you would do containers or not depending on the situation. Lastly he shares what tech is most exciting for him now – TLA Plus. Join us to hear more about what that is exactly on today’s edition of CTO Studio.

Please rate and review our podcast!

Click for Here iTunes

Why All Companies Need a Code of Conduct, with Daniel Norman

By | 7CTOsTV, The CTO Studio | No Comments

Audio Version

Welcome to today’s edition of CTO Studio! Does your company have a code of conduct? Do you have a verbally understood code of conduct, or an actual written one that is in your workplace for everyone to see?

Our guest today, Daniel Norman, explains why you need the latter and why it’s so important to the health and longevity of any company, including yours. Daniel is the current CTO of gudTech whose love for technology began when he was a kid with a Commodore 64! Today he shares how he went from playing with Commodores to his CTO role today. Join us to hear his journey on our latest episode of CTO Studio.

In this episode you’ll hear:

  • What is most impactful on the success of a company?
  • Why did gudTech brand Retail Ops separately?
  • Why does language in code of conducts matter?
  • What happens in the absence of a code of conduct?
  • Rust vs. Go: what are the pros and cons of each?
  • And so much more!

Daniel’s first exposure to technology came early on as a kid. He quickly moved from the Commodore 64, then to the 128 and on to working in a school district servicing their computers. His undergraduate work was in technology and he interned with several engineering firms and then was employed by QualComm for several years before finally landing with gudTech.

When I asked Daniel to tell me more about the concept of codes of conduct and why they matter so much, he explained within our organizations we should be talking about them, formalizing them and making them a pillar of our business.

They are not meant as boilerplates but are meant to be celebrated as part of the daily discourse and daily water cooler conversations within our companies. Codes of conduct should be official documents that outline the values of our companies.

They can vary depending on the company but codes of conduct make it clear to everyone what are the values of the company. When these values are in bold print employees aren’t surprised by them, everyone knows these are the values you uphold as an organization. In a nutshell, whatever your values don’t just talk about them, write them.

Also be aware of the subtleties of our everyday language, like using the term “guys” to refer to an abstract group of people. If you can name the group you are speaking to and they are all men then guys is appropriate. But there are so many disparities in gender and for various other protected groups that it behooves us to be conscientious of our language and our values in our organizations.

Are you a technology professional looking to connect with like minded people?  Sign up to get connected with 7CTOs!

Next we moved on to talking about Rust versus Go (two programming languages). I wanted to know if they have used Rust in their Retail Ops product. Daniel said they don’t but they do have a good amount of Go. In fact, they are moving more towards Go for application programming on the server side and using Rust for systems programming.

He explains why and how they use each. For example, Rust would be something to use to write a very high performance piece of your code like a database or a network stack.

While Go has addressed a lot of their systems programming issues, and there have been databases written in Go that work pretty well, it isn’t as good as Rust.

Go does a good job with certain types of problems as long as you are okay with the starting assumptions the language makes like you’ll have a garbage collector and green threads in everything. He recommends using it on a case by case basis, you have to decide when it’s okay and when it will be bothersome for your users.

As far as Rust, safety from data races is the #1 reason to use it. Any time you are building mission critical code there are a host of subtle errors the programmer can make and inevitably will make, unless you have a language like Rust which enforces certain invariances. Rust is very strict.

It’s so strict that Daniel says your first few weeks with Rust will involve a lot of swearing and you will hate the compiler! The compiler will be your enemy. But somewhere around week 2 or 3 something flips and you’ll learn to love the compiler because when it does finally compile it will probably be right. There’s a host of different problems your program will not have that it would most certainly have if you used another language other than Rust.

After talking a bit more about Rust and its strictness regarding the key concepts of ownership and borrowing, we also touch on the San Diego Meetup group for Papers We Love before finishing up with some of Daniel’s biggest learning lessons as a CTO.

Join us to hear the details on those topics and what Daniel is reading and listening to on today’s CTO Studio.

Please rate and review our podcast!

Click for Here iTunes