How a great Technical Lead Engineer works
We have a lot of roles in one engineering team, especially when we talk about the agile development team, like and software engineer, software developer, QA, scrum master, product owner, UI/UX, software architecture and software engineer manager.
There are so many roles that sometimes we get confused. What is the difference between a software engineer and a software senior engineer? Why do we need a tech lead or lead software engineer? What does an engineer manager do?
I think the tech lead mission is to make the team autonomous, encouraging their responsibility. Tech Leads should do that connecting their leadership, business knowledge, and technical skills.
In my personal experience I have noticed that some activities differ software engineers from Tech Lead, and most of the time it is not related to technical knowledge, but it is related to what and how tech lead works. So I decided to share some responsibilities that I appreciate in one Tech Lead. It is even better when the Tech Lead can help team members to improve these skills as well.
Focus on the problem and not on the solution
The technology only comes to solve problems we had, based on that, the technology is not the most important thing when we are creating a new product or solution, the problem should be the focus.
The tech leads should focus on the problem, they should understand every detail about the problem and ask a lot of “whys” to the stakeholders and the product owner, how many are needed.
Only when we know exactly what is the problem then we can start to think about solutions. Besides, we should focus on a simple and easy solution for the problem found, there is where engineers fail.
Most of the engineers try to avoid all the possible future problems that they don’t know if someday it is gonna happen, they try to prioritize the most efficient solution over the simplest solution. They try to create the best algorithm, generic and reusable for the first time they are creating the feature, they don’t even know if the feature is gonna solve the problem but the feature already has to be the most efficient and quality ever. Normally what they do is the Big Design Up Front (BDUF) and violate the You aren’t gonna need it (YAGNI), one of the Extreme Programming (XP) principles.
Remember, study carefully your problem and solve it using an easier and clearer solution.
Know the big picture and go deep into the details
It is extremely important that the Tech Lead can suppose and explain what will happen if we decide to change some part of the code or some integration of two or more components.
They should know how the components are related, what the data is stored and what can happen if we decide to start calling a new web service or what can happen if some service or batch stops to work properly.
One tip to improve this knowledge is to reserve time to improve the integration tests and unit tests, it will help the tech leads to imagine scenarios and they can just create more tests for that and maybe can start deal with unexpected behaviors.
Plan the software deliverables
What the engineers often do is trying to deliver everything at once, they like to put their earphones, work eight hours nonstop, delivery the feature without warning anyone, no testing or testing only the happy path and the worst: they simple start doing what they think is needed.
For example, if we noticed that we were saving address information into the client table and now we want to save into a new address table we have several things to do:
create the new address table, create the audit table, create a trigger to fill the audit table when a record is updated or deleted, add initial test for the new code, add code to save the data in the new table, stop to saving data in the client table, make sure in case of errors saving on address table the client record is rolled back, fix the test code, add integrated test code, add integrated test code for unexpected exception… and finally, we have to create a script to migrate the old client data to the new address table.
Before we describe each task it didn’t look a complex feature, but now it looks quite harder. Even after that, the engineers would say that they can do it alone and delivery quickly.
After some time, when they are creating the code to save the new information into the address table, they realized there’s no external number for the address, so the engineer decided to change the front-end, change de API to receive the new field, etc. After all, they will delivery the feature and improvement.
When coming to the date to deploy we have to delivery new DDL scripts, front-end app deployment, back-end app deployment, migration script and it should be done in a specific order otherwise it can fail.
Why don’t we plan the deliverables and deploy it on small pieces, first the new table on prod, then the trigger, then start saving the data into the new table… If something more important comes? We can stop and work on the more important task, then we can get back and move on with the previous feature as it is partially on prod.
I am not counting on priorities and merging issues, it can add more and more complexity if it happens in the middle of the coding process.
It looks pretty simple but I always see engineers making this mistake.
