The First Time I Became a CTO

Problem

"In 2016, I became CTO for the first time in my career, joining a 60+ person startup based in KC, focused on the commercial solar space. I was a co-founder of a small startup (< 15 people) and became an executive of a larger software company that had acquired us. However, that took me away from software engineering and I was itching to back into hands-on development as well as leading a software engineering team and helping grow a product. I was taking over a team of 12 people and the company wasn't a tech company so the software team was almost a side pet project of the CEO and he had made some mistakes with the previous leadership. Thus, he was looking for someone to help him fix it."

Actions taken

Before I joined

"Do as much research as possible"

"First, I actually did a short consulting gig with them before I joined, so I got an in-depth look into the code base and processes they had built before taking over the team. An interesting dynamic was that the previous director of engineering, who built this team, was still there, so I spent some time with him but I didn't really get access to the rest of his team. By the time I started 6 months later, he had already left, so I didn't have to contend with him. I also knew ahead of time that this was sort of a 'turnaround job' based on conversations with the CEO and CFO."

First Week

"Getting to know the team, presenting your technical leadership philosophy"

"In my first week, I met with all the members of the team in the KC office. We had 7 team members, 2 in QA, 1 scrum master, 2 IoT engineers and a do it all devops engineer. There were also 5 remote Upwork employees who maintained and architected the stack, but I'll get to that later. When I met the local team I wanted to get to know them, understand their roles, and specifically what they would change about the current processes and technology that existed. I also met with the head of product and got her take on the situation. Furthermore, I spent more time getting deeper into the code base (Angular / NodeJS stack), and trying to figure out what tech we actually had. This was a bit hard given that I didn't have experience with that stack, but I tried my best. Finally, I did a presentation with the local KC team about my leadership philosophy- building a team based on autonomy, mastery, purpose and transparency."

First Month

"Building the right team and creating a bond"

"Given my suspicions after my initial consulting gig, and confirmed by the existing team, I acknowledged that we had overbuilt the product. We spent way too much time and money on it without really gathering meaningful requirements or having a cohesive team or architecture. Since we had to deliver a new 'control' product which would manage a fleet of thermostats (think Nest for businesses), it came decision time to either build on what we had or to start anew. I felt confident that there was enough talent and knowledge on the local team to start fresh. So, I cut the entire remote team, and decided to build the 'control' product completely in house."

"However, I was faced with two problems. One, I wasn't sure some team members could adapt to this new structure. Second, even though I had a ton of rails experience and enamored with Elixir/Phoenix, I wanted it to be a team decision. Thus, we decided to spend a month to evaluate different technologies: RoR or Sintra, Elixir/Phoenix or NodeJS all connected via a front-end either Angular or React."

First quarter

"Building the right product with an energized team"

"After the first month, it was clear that one of the QA people could not cut it. I was syncing up with each team member every week, so it didn't come as a total surprise to the person or the team. Once we picked the stack (React + Elixir / Phoenix), we wanted to build a POC of a new Control system. The scrum master was also struggling a bit, so I worked with him on a one-month plan including check points on his progress. The others were doing well, and to my surprise the alternate QA person was doing well as a React developer and was just previously being misused. The same was true for the devops engineer who was just a great all around developer. This gave me more confidence that we could build a functioning MVP."

"The other thing I did was blogged about this process and how we picked the stack and rebuilt our architecture from scratch. This also had the side effect of letting the rest of the company and CEO know what we're doing, in an open and collaborative way."

Successful launch but short tenure

"In the end, I had to let the scrum master go, but parted ways in the best manner possible, as he also recognized that he wasn't a fit. Over the next few months, the five person team was able to launch our control product and we successfully onboarded our first customer. However, the main solar business struggled and eventually the technology team was spun off as its own company. I chose not to stay on and moved back to SF to be CTO of another small startup. I remained in touch with the team, and while they chose to focus on a different market they ended up raising multiple rounds of funding and eventually had a successful exit in 2019."

Lessons learned

"Find purpose through the customer and build an autonomous team focused on mastery"

"This was my first gig and I was definitely unsure if I was doing the right thing. But in the end, I trusted my gut which said follow the customer use case and use that as your sense of 'purpose'. Make sure the team understands what they're trying to do and get them excited about it. Then, create an environment so that the team can decide on the right direction to execute. As the leader, you of course need to course correct and adjust as needed, but leave it for your team to guide you. Finally, push them harder, ask them to aim higher. Even though we did some great things the first few months, we had much more to do and had to get better. Continue to set the bar higher and don't get complacent."

"Identify your stars and trust them to provide you direction"

"This team proved it for me that the existing teams knows what to do, but maybe didn't have the permission or time or experience to implement it. It's your job as the leader to identify your advocates and detractors, and then create a system to allow your team to make the necessary changes to achieve success. I've used this identification model ever since."

"Make decisions and course correct quickly"

"There is no perfect time to make decisions, and I've definitely made mistakes in not acting fast enough or too fast. But in this particular case I made a quick call and it worked out. It was an informed decision but fraught with uncertainties. Could the team really execute? Did we give up on the old architecture too early? Did I even understand it? Did we pick the right tech? Is the tech too new and were we too inexperienced to build on it? In the end, you'll continually make decisions and you have to adjust accordingly."

"Be transparent and consistent"

"Be open and present your thoughts. Write everything down. Do presentations. Do lunch-and-learns. Have consistent team standups. Then write it all down (I put it in a GitHub 'getting started' repo) and blog about the whole experience. Also make sure you include other cross-functional teams and be open with them on what you're doing. Finally, repeat your message and framework constantly and consistently. As we went through a lot of ups and downs, I was always open and honest with the team. I tried to keep them up to date, focused on the task at hand, and on track to following our development philosophy and methodology."