It’s been a transformational year for the engineering team at Code for America, and I’m honored to have been a part of it. Looking forward to our next year, I wanted to share some reflections on our progress and thoughts on how we plan to continue maturing the organization.
We’ve grown from a team of five full-time engineers to fourteen working across three major services — GetCalFresh, Clear My Record, and ClientComm — and we’ve been busy writing our next chapter, making government services work for people who need them most.
We’ve also grown our impact. GetCalFresh, our longest running service, has now helped over 100,000 low-income Californians get the food assistance they need and is serving over 6,000 new people every week. Clear My Recordand ClientComm celebrated their first birthdays a few months back, and are at an earlier stage, but we’ve learned and grown a great deal there as well. We’ve helped to submit over 4,500 applications for criminal record expungement with Clear My Record, and ClientComm is helping keep people out of jail for “bullshit” (as the team likes to say) by providing better communication tools to probation departments across the country so folks on probation, parole, and pre-trial don’t end up in jail needlessly over technical violations.
As 2017 draws to a close, we’re also gearing up to take on what is possibly our biggest project to date — a re-imagining of social services focused on integrated SNAP & Medicaid benefits in 3–5 states.
Throughout all of this, we’ve maintained an entirely flat reporting structure, and our cross-functional service teams have been largely self-organized.
While I’m a fan of limited hierarchy and self-organized teams, we’ve reached a size and complexity where we’re feeling the need for a bit more structure. Specifically, we think we’d benefit from more clearly defined responsibilities within our service teams to help us work more efficiently, as well as more management bandwidth within engineering to ensure that everyone on the team is getting the development opportunities they need to learn, grow, thrive, and lead.
We also want to enable a lot more collective code ownership at Code for America. We’ve found pair programming to be a really effective way to achieve this within teams, but before now it’s felt like moving folks around teams would be challenging. It would carry a high risk of disrupting our small teams, each of which is focused on an incredibly deep, unique, and challenging domain.
Having people who are focused on being attentive to personnel needs and others who are dedicated to providing continuity in their domain should give us the confidence to rotate people around teams more frequently and create more opportunities for folks to pair in different configurations. We believe that will result in better practices, better code, and a tighter team — and ultimately will help us to deliver better outcomes for the people we serve.
To these ends, we are introducing two new roles at Code for America: Engineering Manager and Engineering Lead.
Both Engineering Managers and Engineering Leads still contribute to their teams with hands-on technical work. The Engineering Manager also dedicates a significant portion of time entirely to helping other engineers develop, while the Engineering Lead dedicates a significant portion of time to making sure their team is building the right thing and building the thing right.
These roles aren’t necessarily mutually exclusive, but we recognize that each role is uniquely challenging and we expect that a single person playing both roles will be the exception rather than the rule. Engineering Leads will generally report to Engineering Managers for career development and support, and Engineering Leads will not have any direct reports themselves.
Engineering Managers typically manage no more than 5 direct reports who span multiple services. By mentoring people across the organization, as well as moving more frequently around service teams themselves for their hands-on technical work, they act as agents for the spread of engineering culture and practices. An Engineering Manager’s responsibilities include:
- Conducting regular 1:1s with all of their direct reports so everyone has sufficient time and attention to work through big issues and professional development plans.
- Gathering and providing candid feedback to their direct reports so they can continually grow and improve, and are never caught off guard by performance issues.
- Helping their direct reports think about their career growth and goal setting so they can be intentional in their development path.
- Ensuring their direct reports have what they need from the organization to be successful so everyone is setup to succeed.
- Providing performance evaluations and input for compensation reviews so their direct reports have periodic opportunities to more deeply reflect on their achievements and areas of development, and to be rewarded for their contributions and growth.
- Surfacing issues to leadership so that problems can be detected and dealt with early before they become bigger issues.
- Advising leadership on project staffing so our teams are staffed with the people they need to be successful.
- Helping with interviewing and hiring to ensure that we improve our team and maintain our core values with each hire we make.
Engineering Leads are experienced technical leaders who are experts in their team’s domain, provide continuity on their project, and are ultimately responsible for their team’s effectiveness at delivering software that creates the impact they are aiming to achieve. An Engineering Lead’s responsibilities include:
- Working hand-in-hand with PM and UX teammates to ensure the entire team understands user needs and opportunities so we are always Building the Right Thing.
- Setting standards and practices for the team that are consistent with our engineering principles so that we are always Building the Thing Right.
- Leading by example, and guiding and inspiring the developers on the team so they are all empowered to do their very best work.
- Making sure the team is focused on the highest priority work and that it has been scoped, tasked, and estimated so that we are delivering the most minimal, effective solution for any given user need.
- Taking ultimate responsibility for ensuring the team is consistently delivering high quality working software so that we are regularly delivering value to our users.
- Making sure the team is regularly conducting retrospectives and blameless postmortems so that they continuously learn and improve together.
- Identifying people, process, and technology needs and opportunities and sharing them with peers on other teams so all of us are learning and improving together.
- Balancing moving rapidly with moving smartly so that the team has a good velocity while keeping technical debt under control.
- Encouraging the team to self-organize so that we take collective responsibility for the work we do. It is not their job to tell people what to do but to enable them to do it themselves.
- Ensuring that no one person on the team is solely capable of accomplishing a task or activity so that we are able to continue working effectively when people are away.
We’ve just gotten started filling these roles, and it’s my great pleasure to announce that Laura Kogler has joined Code for America as our first Engineering Manager. She has already done exceptional work for the past year here as part of a Fellowship team working with the California Department of Justice. Prior to her Fellowship, Laura was an Engineering Manager at Pivotal Labs. She is a tremendous addition to the Code for America team and has already helped to shape our new engineering management practice — I’m looking forward to collaborating with her to continue to grow that practice going forward.
I’m also looking forward to learning from this structure and improving it over time. Like any organizational change, it’s an experiment, and there are hypotheses we’ll need to validate together as a team. For example, we believe:
- If we make the manager and lead roles distinct, then engineers at CfA will feel more empowered to grow in their career and navigate challenging situations.
- If we expect managers to code and be embedded in teams, but don’t expect them to lead teams, then they’ll have the bandwidth to do an outstanding job of mentoring their reports.
- If we formalize leads on service teams, then we’ll deliver more impact as we get more efficient at planning and scaling processes and practices.
- If we formalize leads who deeply understand their domain, then we’ll be able to move other folks around teams more without disrupting forward progress.
- If we move folks around teams more and pair frequently, then we’ll spread useful engineering practices and tools more effectively.
This next iteration of our engineering organization will be an exciting one as we look to continue to scale our impact and our team. Has your engineering team gone through a similar stage of growth? We’d love to hear about your experience in the comments!