Answers That Depend: Tech Leadership Q&A, pt 1
Your questions from the newsletter and podcast
Welcome back, everyone! Now that we've wrapped up the book, I've been diving into all the fantastic questions you sent. This week, I'm sharing some particularly interesting ones that touch on challenges many of us face in tech leadership. If you'd like the extended, audio version of these questions and answers, you can listen to the latest episode of the podcast.
Matrix Organizations and the Accountability Dance
Luca R., an engineering manager at an EdTech startup in Milan, wrote to me with a challenge I hear about quite often:
"How can I keep clear accountability in my engineering team while encouraging collaboration with product and design teams? We need to avoid silos but still meet our sprint commitments."
This is a common tension in matrix organizations. Every part of the organization touching the product wants to drive accountability, and it can get messy fast. I've actually had to correct product manager job descriptions that claimed they "owned" things because they don't own them alone. They collectively own them with other teams, like engineering, quality, and design.
I believe that the rise of combined product and engineering leadership roles we're seeing is partially an attempt to address this very issue. When product and engineering have conflicts and don't report to the same person, it's tough to resolve them. So companies think, "Well, one person needs to be responsible, not two."
But in a healthy organization, it's an agreement. Engineering doesn't own product direction; that's the product team's job. And the product team doesn't own delivery, that's engineering's responsibility. Each role has its domain; the key is making that crystal clear while working as one team. I have often said that the occasional tension between the different disciplines produces better results.
As a CTO, my relationship with the Chief Product Officer must be incredibly tight. We need to know everything the other is planning and thinking about. But it goes beyond that; I also have to coordinate with Marketing, Finance, and Operations. We all bring different contexts to the table and build a shared vision of where we are heading.
The same principle applies at every level. You and your product and design peers need to share context constantly. They will bring perspectives you don't have from their disciplines and conversations with their managers. You bring the engineering context they need. Together, you build that shared vision and move forward as a team, with each person accountable for their part.
If you're struggling with a product manager who doesn't see it this way, that's a conversation for you and your manager, and for them and theirs.
The Challenge of Measuring What Matters
Tatiana O., who heads data science at a FinTech company in Tallinn, sent me a thoughtful question about performance reviews:
"We have great systems for measuring quantitative outputs: models deployed, accuracy improvements, but how do I properly evaluate team members who excel at mentoring or generate innovative approaches that don't translate to immediate metrics?"
Tatiana, this is the eternal challenge, especially for data-driven leaders like yourself. Qualitative contributions are hard to measure precisely because they're qualitative, not quantitative. But you're absolutely right that both need to be acknowledged in your evaluation framework. Otherwise, you end up building a team that's great at hitting numbers but terrible at working together.
The best approach I've found for measuring these soft skills is the 360 review. If your company doesn't formally do them, that doesn't mean that you cannot. For every person I'm reviewing, I send out a simple questionnaire to everyone they work with: their reports, if they're a manager, their peers, and folks from other departments they interact with regularly.
I keep it short because you want people to actually fill it out. My go-to questions are: What is this person doing well? What could they do better? Is there anything I should know that you don't think I already know? Sometimes, I'll add one or two more, but brevity is key. I'm not expecting essays. A couple of sentences or a paragraph is fine.
What emerges are patterns. Common themes about someone's mentoring abilities or innovative thinking start to surface when multiple people mention them. This gives you some data to back up your observations and helps quantify the unquantifiable.
Now, data science folks don't always respect these kinds of qualitative measures; things like customer satisfaction scores can seem fuzzy. But we're evaluating people, not algorithms. While it's tempting to make everything as numbers-driven as possible, we must remember that people are all different, and the value they bring is also different.
From Data Science to the C-Suite
Tatiana had a follow-up question that I found particularly interesting:
"I've built a data science department from zero to 15 specialists. Is CTO a logical next step? What capabilities should I develop beyond technical knowledge?"
This is a great question, and the answer depends on what kind of CTO role you envision. Given your background, the most natural progression might be toward a Chief Data Officer role. Not every company has one, but data-driven companies often do. Depending on the company's focus, a CDO might report to the CTO or even directly to the CEO as a peer to the CTO.
But it sounds like you're interested in the broader CTO role, full technology responsibility beyond just data. That's a bigger leap, but definitely achievable. You'd likely be running engineering, IT, and other technical functions in addition to data.
The key question is: Are you interested in being a CTO at a technology company that's not specifically data-focused? That requires building a much broader skill set. You'll need experience with product development, production systems, and the full software development lifecycle.
If you're serious about this path, talk to your manager about taking on more engineering responsibilities. Maybe you could lead some data-driven product initiatives within your current team. This would expose you to working with product teams, dealing with production systems, and managing the whole development cycle.
You might even consider a lateral move into engineering leadership for a while. It might mean stepping back temporarily, maybe managing a single engineering team, but your seniority and leadership experience would likely put you on a fast track for broader responsibilities.
Your background might be enough for a data science company to land a CTO role directly, especially if you can hire a strong VP of Engineering to handle the pure engineering aspects. But for a broader technology company, you'll need to demonstrate that wider experience.
Staying Resilient in Uncertain Times
Priya D., the lead of a payments integration team in Bangalore, asked about protecting her team from potential layoffs:
"With layoffs happening at nearby FinTech companies, how can I protect my team beyond the usual 'keep your LinkedIn up-to-date' advice? Our CEO says everything is fine, but I'm not fully convinced."
Priya, your skepticism is healthy. When companies in your space are cutting staff, it's smart to be proactive. The most important principle I can share is what I call "be the franchise." It's a sports metaphor that refers to being the most important player on the team. In a company context, I use it to refer to aligning yourself (and your team) with the company's priorities.
In a FinTech company, your payment integrations team is probably already in a good position. Payments are mission-critical. But you want to make absolutely sure leadership understands your team's direct impact on revenue. Teams clearly tied to revenue generation or customer retention are much less likely to face cuts.
Keep your team visible. Ensure you regularly communicate what your team delivers and tie it back to company priorities. When leadership starts looking at where to cut costs, they will ask themselves: "Which teams can we reduce without impacting our ability to maintain or grow revenue?" You want the answer to be "definitely not the payments team."
Another crucial point: don't keep low performers around. Teams get reputations, and if you're known for harboring underperformers, you become a target for cuts. It's better to run a lean, high-performing team than to protect someone who's dragging down the team's reputation.
Also, build strong networks within your company. Sometimes the best way to protect your people is to help them transfer to other critical teams if yours faces pressure. And yes, keep your external network warm too; help those classmates who lost their jobs find new ones. They'll return the favor if you ever need it.
Thank you for your questions! Please send me more!
These questions really highlight the complexity of tech leadership. There's rarely a simple answer. It usually depends on your specific context, your company's culture, and the broader industry dynamics. But that's what makes it interesting, right?
Keep sending your questions to contact@itdependsbook.net, or reach out on Blue Sky, Twitter, or LinkedIn. I'm collecting questions for future episodes and newsletters, and I love hearing about your challenges.
Until next time, remember: the best answers usually start with "it depends."
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores