Month: February 2015

Note: I wrote something work-related, after years of silence in that regard! Revel in the novelty.

Having read and considered the three recent articles on the lack of innovation in the digital asset management space, I can only agree that there are certainly issues with vendors, chief among them being the lack of standards, and it starts at the most basic level of simply describing their solution’s basic function. Major Vendor A can call their solution 'digital asset management' while Major Vendor B uses a broadly similar tool for web content management, but they can each easily swap labels if that's what the customer thinks they want, perhaps because they don't have anyone with real DAM expertise on staff to dig further into what's on offer.

And that goes to the core of Jeff Lawrence's article - customers aren't demanding clarity, much less innovation. It's almost depressingly common in our field to discover that the only person in an organization who truly understands how DAM works (or, perhaps, how it should work) wasn't involved in the purchasing decision; they've often inherited something that wasn't truly fit for purpose, and they don't have the budget to do much about it now. But if the customer does not budget for enhancements or new systems, vendors can't be expected to pay particular attention; understandably, they've moved on to selling their existing solution to a new client. Yes, new features may roll out if that bigger client demands more attention during the implementation phase, but after that, the feedback loop unravels.

But standards are again top of mind in Ralph Windsor's piece on the role of the media; his points about the truly alarming lack of metadata knowledge give one pause, and the difficulty in measuring ROI certainly takes time away from crafting the perfect taxonomy model. Some DAM vendors have clearly given careful thought to the role of taxonomy and metadata, and considered how users, both administrative and end-user, might interact with that metadata (even if they don't know they are doing it). But that's not true across the board, and if DAM enhancements have fallen to someone who lacks experience in that space, it's difficult to move forward true functionality improvements, since all DAM functionality flows from useful, well-managed, metadata.

And while we 'know' that the DAM saves money in the long run, demonstrating that to those who hold the organizational purse strings isn't as easy as it should be. This can prove a particular challenge if the team (or, let's be realistic - person) running a DAM is that rare IT unicorn with a combination development/project management/taxonomy background; suddenly they also need to become an expert in presenting on their program's successes and challenges to senior management. While that's a great career development opportunity (and you may detect the voice of experience here), tools within DAM software should make getting to that supporting data simple.

To summarize, my view is that there is a lot of truth in each article, and it's something of a vicious circle. DAM vendors (or vendors that have decided they have a DAM solution, even if it's far from best of breed) aren't incentivized to innovate because the clients don't demand it. Clients don't demand it because they have systems that can be difficult to use, and therefore hard to build a business case around further improvements when they've already spent their initial budget - not infrequently on the 'wrong' system, so they are essentially starting from scratch again when they can afford to 'go shopping' once more.  And much DAM media is so internally-focused that the 'right' people in organizations that need DAMs don't even know it exists. It seems that one solution would be for DAM vendors to seek out long-term DAM managers and librarians for product management roles - people who live and breathe the tools, and who understand the importance of standards – to really push the next generation of DAM solutions.

And as DAM professionals, we also need to keep the conversation going with our vendors; it's not always easy, and there isn't always a response, but keeping quiet hasn't helped so far. Let's get loud!

This post also appeared on Medium.

A bit of background is in order: I fell into my first coding job in 1996. I was meant to be working on my MA in archaeology in London, but I discovered that HTML, even back in those days before tables, offered a sense of instant gratification that is often lacking from the humanities. I duly emailed my (then very brief) resume to Time Out magazine in response to an ad seeking a Web Assistant, and that was such a novel approach that I was hired on the spot. From there, I bounced to Silicon Valley, turned down a job at Yahoo that would not have paid enough to live on, stock options notwithstanding, and spent the next several years at Women.com, where I quickly rose to the heady heights of Web Production Manager.

While I did work with a few men, unsurprisingly the company was nearly all-female, and even when other companies tried to headhunt me (something that happened all the time to everyone in the late '90s/early 2000s, presuming you had a pulse, basic HTML and Javascript, and an ability to navigate 101), most of the development teams I met with were largely female. Sexism never crossed my mind back then; the only faint flicker of an 'issue' was on a night out with some fellow techies. One complained that 'all the good female coders get swept up into management,' and I was taken aback — wasn't that the goal? I enjoyed working with code, but I didn't plan on doing that forever — I also liked managing people (though it was less pleasant when they were pretending to be sick or were otherwise not especially interested in their jobs) and projects, figuring out if a vendor had a good solution, writing here and there, and translating what my team did up to the c-level. In my mind, being a coder was a foundation for being a good tech generalist, which was what could (I thought) propel you up the hierarchy. It hadn't occurred to me that some people simply loved code, and that there was an attitude among some of them that women who started in code but moved on were somehow letting the side down. I filed it away as an interesting point of view, but not one that would be terribly relevant to me.

Then the dot-com crash happened, and things began to change.

It's certainly true that many of the pre-bubble companies, including some I worked for, could have been more strategic, less spendy, and generally more thoughtful in how they did their business. But it also seemed that hands-on experience in being a part of the building of those companies' products became less important than having a freshly-minted MBA, and the men in suits — and they were largely men — swooped in to pick over what was left. One of my former colleagues, who had been at the company much longer than I had, said she felt the experience of the boom and bust had been like getting an MBA in how not to run a company, and I fully agree, all these years later. With tech jobs becoming harder to find, many friends and colleagues went into other lines of work, and I found myself a minority, along with my fellow female tech holdouts. I took jobs that were a few steps below those I'd had during the boom, but assumed that would be a temporary step back -surely, the market would improve and I'd be back where I'd been at the age of 24. It was around that point I realized that while I often still had female managers, that was as high as things went on the tech side. There were women executives elsewhere in the companies I worked for, but they tended to be in marketing, HR and other roles. Somehow, the lady nerd pipeline stopped at middle management.

I ensured I still had as many strings to my bow as possible: true, I did less coding, but much more project and program management, more writing and content strategy, more taxonomy, more going to conferences, and spent a goodly amount of timing thinking about what I wanted to be when I grew up. Social media and even its mainstream cousin began to fill with stories of women in tech being either subtly passed over to outright abused (online and in person), and that became one new reality. On the flip side of that, high-flying women in tech of the Sheryl Sandberg- or Marissa Mayer-variety were trumpeted as success stories. But for those of us somewhere in between, there was no real acknowledgement of our experiences, nor a clear pathway to get from the middle to closer to the top. There are a lot of possible lateral moves, but unless you want to found a new company — and more power to you if you do — it's hard to get to the c-suite, or even just below it. And the women who do make it there often came from a less technical background, though I'd argue that your MBA won't teach you as much about how to choose an enterprise software solution nearly as effectively as living through trying to integrate the wrong one. That's not to say, as some might, that they don't belong there; anyone can learn to code, but learning to be a good writer, people manager and politician can be a much trickier road. That said, it still seems that comparatively few women who started off in the lower rungs of the tech world, whether that's valuable experience gained doing tech support or writing code, are getting to those top-level positions.

We're told we don't 'do' enough — we should 'lean in,' we should speak at conferences, we should go to hackathons, we should give back through programs that teach girls to code, we should be mentors in our workplaces — all while doing our day jobs, continually learning more skills on the side, raising families and occasionally sleeping. These are all positive things, but one wonders if men are held to the same measuring stick; I know very few men who do all of these things, yet they seem to keep rising in the workplace without all the 'extras' — yet they often seem to be prerequisites for a female tech leader.

And tech is perhaps unique in that it's possible to earn more money in a 'lower level' position; I am constantly reminded by recruiters that I could be earning considerably more as a developer than in my present role managing developers (among other things), and while I still enjoy breaking out code from time to time, I like flexing other muscles more, and I'm very well aware that in many coding languages, there are people who are simply better at it than I am at this point. That may mean that I no longer pass the 'real coder' litmus test, which I find another irritating variety of the 'female fake nerd' straw woman, but it's equally important to have someone in the middle who can see All The Things. And if I can still call out a vendor who claims there's no solution to a problem when I found it in five minutes on StackExchange, so much the better.

But the question remains — how can we 'upper middle management' tech women get beyond our current levels (understanding that there's already a huge amount of privilege and opportunity that is simply unavailable to most people on the planet, male or female, but that's another essay), and into those CTO/CDO/CIO offices? Obviously to some extent you need to write your own ticket, and that's not a path everyone wants to take, but the mid-career ceiling seems to be less made of glass, and more of a Red Rover situation.

From my perspective, what's missing are the stories of women in tech who had a more varied path to the c-suite (or to whatever more senior role was their goal, understanding that goals can and do change) — those who haven't had the editorial-friendly ultra-rapid rise to the top, who weren't profiled in Wired, who didn't have a book tour, and who can help bring others up behind them along the way. There's nothing wrong or inauthentic about those who did have that experience, but it's not reflective of those who started off as worker bees and continue to keep the hive humming.

If younger women look at tech careers and get the impression that the two options are to either encounter unbeatable sexism, or that you'll have 'made it' by 30 (and that something is wrong if you haven't done that), we're doing a disservice not only to them, but to ourselves. Highlighting the other positives about tech — flexibility, a culture of continuous learning and experimentation, and a wide variety of potential career paths would be hugely helpful, and a more realistic view of the field, which is so often presented in mainstream coverage as a binary (see what I did there?) either/or.

If I've learned anything in nearly 20 years as a nerd-for-pay, it's that you make career leaps when someone tosses an opportunity you weren't expecting into your lap, and you're left to sink or swim with it. But as I've gotten further up in the world, fewer of those have come my way. I've had people assume I 'wasn't interested' because I was a parent (never mind that the man who got the opportunity was as well), and as managers who 'didn't realize' I had a hands-on tech background. While there is no road map for challenging these assumptions, and beyond the high farce of the dot-com crash and subsequent layoffs (oh, I have stories), the 'normal' career progression isn't an immediately exciting topic for a book, stories from women in tech who have had a career that trundled along nicely enough, thanks very much, would be of great value to others coming up behind them.

Want to share?