Nikki Lee, Product Manager, 18F
Editor’s note: GovLoop interviewed current and former government employees about limiting beliefs they’ve seen throughout their careers in public service. Here’s an excerpt from that conversation in the words of one interviewee.
Nikki Lee is a Product Manager at 18F. She helps state and federal government agencies build capacity for product management inside their organizations and sort out thorny technical problems.
Limiting belief: Nontechnical teams in government cannot successfully lead technology projects.
The backstory: There’s this myth that government needs to outsource IT mainly because their staff is not capable of leading technology projects. And that results in program staff taking their hands off the steering wheel, and it forces the IT teams, who are often vendors, to figure it out with minimal input. This fear and uncertainty causes people to step away from important work that they ought to be doing.
More on that issue: Technologists like myself haven’t done a good enough job being inclusive in the way we talk about our work and in the way that we incorporate other people who maybe aren’t as familiar with building software. I put the onus on us as technologists to do a better job of showing that we can explain things in plain language and that there are areas where we need input from nontechnical collaborators.
How limiting beliefs are communicated: You’ll hear people say everything ranging from “I can’t do IT” or “I don’t understand IT” all the way to a really direct “I don’t like technology, it’s not my area of expertise.” And often people will extend that to their team at large and say, “Not only do I personally not feel comfortable with technology, but we as a group don’t have technology skills.”
Know the warning signs: If you’re working in government and the only real contact you have with the vendor after an award is made is about documenting performance, I would say that’s a warning sign that you’re probably holding back and letting your discomfort guide your distance.
Know the goal: The ultimate thing that you want to be doing is having program staff and IT staff acting like a true team together. And you want to be in a place where you’re able to acknowledge that everybody on the team is holding a piece of the bigger picture. The only way that you can guarantee that you’ll be building the right thing is if you bring all of those perspectives together.
Understand the why: Your program staff, who is closest to the policy, is going to own the why of a project — the why is this project happening and what difference in the world it’s going to make. Your technical staff, who have deep expertise in building software, are going to own the how of the solution. And then the place where you really meet in the middle and have 50/50 ownership is defining what it is that we’re going to build together.
Advice to cut through red tape
For technical employees: The conversation needs to be about making our work accessible and making our work understandable and approachable to an audience that isn’t super confident and comfortable with technology. Continuously reinforce with your coworkers that you need input from program staff.
For nontechnical employees: Take more strategic ownership of your work. When you’re talking to technical staff, help them understand the mission and the program priorities as much as possible. Just like technical folks should be explaining things in plain language, they also need feedback from their nontechnical teammates. Remind yourself: Technology helps us achieve the mission, and so there’s no reason that we should be disconnected from technology projects that further our mission.
This article is an excerpt from GovLoop’s new guide, “Agency of the Future: Common Misconceptions Holding You Back and How to Break Free.” Download the full guide here.
Yes!!! This is a huge pet-peeve of mine. Only IT people are capable of learning or making technological changes.
The people who know the work need to learn the technology because that’s the most efficient way to make tools that work for them.
Our e-sign off system was created by four non-IT personnel who were committed to learning how the make the technology work for the work we do. In fact, our system was even selected over a contractor proposal because it fit the work better and was more user-friendly.