Date: 2026-03-06
Format: Panel interview, ~30 min
Vibe: Professional, on time. Straightforward conversation.
Tony asked about a product Andrea was part of where there was a lot of complexity.
Andrea's answer: The Ting internal platform — developing new microservices and having to orchestrate/coordinate across them. Created a lot of need for:
- Thorough documentation
- Working closely with teams to understand expected outcomes
- Clarifying through testing what the actual functionality and dependencies looked like across the platform
Also mentioned developing the beta program as a proving ground in production to validate their understanding of how the platform worked.
What landed: Demonstrated comfort with platform-level complexity and microservice coordination — directly relevant to Tony's integration architecture work.
Follow-up from Q1. Asked about a product decision involving a trade-off that changed direction.
Andrea's answer: The beta program results revealed that the earlier trade-off of not rebuilding provisioning was not feasible for go-to-market. Took data from production (from the beta program) and used it to justify building a new provisioning system to ensure they could actually launch.
What landed: Data-driven decision reversal. The beta program wasn't just validation — it was the mechanism that surfaced the need to change course. Shows Andrea doesn't get attached to earlier decisions when evidence says otherwise.
How do you decide what becomes a reusable shared capability vs. a one-off?
Andrea's answer: Used the migration project scoping as the example — evaluating multiple billing systems and many one-offs from legacy systems (especially custom-built ones from previous acquisitions). Highlighted a memorable example: one acquired company had built a process for customers to pay with gift cards. Clear-cut one-off that would never be approved today.
But also noted that the harder calls are around stopgap solutions — things built because the company lacked resources or capability for the proper solution. These tend to be short-to-medium-term fixes that won't exist as workflows long-term. Evaluation criteria:
- Is this a stopgap born from resource constraints?
- Does it have a natural expiration (short/medium term)?
- Would it survive as a workflow in the long term?
If no to the last question, it's a one-off regardless of how embedded it currently is.
What landed: The gift card example got a reaction (funny, concrete). The stopgap framework shows mature platform thinking — not just "is it reusable?" but "why does it exist and will it persist?"
How do you handle communications and working across teams?
Andrea's answer — internal:
- Early stages: flexibility before things get cemented — cadences and responsibilities aren't well-defined yet, so communication needs to be more fluid
- Once established: clearer swim lanes with structured feedback loops across teams
- Migration project example: reported upward to C-level internally and upward to C-level at the vendor. Also communicated laterally with team leaders of responsible teams internally.
Follow-up — external/customer-facing communications:
- Critical to have clear, regular cadence — biweekly syncs with marketing, sales, and customer support
- Purpose: get external feedback loops flowing back into product/engineering, and feed insights back out to GTM teams
- Example: used Zendesk as both CRM and support tool. Support tickets, marketing analytics/reporting all flowed through Andrea as the conduit between external-facing teams and product/engineering, and back outward to GTM.
What landed: Showed she understands communication as a two-way system, not just status reporting. The Zendesk example made the feedback loop concrete — she was the hub connecting external signal to internal decisions and back.
Tony asked specifically about Andrea's operations background after her intro.
Andrea's answer: Two examples:
1. Atsu (Lalamove): End-to-end operations — from picking up the phone and calling drivers to going down to the parking lot to check on cars. Later moved into product operations, working closely with dev teams and setting up smooth end-to-end workflows.
2. Ting: When she first joined, there were no established processes or workflows. Set up the product team workflows from scratch.
What landed: The breadth of operational experience — hands-on ground level to process design. Showed she's not above getting her hands dirty.