Skill that will make you a better Lead Software Engineer

1. Empathy
2. Collaborate with team members
3. Suggest don't impose
4. Curiosity
5. Inspire success
6. Micromanaging
7. Impostor syndrome
8. Treat all developer as equals
9. Deadlines and code
10. Control the ego
11. Handle pressure
12. Handle conflicts
13. The Hero
14. Taking shared Ownership
15. Attitude and Motivation
16. Team player
17. Influence
18. Accept the challenge
19. Knowledge Management: Sharing and Transfering
20. Stay in the top of the wave
21. Culture company

Empathy

Empathy is the ability to understand and share another person's experience, perspective and feelings. We need to Lead and work with empathy. Don't confuse empathy with making people happy or being just nice.

Types of Empathy

Cognitive Empathy
Cognitive empathy is basically being able to put yourself into someone else’s place and see their perspective.

Emotional Empathy
Emotional empathy is when you quite literally feel the other person’s emotions alongside them as if you had 'caught' the emotions.

Compassionate Empathy
Finally, compassionate empathy is what we usually understand by empathy: feeling someone's pain, and taking action to help.

Further information:
https://www.skillsyouneed.com/ips/empathy-types.html

Help team members in their career path

Lead a team and mentor it is no simple task. We need to determinate the interests, skills and career goals of the people to determinate the kind of leadership required or even not required, from carrier advice, technical support, advice about goals and mentoring to just simply no supervision and simple trust.

We need to put team members first. The goal to make the team members shine. Makes their work interesting and engaging, facilitate the communication, elevate their individual qualities and create a star team.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." — Martin Fowler

Suggest don't impose

If we have to implement new changes: Suggest a guiding principle instead of imposing rules.

If we have to implement new technology, pattern or methodology that requires time to learn: Create a workshop, share this technology, discuss benefits and possible implementation implications with everyone in the team, and the company then IF everyone sees and understand the global potential benefits create another workshop to share the knowledge and spread the word.

Curiosity

Curiosity is a thing, a thing that keeps developers mind busy and feeds their ming. Curiosity motivates the desire for discovery and moves forward.

https://res.cloudinary.com/practicaldev/image/fetch/s--uxP6BXEg--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/4jhuadb9nbcdpqhjblqx.jpg

Micromanaging

It happens when Managers can find it hard to delegate operational responsibilities and start playing the blaming game.

In business management, micromanagement is a management style whereby a manager closely observes and/or controls and/or reminds the work of his/her subordinates or employees. Micromanagement is generally considered to have a negative connotation, mainly because it shows a lack of freedom in the workplace.

Micromanaging, in my experience, is a set of actions that shows a lack of trust and lack of respect that lead to anxiety and decrease morale and performance. The further issue is that is someone is micromanaging people, questions need to be asked about their skills as a manager and the people who support it.

As a manager, employ people to do a job, teach them well and let them do what you employed them for and trust in them to do it.

Monitor but don't micromanage, be a "Servant Leader" and "master the skill of delegation".

Inspire success

"Limitations live only in our minds. But if we use our imaginations, our possibilities become limitless." – Jamie Paolinetti

The problem is on knowing what we want. You've got to have a purpose no matter what you do in life.

Rules of Success:
1) Have goals, purpose, and visions.
2) Don't listen to the naysayers or doubters.
3) We have to work our a** off and advertise.
4) Don't have a backup plan. We function better if there is no safety net.
5) Never doubt yourselves.
6) Everyone fails and losers stay down. To be a winner we have to fail, we have to never be afraid of failing, we have to never stay down, and we have to get up continuously.
7) Being relaxed and giving it everything we have is the best way to perform.
8) Help out others and give back to the world.

-Arnold Schwarzenegger's

Impostor syndrome

We all in the developer path felt in a way or other suffer from the Impostor Syndrome.

Here is a fact: Technologies change too fast for us to be an expert in all aspects. So, no matter your skill level, no matter your position, you are not an impostor. Know your accomplishments. Don't play to compare game. You are where you are because you make it possible.

"Don't get distressed because you aren't an expert in the en vogue framework or you haven't yet learned a functional programming language. Paradoxically, the fact that you're self-aware enough to have impostor syndrome in and of itself means that you shouldn't think of yourself as an impostor. You are aware of the limits of your knowledge. You know what you need to learn to stay competitive, or advance your career, or stay at the cutting edge of your particular niche."

The people who don't have impostor syndrome are the ones you want to avoid.

@awwsmm - https://dev.to/awwsmm/youre-not-an-impostor-1boi

Treat all developer as equals

We need to understand that we are all professionals:
Every developer: junior, middle, senior are a completely separate universe with their own background of technologies, patterns, paradigms and ideas.

Treat every member of the team respectfully and always put their opinions on the same balance. If you don't respect their opinions, probably they will not respect yours and it will create divisions inside the team.

Working with juniors and seniors developer opens a world of opportunities: in one hand we have the chance to deep into our knowledge but also make our foundations even more solid.

Deadlines and code

Deadlines are always there. Sometimes are tight and very often it produces stress and conflicts between members of the team.

If we show some concerns and treat developers badly because of deadlines and code. That's means we care more about deadlines and code than the human being. Always place the people on top. Always work together not against each other. Remember we have the same goals.

Tight deadlines are a direct response to the logic of Parkinson's Law, which argues that "work expands to fill the time available for its completion". By limiting the time available to complete a task, we are controlling that expansion.

Remember, mainly all the time, strict short deadlines are due to the result of bad planning.

https://timelyapp.com/blog/do-tight-deadlines-work

Control the ego

"When the ego is lost, the limit is lost. You become infinite, kind and beautiful." - Yogi Bhajan

To be clear, the ego is not a "bad" thing, but a super "me", "myself" and "I" ego it is. Keep it under control is a must learn.

Many people don't want to listen to the ideas, opinions, and constructive feedback of others just their own voice. The personal ego is an obstacle at work. Surrender your need for control. Belive that we know more than others is a false and temporally illusion.

Try not to be defensive whenever have a critic, take it a constructive criticism instead and instead learn from the feedback.

Try not to criticize other's code or attitudes. Try to make objective, positive and professional observations or suggestions instead.

Try not to be over defensive all the time, doing that it will end up creating personal silos within the team.

Handle the pressure

Juniors or Seniors will be experimenting and working under stress, and this is normal. It especially hard to reach the best result of a problem under these situations, but remember always be positive and don't worry about asking for help. Sometimes a new couple of eyes could see the problem from a different point-of-view, and maybe the result it was always there but hidden from our eyes.

It is inevitable we in one way or other needs to handle the pressure and stress.

Handle individual conflicts within the team

We work with people, still do, we seeing each other every day for several hours. IF we have an issue, this issue across time can grow and becomes a real problem.

We need to deal with it and mitigate team members technical and personal matters.

Conflict is not necessarily a bad thing. Healthy and constructive conflict is a component of high-functioning teams when we encourage each other to move out of the comfortable zone.

Based on my experience, the approach must be neutral so do not take aside. We need to deal with the situation immediately, remain positive and contain the situation if the situation escalates, take a break and wait for emotions to calm down and not letting conflict get personal. Then we need to listen carefully to the different parts, identify points of agreement and disagreement, prioritize the areas of conflict and create a plan of action where both parts agreed to follow and move forward together.

Remember, we all have the same goals and we all want the best for the company.

The Hero

Often very seniors developers that being in the same company, doing the same thing for years they could reach a good level of influence over other new joining senior developers. Project Managers and other Seniors Developers tend to create a binding dependency between the project and the "Hero", relying on it as if they always will be there and trusting their decisions blindly.

OK, now the reality check is developers move too often from job to job and one day the smart "hero" could leave the team, leaving with the "Know-how", and there is no documentation that covers that.

Desition and "know-how" must be share and handle by the team, all team members should be willing to collaborate because there is no one more important in the team, than the team itself.

Ability to Teach and Learn

If you want to become a truly great engineer, you should be able to swallow your ego and status.

Wise senior engineers will often tell you they learn new things from junior engineers all the time.

A wise engineer considers and accepts any information from any source. Leave your dogmas at the door.

Taking shared Ownership

To be a leader, you don't blame people. You solve problems, we need to take ownership of the issues.

If workers take ownership and treat their code or products as if it belongs to them personally, they will take special care and consideration.

Attitude and Motivation

Having a great attitude always beats having any number of years experience.

Having a good, positive attitude, along with positive thinking at work will reflect on what you do and make you a more productive employee.

I know not all the days are good, we are humans after all but stay motivated and motivate others. Find whats keep you actively motivated and the others and transform those motivations in daily activity.

Encourage yourself and other developers to stay motivated.

Team player

Actively promoting team empowerment. Seeking continual improvements in company culture. Great teams put their minds together. Greater problems require great teams. Trust in your team, and play together.

I love to work with people that are very proud of what they achieved in the past jobs but is a sense of alarm when they are talking all the time using: "I" and not "We" or speaking badly about previous companies.

Develop great teams, not just software.

Influence

Being a successful developer and team player it will be easier if we can influence and get ourself influenced by others.

Inspire others to find their voice of the Passion and Persistent. When you cast a vision, enrol your followers to express their voice as co-creators and co-contributors to the vision.

Develop a culture in which employees are given ownership over decisions.

Accept the challenge

Probably the hardest one. Here a great engineer should be fun to work with, non-lethargic, and ready to take on challenges.

Based on my experience, I found better results when we focus on the excellence of the code but prioritising on the team members knowledge sharing, others point-of-view and accept that more often than we think: we are wrong. So what we do then? Learn and evolve.

Culture company

Company culture is defined by how people inside the organization interact with each other.

Company culture is a set of, sometimes no written, business buzzwords that setup behaviour and actions from the top CEO to the bottom of the company.

Leaders must understand, embrace and actively participate to improve the company culture, even model the behaviour they want the organization to emulate if necessary.

Thanks

{ 'Leo Lanese',
'Building Inspiring Responsive Reactive Solutions',
'London, UK' }

Twitter: twitter.com/LeoLaneseltd

Portfolio http://www.leolanese.com

DEV.to: dev.to/leolanese

Blog: leolanese.com/blog

Questions / Suggestion / Recommendation ? developer@leolanese.com