May 09, 2013
Finding excellent technical people is a constant challenge that I struggle with every day. The traditional recruiting process of searching résumés for keywords has been broken for a long time. You need to use clever techniques like my "One Field Job Application" and engage in various communities to find people who are passionate about their craft and want to do great work.
Interviewing candidates is even harder than sourcing them. You don't want to waste anyone's time (including your own) but you also want to get a real feel of how someone works. Developers who work on large teams are particularly hard to evaluate because responsibilities are often ambiguous. It takes a while to learn that a candidate had a really mundane role on that very interesting project on the résumé or that he/she didn't have the professional curiosity to learn about what other people were doing.
Some recent experiences are leading me to believe that the ideal technical interview question is "Tell me about your setup." While the tools that people use may at first seem mundane and subjective, I am starting to believe that tools are a reflection of the attitude a person brings to his/her work. This theory was originally inspired by the site UsesThis, which contains personal descriptions of the tools that people use. The people that submit their setups are clearly passionate about their work and pay attention to the details. Most importantly, they identify with their work — and that is critical to the type of commitment that leads to greatness.
I am not so interested in what the tools are (although I am starting to see some interesting patterns that I might share in a later post). I am more interested in the why. If an interview candidate starts to light up when explaining why she loves to use something, you know right then that she loves her work and she loves being good at her work. This is especially true for people who like tools that require some dialing in but have incredible power. Users of these tools have proactively invested their time to get better at something. Contrast that with someone who is indifferent about his tools: who just uses what he is offered; who likes a tool because it has buttons that you can click that does things that he doesn't understand. To me, that is a sign that I am talking to a drone that is satisfied with the bare minimum. His passion lies elsewhere or doesn't exist at all.
Passionate professionals who care about their craft don't just make a team more effective, they also make work more fun because passion is contagious. When you see a colleague doing cool things, you want to learn from them. You are also inspired to raise the level of your own work. When your peers are just going through the motions, it has the opposite effect. You de-personalize and get cynical and start identifying with Dilbert.
Dec 31, 2012
A few people have been asking me about how my One Field Job Application experiment turned out (preliminary results here). We ended up hiring two excellent technical web PMs. Gerry Tamakloe works out of our Dublin Office. Gerry is a powerhouse: helping teams get the most out of our systems. He is not afraid to get into the details of an application and optimize it for an internal or external customer. Katie Methe works with me here in Massachusetts. In addition to managing projects, Katie handles deployments, QA, troubleshooting of our websites and GMO applications. I bombarded her with new stuff on her first day and she didn't even flinch.
In addition to finding some great people, this little experiment has reassured me that I am not unreasonable in expecting a web project manager to be capable of both managing people and doing technical tasks. A web project manager should rise to, rather than shrink away from, a technical challenge. Rather than just distributing work, A good web pm adds value to everything he/she touches: whether it be verifying and diagnosing a defect, deploying a fix, doing technical research, or configuring software.
Oct 26, 2012
John Allspaw (SVP of Technical Operations at Etsy) recently published an excellent article about what it means to be a senior engineer: "On Being a Senior Engineer". It's long but worth every word. It made me think of all of the colleagues that I worked with over the years. It also made me think of how little justice the title "Senior Engineer" does to this role. When recruiters look for senior engineers or senior software developers, they are basically asking for coders with some experience - perhaps on their second job out of college. Developers expect this title as a birthright after putting in a few years.
Allspaw's definition calls for characteristics that not everyone will acquire no matter how many years on the job. It makes me wonder if it would be more practical to use a different name for the role rather than redefine a term that most people use differently. The problem with the word "senior" is that it implies that it is part of a normal growth path. While I would love this to be the case, my experience is that most developers are not heading in that direction.
Another thought that I had is that most companies under-appreciate the role of senior engineer. Perhaps their businesses do not require need these talents. Maybe it is sufficient to have a project manager working with a number of non-senior developers. I would say that all web and software companies should definitely appreciate and cultivate this role. But does a bricks and mortar company with a commerce site on the side need a senior engineer? If not, what happens if the non-senior engineer starts to develop senior traits? Does she change jobs or do you move her out of software engineering to a pure management role?
Anyway, I thoroughly enjoyed the article. It really made me think about recruiting and careers in technology.
Aug 29, 2012
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.
Oh, and one more thing… I have still not received a successful submission from anyone using Internet Explorer.
Aug 01, 2012
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!
Nov 14, 2011
Jack Templin just sent me this excellent article called How to be the 10X programmer. A 10X programmer is a single person who has the effectiveness of 10 programmers. While this at first sounds like an impossible or at least unsustainable model of one super hero doing more work than a team, it is reasonable when you think of one person having the effect of increasing the productivity of everyone around him. That is, the productivity increase is not limited to his/her own output. Here is the kernel of the argument.
The 10X programmer is hypersensitive to problems. Solving a problem that costs other programmers a minute of waiting will gain a lot more than a minute for any programmer who then encounters that problem later. This is because of flow).
...
Importantly, the 10X programmer fixes the problems that knock her out of flow. Fixing problems - even "trivial ones - , leaving documentation so people can understand faster, keeping a database of common problems, and so forth, all potentially make a much larger difference because of flow than just a few minutes it takes to fix them.
I feel like I have worked around people like this and have had fleeting episodes when I have added that value. The true challenge is that the 10X programmer quickly becomes a bottleneck because he/she is the pivot point through which many decisions get made. The temptation to fill up his/her time with meetings is too great. Also, there is the question of compensation. Can the employer really afford to pay these programmers what they are truly worth?
What is probably more realistic is to establish a culture where everyone on the team thinks like this. I love the Pragmatic Programmer books because they help inspire you to do great work that makes you and your peers more productive. Maybe you don't get a full team of 10X programmers but a team of 5X programmers is nothing to complain about.
Nov 23, 2009
Over the past few years we have witnessed the transfer of website ownership out of the technology organization and into the department that owns the information. This has been a positive trend. While technology is certainly necessary to run a website, what makes a website successful is the content and its ability to communicate to an audience. Even though most I.T. departments recognize this, they have other systems that compete for enhancement resources and they often find themselves blamed for latency on web initiatives. Furthermore, technology is an easy scapegoat for more embarrassing organizational deficiencies like not having skilled and motivated contributors. Removing I.T. from the equation puts power and accountability squarely in the hands of the people who own the content (and the conversation) and removes any and all ambiguity about who to blame when the website fails to produced desired results.
As attractive as these outcomes are, transferring ownership is not comfortable. It puts a business manager into a position that he or she has not been in before: an owner of technology. Growing up through the ranks of leadership, most managers didn't sign up for planning technology projects, directing technical staff, or taking shifts on "pager duty." They purposely avoided a technical career track and neglected to build those skills. On a good day, they can ignore technology but on a bad day... well, we try not to think about those. Instinctively, the business manager wants someone who he can shout at (or hover over) until the issue is fixed. But who is that person and who pays him?
The first step is to hire a web development shop (systems integrator) to do the initial implementation. Even if you are an I.T. organization, I recommend bringing in a systems integrator who has significant experience on the platform you plan to deploy. These systems are extremely flexible, which means that there are plenty of bad design choices that you can make; you want to work with someone who has ruled out at least a few of them. But what happens after launch? An optimistic (naive, really) approach is to believe that, once the system is implemented, business users can just run it themselves. That doesn't work. Even if you are lucky enough to have no bugs and contributors that don't make mistakes, a successful web initiative attracts ideas for making it better. Ignoring those ideas is demoralizing to the users and causes them to dislike the solution.
In many cases, the business unit will create a retainer relationship with the systems integrator where the system's integrator plays the role of outsourced I.T. This typically only works when there is an internal staff member who plays the role of "product manager" and directs the external development team. Otherwise, the relationship can get very costly as hundreds of uncoordinated change requests start to degrade the usability and maintainability of the solution. It is also costly to have this external partner provide the first line of support. You don't want to pay consultant rates to triage "the Internet is down" and "I can't find the 'any' key."
If it is critical to the business that the website continually adapt to changing requirements and opportunities, it will expensive to maintain a team of consultants working on an endless enhancement queue. At some point, it will be cost effective to hire internal development resources to implement routine enhancements (like template changes). I think that more and more companies are falling into this category. The web is changing so fast. You need to try new things and continually improve.
Here are some staffing levels to consider:
-
__Infrequently changing website: __ one website product manager managing an external developer. The product manager also does training, contributor mentorship, and first line technical support (including pager duty to differentiate between an unplanned outage and "the AOL is broken."). The product manager should also maintain and interpret website analytics reports and Google Webmaster Tools.
-
__Continually optimized website: __ a website product manager with web developer skills. In this case, the product manager has the skills to reliably execute routine template edits and basic system administration tasks (configuring accounts and roles on the system, unlocking files, etc.). It is a good idea for the third party systems integration company to regularly review new code to suggest refactoring for quality, maintainability, and security. Like with the previous staffing level, the systems integrator is also brought in for larger, more complex enhancement projects.
-
__Steadily changing website: __ a website project manager managing an internal web developer. The web developer has solid DHTML development skills and is proficient in the template developing syntax of the WCMS. Like with the previous level, a third party systems integrator does periodic code review and executes larger enhancement projects. The development queue consists of a medium size (3 days to execute) enhancement, plus a steady stream of tweaks.
-
__Rapidly changing website: __ when I interviewed publishing companies for my Web Technologies for Publishers report series, I learned that most successful web publishing companies had a development team of between 2-5 developers and deployed new code as frequently as once per week. If your business is your website, this is the staffing level that you probably need.
Full outsourcing of all technology knowledge and ownership is not realistic. At the least, you need to have staff that understand the technology enough to know what to do and how to direct people to do it. How much you go beyond that depends on how aggressively you need to advance your platform.
Jul 21, 2009
Even in this down economy, finding technical talent can be extremely difficult. Résumés are worthless. It comes down to this: programming is a craft but we don't get to see the craftsmanship and creative process when we hire programmers. At least not before we narrow down the application pool of thousands to a short list of real candidates. After that, during the interview process we can do things like logic questions and programming exercises to see how the programmers solve problems.
The issue of finding talent is a very real concern not just for start-ups but also for established organizations that are selecting technology (like a CMS) that they must staff up to support. The natural tendency is to go by the numbers. Choose a technology with a "household name" like Java, .Net, or PHP where programmers are a dime a dozen. You are bound to find a needle in a haystack that big. Where this logic breaks down is that when a technology is so widely known and used, everyone seems to have it on their résumé. You can't tell if the candidate just spewed out a few hundred lines of crappy code or if they have immersed themselves in the technology to the point where they understand the core principles and philosophy. You can't tell if they are a talented craftsman and are able to learn new things. By selecting a household name (commodity) technology you have just made the haystack bigger without necessarily adding more needles. It is hard to find a Jamie Oliver by putting out a search for people who can make a hamburger.
When it comes right down to it, a language is just syntax that lets you do things like assign variables, create conditionals (if statements), and loop through lists. Learning what is available in libraries is the true learning curve when it comes to a technology and those libraries are constantly changing. So a good programmer is always learning. One of my favorite books about programming (The Pragmatic Programmer: From Journeyman to Master
) recommends learning a new language every year to expose yourself to different approaches. The best programmers love the challenge of learning a new language or framework. They read books on different technologies and practices. If I was hiring a PHP developer, I may get an even better result if I found a great Java developer who is open to working in PHP. Of course, then I would have to find a great Java developer. If I was looking for a great Java developer, I could see myself looking for people who have worked in Python, Ruby, Groovy, or even Scala. That would show that they are committed to learning new things rather than churning out code the same old way.
When you look at it this way, the relative size of the "talent pool" should not drive you to a technology choice. You want to choose a technology that has proven itself to be more than a fad so that it will continue to evolve and mature. You want to work with a language that has good resources for learning (like articles, books, IRC, and mailing lists). But you don't want a technology just because a majority of technologists claim to know it. Most importantly, you want a good programmer. If a technology is sound and effective, a good programmer will be able to learn it and be productive with it.
Jan 26, 2009
Angie Byron, has wonderful post on approaches to contributing to an open source project. She makes her point in parallel stories of an outgoing developer who puts a lot of intermediate versions of her code for public review and a perfectionist who holds back code that is not finished. Through the narratives, Angie shows how submitting lots of code helps leverage the collective knowledge of the community to learn better programming skills. Submitting code and interacting with the community also helps a developer build relationships with other developers who will be more likely to help her out.
With all of the focus on cost savings and intellectual property, the educational aspect of open source software is frequently overlooked - at least by business decision makers who have no idea how poorly written their in-house developed code is. Open source software has advantages over in-house software that extend beyond simply having more programmers eyes on the code; the ability to interact with similarly inspired developers across corporate boundaries can be a huge benefit that translates into professional development and job satisfaction. Of course, this value does not come for free. Like any other activity that builds skills, working on open source takes time. A manager should consider the educational aspects of open source software when developing a professional development program for his/her technology team. If you think of the time and expense of going to a traditional conference where a developer will, at best sit passively through conference sessions, working collaboratively on a real project either remotely or with developers at a sprint. This does not have to be limited to open source software but the open source licensing model certainly helps. There are some commercial products with active developer communities modeled after open source communities that share code and interact. If you have a large in-house development team, consider practices like pair programming, commit mailing lists, and code reviews that help turn programming into more of an open, collaborative effort.
A tale of two developers belongs on my "all time" open source reading list. Thanks Angie!
Mar 30, 2007
Having been employed at startups and fast growing companies, I have seen my share of technical résumés and my conclusion is that the technical résumé is nothing more than a misleading garble of acronym soup. They are totally worthless. Developers list every technology they have ever heard of regardless of whether they understood the technology or are current on it. Many developers work on large systems and have very little understanding of the technology beyond a narrow little slice that they were responsible for. Don't even get my started on certifications. In fact, my experience is that the more certifications, the less competent the developer. The technical résumé is the equivalent of search engine optimization circa 1999 - load your résumé with keywords, post it on Monster, and wait for the hits.
The truth is that a developer is not good just because she knows a certain syntax or has worked with a product. What makes a good developer is how she thinks and how she works on a team. Good developers are interested in the underlying design and function of the technology and are diligent about following best practices - not because they are told to but because they understand the value behind them. Even when they are heads down, they are aware of what other people are working on. They anticipate interdependence and communicate. Good developers make other people on the team better.
Luckily, with the advent of social networking and Google, the era of the technical résumé is about to end - certainly for senior technical people and upcoming tech rock stars. The reason is that these people who are smart and love their field do not just code anonymously in their cube. They interact out in the open and with some good Google searching, you can follow their tracks. This is certainly the case for open source developers but it also holds true with developers that specialize in proprietary applications as well.
If you are evaluating a technical candidate, don't spend too much time on the résumé. Start by Googling their name. There you will find posts to mailing lists and forums, chats on IRC, a blog, comments on other people's blogs, entries in bug tracking systems, even user group presentations that the candidate did. Ideally, you see the candidate answering a question or putting forth a well supported opinion. If he is asking a question, you can learn a lot from the quality of the information and the tone in the question. See my post on how to post on an open source mailing list for what makes a good question. Plus, a simple search may turn up any strange affiliations or interests that you might want to know about. For a proprietary product, you can do a lot by searching on the support extranet which may contain a forum or other community content space.
LinkedIn and other social networking sites are a great resource. The candidate might have received recommendations from people he has worked with. You might even know someone in common. If you do, start talking to people and find out what they thought about working with the candidate.
If you are on the other side of the equation and you are a technologist that wants to optimize his employment opportunities, stop getting certifications. Get out there and engage. Rather than get an MCSD, show what you know by writing something helpful on a MSDN Forum. Make more of an effort to understand the other components of the project you are working on. Sit in on someone else's code review. Actively read blogs (comment too). Participate in an open source project. If you are not interested enough to make this commitment, you can still have a comfortable career as a technologist but you will not go far. You will probably wind up being a PM ;)