These are my notes from a session on what a tech lead needs to do and know when arriving on a new project. The original wisdom came from @JimBarritt at Thoughtworks , and then I’ve added five extra sections at the end (these were added on Fri 11th July ’25, a couple of hours after I linked to this post from LinkedIn etc).

Note that this list applies both to projects that existed before the tech lead arrived, and those where the whole team / product is new.

The first two are apparently “the two most likely causes of death or injury”:

1) Infrastructure

• Where’s the production environment? It’s the most important one! What does it look like? When will it be ready? (Development environments are an afterthought after prod)
• How are we going to go live? What’s the plan?
• Load balancers
• Firewalls
• Certificates

2) Third parties

• Integration!
• If environments beyond your control are chaotic, it’s even more important to make sure your own environment is super-organised and disciplined, smooth, automated, with good scope planning, etc

3) Find the movers and shakers

• Find all the people who can say No, and the people who hold the purse-strings/can sign off budgets, and the people who can say “Yeah, you did a good job” and get to know them
• Eg:
  • Architects
  • The person who has control over data protection (Beware “organisational scar tissue”)
  • In the public sector, the SIRO (Senior Information Risk Officer)

4) Find any top-level documentation of your team’s work, read it and understand it

5) What’s the budget and the value proposition?

• How well defined is it? Why are you doing the work? What’s the vision? Do people understand it?
• Once you find this info, be really repetitive about it
• If there are assumptions which are crucial to the whole success, keep repeating them at the start of every showcase

6) Try to have a one-to-one with each person in the team

• Try to understand what their goals are, particularly on the project – and be transparent about your own goals. For instance if you have areas you want to move away from, find people who are keen to move INTO those areas
• What are their main pain points and blockers?

7) Befriend a project manager and get to understand how they manage budgets

• This helps to establish a relationship of trust
• Get to know “Real Options” from Chris Matts
• Read “Implementing Beyond Budgeting” by Bjarte Bogsnes
• Brett Ansley did a talk at Agile on the Beach in 2016 on money and teams and how to account
• Read 37 Things One Architect Knows About IT Transformation, by Gregor Hohpe
• Don’t try and become an expert on the arcane detail of finance, but understand the basics: how does money move around, what are the different types of work, what’s the difference between OpEx and CapEx

8) If there are multiple teams, find and get to know the other tech leads

9) Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead

• There is often a tension between these three areas
• Build relationships with these people
• All three should be present for all decisions, otherwise it’s likely to be skewed
• Tech leads can sometimes get a bit side-lined in these relationships

10) Backlog: make sure the scope is clearly structured

• Use story trees and backlog hierarchies
• People can struggle with higher levels of grouping / scale
• You need to get into the helicopter, go up and look down on the thing you’re building

11) Code:

• Make sure you have access to it
• Remain connected to it
• Get a couple of the devs to give you a guided tour
  • Can be particularly illuminating to get newer team members to do this
• You need to be able to visualise the entire code base (overall architecture)
• How easy is it to run it from scratch for the first time?

12) What are the pain points and blockers?

• Project manager is good person to talk to about that

13) Cross Functional Requirements

• Resilience & scalability
  • Is it going to fall over with the load
• Security
  • Is someone going to break into it?
• Automation
  • Although automation is awesome, don’t fall for the trap of thinking you have to set everything up at the start
  • Don’t necessarily prioritise automation – but do prioritise what you need to actually deliver something
  • Once you have something up and running and iterating, it’s all good – but how do you break that initial blank sheet of paper?
  • You want pipelines etc, but as a principle, maybe there are different laws of physics right at the start of a project
  • Don’t spend six weeks building a pipeline with no actual deliverable – make sure you have something iterative
  • Imagine this product that you’re building… imagine you’re doing it with no software at all. Then bring the computer into it, and ask why – what is it going to give you? Where can it give you the most value? Don’t add stuff you don’t need
  • Imagine a walking skeleton in business terms – for instance, delivering whisky by physically posting it*. Your deployment walking skeleton can be over the top – only automate something when you need it
  • It’s a subtle art though – you don’t want to end up with tons of tech debt
  • You can spend a bunch of time working out the concept without having the capability.
  • Could have a simultaneous technical alpha – looking at cross-functional requirements etc
  • Try a walking skeleton of the architecture – a “scale model”

14) As a tech lead, what things are scaring you most about this project?

• Do a futurespective graph with time on the x axis and clouds of uncertainty. If the cloud is really close and has a lot of lightning coming out of it… pay attention to it!
• This is partly about risk management

15) Extra tech checks

• Do a performance audit asap – can performance be improved? How?
• Do a resources audit – is money being spent on unnecessary products and services? Can savings be made?
• Look for quick wins / low hanging fruit – eg improving performance, making savings on services.
  • This is the kind of thing that can really benefit from fresh eyes and allows you to make a quick positive impact and therefore cement trust and good relationships, if handled right.
  • Do NOT assign blame in this process. You are there to help, not to make other people look bad – particularly if those people are still working in the same organisation, or are closely connected.

16) Processes

• Be very clear about agile processes, team hygiene, roles and responsibilities.
  • Be explicit.
  • Negotiate.
  • Get buy-in.
  • Encourage people to have input in defining their own roles and responsibilities, and the whole team should have input into team processes.
• Be very clear about deadlines, estimation and forecasting.
  • If the end of a sprint is seen as a deadline, WHY? What is gained by that?
  • Do you want to be rushing and panicking at the end of every sprint?
  • If not, what can be to done to mitigate against that?
• Talk about the trade-offs between estimating and forecasting.
  • An estimate is just a guess to be validated using end-of-sprint data so you can plan the next sprint more effectively.
  • Estimates are not promises, they are just planning tools.

17) Building new relationships

Be explicit about the following:

• Bringing your whole self to work
• “No blame” and psychological safety
• The value of taking time to learn
• There will be tension and conflict.
  • For instance, the roles of Tech Lead and Product Owner sometimes have different priorities.
  • Not only should you be braced for conflict, if there is no conflict then you’re doing something wrong.
  • It’s an important part of the push and pull of product development and it’s nothing to be afraid of.
• You, and the devs on your team, need time to think.
  • That needs to be built in – you need to be wary of the tyranny of deadlines making devs fearful to put that time aside. Go slow to go fast.
• The client/consultant commercial relationship (if it’s there), and the impact it can have.
  • For instance, in a non-consultant scenario, each member of the team will work most effectively if they can bring their whole self to work and assume that mistakes and fallibility are ok.
  • But in a commercial relationship there can be a tendency on both sides to think that the consultant should be infallible and there should be consequences if they’re not.
  • The problem with this is that it lowers psychological safety, lowers effectiveness and brings about worse results for both client and consultant. So (if you’re in a consulting scenario) you have to get it out there in the open and talk about it upfront.
• Empathy: Think about things from your stakeholders’ point of view.
  • In conversation about important things, try to avoid being reactive to what the other person is saying, or focusing mainly on your own point of view.
  • Considering what their goals are, do their current actions bring them closer to that goal?
  • When talking to stakeholders, think about what you are trying to achieve then think about what THEY are aiming for, and how you can present your goals in a way that allows them to achieve what they want.

18) Outcomes and stories

• When you have reached your goals, what is the story you will tell?
  • What journey do you want to be proud to have trodden (eg we increased num releases to x per day or increased users by x)?

19) Potential Pitfalls

• Remember to find out what outputs or outcomes you are being measured by.
  • It doesn’t matter how well you think you are doing if you’re being measured by something you either didn’t know about or don’t agree with.

* Whisky idea inspired by JK Werner.

• Agile
• Technical Leadership