First time working on a project with non technical work as well.

Non-technical is not accurate to describe what complex, cross-team coordination. That requires a blend of deep technical skills and a very special kind of communication skill, too (which we call a soft skill, but technical communication is still tech in my eyes.

I would try to have each contributing team provide individual updates, so you can collate that with status against dates for work streams and the overall project. If you can front load anything that is an interdependency, it means that a single-team delay doesn’t cascade. Determining the API contracts and mocking/faking both sides at the outset, having data entities predefined, etc. can avoid blocking between teams.

Communication to clients should likely be different than internal xfn project status. Clients should have a stub endpoint to call from the outset that fakes results, and adds request validation little by little (did you send what’s required can be done right away, making sure a specific item id can be validated once you onboard that dependency, etc.), can let clients start writing the treatment arm of their code so they can easily test what they’ve done so far. They should be able to either use your fake responses, or at least self-generate a usable model since the model will be determined in advance.

I would challenge you to be very aggressive in finding possible pitfalls, failures, long tail items, and so on and do them first. Don’t start a privacy or security review when you’re code complete, start it tomorrow. For launch, look ahead and see if you’re in a Q4 freeze or other holiday chill period that will stop you from launching, and provide alternatives (pre-launch before, fast follow after, or do deep testing during the freeze to prepare for launch, or launch in non-prod, etc). Design your experimentation/ramp-up considering the whole system, so you aren’t trying to coordinate ramps on different systems with different controls. Maybe that’s having the client callers send their treatment with their request (as a “mode” or “behavior”, not just “T1”), then wire it through to your dependency, or have your experiments “or’d” so you can enable a path based on a client call, or a dedicated check in a given service (maybe to allow you to send traffic in parallel and do a comparison offline, etc). Know how you are sure it’s working and how you’ll validate and prove that. Define your metrics up front and create your dashboards early. Be able to show success/failure even with very early mock traffic. Have a rollback story already written, don’t think you’ll just modify a binary or modify an experiment in one spot. Do you need to rollback a schema change, or can you leave it? Do you need to have a rollback journal to undo data writes? Do you need to have a coordinated rollback across systems, or have an “and” kill switch with any experiment check, so once you throw it you’re back to 0. Do you need holdback to have longer term comparisons to the old call path? Do you go from exclusive old, old + new with comparisons but old result used, old + new with new result used, exclusive new? Creating a correct system seems like a win condition, but without a well-orchestrated, confidence-instilling launch it doesn’t matter.

I don’t know, that was a lot of writing. Hopefully some parts are useful.

This is an awesome start! You have a lot of great instincts here, which I recommend building upon.

For cross-functional alignment, what steps should I take for communication and updates? We have a Slack group with all clients. If there’s a communication template that worked well for similar projects, it would be helpful.

A weekly or bi-weekly update seems good. Check this out for a template: "How to get more visibility on work?"

If there was one thing you'd challenge me to do in my execution of this project, what would it be? For context, I’m probably mid-level with an interest in learning how to grow.

Get the project in on time while meeting the following criteria:

1. Nobody hates each other at the end (make sure XFN bonds are healthy)
2. Nobody is burnt out at the end
3. No production fires after shipping the product
4. At least 1 other engineer in the effort who is more junior than you grew during the process (i.e. they took on scope greater than anything they've done before and crushed it)

We're working on a "How To Be An Effective Tech Lead" course right now, but in the meantime, I recommend going through the "Project Credit And Scope" section of the promotion course here: https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/its-not-just-about-impact/

Tailor your communication to the level of context and time that your audience has. A xfn collaborator working closely with you will need more detail. A leadership update should have a tl;dr and focused more on timelines/outcomes.