Innovation and Impact: U.S. Digital Service through the Lens of Women Technologists | Kate Green, Software Engineer Leader 

In this monthly blog series, Innovation and Impact: U.S. Digital Service through the Lens of Women Technologists, we spotlight some phenomenal women technologists at the forefront of transforming the U.S. Digital Services (USDS) – the government’s digital agency for technology and innovation. They share their expertise, leadership insight, and impact on shaping the nation’s digital landscape, representing diverse software engineers, data scientists, product managers, and UX designers who drive innovation within the U.S. government.

Each blog delves into their unique journeys, career paths, challenges faced, and pivotal projects they’ve undertaken, sharing insights into the dynamic intersection of technology and public service. 

Kate Green is a software engineer generalist who loves to work on big problems. She absolutely loves working at the system level to see how technology can help meet a need, but she also asks if technology needs to be in the solution. She has worked on four projects at U.S. Digital Services, serving as team lead on two. While at USDS, she’s gotten to work as a full-stack engineer,  technical and testing architect, and team lead. She’s had the privilege to work alongside colleagues at various agencies. She has served the public, such as refugees and disaster survivors, during her time at USDS.  

Can you tell us more about your career journey and non-traditional career path? From a full-stack engineer to a team lead, can you share with us the journey that led you to these diverse roles and your passion for system-level problem-solving?

Right before Y2K, I got lucky to find myself in tech as a secretary while in college and never left. They realized I learned new skills fast, and I was assigned to create my first database-driven application even though I was initially hired to work on admin activities. I learned about usability and user experience with these first applications—I was a user of my applications, and I solicited feedback from my colleagues. So many times, I’d use my app and realized I hadn’t thoroughly thought through the processes’ workflow and would go back and refactor. This lesson has supported me on every project since.

I built on that “can-do” reputation with the sponsorship of my first boss, and ended up spending the first eight years of my career doing all sorts of technology-focused tasks that were needed within the Naval Research Lab. I worked as a web designer and graphic designer, I created and maintained databases, and I secured servers. I learned how to code data from survey responses and did a Six Sigma Green Belt project.

Being a generalist comes naturally to me. As a high school and college student, I performed on many musical instruments and I love to make connections between related skills. Creating graphics and a usable application have overlapping skills, as do normalizing and coding a database. Finding and making connections helps me learn faster and evaluate and understand quickly. I can see the whole picture and all the small details, like the gaps to identify where to focus my efforts quickly.

Your role requires proficiency in a wide range of technical skills. How do you prioritize and balance these skills, especially when leading projects at USDS?

This is a good question! At USDS, we are often asked to use our technical skills in non-technical spaces. Problems in a system can often actually be people problems and not technical problems. Technical skills are important when the people problems are within a technical project. My technical skills may less important than my people, planning, and strategy skills, but without my technical skills—I couldn’t be successful.

My degree in education is more helpful than you might think! I’m often advising, developing strategy, and leading teams with and without authority. Thus, I am using influence, teaching, and building relationships to get the technical work started, unstuck, or over the finish line. And balance for me means I’m not focusing on how to write code, but instead, I’m relying on my leadership skills and educator background.

I haven’t written a lot of code in the roles I’ve had at USDS, but that isn’t always the case for every engineer. If my next job needs me to write a lot of code, it will be hard. But if they’re looking for a leader who can jump in, look deeply at hard problems, and find ways to help— I’m your engineer.

With the growing emphasis on UX/UI, how do you ensure designs are not only user-friendly but also functional and align with the core objectives of a project?

I ask a lot of questions! Even with UI/UX, you need to ask yourself in this order, “is this solution going to meet the needs of our users and the business?” I say “in this order” because many people think of the business first. As a previous front-end engineer who collaborated with designers—we are your user-focused people. Leveraging the natural tensions from negotiating engineering, design, and business constraints will reap rewards if you’ve built good relationships, collaboration, and communication channels.

Equity in tech decision-making is paramount. How do you ensure that your engineering decisions prioritize all users, and what advice would you give engineers to consider equity in their work? How do you believe equity relates to accessibility and decision-making in technical projects? What best practices would you share with other engineers?

This can be hard. Many places feel strapped for time, people, and cost and end up cutting work that benefits all users on the idea that they can go back and do it later. But I can’t tell you how many places I’ve logged “tech debt” and accessibility tasks only to have the business move on to the next feature without returning. It feels awful to many of us, especially when we can see the ways we could make it better.

In September, the White House released Digital Experience (DX) guidance, which includes mobile-first design and developer practices. This guidance can help teams prioritize reaching all users. 

Here are some engineering-focused ideas:

• Do all your development using mobile-size viewports. Ask: Do things fit on your screen? How does it look on the tiniest devices? Reaching all users means reaching those whose primary Internet access is those who only have phones, perhaps not a new or fast one.
• Enlarge your text on that mobile viewport. This helps you understand what your grandparents or someone with low vision may experience.
• Make sure to use those `aria` labels, and if your design system has accessible boilerplate code, make sure to include all the `html` elements. Also, try to keep your HTML as simple and hierarchical as possible since screen readers use HTML structure to decide how to navigate the page. For instance, using `h1`s and `h2`s and other headers to denote hierarchy on the page makes it easier to understand the page without seeing it.
• There are plenty of accessibility tools that you can install in your editor (Axe Linter for VSCode)  dev tools (Axe Dev Tools), that you can put in your CI/CD pipeline (pa11y)
• Advocate for the importance of design, UX, and research and elevate design-centric voices within your organization. In many places I’ve worked, designers aren’t heard as much as they should be.
• Remember that not all users are like you. It’s easy to fall into the trap of thinking you know your users and know how your application is experienced. It’s important to stay humble and admit many of your users aren’t like you.

Mobile-first design has become increasingly crucial as more users access websites through their mobile devices. Can you share a specific instance where this principle significantly impacted a project you were working on at USDS?

Yes! My first project here at USDS was a mobile-first-designed proof-of-concept. Our team provided a demo to stakeholders on their own devices that showed the power of the idea. As the primary front-end developer on this work, it also made my own dev work much simpler: I solved for desktop and tablet size by creating a `div` that was two-thirds the size of the screen, and that was it. Then, we could demo on any device with the best experience being on the phone. Obviously, there is probably a better solution for a bigger project, but starting with the screen size most likely for our users allowed us to demonstrate the project’s validity.

Managing, coaching, and mentoring are valuable, especially in tech. Can you share your experiences in these roles and the importance of mentorship in career growth?

My first opportunities resulted from sponsorship from the best boss I have ever had. Sponsorship is when someone with more influence than you advocates for you in spaces where you are not. He also coached me and modeled some great habits that I use today. 

Later on, I found that mentorship and coaching can be rewarding on both sides. I find I’m at my best when building people around me, whether teaching, coaching, or celebrating victories. Plus, I’ve also found peer coaching to be rewarding. At USDS, we often coach each other by talking through problems, giving each other ideas, commiserating, or whatever is needed. The job is hard, and having such great colleagues makes it easier.

Most importantly, the key is building relationships with people you want to be more like and with people who build you up. Remember that the mentor isn’t who you think it’ll be sometimes. They may be younger, not look like you, and may not even be in tech. 

What advice would you give to budding software engineers, especially those looking to make a meaningful impact in public service through technology?

First, I tell everyone, engineers or not, to find your people. Who builds you up, who’s there when you need them, who can you support in turn? Make sure you have a group of people there for you. 

Second, ask all the questions. Keep looking for people whom you can ask questions of and if there isn’t anyone, connect with people outside work where you can safely ask ‘what query joins are’ or ‘what TCP/IP is. Ask about your tickets to break stuff down to the smallest parts, and ask questions of your designers, leads, or product managers about why this work is important. Look at the big picture as much as you can. Often, people bring solutions without really considering the problem. So ask! Ask! Ask!

As for my budding civic technologists, the first thing to remember about anything you’re passionate about is that you care a lot. And that’s good, but you must also remember to take care of yourself. Set your boundaries, and if you feel yourself hustling to prove yourself to people, examine the situation and see if it’s healthy. Anytime you combine a precise art like writing code with caring deeply about the work, you will get close to burnout at some point. Understand what helps you to avoid burnout. We need you here, but we also need you to be healthy and capable.

What are you passionate about outside of work?

I have two elementary-aged boys who make me laugh and think and inspire me to follow on their path. I love watching them blossom and grow and seeing what they are into. 

I also compete with my two herding dogs in agility, an obstacle course game where you do jumps and tunnels and things at speed. I see a ton of connections with my work in this game. The trusting relationship I have with my two dogs is a lot like the trust I need to foster on the teams I work on. The level of precision and clarity I have to teach them to do really hard skills is not unlike breaking down my work. “Proofing” skills, or testing them out in different situations, is very much like testing software, and the mental game you have to bring to perform in national competitions is helpful when you’re doing something out of your comfort zone, which is similar to this job.