Last month, I caught up with one of my former product managers and she gave me some feedback that I was great at fostering continuous growth for folks on my teams. This is something I’ve taken very seriously since I managed my first team of front-end web designers back in the early 2000s and it all started with a great manager I had at my first job after college.
Before dot-com, I had an administrative job at a pharmaceutical advertising agency in New York City. The year was 1998 and my boss was a wonderful person named Shirley. I reported to Shirley for about a year before I got a position designing and building websites for a stock photography agency making the difficult jump from analog to digital photo licensing.
What I loved about Shirley is that she always supported my career growth. The job was administrative — Microsoft Office all day — and she knew I wanted to get a job in the new field of web design. Shirley supported me in being successful at my admin job, learning how to type, put together slide presentations, and succeeding in a corporate office environment. She also supported me in learning HTML and Photoshop to become a web designer. She knew that my career was in high gear and that I wouldn’t be around for that long.
In Kim Scott’s book Radical Candor, Scott calls these folks “Super Stars”. These are folks who are in a phase of their life that allows them to rapidly advance their career. She differentiates them from “Rock Stars”, folks that excel at their role while also being satisfied in their role enough to stick around for a while. Super Stars, on the other hand, don’t tend to be on your team for long before they’re off to a new thing. This can be hard to accept as a manager. You’ve invested a lot in finding and hiring them and having their expertise on your team is a huge asset. But clinging to these folks will make you and them miserable. Shirley’s example for me made this a lot easier to accept as I began to manage people.
While I trained at night and in my downtime, Shirley was always there giving me feedback, asking me tough questions, and even letting me view my web pages on her computer — the only one in our department that was connected to the Internet at that time!
So I’ve taken Shirley’s inspiration with me over the years. — thank you Shirley ❤️ — and I have a few techniques I use to foster continuous growth on the teams I manage.
1. Create a space where it's safe to make mistakes
Creating safety means different things to people, so when I use “safe” in this context I mean that trust has been built over time on a team such that when mistakes are made they become positive growth experiences and not negative experiences which make folks feel unsafe to take risks in the future.
If you are a senior member of your team and you’re not confident that the rest of the team feels safe making mistakes, then you have an opportunity to make a positive impact on your team by leading by example. When you make mistakes, don’t cover them up. Explore your mistakes openly with your team in your next retrospective and ask for advice on how things could be better next time.
“I wish I had not OK’ed that new feature for production. I didn’t give folks enough time for QA and having to pull it back was embarrassing and wasted a lot of the team’s time. Do you all have ideas on how I can improve our process for next time?” — Me, during a retrospective after a botched release.
I find that whenever I own my mistakes, I lead by example and begin to build a culture where the entire team feels comfortable doing the same. This doesn’t mean folks are not accountable for their mistakes. Accountability is extremely important for building a great team. It does mean supporting folks through the full cycle of making a mistake, learning why it happened, fixing it, and learning how to do better next time.
2. Make growth a priority
Even the best work environments can sometimes be a grind. Sometimes there’s just too much to do and you’re short on time and people. Sometimes mistakes were made and you’re working a late night or two to fix them. Regardless, as a manager, it’s important to make individual growth a priority.
At one point I was mentoring a product manager, who had a lot on his plate. We had a couple of sessions together where we focused on the laundry list of tactical issues he was facing. Important work to be done, but after a month or so, I noticed the energy and morale started to slip in our sessions. I realized we were prioritizing his tactical work and neglecting the strategic stuff that would help him grow professionally.
I changed up our sessions so we dedicate an equal amount of time to his big-picture career growth. We did the strategic work first and dedicated the last half of the sessions to tactical work. This worked way better and within a month the mood and morale for both of us had drastically gotten better.
Proactively using your experience to help find learning resources, helping folks research new things, reaching out to your network for experts, and making sure folks have protected time and a budget to learn are all great ways to make growth a priority on your teams.
Additionally, use your "spidey-sense" as a leader to know when someone on your team is interested in learning about something but doesn’t feel safe telling you about it. This could be for various reasons such as being new to the team or fearing that it’s not relevant to their role at the organization.
This area, in particular, is a growth area for me as it can be easy for me to put blinders on and focus too much on the problems right in front of me. Often this is a symptom of being spread too thin, having too much on my plate or managing too many people.
3. Be honest and vulnerable about things you don’t know
If you’re a manager, have seniority, or are in a position of privilege at your organization, being honest and vulnerable when you need help is especially important. This can be a really hard thing, especially for mid and late-career folks.
A few years ago, I learned this the hard way when I was working with a large public school district to upgrade its web infrastructure. I hired two software engineers for the initial team. I felt nervous about the hires because I didn’t know the chosen software stack very well. Additionally, I prioritized budget over skill. Times were financially tough for my company and we needed to be frugal with the process and the cost of who we brought on. I took a risk that I could use my background to lead the technical screening of the candidates. I knew they were not the most senior of the candidates, but they were less expensive and I thought they were good enough to be successful at the job.
After two months, it was clear I had miscalculated. These folks were not working out and I had to let them go. It was a hard lesson for me to learn. We lost two months of engineering time and hadn’t made any significant progress. The design team was frustrated. The client was frustrated. I was frustrated. If instead, I had accepted that I didn’t have the knowledge to do the technical screening and instead hired a specialist to do it, we would have spent a little more money in the short term, but we would have saved a lot of money over the long term.
I learned from that mistake and guess what? I’m more confident in being honest with my team when I don’t know how to do things. It can be an ego bruiser at first, but I know from experience that the outcomes will be better in long run.
4. Create a structure for knowledge sharing
After your team does an activity a few times such as a design sprint or a product visioning workshop, patterns begin to emerge for how you make these successful for your organization. I’m not talking about the way Jake Knapp conducts a Design Sprint in his wonderful book, but the patterns from these practices that make them uniquely successful for your organization and stakeholders.
The patterns that emerge are the gold of your organization and where thought leadership can thrive. But this doesn’t happen without a system of governance around your practices. Inspired by my background as a Jazz musician, my last organization called this our Real Book. Other organizations might call this a playbook. Regardless of what you call it, it becomes your repository of how you get sh*t done. You shouldn’t be figuring out how to do things new every time. Start wherever you are with this and build on your institutional knowledge over time.
In our organization, we knew we needed to create templates for our practices, but it took a while for that to catch on — people are busy and it’s hard to know where to start. We began by creating a shared taxonomy of our practices and gathering all the past examples we could find for each practice.
Doing this created a framework for our designers, software engineers, and product managers to publish and evolve practices and the benefits slowly started to accelerate. Our workshops took less time to prepare, our teams developed a better cross-functional understanding of each other and thought leadership around our practices began to emerge.
Across the organization, it became easy to see who was the expert around a certain practice. It gave them organizational recognition for their expertise and created a system to ramp up others to the practice. We used Notion to build our Real Book, and AirTable probably would have worked great as well.
5. Bring folks along with your decisions
Being a leader in your organization could mean a lot of things, but I’m going to talk specifically to folks who have titles such as Manager, Director, VP, CEO, etc. Sometimes you are the person who has to make the decision that moves things forward, whatever it is, the buck stops with you.
Thankfully in my career, I’ve rarely worked in organizations where my boss ordered me to do something without any explanation for why. I’ve mostly had great managers who brought me along with their decisions.
Smart people ask, “Why?” And we all want to have smart folks on our teams. But answering the why is sometimes a bit of work. Especially if an individual is tied to a certain path and your organization needs to go in another direction. But just like a designer has to bring stakeholders along with their design decisions, you have to bring your team along if you want buy-in from them.
The best way to do this is to make your team, or a subset, part of the decision. Collaborate as far as you can, and when it’s time to make the decision, do so with confidence especially if it's unpopular. Let the team know what outcomes you’ll track to know whether it was right or not.
Don’t shame the contributor whose decision you didn’t go with. They put something out there and were vulnerable to do so. If you want them to contribute great ideas in the future, make sure you know that they’ve been heard. If you need to follow up with them — maybe one-on-one — to explain why you didn’t go with their solution, do so. If there are obvious flaws, let them know how it can be improved, and make sure to consider their recommendation if the path you chose doesn’t produce the outcomes you’re hoping for.
That’s it. Easy right? Well, not really. And I’m still learning every day. I’d love to hear from you. How do you foster continuous growth on your teams?