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

Utilizing Emotional Intelligence in the Workplace, with Michael Saul

By | 7CTOsTV, The CTO Studio | No Comments

Audio Version

Welcome to another episode of CTO Studio! Today I’m sitting down to talk with my close friend and colleague, Michael Saul. Michael is the cofounder of 7 CTOs, and is a dear friend, partner, and mentor.

On this episode, you’ll hear about how Michael came to be my work partner, as well as the value of emotional intelligence in the business world. You’ll also hear his advice for better communication among CEOs and CTOs, how his interest in emotional aptitude came to be, and so much more!

In this episode you’ll hear:

  • What exactly is emotional intelligence?
  • How can you become aware of and in control of your emotional responses?
  • What did Michael learn from first venture in the business world?
  • Why people are so invested in their outward appearances.
  • The reasons why CTO and CEO can be such lonely roles.
  • And so much more

Michael’s interest and experience with emotional intelligence began at a young age. As he recognized different emotions he also discovered there was often a root problem attached to those emotions, just buried underneath them. That knowledge would go on to serve him well in business, and other areas of his life.

This same process he uncovered with emotions – the problem being buried behind people’s emotional responses – is similar to the reverse engineering process people in technology and tech-related businesses often use to get to the heart of an issue.

When I asked about his early days in business, Michael explains his journey in business was deeply rooted in his love for the outdoors combined with problem-solving. His initial business was a white water rafting company as well as a beginner’s kayaking school, both of which he founded at the age of 20.

Shortly after he expanded his businesses to include winter sports facilities, he experienced devastating fear when all three of his new businesses went bankrupt and collapsed. Those losses left him fearful his business image had been permanently damaged in the outside world.

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

But Michael persevered, picked himself up and carried on. He took the lessons he learned and applied them well to overcome adversity in the future, and has been successful as a result.

I was curious to know more about how emotional intelligence and recognition can play such important roles in the business and technology worlds. Michael has witnessed firsthand how the CEO and CTO roles can both become very lonely, if the people in those positions allow for it.

He gives two main reasons for this: being the person who makes decisions that affect everyone in the company and being the one in charge of so many employees.

In order to combat that loneliness that can set in, proper communication between the CEO and CTO is vital. It can certainly seem as if the two partners live in extremely different worlds, but when you look deeper you’ll see the two roles have so much in common. Both roles have similar goals, drive, and vision.  

Continuing on that train of thought, we discussed what Michael has observed in current CTOs at 7 CTOs. He says that he has been pleasantly surprised at how wholeheartedly the CTOs have embraced their roles, and that he is looking forward to seeing what happens when CTOs begin collaborating with one another and using innovation as a tool.

You can hear more from Michael on emotional intelligence and other topics when you tune in and join us for this episode of CTO Studio!

Episode Resources:

Michael Saul on Linkedin: https://www.linkedin.com/in/misaul

Please rate and review our podcast!

Click for Here iTunes