Back to Blog
Mar 01, 2023

The First 30 Days as a CTO or VP of Engineering for SaaS: What You Need to Know

Written by Zack Schwartz

Starting a new leadership position can be both exciting and daunting, especially if you're taking over a product or team that you know little about. The first 30 days are critical for setting the tone and direction of your leadership and establishing credibility with your team and other stakeholders. In this post, we'll provide a roadmap for surviving and thriving in the first 30 days as a new CTO or VP of Engineering.

Fact finding mission

Before diving into your new role as CTO or VP of Engineering for a product or team, it's essential to gather all the necessary information and assess the situation at hand. Are you stepping into a well-oiled machine where your role is to set a product vision? Or have you been hired to perform a rescue operation to turn things around? To effectively navigate this new landscape, it's critical to understand the ground truth, uncover any hidden landmines, and identify where the bodies are buried. We'll outline two essential actions to take when conducting a thorough assessment before diving into your new role.

1) Mock tech due diligence
Approach fact-finding as if you were conducting a tech due diligence for a company sale. Conducting a mock due diligence can help you uncover any potential issues and ensure that you have a clear understanding of the current state of the product or team. The following are a some of the topics you will need to get an understanding of depending on your particular situation.

  1. Architecture: What is the architecture of the SaaS product? Is it scalable, reliable, and secure? What cloud services and infrastructure does it rely on?
  2. Code quality: What is the quality of the codebase? Is it modular, maintainable, and well-documented? Are there any technical debts or legacy code that may pose risks?
  3. Technical team: Who are the key members of the technical team? What are their backgrounds, skills, and experience? How do they collaborate and communicate?
  4. Development process: What is the development process of the SaaS product? Is it agile, lean, or waterfall? What tools and methodologies does the team use for version control, testing, deployment, and monitoring?
  5. Product roadmap: What is the product roadmap of the SaaS product? What are the upcoming features and enhancements? How do they align with the market and customer needs?
  6. Security and compliance: What are the security and compliance measures of the SaaS product? Does it adhere to industry standards and regulations, such as SOC 2, HIPAA, or GDPR? What are the disaster recovery and business continuity plans?
  7. User experience: What is the user experience of the SaaS product? Is it intuitive, user-friendly, and accessible? How does it compare to the competitors in terms of usability and user engagement?
  8. Integration and APIs: What are the integration and API capabilities of the SaaS product? Does it support common protocols and standards, such as RESTful APIs or OAuth2? How does it integrate with other systems and platforms?
  9. Data management: What is the data management of the SaaS product? How does it handle data storage, backup, retention, and deletion? What are the data privacy and security policies?
  10. Financials: What are the financials of the SaaS product? What is the revenue, profitability, and growth rate? What are the pricing models and plans? How does it compare to the competitors in terms of pricing and value proposition?

2) Trace the journey of a bug fix or minor change
See if there are any new bugs reported that are trivial to fix. If there aren't any, then ask the team to make a small update, such as changing the color of a button when clicked, adding contextual text, or producing a report based on existing data. By tracing the path of these small updates, you can gain a deeper understanding of the development process, identify potential bottlenecks or inefficiencies, and assess the effectiveness of the team's communication and collaboration.

  • How many meetings, teams, project managers, developers, and stakeholders are required to make a trivial change? How are decisions made?
  • How many tools are used to track this change request?
  • Are there any bottlenecks that would prevent this change from entering the queue of work?
  • Does a trivial change cause a cascading impact on previously scheduled work or can it be fit in to the current task list?
  • Does the team recoil and argue that the changes are not trivial? What is it about these changes that make them difficult? Is there legacy code or too many dependencies?
  • How fast can you roll out a change to production?
  • What does a feature roll out to production look like? Are there any safe guards missing?

Identify the key players

Once you've completed your fact-finding mission, it's crucial to aggregate all your notes and analyze them to identify key players within the organization. Look for individuals whose names keep popping up as essential contributors or dependencies for various projects. Are they a single point of failure, or are they effectively supporting the team? You may also identify connectors, individuals who may not have official titles but serve as the glue between different teams. Are there any underutilized individuals or those who act as bottlenecks? Who possesses the most institutional knowledge, and where is accountability lacking? Are there initiatives or functions without clear ownership or committees that answer every question of responsibility?

A valuable exercise to perform within your organization is to create an Excel sheet listing every initiative, function, and tool used and identify whom to contact for help and how to obtain it. This process can be challenging, but it can be incredibly enlightening and reveal any gaps within the organization. 


Is there someone whose name appears most on your list after conducting this survey? Are they performing too many responsibilities?

Going forward

Armed with the essential context and key information about what you have gotten yourself into, it is time to plan for your long term success.

Building Relationships
Building relationships with key stakeholders, such as team members, other executives, and customers, is critical for success in any leadership role. In the first 30 days, focus on establishing rapport and building trust with your team and other stakeholders. Be approachable, show genuine interest, and listen actively to what others have to say. Remember that building trust takes time, so be patient and consistent in your interactions.

Defining Priorities
With a better understanding of the situation and relationships in place, it's time to define your priorities for the next 30, 60, and 90 days. Setting priorities early on is critical to avoid getting overwhelmed and losing focus. Consider focusing on high-impact areas, addressing urgent issues, and balancing short-term and long-term goals. Be sure to communicate your priorities clearly to the team and other stakeholders to ensure alignment and buy-in.

Developing a Plan
Once you've defined your priorities, it's time to develop a plan that aligns with them. A good plan should be comprehensive, yet flexible enough to accommodate feedback and changing circumstances. Consider involving the team in the planning process to ensure ownership and commitment. Set clear goals and define metrics for success to keep everyone focused and accountable. Be prepared to revisit and adjust the plan as needed based on feedback and new information.

Communicating Effectively
Effective communication is essential for any leader, especially in the first 30 days. Be transparent and authentic in your communication, avoid jargon and buzzwords, and use multiple channels to reach different audiences. Listen actively to feedback and respond promptly and appropriately to build trust and credibility. Remember that communication is a two-way street, so be sure to solicit feedback and input from others.

Conclusion

It's always a bit daunting stepping in as a leader of a group that has been working together for a long time and likely know way more than you do about their product. But hopefully this provides some ideas for how you can get started without spinning your wheels. Good luck!

picture of the author
Zack Schwartz @apexdodge

ENTREPRENEUR & SOFTWARE ENGINEER, AUSTIN, TX
I enjoy tackling a wide array of business challenges ranging from front line product support and operations to sales and marketing efforts. My core expertise is in software development building enterprise level web applications.


Subscribe to the Raytha newsletter