In my last two articles here and here I provided anecdotal experiences from my past highlighting things you shouldn’t do as an employer or developer. I considered these aspects as a form of “cold war” against each other.

In this article, I’d like to highlight the positive outcomes from the last two articles and what I’ve learned from them. Again, I hope that people from all sides of the community can learn something.

Respect each others time

I think this is the most valuable recommendation I have learned. Respecting time can go both ways and it can end up being invaluable.

For employers, it can mean trying their best to avoid scope creep and keeping requirements sane. It can mean not setting unrealistic deadlines when at all possible. It can mean not asking too much from your developers in terms of their time on any given day, week or month.

For developers, it can mean not over engineering solutions. It can mean giving yourself proper time outside of work for your social life. It can mean being honest about time estimates.

Help each other learn

This is also a pretty important factor, in my personal opinion, as it goes both ways again.

For employers, this can mean being very clear about the business requirements of a task and the ramifications to the business. It can mean explaining how certain aspects of the business work outside of the technology stack. It can mean giving your developer(s) an opportunity to use something or execute something different than you originally intended.

For developers, this can mean learning how to respectfully counter business requirements on a project. It can mean helping the employer to understand something from a technical aspect. It can mean being honest about time constraints or resource debt and why those are going to cause a problem.

Positively reinforce each other

This one is slightly a “catch all” because you can apply a lot of this article into this topic. But some specific areas come to mind.

For employers, it might be something simple like providing proper credit for a job well done or meeting a deadline or going under budget. Honestly, it’s simply communicating to the developer (and this extends to any employee relationship) that they’re on track. Developers can be insecure, even if they have big egos, so a few good words when it’s earned actually goes a long way. You’re helping the developer feel successful and it encourages them to keep driving.

For developers, you may want to consider what kind of feedback you’re giving to your employer. When was the last time you thanked your employer for the cool work they paid you to do? I have a few work relationships that have, over the years, turned into friendships but it took this level of back and forth communication to get there. I couldn’t expect to hear a “job well done” if I didn’t say “I like working here” or “That was a fun project! Give me another!”.

Actually give a crap about each other on a personal level

This sort of extends from the last topic.

Social skills are, in my personal opinion, an art. I am an introvert by nature and I find social context difficult to deal with. I fight very hard to battle those feelings.

Whether an employer or a developer, show some interest in each other. My new baby is a talking point a lot. Take notes about things you talk about with others if you have a hard time remembering.

It’s difficult to see the 1:1 relationship between social activity and your programming but I guarantee you there is a relationship. When you feel connected to the people you’re working with, the difference is huge.

Respect each others expertise

This is pretty plain and simple.

As an employer, if you could create the website or system you’re asking your developer to create, you would probably do it. You probably wouldn’t ask a developer to do it. It’s like asking a building contractor to build you a house and you’re a pharmacist and you come in and start telling the contractor how to build your house. Your developer isn’t wholly ignorant. They have skills and experience you probably don’t. Respect it and have some faith in it.

As a developer, you have to step up to the plate too. You need to be honest about your own limitations in your own experience. Don’t carry an ego. Don’t be a know it all. It’s ok to say “I don’t know how to tackle this” or something along those lines. Furthermore, it’s very beneficial to dive into the business you’re working with and understand it. It goes a long way to executing your own code and engineering it.

Challenge each other

Yes! This is ok! It’s ok to debate about approaches. It’s ok to argue, even. It’s ok to stand your ground or to give in when a good case is made.

When you’re both challenging each other with constructive feedback you will not feel like you’re arguing. It can be a rewarding process and you both learn a lot through it.

This happens to me and a friend I often work with. He’s a product owner type of guy and I’m the developer. Sometimes we argue about a user experience feature or an SEO item. I will have one approach in mind and he will have another. It’s up to both of us to win each other over. Really think about that term.

Win each other over.

It’s not “Show that I’m smarter” or anything along those lines.

You want to get someone to be on your side and see the benefits. Of course, this means you need to be open to jumping to the other side!

Communicate like your life depends on it

This is a big one for remote teams as well.

I was leading a team of about 12 people at one time. One of them was in Australia. He communicated every two or three hours. Like clock work. Even if it was just to say “No updates since last time, just bashing code out”. At first, I was annoyed at the amount of messages I had to read.

I quickly, very very quickly, changed my mind on that stance when I had a team member who wouldn’t talk to me for a day and then, at the end of the day, show me what they had done and they were way off the mark. I would much rather be pinged every three hours and see what’s going on then go 8 or more hours with anything and be very concerned at the end.

For employers this can also go the other way. Communicating probably comes in the form of explaining requirements or why you have a timeline such as you do or things of that nature. It’s a bit of a different mindset when you’re talking about communication from an employer but it’s just as important. You need to be able to help your developer(s) understand your needs so they can provide the right answers for you.

Conclusion

Overall, these are just a few of things I have personally gleaned from my past experiences. I hope these help someone else out there.

Thank you for reading my articles and please feel free to reach out to me if you have anything you want to say or ask me or if you just want to shoot the breeze.