Engineers, please stop pushing “tech” as a feature
I just read a related post over on CNET about something Steve Wozniak said, his point was essentially that people don’t want to know about technical advances or solutions, just the human element - I couldn’t agree more! This is something I’ve believed in for a long time (from a UX perspective and from a coding perspective) but it’s probably actually hindered my career progress since I have a habit of discussing things too informally now.
My twist on this as a software engineer (or whatever you want to call me - “developer”?) is that I’m used to working with both technical and non-technical people - so there are times when it’s hard to differentiate between “giving a technical explanation” and not doing so. For example, with a project manager or project stakeholder I’ll always make the effort to omit the technical blurb on what I’m saying.
For example, a developer says to the stakeholder - “Oh, we implemented Widget X using MVC but because you wanted it scalable we switched the backend from a load-balanced n-tier solution to an SOA implementation using WCF”. Eww, that’s just not humanised at all - I mean she doesn’t talk to you about PRINCE2, or lean-sigma principles does she?
And then we’ve opened a can of worms, because the next time I see the same stakeholder she’s probably going to try to mix in some of that technical jargon - maybe because she feels intimidated - or because she wants inclusion - or because everyone on the team uses technical terms around her frequently anyway.
The worst upshot of this is that the project is then renamed from “The Widget X Project” to “The MVC SOA project” - I’ve seen this happen and it makes projects difficult to differentiate between… imagine having a project called “The SQL project”
Why not just say “we made it faster and easier to scale” - if that’s all they asked for, that’s all they want to know. And even then, that maybe too verbose!
My point here is that technical people should only talk to technical people about technical stuff - one of the hardest things we technical people have to realise is when to STFU and listen to people. That the human-element should be one of our top considerations - I know this is difficult for most of us because it involves an element of empathy (and communication skills) - but those abilities are what enable us to better express ourselves - and are absolutely needed when talking to non-technical types.
As a last point, I should mention that I’m not advocating that we should all grow a superiority complex over non-technical types and dumb everything down - we should just talk to them like their a fellow person - plain and simple
Good article describing a scenario I have seen many times. Another drawback of this form of dialog is that the stakeholder will end up coming to the developer with a pseudo-technical solution, rather than stating what the problem is, thus missing the point.
Also, I wonder if developers are sometimes guilty of over-stepping into the stakeholders area of expertese and business jargon? If we are given a requirement that on the face of it seems absurd, should we accept it or challenge it?
I would argue it”s more worthwhile to challenge it, if a developer doesn”t understand the full repecussions of what he/she”s working on, how can we have any confidence in what we produce?
I think recently we”re starting to see more of this problem, where a spec does not fully explain the business need. I don”t think developers can afford to be sheilded from the business by PM”s or BA”s - because then we can very easily produce something that is entirely not what the customer wants.