Developer To Product Manager: Put The Kettle On

Filed in Racker Culture by Felix Sargent | September 13, 2013 12:00 pm

There’s nothing quite like a promotion to both stroke the ego and demolish one’s comfortable sense of security.

I had been a Python developer for a few years, but never felt as smart or as accomplished as my teammates. I was always learning, but never felt as though I belonged, or was playing towards my strengths. My manager pulled me into a conference room: “Felix, we need a Technical Product Manager. Are you interested?” “Uh… Sure!”

But the champagne celebration quickly turned into dry-mouthed realization: I had no idea what I was supposed to be doing.

I tried to remember what the product managers I had worked for did. I had told them what I was doing, but somehow I never had understood what they did.

The mystery deepened as I plowed into the popular management books and theories. Most of these texts provide only the most general suggestions. The authors call on readers to “align vision” or promote “cross functional synergistic development.” I could feel myself developing hives.

As far as I could tell, modern product management strategies such as Scrum, ExtremeProgramming, Kanban and others are all about communication. They’re ways for developers to provide feedback to their managers and the company. Scrum? That’s little more than a formalized way for developers to tell managers that they don’t know how they’re going to solve a problem. ExtremeProgramming? That’s a way for developers to do smaller pieces faster. Kanban? It’s all about doing one thing at a time and doing the most important things first.

But none of these things told me what I was supposed to do in my new role.

Maybe I was supposed to manage backlog. That’s what Scrum strategy dictates: “The Product Owner’s focus is to manage the backlog.” Finally, marching orders I thought I could follow.

But it’s so easy. I’m not bragging about my abilities, it’s just that making an ordered list of tasks just doesn’t take that much brain power. Especially when compared to the intricacies and multiple dependencies of coding. Can you make a list? Can you see that some things are more important than others? Can you put the important things at the top of the list? Great—you can manage backlog. I found it took less than 10 percent of my time.

I started to wonder, is that all there is?

After about a month of being a product manager, my boss and I had a one on one. My frustration had been building right from the beginning and I did what I could to hold it back during our conversation. Finally, I just blurted out: “I don’t feel like I’m doing any work!”

That put the brakes on the conversation, and my boss gave me a strange look. I’d clearly floored him with my admission and my career flashed before my eyes. I imagined him going straight to HR and revoking my promotion.

Finally, my boss regained his composure. He leaned forward in his chair, locked eyes with me and said: “You’re not here to do work. Your job is a facilitator. While everyone else’s head is down, you should be looking around.”

I immediately felt the confusion clear. With one sentence, he cleared a month’s worth of worry. I started to relax.

But I also started paying much closer attention to things like meetings. Meetings are, after all, the best opportunity to facilitate and to observe. For product managers, the daily “Standup” meeting is an opportunity to shine. The goal of the Standup is to understand how everything is going with each individual contributor, to anticipate delays and brainstorm workarounds. It defines the day-to-day pace of product development.

Unfortunately, they’re often painful, forced, time-boxed, stressful and aggravating. What’s the point of all these methodologies if nobody wants to talk to with you? If nobody’s talking, how can you listen? I struggled getting the “best practice” management theories to work in real life.

My team was frustrated too. They viewed the Standup as something that had to be endured rather than an opportunity to get help or share productive information. They started coming to me outside of our appointed time to gripe.

One afternoon, after a morning full of handling my team’s issues, one of my engineers came to me with yet another request. Admittedly, my brain was fried. I was tired of being the conduit for everyone else’s issues. I needed a reset.

I’m English, so when 3 p.m. rolls around it’s tea time for me. Good tea is both calming and invigorating. It helps clear my mind and set me on a productive path for the rest of the afternoon. I invited my engineer to join me for a pot of tea and we started discussing the issue he’d brought to my attention.

We moved from our company kitchen to a set of comfortable couches and talked candidly about the issues. Others wandered over, listened in, aired their own opinions and started solving problems themselves. I poured more tea and put on another pot. As my team talked, I found myself hearing them in a new light and finding opportunities where I could make their work easier for them. Sometimes it was as simple as clarifying priorities and helping them understand deadlines. Other times it meant working with others in our organization to better use APIs or integrate code. When my team felt comfortable sharing, I found my purpose was clear.

For us, the key to a good Standup meeting was to sit down. When we created a comfortable environment where people feel as though they were taking a break rather than being pulled away from their work or forced to report. We’ve been doing regular 3 p.m. “Tea Time” Standups since then. My co-worker, enamored with it, wrote a blog post[1].

I gained confidence from breaking the mold of prescribed software development methodologies and embracing a more relaxed environment. It’s a different kind of “doing” than what I did as a developer. Now I listen to my team and make things easier for them, and they comfortably make our products better each day.

  1. wrote a blog post:

Source URL: