Anatomy of a Prototyping Engagement: AnyCompany & AnyProto
Part 6: The Handoff and Knowledge Transfer
This post is part of a series walking through how I approach a PACE engagement end to end: the considerations, the decisions, and the consequences of getting them right or wrong. Details here are anonymized and composited for illustration; AnyCompany and AnyProto are stand-ins, not a real customer or product.
← Part 5: The Closeout | Series index
Scene
The closeout has been done, and stakeholders are happy and excited about AnyProto. The prototype has reached its final state, and all that's left is making sure it's good to share.
Now What?
Get the code cleared to leave the building. The first order of business is making sure the codebase is actually ready to share. My team has a standard that no code reaches a customer's computer without first being reviewed by a security champion. I run several static code analysis tools, things like Semgrep, Checkov, and npm-audit.
When there are issues or vulnerabilities with high or critical severity, I have to fix them. Once the static scan is done, I get on a call with the security champion I've shared the code with, to talk through any potential architectural issues. I'll likely have to refactor a thing or two, but once that's done and the code is cleared, I'm set to send it over via an S3 signed URL.
Set up the next team for success. The next thing I have to prepare for is the knowledge transfer session, where I onboard the developers who'll be taking AnyProto to the next level. Honestly, there's usually so much documentation available already, and I'm so familiar with AnyProto at this point, that there isn't much left to create.
What I do need to account for is any particular needs from the team taking on the project. Whether that team is from AnyCompany or from within AWS, they usually come in with specific concerns or obligations top of mind, things like security standards, scale, or path to production.
I've found that the earlier the next team becomes aware of and involved with the project, the better the outcome. I try to bring them in as early as the last sprint of the engagement, and at minimum get their attendance at the closeout meeting. If they can't make it, there's no shortage of meeting recordings and documentation to hand them instead.
Scale your impact beyond AnyProto. Throughout this engagement I've primarily been thinking about executing on what AnyCompany needs and their bottom line. A great solutions developer also thinks about how AWS benefits from the engagement, beyond the obvious increase in spend and market capture from AnyProto moving into production. So let's talk about how I make AnyProto more than just AnyProto.
A great way to multiply the impact of a prototype is to disseminate everything I've learned working with AnyCompany out into the world. One good way to do that is through public references with AnyCompany. Public references are outward-facing material that AWS has permission from a customer to use in marketing or blogs. They strengthen the partnership between AWS and AnyCompany, and they help other customers who have similar business problems that AnyProto-style solutions could solve.
Say AnyCompany doesn't want to advertise that they're working on this particular business problem. That's fair, but there's still something I can do. I still have the right to advertise the effort behind AnyProto internally within AWS. AWS is such a large organization that there's a good chance the problem I worked to solve is one someone else has already been thinking about, or working on.
The account team I've been working with for the engagement is a good source of ideas for who to share AnyProto with, and where. In the past, I've worked with global account managers to showcase my solutions to other Amazonians in the same industry. Even if there's no immediate lead for fitting AnyProto into another organization, things like the closeout deck and demos are genuinely useful for showing AWS what works and what doesn't.
Down the line, an account manager will inevitably run into a problem similar to AnyCompany's, and use AnyProto as a reference point for what a solution could look like, accelerating that next team's development process. Knowledge that isn't shared is knowledge that eventually gets lost.
A good line for the account team, or even my manager:
"It was great working on AnyProto with you. I'm glad AnyCompany is getting off on the right foot with this business problem. Do you know of any other Amazonians who might be interested in this kind of solution? I'm really excited about the tech that went into this, and I think others would benefit from what we learned building it."
Managers tend to be well connected, whether it's my manager or an account manager, and someone usually knows an Amazonian who'd be interested in AnyProto. Then I have a lead to chase, which often leads into another adventure entirely.
Collaborating with others to scale AnyProto's impact can be a high-resistance task. Amazonians are a busy group, and the use case I worked on could be obscure enough that the return on investment isn't obvious. But just because there's no clear collaborative path for disseminating what I've learned doesn't mean there's no path at all.
There are smaller scales at which I can extend the impact of building AnyProto. Even just writing a post in a team channel can go a long way toward accelerating someone else's work. Someone else might end up working with AnyCompany later and benefit from hearing about my experience with them. A teammate might be tackling a similar use case for another company and save development time with my help. Someone may have already worked through a similar use case and have notes or feedback on my implementation. None of that benefit reaches anyone if I keep the work to myself, and everyone ends up worse off than they could have been.
Keep your own brag book. The very last thing I want to do before putting this engagement behind me is update my own personal records. It's important to keep a brag book going throughout my career, because while AnyProto has been front of mind for the past month or so, something else will take its place soon enough. The best time to document the story, and why it mattered professionally, is right now.
It's important to document the context of the engagement: the use case, the goal, the objectives, and so on. Especially important is documenting my own role in it specifically: what my tasks and responsibilities were, what I actually did to complete them, and what the results of those actions were (the more quantifiable, the better).
This pays off directly for career mobility, since it leaves me far better equipped to sell my skills and communicate my experience later on. Other things worth documenting: the technologies involved in the engagement, and my key takeaways and learnings.