Being a Software Engineer IV or Salesforce Platform Manager at IH
Job Descriptions: Software Engineer IV · Salesforce Platform Manager
You are a technical leader and force multiplier — still a hands-on practitioner at heart, but with influence that extends well beyond your own work. Your responsibilities span three broad areas: technical leadership and decision-making, delivery and quality, and people, influence, and team health. As a practitioner, you’ll spend the majority of your time building and shipping solutions alongside your team, whether through code or platform configuration. A meaningful portion of your energy goes into the people and practices around you.
Much like an Engineering Manager, impact at this level is often indirect and non-obvious: quality decisions, mentorship, risk reduction, and the connective work that keeps teams running well. Success at this level isn’t measured by ticket output. It shows up in the quality of your team’s decisions, the engineers who grow around you, and the systems that hold up in production.
Our systems touch residents in hundreds of thousands of homes: the app they use to pay rent, the portal for maintenance requests, the tools associates depend on every day. Technical decisions at this level have real stakes. When we get it right, people feel it.
(“Residents” are the people who live in our homes; “associates” are our employees.)
Tanya Reilly, author of The Staff Engineer’s Path, coined the term “glue work” to describe exactly this kind of connective leadership — the mentorship, documentation, and coordination that holds a project together:
“Glue work is the difference between a project that succeeds and one that fails.” — Tanya Reilly
No two people in this role will look the same. The exact mix shifts depending on your pod’s maturity (your cross-functional team), product clarity, and the complexity of the systems you own. It evolves as your team and your own leadership develop. What stays constant: the expectation that you’ll make sound decisions with incomplete information and help the team move forward even when the path isn’t clear.
Technical Leadership
Strategy and Technical Direction
You are accountable for the how of delivery. You own or co-own the most consequential technical decisions on your team, bringing context, judgment, and a clear point of view. That means thinking beyond immediate delivery: considering system-level impacts, failure modes and edge cases, long-term maintainability, and whether work is truly ready to build before it enters a sprint. If something isn’t ready, say so. Influence requirements upstream.
When facing a significant technical choice, come with options. Suggest and compare viable approaches, make trade-offs explicit, and document decisions as Decision Records, either in the relevant repository (for decisions scoped to that codebase) or in our shared technology decisions repository (for decisions with org-wide impact). The goal is for your Engineering Manager (EM) and teammates to trust your judgment and actively seek your input.
At this level, work increasingly involves unknowns: incomplete requirements, evolving scope, or problems without clear precedent. You’ll have significant autonomy. The expectation is that you use it well and own the results. Take responsibility for outcomes, not just the tasks assigned to you, and use those moments to create clarity for the team.
Pod and Cross-Team Influence
Within your pod, you are a technical anchor. Lead or coordinate solution design and architecture discussions, and partner closely with your EM. One mark of a strong technical leader is enabling other engineers to present solutions and own decisions, not being the sole technical voice in every room. Create space for junior engineers to stretch and own decisions, not just execute them.
Across teams, show up in solution architecture discussions, Special Interest Groups (SIGs), and cross-team reviews. Understand how your pod’s changes ripple outward, and serve as a representative of your pod’s technical reality when it matters. When ownership across systems or repos is unclear, help define it. Ambiguous ownership is a technical risk: step in to resolve it rather than letting it drift.
Delivery, Quality, and Execution
Execution and Delivery
You help ensure work is delivered predictably and correctly. That includes refining stories and acceptance criteria, participating in estimation and scope discussions, surfacing risks early and helping course-correct when needed, and unblocking delivery issues: failed deploys, unclear ownership, or coordination gaps. The goal is to be the practitioner who makes the whole sprint go more smoothly, not just the one who closes the hardest tickets. Maintain momentum and a bias toward shipping working software over debating it. AI tools — coding assistants, admin copilots, and the rest — are part of the modern toolkit. Use them, and help your team develop good judgment about when and how they add value.
Code and Quality Stewardship
You own the quality bar for the pod. Set expectations for PR quality, test coverage, and maintainability. Hold to them. Ensure issues are addressed before merge, and keep an eye on compounding technical debt: what looks like a small shortcut today often becomes a larger problem later.
Your pod maintains a KLO (Keep the Lights On) backlog — work that keeps the codebase healthy: addressing technical debt, improving developer experience, increasing automated test coverage, and reducing toil. These are our engineering principles in action. If something can be automated or improved, we don’t let it linger. Take an active role in identifying and prioritizing this work. The target is roughly 10% of each sprint’s capacity, and partnering with your EM to protect that time is part of the role.
Production Ownership
Your accountability doesn’t end at merge. Participate in on-call and production support rotations, and support on-call engineers even when you’re not the primary on-call. We take on-call seriously: rotations are designed to be sustainable, and at this level you help set the culture around how that responsibility is shared across the team. Maintain awareness of system health and operational risks, and bring production learnings back into design and planning. Systems improve when what you observe in production informs how you build next time.
People, Influence, and Team Health
Our vision is to delight our residents and associates with innovative solutions built by happy teams. Happy teams don’t happen by accident. They’re built by people who invest in each other. The mentorship, communication, and culture you model at this level are how that part of the vision becomes real.
Mentorship and Engineer Development
Mentorship is a core responsibility at this level, not a side activity. Pair with junior engineers, guide their decision-making rather than just providing answers, and create opportunities for them to take ownership, with safety nets. Provide direct, specific feedback through PRs, pairing sessions, and one-on-one conversations.
You’ll know it’s working when junior engineers grow in confidence and autonomy, the team requires less direct intervention over time, and your impact shows up in others’ success.
You are also a culture carrier: your attitude and energy set the tone for those around you. Show up with the curiosity, positivity, and high standards you want to see in the team.
Communication, Documentation, and Glue Work
Much of your value comes from connective, sometimes invisible work. Translate complex technical concerns into shared understanding: in design discussions, in Jira, in Confluence, and in conversations with your Product Owner. Lead design discussions with clarity and inclusion: be able to explain what the team is building and why.
Encourage and model decision documentation. Help ensure architectural and system knowledge is written down and accessible, not locked in someone’s head. Preventing knowledge silos pays long-term dividends for your pod’s health. Every repository your pod owns should have a great README: one that tells a new team member what the system does, how to get it running, and where to look next.
Working with Your EM and Product Counterparts
At this level, you are a trusted partner to your EM and Product Owner, not just an implementer. Act as a technical sounding board: challenge ideas respectfully, bring data and context to discussions, and help your EM make better-informed decisions. Advocate strongly for your position, and commit fully once a decision is reached. That combination of honest advocacy and full commitment is how teams debate well and still move fast. Model that behavior for the engineers around you. Build strong working relationships with your Product counterparts, and understand the why behind your work: not just enough business context to inform technical decisions, but enough to ask whether you’re solving the right problems.
Your relationship with your EM works best as a partnership: complementary perspectives, shared accountability for outcomes, and mutual trust. Together with Product and Design, you form the extended leadership core of your pod: the people who own not just the work, but how the work gets done.
From here, you’ll have a clear path to Staff Engineer on the individual contributor (IC) track, or to Engineering Manager if you’re drawn toward people leadership. Formal people management and org-wide technical strategy are out of scope at this level; those are the territory of the EM and Staff Engineer tracks respectively.