This is the second in a three part series on empowering early career devs. In this post, I’ll cover the processes we’ve been putting in place on my current team to facilitate opportunities for my early career team members to be empowered. I’ll walk through what we’ve done and what we’ve learned.

1. Empowering Early Career Devs: Why its important
2. Empowering Early Career Devs: My current team process
3. Empowering Early Career Devs: Strategies for your team

I’ll be using the framework of Prepare, Propose, and Practice to introduce our process.

Prepare > Propose > Practice

Prepare

The first phase, Prepare, is where this plan came to life. Working with my manager, we talked about ways we could mentor and coach my team to help their professional growth. We thought it would be great to find a way for everyone on the team to have ownership over the project as well as space to practice skills they weren’t getting a chance to.

So I started by asking how am I a silo? What roles and responsibilities do I have, as a lead, that the team doesn’t get insight into and that results in them not getting the experience they need to grow? For our project and my team, the answer client communication. I owned almost all of the technical communication with the client. My team could really use the opportunity to practice and grow their consulting skills but didn’t have a place in which to do that. I was also leading all of our decisions and meetings, but my team was ready to share those responsibilities.

From there, I spent some time defining the purpose of what we were trying to do. I wanted to define the responsibilities so that everyone had clear expectations of the new practices we were putting in place.

For all members of the team to gain consulting, client engagement, and leadership experience.

Ultimately, we decided that each member of the team would own a feature area of the application.

Finally, I had to prepare myself to delegate. This was the biggest challenge for myself personally and I think for a lot of people leading a team. You need to prepare yourself to share responsibility and accountability, and to let go of some of the micromanager tendencies that can be common in leadership.

Think about your role as a team lead like the grounds crew at an airport. To connect to a jet-way bridge, an arriving plane must center itself perfectly on a white “J line” painted on the tarmac. Because the airplane door is behind the cockpit and the J line is underneath, pilots can’t hit their marks perfectly without help. The Federal Aviation Administration actually requires three ground crewmembers to guide in each big plane — a “marshaler” under the nose of the aircraft and two “wing walkers” on either side. So your role as a lead is the same as those grounds crew members: to watch out for things the team may not be aware of or may not see and direct them towards success. You are not jumping into the cockpit and doing it for them.

Propose

The second step to implementing our new process was Propose. In the Prepare step, it was mostly me and my manager coming up with ways to put a plan into place. But in this second step, I wanted to introduce the plan to the team, create a shared understanding, and get feedback from the group about the roles and responsibilities.

These were the responsibilities for feature ownership that I introduced to my team. We were able to discuss, clarify, and refine these as a group. These might serve as ideas that you could potentially use.

The first part of feature ownership is being the client’s point of contact for that feature. As a feature owner, the team member facilitates communication relevant to their application area with external stakeholders and they become a trusted expert for the stakeholders. The team member gets to practice asking questions of clients, holding them accountable to communication deliverables, but they also get to practice answering client questions about feature requests, timeline, and priority.

Next, the feature owners need to document everything they’ve learned from their conversations with the client or other external stakeholders. This might include system architecture, user stories, access control requirements, decisions, etc of their application area for the team. Documentation isn’t a flashy part of consulting, but its important. Good documentation and written communication skills are often underrated and everyone has a tendency to oversimplify the amount of effort and skill it takes to write clear and actionable requirements.

A natural progression of documentation is knowledge sharing. The feature owner needs to make sure that they take whatever they’ve learned through their conversations with the client and whatever they’ve documented and communicate those learnings to the team. We don’t want their consulting work to happen in a vacuum and we definitely don’t want 8 distributed knowledge silos, so its vital that the feature owner shares their information with the rest of the team.

The feature owners are a key stakeholder in implementation decisions related to their application area. They get to practice making and being held accountable to their implementation decisions. And they get practice advocating for their decisions when they present their implementation decisions to the rest of the team.

And finally, feature owners attend and lead meetings related to their application area. This helps build domain expertise, facilitation skills, and confidence. It also had the added benefit of helping my team learn what makes a meeting valuable, how to make sure the meetings you schedule are valuable, and when they should just send an email.

During the Propose step, I thought it was important to make sure my team understood what this new process was not as well.

The feature owner wouldn't be the sole owner and decision maker of their application area. They would still be supported by me and other senior engineers on the project. They'd share decision making responsibility with both me, our design lead, and our product owner. And just like a team lead doesn’t write all of the code for their project, the feature owner would still have the support and shared coding responsibility with the rest of the team for their feature.

Practice

The third and final step for us to put this new process in place with everyone sharing these responsibilities was to Practice.

We have an ongoing rotation of feature ownership as we progress through our product roadmap. A few sprints before we are set to start working on a new area of the application, I assign the feature to one of our team members who reaches out to the appropriate stakeholders with our client to gather technical requirements (API integrations, file formats, job schedules, etc), understand their present-day workflow, and start identifying any risks as we learn more about that particular application area.

In our Google Drive, we have folders for each feature where the team keeps all of the documentation. The feature owner puts any and all documentation in this central location. It can be legacy WSDL files, results of data modeling exercises, or an ongoing list of open questions we have for the client.

Here you can see a document Chris uses to track questions we’ve asked the client and the answers we’ve received. Its been super helpful to increase our communication transparency on the team since the client doesn’t always reply to emails—sometimes they Slack or come to the office to answer questions in person.

Sometimes, we need to document decisions that have been made. Here is how Sasha documented some infrastructure decisions we made. She had a conversation with the client and some team members about legacy infrastructure and what we would need to continue to support for backwards compatibility and what we could sunset. She took a picture of our whiteboard and put a few bullets summarizing our decisions. Now the whole team can reference this.

But sometimes documentation isn’t enough and we need to do in-person knowledge sharing. You can see here Sasha scheduled a meeting for the team to discuss the responsibilities of some of the classes in our code and remind us how we should be using them.

The feature owner is also responsible for writing the user stories for their features area. I’ve noticed huge improvements in our team’s user stories over the last few months of our team sharing this responsibility. Our user stories have become more detailed, easier to understand (they’re scoped better) and as a result, our estimates are continuing to improve.

Here Shamyle has created a sub-task for us to make an XML request to a third party service and he’s added a high-level description and some implementation notes for whoever picks up this card and attached a sample request. Anyone on the team could pick up this task and hit the ground running.

Throughout the duration of the feature implementation, the team member continues to facilitate the dialogue with the client and get answers to any questions that may come up as well as field their questions and feature requests. In some cases, this is simply following up on open questions the team has. But in other cases, this can be more challenging and can be holding the client accountable for their deliverables they’ve promised us.

What are we learning?

I’ve personally learned that delegating is hard. And as a lead, you need to be committed to continuing to work on this skill for your team to have as many opportunities as possible to grow.

Feedback is crucial throughout this process. First and foremost, make sure that you’re providing feedback to your team about what they are doing amazing. Identify their growth for them. Fight that imposter syndrome!

Also, make sure to give them constructive feedback so they can continue to grow. Make it feel so normal to give and receive feedback that constructive feedback isn’t scary. It can be something as simple as, “Don’t be afraid to redirect a conversation with a client when they go on tangents like that. Some strategies I like to use are x, y, z."

And also remember to solicit feedback for how you’re doing! One piece of feedback I received early during this process was to prep with one of my team members more before they facilitate a meeting. That’s what they needed to feel more successful, and it was super helpful feedback. I’m more aware of it now and do my best to schedule time on the calendar to prep before meetings.

We've been learning as a team when to offer support and when to take a step back. A lot of the time, it's as simple as asking “How much support would you like on this?” I’ll be talking more about support in the next post, but there are a variety of ways to support your team members.

And finally, remember to check-in especially as your team members move through this process. It can be easy to make assumptions about the types of challenges your team is ready for but they know themselves best. Check in with them, how they’re feeling, what skills they want to work on, and incorporate that into how you improve and iterate on your process.

In the first part of this series, I covered why its so important for those of us in senior or lead roles to invest in and encourage the early career talent on our teams.

In the final part of this series, I’ll give you strategies to build a process like this to empower the early career developers on your team.