sProgramming careers start while working for someone else. It can be your team lead or boss if you are working in a company.
When you are coming from a learning environment to a professional environment major change will be more complex projects than all projects of your classroom and on top of that, you will have to deal with your team lead.
For junior developers, its gonna be a hustle. Your team lead will ask to give estimates on the fly and often you will commit more than you can deliver. Also, you will have to deal with non-technical issues like managing someone else work or meeting the unrealistic demands.
So let’s deep dive into the types of team leads that you can face. In the end, I will share how to deal with them. Generally, there are two extremes technical and non-technical. I will start with technical and their variants and move to the non-technical team leads.
Technical Team Lead
Technical bosses are those kinds of bosses who are perceived as technical which means they have education in a technical field like computer engineering, electronics/electrical engineering and etc. Following are some of the variants of technical bosses.
A) Who Forgot what They learned
They are technical but when you really grilled them they don’t have any idea about the technical details. Why?
There could be several reasons. Maybe they joined the company as technical persons and your company doesn’t fire people. So they climb the ladder by giving 10 years to the organization and become bosses of junior technical people.
The problem is they know very little about the technical details and want to contribute to design and development. You know what happens next…
B) Technical but not in Your Field
These bosses technically sound in some other field but not in the programming field. Let’s say an organization developed a product that has different sub-systems. For example, a cellular phone development company has separate departments for communication, electronics, software development and etc.
Now it is possible that a person may have joined your organization in the electronics department as a junior electronics engineer. Afterward, he got promoted and now he is managing director of both software development and electronics.
Therefore, this type of boss knows little about your field and knows a lot about his own field i.e. electronics.
The problem is that electronics development is quite different than software development. Your boss knows about electronics and there is a mismatch in the expertise.
C) The Generalist
Another type of boss is someone who has a little knowledge of what is going on but does not know about the minute details of the task. Majority of your bosses will be like that. Not every one of your boss knows how to fix CSS issues but they have an overall idea of how CSS work.
They are good bosses. But they become violent when they try to estimate on their little knowledge. When you say to them it will take a day or two for a task they will respond with “Ooh, in my opinion, it’s just copying and pasting and you have done something like that in the past” and you start thinking why I am here!
There are some great bosses in this category too. They have a little knowledge of your field. They will give you all the time because they trust you. Why? Because you are working on something that they knew and they are not blank.
D) Nostalgic
These are kind of bosses who have done software development in the old days i.e. 80’s and 90s (although programming is way older). Now if they continued in software development then they are smarter then you.
But if they changed their field. For example, they move to marketing or any other non-programming job or managerial job then it’s a different story.
Now when they see you programming then all the good memories or the heroic efforts that they have done in the past to rescue someone are coming back. They wanna help you like this:
They are going to interfere with you and slowed you down. They are old and they want to manage computer memory their own way. Even if you told them about built-in memory handler like JVM.
According to them, 2 Megabytes of memory is enough for your program and a Pentium 3 should be enough to run every software on the earth.
NON-TECHNICAL Team Lead
Describing a non-technical team lead is easy. Their only problem is “THEY ARE NOT TECHNICAL”. There is no variant in this category. Because you will always qualify them as ‘Non-technical’.
Either they are the ones whose money is on the stake or someone who is good at running businesses like a CEO.
In my opinion, they are easier to deal. They will doubt your opinion in the start. But since they have no knowledge of the technology, therefore, dealing with them is easy. You just have to remind them of the fact that they are non-technical. Politely of course.
Most importantly these types of bosses are looking for someone who they can trust. They just need one developer that they can trust-even if that developer is at the lower end of the spectrum in terms of technical skills.
For example, one of my friends is managing a product for a non-technical boss. Although his boss can hire a low-cost developer but he prefers my friend because my friend has earned the trust of his boss.
IDEAL Team Lead
Once I ask one of my peer friend about his future plans. I asked, “Do you want to see yourself in some sort of technical role.” He said, “yes, I don’t wanna stray away from technical knowledge.”
Then I ask about if you wanna go in some managerial role where you have to manage things. He again said yes because there are several things that can be done in better ways like the process of procurement and other non-technical stuff.
Turns out that he wants to gain best of the both worlds. So, I asked this question to a couple of others people and I found the similar results. Then I tried to find out such bosses in real-life.
I looked into heads of other departments. I found highly educated PhDs in management role. Who are top notch expert in their field but when they are in management role then they don’t have the time to do technical stuff.
I called such a boss an ideal boss. Someone who is best in the both environments. Technical and managerial. Did I find someone in the past decade? Nopes.
Don’t compare a senior developer or architect or tech lead with the boss or team lead. A senior developer is your mentor. He knows the stuff and he knows how to debug the code better than you. He may assigns you some tasks but remember that he is not your boss.
Your boss is someone who is writing the paychecks. Hiring/firing people. Getting new projects. Talking to customers. Assigning resources.
How To Deal With Team Leads as a Software Developer?
I will share three tips that work with all type of team leads.
1) Limit Your Options
First of all, you should give your team lead options to choose from when asking for a solution. Don’t leave them blank. If you leave them blank they will give you suggestions that will blast your head. So always give them options. The question is how many?
I once heard from a politician that Army Generals usually gave three options to Presidents. First is the solution that nobody likes. The third options is the solution that is the idealist and cannot be achieved but the middle one is the solution that is achievable. Most importantly this middle option is the one the general wanted to implement.
Also according to Steve McConnell in his ‘Software Estimation’ book, there are techniques that let you play with more options and there are techniques that give limited options.
So techniques with more options will give a varying range of estimates and techniques with fewer options will generate a consistent estimate. Hence give your bosses limited options to choose from. Also, options should be in the range of 2-3.
2) Solve Their Problems First
One of my readers said to me he has to deal with a cluttered codebase and it can become better if object-oriented methodology is used properly. But his team lead was interested in rectifying the problem not making a good OO design.
So, most of the bosses are interested in solving their own problems and they are less interested in how you are going to solve it.
So always tell them how the problem will be solved and how it will look like after the problem is solved. Don’t bore them with the techniques that you will use to solve it.
3) Prove yourself with your technical skill even if you have little experience
In my organization, we have bosses at different hierarchies. Once I was called upon by the boss of my boss. He asked me about a critical task and how I will solve it. I gave him all the language, tools and libraries that I have used or read about and told him that I can do the task.
He encourages me and let me go. Afterward, he asks my immediate boss “Is he gonna solve it?”
What………………? Everything that I told him was of less importance. The recommendation of my immediate boss was more important.
Since my immediate boss knows me and I have proved myself to him, therefore, he reassures the senior boss. But you can see what is happening here.
If you wanna prove yourself with your technical abilities then prove it in front of your immediate boss or even to the senior developer and they will recommend you to their boss.
When you have this level of confidence from your bosses then it will be easier to work with them.
I believe these techniques help you. Finally, what have you done to smooth out the friction with your bosses? Tell me in the comments below.