0

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

Profile picture
Mid-Level Software Engineer at Taro Community5 months ago

I'm starting an API migration project due to a licensing issue and am the primary point of contact for stakeholders.

I earned this responsibility by building a relationship with the downstream legacy team and leveraging their solution with ours, using our framework in a novel way. My manager quote said “not that you can you should own the xfn”.

This is my first time doing non-technical work. Here’s what I've done so far:

  • Created a step-by-step plan and design document, captured requirements with due dates, and integrated tasks into Agile sprints.
  • Maintain a living document for future technical challenges, and note taking for all steps I outlined.
  • Outlined the battle plan to the po, my manager, and the senior engineer who all gave sign off.
  • Plan to give updates and assist with troubleshooting for client teams.
  • Set a goal to thoroughly test the solution, ensuring an adequate test suite is in place, aiming for it to work on the first try.

Questions:

  • 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.
  • 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.
80
5

Discussion

(5 comments)
  • 4
    Profile picture
    Staff Eng @ Google, Ex-Meta SWE, Ex-Amazon SDM/SDE
    5 months ago

    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.

  • 1
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    5 months ago

    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/

    • 0
      Profile picture
      Mid-Level Software Engineer [OP]
      Taro Community
      5 months ago

      Only rip rn is this project actually is built in such a manner where it’s clearly doing “best code is no code at all” and we do not have any junior engineers. The other engineer that’s in a similar spot in my team is probably at 3 year mark and is definitely more my peer and their workload is in some other area. Everyone else is senior or staff.

      Best case scenario I work with some junior engineer on xfn team. Maybe I can advocate for myself? While helping junior engineers elsewhere in our company?

    • 0
      Profile picture
      Tech Lead @ Robinhood, Meta, Course Hero
      5 months ago

      Yeah, it's not a requirement, just an idea. If there's a junior on an XFN team, do your best to empower them. And of course, always be advocating for yourself as well.

  • 0
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    5 months ago

    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.