A few weeks ago I experimented with an unconventional approach to recruiting a technical web project manager. A lot of people were intrigued by the idea and I promised to write about my findings. The experiment is still going on but I am happy to report the intermediate results.
As a pure recruiting tool, results were mixed. Out of around 300 people who visited the form, I got around 40 successful submissions. Of those, there were 3 serious and qualified candidates. The rest were a mixture of developers (who didn't have enough project management experience), people who just wanted to solve the puzzle, and some people who were overqualified for the role. Sifting through the non-serious candidates was pretty easy. Many of these URLs were generic sites like Google or they had query strings letting me know that they were just curious about the puzzle. Personal websites and LinkedIn profiles were easy to spot and I enjoyed browsing those. I don't know how this stacks up against traditional recruiting methods but it was certainly less work on my end. I didn't have to read through boring résumés.
I didn't promote the form a whole lot. I posted about it here on my blog and I shared the post on Twitter, Google Plus, and LinkedIn. I might have gotten a larger sample size if I actively drove traffic to the form like, for example, if I posted a brief job description plus a link to the form on a job site. Some SEO work and Ad Words may have helped too.
As a screening tool, the form was excellent. Much better than expected. I asked all of the candidates that came through our traditional process to submit the form before talking to me. A lot of people totally didn't get it and I saved myself loads of time not having to read their résumés or interview them. The ones that did make it through thought it was pretty cool and I think it increased their interest in the role.
The biggest surprise was the professional networking element. I made several great connections with some of the non-serious candidates. In addition to meeting kindred spirits, I got to discuss interesting topics like roles and methodologies in web development and what it takes to manage an effective website. It was professionally refreshing to meet these people. I even met a Lionbridge co-worker from Poland and learned about some of the cool work that they are doing. He is a smart guy. I am glad I know him now.
In all, I think the experiment was a huge success. It didn't magically turn up the ideal candidate on its own but that expectation was probably unrealistic. Going in, I knew that this approach would only evaluate a couple dimensions (technical skills and web affinity) of a very complex and dynamic role. The "One Field Job App" didn't look at communication or organizational skills at all. But before launching this tool, technical screening was very time-intensive. In addition to saving time, I am particularly happy with the unexpected benefits of meeting new professionals and talking with old colleagues about this challenging problem. I will definitely use this approach to recruiting again.
I haven't read the book yet but the video has some pretty intense statistics. This may not revolutionize your content marketing strategy but it will certainly shake your confidence in the status quo. I hope this doesn't make executives snap to the reactionary decision of "we need to get on Facebook." It would be much better for someone to think "we need to deliver a product/service that people want to rave about." If you can do that, those customers will be gushing about you on whatever social network is currently popular with the customers you want to reach.
60% of the successful submissions were from Windows computers. 40% were from Macs. Nobody submitted from a Linux machine. I did get some Linux traffic though. Perhaps, the role was not interesting to these visitors. 14% of the site traffic was from iOS devices but I don't know if it is possible to submit the form from iOS.
For browsers, 75% of the successful submissions used Chrome; 25% used Firefox. I didn't get any submissions from Internet Explorer or Safari users. I am not surprised that most of the submissions were from Chrome and Firefox. The tools that you need to solve the problem are built in. But IE also has this feature. Safari comes with it but you need to enable it.
When you include traffic to the whole site (which includes the form), the breakdown is as follows:
Browser
% Visits
Chrome
53.16%
Firefox
13.92%
Mozilla-compatible agent
13.92%
Internet Explorer
12.03%
Safari
5.06%
Android Browser
1.90%
IE and Safari users were hitting the site, they were just not willing or able to complete the form. There are a number of hypotheses that could explain this.
The profile that would be attracted to solving this puzzle would also be the type to install a browser of his/her choosing rather than use the one that came with the operation system. I will leave it at that and skip the value judgments :).
Internet Explorer users are surfing from work and wouldn't want to be seen applying for a job. Of the IE users, 58% were on IE8 and lower. That might be a clue that people are at their work computers.
Internet Explorer users are all happily employed and wouldn't even consider applying for a job.
The data sample is not big enough to make any conclusions. We are in the early stages of this experiment so I don't have a lot of data. I will keep it running and see if anything changes.
As usual, I am interested in hearing your thoughts here in the comments or on the social web.
I have been spending enormous amounts of time filling this role for a technical web project manager. Most of the candidates that I have interviewed are not web savvy enough. I couldn't see them adding more value than assigning tasks and updating status reports. To be effective in this role, the candidate needs to understand how web pages work, be able to problem solve, and help educate our customers on the nuances of maintaining effective websites. Most of all, the candidate needs to love the web. I mean, really love it. In addition to all that, there are the standard PM responsibilities of keeping track of issues and workload management.
After sourcing candidates the traditional way, I decided to take an unconventional approach. Rather than make the job application process easy to increase number of applicants that can later be filtered (by me), I created an experiment to filter up front with this simple job application form. The form applies three filters:
You need to have a presence on the web — some URL. It could be your blog or personal site, your Twitter profile, your LinkedIn profile, Google Plus, about.me, flavors.me, Facebook… This shows that you are interested in the web and are participating.
You need to be curious. It is not immediately obvious how to submit the form. I know a lot of people will bail and prefer the conventional route of pumping out résumés and job applications. I want a problem solver who looks for a clever solution.
You need to have web skills. The solution requires that you know your way around your browser's developer tools and can diagnose a web display issue.
Successful form submissions get sent directly to my work email. Anyone who meets those three criteria deserves my careful consideration.
I have floated this idea by a few colleagues. Some people love it. Some are skeptical. I have no idea how it is going to turn out and that makes it a perfect experiment. The only challenge is to publicize this as much as possible so I can have a statistical sample. If you are curious about this approach too, please share this blog post and the application link: http://liox-web-pm.appspot.com/. I promise to share the results even if they stink.
If you are interested in the job, good luck with the application!
But, as with websites, this really isn't about one mode of travel being the "right" one is it? If you're just out of university backpacking around Asia, then sure be spontaneous. If you're single traveling on business, then take advantage of features that might not be worth it to the backpacker (like taking a taxi ride straight from the airport to hotel, rather then a series of public transportation that might make sense when backpacking). If you're traveling with a family, then maybe a more planned approach with less stops makes sense. But the point is that there is no single "answer" to the best way to travel, like with websites.
David makes the point that the supporting organization has to adapt to the needs of the website. Some companies transition more proactively and gracefully than others. In the post, David mentions "subsites" as added complexity. I think this is interesting because many organizations look at subsites (marketing landing pages, campaign pages, product sites) as a way to escape the complexity of their main site. It's a little bit like a weekend get-away without the kids. But over time, these subsites become part of the overall web program's complexity.
Not long ago, I wrote a post called Planning for Localization to give tips for enabling internationalization even if localization is not part of your initial launch requirements. As I mentioned before, internationalization is one of those requirements that gets de-scoped with much regret later on. How bad is it? In my experience, enabling internationalization post launch is often a non-starter.
The work involved breaks down into 4 categories:
Presentation template localization. Swapping out static strings for references to resource bundles or creating language-specific variants of templates. The level of effort depends on the number of templates and the extent to which they have static text. Text within images is particularly bad because finding the source files can be a real challenge.
Repository re-organization. There may be some work to re-organize the content hierarchy. For example, you might want to drop the primary language down from the root node to make room for other languages. This may affect the URL structure and you might need to do URL rewrites. Different platforms have different strategies for handling multi-lingual content. In the best case scenario, every asset has the built-in capability of being multi-lingual. In the worst case, the repository doesn't support internationalization at all.
Workflow updates. This is work to update the workflows to add steps for localization or triggers to instantiate a translation workflow when the asset in the pivot language changes. There is also an organizational aspect here. Often you need to have someone with both the language.skills and access to the staging area to preview localized content before publication.
Language fall-back logic and other multi-lingual configurations. This is kind of a catch all for any type configuration that you would skip on a mono-lingual website and only do for a localized website.
I asked around my network of systems integrators for their experiences and they are consistent with mine. Several of my colleagues said that an internationalization retro-fit often costs as much as a complete do-over. That can be in the $200,000 to $400,000 range. You might also need to add another couple hundred thousand dollars to license a new WCMS if your current platform doesn't have strong internationalization support. Others came in a lower worst case scenario of around 50% of the initial implementation cost. Of course, the level of effort depends on the size and complexity of the site, the native internationalization capability of the platform, and the number of internationalization corners that were cut in the initial implementation.
The problem is that you don't really know the extent of re-work involved until you start the project and dig into the code. Sites that have been around a while often have functionality or display templates that are rarely or never used. You still need to internationalize them just in case. Also, if you are working with a new systems integrator, they need to assume that the initial implementer didn't know what they were doing and buried stinky code all over the place. It's a bit like when you open up a wall for a small home project and you realize that some serious structural problems need to be addressed before you do anything else. So any fixed-bid proposal is going to be based on a worst case scenario of having to do extensive refactoring.
The systems integrators in my network have started to plan for internationalization in all of their projects. They ignore their client's request for a U.S. English-only website because eventually someone is going to realize the market potential of U.S. Spanish or opportunities for global expansion. If you are building a new website, make sure that your systems integrator thinks this way. If you are considering internationalizing your mono-lingual site by adding a new locale, the most practical solution is to deploy a translation proxy, which hosts the translations outside of your website. This means that no retrofitting is required and you can avoid all of that expensive and risky rework.
You go to a site and get blocked by a dialog box that encourages you to download their app. When I click on a link or type a URL, I am sending a pretty clear signal that I want the content that is on the other end. I am not looking for another app to install.
If you want to promote your app, use a banner ad slot to make a subtle suggestion. Don't put up an interstitial that breaks the flow. A few sites do this nicely by putting a small floating tab on the bottom right of the page.
Dialog Boxes
Speaking of dialog boxes, don't put them on your mobile website at all. If you feel like you need a dialog box, make sure to design it for mobile by making the buttons extra big. Those tiny x's in the corners just don't cut it.
Flash
The writing has been on the wall for a long time now and, now with Android Jelly Bean dropping Flash support, there is no denying it. Flash is dead on mobile. Don't use it — especially if your site is for a restaurant or any other destination for people on the go.
Disjointed Mobile/Full Experience
If your content is any good, it will be shared between users on all sorts of platforms. Someone might first encounter the content on a mobile device and then want to continue reading on the full experience. To facilitate this, make it easy for a user to jump between content views.
Astute observers of this blog have probably noticed that I redesigned the site. Being someone who agrees with Lou Rosenfeld when he says Redesign Must Die, this wasn't as capricious a decision as it may seem.
So why the redesign? Two reasons really. First, since joining Lionbridge this site is no longer for selling consulting services. It has gone back to its roots as a blog. I wanted to move away from the Content Here, Inc. company branding and get it back to a personal blog. Second, and more importantly, I wanted to experiment with adaptive design. Over the past year, a growing proportion of my traffic has been from non-desktop devices (phones and tablets). Reading the site was rough on a little screen. And that plays into a larger philosophy of minimalism — keeping as little as possible between the reader and the content.
As an experiment, I downloaded a very basic theme (Backbone) and didn't customize the code at all. I just played with the configuration options. I also benchmarked the site using Sitebeam, which applies 40 tests. After a bit of tweaking, I was able to increase my total score from 5.6 to 6.9 out of 10. The greatest improvements were in accessibility (from 6.0 to 7.3) and technology (4.6 to 6.0). There were also improvements in the content and marketing categories (see screenshot).
It remains to be seen if these scores reflect real usability and utility improvements. Anecdotally, I think the mobile version is much better. The content stands out and is easy to read. That was the result that I was going for. More importantly, I want to hear from you. Please provide feedback in the comments, Twitter (@sggottlieb), or Google Plus.
I was just thinking about the recent AWS outage and came to the conclusion that infrequent events like this probably help Amazon. While the first wave of response is usually criticism and doubt, the end result is probably increased adoption. Here is why. I don't think that events like these are chasing anyone away from the cloud. The reality is that technology occasionally breaks — especially under extreme conditions. No matter where you have a data center, bad events are going to happen. I was just talking to a friend who works in the Baltimore area and their self-hosted site has been down for days due to power outages. When people take a close look, they realize that most cannot provide better availability than cloud computing resources.
Rather than abandon the cloud, I expect that most customers will do what I found myself doing: the opposite — increase their cloud investment. If they were in one availability zone, they will expand their cluster to get into multiple availability zones and even multiple regions (which I am doing). They will create warm standby servers to switch over to in the event of a catastrophic failure. All these changes increases their monthly AWS bill and leads to higher Amazon revenues. It's just like the insurance business. The best time to sell new policies is right after an unlikely disaster, which is also usually the least likely time for the disaster to happen again (especially when new controls are put in place to prevent it).
I have a site that was affected by the recent AWS outage that took out Netflix, Instagram, and Pinterest on Friday. I thought I was in the clear when I checked on Friday. But I when I checked again on Sunday evening, my site was down. The problem was that the database didn't come back correctly. Last night I went through the restore procedure and the restore tool has been stuck in process all night. After buying a support contract, I learned that it hangs when the backup is corrupt. All of the support documentation says to just wait it out. I am still working with support to get a good backup.
This is very frustrating. The only comfort is that sites much bigger and more important than mine have also been taken down. The news about those big sites makes it easier to explain the issue to my users. It definitely beats having to say that I did something stupid.
