New People
There’s a lot of excitement when someone new joins a company.
For me, much of that comes from gauging the success of our products and associated halo to that point (docs, marcom, etc…). If someone fresh can figure out what it is we do, and what our products do based on our standard messaging and documentation, we must be on the right path.
The other element associated with this is, how should things be changed to make them more clear? What would have prevented the new hire from being confused? How can the materials and explanations be presented in a clearer way the next time round?
Chances are, if a new employee can’t figure out your products, your prospects and clients are having a hard time understanding them as well. Leverage the new resource to determine what can be improved and go forward from there.
Releases with QA
My release cycle does not include a serial QA pass. What I mean is, I don’t block out 1-2 weeks after a “code freeze” to do QA; I want QA being done while the developer’s mind is still fresh on the code and they haven’t already moved on to something else.
A typical release cycle for me will see a QA lead create a test plan for what’s going out the door, and then work with the developer (or dev lead on the project) to cycle through any found defects. The QA test plan is captured directly from our defect tracking system, which is where I log all requirements for a release.
This helps us in a couple of ways. The first being, no one is sitting around waiting for QA to sign-off on a release. The second is development & QA are directly engaged, and talking about the release so defects can be fixed faster. There’s no cycle time between when QA ends and when fixing any bugs they have found begins.
I’d always recommend looking at what happens when you encounter a code freeze in your release cycle. Are you doing all that you can to ensure the process of getting high-quality product shipped as fast as possible?
Brief Notes on Scheduling
Dev scheduling, and scheduling in general, plays quite a big part in my day-to-day work. Everyone comes to me for dates, estimates, status, release details, etc…
So, how does one go about it in a startup without going totally crazy? Well, by avoiding getting sucked in to the details, of course.
I’m really all about macro-level views. I like to keep things fairly hands-off, but know enough about what’s going on that I can provide guidance / assistance when required. The other benefit to doing things this way is, you can handle a lot more because you aren’t trying to manage all of the sub-tasks that sit below a milestone, but you can start to drive communication / efficiencies cross-functionally, which is also a big part of being a successful PM.
There’s an underlying theme with this that I’ve been told a few times by people way smarter than I’ll ever be: if you control the information, you have some degree of influence. I still have to think about everyone creating and sync’ing schedules and how to manage that in the sense of getting folks the right information in a timely manner - helping them execute where I can, and actually executing on your own stuff.
Part of the fun in all this is that no one group in an organization will handle schedules the same way. But of course, a PM needs to get team leads / project leads that are working on release-specifics, on the same page so it can all come together.
It’s a lot of fun, to be sure.
Headed to SXSW
I’m off to SXSW in Austin, TX on Tuesday. If you are going to be there and want to meet-up, send me a quick email: adam [at] musicip [dot] com. I’ll be town from Tuesday through Friday for the entire show.
MusicIP will also have a booth on the floor, so feel free to stop by and see us!
