Career Insights from a Developer-turned-CTO-turned-VC

If you’re in the Boston startup scene, chances are you know Bob Mason. He’s the ultimate friend to founders, particularly highly technical founders who suddenly find themselves charged with leading and growing big businesses.

Bob started out as a developer. He studied computer science at Worcester Polytechnic Institute (WPI) and was one of the first engineering hires at Art Technology Group (ATG), which went public in 1999 (NASDAQ:ARTG) and was acquired by Oracle in 2010. Bob also co-founded and was the CTO at Brightcove (NASDAQ:BCOV). He’s been a mentor and investor at TechStars for over a decade and today, he’s the founder and managing partner at Argon Ventures, a pre-seed fund that invests in ​​intelligent industry solutions.

Bob’s an early investor in AppLand. He’s also a good friend who’s mentored me throughout my own career in startups. With all of the job-hopping and hiring going on in tech these days, I asked Bob if he’d be willing to share some of his career learnings with the AppLand community. Read on to hear more about his interesting career path and the advice he has for anyone who’s trying to figure out who they want to be professionally:

You’ve been a developer, CTO and now a VC. What was that evolution like?

Looking back, it’s clear that even during these transitions I’ve always been building. For the first 10 years of my career, I was a developer so I built by writing code. During the next 10 years, I was a CTO so I built by devising strategy and establishing great teams. And now in venture, I’m building by helping founders create companies.

ATG was my first job out of college. We were a team of 10 when I joined, and working at such an early-stage startup really wasn’t ‘a thing’ back then! It was intense and rewarding to invent a whole new industry. We began from a blank slate and had to literally write every line of code starting with a nascent version of Java. Eventually, ATG grew to employ over 1,200 people and even though I was a founding member of the product team, I really didn’t want to become a manager. Now I realize that was mainly out of fear.

Making the transition from developer → manager is tough. You’re usually working in this very collegial atmosphere, so it’s uncomfortable to suddenly have to manage your friends. When I co-founded Brightcove as CTO, I still didn’t want to manage anyone!

How did you get over the hump of not wanting to manage people?

Well, at Brightcove it got to the point where I had to start managing people. And that sent me into somewhat of an existential crisis! I’d always thought that the quantity and quality of code you wrote reflected your worth within an organization, but as CTO I was spending so much time writing emails, going to meetings and talking on the phone. If I wasn’t writing code anymore, was I even worthwhile as a human being?!

Lots of people hit this moment in their careers where they can’t quantify their output or value it in the same way anymore. During the first few years of Brightcove, I was still writing code in addition to being CTO. But after some self-reflection, I realized I didn’t need to be coding to find joy or feel valuable, so I just let go.

It’s not easy to no longer identify as a coder. In fact, it took me about a year to get comfortable with it. For CTOs and heads of engineering at startups, it’s particularly challenging, because your identity is never clear. You have to be a player/coach: You’re writing lots of code still AND managing a team.

What were the pros and cons of no longer coding full-time?

Emotionally, it was great. Once I accepted my evolution from developer → manager, I was a lot less stressed. I do occasionally miss coding, though. There’s such joy in completing something and knowing it works. It’s definitely hard when you transition away from being able to quantify your output. As a manager, your value is almost entirely qualitative.

What would you say to a developer who’s thinking about moving into a more managerial role?

Jump in and give it a try. Early-stage startups are the best place to experiment, because the structure of the organization (or lack thereof!) gives you the fluidity to try out lots of different roles in a short amount of time. Then, as you’re experimenting, ask yourself, “Do I get joy out of helping teams work better together or does this feel like a daily burden?” There are a lot of stereotypes out there about what managers and coders should be like, so keep an open mind.

But it’s also important to understand that one doesn’t need to become a manager to build a meaningful career and gain leadership. It’s awesome and hugely valuable to focus on the craft of coding and be a technical mentor to others. Great companies recognize this value and reward those who seek fulfillment in solving complex problems through code.

Any practical advice you can share for newly minted developers-turned-managers?

Seek out a triangulation of peer mentorship. In particular, look for:

• Someone at a similar stage (at another company), so you can talk about common challenges and commiserate with one another.
• Someone who’s slightly ahead of you, so they can teach you the ropes and answer some of your questions.
• Someone who’s just behind you, so you can mentor them. This is actually the most important one, because when you’re a mentor, you’re forced to have an opinion and synthesize information in a way that solves someone else’s challenges.

Has your background in engineering helped you be a better CTO and VC?

Absolutely. At WPI, the curriculum was all about project-based learning. We were taught to decompose problems into unit parts, which really is the fundamentals of engineering. You’re bringing a group of people together, breaking down a problem into discrete components and incrementally solving those components to deliver a whole solution. People who’ve trained as engineers think about the world within that framework, and it’s really powerful when applied to other fields and challenges.

I also still lean on the scientific method in my work today. I’m always thinking, “Ok, this is what our baseline is, this is what we’re going to change, and now let me evaluate how things are different after making that change.” It’s another fundamental mindset that I learned from my engineering training, and I’ll never forget it.

Thank you, Bob! 🤗

If you have any follow-up questions or insights of your own to share about navigating a career in engineering, we’d love to hear from you!