Tech Audit
What is the goal of a tech audit?
When we begin working with a new team or a new application and platform, we need to understand what we're dealing with.
A few key components include:
- the current state of things
- a deep dive into how the team develops and delivers software
- and identifying the starting points for our work.
The goal of the tech audit is to build and establish a shared understanding of the platform we are working on.
Where do you start?
Start somewhere simple and easy. I approach this section with the mindset of a stakeholder who only needs high-level details.
Here's a list of questions I use in the beginning:
Are you going to work on an existing application or start from scratch?
If it's a new application, it's important to get a general idea of the planned volume of users or traffic.
If it's an existing application, find out what stage it's at.
Is the platform operational in production? If yes, we delve deeper and understand the scale of the platform: how much traffic it handles. If the business is in a transition or modernization period, it's crucial to determine what percentage of customers it's enabled for.
If the platform isn't operational in production, ask why? Is it because delivery is planned for later? Try to determine if there's a risk of delay.
Team, Tech Stack and Skills
Once you have a basic understanding of the application, it's important to know who is working on it.
When starting from scratch, team details are less relevant initially. However, when you're integrating into an existing organization or taking over an existing application, it's crucial to understand the tech stack and the current team’s skills.
Think like an engineering leader within the team.
Here are some questions to guide you:
- Do you have an org chart?
- How many people are in the engineering organization?
- How many teams are working on this?
- How many developers are on each team?
These questions give you a general idea, whether it’s one team, five, or fifteen.
For each team, know how many people are there and what their roles and skills are: product manager, frontend and backend engineers, QA, DevOps/ops, designers.
Approach
Now that you have a general understanding of the application and the team, let’s dive into the details.
Imagine you're a developer working on this project.
Use these questions in your checklist to help guide you:
- Tech Stack
- What technologies are you using?
- Provide a high-level description of the technology stack. For example, this might include Node, .NET, PHP, Go, Ruby on Rails for backend technologies, and MySQL/PostgreSQL, Elastic for databases. For frontend technologies, examples might be React, Next.js.
- Architecture
- Is there an architecture diagram available?
- If you could describe the platform’s architecture in a few words, what would they be?
- Code Hosting
- Which platform hosts the code? GitLab, GitHub, or another service?
- Is it cloud-based or hosted?
- Repositories Structure
- Are you using multiple repositories or a single monorepo for the application?
- What are the key repositories for the app?
- Git Branching Strategy
- What is the team's approach to Git branching? Are you using feature branches or trunk-based development?
- In the context of Git branching, what are the code review practices?
- CI Pipeline
- Assess the maturity of the CI pipeline to understand the level of automation for the app.
- Key areas to consider:
- Security checks
- Linting
- Types of tests used (unit, acceptance, or end-to-end tests) without focusing solely on metrics like test coverage.
- Deployment Targets
- What is the outcome of a CI job? Is it a Docker image, an archive, or something else?
- Where is this artifact stored? For example, is it on a hosted platform or a cloud solution?
- Deployment Strategy
- Which branch gets deployed and where?
- Describe how deployments to production are handled.
- What are the pre-deployment checks?
- How frequently are deployments to production made? Options might include multiple times a day, daily, weekly, or monthly.
- Operations Platform
- Now that we have an artifact ready for deployment, where do we deploy it?
- Consider the hosting provider and products used, such as on-premises solutions, public clouds, or platform-as-a-service providers.
- Operations Process
- After deploying your code to production, it’s crucial to ensure it's operating correctly.
- What are the existing observability practices, including log aggregation, monitoring, and alerting?
- Is there a standard incident response process? What does it look like?
Process
Think like a developer on the team who needs to make a change.
- SDLC (Software Development Life Cycle)
- Is there an established SDLC?
- Is code review part of the process?
- When are test cases defined?
- Are there regular system design or architecture reviews by senior engineers or architects?
- Defining Work That Needs to Be Done
- Who provides the requirements, and in what form?
- Is there a backlog of items that need to be addressed?
- How is the work estimated?
- Team Ceremonies
- Are there regular backlog grooming sessions?
- How often do you demo your work?
- Who from across the organization participates in these sessions? This helps to understand the level of collaboration beyond just the engineering team.
Direction
This section is about understanding the next steps and how you will approach them. There are two main aspects that are important to me:
- Product Strategy
- Is there a clear Product Vision for what you're working on?
- Do you have a product roadmap that outlines how you will achieve this vision?
- How frequently does this roadmap change? How often are priorities shuffled?
- Engineering Strategy
- Is there a forward-looking vision for the platform?
- Does this align with the Product Strategy?
- How is the Engineering Strategy aligned with the Product Roadmap?
Drawing Conclusions
The goal of this entire exercise is to:
- Build a mental model of how the company operates and what is considered "normal" or standard.
- Understand where the company aims to go. This helps inform the direction and focus of development efforts.
- Identify the most efficient points for intervention within the system.
For instance, this might involve replacing an application, changing development practices, or identifying gaps that could significantly enhance the developer experience.
