Inheriting an engineering team and product comes with a lot of challenges.
An incoming VP of Engineering needs to get up to speed on the technology and learn how to build on top of decisions that someone else made.
Plus, not only do they inherit the product, but a team of people as well.
The engineering team at DC based startup, Till, recently experienced this transition. They use rental housing as a platform for financial inclusion by helping residents pay, stay, and thrive in their homes. They also build products for landlords to help them extract the maximum value out of their portfolio, while enabling residents to live better lives.
The startup originally employed a fractional CTO to spearhead their engineering efforts. Once they were ready to scale their product and have a larger user base, they knew they needed a full-time resource to lead the engineering team.
Johnny Ray Austin, local technologist and thought leader, stepped into that position and now serves as the Chief Technology Officer (CTO) of Till.
In this interview, he shares a unique perspective on inheriting a product and the role of a fractional CTO.
The conversation below has been edited for length and content.
Till had a unique start to their evolution with the usage of a fractional CTO in earlier stages. Then you transitioned in as a VPE. Can you talk us through that transition?
It was actually quite an ideal situation for myself and everyone involved. The fractional CTO, Matt Walnock, does this as a living and runs his own CTO coaching agency, Longitude-77.
I was pleasantly surprised that just enough of the early platform was built out to get product market fit and prove the hypothesis of why Till should exist. We already had customers using it, but things were built in such a way that all decisions were easily reversible. It was a very Zapier approach where you’d use existing SaaS tools. It was all pretty minimal, with just enough technology enablement to get the ball rolling.
When I came onboard, there were a couple of engineers who had started a few weeks prior, so we were all pretty new. As I started meeting with Matt and two other engineers, it was pretty straightforward to see what we were building. We were going to take this SaaS enabled product and use it to build out our platform so we could scale to our target number of users. A lot of things were in C#. We wanted to do more JavaScript and TypeScript and run a couple of things in Azure. Subsequently, we moved over to AWS.
It was pretty straightforward. To be honest, my situation isn’t indicative of what many other people face. A lot of people go into a big mess and do something like a cloud migration or rewrite everything in a different programming language. We did a little bit of that, but there wasn’t much to do.
Were most technology decisions already in place or did you have a chance to collaborate with Matt and make recommendations?
Matt had the mentality of “it’s your team, build it in the way you envision it.” I really appreciated being given that autonomy. He took nothing personally.
So, when I decided to transition from Microsoft technology to AWS, he encouraged me to do what was comfortable for myself and the team.
That process was pretty straightforward.
The decisions made thereafter were really about myself and the team of two engineers I was inheriting. I would ask Matt for advice and whether there was anything I should take into account as I transitioned into my role. A lot of decisions were made by our team with advice from Matt along the way.
How long did the transition take from when you came in, to when the fractional CTO had fully transitioned out?
It was very much a slow roll, and it’s still not “done”. Matt’s in Slack right now as a guest and I could ping him if I needed to.
Initially, he came into the office a few times a week to do standups with the team and catch up on what people were working on. He did that for about a week until I felt good about running standups and knew what everyone was working on. Then it transitioned to him coming in every couple of weeks to grab lunch and catch up. Then it was every couple months and eventually became, “let me know if you need anything.”
Every once in a while, he’ll still ping me to check in and see if I need any support. That tends to lead to a conversation. So there was never really a “clean break.” He’s still around in a lot of ways.
What did the interview process look like, from buying in with the vision to buying in with the technology?
It started off with the founder, David Sullivan. The first part of the interview was in a coffee shop in China Town. It must have been about two hours. We had a great conversation. He gave me the overview of the business and told me about where he saw the platform going.
He comes from the real estate industry, so he’s not a product or tech guy. But he does have an understanding of how technology enables the product he wants to build. We talked a lot about that and how he saw data playing a big part of that strategy.
I was able to engage with him at a high level about my thoughts and how I would approach it. It was a really good conversation.
The next step was to meet with him again and also Matt, the fractional CTO at the time. It was really just Matt validating my technical background on behalf of David. We got more in the weeds and talked about data and data strategy. There were a few tangents about specific technologies and how to solve specific problems. We also talked about building teams. It was a very broad discussion.
The job of VPE, especially at an early stage startup, spans everything from hiring to building teams to the technology strategy. We touched on a bunch of topics.
After that, I interviewed with the two engineers who were already there. We went deeper and discussed very specific technology questions. They also asked questions about my expectations and leadership style.
During the interview process, did you all discuss what the leadership transition would look like or did you decide to play it by ear?
We did have explicit conversations about the transition. Their feedback was that it was all on me. It depended on how soon I could become comfortable enough with what we were doing to take everything over.
The timing was all on me. Matt was very generous with his time. He let me know he’d be there as long as I needed him to be there until we had a successful hand off.
It didn’t take very long for me to come on board. Because the company was in such early stages, not much had been built. It didn’t take long for me to get a handle on what was there and what we were trying to build. At that point, everything else was just implementation details. It didn’t take long, but if I needed more time, they would have been fine with it.
Were there certain things that the existing leadership had done well to make the transition seamless?
The best thing they were able to do, honestly, was go hands off. They answered my questions if I had any, but they were very unopinionated. Their mentality was, “it’s your show.”
I work best when I’m handed a problem and am left to my own devices to figure things out. So, in this case, I was handed a product that existed in a certain way but needed to be scaled for more users.
I think I would have struggled a bit if I encountered roadblocks from them being very opinionated. I would have been like “come on guys, you have to get the handcuffs off if you want me to do this.” But I didn’t run into those issues.
I think they did a really good job of giving me autonomy to just jump in.
Do you have any tips for other early stage companies going through this process?
I’d say it’s helpful to not get too invested in what you’re building on day one.
I really liked that SaaS or Zapier approach that our founders and fractional CTO took. They used just enough technology to solve a problem and nothing more.
You don’t want to get too tied to anything.
Granted, you want to respect the people who had been there before, but the thing you want to focus on is handing problems to your leadership and not recipes to implement.
I was extremely fortunate because I came in so early on. If it were to happen now, at Till’s current stage, it would be a completely different ballgame.
We’re deeply embedded in AWS. We have a product that serves a lot more customers than we did at that time. A handoff would take a lot more time.
Another aspect to consider is that it’s not just the technology that’s important, but the people. You’re not only taking over the technology or department. You’re taking over people’s careers, growth and guidance.
You have to handoff that knowledge of the people on your team. It’s a much harder process than handing over a few passwords and saying, “this is how we’re doing it.”
I’d also say not to change things for the sake of change, since that could be highly disruptive. Make sure there’s a reason for it.
Are there specific traits or attributes in a person that would allow them to operate better in this fractional CTO model?
I think fractional CTO’s are a bit more solutions oriented and not too invested in a specific technology.
I think they have to be pretty confident about what they’ve done and how they’ve brought the team along. It can be very easy for people to get defensive about the decisions they’ve made.
If they’re not confident, when someone comes in and makes a different decision, it would be easy for that fractional CTO to be sensitive about the change. If someone comes in and has a better way of doing things or more of a long-term vision in a different solution, it’s important to be on board with that solution.
Also, it’s just good to respect that person’s space as they come in and get a handle on things. Success in this kind of model takes someone who’s self-aware and not too invested in the way things are.
In early stage startups, titles can mean many different things. You came in as VP of Engineering, but recently got promoted to CTO. Did that title change come with additional responsibilities or was it similar to what you were already doing as VPE?
I had been in the VPE role for a little over a year.
I’d say that 90% of my work is exactly the same. I still have my team that’s building the product and I’m still working with our product manager to help with delivery.
The last 10% is the unseen work. It involves working with the executive team to push forward the business strategy and not just be the representative of the tech team.
It involves me challenging our company on how we use data and making sure we’re doing it in a responsible and secure way.
We have to understand that we could be dealing with vulnerable populations, so it’s important to make sure we’re doing right by all of our customers – both the residents and the landlords. We have to make sure we’re looking out for their best interest and that we’re securing the future of the company.
These are conversations that would occasionally pop up in the VP role, but now it’s much more of an expectation moving forward.
Searching for a new Job? Send us your resume.
