Why Marketers Should Learn To Program – But Wait, There’s More
- Image via Wikipedia
A little while ago, Christian Buckley (@buckleyplanet) retweeted a link to an intriguing blog post from Scott Brinker (@chiefmartec) entitled Why marketers should learn how to program. Scott’s main points center around the idea that for Marketers to be truly successful these days, they should learn at least the rudiments of software programming. This will give them new tools to succeed in an ever increasingly technology-driven discipline. I was motivated to comment on Scott’s post and wanted to capture and add to my comments here as well.
Understanding enough about the other disciplines related to succeeding at one’s own discipline shouldn’t be important just for Marketing folks. As the pace of innovation and change in the workplace continues to accelerate, it has become more and more important to have people available who can straddle many different disciplines.
In the past – perhaps way back in the 1990s or so – we were used to building teams that had one person representing each discipline. The teams had fairly long lifespans and knowledge areas were sacrosanct. Crossing the lines was frowned upon. Each team member was on the team because they were in a certain department, had a specific knowledge area, or needed to be on the team for political reasons.
Today all that is less often the case. We need teams to coalesce, accomplish, and dismantle in faster and faster cycle times. By building those teams with fewer people who have wider knowledge spans, we can reduce the communication requirements and accelerate accomplishment, thus innovation. Fewer team members with wider knowledge spans is simply a more efficient way to operate. This is especially true because those team members are increasingly likely to be spread widely across geographies and may even work for different organizations.
So, maybe Marketers should learn to program, but Developers should learn good design, Designers should learn basic accounting, Accountants should learn about organizational behavior, HR people should learn something about Marketing, and so forth.
It’s yet another time in history where the “Renaissance man” ought to be in high demand, and therefore should be able to call his (or her, of course) own shots.
I actually have a hobby-site revolving around first steps for programmers. I think that people who want to be real programmers can find the resources they need on the web. It takes time though, to get a genuine foundation.
I wonder if some of the people looking for a little exposure are a little like someone who learns first-aid as an insight to surgery. I mean, there is a little overlap, but knowing how to bandage you can’t really second-guess a kidney transplant.
Does that sound harsh? I don’t really mean it to. There are some good introductory paths, and certainly they’ll be enriching, but I also see them as more a way to test the water than to gain useful knowledge.
As an aside “Processing” is a very nice accessible language for non-programmer types.
John:
I think it’s more about awareness than total skill. If I were going to have a kidney transplant, I’d sure as hell want to learn as much as I could in advance of it. At that point, I wouldn’t be a kidney surgeon, but I’d be useful in a discussion about kidney transplants. The same is true of cross-disciplinary teams. If we don’t understand anything about what each other does, then we can’t enter into the conversations as quickly or as competently.
M.
I think the things most valuable to non-programmers interacting with programmers come from the high level, and aren’t what you’d learn programming small projects.
The key is that a specification sets the programmers’ direction, and that changes to spec become increasingly costly as code is committed.
That matters far more than what the code looks like.
Maybe instead of programming some intro Software Engineering text?