·1 min de lecture
My (quite long) journey to the backend dev peak and its hidden communication path
Auteur(s) de l'article
[Your attention please, this text has been written for and presented live at the Deliver Conference ORALLY and has been transcribed the same here below. English purists please, do not read. Or don't feel offended. At least]
I am sure there are a lot of people here like me that have been propelled in the digital world. We are commonly called “non-techie” people. You know, people who didn’t know that digital actually had its own Architects and that you shouldn’t pronounce the “webmaster” term in any way [or worst a “computer person”].
These people are often the “Techies” target right? Like “How will they survive”? Even more when you are Digital project manager.
Today I am not writing about a new tool, a new process, or how to assess risk. Not that these topics are not interesting, but I just wanted to make a little fun and bring some sarcasm [Big Sarcasm Alert] about something that reaaaaally took me a lot of energy when I began to work in the Digital world. Being more specific, I am going to share my quite long journey on the backend dev peak and its hidden communication path.
As said, the Digital Project Managers are often the developers’ target, so for once, let’s do the same the other way around.
So what’s the context exactly? Well, it’s not really hard to define:
- A team of digital experts in front of you
- A brand new job
- A lot of incertitudes
- Hundreds of knowledge gaps
- A fresh team
- A bunch of backend developers and
- A bouquet of tacit rules you’ll definitely violate one after the other.
Not to mention you’re the only woman and can’t even ask for a tampax when you need one. Yeepeee!
Jokes aside, it’s hard to enter the digital world, I am sure you may have faced the same problem.
Like coming in the office in the Morning, saying HI THERE out loud and then waiting for someone to answer you. And the magic does not happen.
Like spending your 3 first Months trying to understand the difference between the tools you’ll spend your entire time on.
And this man, the one developer willing to embarrass you and with whom you have no idea how to interact.
Kinda looks like a nightmare huh?
Or should I say the nightmarezzzzz. Because...
No no no, there were few more things I didn’t get right away:
Of course first, you have all these terms used the wrong way and misunderstood leading to awkward situations sometimes. I remember this first meeting where I had to explain to the client what is a DNS, and I don’t know why I wanted to explain this. Maybe I suddently felt able to be actor more than spectator. But the fact is I began my explanation with “I don’t know if I got it right, but this is my understanding of what this is” And then I stared at my boss after the explanation with a “was that right?”. “…My understanding”? Oh well that’s cute. Thank you Saniha for you strong knowledge and participation.
Then you have all the tools (so many tooooooools). Like you can really go crazy. Example: You have to tell something to someone. Quite a simple situation isn’t it? And NO! Why? Because you can tell this either: through Basecamp or through Highrise. Through a message on Basecamp or through a todo on Basecamp. Or through Slack, or through Trello or through WhatsApp or with a simple mail. So, what do you choose when it’s your first week, let me ask you?
My biggest nightmare was still the developers’ job. And the developers themselves. How to communicate with them. I felt like I was trying to engage with some foreigners talking a different language. I would say “What is this?” he would answer : “Das ist ein Gummi”. Except that I do speak german...
And you have to behave, act as if everything was alright. Because the developers will not help you, at first. First you’re just something really trivial. A small noisy fly. Asking stupid questions. And you get some pretty exciting answers:
"Oh the client noticed a bug? Then open the client's repo on Github, open an issue, report it as usual using What we have / What we want, put it in the right milestone and assign it to me".
[……….] Repo? Github? What Milestone? You truly think I know what you're talking about after 2 days?!?
And that’s the easy one, not to mention other words you never ever heard of before! Like PR, Branch, Merge, Bootstrap, commit, staging, etc.
Of course, “please”, “thank you” and all other polite terms are optional.
Of course, having the sensitivity to train or explain are optional too.
You can feel this in their eyes: “Hey sweetie, you should know.”
And then they continue, because otherwise there’s not enough F U N:
“Saniha, I just checked the issue, the browser used and its version are not mentioned, tell them I can’t work on this bug and fix it, maybe next week, maybe not”.
And by saying this they would add: “and can you lower the blinds, there is too much light in this room”. Of course my dear bat...
And here, in parallel of your daily comprehension “challenges”, comes another one: you are the client’s contact. Nightmare number 4. How do you communicate all this? What’s the best way to notify your client that the developers just post-poned their work on a major issue because of a missing browser version? And how do you vulgarize what you don’t understand?
Because coming on development, there is a lot to vulgarize, so to mention:
- The developers answer questions (when they actually do answer)
- Their explanation on a bug source - "There was a string interpolation in the wrong context" WTF?!
- The developers saying ’ “The answers’s no” to new features request - “Why does the client want this feature, what’s the goal? Oh it’s political? They just want to implement it? NO, it’s useless. Won’t implement this, ‘tell them”.
See the problem? That’s the reality, Developers have unlimited resources in term of code and logic, way less in term of emotional sensibility and empathy. Sorry dudes, that sounds fully cliché, but hey let’s just face it, lots of developers just seem to enjoy being the engineer archetype. Right there you have 2 choices:
- Slowly but surely lose your self-confidence
- Sing and pray for hope (and work on it) [Work work work work work work.]
- "Every problem has a solution"
- "After the rain comes the sun"
- "At in the end everything will be alright. If it’s not alright, it’s not the end"
- "Worrying will never change the outcome"
A lot of nice sentences can motivate you. Still, this will be useless if you don’t FEED hope and put some energy and work to support it. Empowerment isn’t a moto to repeat, it’s an exercise to apply and train for. Because real life is not a Walt Disney movie. Things don’t go better like a magic Jack in the box jumping and laughing out loud. You don’t suddenly understand Developers' "hello world"!
So that’s what I’ve done first. Work led me to hope. Hope led me to work harder. I knew I had the abilities to learn. I knew I had the abilities to scan and understand my work environment. I knew I could win confidence and trust and, cherry on the cake: respect. And most of all, and sorry for being a badass poser, I am a good Project Manager. I tended to forget this. Suddenly the challenge, yes the challenge, came as an evidence. I just had to do what I loved doing. Being a crazy and annoying cameleon. And it’s not some hard to scan Backend developers that would make me miss this next chapter of my life. Word after word, tool after tool, conversation after conversation. All was becoming clearer. I understood. Exchanges were then smoother, and I was quitting the world of the “In any case she doesn't know what she's talking about”.
As a matter of fact time can be your worst enemy sometimes. It can also be your sunlight, believe me. I won credibility. Hope had turned into something more valuable and tangible: learnings.
Speaking about learnings, “They” were a lot, and here come my 10 commandments list:
1. Back to the basics
If you want to fit in your andience, learn quickly the basic words, in that case UX, Wireframes, Usertests, Userstories, Github, Frontend, Backend, Responsive, Issue, pull request were a good MVG (for Minimum Viable Glossary). Personas, Dynamic Styleguide, Gestalt principles, Webfonts and Bootstrap can come as v2.
Avoid the terms thing, stuff, thingummy, thingy, thingamajig, you have techies in front of you, behave!
3. Be specific
Prepare your question and define the scope before asking
4. Chatting is annoying
Choose the right moment to talk and disturb your audience. Because chatting is annoying.
5. Use the chat
Don’t just open your mouth when something is going on in your head, respect the work of others and their concentration.
6. Observation, Observation, Observation
Allow time for observation and be curious everyday.
7. Understand your audience
Understand each and every profile you have around you and learn how to talk to them. Your role is to be a conductor of orchestra slash psychologist slash analyst slash orator slash police slash mama slash motivator slash smooOoOoth operatooooor.
8. Empower yourself alone
Don’t wait for the others’ to help you and show your motivation to learn, people will then consider you.
9. Ask, don’t assume
10. Be strong or die
Well… That being said, and hopefully when you chose to live, sunny days will come! Kudos! Champagne! You did it. Feels like when you first go driving and don’t think about the clutch, huh?
Today, when I come to the office my beloved collegues and I are joking, making weird noises, they say HELLO OUT LOUD (yes I swear). We laugh, we drink, we celebrate, we are making jokes of ourselves and I don’t hesitate to tell a dev “I have nooooooo ideaaaaaa what you’re talking abouuuuuuuuuuuuuuuut”.
It seems that in the end, it doesn’t matter in which industry or with whom you’re working, you just need adaptation and patience.
Internal Miscommunication or Misunderstaning is a challenge, but you’re all stars. So let’s be strong and shine bright folks. Or shine on you crazy diamonds.
Mise à jour le: 12 December 2020