Sunday August 13, 2006

A few of us at Geniant have been working on a career growth plan. This is for the User Experience Design (or “Enterprise Gateway”) practice, and should not only benefit individuals (“how do I get to the next payband?”) but also lend some structure to a pretty diverse range of skills and disciplines.

Had we not merged with Geniant, this formality might have emerged (to some extent) from the company culture, the type of projects sold or pursued, and the natural growth curve along which a company matures. However by pushing the fast forward button on our company, it’s been necessary to take a more proactive role in defining this internal structure. One, because we’re plying our trade in a different arena – enterprise service offerings. And two, because we have to figure how our expertise complements or integrates with existing focus areas we didn’t spend a lot of time pursuing – portal configurations for example.

Specific things we wanted this framework to define are:

• what types of people we want to hire

• what skills we value

• what skills we lack (for both the work we are doing and what we want to do)

• what types of growth opportunities there are within the company (for new and legacy employees)

• how this practice and different roles within this practice work together

• and so on…

That, and we needed some hiring structure in place to insure we’re hiring the right people for long term growth (and not just staffing short term needs).

The Presentation:
You can jump into where we’ve arrived, here:

…or continue reading below about some of the challenges we’ve faced, other models we tried that didn’t work, and what is revealed by framing our practice this way.

Challenges we’re facing:

• Technology for Geniant includes both web based apps and desktop based applications (e.g. WinForms). Having focused primarily on web-based applications at Bright Corner, we’ve had to rethink what skills are expected from a Front-End Developer. A really good—and valuable—WinForms developer may know very little about DOM Scripting or valid markup, for example.

• Along those same lines, we’ve wrestled with how to value people who are prized for the expertise in a specific Enterprise technology package or platform, but know very about things like semantic markup or valid CSS. How do you compare a Front-End Architect to someone who knows a package really well? They’re both making the UI a reality from a programmatic perspective, but it’s comparing apples and oranges. There goes a linear growth track.

• Not all IAs are created the same. This is true anywhere, but in our case we’ve had some fairly unique flavors of information architecture, resulting in some different processes and deliverables based on who was delivering on a particular project. Garrett and I are both IAs, but we can approach the same project very differently with very different priorities—and that is a good thing. What we’ve never had is a homogenized brand of IA.

• Not all IAs are created the same (II). While we were rather loose about our definition of “Information Architecture” at Bright Corner, at a larger scale we’ve needed to be more particular (mostly for hiring purposes) about the distinctions between interaction designer and information architect.

• Not all IAs are created the same (III). Defining IA for an organization is further complicated by the fact that no one in the field can actually agree on what IA is. Just when you think you’ve got a handle on it, along comes ‘Cross-Channel IA’ and ‘designing shared information spaces’ (other than just the virtual). Peter Merholz’s closing plenary at the 2006 IA Summit was a great recap of what IA has been and is about. Though I might quibble over the semantics…

• Not all IAs are created the same (IV). Let’s just say, for where Geniant wants to go, we’ve needed to start looking at Enterprise Information Architecture a bit closer…

• Content Sites and Applications are very different, each requiring as different a set of skills.

• Custom Applications and packaged implementations require different sets of skills.

• One of our strengths is the ‘deep generalist’ mindset, where we each have a broad set of very deep skills across many user experience disciplines. So how do we maintain this differentiator, but also support hiring highly specialized employees who do not have a broad set of skills?

• Whether it’s labeled as “Cross-Channel IA” or “Designing for Experiences,” adding these services can be… challenging. For a group that is so wholly focused on interfaces, how do you plug in the design of environmental spaces or processes? More importantly, try explaining to an IT company how these services are a logical extension of the interactions being designed for in the UI.

• We also recognize that younger hires we are able to mentor will probably grow along a different trajectory than that of most senior hires who have grown up inside other organizations. Developing a plan that works for and rewards both types of employees is also important.

Some of the approaches we took:
So, with all those challenges in mind, taking a historical look at the company, assessing present needs, and trying to anticipate the future, here are some of the initial approaches we took to structuring our practice:

“The Baseball Diamond”
This model is based in the idea that we all start with a similar (if not the same) set of skills and as we mature in our careers we move farther out into more specialized directions.

Pros: It was a nice, early start at articulating the ‘deep generalist’ nature of many of our employees; what’s represented here is the idea that if we all share a common base, then we’ll be ably to work more fluently together as we move into our specialized areas (contrast this with traditional organizations where disciplines are very siloed, with little to no understanding of what other people on the team contribute).

Cons: While sharing the same base set of skills was true for many, this is not true for most. Also, what are the specialized skills people move to? Are these proportionate across the board?

“The ‘Slider’ Approach”
Imagine a mixing board. Or an equalizer. Or for those familiar with the user experience tracks in Peter Boersma’s T-model post, imagine each of those tracks as a slider, where you can mix the skill levels of an individual across nine categories, with the goal to be somewhat experienced across most of these disciplines. Something like this:

Pros: Encourages a deep generalist mindset; recognizes a wide mix of skills; easy to assess your talent level across a range of skills, resulting in a quantifiable numeric value.

Cons: Which disciplines get picked? How do you get a fair mix of disciplines that doesn’t favor a design group over say a programming group? Also, this approach flattened and equalized some really disparate skills. And, without introducing some hacks and complexity, this didn’t support dependent disciplines (e.g. IA leads to EIA). Likewise, highly specialized people (who’ve reached the highest level of only one track) weren’t compensated fairly under this model. And again, who decides what the sliders are, and for how long?

“3 Most Popular Titles (with a 4th variable slider)”
Since the roles of Front-End Developer, Information Architect, and Visual Designer are so commonly bandied around—why not just turn these into three tracks, each with its’ own growth levels? And to support the specializations people have (mobile devices for example) add a 4th slider which is unique per individual

Pros: Around the office, these are the only three user experience titles most people recognize; from this the idea of ‘grades’ originated. As you see in our final model, maybe there was something to these 3 tracks…

Cons: Unfortunately, these tracks are grossly disproportional. Also, is a front-end developer the only kind of technology position we recognize? What about usability testing—where would this go? What about visual designers who are now doing UI design? And (rattle off a dozen other focus areas not covered by Visual Designer, Front-End Developer, or Information Architect)...

So…
There were other variations of these models, and other models discussed or proposed. But in the end, the things listed above gave way to…

“The 3×3 Model” (the final)
While the ‘3 tracks’ were way too narrowly defined and not remotely equal in scale, simply relabeling and broadening the focus of these tracks altered things considerably:

• Visual Design becomes Design

• Information Architecture becomes Human Sciences

• Front-End Developer becomes Technology/Development

While this might seem like a slight change, it changes things profoundly. Where before there were specific roles, you now you have focus areas — which could include a number of different roles and span a longer period of time.

Some explanation:

This model supports people from different tracks playing the same role on a project, a very real situation for small and growing companies where multidisciplinary skills are highly valued. In our case it’s common to have designers and developers doing information architecture. This model starts to explain how these disciplines can respond so differently when faced with the same problem. Designers favor elegant solutions. Developers want a system working as intended. And ‘Human Sciences’ people love concepts and mental models. Gross stereotypes, I know. But there is a grain of truth in here.

Coincidentally, as we started exploring these 3 tracks, I started encountering validation from other places. The most striking similarity came from MAYA Design, where they are fond of saying ‘Mayans come in threes,’ referring to the three broad disciplines represented on every project: Designer, Engineer, and Human Sciences specialist. Of course their scope of focus is broader than ours, where design also includes industrial design and engineering is about more than software. But, the idea is sound:

Every project needs…

• someone focused on what can or can’t be done with technology

• someone focused on how people think, feel, and interact

• someone who can create innovative solutions, whatever form that solution takes

While Geniant is not exactly cross-channel focused (yet), we do look beyond just screen interactions. In several instances, our information architecture work has resulted in organizations modifying offline process flows. By abstracting these tracks to the underlying discipline, I also didn’t need to go off and create a second model (outside of this one) for higher-order strategic offerings that moved beyond interface-based interactions. Where earlier models suffered from being entirely user experience focus (limited to screen or interface interactions), this model supports moving off of the screen and into cross-channel experiences or organizational assessments. Example: a simple ‘design’ track can support a “design-minded” person through 10 years of growth – from visual designer to interface/interaction designer to someone managing strategic innovations. Where the roles and duties might change, one thing remains—a person’s motivation for doing their work (even if that actual work produced changes from year to year).

Beyond the tracks, this model presents ‘grades’ – levels of advancement in a position. This was a carried over from an earlier model and stretched to span over 7-10 years of maturation—and several role changes. Where before the three grades represented career growth within a specific role, grades now took on a larger meaning, representing an invidual’s growing awareness of their contribution to the overall organization. Where someone may start off with a narrow focus at the screen level, at the highest levels of maturity that same person may look across multiple applications, technology stacks, and the corporate strategy, to make decisions rooted in a much deeper understanding of the business context.

There are a lot of nuances I’m glossing over here, and a lot that is probably very fuzzy without looking at the visual. So go ahead and download the framework. Let me know what thoughts you have…