Changing Course

Posted on March 21, 2016

Well, this post isn’t exactly news, I elected to switch teams back in November of last year. But now that I’ve had a chance to settle into my new role, I have gained some perspective on how the reality measured up to my expectations. Though I’ve contributed a lot of code in my role as designer, leaving our immensely talented, and close-knit design team was not an easy decision to make.

Getting my hands dirty with implementation is equally as fun as exploring product design and mapping out user experience. These are distinct facets, but equally vital. The opportunity came as this: We have a real need for design and development to work together more effectively; we don't need to be adversarial; take what I know about front-end development to bring our design and the way we implement it to places worth exploring.

I did have some trepidations, however. While I have been contributing production periodically since I started in 2012, I was not the full-stack developer that we generally hire. Doing this full time was going to expose a lot of my perceived vulnerabilities. I guess I’ve always had a rapid case of “Impostor syndrome.”

With self criticism, I tend to be a little more harsh on myself. I imagined a very real possiblity of the move not working out and humiliation of trying to get back my old job. That I would never have a strong enough grasp to work independently, relying on others for everything. Luckily, that was not the case. I think I’ve found a comfortable niche, but getting there wasn't exactly smooth sailing. What helped was knowing that we all have our pain points and discussing them openly. That really help garner some comfort in how I fit in with the team at large.

To be on an engineering team when I still consider myself a designer was a little weird at first. But with role I’ve elected to play, it is the team from where I can fill that role with the greatest ease. Recently, I have been laser focused on trying to build a sustainable design system with modular components. Our legacy code is beginning to create major headaches. For developers, it is difficult to grasp its structure (there is none) and specificity creep makes writing good CSS nearly impossible. For designers, build rarely matches the spec. For the consumer, there is so much inconsistency in design and interaction that it sullies the experience.

This is work that I cannot do in a vacuum. I have to find a way to wedge it into an existing product, which requires the help and expertise of my teammates. It is also a wonderful opportunity for knowledge sharing. I ask a lot of questions, but will answer just as many. Not only does this make us more knowledgeable about our internal apps, but it makes us more well-rounded as individuals and stronger contributors.

A Lesson to be Learned

You’ve been brought onto your team for a reason, and that reason is you have something to contribute that nobody else can. But are you expected to know all the things? Absolutely not! And that’s fine, because we all have different skillsets amongst us. Admit what you don’t know, but have a desire to learn. It is amazing how much your teammates are willing to teach you.