A lot of us are techies right? We love the technical challenges, how our products work, solving problems, designing/developing/improving systems? Right? A lot of this work will involve interaction with others, team members, management, customers. The way we behave with this interaction, both directly and indirectly can have large implications on the quality of our work, how we are perceived and subsequently treated at work.
I'm a HUGE advocate of soft skills, we need these to be able to make use of our technical skills in the best way possible. In a way, this is a follow up from my first ever blog post:
We all have our (ad)vices. (sqlrod.com). Don't be comic book guy.
This isn't a technical post in the slightest, and I apologise in advance if any of this comes across as preaching, that certainly isn't my intention (and it's my first point). More of the things I seem to do naturally by being helpful, and seeing it help the workplace for many, not just myself.
No matter what I ramble on about below though, your workplace policy is the boss here, follow that first NOT anything I say below. This is purely my observations from experience and how I naturally behave. None of the below will magically allow you to change the world, but every little helps. Some points may not be for everyone, and I fully accept that too.
General Advice
Don't preach at people.
There are a lot of VERY clever people out there, with a lot more experience and technical skills than you or I. Simply preaching at them as you feel that you know/have the answer or are right often causes people to dig their heels in and resist. Explain your reasonings why you think something is/should be the way it is, or why you think someone else may not be correct. Note the use of the word think there... the two statements "You are correct" and "You think you are correct" could ultimately be the same, but could be poles apart. However the perception of the statement is a lot softer, which counts for a lot.
This has served me well on many occassions, particularly when in a consultative role where i've been shipped in to assist with something? Existing staff have been wary, but something as simple as talking to them, and not at them has allowed the barriers to drop, as they realise i'm there to help and not steal their job.
This same advice when talking to less experienced / junior staff. Yes, they may not be as experienced, but don't stifle their enthusiasm by preaching. Encourage their ideas, and explain why something may not be correct/optimal etc. If it is correct, then make sure the credit is given (see below).
There's always someone smarter than you.
*Maybe apart from some of the people I had the pleasure of working with in SQL CSS at Microsoft. Wow, scarily clever and completely humble with it.
Don't put people down to make yourself look good.
This particular statement makes me feel bad even saying it. Teamwork is not a competition (usually), you'll get more things done, in a better way AND all in a better work environment if you get on well. Putting people down will only serve to form barriers between you and your peers.
Give credit.
If someone has done something well, whether it be created a solution, fixed an issue, or even simply came up with a good idea that noone else thought of? Let others know that it came from their mind, not yours. The simpliest actions like this often get team members working closer together as it builds on trust. This is particularly of use to junior members or those with less confidence.
Don't steal credit.
On the polar opposite to the above, if one of your colleagues has done work, ie... solved and issue, developed a solution, don't say, suggest or even imply that the work is yours. Why? Well, first off, its just unfair...they've done the hard work, so they deserve the recognition for it. Secondly, if there are issues, questions or just incompleteness to the work, and you don't have the background as to how or why something has been done the way it has been done, you're not going to be able to answer with any conviction, and end up looking stupid. Thirdly, its the fastest way to alienate you with your colleagues. If they lose trust and respect because you are trying to make yourself look good at their expense? (oh look, see above)... team work vanishes.
This applies more to your direct colleagues, and less to research that you've performed for your own work solutions. You can always send a message to the author to say how much they have helped you. If you are posting in the public domain, ALWAYS give credit to anyone else's work that you've based your work upon. Provide links if at all possible to their work/bio too.
Email/Chat Etiquette
Remember a time when we had a phone on our desk? Remember the time we had our own desk for that matter? "Speaking" to people over the years has become less personal, by that I mean far more text based, and far less talking.
I'm not saying DM/email is bad, far from it, its a magnificent convienent tool. Just that we need to be careful with what we type, for several reasons.
Context can easily be lost in what we are saying.
The general tone of the message may be misinterpreted.
Shortening messages can come across as stern and potentially ignorant.
An occasional emoticon in a chat message can go a long way here to get across your meaning. Hashtag smiley face.
A couple of other DMs observations.
Try to avoid one word answers, it comes across as ignorant (would you do that in a phone call and then hang up?). It takes 5 seconds for a couple of extra words in an answer.
Don't "machine gun" DMs to a person one after the other, all it serves to do is distract and annoy them when they're being notified every second and are trying to concentrate on something. If you have several things to say/ask, concattenate them into fewer DMs.
If someone is on Do not disturb. Try not to, unless the building is proverbally on fire.
Not a direct tip, as it seems to fly in the face of the above, but check out https://nohello.net/en/ . Its effectively a brief set of guidelines on ways to help DM interaction. Basically avoid splitting pleasantries and questions up into multiple messages. It seems odd at first, but works really well. By the way, i'm not saying NOT to put pleasantries in messages, I WANT those in there, just put them together with the reason for the DM.
A call can do many things to address the above as context and tone of voice automatically potray such things without us even trying. I'm definitely not saying replace all of your emails and DMs with calls, that isn't feasible, just be wary in how you come across when using those tools.
Offering Input in meetings
How frustrating is it? Being on a Teams call and hearing silence with every question that is asked, or no opinions given on a discussion? Almost makes the person running the meeting seem like they are talking to themselves. If its a meeting that you have a vested interest in, can you give feedback and ask questions? Or even just clarify that you've understood/agree? Granted, i'm sure many of us have too many meetings, and an email could have replaced some of them, but try not to use meetings as focus time for other work.
Camera on in online meetings
Try it. You'll be amazed at how much better interaction you'll get in meetings. It may also focus you on the meeting as well, and not getting sidetracked with other tasks. Just be careful if you're working from home and have offensive slogans on your coffee mug those...
(The truth is on this one is that I like upsetting colleagues by making them look at my ugly face. 😁)
Helping the new hire
We've all been there, first few weeks. You don't know systems, logins, processes, even urls to use. It can make the new person feel a bit helpless and overwelmed. A simple 2 min run through of how to do tasks can get them up to speed quicker, build good team work bonds, AND only take a few minutes out of your day. If your company has a 'buddying' process, then don't skimp on it, help them out.
Admit if you don't know something.
We don't know everything, we can't be expected to know everything, or have immediate recall for everything we've previously learnt. Don't be afraid of that fact, 99.9% of us are exactly like that too. So, that said, if you aren't sure of something, then say so. Let people know that you need to refresh your memory on the matter, or do some research on it. Be careful pretending to know something, particularly if its not your area of expertise as there will be others who do know it, and you may be speaking to one of them.
Be sensible with your Admin duties.
This one isn't related to soft skills as such, more of a case of being sensible in my opinion.
We all have those administrative tasks as part of our roles that we don't enjoy, but the thing is that they are usually really quick things that we can perform, AND there are other members of staff who are waiting for this information. Don't put them off when you have a quiet(er) moment. Remember, the same admin people may be the ones who get your timesheet signed, or chase your expense approval.
Working with other Teams
This is often an area where friction occurs, especially when teams are remote. We don't have the luxury of an issue always being obviously related to a single technology. For instance, a slow SQL server may or not be SQL itself, it could be IO related. So from there, is it the SAN having issues, the load, the bits of cabling between, sunspots, the chaos monkey or anything else for that matter. When involving other teams in investigations, give them the reason WHY you'd like their input and you think it may lie within their area. Supply a little bit of performance data if you need to and a couple of lines explaining exactly what they are looking at. You'll often get a much better response than just throwing the incident over the wall to the other team's queue with the update "SAN is running slow".
Politics
*sigh*
I can't avoid this topic, as much as i'd like to. Often, our workplaces have a level of politics that we have to navigate. Whether that be siloed teams, split responsibilities, a blame culture, it doesn't really matter, we're part of that system.
We're on the same side.
We all want the best outcome for the company that is employing/contracting us.
Playing games and being deliberately obtuse/unhelpful doesn't get anything achieved.
Obviously, this isn't all you, there may be others wanting to get ahead at the expense of others (you) via politics, always be mindful of that fact. I've used the the line "I have zero interest in politics" countless times to all levels before now. Don't be afraid of saying that if you feel the need to.
Management Interaction
Querying
The boss is the boss right? What they say goes, as they have the power to end you. Right? Well yes, and also no. For the simple mundane tasks, yes, do what is asked of you, when it is asked. But, there may be times where they may not understand the impact of something being done at the technical level? ie...If they want something performing that you know would cause say, concurrency issues, or just impact the performance\availability of something more critical, then its prudent to resist that request, as long as you explain to them why, and what would\could happen if you did as they ask when they ask it. You may get overruled, but then fine, you've at least tried to highlight risk.
Options
Don't only offer one option, unless there is only one option. Us techies often get caught up in exactly that, the tech... Management may have to balance the bigger picture, including cost. If you feel that there is only one option, explain this, and also why there is only one option. There may be other options that you don't feel are feasible? Explain why if possible, and that you wouldn't recommend them, again with the reason why. It may be supportability, reliability, anything.
One thing I've noticed is that cost may not be a reason to rule something out? Just say it as exactly that, it's expensive... Or its cheap.
Costs
While we're on the subject of costs, I'll ramble on about that. Stop and think about what is needed for a system to meet it's requirements. Note, I said 'needed' there and not 'wanted'. It's easy to over spec systems, both in resources and software editions to cater for load and growth without actually thinking about it. Is it actually needed? Granted, resources are much easier to rescale with virtual technologies, but it still costs. This is particularly true for the cloud, performance comes at a price and is far more visible, so getting into a need mindset rather than want mindset will help.
Is this a soft skill? Not directly, but having budget in the background of our thought process may not be a bad thing to do. Budget may not be an issue if you're lucky, but it's far more frustrating to get a design / recommendation dismissed because it's deemed too expensive. Sometimes keeping your powder dry until there's something expensive that is needed.
Also, be careful playing the needed card too often if you can help it. But if you must, then explain why, and what would/could happen if it doesn't happen. If its a 'could' happen rather than a 'would' happen, then also supply the chances of that happening. It's all needed in the decision making process up the management tree.
There will be loads more little things that haven't come to mind and the post is far too long already. Nor is it a list of rules of what you should do, thats completely up to you.
Helpful Rod
Comentarios