I am an emotionally challenged developer!
I’m not the most socially aware person in the world. I can be abrasive, totalitarian, “direct”, antagonistic, and even a plain ol’ asshole sometimes. Am I a bad person? No! Do people like me? Apparently - they invite me to lunch, drinks after work, ask how I am and generally want to be around me. I’m just saying that I have my strengths and weaknesses as everyone does. It’s important to be honest about these and if you’re confident enough to admit it to yourself, then try sharing it with a colleague - you’ll be amazed at the strength it can add to your working environment.
So here are my three tips for being more effective in a team. These are especially useful to those who might find it harder to integrate into a team in a non-technical capacity –
- Talk with your peers.
- Join them for lunch.
- Buy them coffees.
- Let them buy you coffees (especially important for those of us who struggle with receiving gifts)!
- Be patient during discussions, even when things are frustrating you.
- Remember you don’t always need to win. Teamwork is about compromise just like every human relationship is. And for clarity: working in a software team is a collection of human relationships. Yes, you do “do ships”!
- Try to participate as best you can. If you’re introverted, then it’s important to share your ideas and opinions occasionally. Others need to know you care if only a little. Please try to join in.
- And always remember: don’t interrupt others! It’s so rude. Respect is a cornerstone of human interaction. If you cut others off a lot or talk over them, then please begin to listen to yourself. Listen to others first who do it if you can’t hear it from your own mouth yet. It’s important to chip away at this one. And if you do manage to bring this under control, you’re not going to have others copy you because you’ve suddenly started to be polite. But that’s ok.
- Share something about yourself with your peers. It doesn’t have to be in a group, it might be just one person you seem to trust a little. It doesn’t have to be “my marriage is failing” or “my pop just died” but it should be something that reveals a little about you and that you don’t “have it all together”.
- Show others you’re not perfect. “Nice catch” - on a Pull Request; or “my goof! I’ll fix the broken build”. In other words, it’s ok to show that you make mistakes. These are somewhat unnecessary from a pure knowledge transfer point of view, but we’re not dealing with machines here. People want to know that they can identify with you, that you’re human, imperfect and fallible like they are. It helps you to be more likable, and you do want to be likable.
- Ask for advice (even if you need to fake it a little). Find a way to have the junior dev help you even if you consider yourself far more experienced. It will not only boost their confidence but help them to trust you more. This is especially handy when you need an extra ally when you propose that massive refactoring you’re sure will reduce technical debt.
Give Something Back
- Your time - pair with someone; offer to review more code; take more time to explain your passions, points of view and reasons for the preferences you’re so driven about.
- Buy coffee or donuts (or vegan “power balls” that are free of gluten and flavor). If you don’t have money, write a post-it for a peer thanking them for their help yesterday. Just don’t make a show of it to others.
- Shout folks a lift to the restaurant for lunch; pick up a colleague walking from the bus stop because you have the car today; offer to carry their gear to that meeting when you can see their hands are full. You’re a kind person remember - you can show it by giving.
- A handy productivity tip, a funny link in the #random channel (everyone could do with smiling more), a kool sticker for their laptop, a new mouse pad (hahahahah! got ya! no one uses mouse pads anymore!), or just a high five at the end of the successful deployment. booya! Yes, it’s ok to touch other humans in the office if it’s appropriate. High-fives are definitely appropriate when you’ve cracked that bug, deployed into PROD or received that awesome feedback from the customer.
Most of these are easy and things you can learn. They can be taught - if you’re unsure, ask a peer for help (#bevulnerable), and they’ll probably respect you more for it. Furthermore, I’m not a master of these either. They’re a daily challenge, but one I’m willing to work at. I hope you can think of it that way too.
That’s all I have for today. I’m going to head off to a team lunch soon and try to put more of these into practice.
This was cross-posted to LinkedIn - feel free to share.
Special thanks to Azella, Matt N and Ronnie for reading drafts.