Author: Elaine

Two weeks ago I wrote about generalizing vs specializing, or being a general specialist, or the changing nature of specialization in re web design. I’ve had an evolution of my thought about this because of my new job, wherein I am a specialist, but on a generalist sort of team. Which means I’ve also been thinking about teams.

In all the years I’ve been doing web development, this is the first time that I’ve ever been on a team of web developers. I should caveat that by saying that I had an assistant at Pierce, and worked loosely on web-ish projects with other departments at both TwinStar and Pierce. This feels significantly different: I am on a Web Team, my boss is a web developer, and the other full-time team member is a web designer. We each have areas of expertise, mostly related to our job descriptions, but there’s some fairly strong overlaps, and we speak a common language.

I guess we’re still in what the organization development types call the “norming” phase, where we work out who does what when, processes, lingo, what normal behavior looks like. Which is maybe complicated by all following each other on Twitter? I don’t know. Not to get into too much detail — because to some extent I’m trying to hold to the rule I worked out with my boss at Pierce way back when — but I feel pretty good about it. Anxious, of course, because social anxiety is my middle name (or something), but not more than my personal baseline of fretting about interpersonal relationships.

Again, just looking at myself, I find that I’m challenged by having to “share” — to realize that decision-making is different on a team like this, to know what I should do and what I don’t need to take responsibility for, to be explicit in communicating decisions and processes. As C has noticed a few times, I tend to take things in and then want to go off and hide and do something all alone before talking about it at all. (Introvert!) And it very often works well for me, but sometimes it’s counterproductive in this situation.

And The Web Team is not my only team here. I’m also working on a cross-departmental team, building a fairly significant product for the college community, where we actually work together in the same room one morning a week. I always dread it on some level, because that amount of real-time collaboration is exhausting. (So very introvert.) On the other hand, we’re doing something interesting and important, and the other team members are smart, engaged, and very knowledgeable about the college. And that Venn diagram is very different from the one that would describe the Web Team’s skills, so I can work on different things in different ways. So I get done with the cowork time (as I have just now) and feel like I’ve done something interesting and useful.

No conclusions about all of this just yet. Simply: teams!

The last Squirrel & Moose podcast reminded me of something I’ve been meaning to write about for a few weeks now, in so much as talking about workflow (I’m a code-in-Firebug person too, BTW, when it comes to CSS*) leads to thinking about workflow in the broader sense, and in so much as that it’s a topic Dylan & I have talked about off and on for years now.

My title at my current job (6 months yesterday!) includes the word “specialist,” which feels weird considering how much being a generalist has been part of my professional identity. I like have a broad range of skills, not being stuck in a tiny niche. And if it had been anywhere but working at Evergreen, with Susan, I would have been really hesitant to go into a specialized role.

But I have realized a few things; thinking back on my almost 15 years** creating websites (13 paid, 12 full-time), being a generalist seems to have shifted — or the scope of “web work” has increased, or something.

I like to tell the story of how I got my one and only raise at Pierce: they were doing an evaluation of all the “administrative exempt” positions (think of the Bobs in Office Space), and I had to revise the job description I was hired with. The list of things I was doing was twice as long as the list of what I was hired to do. Something similar happened when I helped write a job description for hiring my replacement at TwinStar: a significant expansion of duties.

Only some of that is my unfortunate tendency to get enthusiastic about more things than I have time or energy for — most of it was just new things that happened in those years. Social media of various sorts, email marketing, AdWords, content management systems, and just plain higher expectations of what ought to be on the web.

It got to the point where it was just too broad for me, and I was spread too thin over things outside of my strengths.

So on some level, being a specialist is a bit of a relief. It was much the same way when I got my first full-time web job; I was coming from a position where I worked on the website, supervised a secretary, organized events, ran a speakers’ bureau, and did a little bit of print design. Going to the web WAS specializing. Sometimes it’s just nice to be able to say that someone else has the strengths to do X really well (on the one hand), or when X is something I dislike or that’s problematic for me, that X is not actually my responsibility (on the other).

I’m also lucky enough to be on a team where I can use my broader skillset when it makes sense, and not just the things I was hired to do. I credit my boss for being open to that, and to some extent also the environment of Evergreen. Or perhaps I should say that I find the environment to be empowering in keeping the spirit of a generalist, even as I do some specializing.

So I guess overall I’d say I’m ok with being a “specialist,” more so than I would have thought.

I don’t have time right now, but I do also want to write about the experience of being on a web team for the first time, and the experience of being in a new team where we’re all working out how we work together. Soon! (Hopefully.)

* Just yesterday told someone that not having access to Firebug was like having someone chop off my arm, as far as getting stuff done.

** First started playing around with HTML in about February 1998, with the happy confluence of a cubicle neighbor who “did web stuff” where I worked, C’s first new computer, and IIRC, our first Internet access at home. Has it really been that long?!