Skip to main content

Responsibilities

As a software engineer on a cross-functional team, you are responsible for:

Software development and delivery​

  • Determining how best to prioritize and deliver new features, in collaboration with your PM and the rest of your team.
  • Automated quality checks, including an automated test suite and a CI/CD pipeline.
  • Version control management, including setting up your GitHub repository and all integrations.
  • Software delivery, including production deployments and managing the prod environment, secrets, and any associated DevOps tasks.
  • Clean coding practices, including modularity, good variable naming, clean coding conventions, and readable, maintainable code. You should always code as though someone brand-new is going to have to join the team and work in your code starting tomorrow.

Security​

  • Managing secrets in a safe, secure way, including during production deployments as well as for local development.
  • Setting up any data storage, API connections, or integrations in a way that follows data security best practices. This includes understanding and implementing encryption and access control for sensitive data and PII.
  • Working with the IT department to manage firewalls and access control for your application.
  • Keeping your ecosystem up-to-date with package updates.
  • Be aware and mindful that any openly accessible project tools should not contain information about "internal government affairs" (such as names of our partners, agencies/departments, personally identifiable information about people, internal tools, and the like). This includes not just code but also commit messages, project management trackers, and any other publicly available tool.

Accessibility​

The legal floor: the Department of Justice's 2024 rule under ADA Title II requires state and local government web content to conform to WCAG 2.1 Level AA, with compliance dates phased by entity size (April 2026 or April 2027); federal work under Section 508 references WCAG 2.0 AA. Our working standard is WCAG 2.2 Level AA, which satisfies both. Everything we build should be navigable, viewable, and usable on a smartphone, tablet, or similar mobile device.

  • Automated a11y testing should be used on any project with a frontend that we can change. (If it's a vendor frontend, we should manually test and report issues to the vendor.) Many of our teams use Deque's axe tool or a library based on it in integration or e2e tests.
  • Automated tools catch roughly a third to a half of issues at best (the UK Government Digital Service measured ~30-40%; Deque claims ~57% for axe). They cannot detect usability problems (nonsensical headers, alt text that is too long, etc). Therefore:
    • Accessibility issues should also be flagged and fixed in code review
    • Engineers, designers, and PMs should also do a manual accessibility check whenever they are reviewing front-end changes
  • Coordinate and work with outside accessibility testers as needed who are experts in usage of screen readers and similar accessible software tools (talk to your director for contacts).
  • The ADA applies to workplaces, too, not just our public-facing projects. We should keep accessibility in mind as we choose vendors, write documents, present our work, and build internal tools.

We also have the #accessibility-all Slack channel for posting a11y questions and soliciting advice and discussion from our champion panel of a11y-trained staff.

Documentation​

  • Keep useful notes on how to set-up, run, test, and contribute to your codebase, even if you are the only engineer working on it. That may not be the case forever.
  • Tests are the best way to document code.
  • We have an Innovation Repo Template that (along with other shared cross-project config) gives guidelines on starting a README and what should be included in it.

Software quality​

  • Remember that we are creating software not just for the problem at hand, but also as a model of how software can be built in the government. Think of your open-source repo as a model that others could and may be looking at for guidance and as an example of "how to do it right".

Cross-functional technical responsibility​

  • You are a software engineer on a cross-functional team, and you are responsible for representing the voice of technical feasibility to your team.
  • You are responsible for being an active member of a team that follows user-centered design principles. You should always be putting the user first in everything you do; that is not just the responsibility of PMs and designers.
  • You are responsible for taking ownership of product stewardship, and having an opinion on the trajectory of the product. You are not a coding vessel that the PM dictates requirements to. You are a fully-functioning member of a team of equals.
  • You will need to communicate with a variety of stakeholders across various practices, from government agencies to partners to vendors, and more. You are responsible for communicating our needs (whole team or engineering team) and our objectives clearly and succinctly, and without technical jargon. You will need to be able to communicate the what and why of what you're building, not just the how.

Working with external partners​

  • Consider blurring your video background or using a virtual background when on a call with external stakeholders. We have a folder of company-branded virtual backgrounds which you can download.
  • When on a call with external/partner stakeholders, consider dressing business-casual (wear a nice shirt).
  • We have access to several tools and collaboration cloud platforms that external partners cannot and do not use. Again, we want to maximize collaboration and de-emphasize our unique status when working with external partners.
    • Partners do not have/use Google. Do not link them to Google Drive documents; copy the contents into a Microsoft Office365 document instead if you need them to have access. (It's okay to show Google docs and decks when screensharing)
    • Partners do not have/use Zoom. Use Microsoft Teams for calls with external stakeholders.
    • Partners do not have/use Slack. Expect to communicate with them using email or Microsoft Teams.
  • Exercise common sense when interacting and communicating with stakeholders
    • Communication with particularly high-level stakeholders (commissioners, for example) needs to be vetted with leadership.
    • Be aware of the context in how we have communicated with someone in the past and what they may or may not be aware of in working with our organization. It's your responsibility to seek out this context as you engage in communications with stakeholders.
    • Talk to your engineering director or a senior leader if you have a new stakeholder or partner. It's your responsibility to know how we exist as an organization to a new stakeholder or partner.

Last updated: Jul 2, 2026