A good program manager (PM) is imperative for making really good software products.
In Toyota, they have this role of Chief Engineer. For those who don’t know, Toyota has been the fastest growing car company most of the time since the 1950’s, and apart from having technical excellence in their product, they credit a lot of this to the role of the Chief Engineers. The Chief Engineer is a guy that would embed himself with potential customers of the new design. If he were to design a car for carpenters, he’d put on his carpenter pants and get all carpenty. Usually he’d discover a lot of design details needed a carpenter. Stuff like double (or triple, or quadruple) coffee holders, a flat dash-board for throwing documents on and to write upon, doors that swing up really wide, to expose the sound system speakers to the outside workers, and so forth. Basically a lot of stuff an office rat, or a technical engineer wouldn’t dream of.
This approach, combined with the excellent technical quality and their unprecedented production effectiveness, created a lot of success for Toyota.
We’ve chosen the little more cheesy title “Program manager” for our Chief Engineers. We like cheesy, because it’s so cheesy. (Actually, people don’t like it).
With 7 people and 3 products, (Aptoma anno 2010) everybody is a PM. And everybody is a developer. And everybody is a janitor. And so on. The lines between developers, visionaries and managers are as blurry as they should and have to be. Everybody is taking turns doing anything, and this is part of the fun of being in a small company. Great stuff.
It doesn’t scale.
We’re now 13 people in Aptoma, 10 of which are developers (and we’re looking for more talent). With more customers and products, development and maintenance gets increasingly complex, both in coding and in managing. And so we need more focus time on development and on program management as two different, but mutually dependent, exercises.
We now have established formal program management for two of our products (front-page editing, and article- production and layout) and one for our elastic cloud services (streaming, hosting and video transcoding for the media industry).
What Does a Program Manager do?
In short, there are five main responsibilities to the PM.
- Serve as the customer advocate
- Write functional specs
- Keep track of progress
- Hold team reflections.
- Maintain road-map.
- Remove obstacles for the team.
Seems so simple from the list above, but there is a lot to this role.
1. Serve as the customer advocate. In order to serve as the customer advocate, you need a lot of information about what to advocate. You need to talk to users, you need to empathically understand them, and you need to dear to expose yourself to irritated users having problems. And you get to talk to those that are really, really happy and has had the time to reflect and envision new stuff. We aim to do this a lot for the same reasons that the Chief Engineer do in Toyota. This can be done by checking in at the customer, and saying “what’s up!”. Sounds easy, but the tricky part of this is that if you have a crappy product, they’ll only tell you about how crappy your product is. So get your bug-list to zero first. As such, the PM has to coordinate input from various sources, and streamline this information to use it to advocate the customer needs to the rest of the dev-team.
2. … and that’s where the functional spec comes in. Based on the deep understanding of customer needs, the feedback from support, from developers, from just about anyone with a stake in your product, the PM will propose changes, often through a written functional spec. The functional spec will describe an idea for improvement or extension to the product. If the functional spec contains wire-frames (in HTML, or just drawings) it can even be tested on potential users for early feedback.
3/4. Keep track on progress, and hold reflections. Once you say GO to a great development team, they will go into ‘get-shit-done-mode’, and won’t stand for any interruptions. That’s why the PM is keeping noise away from the team by being the customer proxy, gathering input, writing the next functional spec in parallel. And if anyone is to know anything about what is going on, someone must have the job of saying “Hey! How are things going?” and “Hey! Do you have what you need?”. Developers in ‘get-shit-done-mode’, will first bite your hand off, but everybody appreciates to pause and reflect from time to time, and to be able to report achievements.
5. Maintain roadmap. This is the wet dream for every bureaucrat. The internal road-map needs to contain information about technical challenges, resource availability, timing, deadlines, suggested and affirmed projects and so forth. Someone needs to coordinate all this. Presto!, the PM is there to help.
So how did anyone in Aptoma find the time for all of this when we didn’t have formal PMs? They didn’t. But these things just kind of works, to a point, when the company is small. We’ve exceeded this limit now, and this, our first small step towards dev-teams’ separation of concern is here.
6. Remove obstacles. The PM will, by nature of the role, gain overview of the work flow, and during reflections get insight into obstacles that are holding the team back. This can be recurring problems, communication challenges, and so forth. The PM will work to remove such obstacles, to make work flow smoothly.
Boring maturity. We have to fine-tune this role for it not to become a boring formal meeting process. And we need to acknowledge that we’re not Toyota. Yet. We’re still a very small company, and a lot of people do a lot of different stuff. A job description any cleaner than your average pile of laundry still does not exist at 13 employees.
Conflict of interest. There’s been internal developer outcry for PMs for the last few months. And as expectations are high, it might be natural to think of a PM as a silver bullet “Ah, nice, here comes someone to do all stuff that is boring to me, so I can do only the fun parts. Woho!”. Chances are, however, that some work is fun for both PMs and developers. As such, fun vs. boring is not a well defined separation of concern. For separation of roles to work, one has to consider intellectually (what works, and what does not), as opposed to just consider emotionally what belongs where. The goal is better software and services for our customers, we must keep in mind.
Loss of agility. If the PM (the bureaucrat that he is) goes all-in on on functional specs, and basically tries to solve the entire problem of creating new functionality/products there, this might lead to over-planning causing unnecessary delays and loss of agility, innovation and flexibility. Knowing programmers quite well, I’m quite sure he’ll get a friendly (or even hostile) kick in the butt if this occurs.
- More time for developers to focus on development.
- Deeper empathical understanding of our customers needs.
- Better and more holistic planning; one guy gets access to all the input and sees the whole picture.
- Better coordination to strategy; PMs will report to the director, which makes it easier to provide feedback on direction, and to fine tune strategy.
What We Aim to Preserve
- The autonomy of teams; As the director gets higher quality reports, and as planning gets well managed, it might be tempting for top management to mingle more and leave less decisions to the team. This can be harmful.
- Developer ownership of ideas; The point of program management is not to shield the dev-team completely from information and customer concerns, but to structure and wisely involve at the right time. It’s a balancing act.
- A peer team-structure; PMs don’t need ties. They’re embedded in the team. Authority comes from professional and personal qualities, not from formalities.
PS! I say “he” not because we don’t think women can be great developers or PMs, but because this is a note about us. All PMs and developers are still men in this hot dog shop. Don’t let that scare you from contacting us, if you’re a woman.