Maybe you’ve identified this developer in the wild, maybe you haven’t yet. But I assure you he’s out there. And he’s not very creative.
Okay, I know that sounds harsh. He or she means well. He may even be very creative with an algorithm or a database. But the archetype I want to talk about today is the colleague who can tell you in a split second whether he can implement your work—and does so. Frequently. Without investigation, planning, or brainstorming.
Does this developer persona mean she can’t implement your design, or just that she won’t? We’re talking about that developer who tells you something is impossible, but that awesome dev on your last project already built what you proposed—twice. This may even be that developer who tells you he can’t do things you know how to build yourself. This is the type of developer who tells you he can’t do things even when they’re requirements.
Which may leave you feeling like this:
Or possibly this, and rightfully so:
Good news! Working with someone of this archetype is an excellent opportunity for you to sharpen your “political” and “managing up” skills. And he or she also provides ample opportunity to learn to tamp down frustration and remain calm under pressure. 😉
Working with this type
First, let’s try to understand before we seek to be understood.
Understand that developers of this archetype don’t mean any harm. They may feel as bad or as frustrated as you do. They may wish they had enough time on the project to build your awesome designs, but for whatever reason, they feel like they don’t. They may be angry at the project for leveling requirements that are impossible or setting this poor designer’s expectations too high. They may even wish they worked somewhere that did let them build what you asked. And of course, there will be projects sometimes where this is all true and valid. But the thing that defines the Uncreative Type is that they are actually not entirely true right now, on this project.
Having empathy for the people you work with is just as important as having empathy for your users. (Although don’t let it get in the way of getting your job done.) It will help you find ways to help this person help themselves.
The Uncreative Type is often a mid-level to senior developer who has shipped more than a couple of releases. They’ve really gotten their sea legs, and their confidence in what they can do has grown much since they first began. They’ve been there and done that. This is a really tempting point in any type of career to stop learning or get overconfident. (We could also call the Uncreative one the Overconfident one, but it would be less kind and also less focused on what you need to do to convince them to actually build your design. ;-] )
When this type shoots you down, usually extremely quickly, they have either:
- immediately thought of the ideal way to do that, which is not possible within current constraints or
- can’t immediately think of a way to do it, therefore… impossible.
Note: they didn’t spend time thinking this through.
When was the last time you designed something that didn’t need any time to think it through?
Well, no matter how experienced or brilliant, he or she needs to spend a few minutes thinking it through, too.
Ask why.
See if your colleague can explain why something is impossible. Does that sound plausible, or does your spidey sense tingle? Do they even have a fully formed explanation and will they share it? See if they’ve already tried to do the thing you’re asking for exactly, especially within the last six months. Can they explain to you a deep problem in computer science that no one has solved that your design requires? Can they show you how performance would be affected in very specific ways? Is the architecture just a crazy clusterf$#k designed to make your design insanely awkward and convoluted? All these things are good reasons, and a great collaborator will be willing to take you into her world and explain the dragons that lurk in the deeps.
Obviously, I understand sometimes designs are also just plain out of scope. We all need to compromise sometimes. Compromise is good and part of collaboration! To be clear, the Uncreative Type has not thought about this long enough to be sure that this is an out of scope idea or time to compromise.
The tell-tale signs of an Uncreative Type are:
- they reach a decision extremely quickly.
- they are always telling you that your design can’t be done.
- they consistently implement designs to a lower bar than other developers around them.
- they say things are impossible with no explanation.
- they don’t talk to other developers for ideas or to investigate how your design might be built.
- they don’t seem to consider it their problem to figure out how to build your design, but rather your problem to come up with a design that’s easy and obvious how to build.
If you can, encourage them to explore.
Let’s say they don’t have an explanation why, or you don’t buy it. Or you’ve heard the same excuse one too many times. Encourage them to make an attempt before rejecting the idea. Do they have a more senior colleague they love to chat with and respect greatly who is not uncreative? You could suggest asking if that person has any ideas of how it might be built.
Enlist help.
Are their designers in your organization who were formerly developers? Run their rejection by them and get the smell test. Have other designers struggled with this developer as well? Is there a pattern? (There always is, with the Uncreative type.) Do you have a close developer friend on another team you could ask for advice on how to approach the situation? They can also help you understand if you are barking up the wrong tree and if there are any actual hard problems to solve.
The internet can be of help too. Depending on how technical you are, you might find a stackoverflow thread or forum post that solves the problem the developer is worried about. If you’re not technical, a developer friend might be able to help you make sure it’s really related to the problem at hand. If you can find this, it can both get this design implemented and help encourage the Uncreative Type to realize that they could have looked for the article too, probably a lot faster than you.
Escalate.
Game of Thrones time. This is delicate, but also part of a designer’s job. Your job is to get the best product possible into the hands of users, remember? That doesn’t just include thinking up cool thoughts and/or drawing pretty pictures. You’re a member of a team, and responsible for helping that team achieve all it’s capable of. You’re also a member of a company that needs you to be more than a cog in a machine (even if they don’t know it heh).
Developers, architects, project managers, and anyone responsible for business or requirements concerns can all be your allies. Try to get your relationship with your developer colleague into the best possible position you can before enlisting outside help. You might tell them you’d like to get some fresh ideas on how you could solve the problem together or come up with a great compromise by setting up a meeting with someone smart whom you both respect. You might play a different card and say you’re worried if certain stakeholders will be okay with not implementing this feature this way, and suggest you consult with them together to come up with some options. Some developers will welcome this—it often has simply never occurred to them to reach out to others. Especially if they’ve had a successful career without needing to do this very much.
Others may be irritated. It can feel like an insult or an attack on the ego. This was something that was hard for me to personally handle, but things can be smoothed over over time. If you never ruffle any feathers, you probably aren’t pushing hard enough. Reinforce whenever possible that you have the needs of your users (and therefore the company’s business) at heart, and you know you are all trying to do your best.
Great user feedback can heal lots of wounds. Be sure you’re likely to get it by having tested your design in quick and dirty prototypes. Axure or Balsamiq can make amazing things, very quickly, and you can even really do some damage with a simple PowerPoint or Photoshop image map.
Another approach is to get independent feedback from stakeholders individually. Discuss potential compromise options or the negative potential consequences you foresee one-on-one. Share with them your concerns, and stay professional. Especially if this person is technical and on your team, they may be able initiate working through the problem with the developer on their own. It may also be a good reality check to help you figure out if your concerns are overblown. Always trust your gut, though.
Here’s another tactic that’s an option: review the proposed new design, with key stakeholders in attendance. If your organization does reviews, this may a natural part of the process. If you’ve already shown key people one idea in a review and it’s on the chopping block, have an update meeting to keep them informed of what’s changing (and make sure they are on board). Show them the old idea, explain what you’ve been told about why it absolutely can’t be done, and present a new idea and the tradeoff choices you’ve made. Point out and acknowledge any places where you understand it sacrifices user experience in a calm, objective way. Include any plans for future improvements or how those sacrifices can be mitigated. When stakeholders see compromises happening as they go, they have the ability to course-correct, and also aren’t surprised discovering them later in a build. You also show are both willing to compromise, and aware of the costs. You show you are in control and trying to make smart, but practical decisions within constraints—the essence of an effective designer. This may even generate new, better ideas that aren’t such a loss. But if you approach it fairly and objectively, it may also encourage people to dig deeper into the first idea and more fully consider if it can be done and if the sacrifice is worth it. Someone in the room may even be excited to be the hero / genius who can think of a way to do the idea easily.
Obviously, when it comes to escalation, you have to pick your battles. Do not fight every battle. Find the ones you believe you can win, where you’re relatively sure your design is necessary to business success, and where the potential user impact is huge or very risky. This will help your team trust that if you’re stirring up trouble, it’s probably for a good reason.
If you feel like you can’t get through to them, encourage them to build for your design in the future.
If there’s no way around it, or you don’t have the energy or certainty to fight for this particular design on this feature in this moment, it can’t hurt to suggest that they make their implementation as compatible with the desired design as possible. They might not listen, but you can try. Sometimes this even encourages a process of realizing that it is half-achievable, or it is doable after all, after they get into the actual coding.
This has happened to me more than once. The impossible can turn possible once they’ve fired up the IDE and actually looked at it. 😉
Remember—it’s not personal.
This isn’t the ‘They-just-don’t-like-you’ archetype. The Uncreative Type means well (mostly). They’re experienced, and they know their shit. They may not be used to working with UIs or designers, or they may just be out of practice of really exploring how to solve a tricky UI problem when UIs are often relatively straightforward. If you can help them get out of this professional rut, not only will your product be better for it—their career will be better for it too.
