Three Lessons I’ve Learned from Three Previous Bosses

In just over three years at my current company I’ve had four different bosses. This has been due to organizational shifts, role changes, and an agile transformation (though it could really be that I’m a real challenge to manage). While some may dislike this change frequency, I’ve personally enjoyed learning from such a variety of good leaders, each with different lessons that I’ve tried to absorb and share below. Note that I left out my current boss not because I haven’t learned anything from him, but because:

1. It could come off as brownnosing
2. He could be reading this. In that case see #1

Boss #1 — The Importance of Stretch Assignments

My current role (developer chapter lead) is sorta like a half manager. I don’t lead any teams (at least not officially), but instead I’m responsible for the growth & career development of the employees reporting to me, alongside other people leadership and software development activities. In this role I think & talk a lot about upskilling, trying to unravel the problem of how to ensure that my talented, hard-working developers have the future-oriented skills needed to succeed in their next role, technology, etc. While I’ve often focused on formal training and mentorship, I’ve started to realize that on-the-job learning is usually the best way to grow as a professional, especially for high performers.

This is something my first boss understood well. I joined his team as a junior Java developer, but soon saw that the team’s scrum practices weren’t exactly “up to code”, and that cleaning them up could help us establish, stick to, communicate, and execute on a development plan based on prioritized needs every two weeks. Given my experience working in both adopting & mature scrum teams I emailed my boss and asked if I could help the team clean up their scrum practices. Looking back I realized how bold this was (most scrum masters were at least two pay-grades above me), but this boss gave me the green light, presumably curious about what this bold, snot-nosed college kid could do. After helping the team deliver consistent value that aligned with the program strategy, this first boss saw an opportunity to tap me for a new role: Lead the first company-hired team in a new platform called Appian. Nevermind the fact that I’d never worked in Appian before, nor had I ever led a team, he saw potential in me, and wanted to see if I could handle a challenge that on paper seemed well beyond the typical junior developer’s job description. Through many late nights I was ultimately successful in this role, and this provided enough firepower for him to double-promote me into a new role called a developer chapter lead, where I remain today.

The reason why I had such a strong start to my career was not entirely because boss #1 provided excellent training opportunities or pitch-perfect feedback (not that he was bad at any of that), but because he was an expert at giving stretch opportunities. He saw something in me (whether that was potential, pure hutzpah, or a bit of both) and gave me stretch roles that challenged me & fostered fast growth, while ensuring he had a backup plan in case I failed.

Since then I’ve constantly looked for ways to enable my developers’ career path-oriented skills development by finding opportunities for them to practice that next step in a small-scale, safe environment. A good example is with potential future tech leads: I’ll often bug their team’s leadership to break off a specific feature and give it to my developer to lead the requirements gathering, refinement, design, and development processes as a typical tech lead would. Not only does this take load off of their actual team’s (often overworked & grateful) tech lead, but it gives my developer the opportunity to experience what this role is like at a smaller scale, and build the skills they’ll need when they finally get the chance to lead a full team.

Boss #2 — Build a Reputation, and a Career Will Come

After getting the developer chapter lead position and briefly (unofficially) “reporting” to a senior leader in another department who taught me the basics of people leadership, I ended up under boss #2. Of the many valuable lessons I learned from her, one that stands out came from one of our “career conversations”.

Given my interest in a future senior leadership role (once my beard’s turned grey and I’m a lot wiser than I am now), I asked her how ladder climbing works in her experience. She answered thusly (to paraphrase):

Don’t focus on climbing the ladder. Instead focus on building a good reputation with the people around you. Interesting opportunities & new roles will come to someone who works hard, shows talent, and cares about the people they work with, but this only happens to those who build a good reputation. Become the type of person that people want on their team, in their meetings, & within their collaboration sphere, and good things will come.

I’ve thought about this a lot since our conversation, and I think it’s a great way to build a career & satisfy ambition healthfully. By slitting throats (metaphorically of course) to climb to the top you’re only building a reputation as a backstabber amongst those who’ve worked with you, and when you need their help most they’ll be unlikely to give you the time of day. Whereas focusing on doing right by others, keeping your commitments, helping when asked (while fostering learning and not just “giving the person a fish so they can eat for a day”), actively spreading knowledge widely, and celebrating others’ accomplishments leads to not only more opportunities & broader support when you take said opportunities, but it’s also a much healthier ambition to strive for, and one that’s more enjoyable in my opinion.

Boss #3 — Pick Your Organizational Battles

Boss #3 had been at the company for over two decades, and as such had great organizational awareness. This was a good counterbalance for me since my first instinct is to change things that seem outdated or ineffective, regardless of how widespread and engrained they are. But organizational change “from below” can only be done in bits at a time, and is typically a process of testing the idea amongst peers (“do others feel the same way I do?”), building broader support, finalizing the proposal based on feedback, then finding the right channel to filter the request up. This is time consuming and often doesn’t pan out, so much like in software development it’s important to prioritize which changes you’d like to see, focus on those first, and gradually iterate, performing the cost-value analysis and reprioritizing as you go. Priority typically comes down to:

• Impact — What’s the upside of changing this practice or process?
• Challenge — How widespread is this practice (local to your team vs. company-wide)? How engrained is it in the company’s processes or culture? Do you see the full picture around its impacts (could there be upsides to this practice elsewhere that you don’t know about)? How open are communication channels to the level where this could be addressed?
• Potential for Failure — How receptive are your peers to this change? Do they feel the same way about the practice as you do? How excited does senior leadership seem about this practice?
• Downsides for Failure — If this gets rejected, what would that do for your reputation amongst peers & senior management? (seems egotistical but this could impact your ability to elicit future changes)

By prioritizing impactful change initiatives that probably won’t receive as much pushback or carry as much risk, you can make a strong positive impact without sacrificing time and credibility that can be used elsewhere.