Opinions and decisions, how to be a successful team mate

Opinions and decisions, how to be a successful team mate

I have been working for more than 8 years in the software industry and have dealt with loads of developers from junior to senior.There are multiple points which can make a successful team mate. One of them is knowing when to express opinions and when to take decisions. One thing I have learnt is that decisions, forcefully agreed on, will most likely not be respected by the team. I also learnt that decisions come from opinions and the way we express opinions will dictate the level of respect team mates attributes to you and the level of trust they place in you. Just like in sport, respect and trust are the most important values to have.
Today I would like to explore the different scenarios where we, as developer, should express our opinions and also when should we, as developer, take decisions.

1. Opinions

Those are rules that I have followed and which have lend me into building lasting relationships with team mates.

There are two rules which I try to follow as much as I can:

  1. Do not be ashamed of not having any opinions. And especially do not invent fictive opinions and arguments to defend fictive opinions.
  2. Do not invent position to defend personal preferences/self interest which do not align with the business.
  3. Do not defend your opinions because of fear of not knowing how to deal with others opinions.

It might seem logical to follow those points but it is actually harder than expected because of human nature.

Most of us are ashamed to admit that we do not have opinions on certain subjects because we fear of being seen as useless.
Most of us rather defend personal goals than goals which contribute to the business.
Lastly most of us do not wish to understand or make the effort to understand other members opinions but would rather stick with our owns.

In order to be in peace with others and ourselves, we need to think before letting our instincts take control. Opinions are extremely important as they led to decisions. Therefore pay extreme attention to their origins.

2. Decisions

When working in a team, decisions and agreements happen all the time.

Similarly to opinions when you do not have any preferences, it is ok to not decide. If you feel uncomfortable letting others take decisions for you, think of it as if you were “delegating the decision to someone else” instead of “letting someone decide for you”.

Now let’s see some situations and how decisions can be agreed on:

  1. If a trusted entity wants to decide and you do not have any opinion, accept the decision.
  2. If a trusted entity wants to decide and you have an opinion which contrast the decision, share your opinion and make the other party enlight you, or enlight the other party, on the pros and cons of each possibilities. Make sure to end up on an agreement which both parties are happy with. Do not let doubts come in.
  3. If you are convinced that your decision is best and people expect you to take a decision, share your decision and take it.
  4. If you do not have any opinion and people expect you to take a decision, figure out steps to guide the team to help you find a decision.

The last point is the most important to not break the trust people have placed in you.
When people expect you to take a decision, make sure you do everything possible to come up with one. If you can’t, make sure you have a plan on what to discuss to guide you to take one.
The key point is to remember that your team mates have their own decisions to take and that this particular one was delegated to you so that it would ease their sides. By not coming up with a decision, you are overloading them which will affect their trust in you.

Conclusion

When working in a team, it is important to trust and respect your team mates. Whether junior, middle level or senior, everyone diserves the same level of respect. Lack of knowledge should never be penalized, therefore we should not be afraid of admitting that “we do not know” or “we have no opinion”. “I do not know” is different than “I do not care”. Respecting team mates and earning their respect is the most important value which one needs to have for her decisions to be followed. Hope you liked this post, let me know if you have similar experiences which I would love to discuss! See you next time!

Comments

Post a Comment

Popular posts from this blog

A complete SignalR with ASP Net Core example with WSS, Authentication, Nginx

SignalR with ASP Net Core SignalR is a framework from ASP NET Core allowing us to establish a two way communication between client and server. This two way communication allows the client to send messages to the server but more importantly allows the server to push messages to the client. SignalR makes use of Websocket when available else it falls back to SSE or pulling. Today we will focus on how to setup SignalR to work with WSS, Websocket secure and how we can authenticate the user requesting to connect to our SignalR hub via Webscoket. Getting started with SignalR SSL encryption for Websocket Secure WSS Websocket Authentication with Identity Server 4 SignalR behind Nginx 1. Getting started with SignalR The Hubs are the main components of SignalR. It is an abstraction of a two way communication available for both client and server. Public functions from the hub can be called from the server code and can be called from the client. The frontend NPM package @aspnet/signalr
Keep reading

Microsoft Orleans logs warnings and errors

Microsoft Orleans logs warnings and errors Microsoft Orleans is a framework which helps building distributed system by implementing the actor model together with the concept of virtual actors, taking care of availability and concurrency. If you are unfamiliar with Microsoft Orleans, you can look at my previous blog post explaining the benefits of Microsoft Orleans . Even though Orleans promises to abstract the distributed system problems, there are instances where errors arise without us being able to understand what is going on. Lucky us, the logs are well documented… but only for those who can decrypt them. Today I will go through some of the errors and warnings which can be seen from silo and client so that you too can undestand what is going on. Enjoy! The code used to produce those errors can be found on my GitHub https://github.com/Kimserey/orleans-cluster-consul . 1. Client logs Logs on client appears with address {ip}:0 . 1.1. Can’t find implementation of interface An un
Keep reading

One way to structure Web App built in F# and WebSharper

Image
Architecture for Web App built in F# and WebSharper F# + WebSharper is an awesome combination to build web application . The only problem is that if you want to build a web app larger than a to-do list, it’s hard to find examples to use as references. It is even harder to find tutorials that touches on overall design and answer questions like: How should I start? Where should I put the code? How should I separate the code, put it in different files, with different namespaces or modules? How many layers? Asking these questions at the beginning of the development is important. All these questions if answered correctly will lead to a good structure for the application. Answered incorrectly, or not even asked, will most likely lead to unmaintainable/fragile/rigid (or whatever bad adjectives for coding) code. Over the last few months, I have been working on a web app built in F# with WebSharper and came out with an architecture that caters to extensions and decoupling. Today, I wil
Keep reading