One of the talks Aaron Contorer gave that I’ll never forget is the talk in which he covered two topics: functional programming and how to provide solid tooling as a CTO. Those two topics are our focus for today’s show, and we waste no time jumping into the deep end!

Aaron has a technical background and built his company, FP Complete, around those very same subjects. You’ll hear how and why he started that company and much more when you listen in to today’s episode of CTO Studio. 

In this episode you’ll hear:

• When does it make sense to start slow and when should you start quickly?
• Why should CTOs be more optimistic and aggressive?
• How to use bootstrapping to build something big in incremental steps.
• What is the single most useful and most powerful management model?
• What is the biggest problem we are facing in software today?
• And so much more!

More About CTO Studio
When Aaron was at Microsoft and was managing a number of different R&D projects, he was surprised to learn how much of their time they were wasting using old-fashioned tools. He thinks even among the smartest IT people there is a bias to work around something and see that work-around as productive, when in reality is not.

He likens it to building a factory: every day with our work we are building a factory to build the things we really want done. We don’t run the web site by hand, for example, we build a factory that runs the web site. And if we are really good we build the factory that builds factories. And if we are in the tools business we build factories for those tools.

We are trying to get leverage in what we do, but we sometimes forget if we aren’t investing in building a better factory then the products that come out of our factory are not going to systematically improve or get any cheaper or more reliable. We need to invest in better tools and better processes – that is what being a CTO is all about according to Aaron.

An example he gives is a medical device company, one of his clients, that makes a successful medical device. They said they needed a data cloud that is would gather all the data from all their devices in the world and put that data together. This would allow all the users to see what is going on with their health and practitioners to see what is going on with groups of patients.

So they built a V1 product to get something out, it was thrown together quickly. They thought maybe 10,000 people would use the app. It turns out the device was really good and people really liked the app, and a million people wanted to use the app. The problem became not just that the app was never designed for that amount of users, but neither was the data storage nor any of the infrastructure. The engineering systems themselves were never built to support that number of customers.

Next I asked Aaron to weigh in on whether it is true that devops is what happens when the engineering culture doesn’t take care of or consider the infrastructure.

To him, devops looks like this: you’ve got dev and you’ve got ops. In between the two is the middle ground called deployment where you are done building something but it’s not yet running on a production cloud or something similar. In general when talking about devops he considers it the family of technologies and design approaches that are all one big factory.

He gives the story of the Airbus A400M which fell from the sky in 2015 while they were doing a test flight. On that test flight they had designed their software in a tiny little computer inside every engine to control the fuel flow. The software must have passed its test because it was used in the build.

So they took it for a test run one morning with the new software added to the engines. The plane took off fine, but when the pilot adjusted the throttles downward all the engines went into idle except the one without the new software. So three engines turned into idle, and no matter what the pilot did with the controls he couldn’t get any more fuel into those other engines. As a result, the plane couldn’t maintain air speed and it fell from the sky, and everyone aboard died.

It turns out the software was fine, the problem was in the deployment. The person who did the update of the software into the engines did so using a non-automated system, and he missed a step. There was a file that didn’t get copied onto the engines, and it was the data file that said how much fuel to put into the engines. As a result, the engines couldn’t operate and there wasn’t a thorough enough system test to discover the error beforehand.

It’s a tragic story highlighting the importance of every aspect of development, deployment and operations.

We continue with that discussion before seguing into functional programming, why his company provides commercial Haskell tooling and work, what it’s been like being a CEO at FP Complete. You’ll hear from Aaron and I on those topics and more on today’s CTO Studio.

Making the leap from a technical role into the CTO position requires many things, and not everyone makes the jump. One man who has is our guest today, Dr. Dan Stoneman.

Dan recently completed his doctorate in Organizational Industrial Psychology. He continues to learn and try to understand his world. Throughout the course of his career experiences, he’s learned the importance of psychology as a CTO and we get into why that is (and much more!) on today’s edition of CTO Studio.

In this episode you’ll hear:

• What does servant leadership look like as a CTO?
• What three pillars are needed for employees and organization to achieve success?
• Why is going from a technical role to a CTO role so challenging?
• What is a destructive hero and why does this role fail so often?
• Can you just flip a switch to go from employee to manager?
• And so much more!

More About CTO Studio

Dan has spoken at our CTO gatherings a few times, and one of those times he was the Chief Innovation Officer at a school district. I wanted him to repeat something he said during that talk when he was describing his career. He said it’s hard to describe as a path or a trajectory, it’s more of a personal mission of understanding. He believes a big part of his personal being is to understand the world in which he lives.

He was fascinated by his computers when he was young, so he started to figure out how to build and design them. He went to college and got a micro electronic engineering design degree. He learned how silicon becomes transitors, transitors become chips, and so on. So he designed transistors and chips and then circuit boards, at each stage he tried to understand how things fit together.

And from there software sits on top of the hardware, so next comes how to design software, and how to build the software. That leads to project management, program management and product design and customer use cases – all of which eventually lead to business strategies, leadership and psychology.

Next we dig into how industrial organizational psychology (or I/O psychology) works. He believes each person does make their own decisions, so all you can do is set up an arena where they can be successful. He is a big proponent of the book Drive by Daniel Pink.

In that book, Daniel Pink talks about the three pillars of autonomy, mastery and purpose.

He explains as a leader if you create an arena based on servantship in which people have a great deal of autonomy, feel a great degree of mastery, have the proper training and understanding of their profession while also aligning their work to your organization the rest takes care of itself. That’s his take on what it means to be a leader.

I agree with that premise. When I became the CTO of my start-up I realized the people I was hiring weren’t there to be an extension of me; they weren’t there to go through my to-do list and get stuff done while I was focused on the other parts of the system.

But instead I was hiring human beings who could think for themselves and have their own ideas, and the best thing I could do would be to activate their creativity and get out of the way. I remember that realization was a massive moment for me!

Dan thinks that is true for many of us who started in engineering. It was for him, and so he’s been investigating organizational psychology and how to set up your organization. If you think of it like having a baseball team, organizational psychology would be looking at and deciding how best to set up the game field, the rules and regulations, what does the field look like and how are the umpires going to treat the field.

And industrial psychology is typically how to treat each individual player: what does each person need specifically to succeed? Industrial and organizational psychology work hand in glove, and why it’s called industrial organizational psychology.

On today’s episode of CTO Studio, Dan also tells us a failure he’s had in his career. Dan explains a great engineer does not make a great leader. In fact, they are completely opposite. He says he was a good engineer and as an engineer you are rewarded for finding needles in a haystack. If one transistor is out of place or one semi-colon is not in the right spot, everything falls apart.

It’s the exact opposite when you are a leader. As a leader the needles don’t matter, what matters is the haystack. How you can traverse the business arena and leadership arena doesn’t have to do with tiny nuances, it has to do with people and relationships.

We get into why taking a technical path to leadership is one of the most difficult, and why it’s such a high hurdle.Then we talk about the differences in the roles of CIOs and CTOs, if leadership becomes your responsibility as you gain experience and Dr. Dan’s productivity tips! You can join

Getting your CEO and other leaders to buy into re-engineering platforms is no small feat, but our guest today has done it four times! Matt Ferguson of Zeeto tells us the ins and outs of company-wide agreement on major platform retooling.

Matt is a former Montana native with a love of horses and math, the latter of which led him to into the tech world. Here about that transition and much more on today’s edition of CTO Studio.

In this episode you’ll hear:

• Why people answer questions when they are online.
• How can you break out of the software paradigm, and why should you?
• Why is retrofitting not a great strategy?
• What does it mean to “forklift out”?
• Why is the CTO role not what some people think it is?
• And so much more!

More About CTO Studio

Today Matt is the CTO of Zeeto, a company in the ad tech space. They think of their company as a bidding platform to place advertising. Both advertisers and publishers are able to sign up. Most importantly they ask a lot of questions to get your ads in front of a specific type of person, that’s how they target for you. They are the only company doing something like this right now.

As a publisher working with his company goes like this: you would imbed a specific piece of code that would then display a question’s interface. That piece of online real estate enables his company to ask questions. For example they may ask if someone is planning to travel this year, or sell their house this year, etc.

Zeeto’s revenue comes from collecting money from the advertisers and then paying the publisher, taking a small revenue share along the way.

As far as the specific technology they are using, it’s a platform that was written before he joined and was done in PHP. It was quite successful and helped the company become a multi-million dollar organization. But they decided to reinvent the tech, make it more scaleable so the company could go big – and that was why he joined the team.

They wanted to reinvent the tech because adding new features, and new ad types had become harder. Also, the data modeling wasn’t flexible enough, it wasn’t multi-tenant so they had to stand up more servers and databases for each new customer. And the cost implications of all of that was too high.

They knew they could get to a platform that would run at 1/10th the cost and be multi-tenant, and be more scaleable so he assembled his team off-site for 3 days. They went through a decision process of laying out fundamental architecture and making platform technology choices through a matrix analysis of what was in the market, what was too cutting edge and getting the team to agree on the boundaries.

It was a democratic, and transparent process to see why they made the decisions they made. They didn’t want people to step in six months later and say well it would’ve worked if we had done X. Everyone knew how the decision was made, and what the criteria were for making the choice.

Matt opted for a retreat that included everyone who was going to work on the product, not just senior leadership. He was new to the company and was curious to get to know what everyone was passionate about, and were good at. Matt tried to do as little speaking as possible so he could figure out who were the leaders, who would become owners and identify the folks who could take technical leads or drive the project personally or interpersonally.

What advice does he give on re-engineering a project? The biggest thing is to get an admission of where you are as fast possible, and buy in from the CEO about what it’s going to take. He’s replaced a major platform four times in his career and after the 4th time he’s learned starting over is the right strategy, especially if the platform is older.

Technology moves so fast. Consider the amazing transitions we’ve had over time from off-site data centers to the cloud to now being server-less. Those are at least 3 fundamental changes in hardware alone!

On today’s show, we also talk about what specific technology they used in the new platform for Zeeto and his recent communication accomplishments for the company’s teams. You’ll hear Matt and I dive into all of that and muc more on this episode of CTO Studio.

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.

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!