When joining a team, I want to see a release. A small one is enough: a customer asks for something, the team changes the software, and the change reaches production. Following that chain tells me where to look next.
I’d also want to know what the founder expects to be different in three months. Those two conversations give the technical review a purpose. Here is what I’d look at during the first month.
What needs to ship?
“We need to move faster” leaves too much open. Is there a contract waiting on a feature? Are customers leaving because something is unreliable? Is the team spending its week on support? Each problem calls for different work.
I’d ask the founder, the product lead and the developers separately. If they name different priorities, we need to resolve that before adding more work to the backlog. A short list of agreed priorities is enough to start.
Follow a change all the way through
Pick a recent ticket and sit with the people who worked on it. Look at the original request, the pull request, the tests and the release. Ask where the work waited and why.
Perhaps a one-day change spent a week waiting for a decision. Perhaps every release depends on one developer’s laptop. These details help explain a delivery problem much better than a high-level architecture diagram.
Check what could stop the business
I’d check access to production, the release process and the ability to restore data early. An untested backup worries me more than a framework the team would prefer to replace.
For other issues, I’d ask for a failure scenario: what breaks, who notices, and how do we recover? “The code is old” needs more explanation. “Only one person can deploy, and they leave next month” gives us something to act on.
Finish one improvement with the team
I’d choose one recurring problem the team can fix during the month. Automating a manual release step, removing a slow approval or fixing a noisy alert can all be useful. The team should help choose it.
Working on that change together also gives me a better sense of the codebase. I can review the implementation and understand the constraints before recommending a larger piece of work.
Write down the next decisions
After a month, I’d want a short document we can use in a planning meeting: the priorities, the risks, the next decisions and who owns them. Any recommendation to rewrite or hire should explain the problem it will solve and what it will cost.
I’d include the questions we still cannot answer. Some systems take longer to understand. The document should help us decide what to do next week, rather than pretend the review is complete.