Says Tim O’Reilly:

I was in a meeting with the CIO of large financial firm a few years ago, and he made an important comment. He said something like "We don't need to know about new technology. We need to know how to change the company organization to take advantage of new technology." The organizational impact of new technology involves new skills, new job descriptions, and new ways of thinking about old problems. The job of "data scientist" didn't even exist a few years ago. Now it's one of the most important roles in a cutting edge organization.

The New IT Jobs

#SeedCamp Product Day finished up with a master class on community management from SoundCloud’s @David. David is a community manager, and another I know is GroupSpace’s @shevski, who first explained the role to me. Here are people working daily in roles which really didn’t exist a few years ago. Sure, there were related ancestor roles, but these new-breed community managers spend every working minute dealing with tools and experiences foreign to someone a few years ago.

There are new job titles which are creating competitive advantages for startups over their enterprisey counterparts. They are not postmodern titles from 1998 (“comptroller of nerfball”), nor are they stand-in titles (“director of e-marketing who is still reporting to the same boss in just marketing”). They aren’t wannabe-important titles (“local social media expert”) and nor are they zombie consultant talk (“lean theatre mouthpiece”). These new job titles are significant because they represent new areas of resource allocation in the industry.

1. Data Scientist

Combines skills from statistics, mathematics, computer science, business analysis, econometrics, product development

Data science has been explored in the following places:

ReadWriteWeb: Jobs for Data Scientists Explode Across The Market

Data Scientists Turn Information into Gold

Conferences. There’s O’Reilly’s Making Data Work conference, and O’Reilly have also been busy exploring data science. a Data Science Summit, GigaOm’s Structure Data .

Data science is about dealing with “big data”. Recording all the info, because it’s so cheap to do so, and mining it later on to gain insights. There’s a big component of technical know-how involved in scaling operations, taking advantage of elastic scaling, NOSQL data stores, and optimal algorithms like map-reduce. It’s also about interpreting the data to a useful end. A great example is Google Flu Trends, where Google discovered its search data could predict an outbreak of influenza 1-2 weeks before authorities detected it!

Big data doesn’t have to mean big company. Lately, I’ve been focusing on the world of lean startups, where optimisation and validation is the name of the game. In particular, a obsession with data-based experiments, often in the form of a-b tests. Any entrepeneur worth their salt can have a crack at it, but for serious optimisation, an expert is needed. A data scientist. Even 37Signals, the flagship brand of the lean Software-As-A-Service model, now has a data scientist on board. And look at the results of their recent A-B tests. The data scientist role has certainly paid for itself.

2. Developer Relations (Developer Advocate, Technical Evangelist, Platforms Manager)

Combines skills from programming, marketing, technical support, and public relations

Using its related name, “Developer Evangelist”, you can see how this has risen over time:

This would be the role I know best, being that which I worked in at Google, and also at Osmosoft although it wasn’t my job title and I didn’t think of it that way at the time.

There’s a big fat head and a very long tail of platforms out there, which developers can tap into. At the top end, they are 800 ton platforms from 800 ton players. Microsoft’s .Net platform, Google’s Android, Apple’s iOS, Amazon’s elastic cloud, Facebook’s Connect, Twitter’s OAuth. These guys pump {m,b}illions into their platforms and are betting on adoption. In the middle, a boatload of APIs where you can access news, send text messages, and stream music. As well, there are developer-facing tools like IDEs and hosting. And in the glorious long tail, there are open source libraries, novelty widgets, even ahem RESTful random number generators.

The reasons for wanting adoption certainly vary. Some companies charge developers a fee, so the effect on bottom line is very direct. Other companies receive indirect benefits, by way of improved adoption of their core services. Apple and Google both want adoption of their mobile platform because - for all the talk about screen sizes and home screen capabilities - apps are arguably the no. 1 decision factor when customers choose a smartphone. People will buy a phone on the basis of it having a single app. Conversely, try selling a modern smartphone without a Facebook app. Good luck with that.

Whatever the business model, one thing is certain: Where there’s a major platform, there’s a company who wants people to use it. And this is where developer relations comes in. Developer relations has several components to it. Evangelism is the most obvious - “sell” the platform’s benefits. This can be done with great demos, especially those from third parties. Also with captivating data about the benefits developers will derive - promoting the market size, ease of implementation, etc.

But evangelism is a blunt instrument. These days at least, you have to treat partners and customers as intelligent entities, so developer relations is much more than evangelism. It’s also about advocacy, which means advocating for the developer, not just the boss man. This means partnering up with developers to produce demos which will not only excite other developers and users, but will also inform and evolve the product. That is, it’s a two-way relationship, and a solid developer relations programme pumps as much information into the organisation as it pumps out. It doesn’t happen much today, but devrels should ultimately be owning And there’s also a straight-out technical support component - supporting the long tail development community online and at events. For this reason, sourcing developer relations folks is a challenge.

“Developer Experience” is where this is headed in my view. Overall, DX is User Experience applied to developers. A holistic way for platforms to say to their developers, “what do you want to do and how can I help you kick major butt?”. The future of this role is “Developer Experience Manager”. To quote someone who knows devrel inside-out:

It’s true that a fertile market will always drive developers to it, even if the developer experience is poor. This logic is backed up empirically; Facebook recently won the dubious “Worst API” award, and we know that didn’t stop a gazillion agencies and farmville wannabees jumping on board. Even so, they have a big push on to improve developer relations, as evidenced by 9 (at present) job postings under “developer relations”, increased presence at developer events, and their very cool new integration with StackOverflow.

I’ll close this section with an expert opinion from a leading software company about the importance of developer experience. No, really. MS may have pissed off a dev or two, but back in the day, they worked tirelessly to make the platform developer-friendly, and a giant universe of applications was a key ingredient in their rise to the top.

3. Community Manager (Customer Relations, cringeSocial Media Expert)

Combines skills from product development, public relations, and tech support

This is a new role for most companies, but actually a very obvious one when you consider the enormous amount of user-generated content and conversations surrounding any popular product or service. You could draw its roots in the Cluetrain Manifesto. Markets are converastions, whether companies like it or not, and they need to take part in the conversation.

@David’s done a great job explaining the role in his talks, and a few key points are: being authentic (acknowledge problems), help the user community be part of the growth story, go where the conversation is (Twitter, offline, wherever…not just the corporate sandbox). It’s somewhat paradoxical that this role exists at a time when individuals inside a company are more transparent than ever (another Cluetrain phenomenon). But the reality is that the sheer volume of conversation is overwhelming for people who have a job to do.

A lot of this applies to developer relations too.

Are We There Yet?

Of course not. Part of the fun of this industry is the dynamic nature of roles and processes. These roles will be old hat in 5 years and there will be a ton of new ones for companies to take advantage of. Just for fun, some speculation:

• Code Mixer: A “developer” who doesn’t build fresh code, but patches together products by mediating between open source products (GitHub) outsourcing websites (eLance), contest websites (99Designs), and component distributors (themeforest).
• Software Archeologist: An investigator of corporate and open-sources code corpuses, with the aim of discovering principles, patterns, and metrics. Not a new concept, but one that will gain momentum thanks to the “big data” movement described earlier. Listen to this StackExchange podcast about the topic, and read this book. “Joel requires that you read this book, because its the first one to take a scientific approach to making software as opposed to the subjective and anecdotal way that most have in the past”.
• Information Visualiser: There’s a proliferation of data about how a company is performing, be it a/b test results, continuous integration builds, or real-time social conversations. Tools are starting to emerge which can deal with this complexity, but these tools need to be combined and configured in ways to meet the companies needs. Sure, there can be individual tweaking, but someone needs to take responsibility for the overall platform and provide sensitive defaults and guidance. Developers will certainly want different dashboards from CEOs, and don’t get me started about the information needs of Data Scientists, Developer Advocates, and Community Managers!

What other weird and wonderful jobs are you seeing, or you think we’ll see in the future?