Level up your DevRel Team
A presentation at Dublin DevRel Meetup - April in in Dublin, Ireland by Jason St-Cyr
Level up your DevRel Team
Hello friends, my name is Jason! I lead our Developer Relations efforts over at Sitecore and today I want to talk about the challenge of levelling up your team. As a people manager, there are a lot of hats to wear, and often we have to wear the hat of a career coach. From the first day that a new team member joins the crew, to the day they become a manager in their own right, I feel that part of my job is help guide folks and provide opportunities to advance.
Guiding the story
In some ways, this is like being the Game Master for a group of adventurers in your favourite Table Top RPG. Each one of these party members has their background, skill sets, experience, role in the party, and a story waiting to be told. Today, let’s talk about how we can guide folks in that story!
What are we going to talk about?
I wish I could go through everything, but with limited time today I’m going to focus on those higher level opportunities to level up. Obviously, how this happens depends a lot on the individual and the skills and experience they bring to the table, but I’ll cover a general blueprint that has worked for me!
First up we’ll look at getting to a senior level From there we’ll look at both levelling up as an independent contributor, or making the switch to the manager track.
For each of these, I’ll talk about some common tactics we can use to set up appropriate challenges for them to level up!
DevRel @Sitecore
Before we dive into the details, it might be good to set the context for where I’ve used these tactics.
At Sitecore, I’ve defined DevRel as being an audience-focused group that handles a lot of different functions across Developer Advocacy, Community Programs, and Developer Experience. Sitecore is big enough that we have teams focused on reference documentation, support, field marketing, that sort of thing. So we address the gaps that connect with the community. Things like community events, newsletters, engaging with individuals on digital platforms, creating helpful content for our community, starter kits, examples, and running ambassador/MVP programs.
Okay, with that context… let’s get started!
Climbing the rope
Every organization uses a different set of levels for their individual contributors. However, there’s an analogy I’ve seen about rope and rope making that I’ve really liked, trying to determine the difference between different levels of seniority:
Climbing the rope - Intern
Intern/Just out of school: Learns about rope
Climbing the rope - Junior
Junior: Can tie basic knots, shown complex knots
Climbing the rope - Intermediate
Intermediate: knows a lot about knots, calculates rope strength
Climbing the rope - Senior
Senior: Understands rope making
Climbing the rope - Principal
Principal: Knows more about rope than you ever will.
Climbing the rope
I love matching this onto basic roles in the team. In our context, it might be:
- Intern: Learns about the products and things like writing and video editing and community support
- Junior: Participates in developer advocacy and collaborates with others in the team
- Intermediate: Joins projects with support from seniors, voice of the developer for a product
- Senior: Mentors and leads projects, becoming a voice of the company in the industry
- Principal: Coach, leads programs, impact beyond the team and company, drives strategy and results, knows more about helping developers than you ever will
Intermediate vs Senior
When I look at the difference between an intermediate and a senior, I see four big things as the capabilities that I want to see them demonstrate.
Intermediate vs Senior: Mentoring and coaching
At an intermediate level, you focus a lot on doing your job really well, but I expect a senior person to know how to think about projects beyond themselves and bringing others along, teaching what they know, helping others do better.
Intermediate vs Senior: Key results and execution
At a senior level, I expect the individual to understand the strategy and be able to explain what we need to do, and when, and then drive the group to get those results. This sounds a little bit like a project manager, but somewhat different. There are a lot of similar skill overlaps, though.
Intermediate vs Senior: Collaboration
At an intermediate level, I expect someone is participating in collaboration and actively working with others in the team. But for a senior I expect they are the ones driving this collaboration to happen, not only in the team but across departments. They are reaching out, setting up alignments with other teams as needed, and getting everybody working together.
Intermediate vs Senior: Self-driven
My senior staff is confident that they really know their role and how it will be successful. They feel empowered to make decisions and keep me up to date. They don’t need to be micro-managed and can have independence to do what is needed to accomplish our goals.
Providing adventure opportunities to learn
Okay, so your adventurer is starting out on this path. You get to be the Gandalf to their Bilbo and guide them to the next level. The first step is always about identifying the gaps between where they are, and what is next. What would they need to be able to do for you to feel comfortable promoting them?
Once you know the target, then you can start opening up opportunities for them.
Mentoring and Coaching
For example, let’s take the case of mentoring/coaching. As an intermediate-level individual, it can be tough to establish a seniority enough to be doing mentoring or coaching of somebody else. This usually requires you to have junior-level members of the team. If you happen to have some more junior folks, having them help with onboarding the member to the team or working together on a project can be a great way to allow them to practice this skill set.
Another way would be through leveraging their existing expertise. Perhaps they are really good at video production, or copy editing, or doing code reviews. Find a strong-suit of theirs, whatever their superpower is in the team, and encourage them to help other team members on that. This might look like a guide for the other team members, a show-and-tell during a team meeting, or even establishing a review process of ongoing work where they get the opportunity to provide feedback to other team members on that expertise topic.
A third thought here would be using your community. Having them help members of the community work through issues, or answering questions, can be one way that they can establish their ability to take more of a mentoring role.
Define key results and drive execution
As a manager, the easy mode for me on this is to delegate a project. Our teams come up with projects all the time, and giving an opportunity to lead one of these projects is a great way for them to get experience defining priorities, what success looks like/definition of done, and keeping on top of all the stakeholders involved.
Some people are not quite ready for that yet. Instead of a project, I try to find something that is more about process and following up/reviewing. For example, we run an agile task board for all the content we are creating. I allow folks who are first taking their step into owning something to take on owning the board. They become a point of contact for questions, they check to make sure things are flowing, and follow up when things seem to be getting stuck.
Drive collaboration across functions
This is one I usually prefer to save for later in someone’s development. I prefer to have somebody start off by working internally in the team. It is a safer place for them, psychologically. They know that their teammates have their back and I try to foster a work environment that accepts that things don’t always work. However, going to senior means leaving the bubble more and more and working with other teams and departments.
This project might be a sample starter kit, an FAQ, or a recommended practices article. Something that multiple teams need to provide feedback or content into.
This type of a project allows them to learn a little of trying to align multiple points of view, managing timelines and availability of people, and establishing a habit for decision making and delegation/task assignment.
Self-driven and independent
For me, this is the most nebulous one to tackle. Everybody develops different skills at different rates, and this needs to be a gradual change.
It might start by having less direction from the management level and moving more towards a reviewer position. Having them start defining task priorities can let them learn about what’s important and how to make that decision.
My colleague Thomas uses the terms “I do, we do, you do” to talk about the transition of knowledge of how to do a task, and I think that fits here well. At first, I’ll have somebody join me or another team member to see how a task should be done. Then they get to participate and start learning these tasks. Finally, they do it on their own with the ability to ask questions and get support. Eventually, fewer and fewer questions come in and the amount of supervision required goes down.
Senior vs Principal
Let’s talk about the next jump up: the Principal. This has different names in different organizations: Staff/Fellow/Ninja/Director. For today, I’m focusing on a role that is a level above the Senior role. At this point in their career, some folks just don’t want the management track and want to stay in the independent contributor role. So how do you give them a path to level up?
When I look at the difference between a Senior and a Principal, I see these 3 things as the priorities:
Senior vs Principal - Drives strategy
Where a senior member of the team may be driving the execution, I feel a Principal layer is able to see things above the project and focus at the program and team level. They are able to define strategies and objectives, they own major programs and are recognized as a strategic member of the execution team.
Senior vs Principal - Impact beyond the company
This is especially true for developer advocates, but one thing I look for in a Principal level is not only the participation in the industry, but impact upon the industry. With DevRel folks, a lot of the roles across seniority levels already have an element of working with the community outside the company. Unless you’re in Internal DevRel, you are somehow working with developers in the industry. The objective here is not to participate in the community, or trying to evangelize the product or company, but showing expertise in Developer Relations itself.
Senior vs Principal - Drives improvement
They will monitors the current industry trends, where the company sits in the ecosystem, what is happening in DevRel. They make suggestions and improvements to make the team better and keep pushing for continuous improvement on the team.
Giving veterans a path to mastery
So what do stretch opportunities look like for somebody who wants to move beyond senior and into this Principal type of role? Just like with moving to senior, you might have informal gap assessments, or you are using a career ladder definition to help you out. If we focus on the three specific differences I mentioned before:
Drives strategy
One of the big deltas is moving from thinking about execution and into looking above the project level. A really straightforward opportunity here is to give the individual charge over a program or area of responsibility in the team. You can work together on defining the goals and objectives for the upcoming quarter/half that relate to that program. Also, when it comes time for budget discussions, invite them to suggest where improvements could be made. What areas should we be investing in, asking for more staff, getting additional budget. And also where should we be cutting? As time goes by, this can change from involving them in providing feedback towards full delegation of the ownership for this program or area.
Another very tactical thing you can do is to start involving them in calls related to their program or area of responsibility. By having them there, they can speak up on the details of the program with other decision makers in the organization. This raises their visibility outside the team and also gets others to know that this program is something owned by them. Eventually, this also might mean one less meeting in your calendar!
Impact beyond the company
In terms of showing industry impact, I would try to connect them with developer relations events, like this one, or have them start a video series or blog where they can begin advocating for developer advocacy, or community management, or whatever their area of expertise is. Much as they would have done a talk about how to connect to an API layer from Next.js, but instead changing to their DevRel role instead.
I would want them to be engaging in DevRel communities, trying to help other professionals who are starting into this type of role. Much as you want a developer advocate to build brand trust in your product, but now the product is the DevRel team itself.
Drives improvement
Getting someone to drive improvement for the team is probably the easier one to plan for. They have probably already been doing this, but in a more passive mindset. Your team member may already have been providing feedback to you over the years on where things could be improved. The key change we are looking for here is that they not only identify what could be an improvement, but can back that up with industry examples, prioritize it along other opportunities, and drive the execution of the change.
This can start out simple by working together on defining actions. Grabbing their feedback and working with them to figure out a list of things that the team could do to improve. When you feel they are ready, have them start identifying which ones are more important, or would have the best impact based on the effort required. This allows them to start getting prioritization into the mix. Usually, after these sessions, you would be driving the change and working with your reports to get people to adopt new ways of working. What we want to do here is to gradually allow our senior team member to start leading that driving. Having them show the options that were looked into, the current priorities, and evangelizing the change with the rest of the team.
Senior vs Management
Sometimes somebody in the party is interested in going a leadership path instead. Often this is from a Senior level, where they have already developed some of the mentoring and lead capabilities in the team.
Whereas transitioning from Senior to Principal is more about learning to be the absolute best at Rope Making, moving from Senior to a Manager role is more like transitioning from making the rope to being able to make sure all the rope makers have what they need to make the best rope. It’s handy that you know about rope and understand the industry and know what the rope makers are doing, but the real skills you need have nothing to do with the rope or rope making.
These are the priority gap areas I look at:
Senior vs Management: Career coaching
This is a natural follow-on from the role of mentoring/coaching junior members of the team. However, instead of focusing on coaching about how to do a specific role, they are focusing on coaching on how this individual can get to the next role or level.
Senior vs Management: Prioritization
At a Senior level, we worry about prioritizing the tasks in a project. Going to the manager/team lead we need to do that and also look at the higher levels. Which projects are more important? What needs to be done this quarter/half?
Senior vs Management: Status reporting
Individual contributors know to report their own status: what I did today, yesterday, will do next. At a manager level you now have to summarize that and report up, without the gritty details. You need that context, but with upper management they need a more abstract update that lets them know if things are on time, or if there are any major issues.
Senior vs Management: Performance reviews
Everybody loves sitting down with their manager for their periodic HR-mandated performance review cycle. Most folks know what it’s like to be reviewed for their performance, but in this case we are flipping to the other side. Now you need to know about evaluating a team member’s performance against expectations and goals and also how to plan for what’s next for them.
Planning opportunities to lead the adventure
So what do stretch opportunities look like when transitioning into a manager track? The ‘ladder’ approach before doesn’t apply here, now we’re switching to a different track. Here’s how we can help somebody build those muscles:
Career Coaching
One first step might be to ask for feedback about some of the more junior team members and what seems to excite them. You’re looking to learn more about your team and where you can be coaching them for their career, but this also allows your senior team member to start thinking more critically about strengths and weaknesses of the team.
Another element to try here is involving them in discussions on progression opportunities for other members of the team. Try asking them what projects might be coming up where somebody would have an opportunity to try a new skill? Or if there was a particular part of their work that they felt would be a good opportunity for another member of the team.
Prioritization, Goals, and Objectives
This is probably one of the easier ones to make opportunities for. Initially, your party member can join you in defining goals to see how it’s done. You can purposefully identify too many objectives and then ask them for help in prioritizing which should be done next. You may eventually give them a program area that they will own. You can work with them to help them determine the priorities for that area. Eventually, you can push that area completely to them and let them define their own goals for that area.
Status/Progress Reporting
Managing upwards can be tricky to open opportunities for. Typically this would be your role to go above the team, and typically your reports are providing status updates to you. One way to do this is to have your senior team member start running your status meetings where you gather updates from part of the team. This allows them to learn about running the calls and gathering the input from multiple folks. Later on, you can have them provide the status to you from those calls so they get used to summarizing and reporting. Another option is having internal newsletters, department update emails, etc. Have them own a section about their group so they can learn about reporting outside the group.
Performance reviews
For performance reviews, a good first step is gathering feedback about other members of the team. This allows them to start thinking about all members of the team, not just themselves.
Using shadowing on reviews also allows them to see what you do and how you make decisions. They can ask questions, you can explain why you are doing things, and you can work together on messages/ratings.
Beyond the individual review, you should also be going through the team view and comparing across individuals. Who is standing out? Who is taking on more challenging work?
Are we there yet?
For all of these changes, the question always exists: are they ready yet to level up? There is no science to deciding if somebody is ready to move to the next level. There is no metric or percentage of completion. In DevRel, the work can be very squishy, and the same goes true for deciding if somebody is now operating at a higher level. Everyone has different strengths and weaknesses. 100% coverage is not going to be needed, there are going to be some areas that right now are just not as important as others. Business priorities change, and we need to adapt with that.
What needs to be asked is: Are they strong in the areas that the team needs right now? Are they weak in areas that will cause an issue?
You can do this!
As we wrap up, there is a very important thing to remember: You can do this! You know your team better than anybody else and if you spend the time to get to know where they want to go and provide them the path, you’re doing the right thing.
In general, for any of these level up scenarios, here are things you can do to help somebody move forward:
Identity next step
Work with your team member on what they want their next step to be.
Define the path
Have a definition for what those next steps look like. Turn this into a career path if you can so you can reuse it
Provide opportunities
Provide opportunities to develop the capabilities for any gaps they have for that next step.
Evaluate readiness
100% is not needed. Align growth progress to the strategy. Have they developed the skills you need for the next step?
Level up!
When they’re ready, it’s time to level up! You get to push for that promotion and congratulate your teammate.
Questions?
THANK YOU!
Jason St-Cyr Director, Developer Relations Sitecore
- Website: jasonstcyr.com
- Mastodon: @jasonstcyr@mstdn.ca
- Twitter: @StCyrThoughts
A manager’s guide to creating career advancement adventures for your party members!
for free. You
can too.
Video
Resources
The following resources were mentioned during the presentation or are useful additional information.
-
Dublin DevRel Meetup
The Vito hub for the Dublin DevRel meetup
Buzz and feedback
Here’s what was said about this presentation on social media.
