Photo by Jason Goodman on Unsplash
Stakeholder Management Tips for Developers.
What I've learned so far...
Introduction.
"Developers are so annoying,"...a common rhetoric mostly held by well, not developers.
Many people dread working with developers; Product managers, UI/UX designers, clients on contract, and other developers...the list is long. If you're reading this as a dev, you probably have multiple reasons why the fault isn't with the developer but the unrealistic expectations from the *insert annoying role that you hate to work with as a dev*.
Annoying co-workers aren't going to change(on both sides of the divide), but maybe, just maybe, the tips listed here would help improve our working relationships with our stakeholders as developers. Why is this necessary?
At the end of the day, what people will remember is how they felt about you through the entirety of the project, regardless of its outcome. Were you a team player, or an opp?
Another reason is that the best jobs are usually referrals. How can you get referrals if people don't "like" you? You see, in the business world, being liked is a very valuable currency, a currency a lot of technical people don't seem to prioritize, or think they need. Sometimes, it's literally what separates Seniors from Mid-level and Junior devs.
In this post, we'll be looking at how we can hone our soft skills to ensure we leave our stakeholders with good memories of us, or at least, without them doubting our proficiency. I'm still learning myself, I mess up multiple times, but I'm getting better. So can you.
Who is a stakeholder?
Based on this definition from TechTarget(no affiliation):
A stakeholder is a person, group or organization with a vested interest, or stake, in the decision-making and activities of a business, organization or project.
Who are your stakeholders?
Everyone with a vested interest in the project or task you're assigned. Your manager, the QA guy/gal, the PM, the design guy, and most importantly your users. That's a long list of stakeholders to manage! 😮💨 let's get to it then.
The Tips in question(finally):
Give updates before being asked:
This could save your butt a ton, especially when the blocker isn't from you directly. Technical issues, a colleague with a crucial piece of info you needed that aired your message. Whatever it is, don't wait till you're asked before you give the update.
An angry but informed stakeholder is better than an angry and ignored one:
Your stakeholder has asked for updates, you're panicking because you're not where you promised you'd be, in other words, your E-T-A did not E-A-T! What to do? Still, give the update! They will huff and puff, it may dent their image of you in the short term, but it's nothing compared to you being unreachable! You can always buy more time, a ruined image? Way more expensive. Ask billionaires.
When you’re dependent on others, double-check and triple-check their work(politely):
This one bit me in the butt not too long ago. I got assurance from someone I was working with that a certain task was done(not coding-related). I even confirmed once more with him and he, slightly annoyed, assured me again. A week later, with hours spent debugging, and one very angry stakeholder, we discovered that he didn't do the task appropriately. As a bonus, I discovered that the next task on the list I had got assurance for, also wasn't done. I was livid. I had to take the brunt of the blowback. Lesson learned. You need to be a little persistent (and annoying) to get some things done. That's the price of getting it right! That's being a Senior. You don't have to be an asshole about it, no, but be firm, and thorough.
Don’t be scared to ask for help even if it would cost you:
There are times when the amount of information you have about a task is limited or unclear. You claimed you understood but you didn't. Asking, especially when the deadline is close would make you look incompetent and unserious. Guess what? Still ask. Take the blame, which is rightly yours, get over it, and get started. The success of a task or project should always be more important to you than your ego. They may not remember your dumb questions, but they'll remember if you missed your deadline. Better to look dumb in the short term than to fail overall.
You won’t always get it right, be kind to yourself:
On the path to becoming a Senior, you would make many mistakes. There's no Senior without battle scars, ask them. So remember on days when you drop the ball: be kind to yourself, and keep trying to do better!
Team synergy and Effective Communication is better than a 10x dev from hell:
Your output won't matter if no one can get a hold of you during time-sensitive moments. Yes, slack notifications are annoying and take valuable time away from problem-solving. However, you still have a responsibility to communicate. I don't think setting a 5-minute time slot every hour to check your work messages is too much to ask.
It is better to over-explain than to under-explain:
I learned this from one of my line managers I respect. Every update he gave to a stakeholder had a well-detailed, verbose answer. None of the parts of the message were redundant or repetitive though. I think this is a good strategy to apply. It is better to give all of the information than to give bits that don't paint the whole picture. However, remember to eliminate redundancy from your messages! Detailed, but concise.
Don’t be scared to push back and give realistic timelines, not doing so could cost you:
Sometimes, your stakeholder, who probably has another stakeholder demanding the extraordinary from them, would attempt to pressure you into working with a tighter deadline than is realistically possible. Please, for all that is good and pure, push back. If you get roped into giving unrealistic deadlines often, you'll damage your image in the eyes of the people depending on you. "They get it done but take time" will always be better than "They're incompetent, never keep to deadlines". Always.
Be empathetic to your stakeholders. Everyone has a boss and key metrics to deliver:
Sometimes we let our egos get the best of us. We forget that the annoying manager, product manager, QA engineer, or Scrum master, has a boss. This isn't done. Yes, your task is a lot, but being a dev that people love to work with means taking ownership. This comes at a personal cost sometimes. I confess this is something I'm still learning to do, I fail at it too. However, it is necessary to see the big picture. They're not "stressing you" because they want to. Everyone is there to do a job, try your very best to ensure that you don't drop the ball when it's in your court! Always ask yourself: How can I make my stakeholder's job easier?
Practice:
Managing stakeholders takes practice. Your emotions will be tested. Commit to becoming a joy to work with and see glaring reviews pour in!