Modern CTO: Everything you need to know, to be a Modern CTO.

by Joel Beasley

I was shocked when I found out that the majority of CTOs on the planet today went from developer to CTO.

Developer and CTO are two distinct roles. It’s the experience of transitioning the space between them that is unique to our generation.

Every skill we learned on this path from developer to CTO defines the Modern CTO. These skills were not handed to us; we had to discover and earn them. We developed skills in: relationships, growth, communicating value, scaling, management, learning how to learn, balancing imbalance, opportunity, focus, identifying white space, understanding failure, processing feedback, making people feel heard, sharing, speaking up, teaching, and developing effective products that bring value to the market.

After selling my technology, I got exposed to the business side of things. I began to ask, “Is there a programmer that’s also the business person?” That’s the CTO.

You become stronger and more confident as you get through each trial. So, lift the heaviest cross you can bear and carry it like a champion.

Notice anything strange about this conversation? There’s barely even a mention about tech or business strategies. In the broader sense, visionaries typically come out of the backwoods without even a care about our Silicon Valley world. Instead, it’s their struggle that defines them and gives birth to their vision.

The essence of being a visionary is not being satisfied with who you are right now, and always, always moving towards who you want to be in the future.

McKinney offers some awesome ideas to spur visionary thoughts (like:) Change routines (new social circles, new routes to work, new conversations) Brainstorm about stuff unrelated to your niche (list 50 ideas about how to start a lawn care service) Pay special attention to assumptions and challenge every one of them McKinney also encourages us to never stop at the first answer.

It’s not enough just to come up with incredible ideas. The visionary CTO must have a high capacity to execute, organize, identify whitespace, communicate, and lead.

Feel and understand the problem, then visualize the solutions. This could be a people problem or a tech issue. Observe, stop, and think.

Gather people, resources, validate experts, and put together the A-team. The B-team gets B results. Hire where you’re weak.

Being a leader means communicating complex ideas simply. You’ve got to make high-level ideas stick in their minds. The easier it is to understand something I make, the more people will spread the word.

It’s critical for me to understand what drives people. At its core, it means I care about what matters to them as people, not just as workers. This principle ties back to the empathy concept—what’s their why?

“The most important thing in communication is hearing what isn't said.” Silence may actually be a problem screaming for attention.

If I rest on past achievements, I’ll never grow. Let me put it this way—a genius programmer could be a lousy CTO. On the other hand, a mediocre developer could be a CTO that makes companies millions.

We’re never good at something the first time we try.

Then over the course of that fifth year these isolated lessons and skills all melded together: how people think, how to create value, how to communicate value, and how to manage people.

Rather than developers and startup entrepreneurs saying, “We wrote it poorly because we’re new and lack experience,” they’ll say, “We built an MVP.” Nope, you’ve built a MESS.

A minimal viable product is a heuristic for building only what is needed to carry out the task in the most basic form: MVP + Users + Feedback + Release = Version 1. Notice how nowhere in that equation is fixing a broken spaghetti mess?

A minimal viable product is something you can take to market and sell.

Getting from prototype to MVP is a lot of work. If you can't take it to market and sell it at scale, it’s not a product.

I don’t obsess with trying to make it perfect, but I’ve learned to be patient and write code that is good enough by expert standards.

If you rushed something out on the cheap in order to get a proof of concept and raise money, that's understandable. I get it. But, when you raise money, make sure to ask for enough to do the project right and with a stellar team.

You might say, "Oh, I want the perfect user experience." But really, you only need something good enough for someone to use it. Get a hundred people to use it, and then improve it. Then get a thousand people to use it, and improve it again. It doesn't have to be perfect. It has to be good enough, and then move forward from there.

By continuously bringing the business into the conversation, I eliminate over-engineering and drive momentum instead. Problems appear all too frequently in the name of "efficiency" or "optimization." When I see this, I immediately tell people to stop thinking in terms of adding value to the platform. Instead, think of how to add value to the customer.

When you build a feature out of fear of losing the customer instead of building it out of value to the customer, you have built a fear-based feature. I find that newer companies often have this problem.

You aren’t building for one person; you are building for a market. Dive too deeply on one individual's desire and you’ll end up with an app only one person cares to use.

Your ability to clearly communicate why something is important is critical to success. The why is the foundation of momentum.

When I first meet a team, I like to get to know the group and then meet everyone one-on-one. It’s important to establish a very simple, basic relationship with them. I try to put them at ease from the beginning. It’s not about trying to be their best friend or anything like that. Still, I want to know one or two interesting things that drive them as individuals and to share with them why I'm doing what I'm doing.

I take notes when we meet. This way I can remember that John likes vacations in the mountains and Beth brews her own beer.

The greater the distance a person feels from the top tier, the less they feel a part of the team.

I always seek the why.

“What are the basic fundamentals I need in order to make that sale?”

Still, the only way we can get there is by taking the basic first principles and repeating them over and over again. You build momentum, and that momentum eventually gets magnified exponentially.

When I see people taking investment money, it scares me. I just want to reach out and say, "I'm glad you got your investment money. Just don't do what I did the first time I got money, ‘cause I screwed up."

Another way to destroy momentum is to have people redo stuff. If you have people constantly having to redo the same thing, it’s the quickest way to destroy momentum. Let’s say you're in a retail store, and you pay someone to fold towels. Then, you walk right over to them after they finish, and you knock the towels over. They have to refold the towels. You do that a couple of times, and they're going to quit.

The same thing happens with programming and developing products. If you keep having your team rebuild and refold, only to walk over and smack it down, they are going to quit.

If you're in a situation like this right now, and you've got people working on something that you know will not be used, just do them a favor and stop them.

No one at my business or at my company will ever feel like the work they did was useless. I may not use it, but I’m never saying, "Nope, it's useless; we're never going to use it." If you find yourself saying that, it will kill your team's momentum.

If I have situation where someone just finished something that we’ve decided we're not going to use, I’ll communicate it in a way that doesn't make them feel useless. I might say, "Awesome, great work; this is fantastic. We're going to put this in the roadmap here to go ahead and move it into this future branch.

Another way to kill momentum is to change something and then change it back. I call them “re-changes.” It's a rude thing to do. I might say, "I want it like this." So we go and make it like this. Then I say, "Oh, but actually you know what, I want it as it was before." Re-changes will kill momentum super-fast because it just made people feel as though they wasted their time.

Instead of obsessing over problems, I’ll take a step back and return to a project’s core goals. These three to five goals are the main objectives

As a leader, I can't drag the whole team down due to personal problems.

Hiring your competitor is favorable when you find a product or business at a very early stage. At this stage, the product is likely to be backed only by an individual with a brilliant idea rather than a well-established company.

If it's a truly disruptive technology, I’d find a way to buy them. Otherwise I’d drive myself crazy trying to adapt my systems or trying to create a new product team. If the technology is that far off from where I’m at, I would just simply buy them out.

If purchasing the technology is just not going to happen, I would immediately seek to bring in two or three key individuals that could move us forward.

In general, I follow these simple guidelines when building teams: No more than five in people total, including one to three developers and one to two designers Separate the back end from the front end Ensure that each team has very specific

My teams are structured the way I like to structure code—clean, concise, and with a keenly defined goal.

They are small, isolated groups that have a single responsibility.

So I group those working in odd time zones together. I also avoid micromanagement completely. In fact, I only intervene if they don’t reach their goals; free-thinking people produce better things faster.