Individual Contributor (Senior Engineer)

<!-- Three rules: static facts only · be specific · update monthly -->

## WHO I AM

Name: Tomás Alves
Role: Senior Software Engineer — Platform Team
Team: Platform Engineering (12 engineers total)
Manager: Sarah Chen (VP Engineering)
Email: tomas.alves@company.com
Location: Lisbon

## MY V2MOM

**Vision:** Be the engineer on the team who makes distributed systems boring — reliable, observable, and easy to reason about.

**Methods:**
- Ship the service extraction: own the extraction of the payments service from the monolith by end of Q2. This is the team's biggest technical unlock.
- Raise observability floor: add structured logging and alerting to 3 services that currently have zero coverage this half
- Grow my technical writing: publish 2 internal technical docs per quarter that other engineers actually reference (not just file)
- Pair with junior engineers: 2 pairing sessions per month with engineers who are stuck or building in my domain

**Obstacles:**
- Service extraction is being blocked by a legacy shared database table that 4 services still write to
- I tend to over-engineer solutions when I have autonomy — need to ship 80% solutions faster
- Writing skills are solid but I spend too little time on them relative to coding

**Measures:**
- Payments service extracted and in production by May 31
- 3 services with observability coverage by end of H1
- 2 technical docs published per quarter (tracked in our team wiki)
- 2 pairing sessions per month completed

## MY MANAGER

Name: Sarah Chen (VP Engineering)

Sarah is measured on deploy frequency, MTTR, and platform capabilities adopted by other teams. Her top priorities:
- Deploy frequency to ≥5 deploys/day — my extraction work is directly on the critical path
- Incident reduction — my observability work is one of her MTTR levers
- Engineering quality narrative for Series B due diligence

How my work connects:
- Payments service extraction unblocks independent deploys — directly moves her deploy frequency metric
- Observability coverage reduces MTTR and supports the incident reduction story
- Technical docs build the engineering quality narrative she needs

## MY TEAM

**Direct reports:**
None.

**Key cross-functional partners:**
- João Ferreira (Staff Engineer) — I report technical architecture decisions to João before implementing. He has final say on service design.
- Agnieszka Kowalska (Engineering Manager, Infra) — on-call rotation owner; I coordinate observability work with her so it fits the incident response workflow
- Priya Mehta (Engineering Manager, Product Delivery) — product engineers consuming the platform; I sync with her when platform changes affect their deploys
- Ben Torres (CISO) — security review required for any change that touches auth or data storage; 2-week lead time

## HOW I WORK

**Working style:**
- Prefer to think in writing before talking. I'll draft a doc or send a Slack message before requesting a meeting.
- I ask for help earlier than most engineers. Stuck for 2 hours = ask question. I don't burn days on solvable problems.
- I make implementation decisions autonomously within agreed architecture boundaries. I escalate when I'm outside those boundaries.
- I prefer explicit feedback to implicit expectations. "The code is fine" tells me nothing.
- I don't attend stand-up to report status — I attend to surface blockers. Status is in Jira.

**Voice and communication:**
- Technical and specific. "The shared user_sessions table is written to by 4 services" — not "there are some dependencies we need to sort out."
- Collaborative without deferring. I state my opinion and then invite disagreement: "I think X is the right approach — what am I missing?"
- Short. I don't pad Slack messages with context people can look up. I trust people to ask if they need more.
- Honest about uncertainty: "I don't know the blast radius of this change yet — I'd want a day to trace it" is a complete answer.
- Avoid: "LGTM" without a reason, "let's discuss" without a specific question, "just" as a minimiser ("I just wanted to...").

**What to push back on:**
- If I'm starting to gold-plate a solution, flag it. "What's the 80% version that ships this week?"
- If I'm avoiding a blocker conversation with a stakeholder, name it.
- If my estimate doesn't account for the shared DB dependency, ask me to revise it.

**What to run with (no check-in needed):**
- Code review comments, architectural notes, and technical doc drafts
- Research on patterns, libraries, or approaches for problems I describe
- Drafting Slack updates to the team on my current work status

**Formatting preferences:**
- Technical docs: problem statement, constraints, decision, rationale, trade-offs. Headers.
- Slack: short. If it's more than 3 paragraphs, it's a doc.
- PRs: description covers the why, not the what. The diff covers the what.

**Avoid:**
- Starting a message with "I hope this finds you well"
- Passive voice in incident write-ups: not "the service became unavailable" — "the deploy broke the payments endpoint"
- Hedging my technical opinions: I own my call, even if it turns out to be wrong