Hi Mitch, welcome to the Engineering Success Podcast. You've worked at a variety of companies, shaping technologies and products like Joomla! and now your current startup. What insights have you gained in building the right teams throughout your career?
When I initially became a CTO, I thought I had it all figured out—I was young, smart, working hundred-hour weeks, and I had everything wrong. I really learned about leading teams on the open-source side of my career.You mentioned Joomla. I go way back. I have commits in the 1.x kernel and was involved in Postgres very early on. I remember when we used to ship a tarball of the NCSA web server with a bunch of patches, and someday someone said, "That's an Apache server," and we called it Apache.
‍
My leadership skills developed almost exclusively on the open-source side. That environment is very different from the commercial world. In the commercial world, I have easy buttons to push: I can give raises, demotions, change titles, shift groups, or write PIPs. But with unpaid volunteers, you can't hire, fire, or give raises. You have to find entirely new ways to motivate people and help them find their own way.It's almost all relationship-driven, based on trust, transparency, and accountability. Setting my expectations and making sure they align with what someone is passionate about or good at, then keeping us in alignment and finding value in that relationship—that's what makes good open-source leaders. It's not just about being good evangelists and speakers; you also have to build relationships.
‍
As I transitioned from open source to the commercial side, I brought those leadership styles with me. In bigger companies, managers often pat themselves on the back for hiring but avoid talking about turnover. In my opinion, if you're not retaining your hires, you're not building an environment that sparks change.I've brought that open-source mindset into my leadership style. In entrepreneurship, it's a lot of trial and error. Some people are naturally gifted at business, like my CEO, who is always on the ball. I wish I had that skill, but I don't. As an entrepreneur, it's about repetition and learning from experiences.

As you move up in engineering leadership, hiring becomes more important. How do you balance the role of a CTO between hiring, strategy and technology?
‍It depends. The kind of CTO a company needs varies. For a major financial institution like Capital One, my role would be administrative, focused on numbers, executive relationships, and vision. For a small startup with a team of seven engineers, I'm doing code reviews, issuing pull requests, figuring out databases, and discussing features with the CEO.In startups, the role of a CTO is driven by business needs. I've been in startups needing a technical CTO focused on doing and keeping engineering moving fast. In others, the role was more about delegation and facilitation, ensuring the team is unblocked and aligned with business needs.

When building a team in my current startup, I knew it had to be lean and high output, so I only interviewed senior-level engineers. My favorite engineers are those who went to a bootcamp, early in their careers with lots of light bulb moments. But in my current role, I needed experienced, curious, humble, and friendly engineers who could handle a demanding environment.

‍In a small team, how do you ensure the team is working on business-relevant tasks and aligning tech efforts with business needs?
‍There's always a tension between chasing the latest shiny tech and adding business value. Engineers need to take ownership and pride in their work. I look for people who don't say, "It's not my job," and who focus on adding specific value to the business.In larger organizations, you can carry bloat. In a small team, one non-performing engineer is immediately felt. Code that doesn't add value or isn't aligned with business needs can't be tolerated. The focus must always be on what's adding value to the business.

How do you balance a performance-driven team culture with maintaining a healthy team environment?
This was something I learned in open source: you have to delegate. I have trust issues, so I'd rather do things myself to ensure they get done. But in open source, with limited resources, you always look for someone to pick up tasks so you can move on to the next thing.I brought this delegation approach into my entrepreneurial career. I give senior engineers a lot of autonomy, more than some are comfortable with. It's a calculated gamble, but it allows them to flex their muscles and take ownership. This approach scales the engineering organization and fosters a culture where everyone takes ownership of their work.

How do you avoid knowledge silos and ensure a fungible engineering team?
Addition by subtraction can work, but it can wreck morale. Cutting a superstar engineer can be culturally disastrous if others look up to them. To avoid this, build a culture where everyone is fungible. Preach the message that job security through knowledge hoarding is actually a trap. Make sure more than one person has critical skills.Engineers should own and maintain systems they build, which ensures quality and accountability. In healthcare, compliance requires separate teams, but in startups, engineers are responsible for running and maintaining systems. This ownership ensures they write reliable code.

You've been an advocate for engineering productivity. How do you see this evolving?
‍Engineering has become more complex. We're not building simple web pages anymore; it's hundreds of API calls and numerous dependencies. Managing teams and productivity has to adapt. Metrics that worked five or ten years ago don't apply to today's tech stack.Software development has shifted from handcrafting to scaffolding to using bots. Each shift requires starting over in managing teams. The signal-to-noise ratio with data is harder to manage, making it challenging to measure productivity accurately.

What role do you see AI playing in managing engineering teams and productivity?
‍AI can augment humans, not replace them. For example, a pet project of mine at Capital One aimed to consolidate knowledge from various sources to identify top projects or engineers with specific skills. AI can help make sense of vast amounts of data, identifying teams that need help or processes that need improvement.AI can handle grunt work, freeing engineers to focus on more valuable tasks. Using tools like GitHub Copilot, AI can convert formats or handle repetitive tasks. AI can also review code, identifying complex areas and suggesting improvements. It enhances our capabilities, making us more productive.

There's a lot of talk about 10x engineers, but you've mentioned the importance of building 10x teams. Can you elaborate on that?
‍Engineering is definitely a team sport. There's no room for superstars if you want the organization to win. A team of competent, dedicated engineers will outperform a single superstar. It's about creating an environment where everyone can contribute and excel. You need to build strong, cohesive teams that work well together, rather than relying on individual rock stars.

‍What does a day in your life look like as a CTO? And how was managing an open-source team different from managing your startup team?
‍Managing open-source teams involved language barriers, time zones, and unpaid volunteers with limited availability. Deadlines were impossible, and estimations were difficult. In a work context, business people have real demands and expectations because they're spending money on PR campaigns and ad spends.In a startup, my day-to-day varies. We're launching to a small market, so there's a lot of urgency and unpredictability. Some days are filled with meetings, others with coding or solving technical problems. The smaller the startup, the more variable the CTO's day-to-day can be. That's part of the excitement and fun of startups.Guy Kawasaki's "The Art of the Start" talks about starting a startup within a larger organization. You get the excitement of a startup with the stability of a large organization. I prefer the responsibility and pressure of a small business where any decision could be fatal. It's a personal preference for the challenge and excitement.

It's been amazing having this conversation with you, Mitch. Thank you so much for sharing your insights. I'd love to have you back for another conversation sometime.
The pleasure is mine.

- Mitch Pirtle