(8 minute read / 43 minutes front to back)
I refer to hands-on Technical Advisors as Technical Coaches to emphasize that their roles and responsibilities are very unlike other kinds of advisors.
*** DEFINITION ***
Technical Coaches are hands-on advisors,
have specific responsibilities, and support everyone in
your organization – not just the executive team
At a minimum, coaches must:
You always need at least one coach, but you might not need much time with them.
You only need a couple hours each month with a single coach when you have an extremely capable development partner (firm, CTO, or Technical Cofounder) and an extremely capable coach who can review your solutions, team and code.
As your project evolves, your coaches should become more specialized.
It’s very difficult for a single person to truly master all aspects of technology – especially as things get complicated.
Ideally, you want a Product Coach finding ways to simplify your solutions, a Team Coach watching the performance of your team, and a Code Coach reviewing your code.
That said, you don’t have to interact with all your coaches.
To illustrate, when I work as a coach I usually subcontract more cost effective specialists to review code and architecture while I focus on people, process and product.
My CEO rarely interacts with the Code Coaches I provide, but their presence remains vital.
When the total cost for all your coaches gets significant, it’s time to find yourself a traditional equity-based Technical Advisor (or friend) who can make sure all your coaches are charging appropriately.
When you are solving the wrong problems nothing else matters.
This means your first coach needs to be great at figuring out what problems are really worth solving to help you to find the cheapest and simplest solutions to those problems.
Jim met me at a panel, much like Billy. But unlike Billy, Jim asked me to review his MVP before starting to build it.
Jim was already working with a firm when we started working together. He had already paid a substantial deposit and created wireframes.
The problem, as usual, was that his firm was focused on their interests, not his. They had convinced him to spend $30,000 on an MVP, and just like Billy’s firm – had designed a product that made zero sense for his market.
Jim was targeting millennial users who were renting apartments, but his firm had designed an MVP with a million features and an interface that felt like a 1990 corporate intranet. It was never going to work for millennial users, and Jim understood why as soon as I pointed out the flaws were pointed out to him.
I helped Jim design a new product that borrowed from Instagram and respected the way his users wanted to use their phones. We simplified his approach so that he could test one thing at a time.
Then, when we proposed the simplified design to his firm, they actually had the nerve to hike their prices another $20,000. I helped him find new developers that were happy to help for $10,000 shortly thereafter.
Jim saved $40,000 and months of time.
I call this role the Product Coach.
Product Coaches are responsible for three things:
If you have a strong vision for the product the Product Coach looks over your shoulder to help whenever possible. If not, they work with your CTO, your developers, or your development firm.
Product Coaches are helpful for both startups and billion dollar companies. It’s not about the title, it’s about the nature of your relationship.
Few startups have CPOs, so Product Coaches tend to start off heavily involved, then taper off while MVPs get built, and then come back again with a vengeance once the product is up and running.
At larger companies, the Product Coach supports the CPO from day one. The stronger your CPO, the less help you need from your coach. Regardless, you always need an independent voice in the room – this allows you to put pressure on your staff (or yourself) to deliver while relying on your Product Coach to keep you on track.
Product Managers are not qualified to be Product Coaches without support. Product Coaches help shape the direction of the company and need broad training with strong executive communication. My experience has been that CEOs tend not to listen to Product Managers even when they are correct. But, it can be very cost effective for early stage startups to pair a less experienced Product Manager with a senior coach serving in a limited capacity.
Also, because Product Coaches assist in driving revenue, they need to be heavily in tune with WHY the business exists, where the business wants to go, and what it’s goals are. They need to be in touch with where the industry is going.
Granted, it is the responsibility of the CEO to articulate the WHY behind the company, and to ensure alignment across the executives and company. But, if the Product Coach is out of step here, they can make recommendations that are counter to the type of company being created.
Once you have a product direction established, it’s time to put a team together to help you build it.
Team Coaches help show you how to locate people, evaluate their performance and implement your processes. If this sounds like a CTO to you, you’d be right. Team Coaches are typically CTOs at other ventures who help make sure you’re doing it right.
Examples of powerful job ads and more information about hiring developers can be found on my blog: https://jaycrouch.wpengine.com/posts/win-the-war-on-talent-stop-writing-job-ads-like-everyone-else/.
Traditional equity-based Technology Advisors are usually most equipped to be Team Coaches because they tend to be CEOs or CTOs of other ventures. However, remember that often the best equity-based advisors are accomplished people able to open big doors for you. They usually aren’t equipped to help you recruit your team as cheaply as possible or get involved in the day-to-day issues your team is struggling with.
Team Coaches should be very knowledgeable at recruiting and setting up processes for businesses at your current stage. The key is to make sure your Team Coaches aren’t responsible for driving performance. That responsibility must fall to your CTO, your development firm, or you – while your coach points out mistakes and opportunities.
It can be cost effective for early stage startups to pair a less experienced Director of Engineering with a senior Team Coach serving in a limited capacity in the same way it can be cost effective to pair a Product Manager with senior Product Coach.
I recently worked with a couple founders looking for someone to help them build an MVP. They were interested in a few candidates, but one stood out above the rest. He was a long time friend of the founder, all the way back to college, so the founders felt comfortable with him. Let’s call him Bob.
Bob disliked working hourly because “there is no motivation to finish quickly”. He felt it was better for everyone to work on a project basis, and because of that, he proposed a quick discovery phase for $20,000 to figure out what to build before starting to build anything.
When I pressed him for hard answers, he said that he guessed we were looking at a 6 month project based on the documentation he had seen. He also said he didn’t have an hourly rate, but if he did, it would be somewhere near $200/hr.
I have to admit, he was a good salesman. The founders were convinced. They had raised several million and figured a $250,000 MVP sounded about right for everything they wanted to do.
I advised the founders stop talking to Bob.
Bob was the worst of two worlds. He wanted to build everything his way – which locked the founders into working with him down the road. And, he wanted to work on a project basis which forced the founders to prematurely commit to a 6 month project – and allowed him to pocket an expensive discovery phase.
At no point did Bob ever stop to consider what was best for the business.
Bob never bothered to challenge the founders to build a smaller MVP. And, his justification for not wanting to work hard on an hourly basis was a dead giveaway that he didn’t think like a CTO. A large part of the CTOs job is to make sure everyone is working hard.
In the end, we created a simple product roadmap and hired a full time developer. Our discovery phase lasted one day.
The founders called me two weeks later and told me that they wanted to change the roadmap because of all the exciting news they had just learned from their customers.
Had they worked with Bob, they would have had to pay to change the specifications they had just paid $20,000 to create. And most likely, they would never have been able to get rid of Bob because no one else would know how to work with his code.
It’s hard for CTOs to be strong at building teams and coding at the same time, so you’ll need a stronger Team Coach when your CTO is responsible for coding. Also, you’ll need a stronger Team Coach when you work with a development firm.
When your Team Coach starts becoming responsible for milestones or deadlines, it’s time to convert them to CTO and find someone else to look over their shoulder.
Despite what you may have heard, your CTO really shouldn’t code for you. Ideally you want a Development Firm/Lead Engineer/Technical Cofounder/VP of Engineering to be in charge of delivering code and a CTO or coach to be responsible for building the team and processes.
Besides looking for general cultural fit, screen candidates with this criteria:
Start slowly and look for alignment.
Save your equity pitch for developers and hands off advisors. Most experienced CTOs and Team Coaches usually don’t care much for heavily equity-based relationships.
Once your product direction and team are ready to go, the final step is to ensure that your system is scalable and that your developers aren’t taking shortcuts which lock you into working with specific people down the road.
Although most Team Coaches were capable developers at some point, they are focused on people and process today, which means they are probably out of practice with the specific technologies you are using, and this means you need a 3rd coach to supervise your code on a regular basis – a Code Coach.
Code Coaches work at the lowest level to review code and architectural patterns. Like other coaches, Code Coaches aren’t responsible for creating your code, they only help you make sure it’s being built correctly.
Fred decided to work with a team of internal developers directly.
Three years and several decisions later, he had invested $7,000,000 dollars into his company but had almost no users. Yup, 7 million with zero traction.
Much of this had been spent directly on technology – the rest had been spent on ineffective marketing and operations because his site didn’t work.
Why? Because Fred’s advisors weren’t paying attention. Fred didn’t ask his Technical Advisor to review his code regularly. If he had, the advisor would have told him that he didn’t have the expertise required (I know because I met him).
The Technical Advisor interviewed a couple developers at the beginning, but didn’t do much after that.
The developers that had built the code lacked the executive skills required to convince the founder that he needed to spend money on things like automated testing. And, of course, by the time he finally brought me in, he had fired all his developers.
There was no way I was going to start over from scratch – that’s a rookie move for another guide. But, we also couldn’t easily hire new developers. New developers wouldn’t know if the changes they made would accidentally break everything because there were no tests to help them understand the consequences of their changes.
Thankfully, the old developers were open to working with us again, but we had to pay them more than before. It took months to build a test suite that enabled us to hire new developers and redesign everything.
In the end, we ended up with something that pros could have built for $500,000 in under a year.
Code Coaches are experts with specific technologies. They have recent practice working with languages like Ruby on Rails, Python, Java, PHP, .NET, etc.
These guys are the “nerds”.
You don’t need to talk with Code Coaches directly. Your Code Coaches should report their findings to your Team Coach and CTO.
Finding Code Coaches is easy. Your Team Coach can help you find, hire and manage them. They also happen to much cheaper than Product and Team Coaches. Code Coaches for early stage teams are usually Directors of Engineering at established companies while Product Coaches and Team Coaches are CPOs and CTOs respectively.
People often wonder if Code Coaches are really needed when capable CTOs are on the team.
Code Coaches allow CTOs and Team Coaches to remain open to working with any reasonable technology so they can help you find the most cost effective people possible.
I hire Code Coaches for every team I shepard.
The people on your team are always compromised in one way or another. The obligation to drive results affects their objectivity, and your entire team needs to hear an outside perspective.
If you are using several technologies, you probably want a couple different technology coaches, or “domain experts” – each specializing in a specific technology or domain.
If you’re thinking that Team Coaches, Product Coaches, and Code Coaches sound like Chief Technology Officers, Chief Product Officers, and Chief Architects – you’re right.
The important thing to remember is that while Technical Coaches are hands-on, they are not your CTO, CPO, or CA. They only help you manage and support the people responsible for meeting your deadlines and budgets – including your CTO.
If you have a CTO, then your coaches supervise and support him/her. If you don’t, your coaches supervise and support your developers and development firms directly. The more capable your CTO, the less help you need from your coaches, and vica-versa.
It’s okay to turn a coach into a CTO down the road, but know that the moment your coach becomes responsible for delivering results they become compromised and unable to assist you as a coach. The reason is that no one can objectively help you assess their own performance.
Key Concept – Coaches Are Not Responsible For Driving
Results, Your Team Is (Or You Are)
Think about it this way. You, being a good leader, need to push your team from time to time. At some point in the near future, you are going to tell the people building your software to move faster regardless of what it takes to make it happen.
In turn, a reasonable CTO might warn you that you are making a costly decision, but eventually back down and take the shortcuts needed. At the end of the day, you’re the boss.
This causes a damaging conflict of interest because your CTO might lose their job if they continue to push back. But a coach can. A coach can remind you to repair the shortcuts you have taken because they aren’t responsible for how fast or slow things are moving.
They can speak freely because they are only responsible for ensuring the performance of your code, team and solutions.
Three things matter far more that shipping code quickly and cheaply.
To realize the full power of coaches, work with specialists.
Your first coach, the Product Coach, needs to be great at figuring out which problems are really worth solving to help you to find the cheapest and simplest solutions to those problems.
Your second coach, the Team Coach, helps show you how to locate people, evaluate their performance and implement your processes.
Your final coach, the Code Coach, works at the lowest level to review code and architectural patterns.
Coaches aren’t responsible for creating your code – they only help you make sure it’s being built correctly.