Over my years of work I've heard all sorts of things about so-called soft skills, from people in charge, from HR, and from those who are (not) expected to have these very skills. During this time I've done some managing myself: as the head of my own studio, as a hired team lead, and as the head of a laboratory.
So here's what I have to say about the most important soft skills, especially for an inexperienced developer or one who has recently joined a team. So important, in fact, that if you master them, you'll be head and shoulders above many others — even if they code better. And if you're a novice team lead, they're an absolute must.
1. Always add value
If you're given the floor at a meeting, if a ticket is assigned to you, if someone asks you something in a chat — never leave the discussion in the same state it was in before you. Always add at least a little value to it. Don't play ping-pong with tickets:
— Here, Pete, please take a look →
— Bob, I didn't understand a thing, explain it properly →
— What's not to understand, read it and figure it out →
— Spell out step by step what you want from me → …
If you and Bob regularly take part in exchanges like this in the task tracker, it's a sure sign that you both are long overdue for a slap on the wrist. Instead of continuing to toss the ball back and forth, waiting for someone to do everything for you, try:
— Here, Pete, please take a look →
— Bob, I've read the description twice and I have these questions: <a list of specific questions>
Yes, the task still isn't solved, but it now has an actionable: Bob has to answer the specific questions you formulated — you've added value.
Try to always do this. Even when you're tired and staring with bleary eyes now at the task, now at the clock counting down to when it's time to go home, grab a couple of beers and finally launch that game you bought a month ago. Didn't understand anything? Read it again. Ask a question. Don't know which one? Guess what the author meant, picking what seems closest to the text, and ask whether you've understood correctly.
And then your colleagues will know that if they assign you a task, it won't just be assigned. It will get moving.
And leave ping-pong for breaks and leisure. And add some proper value there too, if you play.
2. Be specific
Avoid generic phrases. Generic phrases are for the other guys, who aren't into soft skills, enthusiasm, a career and all that. Don't say:
— A lot of processes depend on this, there will probably be bugs.
try this instead:
— This function is used in (sending notifications, triangulation calculations, video processing, pretty much in vain) and if we change it we'll need to test these modules.
Don't do this:
— Well, I debugged again and I've got an error.
— What error?
— Here, copying it
— [censored], that's the same one as yesterday, did you do what I wrote?
— Oh, right, I'll try now…
try this instead:
— I read what we discussed yesterday, tried the new approach, the old error is gone, there's a new one, here's its text: … I can't figure out yet what it's related to, I tried checking it this way and that.
— Great, I see progress, let's figure it out.
If it doesn't work out right away, try this simple exercise: look at your text and try to imagine what question the recipient will ask you first. If you can easily imagine the question, then you can just as easily add the answer to your text right away.
3. Read everything you're given
Got a ticket? Read up on its history. Yes, yes, those four comments under the description. You can't imagine how pleasant it is to see a person who actually went and read the discussion instead of asking again the questions that were just discussed.
Read up, read through, and go to point 1.
4. Be professional
and take everything calmly. For example, if the client's displeasure, expressed rudely, has reached you through the shields of the project manager, the relationship manager and the team lead, then
— don't sweat it take offense. The client is paying money, their own hard-earned cash, dough, moolah. Every penny has to hit the target! And if something's wrong, they may well get upset and vent a little, maybe not very skillfully. That doesn't mean they meant you personally, and it doesn't mean they're a [censored]. And even if it does, so what? Perfect people are hard to find, among developers too, by the way.
— But you can sweat it. Someone, maybe not you, or maybe even you, made some mistake or didn't get something done in time. And that upset the client. Calming them down isn't your job, but why not reflect on the fact that we might be doing something wrong.
5. Follow communication etiquette
Take all these chats, dailies and meetings seriously. Don't write "hi" and then separately what you wanted, don't write 20 thoughtless messages instead of one well-formulated one. Just try thinking first and then doing — things will get better right away. Here you can read a post on how to behave in chats and at meetings.
6. Deadlines can be team deadlines
Remember this. If your team was given a task with a Friday deadline, it doesn't mean all that time was given to you personally. It doesn't mean you should send the task to your colleagues for QA on Friday at 17:50 and then run off into the night until Monday shouting "Hahaha! 1:0, losers!"
QA has its own deadlines, so send it no later than 17:30!!!11
7. Be proactive
If something was overlooked, missed, forgotten and not done, if there's a bug in the code and the architecture isn't perfect — go ahead and tell your team lead. Most likely, you'll be the only one doing so. And don't be afraid — the worst that can happen is that the team lead ignores it and does nothing. All other outcomes are better.
As you can see, there's nothing supernatural in these points. Moreover, they're obvious, these points. But try to follow them strictly — and rest assured, your efforts will soon be noticed.