Monthly Archives: February 2014

Optimism in Designers, Developers and Managers – Part 4

FacebookTwitterGoogle+PinterestShare

If you’re just joining us now, be sure to check out Part 1, where we explored the inherent optimism of designers, developers and managers, and what specific elements of our professions increase our sense of optimism. In Part 2 of this series we talked with real people in development and management roles to learn what leads them to feel optimistic about their work life and projects. Part 3 continued our exploration of optimism as we checked in with some designers to see what makes them feel hopeful about their projects and day to day.

Now let’s visit the dark side…
In reflecting on my own experiences and while talking with the designers, developers and managers on the topic of optimism in the workplace, a funny thing kept happening: folks would have trouble describing what made them optimistic. Instead, they initially (and with apparent ease) listed out the things that did NOT make them optimistic.

Instead of “I love having clear requirements” they would begin with “I hate it when requirements aren’t clear.” Rather than “I love being able to build something that lots of people will use and love” they’d say “I hate building things no one in their right mind will use just because that VP of BizDev thought it was special.”

This is in direct response to being asked about OPTIMISM, people. What the heck? Are we so entrenched in our work and trapped in habitual pessimism that we can’t see the lining of our clouds any more? So it would seem, but let’s dig deeper.

In my own experience, there are a few things that have me thinking like Mr. Edgar Poe. It’s discouraging to be told that due to a particular situation, a given design can’t be used–even if it’s a better solution–due to uninformed (or just plain wrong) beliefs held by stakeholders. It’s one thing to consider options and make an informed decision, and quite another to make a choice based on misinformation or prejudice.

When a project gets canned part of the way through, and sufficient rationale is not provided – that’s a morale killer. When you’ve poured your time, energy, and (let’s be real here) love into a website, application, process, or team – it’s devastating to have it cut off at the knees and not have closure into why it’s been done.

Last, it really gets my goat when assumptions are made about the capabilities of an individual or team. Just because someone is a designer doesn’t mean they don’t have the desire and skills to develop or manage. Assuming a developer cannot think visually or doesn’t have valuable feedback about user flow is a huge mistake. Concluding that a manager has no hands-on skills is downright silly. These mistakes are costly, preventable and senseless.

Let’s hear what our folks in the field have to say

Jeff:
“What I find crushing of dreams, spirits, etc., is writing code that is only good for today. Code that¹s written to get a single job done and doesn¹t need to be well done. Code that¹s not thought-out and generally, in the grand scheme of things, doesn¹t matter, as long as the project eeks by without a major failure. The rushed, ‘just make it work’ kind of stuff.

“Another frustrating thing to deal with are designs that don¹t translate well to code and/or UX…Those cases where a design is harder to code and doesn¹t produce a better outcome (and often causes a worse outcome) due to certain specifics about the design that could easily be tweaked to make the end result much better.“

Matt:
“A concern I have is the lack of language that developers possess to explain what they do to other technologists, much less non-technical people. This lack of understanding seems to make it difficult for non-programmers to appreciate and understand what our profession does. This both adds to the insularity of programming as a profession, often relegating programming to a task instead of culture or ecosystem in many domains.

This lack of language also makes understanding the risks and reasonable limits of technology out of the hands of most people — c.f. the healthcare.gov debacle. Having reasonable, stable systems as public goods will require something to be done here and I’m not sure there is adequate time or effort being made to do this.”

Robert:
“There are cultural challenges with… large companies… and we’ve got some process and workflow challenges that appear to be changing for the better, but it’s happening slowly. Companies can sometimes seem slow to adopt new process ideas and we often fall back into old patterns we know don’t work, because of resourcing/budgeting constraints.”

Hannah:
“If you want to kill my buzz, the easiest way to do that is to…accept mediocrity. I detest laziness, and I have no time for people who aren’t willing to try new things. This can be a double-edged sword in our line of work because implementing new technology and ideas in a large company takes eons when the rest of the world seems to be moving at lightning speed.”

Ask Yourself
Are you doing the work it takes to live on the sunny side? Because let’s be real–it DOES take work to see things in a positive light, or at least from a neutral perspective. It’s far easier to dwell on the dark side, play the blame game and have a portfolio of excuses handy as to why you’re wearing that floor length black trenchcoat instead of the Rainbow Brite sweater from your aunt.

What is it that keeps YOU from feeling optimistic about your work? Think on it, and let’s compare notes in the next and final installment of this series.

Note: Also published on the amazingly rad UX destination GiantUX.com