Lessons of a Startup CTO

For the last 4 years i have been the head of technology for MeetMindful (TS W16). I moved on a couple of weeks ago. It was time.

Being away from the hustle and bustle has afforded me a chance to reflect on how things went over those years. I started as the first employee after the cofounders and became the CTO of a team of 25. A lot had changed. We each learned. Everyone grew.

While the growth i experienced there in 4 years will pale in comparison to the grander startup tales, i wanted to share the biggest learnings i've had on this journey. Some of things i nailed and reaped enormous benefits from. Others, i failed at miserably and will be sure to correct in the future. Each of them are tips i would happily tell anyone embarking on, or part of the way through, a similar role.

Prioritize engineering time to address tech debt

You probably have a strong reaction to this headline. When you say this to an engineer you are likely to get a response like "duh" or "with what time?" Many might have both simultaneously. Therein lies the challenge with this.

The fact remains that tech debt can be a hard thing to justify in the moment. Pressing product or business concerns have a way of always being prevalent in an evolving startup. But at a fast moving startup, those conditions can appear to always be present. Sometimes you need to be the naysayer to allow for code cleanup. Without regular cleanup, the structure you are all working towards can start to resemble a jenga tower more than a skyscraper.

Refuse resume-driven development

The line between refactoring tech debt and searching for an excuse to try the library du jour can be a surprisingly thin one. This is especially true in the current JS ecosystem which more closely represents a sort of technological primordial soup than rigorous engineering output. Which is not a bad thing. But like early life forms, young libraries should be given an opportunity for evolve before they are relied on for production purposes.

Regularly share with your team

If your experience is anything like mine, it is almost more appropriate to have a portfolio than a resume. Personal products sitting in mothballs, random open source commits and frameworks few have heard of. None of this is on my resume, but the evidence of this experience provides value in tidbits over time. Your team is done a disservice without these lessons being shared with them.

Find the medium you can best provide this feedback. For some that is paired programming. Others might find it in code reviews. I've had success pairing with an engineer and writing a document on the suggested way to handle one layer of the codebase (CSS, React, etc). Whatever method you choose, make sure it is also a two-way street. You do not know it all, so be sure to make space for your learning as well during these opportunities.

Have biweekly 1-1s with each member of your team

There is simply no replacement for having a regularly corrected understanding of how each of your employees is thinking and feeling. Authenticity can be hard in some of these meetings, but do your best to make space for it. Being authentic yourself can go a long way here. Another trick i found helpful was to schedule my 1-1s in blocks, starting with the people i felt were the most outspoken on the team first. This would often surface problems early that i would check on with other engineers later on. The goal here is to find the wins and frustrations of your employees and make sure you can systematic in your improvement of process and team dynamics.

Finally, i understand that this goal becomes impossible at scale. Once you have enough engineers this should perhaps be worded as with each "direct report". But those words gross me out so the headline stays at is.

Be authentic and transparent with your team

I've written before about my general disdain for masked managers. I believe strongly in being completely authentic with your team. Sometimes that authenticity will make you look bad. While it can be hard, i would encourage you to not try and save face. Be honest about your failures. Ask for suggestions from them, especially when you don't know the answers. Assuming you have hired a great team around you, they will see through your bullshit anyway.

Other times, that authenticity will cause the person grief. Whether this is on interpersonal issues, raise talks or firings. Honesty followed with support are the best policies here.

Be even more authentic with the leadership team

I will not soon forget a moment in a weekly leadership team meeting where our CEO asked for the status of a report she was waiting on. This was the second week she had asked for it. "Honestly, I think I am unconsciously committed to not doing it" was the answer she received. I sat there in absolute awe at the comment. While it may sound combative or dismissive on paper, it wasn't. There is actually a great deal of vulnerability there is you look for it. Either way, this is an example of what i would point to as radical authenticity in a team.

While it took a while to truly gel, the leadership team at MeetMindful was a group of relationships i will cherish. I've simply never worked with others who cared so deeply about being radically authentic with one another. I came to value this authenticity and openness more than i ever understood in the moment. But it was the company itself that was the true benefactor of the honesty in our meetings. Issues were sorted out quickly. Personal gripes and drama simply didn't exist for long if at all. When a company chooses to pride itself on being transparent, that must come from the top. If you can't be authentic in a room of your peers, you are lying to yourself and everyone else to say you could do it any other time in a constructive way.

Meet with product and customer support people regularly

In the lifecycle of customer-facing solutions, engineering sits between product and customer support. That is to say that we execute on the vision and research of the product team. Once that vision is released, we are in part responsible for the solution for the issues raised by the customer support team.

Keeping regular tabs with both of these departments is essential to keeping engineering from becoming a silo-off black box in the company. You must understand the context of customer sentiments to be able to drive technology decisions properly. Those sentiments can be found in product's user testing sessions as well as the myriad of channels your customer support team likely juggles. Develop excellent working relationships with members from both teams. Again, make sure those relationships are founded on authenticity. The more you know about the sentiment of your users the better positioned you will be on adjusting the feature velocity compared to tech debt and other engineering efforts.

Create a culture that reflects yourself

One of the members of our team once made the analogy that a company's culture was a soup. Every new person you added to the company was another ingredient to that soup. The first few employees are each one of a few ingredients, so a bad one stands to make the entire experience quite poor. As the pot grows, you get some wiggle room for the ingredients you choose, though hopefully never compromising on the quality.

To this end, be sure that the spire you add to this soup is one that is reflective of yourself. At the risk of sounding like a broken record, i consider this to be another form of authenticity. When you are in a position of leadership people will model their behaviors and feelings off of how you present yourself. If you choose to do that in a way that isn't honest to yourself, you will find it tiring to show up everyday. Worse, you risk creating something you dislike. Instead, be the version of yourself that makes you happiest. It will come through in how you arrive. One day, if you are lucky, you will come to work and realize you are in a company designed by your dreams. How wonderful it will be to learns others enjoy it as much as you do.

Internal tooling and integrations are a worthwhile focus

Engineering plays a unique role in a technology company. The reason for this is that your customers are whoever you choose to define them as. The obvious answer to that are the people who pay your company. They are your customers. The less obvious answer would be the people the company pays. Engineering need not always be building things for the outside customers. In fact, we have already stated this: addressing tech debt is actually thinking about the engineering team as the customer. We are investing efforts to make the live of the engineering team better.

Another way to handle this is through internal tooling. Sit down with people in various departments regularly to get a sense for what people are doing with their time. Find out how they work. It may surprise you to find that they way to make the company the most money this quarter is not to build some swanky new feature for your external customers but instead of build or integrate a tool for another department, boosting their efficiency considerably.

Check how you could have been the solution to problems

Given the impact tooling can have it is useful to ask yourself, if only internally, how could you/engineering have been a solution to every problem you hear. Sometimes the answer will simply be that you couldn't. Bugs and quality issues will also have more obvious answers. But after these you would be shocked to find how many times you do have an answer for it.

Many of those answers won't be worth pursuing immediately if at all. Others will open your eyes to possible solutions a CTO or engineering team is uniquely positioned to solve. For better or worse, when an engineer hears a problem described, our brains think of that problem very differently than most people's do. Leveraging that for the benefit of your company is a responsibility that someone in this position should train to become better at. At the same time, ensure you don't get distracted by this endeavour. Your goal is to maximize the value output of the engineering team, not being the coolest thing you can think of this afternoon.

Invite people to lunches

Lunches, particularly ones people don't have to pay for, are a great way to remove some of the structured formality that exists in the office and give people a chance to vent and share their thoughts with you. Sometimes your position in leadership an give their idea a voice they always wanted to have. Other times it will be an opportunity to hear ideas for internal tools or process updates. Sometimes, people just need an ear for issues they are having in or out of the office.

Regardless of the circumstances, i cannot think of a single time i went to lunch with a single person and came back thinking to myself, gosh that was a waste of my time. When you are in a position of leadership, all employees, on the engineering team or not, are people who are putting an above average amount of trust in to you. It is your responsibility to be a faithful steward of that trust. Building it and caring for it, actually caring, is a big piece of that pie.

Maintain the best team you can

I've debated at length what the primary responsibility of a CTO is. Each time i do, this in on my short list as being the #1. It also means there is a great deal of depth to this particular learning. Maintaining a team isn't just about keeping the people you have. It is about weeding out the ones who don't belong. It also means always improving at you ability to identify and hire those that do. This means being good at hiring, fast at firing and constantly adjusting the process to keep your team both as happy and effective as you are capable of.

You might have noticed that a number of other learnings in this post work in service of this greater goal. That is because this is a task filled with nuance and context. How do you ever know if you hired the best people? Did you let go of the wrong people? I don't know that there are affirmative answers to these questions short of omniscience. But if you can look back with confidence on your choices, you are likely going in the right direction. Do your best stay? Are you regularly proud and awed by what they do? If so, keep doing what you're doing. If not, ask yourself, and them, what is missing. Dig deep, don't be satisfied with surface level platitudes. There will be value in your discoveries.

Be a shit umbrella

Put simply, there are 2 kinds of team leaders: shit funnels and shit umbrellas. Most of us have had the experience of working with, and under, both. Now, i've not met someone who particularly likes spending their time under a shit funnel.

Shit umbrellas, but comparison, work to shield their team from the nonsense above. In fairness, it isn't nonsense. But that is often how it feels when you are exposed to content absent both its speaker and the context in which it was shared. Great leaders find ways to both shield and integrate the feedback and grievances from others into their team and process. Do so constructively, and always without blame.

Refer to the team as "we"

"I've said before that as an engineering team, we win as a team and we lose as a team. Today, we won as a team". This was a line i said when i spoke to the company after a successful launch of a new product that had been in development in one way or another for about a year. The point of the "we" usage is not about the wins, though. It is about the stumbles and the falls.

When you get a company used to hearing about the engineering team referred to in the plural, it gives you the freedom to acknowledge both wins and failures without blame. This is important. When you are pushing for authenticity and transparency in a team, being able to openly share the failures and the respective improvements they will bring is a hard requirement. But doing so safely, where engineers have the freedom and protection to work on challenging problems is also a departmental necessity. Save yourself the pain and start referring to the team as "we". Do it from the moment you have an engineering team of 2. Hell, do it when it is just yourself, and explain the rationale. You might be surprised how natural it feels over time.

Build a user segmenter

In my 4 years with MeetMindful i accumulated over 6,500 code commits, over 6 per day for 4 consecutive years. Throughout all of that code, easily the most impactful thing i would point to in the codebase was our user segmentation engine. This relatively simple code allowed us to segment the user base in any format we chose. This enabled feature testing on a scale i had never experienced in another other codebase. Tests could be run across geographies, ages, personas, genders, completely randomly or with any other arbitrary method you could imagine.

We built this early on and reaped its benefits literally every single day after its release. The freedom and control this afforded the engineering and product teams was something that went unparalleled for years. To this day if someone where to explain to me their business and ask what they should build next, i would start by asking their DAU. It was over 100, i would suggest building a user segmentation engine, practically irrespective of their industry or service.

Integrate behavioral tracking

I struggle philosophically with this point. As someone who is privacy-focused, this particular point flies in the face of my ideals. At the same time, the power and understanding that behavioral tracking can afford a young team is unmatched for product improvements. The trick is to arrive at these learnings in a way that empowers you customer support and product teams without sacrificing the trust users inherently have with your service.

The "obvious" solution here, assuming you are privacy focused like myself is to track these details internally and never share with with third parties. You will likely find, though, that doing this is no small task. Meanwhile, third party solutions are increasingly robust and elegant in their execution. They can enable non-technical people to answer all manners of behavioral questions without needing an engineer to dive into a database.

Whatever solution you choose, do make sure there is a solution in place early on. Make sure that if you are building a user segmentation engine, that engine exposed to the behavioral tracking which test group(s) the user who generated some activity is a part of. The harsh reality of these tools is that they allow people to answer questions empirically that are simply unapproachable without a degree of guesswork otherwise. Invaluable for a team of nearly any size.

Love what you do. Stop when you don't.

They say art is a labor of love. I say coding is an art. To that end, this is the point i would consider most applicable to anyone in an engineering team, including those in leadership. All companies and their teams will go through swings that will make you more of less happy to be working their. None of those should impact your love for the role you play any more than argument with a sibling impacts your love for them. This analogy breaks down, however, given enough time. Like and artist laboring over the same painting for too long, the passion for the piece can eventually fade. When this happens, it is important that you recognize it.

One of the struggles i had with leaving was the worry i would be leaving my team behind. I've come to recognize this opinion as a nonsensical and frankly arrogant reason to ever stay with a company. Chief among showing up authentically with your team is the ability to say you are happy with where you are and are continuing to strive for more. More for yourself, more for the company and more for you team. They often go hand in hand for well-run teams.

When you can no longer say that, it is time to step away. Make room for someone else to carry the torch. Give a member of your team the opportunity to shine in a role they didn't realize was a possibility for them. Make space. Watch what happens and be there to support them when the needs arise. Even if that is from the outside.

Today

In many ways the length of this post is confirmation of the mountain of learnings to be found on a journey with a startup through years of growth. These lessons are hard earned. Too many of them were lessons learned too late. Perhaps that makes them the most memorable.

For those of you for whom this resonated, i am always happy to talk, answer questions or help in any way i can.

tl;dr: The journey of a startup CTO is one of passion, creativity and problem solving. After 4 years with a Techstars startup, these are mine.