Future Technical Works

On the other day, one of our TechLead asked me a question like the following,

Hey Nixon,  what’s the Algorithm for figuring out future technical work for a team of individual contributors?

I could not give him the answers. Technically I never followed any specific pattern or algorithms. But this question was very intriguing.

I have been thinking about it for a while. Here are some of my thoughts,

What is an Individual Contributor (IC) in software engineering?

Ideally, we like to think of a bunch of developers wearing cool headphones with a shiny MacBook and coding all day long to finish a task.

For sure, those are cool people, at the same time, IC also means coaching people within their peers and team, taking ownership of the projects/tasks, refactoring their projects on their own, bringing issues to the table, and many more.

The Algorithm

Having said the previous piece, now it’s kind of easier to know what’s missing and what is the future technical work or how to find them.

1. Find the root cause of whatever is blocking the team to execute faster
2. See in the APM tools for what is abnormal. Why that is abnormal? Do not take people's comments for granted. Sometimes we get used to abnormal situations
3. Check the bug-fixing process and fixing rate. Why those are too fast or too slow or why there are too many?
4. Talk to your manager, find out what’s coming in 6-8 months to the team
5. Why refactoring is slow or no refactoring, ideally refactoring is part of the software life cycle. So what’s happening there?
6. Talk with the peers from other teams to see what’s happening there, what kind of things they are building, and why. what is missing from my team
7. Find out what is the main mission of the team and company. Cross-check the OKR for the team and company, and see if those are aligned or not. If not, then why? what’s the bottleneck?
8. See if there are things that were added as over-engineering desire.  Why? Is there something else hiding behind the walls?
9. Keeping track of the new tools avaible in market, which might help our current scenarios.
10. Do not commit to delivering anything by yourself, always pair with other people, but not more than 2 sprints at the same time. Then you might be biased. Always switch your association with pairs so that you can see the holistic views and problems from different perspectives. You will teach others and will be taught by others too. And you will see and hear the problems with your own eyes and ears. You can form your opinions about the claimed problems. Even you will start to understand the requirements and the random shiny desires of developers.
11. What is missing? What is missing?
12. Always try to see different types of system talks, those will give different perspectives.
13. Most importantly what’s blocking the ICs to able to execute their jobs?

For me, I am continuously thinking about the bullet points I have mentioned. I believe going through those exercises/thoughts(1 or many) illuminates the paths for future technical work for me.