Hey guys and ladies,
Welcome to part 2 of the “Effective Leadership” post, a typical day in the life of a software engineer 🙂 .
So in part 1 of the series I talked about leadership and gave the 3 stages/levels of competency development in software engineering. Well in this part, I will give a detailed analogy/example of how these stages/levels plays out in a typical scenario.
I like to give the analogy of maybe an office boardroom… You walk into an office boardroom with someone and the person notices and points out that the boardroom is not at an optimum temperature and says something like: “Hey John, we cannot have a meeting inside this boardroom because it is too hot and uncomfortable”; here the person has identified a problem with the boardroom and you could say the person is a Problem Finder because they found a problem. Then you could probably call a Problem Solver and say something like: “Hey Jane, the boardroom is too hot, and it is uncomfortable to have a meeting in here. We need to have a meeting in the next 10 hours, can you do something about this?”, Jane would probably say “Sure” and then go ahead to inspect the office boardroom (the problem) and then come up with a relevant and effective solution/set of solutions to solve the identified problem. For example she could propose to:
- install additional Air Conditioner(s)
- set the temperature control on the existing Air Conditioners to produce an optimal temperature
- close the windows of the board room if they are open
- Paint the boardroom a calmer color like white or light-blue
- Replace the chairs in the boardroom with more comfortable ones
- etc
Now she has broken down the problem into different solutions that she can then assign/delegate to Solution Implementers to implement. Each one assigned to one of more solution implementers based on their area of expertise in implementing the different solutions 🙂 .
So basically that is the same thing with software engineers and if you do not know what stage your direct reports are, you will probably be meeting them at a wrong level and they will find it extremely frustrating. For instance you go and bring a Solution Implementer to solve problems, you will eventually frustrate the solution implementer because the person will be struggling to solve problems but the person is used to implementing solutions. So what eventually happens is that the task will become too difficult for the person, the person will be trying their best and then you are putting so much pressure (because of missed deadlines), and the person will be pushing back telling you that they don’t understand how to carry out the task. This will eventually cause a lot of frustrations and might even lead to them resenting you because they will feel that you aren’t really listening to them or understanding them.
But if you know that this person is a Solution Implementer, you just go ahead and break down the problem into solutions and give them the solutions to implement and they will be excelling at that, they will feel very fulfilled and you will be fulfilled too because you are effectively working as a team and meeting the timelines and deliverables. What eventually happens to Solution Implementers is that after they have implemented a lot of solutions, they get comfortable with their problem solving skills that they now “graduate” to become Problem Solvers. At this point, you should be able to recognize that these engineers are now problem solvers and instead of giving them solutions to implement you should start giving them problems to solve. If you give a solution to a Problem Solver and tell them to implement it, they will feel very embarrassed and under-utilized because they will feel that you are not trusting them enough to solve the problem. You should be able to recognize that these engineers are now problem solvers and give them problems and trust them to solve problems.
It will then get to a stage that after they have solved different shapes and sizes of problems that they can now recognize when a system is inefficient or when certain areas of the system can be optimized that they start finding problems in the system and coming up with solutions for them. At that level they have “graduated” into Problem Finders.
And so in the stages of software engineering, Junior engineers are typically Solution Implementers, mid-level engineers are typically Problem Solvers, senior engineers can be Problem Solvers or Problem Finders while solution/software architect are mostly Problem Finders. If you bring a solution/software architect into a process or a new organization, they should be able to identify problem areas and areas where they can optimize the current processes/tools/learnings based on the different shapes and sizes of problems they have solved and the different experiences they have had in their career. They know what is important to optimize and at what time / project maturity level / team maturity level the optimization should be carried out. They know what things to do to make things better, they know what processes they have to bring, they know what tools they need to use to improve the processes / delivery of the team and software.
I use this as my base model when I am motivating engineers and I think it works very well because I have gotten so many positive feedback from people I have worked with and teams I have led (including the Tweet on Twitter that inspired this post).
I hope that I have been able to share one of the strategies I use when I am leading teams or doing some sort of leadership.
And as usual I will leave you with a word from the elders:
Do Not Procrastinate!
Whatever you need to do take action now and get it done!
So guys and ladies, until next time:
“keep growing, keep improving your craft, keep moving forward, keep expanding your knowledge. The Sky is definitely your starting point”.
Have a wonderful and productive week.
Peace XX
featured image credit: https://blog.aiesec.org/
Leave a Reply