Setting Standards for Roles You Know Nothing About
How do you set standards for roles which you have no expertise in? This was a challenge I faced when building OGP. What’s the right bar for a product manager, a senior designer, or a staff engineer? Job titles are all over the place so you can’t rely on them. And every org means something different when they call someone an engineer.
What I ended up doing was talking to anyone in tech who was willing to share their responsibilities and compensation. This gave me a baseline from which I could create competitive roles with similar standards, then adjusted them to our needs. For example, we use rapid prototypes to get buy-in from agencies, so our engineers need more fluency in being full-stack than they do in scaling infrastructure. Similarly, our product managers don’t need to do much marketing, but they need to be very good at navigating stakeholders. It took a while, but to get this right I had to let go of setting standards philosophically and focus instead on the practical implications.
When I set standards too high, it was relatively straightforward to diagnose. People got frustrated with their performance ratings. My best officers left for other roles with greater responsibility and compensation. And good candidates consistently got past our interviews only to reject our offers. This was painful, but at least it was easy to fix.
When I set standards too low, the problem was more insidious. In the short run, everyone was happier. Bigger performance bonuses. Promotions were celebrated. Candidates were happily accepting generous offers. It felt like we had done the right thing.
Where it bit us later was when teams failed to deliver. Quality dropped and deadlines slipped. People lost trust as colleagues dropped the ball. Yet despite these problems, people stuck around and teams got bigger while delivering worse results. I spent a lot of time chasing these issues before identifying the core problem: people were in roles beyond their capability.
This can get very complicated in practice. You might expect too much of junior officers while being too lax with senior ones. Mismatched standards meant I had amazing infrastructure engineers struggling because I really needed webdevs. Because our roles are very different from other orgs, I had to accept that new hires wouldn’t be able to hit the ground running, and we needed to double down on training to get them up to speed. You never get it perfect, but what’s important is you continually adjust as your needs change.
At OGP, our mission is to get government technology working with the same efficiency and innovation that the tech industry is known for. I’ve found that getting standards right has been much more important than any strategic direction or product decision.
Practical steps for how I set roles and levels for OGP
The broad approach is to:
Decide org structure
Design roles and levels for it
Map them to the market
See where you’re wrong and iterate
Concretely:
Figure out what your org is trying to do. OGP’s goal is to experiment with new tech ideas across the public sector. So our strategy is to have lots of independent product teams who are good at rapid prototyping.
Figure out your ideal long term org structure. Our basic product team is 1 PM 1 Designer 3 Engineers. A division has 5 teams to allow managers to keep context. Division leadership has functional leads to keep expertise in management. This is a bit “draw the rest of the owl” but it doesn’t have to be perfect.
Identify stereotypical roles you have in this structure. Write a job description for each of these roles so you’re clear on what you expect them to do. Actual people will differ from these stereotypes, but they are a useful reference point for expectations.
Group similar roles and label them with an approximate seniority needed. In reality you might need someone more senior/junior there depending on project needs, but it serves as a good reference point. Some roles are progressions, where others are different jobs entirely.
Go talk to anyone who is in a similar space and is willing to share. Show them what you’ve mapped out and ask them what they think. You will learn a lot about how reasonable your expectations are. Or if you’re even talking to the right industry to begin with.
Map competitive roles in other companies. Your roles will never be an exact match. What matters is not whether they are philosophically the same, but practically what you are competing with for the people you need.
Try to hire & retain and adjust as you fail. All this was just to get an approximation. As candidates decline offers and people leave for other jobs, ask them if they are okay sharing what the other offer is like. You’ll quickly get a sense of how off you are. Sometimes it’s just a small adjustment to comp to make it competitive. Sometimes you’ll need to rethink your entire structure. For example, with OGP we found that good cross-functional leaders are exceedingly rare, so I’m shifting to teams of leaders from different functions instead.
When I first started building a team, learning about different job titles and career frameworks all felt very arcane. Taking this practical approach really helped me demystify things. There’s no universal “software engineer,” or “senior,” or even “critical skills”. There’s just the org you want, the roles to run that org, and the competitive market for those roles. Everything else is a contrivance to get to that.OGP is looking for experienced engineers and product managers!