TheLadders Blog

Soon after we started developing our first mobile app we, realized that we are now building “shipping software,” rather than a website or web services. There are fundamental differences between the two, which proved to be a big challenge for our team—particularly, given our desire to continue using best practices of agile and lean development.

Product Development at TheLadders

Before I continue, allow me to quickly give you some background on how we develop products at TheLadders. We live and breathe agile and lean development day in and day out. If you haven’t read it already, my colleague Michelle wrote a great article about how we work in cross-functional teams in our company. If I had to sum it up, our mantras are:

• Communication and working software over documentation
• Actual data and user feedback over assumptions
• Product iterations over extensive planning

In true agile and lean-development fashion, we are committed to the idea of solving large problems by breaking them down into smaller, more edible problem statements. Based on that, we create hypotheses, which we turn into user stories. Armed with those, we then start developing actual software. Once it comes to software development, we aim for short iterations to get real user feedback and actual usage data as fast as possible because this guides our decisions as to what we build next. This process is designed to maximize speed of learning about our users and our ability to solve their problems. In a way, you can say that we “test” our way into a great product; a word that captures the essence of this process pretty well is “MVP” or Minimum Viable Product. In other words, we aim to build iterations of smaller products to learn along the way, rather than one, over-thought, or over-engineered, solution.

This iterative approach to software development works really well when you develop web products, because in a web world you can release software quickly and globally for all your users. You can also easily test features with subsets of your users by using multivariate testing. To put it more bluntly: it doesn’t matter if you screw up, because this is part of the learning process and you can recover from it quickly.

Our Mobile “App-roach”

With this understanding of our product development philosophy, you might be able to understand why we first struggled when we started to work on our first mobile app. Our ability to “test” our way into a great solution didn’t seem to be a viable option because a mobile app is software that your users download. And unlike a website, you can’t make quick changes to this software once it is in your users’ hands (quite literally). Consequently, critical bugs or feature flaws have a much higher risk associated with them. Releasing an unfinished MVP version of an app into the app store wasn’t an option because we didn’t want to receive 1 star ratings in the event that the app is buggy or users didn’t care for what we built. What’s worse from a product management side is that you are not able to test different features and experiences easily. In other words, the product that you provide to your users for download must solve the majority, if not all, of their needs. We call this the MDP, the “Minimum Desirable Product.”

Finding a Solution

The root of the challenge lies in getting constant user feedback and usage data while we are still working on the app. For reasons stated, we couldn’t accomplish this with a “live” product, but there are other tools and ways to solve that problem. We devised a diary study with 11 participants from our existing user base that fit our demographic criteria to represent the majority of our total user base. After screening hundreds of interested participants we picked our final 11 and used them as a proxy for user feedback and app usage. After initial set-up, we frequently sent them new versions of our app via TestFlight – a tool that allows you to provision apps on iPhones without going through Apple’s App Store. After every version release, we interviewed each user for 30 minutes each week and studied changes to user behavior. This process was tremendously helpful to prioritize our existing backlog of ideas and features, and helped us to uncover new problems and devise new solutions.

Looking Ahead

The decision to “test” our app along the way with a well-selected, handful of users was one of the best decisions we made early on. In true agile and lean-fashion, we listened to the user, looked at data and then changed direction accordingly. To prove the success of this approach, one of our participants recently mentioned that “this app feels like it was made for me.” So, to come full circle and answer the question I asked at the beginning of the article: Yes, we believe you can be agile when you “ship software.”

Keep an eye out for exciting news about our mobile app, Job Search by TheLadders, in the coming days.

Benjamin Grohé is the Product Manager for new consumer products at TheLadders. When he is not coming up with innovative ideas to delight our customers, he is celebrating his European heritage by cruising the streets of New York City on his new Vespa or playing football (the REAL football).

“You must be the change you wish to see….” -Gandhi

Eight years ago today, I joined TheLadders.

Back in January 2005, we were a small startup with only 25 employees. My first job was working on building a new version of TheLadders.com. At the time, there were only a few hundred lines of code and we spent the next few months working around the clock to deliver a new and improved website. When we were done and the site was launched, I remember my father asking me, “Now what? The site’s done; do you still have work to do?”

We certainly had more work to do then and we still do now. Today, our mission is the same as when we started: finding the right person for the right job. As long as our customers face frustration with their job search, we will be hard at work trying to help job seekers find their next job or employers their perfect candidate.

As we embrace 2013, I am seeing the same kinds of change and excitement that I saw in 2005. Over the past eight years, we’ve learned a lot about the job search, and we’re making big moves to reflect a new way of discovering job opportunities and candidates.

Fundamentally, we have changed the way we work. We threw long backlogs and task-lists out the window, and started working towards shared themes and goals among the whole company; not just technology, not just a single Scrum team. Themes shared by the CEO, marketing, sales, finance, customer service, product, tech and UX groups. With this approach, we have abandoned a traditional team structure previously set by executives and, instead, empowered our staff to determine how best to organize themselves to achieve our shared goals. We try and gather the right people in a room to solve a problem and we know they will make something great.

Have we figured out the magic formula for software-development success? Perhaps. We are closer to being agile with a lowercase ‘a’ than we ever before. We are making better decisions about how to best deploy our collective brainpower and talents. We are shipping value to our users faster. We are learning to say ‘no,’ affording us more time to focus on the work that best serves our users.

Almost 20% of our traffic is coming from phones and tablets, so the new website for TheLadders is completely responsive. It renders well on desktops, tablets and mobile phones. And, we are not stopping with just some fancy CSS; more is coming on the mobile front in the next few months, so stayed tuned.

Because finding the right job should be less tedious than searching through a database of titles, our team of data scientists and engineers work relentlessly to pair our users with the jobs that suit them best. You can still search if you want, but you do not have to be an expert on crafting keyword searches and filters to find relevant jobs; based on what you tell us, and also what you actually do online, we will find you those jobs.

Matching is easy to say and hard to do well. We have to deal with a host of technical challenges, such as classifying jobs into our taxonomy, and we are employing machine-learning to do that. But, that is a topic for another blog post. If you are one of our more-than 5 million members, you may have noticed some of our job- matching efforts with our new Targeted Hiring Alerts.

Job descriptions are becoming a commodity; everybody’s got them.  So, what data do we have to augment them and provide our users with relevant job information they cannot get anywhere else? We’ve launched TheLadders Scout, an innovative (and addictive) way to get a deeper understanding for the job market and your competition. It is a start towards giving our users the data they need to make faster and more-informed decisions in their job search. Here’s our founder’s take on it.

We’ve grown a lot in the past eight years. With more than 5 million jobseekers and 31,000 recruiters and employers, we have embarked on a large infrastructure rebuild, launched powerful caching with Varnish for our web-services layer, and we are leveraging Storm for processing our long-running match and email tasks. Our move from MySQL to Clustrix continues, and dozens of DB slaves are going offline as we increase our load on the Clustrix database. And, most significantly, we are refactoring away some of the most fiddly bits of our codebase.

Additionally, we are rebuilding our data center with shiny hardware, as well as a new network and level of resource flexibility that gets the bits from us to you, that much faster. Our DevOps team has been busy designing the new data center and ramping up for a smooth transition over the upcoming months.

To celebrate our accomplishments so far, and to share our excitement about what is to come, we are re-launching our development blog, because the best decisions stand up to the harshest light of criticism. There are exceptionally talented people on this team, and you should meet them.

Want more from the product and development team? Visit the Engineering Stories blog!

Kyri Sarantakos is Vice President of Engineering at TheLadders.  When he’s not playing around with iOS development, he can be found hacking all things radio-controlled.

If you are a Lead Java Engineer (code monkey or hands-on manager)…or…a Senior Front-End Architect…or a wee bit less senior Java Engineer, I want you to know about TheLadders – both our development environment and our social mission (to help people manage their careers).

But first I’d like to talk about the 3 types of technology companies who hire developers…one of them is TheLadders:

One type is those with a sexy name, lots of funding, and a great social buzz; everyone wants to work at one of these “west coast”-like firms and discussions about the stack often produce religiously fervent comments. This isn’t TheLadders – although we do have many of the same perks.

Then there are those where the product or service doesn’t set the tech world on fire; the stack isn’t a featured discussion on code forums and programming is as essential as plumbing is to a house. But the programming challenges aren’t going to be ones that set the code forums on fire either. This is definitely not TheLadders.

TheLadders is the final type of tech organization. Despite the stack not receiving top public billing, it is architecture, programming, and SQA that enable our job-seeking customers to receive highly customized career content. Everyone knows someone who is looking for work or simply a better career opportunity; these are our customers and our mission is to help them succeed.

In a nutshell, there are three types of developers TheLadders is interested in:

• Those with a keen interest in the scientific end of programming. You will be charged with designing and developing software to make content recommendations to users (AKA customer merchandizing).

• Those with a keen interest in UX programming. This is where the customer merchandizing piece becomes interesting and focuses on the architecture and building of lightweight mashups.

• Those with a keen interest in “plumbing” programming. Here the work revolves around architectural patterns and scalability particularly SOA.

Do you fall into one or more of these buckets and have a desire to architect and build a high-volume, SaaS platform that helps people identify and achieve their career goals? Are you the kind of engineer who wishes you were also a product manager? Do you prefer to work in a fast-paced, open environment where innovation and participation is encouraged through blogging, custom tool development, hack-day events and other out-of-the-box techniques?

If so, you will love it at TheLadders.

Our Software Development Story

To know where you will go when you pick TheLadders, it helps to know how much we improved. During 2011, our technology team:

• Implemented the groundwork for SOA

• Successfully modeled the core domains (jobs, jobseekers, recruiters) that will be incorporated into 2012 front-end/back-end development efforts

• Developed a Continuous Deployment Roadmap that shortened deployment cycle time from every 2 weeks (requiring 6+ hours) to 2-3 times per week (requiring 30 minutes-1 hour)

• Increased overall test coverage from fully manual to fully automated during development

• Introduced Scala into the stack

In 2012, technology will continue to drive improvements in our product development environment and will likely involve new architectures, stack changes, and delivery platforms. Perhaps you’ve been part of large scale efforts to make these changes happen; if so, then you’ll like what you’re going to read next.

Although the stack is heavily oriented towards Java leveraging Spring and built upon Soir/Lucene, MySQL, and Avro – meaning you know Java, the JVM and the ecosystem of supporting tools and libraries – we’re becoming more code agnostic (you will probably have a say in what stack will become).

On the front-end, it’s JQuery, HTML5, CSS3, JS, JSTL, JSP tags, and associated frameworks not to mention the potential use of Backbone, Ember , Less, Sass, Node, Mustache, Handlebars, haml-js, Coffeescript, and Sinatra. What else should we be looking at?

What’s important to us is that you’ve embraced and are active in the open source community; you’re willing to debate and discuss architecture and stacks; your coding style is best described by others as “craftsman”-like in style and quality.

The Positions

Hands-on Front-end Architect

You must be a natural-born problem-solver with exceptional hands-on technical skills. We’ve moving to a REST service-based architecture which will be a large factor in our applications future capabilities.

This role is all about leading us into the future, and we are definitely open to change. This role will be charged with guiding our front-end architecture as we grow and build new products. You will be a decision maker on what frameworks we use, how we build web applications, and ultimately determine what web app development at TheLadders looks like in the future.

Your job will be to help us build highly interactive, visually compelling solutions that will guide our customers to the right opportunities or individuals, and surface and merchandise candidates and careers in the most flattering and authentic light.  This is not a job-board development role; this is a chance to create a new product in a category with a solid social mission – helping people manage their careers by delivering them with customized career content.

You will be working in a young team that will appreciate your wisdom, experience, and creative problem-solving skills but also likes to debate, push back, and discuss options. You’ll be given the autonomy to make the important decisions that will drive front-end development; you will not work for a boss who hovers over you.

Lead Software Engineer (could be a Manager)

You are already a real software development leader in your Scrum and you are comfortable with challenging your team – and yourself – to make better strategic and tactical decisions. You have shipped large projects working as part of a cohesive team…and you can point to them online.

You enjoy mentoring younger team members in an XP environment and take pride in seeing them mature into future engineering leaders. You abide by the “best tool for the job” approach to selecting technologies and languages. You are known for the beauty of your code and are an evangelist for craftsman-like programming.

Your job will be to contribute to the end-to-end implementation of our highest profile projects especially those that focus on the ultra-complex goal of making content recommendations to users.

As a leader in the group – again, you can be a code monkey or a hands-on manager, you will suggest tools and best practices that will continuously improve the quality of design and implementation as well as site performance.

Finally, you’ll have the chance to leave your mark by helping us to staff, grow, and cultivate a very-high performing engineering team.

Java Engineers

Both front-end and back-end teams are also looking for less senior developers who enjoy the Scrum, thrive in technology-driven environments, and are looking for places to make a mark (TheLadders is a meritocracy – you are recognized for what you do not how many years of experience you bring). I’ve written about the contents of the stack and the development environment earlier; interested?

Next Step?

Email me about your interest; send a resume if you’d like. There’s no relocation per se because frankly the New York Metro area has plenty of incredible Java programmers. I’ll be happy to talk to you about the role of interest and answer all your questions.

In the end, TheLadders is all about high-tech meeting high-touch and making a difference. If you’ve read this far, I’m guessing this is what you’re looking for…

Steve Levy is Principal of outside-the-box Consulting and works as the Lead Technology Recruiter at TheLadders. He’s focused on recruiting, career counseling, social media, and organizational development consulting; he has been referred to as “the recruiting industry’s answer to Tom Peters”.

A few weeks ago one of our talented Interactive Designers, Michelle Zassenhaus, suggested we pitch TheLadders executive team on a persona research project. We discussed the need and merit of this project for a while without reaching a clear consensus. Where I was getting stuck was the need for this exercise given how much face time we actually have with our customers. We run usability testing every week. We call customers on an ad hoc basis but it amounts to nearly weekly conversations. The company has an annual focus group initiative and our customer service teams are always vocal with prevalent customer issues. In short, we know our users. So why would we need to create personas?

I posed the question to several folks including Tristan Kromer. Tristan suggested that instead of trying to sell the organization on an expensive project where they weren’t sure what they would be getting for their money and we, the UX team, couldn’t cohesively articulate why we were even doing it, we should introduce the executive team to the concept of personas as a corporate alignment tool. The idea seemed not only viable but also valuable. At the end of that lunch-time chat, I promised Tristan I’d write a blog post recapping the activity and its results. And so, here we are.

I decided to pitch the organization on a proto-persona (aka ad-hoc persona) exercise where the executive team would articulate who they believed we were building products for and how our current and future offerings would meet their needs in the near-term future. My belief was that in each of their points of view, the executive team had a different target audience in mind. In addition, I believed that many of them were approaching corporate strategy from the inside out – in other words, from their particular discipline (e.g., marketing, products/features, services, customer support, etc) and not from a customer-centric point of view. The goal of the exercise was to get everybody’s points of view out on the table and then consolidated into a single, shared consensus about who we believe our customers are and what needs of theirs we should be solving in 2012 and beyond.

My timing could not have been any better. The team was going through the nascent stages of 2012 planning and, if I could have the exercise pulled together quickly, we could build it into their process. I built a quick proposal where I articulated a problem statement, the objectives and goals of the exercise and the specific methodology we would employ to achieve those goals. Michelle and I reviewed it a bit and off it went for executive approval. Luckily for us it was quickly approved and I was cleared to book the executive team for two, 3-hour meetings over the next two weeks.

(It’s worth mentioning that our target audience had broadly expanded in the month prior to these exercises. In October 2011, TheLadders expanded its market reach from the $100k+ salary range to include professionals of all levels. This opened our products and service to a whole new set of potential customers. )

Day 1 – persona creation

Pens, paper, ipads and pizza. What else would you need?

The first day consisted of pulling the team together from noon to 3pm (pizzas were brought in) and presenting them a short introduction. The presentation stressed that we were going to look at the company from the customer’s point of view. Our goal was to articulate who the customer was (or were) and what needs they have that we could choose to serve or not serve. Michelle and I introduced the executives to the concept of an ad-hoc persona by explaining that these were going to be “people” they believed were going to be our customers now and in the coming future. It was important for us to stress the difference between real personas and ad-hoc ones. These were not going to be research-proven customer archetypes. They were however going to be reference points which the team can use as filters in the 2012 planning and decision-making process. We closed the short pitch with examples of what they’d be creating.

The team was going to sketch quadrants for each persona. Here is an example of a finished persona:

Example of ad hoc persona

The top left quadrant was for a sketch of the individual, a name and some basic demographics.

The top right quadrant was for behaviors and beliefs of the persona.

The bottom left quadrant was for demographics.

The bottom right quadrant was for needs and goals.

The team was given 15 minutes to create as many personas as they could or felt were necessary.

Once complete, each executive presented their persona to the team. They read the persona out loud and posted up on a wall. The team would then provide some feedback on the realistic qualities (or not) of that persona and some real-time adjustments were made.

Marc Cenedella, CEO & Founder of TheLadders, presenting his personas

Next, the team was asked to place each persona on a set of 5 spectrums. The spectrums were: years of experience, education, ambition, risk tolerance and tech savviness. Each executive was given three Agile planning poker cards. The cards had the numbers 1, 3 or 5 on them and the team was asked to vote by raising the card they felt most appropriately mapped where each persona fell on each spectrum.

The team voting with planning poker cards

Much like Agile planning poker, if there was consensus there was minimal discussion. If , however, there were outliers or a broad distribution of opinion on where a particular persona lay on a particular spectrum, we encouraged the team to discuss and debate that. In many cases, the outliers managed to sway some votes. In other cases the majority won and in still other cases the team made real-time adjustments to their personas to more closely match their view of our target audience.

As each name was voted on the spectrum, their name was written on the whiteboard in the appropriate spot. Almost instantly, patterns began to form. There were clear clusters and clear outliers. At the end of the 3 hours exercise we had a board filled with personas and persona names mapped to spectrums.

Spectrums with names mapped on them

We ended the exercise by thanking the team and letting them go for the day. Michelle and I spent the next few days consolidating the 20+ personas that were created down into a manageable size based on their spectrum distributions. We wanted to get to 3-5. We ended up with 6.

Completed persona

Day 2 – Persona verification and design studio

Day two began with donuts. It was morning and it was early. Donuts help. A lot.

We began the exercise with the team by going over the consolidated set of personas. We’d sent the team the document in advance of the meeting so they would come in , in theory, prepared to discuss. We projected each persona and began a vigorous discussion around their validity not only as a “real” person but also as a customer that we wanted to support moving forward. This part of the exercise truly engaged the team. Strong opinions were presented and an excellent debate ensued around some of the newer customer types were now attracting to the site.

Reviewing the consolidated personas

Each persona was reviewed in detail and adjusted, in real-time, to provide a representation that the team could agree upon. This was probably the part of the two-day exercise where the most consensus was built. At the end, we still had 6 personas but they were now modified enough to where the team was comfortable with all of them as viable customers (Note: interestingly, one contentious persona had to get down to a vote and made it in as a customer by a vote of 5-4).

The second half of this exercise was a design studio. Many articles have been written about how to run these and we use them regularly with the staff at TheLadders. We modified this one for time and focus. The first 5 minute round of sketching consisted of a single 6-up template for each executive team member.

The design studio in progress

Each executive presented and got critique from the others. The team was then split into two groups based simply on where they were seated and asked to consolidate their sketches in to one big sticky note drawing. The drawings were all supposed to be of TheLadders.com home page articulating value propositions that were relevant to the 6 personas. Each critique session asked how the designs presented were valid for the various personas. The teams consolidated their visions into two big drawings that amazingly enough converged on similar themes.

Big sketchin’!

We dismissed the team, thanked them for their time and asked for any feedback (good or bad) on the exercise. We followed up with a summary email that recapped what we did and what the themes were that we found. In addition, we stressed again that these were our beliefs and that, now that we had them, we will be using them to drive recruiting for usability studies, compare them against other customer samples and will update and adjust them as we find characteristics of real customers that go against our initial beliefs.

The one final asset we created was a printed deck of persona cards so that these ideas could easily come to any executive meeting – especially the ones where we were not present.

Persona cards – front

Persona cards – back

Learnings

We had several goals when we set out to run this exercise with the executive team. The first was to introduce them to the concept of personas. We achieved this goal to the extent that the team now knows what this tool is and what components make it up. Given that these were ad-hoc personas, it is incumbent on us, the UX team, to continue to update the 6 personas we created as we learn more from actual user interactions. We must then update the executives with these new details.

The second goal was to get the executive team thinking from a customer-centric point of view. For the duration of the exercise we succeeded though it was a constant effort to keep the conversation focused this way. Each executive’s tendency was to fall back to their traditional points of view based on their responsibilities and, as moderators, it was our job to bring the focus back to the customers. One additional thing that I found particularly interesting was the team’s tendency to present their feedback and insights to me, the moderator, as opposed to their teammates. Our goal was to have the team debating each other and, while that happened at times, much of the conversation was happening with the moderator (Michelle or I) as the initial recipient who would then bounce the dialogue back to the team. Beyond the exercise, it’s too early to tell how successful we’ve been. Our hope is that the printed card deck will serve as a reminder for the team.

The third goal was align the executive team around a target audience and get them to debate and agree upon value propositions that serve the needs and goals of that audience. Again, within the constraints of the exercise I believe we were successful. We created over 20 ad-hoc personas and consolidated down to an agreed-upon set of six. We designed landing pages for those personas that spoke to the value of the products and services we’d offer them in 2012. There was consistency in the themes the team raised and a general acknowledgment of a shared understanding. Will this alignment last into future planning meetings? Again, it’s too early to tell but early indications point to only minor erosion of these initial ideas.

This article was first published at jeffgothelf.com

Jeff Gothelf is the Director of UX at TheLadders. He’s also the author of Lean UX: Getting Out of the Deliverables Business (O’Reilly, 2012), Agile practitioner, interaction designer, blogger, public speaker, author and design/product thinker.

At TheLadders, we’re committed to our customers and understanding what they need. Our User Experience team takes this to heart by testing every interface we design with real jobseekers every week. Now we have a new initiative—and we’re asking for your help!

In an effort to understand our job seekers better, TheLadders will be giving out free Premium memberships. If you’re selected to participate, you’ll simply be asked to keep track of your job search activities on a daily basis. We’ll ask you to take about 15 minutes per day to log your job search activities and how much time you spend on them. Once a week, you’ll talk with a member of our User Experience team for 10 minutes by Skype or phone about your experience.

TheLadders Premium membership includes unlimited access to jobs as well as confidential connections to employers and recruiters in your field. Our certified professional resume writing team will also provide you with a free resume assessment.

We hope you’ll welcome this opportunity to help us improve the job search experience for other career-driven professionals like you.

Interested? Apply here by Thursday, October 20: http://svy.mk/n2qlI3

Applicant requirements:

- Must be recently (within a month) unemployed

- Willing to track their time spent on job search activities

- Able participate in a 10-minute weekly phone/Skype check-in

Michelle Zassenhaus is a User Experience Designer at TheLadders.  When it comes to design and photography, her eye for detail and artistic talent make her a natural.