2015/04/27

There is a gap in the perception of skills required between agency-experienced engineers and product engineers in today's development community. Understanding their differences in approach and strategy can be key to choosing where you work, modifying your career path, or helping to educate other developers/PMs/colleagues.

When I speak of Agency and Product (capitalized from here on out), I specifically mean for "Agency" to refer to a company that does work-for-hire for many clients on websites, and "Product" to mean a company that works on its own internal project (most start-ups fall in this category). The nature of what is worked on between the two typically being radically different.*

Core UX Values

As an engineer I believe its critical to understand the approach in interaction to understanding the project itself and how it should be grown. This is why I think understanding the differences in the mind-set of experiences is critical to understanding the variations in the mind-set of development.

Perhaps what I have observed most in terms of the different core UX between Agency-style projects and those from Product is explained by the end-user undergoing interactions to receive content vs content driving a user to interact, respectively.

Agency UX Objectives

While this seems to be more of a game of linguistics, I promise that it is not. Many websites (particularly, brochureware, or corporate websites ), are all about the users reading information. The designed flow from a UX point of view is to get them to content so they can consume it.

Any interactions required should ease the goal instead of hindering it. A robust UI requiring many filters and inputs, user-decisions and interactions would be counter-productive to say an effective search and a solid layout that eases readability.

Product UX Objectives

Products in the sense that I refer to them however have a drastically different objective. The user's key vehicle here is the interaction not the content. Through interacting with the Product they accomplish a goal (which varies from project to project and from persona to persona). These can range from purchasing an item, or scheduling an appointment to installing software or launching a video chat.

Variants in Technology

Engineers/developers/coders career-wise tend to stay within one of the two particular ranges, and during interview processes I've seen few Product-experienced engineers be hired by Agencies for website development, and similarly, few Agency-experienced engineers move onto jobs in Product engineering.

(the tolerance I've seen from hiring UI designers seems to be much more forgiving than for those of us who live in the code)

In terms of recruiting, I believe there are a decent amount of applicants to positions on both sides from both sides, but somewhere along the way the process eliminates them due to 'irrelevant' experience with certain stacks of technology (I'm guilty of having done this as well).

Front-end and JS frameworks

Between the two roles, the term "Front-end" seems to have a significantly different definition.

An Agency Developer uses html/css/javascript (or related preprocessors) to build out a designed experience to specification, is expected to be design-minded, and use tools to allow for solid cross-browser compatibility and fallbacks.

A Product Engineer utilizes javascript frameworks (such as Angular) to create an application, with emphasis given to code quality (hopefully), design patterns, employment of cutting edge technology, and targeting only relevant browsers (so probably not IE7-8 —maybe not even 9?—).

reminder these are generalizations from my experience

Both roles are expected to be familiar with frameworks and/or task-runners for managing workflows and both (should) employ preprocessors to ensure DRY markup and styles. But the emphasis shifts from core-knowledge and compatibility to framework experience (or inexperience) when looking between the two.

Bidirectional Bias

The use of certain technologies greatly influences the tone of a workplace and the style of interviews for perspective applicants. As individuals with Product and Agency experience stay in the respective fields, it creates feedback loops and isolated technology experience within each section.

An example of this could be a Rails Engineer on the Product side not knowing about Middleman (an increasingly popular static site generator utilizing Ruby that's been adopted by many Agencies), or an adept programmer in Javascript from the Agency side having primarily worked in vanilla JS (or jQuery which is more likely the case) with little JS framework experience.

For their different roles each candidate is most likely (theoretically) qualified to take on tasks from the opposite company setting, but when interviewing with the existing teams, the difference in exposure to technologies will make the Rails engineer seem less relevant to the agency in question, and the Javascript developer seem less qualified from the eyes of a Product recruiter.

Niche roles and Generalists

Experts

From my own experience on the hiring side of interviews, I can confidently say that everyone genuinely wants an expert, but what they want you to be an expert in can vary. For junior or entry roles, the candidate needs to be an expert at learning, so that they can quickly step up (under the guidance of a mentor in a healthy environment). Once you start recruiting for ranks with seniority however, even companies that look for generalists (pronounced "full-stack" or "ninja"), still want quality and expertise on everything that is done. Regardless of what you are told, its a solid personal move to always assume everyone wants expertise and quality when they are paying someone to do a job.

Language-wise, more often than not however, you will find roles looking for generalists in Agencies or very very young startups (that don't have sufficient staff yet). These startups will eventually mature (I hope), but for Agencies this is the standard mode of operations.

A 12 week training program can give its students the impression that they are now a skilled javascript/whatever engineer (12 weeks doesnt actually make anyone that good at anything btw), but this will seldom land an interview even with an Agency. Dealing with many and diverse projects, their goal is to find someone with extreme flexibility in what they build. They are looking for expert generalists. If such a course graduate shows promise however, and a Product company have flexibility for mentorship, its not unheard of for them to be able to work their in a specific task oriented capacity.

Also Experts

When a product company says they are looking for a skilled engineer or expert, what they are talking about is a specialist whose recent career has most likely been devoted to a single technology**. At the time of writing this, its incredibly common to have Angular or React as a requirement, often disregarding many years of relevant experience (in other languages or frameworks) as unrelated if they don't specifically include the required framework.

Agencies are just as guilty in this sense as the inverse, looking for their specific tools as well.

Adjusting Your Mindset for Interviews

So now its advice time, in what I recommend in terms of how to market yourself to different perspective employers.

Applying to Agencies

If you are applying to an Agency of the typical mindset for a front-end or full-stack position, being able to articulate cross-browser differences, elements of strategy and UX, awareness of design, independence and creativity are the key factors to get across.

I recommend showing your creativity for every job actually. Some companies don't look for or appreciate that trait in engineers. This is often the sign of a toxic culture, so I wouldn't recommend taking a job there anyways.

Applying to Product

Your expertise is your greatest selling factor here. Decide what you are best at and really sell that, whether its Ruby/Rails, Python/DJango, Angular, Node.js or whatever. Your ability to find a company that uses this, and to sell yourself as an authority, devotee or experienced professional in that chosen subject will far exceed any amount fo flexibility.

Hiring

If you are in the rare position to be in charge of recruiting/screening candidates for you company, I have some advice as well. If you tactics include looking for specific languages or frameworks increasing your flexibility will open your candidate pool rapidly. Not only this, but you will most likely be able to find more highly qualified individuals with varied experience, who are capable to picking up the new technologies quickly.

If you are already flexible in terms of what you look for, embrace specificity. If someone has mastered a certain tool or technology, there is a great chance that they could learn another one. Knowing about other frameworks and similarities will help with this, as underlying principles may be VERY similar, making it so that someone with experience in a seemingly unrelated tool, could actually be quite close to what you need them to work in already.

Notes
This article notably contains many generalizations to help clarify differences between the two, which is to say that there are certainly product-minded agencies and vice versa.*

This has by and far been my experience, but there are increasingly more mature product companies that are starting to understand that talented individuals can adapt, and don't look exclusively at past languages/frameworks.