Skip to main content

Why you should never put a junior in a team that is stressed and bad-mannered

It is nothing abnormal for a team to be stressed. During that times they might not have time for nothing else. The focus of the team is to deliver the business requirements in the IT solution. Unfortunately, this time periods can be longer than expected, even if we know that this is not good.
I saw teams being more than 18 months in a phase like this. After a while in this state, they don’t even realize that they are in this state and what is the impact and project and people level.
In this post, I will try to focus on the impact that such a phase can have at juniors and mid-levels in unhealthy teams.

Why?
When you are a junior you are in moment of you carrier when you want to learn. You know that you have things to learn, you are usually a fresh graduate with good theory knowledge and you want to put this in practice.
I like to compare smart juniors with birds that have big and powerful wings, but they don't know to fly very well yet. They can reach the sky and accomplish many things if you offer them an environment where they can fly and develop.
A similar thing is with a mid-level. Even if they have autonomy, the level of knowledge and autonomy is not 100% and they need the support of the team (not as much as for a junior, but still you need to support them).

Things can go ugly
When you put juniors and mid-level people inside a team where level of stress is high for a long period of time you can do a lot of damage on both sides.
I observed that after a while people that are stressed can change. From the nice person that everybody know they are becoming focus only on projects, with a big lack of time. They are on the run all the time. They don’t have time anymore to enjoy their job and help others to learn. Because of these, the time that is allocated to share their knowledge at projects level decrease and tends to be zero. They don’t have time anymore to offer help.

If this is combined with the wrong mindset at team level and you add some juniors, it is like adding them some stones in the back. This stones needs to be carried together with them all the time.
When you end-up in such situations, you realize that if you requests from a senior 10 minutes is already a lot and 1 hour is an eternity. The funny thing is that they prefer to do the job by themselves than explaining and offering support to a junior that could to that job.
In this way, you end up with a team where most of the senior stuff is not only stressed but they are doing the easy tasks because they don’t find time to explain and help the juniors.
Of course, the juniors are feeling this and start to avoid requesting support from the team. In such an environment, they end up searching for a solution for 1 day even if with the support of senior person they could solve it in a few minutes and learn how to do it.
If the senior people would offer support to the other team members then the seniority level of the entire team would increase, allowing them to be able to deliver more value in a shorter period.
You might lose 1 hour today to explain a flow, but once the other understand it, they will be able to deliver tasks that are more complex in shorter period of time. Not only this, but you – as a senior – will have more time to focus other problems.

Who should take action?
When you observe such a behavior avoid pointing a person. I would expect that the Project Manager or Scrum Master are the persons that observe this behavior and take actions. Even if you would say that, the senior people should be the one that observe such a problem (including Project Manager and Scrum Master) there are big chances that they are to focused on the project itself and to ignore the other things that are happening around them.
In the end, any person that observe this behavior should go and discuss with one of the senior people that is more open and ready to listen them.

What we can do?
Be careful how you attack this problem. Going directly to the team and saying something about this might offence them and create a negative wave between them. You might even end up with a team that splits.
You might want to have different approaches, based on people personality. For some you might want to discuss with individuals about how they might need to focus also on sharing and offering support. Not because it is needed, but because otherwise they will not have time to focus on more important things. For others you might need to go and putting as a task to offer support.

Goal
The main goal should be to have a team where people make time to support and help others. Even if you have a lot of on your head, you need to find a balance between how much time you focus on your own task and how much time you give support.
The right balance is different for each of us based on our roles, skills and projects, but I think that seniority should come with 3 things:

  • Knowing to delegate tasks
  • Offering interesting tasks to others also
  • Make time to support other team members


Final thoughts
Supporting others not only help them, but also helps you!
You shall avoid ending up with a team where people are afraid to ask for help.
Sharing is charring.

Comments

Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Fundamental Books of a Software Engineer (version 2018)

More then six years ago I wrote a blog post about fundamental books that any software engineer (developer) should read. Now it is an excellent time to update this list with new entries.

There are 5 different categories of books, that represent the recommended path. For example, you start with Coding books, after that, you read books about Programming, Design and so on.
There are some books about C++ that I recommend not because you shall know C++, only because the concepts that you can learn from it.

Coding

Writing solid codeCode completeProgramming Pearls, more programming pearls(recommended)[NEW] Introduction to Algorithms

Programming

Refactoring (M. Fowler)Pragmatic ProgrammerClean code[NEW] Software Engineering: A Practitioner's Approach[NEW] The Mythical Man-Month[NEW] The Art of Computer Programming

Design

Applying UML and Patterns (GRASP patterns)C++ coding standards (Sutter, Alexandrescu)The C++ programming language (Stroustrup, Part IV)Object-oriented programming (Peter Coad)P…

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…