This is part three in a series on my career shift from software development to product management. If you haven’t read the preceding posts and you’re interested, you can start with part one!

When I first took on the role of Product Manager, it was basically a solo role. While I had plenty of support from our executive team, and a lot of help and direction from both my superiors and my colleagues, absent a dedicated staff, if things needed to be done, I either had to do them myself or trick others to do them for me1!

On its face this might seem a bit crazy (and it was!), but it’s important to realize that, at the time, the company had not yet made the shift to an Agile Scrum development model. As a result, back then, if you had asked me to describe the Product Manager role, I would have described it as high-level and directional, while the actual day-to-day execution was being handled by my colleagues in various other departments, particularly development. As a result, a lot of my time was spent on bigger picture stuff: building roadmaps (badly), scoping releases2, collecting and managing customer requests, general process development and refinement, and so on.3

It’s also worth noting that, at the time, I don’t think any of us at the company had a clear picture of how to integrate a Product Management function into the company in a holistic way, not the least of which because, while this was only five years ago, the role was less defined than it is now.4 And as I mentioned in my first post, ultimately, layering Product Management as a function into an existing organization is an exercise in change management, and we were still figuring out what that meant.

Fortunately, Agile Scrum came along and gave us a model for how to integrate Product Management into software development in a coherent way: The Product Owner role. And if we were going to have Product Owners, those POs needed to get their direction from somewhere, and that somewhere could be the Product Management group (i.e. me)!

It wasn’t much later that, through a mix of good fortune and good planning, we found ourselves in a position where we could grow and tackle some major new projects and products, and at that point the conclusion was inescapable: it was time to start building out an actual Product team, and in particular, bring some Product Owners onboard.

Now, I will be the first to admit that, at the time, the prospect of hiring staff and building a team scared the pants off me. I felt (and frequently still feel) I had absolutely no idea how to:

  1. Write a job description,
  2. Determine a competitive salary range,
  3. Work with our recruiters to find talent,
  4. Interview, hire, or onboard people, or
  5. Manage staff.

You know. Basically the entire job.

That’s not to say I didn’t have plenty of help from colleagues, managers, and mentors, but to say the whole thing was intimidating would be a profound understatement.

As a result, the plain truth is I dragged my feet for a long time before finally beginning the hiring process in earnest. And anyone in a similar position will tell you: being under-staffed is bad. Being under-staffed and under time pressure is far far worse.

Fortunately, just as I’ve traditionally fallen ass-backwards into success over the years, a colleague and mentor of mine basically handed me the perfect candidate on a silver platter.

As a random aside, you may have noticed I’ve been careful to avoid mentioning specifics in these posts, going so far as to avoiding stating the name of my company or individuals I’ve worked with, despite this information being easily obtainable. This is not for lack of pride in the company or those people. Rather, as this writing exercise is a personal one, I wanted to keep their names out of this, out of respect for their privacy.

My first hire was a woman who had been in the tech industry here in Edmonton for many years, having herself grown up in a successful startup and remaining through a number of subsequent acquisitions. Much like me, her background was originally in technology, but her natural leadership qualities lead her to positions of authority where, ultimately, she found herself in a Product Owner-esque role (it may have even had that title, though I honestly don’t recall and I’m too lazy to dig out her resume).

As a first employee, I couldn’t have been more fortunate. Here I had found (or rather, I had been presented with) a competent, mature, skilled, experienced leader who I knew could step into the role and run with it. To be perfectly blunt, in many respects she was probably better qualified than I was to perform the role we were hiring her into, which is the best any hiring manager can ask for!

This meant I could stumble through the hiring and onboarding process knowing that her own talents would likely compensate for any mistakes I might make along the way.

And to no one’s surprise, she has done incredibly well in the role!

However, there was a downside to her confidence and independence: It made it incredibly easy for me to neglect her while convincing myself I was being “hands off”.

In fact, it wasn’t until I had hired my second staff member, more then a year later, that I realized how much I had been shirking my duties and began to more fully commit to my role as manager and coach.

In the years that followed, the team only grew until, now, I find myself directly managing a staff of four Product Owners. In that time they’ve put up with me as I’ve tried to figure out what it means to be a manager and coach of a group of incredibly talented individuals.

In doing so, I slowly realized that managing staff is something I really enjoy!5 I can’t describe the incredible feeling of watching my team perform at a high level, knowing that I may have played a small part in setting them up for success. As someone who, for years, repeatedly told anyone who’d listen that I had zero interest in management and wanted to write code for the rest of my life, I could never have predicted where I ended up.

Meanwhile, if I’ve improved in my role, it’s in no small part due to some very close partnerships I’ve developed with a few extremely talented colleagues and friends (one of whom has, alas, found her own success elsewhere… I miss you!)6 There’s definitely a lesson there: middle management can sometimes feel like a fairly lonely endeavour, but it’s made a lot easier (and a lot more fun!) if you can find like-minded colleagues in similar positions with whom you can share help and support.

But it’s not just my own part of the team that has grown.

Over the years, my manager has also brought onboard some very talented additional senior staff, who share the responsibility for managing parts of the team while providing leadership in areas far beyond what I’m personally capable of. The result is we are now a diverse, incredibly talented group of fourteen people spread across three countries on two continents.

So, while we still have a long way to go7, it’s really remarkable to look back and see how far we’ve come!

  1. Which provides more context for why it was so important for me to figure out my leadership style early on, and also helps explain some of my early missteps: I was way over my head. ↩

  2. It’s also important to understand that we have traditionally built enterprise software deployed on premise. So forget continuous delivery. Think releases. You know, old school stuff! ↩

  3. As you can imagine, still I was working myself ragged, but manageably so. ↩

  4. And it’s still pretty fuzzy! ↩

  5. At least, when I’m not wracked with profound imposter syndrome, which these days is approximately 42.3% of the time. ↩

  6. In fact, I can, and probably should, write a post on the value of seeking out and developing partnership and mentoring relationships at work. I wouldn’t be where I am without those people. ↩

  7. I could go on at length about the challenges of managing the kind of rapid organizational growth we’ve experienced over the last couple of years… ↩