Giving and Receiving Feedback Questions

Situation: As a Solutions Architect I led a cross-functional team designing a multi-tenant cloud solution for a strategic customer. A highly respected engineer repeatedly challenged my architecture in public channels (Slack/design review meetings), arguing for alternatives that conflicted with client constraints and caused confusion among stakeholders.

Task: I needed to preserve technical excellence, keep the engineer engaged, restore alignment with the customer requirements, and prevent morale loss from public friction.

Action (private):

• I scheduled a one-on-one within 24 hours to acknowledge their expertise and ask open questions: “What concerns do you have? Which constraints do you prioritize?”
• Listened to understand technical motivations, surface knowledge gaps, and any incentives (e.g., preference for a tech they maintain).
• Shared the business and client constraints I was balancing (cost, timeline, compliance).
• Co-created options: invited them to prototype or build a short trade-off analysis comparing their approach to the proposed design, with measurable criteria (latency, cost, deployment effort).
• Agreed on communication norms for public forums and when to escalate disagreements.

Action (public):

• Restated the agreed communication norms and the decision criteria at the next design review.
• Framed debates around objective metrics and client impact rather than personal preference.
• Invited the engineer to present their trade-off analysis to the team; facilitated Q&A and asked the team to vote on criteria weightings.
• If the alternate had merit, I integrated aspects via architecture revision; if not, I explained the decision transparently and documented the rationale.

Result:

• The engineer felt heard and contributed constructively; confusion among stakeholders dropped, and decision turnaround time improved.
• We shipped a solution that met client constraints while incorporating two optimizations from their proposal.
• Team morale increased because debates moved from adversarial to evidence-based.

Learning: Respect and curiosity in private, objective criteria and transparency in public, and creating pathways for technical ownership turn resistance into constructive influence.

Situation: As a Solutions Architect, I worked with a senior engineer on a large client proposal. They consistently pushed back on architecture changes proposed to meet a new compliance requirement, which risked delays and a poorer client fit.

Task: I needed to give constructive feedback so they’d engage with alternatives, preserve team trust, and allow us to iterate quickly.

Action (framework + language):

1. Ask first, build safety:

• “I want to understand your perspective — can you walk me through your main concerns about this change?”

2. State observed behavior, impact, and intent (non‑judgmental):

• “I’ve noticed you often reject design changes early in the process. That’s making it hard for us to explore options and is delaying the proposal by two days, which could affect our delivery timeline and client confidence.”

3. Invite collaboration and past values:

• “You’ve led robust, maintainable designs before — how can we preserve those strengths while testing this compliance approach?”

4. Offer options and propose experiments:

• “Can we run two short experiments: A) prototype the compliance module as a feature-flagged service; B) document a smaller change with rollback plan. Let’s timebox each to 3 days and compare metrics: dev effort, risk, client acceptance.”

5. Agree on follow-up and signals:

• “If the prototype meets our risk criteria, we adopt it. If not, we revisit. I’ll schedule a 30‑minute check after 3 days.”

Result:

• This approach kept psychological safety, shifted focus to measurable impact, and turned resistance into evidence-based decisions. The team adopted the feature-flag prototype after the experiment showed lower integration risk and faster delivery.

Key techniques:

• Lead with questions, describe impact (not intent), link to business outcomes, timebox experiments, and commit to concrete follow-ups and acceptance criteria.

I prefer a mixed, context-driven approach: use async channels for information sharing and low-latency review, and synchronous sessions for alignment, trade-offs, and high-risk decisions.

Channels & methods

• Asynchronous: design docs (Confluence/Google Docs) for proposals and rationale, PR comments for code-level review, recorded walkthroughs, and Slack/Teams threads for clarifications. Use templates (problem, constraints, options, recommendation, impacts) so reviewers can give focused feedback.
• Synchronous: live design reviews, architecture workshops, whiteboard sessions, and stakeholder demos when decisions require back-and-forth, conflict resolution, or client-facing sign-off.

When to use each

• Async: early drafts, routine changes, wide-distribution reviews, or when participants are distributed/time-zoneed.
• Sync: finalizing major architecture decisions, onboarding unfamiliar stakeholders, resolving conflicting trade-offs, or during pre-sales technical deep dives with clients.

Frequency

• Design doc reviews: request 3–5 business days for async review; follow-up live review only if >3 unresolved concerns.
• PR reviews: within 24–48 hours SLA for critical paths, 72 hours for lower priority.
• Recurring check-ins: weekly architecture sync with engineering and fortnightly cross-functional product/solutions review.

Making feedback actionable & closing the loop

• Require clear, scoped action items on docs or PRs (what, owner, due date).
• Use tracked artifacts: JIRA tickets or action table in the doc; link tickets to PRs and client notes.
• During syncs, capture decisions and next steps in meeting notes and assign owners immediately.
• Verify closure by requiring owners to attach implementation/PR and mark ticket Done; I periodically audit outstanding items in weekly syncs.

Tone & culture

• Encourage evidence-based, respectful feedback: cite alternatives, risks, and data. Model concise, decision-focused comments and escalate only when trade-offs are unresolved.

This approach balances inclusivity and speed, ensures decisions are documented, and drives measurable closure.

Situation: As a Solutions Architect reviewing a backend service PR for a client integration, I often need to suggest performance improvements without discouraging engineers.

Technique description: The "feedback sandwich" frames constructive criticism between positive acknowledgement and encouraging closure. Start with a genuine positive (what’s working), give the specific suggestion (what to change and why, ideally with an example or alternative), then close with encouragement that reinforces trust and motivation.

Example comment:

• Positive: "Nice work — the module is well-structured, tests cover edge cases, and I like how you separated the data access layer from business logic."
• Suggestion: "One performance area: the current implementation reads the full dataset into memory before filtering, which could cause high memory usage for large client payloads. Consider streaming the results or applying the filter at the DB/query level (e.g., add WHERE clauses or use a cursor/iterator). For example, change fetchAll() to fetchStream() and apply filter() in the stream processor, or push the predicate into the SQL so only matching rows are returned."
• Closing encouragement: "This change should be a small refactor and will make the integration much more robust. Happy to pair on this if you want — great direction overall."

Situation: While supporting a major prospective Lyft integration, the account executive committed to a three-week delivery of a full production-ready connector and end-to-end SLA that the engineering team said would take 10–12 weeks given required security reviews and data schema work.

Task: As the solutions architect, I needed to correct expectations so leadership and the client wouldn’t be misled, preserve trust with the AE, and keep the opportunity moving forward.

Action:

• I scheduled a private, facts-first conversation with the AE. I started by affirming their sales progress and why the deadline mattered to the client.
• I presented a concise breakdown: required tasks (security review, schema mapping, load testing, monitoring), each with estimated effort and risk (visual timeline and dependencies).
• I proposed two realistic options: (A) a 3-week pilot delivering a scoped read-only connector limited to non-PII datasets, or (B) the full production pipeline in 10–12 weeks with milestones every two weeks.
• I negotiated a hybrid: ship the pilot in 3 weeks to satisfy the client timeline, while formally committing engineering to the staged roadmap toward production.
• I documented the agreed scope, milestones, and acceptance criteria and copied engineering, product, and the AE into the plan.

Result:

• The AE presented the pilot option to the client; they accepted it, preserving the deal and credibility. Engineering delivered the pilot on schedule; we completed production in 11 weeks. Client satisfaction stayed high and deal closure probability rose from ~60% to 90%.

Follow-ups to ensure alignment:

• Weekly 30-minute checkpoint meetings with AE, engineering lead, and me to track milestones and blockers.
• Shared Confluence page with timeline, owner responsibilities, and acceptance criteria.
• A post-pilot retro with client and internal teams to surface issues and confirm remaining scope before production.

What I learned: Framing feedback around options and trade-offs, validating constraints with engineering data, and immediately offering a viable alternative preserves relationships and converts unrealistic asks into executable plans.