The Tech Lead’s New Project Checklist

The original list is here. I’m starting to add to it. For now there are just the Building New Relationships and Potential Pitfalls sections below.

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. Tis 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.

Processes

• Be very clear about agile processes, team hygiene, roles and responsibilities. Be explicit. Negotiate. Get buy-in. Enoucrage people to have input in definiing their own roles and responsobilities, 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, and about the fact that 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.

Building new relationships

Be explicit about the following:

• Bringing your whole self to work
• “No blame” and psychological safety
• The value of the workshop
• There will be tension and conflict. For instance, the roles of Tech Lead and Product Owner sometimes have different priorities and 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.
• I, and the devs on my team, need time to think. That needs to be built in - we 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 you have to get it out there in the open and talk about it upfront.
• Empathy: Think about things from the client’s point of view. In conversation about important things, try to avoid being reactive to what the other person is saying and focusing largely 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.

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.

Outcomes and Stories

• When you finish, 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)?