I’m currently trying to put together a post about different modes of thinking that I think developers are not very good at and traditionally leave to other roles to prop them up on, but I’m not having much luck. It occurred to me that a large part of the problem here was that I am, in fact, a developer so most of my perspective of this is from the inside looking out. I’d like to fix that.
As I’ve previously expressed I think having a good team who you can rely on to support you in areas you’re bad at is a wonderful thing, but I also think that relying on them too much and not meeting them half way will create unnecessary blockages and inefficiencies in your work flow – you’ll have to wait for someone else to do something you could have done in 5 minutes really, and so it will instead take several hours and may be indefinitely delayed.
When I’d previously written about this I was thinking in terms of different types of development, but it now occurs to me that exactly the same problem occurs when developers work with non-developers.
So, people who work closely with developers: What are we bad at that you’d like us to meet you half way on? What would it make your life easier if we all got a little bit better at? Can you offer concrete advice on how to do so?
Hard question to answer – quick wins would be cleaner, leaner HTML markup and an understanding of CSS selectors so that we avoid an identifier on every. Single. Element. On. The. Page. When targeting the default html <a> nested in the is absolutely fine, thanks.
So in effect, actually do less, but better.
Bigger picture, (and this may just be reflective of our development environment) is a willingness to go with a feeling/gut instinct and see if something will work, without the rationale being explicitly, logically, empirically fathomed out first. Intertia kills.
hmm. I think the gut feeling thing is culture specific – I’ve also encountered a lot of the opposite problem amongst fellow developers where people were unwilling to take the time to think things through and just went on gut instinct all the time. It wasn’t pretty.
The HTML one is an interesting one to me, mostly in that it’s not a problem I’ve ever actually encountered! But I tend to work in contexts where most of the front-end work is done by people who are both competent front-end developers and competent designers, so maybe that’s why?
Probably shouldn’t have thrown HTML tags willy-nilly into that response – kinda underlines my point though in a strange way.
Technically it was behaving correctly (and the software did close your tag at the end of the post), but I’ve fixed your markup for you. :-)
Most of the problems I’ve observed aren’t so much things developers are doing wrong, as problems that developers could solve by changing their behaviour. Almost always, the non-dev side could also solve these problems by changing their behaviour, too, though.
With that caveat, here’s my list.
– Be explicit about what ‘done’ means. Generally, non-devs will assume ‘done’ = I can use it right now. Devs might mean “I’ve done the story, now I need to do the tests”, or “waiting for deploy” or “waiting for QA”.
– Explain why [complex technical thing] is important, in terms a non-dev will care about. It’s not about translating technical speak to a Cliff-notes version: it’s about explaining the non-tech impact.
As a product manager, I spend lots of my time arguing for the business benefit of development work that doesn’t add new features: we need to do this because 2 days work now saves us two hours a week for the rest of the project’s lifetime; we need to do this so it’s easier to add new features to this bit in future. And I’ve spoken to devs who complain about the amount of technical debt they’re carrying and how they never get to address it, but who have never made an effort to articulate why this stuff needs to be done in terms a non-dev would care about. Side note: if you really can’t do this, maybe this work is not as important as you think?
– Find out about what users/customers want/like/hate. Developers often don’t like sales people. Which is understandable, but avoiding sales people, or marketing people, or account managers (etc) can often mean you’re cut off from how what you’re building is really used or received. The best teams I’ve worked with have stayed in touch with the end-user’s pain points and priorities, either through their own effort or through an intermediary (CTO/product owner/etc). Knowing the high level goals of a product has, in these cases, made life easier for the team building it and meant that they are able to contribute to the ideas of how to achieve those goals.
Thanks. This is all helpful stuff. Some specific comments:
I like this distinction and will use it, thanks.
Yes, very much this.
Part of the problem here is that how to interact with customers to do useful product development is actually a very hard skill that sales people think they’re good at and they’re not. A common complaint here I’ve heard is that developers want to be talking to customers and instead they’re talking to sales people, and this doesn’t always work so well.
We are bad at listening and constructive communication. We get emotionally attached to our solutions and our code. We jump to conclusions and assume things about what the other knows and thinks without verifying them. We tend to say “Yes, but”. We tell our solution, but don’t sell it and aren’t interested in anyone selling us theirs.
When there is a feature to be implemented and someone proposes a solution, we immediately start criticizing that solution if it deviates from what we had in mind. We say “that won’t work, it doesn’t wizzle the nizzle”, the other says “of course it doesn’t, it shizzles the nizzle”, you both think you have the right solution, you keep repeating yourselves, miscommunicate and things can get heated. It often turns out you had different requirements in mind, but never stated them. Or you assumed the other has some knowledge that he in fact doesn’t.
The hardest part is noticing this is happening, stepping back and going into constructive mode. It doesn’t matter which one does this, as long as at least one does it. Instead of saying “of course it doesn’t, it shizzles the nizzle”, you should ask (and the other should (come to) understand you honestly mean it) “Is it necessary to wizzle the nizzle? I thought we could shizzle the nizzle?”. Discussions may be slightly longer, but they will be more relaxed and more information will be exchanged.
An absolute prerequisite is to never get attached to your solutions. Always assume your solution is suboptimal and your colleague is a smart person that also wants the best solution implemented. Most of the time you will come to agree. If you still disagree, let it rest for a day and come back to it. Sleep does wonders. If you still disagree, pick your battles wisely. Is the difference large enough to keep contending it? Does it honestly make that much of a difference? If you always feel it does, then you’re a control freak or perfectionist and you should really work on that.