About two years ago I decided to move from product marketing to a development team to ship something (at the time I was a bit vague on what exactly I’d be shipping, but it eventually clarified to become Popfly). Crossing over opened my eyes to some cultural differences and misunderstandings that marketing has about the development team and the development team has about marketing.
One observation that struck me sharply is the difference in how development teams view schedules and process.
Development teams think in terms of schedules and there is an understood art/science to development process. In addition, development teams have a culture of managing their work (bugs and tasks) in a shared space (like TFS), and progress can be measured pretty concretely by many metrics (bug debt, test pass rates, code coverage, etc.). In the case of big projects like Visual Studio, the schedule can be set months (or even a couple of years) in advance with a degree of specificity about what individuals will be doing at different phases that is pretty amazing. Further, a release management team can determine whether a team is on track or not based on defined metrics.
Marketing teams often move much more fluidly. With the exception of large events like a Tech Ed or a launch, which require pretty sophisticated event logistics, much of marketing work can be opportunistic (e.g. you happen to get an invitation to speak at an event next week so you take it, or a partnership gets signed). And some marketing work such as messaging or naming requires subjective input that development teams find utterly baffling (I think of all the “geez, that name sucks” mails I’ve gotten and sigh.)
This leads to one set of disconnects: development teams like to believe that they can track marketing teams as a set of TFS work items (or something like that). Sorry, but by and large that just doesn’t work. You really don’t know if a particular story will land in the press on a particular date, nor do you know if your partner deals will line up, and the person you’re negotiating with for that domain name might go on vacation for six weeks.
More importantly, marketing teams don’t generally have the culture of shared work item management that development teams use: living in a shared task list and submitting to team-wide (frequently daily) reviews of the task status. Sometimes this is because marketing teams operate in a much more disconnected fashion than development teams, so that a team of five product managers might be working on ten things that only tangentially touch on each other. It’s also because the overhead of such a process is not insubstantial — you need to spend time to update your work items, and it’s time that marketing teams (who are already outnumbered anywhere from 12:1 to 100:1) don’t feel they have. And finally it’s because it’s not part of the marketing “training” you get (if you get any at all).
As much as I dislike process for the sake of process, the rigor of sitting with the team each day even for just a few minutes, looking at our bug list and discussing any blockers does a huge amount to ensure that priorities stay aligned, that nobody’s surprised by that P1 work item that just came in, and enables us to load-balance work when someone is particularly overcommitted. It also enables us to say “on date X we’ll be done with this group of work and can move to the next set of things.” My friend Philip DesAutels once encouraged me to try something like a daily scrum with our marketing team; I never did, but now I wonder if it would have helped people understand more about what’s going on and actually help each other. I’ll leave getting marketing teams to work in TFS to another life, I think, but task management rigor isn’t necessarily a bad thing if its treated as a tool for load balancing and unblocking rather than a tool for abusing people who are behind.