Understanding is the Key
Operation Modes
There are two ways that people can operate effectively.
Supporting Culture: You might not find many things written in a supportive culture. Wikipages and tickers might let you down. However, people, managers, leaders, and experienced engineers spend time helping others provide support. That mode works, and it's very easy to do it; however, it is much harder to scale.
Written Culture: In a written culture, which is much harder to implement, you will find rich Wikipedia pages with lots of details, how-tos, steps, guides, diagrams, and comprehensive documentation. However you might not find much direct support, not at least in a heavy meeting-form. Such culture is good when you scale, as you have paved the way for others.
In my opinion, there is a need to mix both cultures. Supporting others is the fastest-way to grow people and get things done fast, but is best combined with wikipages, rich tickets(even if after the story done), videos and as much writing as possible.
Danger Zone
Things tend to get complicated if there is no support(managers and experienced developers have no time to help other team members, and there is a lack of written documentation. In such a context, only engineers with a hack mindset who tend to survive are very senior engineers by nature. However, such a scenario is bad for junior engineers because it's even harder for them.
In the top of that(and very likely that's what happens), junior engineers are:
1. Suffering in silence (without asking for help)
2. Do not know how to create the Hacker mindset
3. Get little to no support
4. Are operating without proper tracking
5. Do not know leaders'/managers' expectations
6. Receive little to no feedback (not aware of the severity of problems)
That's how execution disasters happen and how people sometimes get tossed. But we can do better. To perfectly fix this problem, you need to work on both the leaders/managers' and the people's sides.
Seeking for Understanding
As an engineer, you might not be able to change how your manager/leader behaves. That's fine, you still can change how you approach things, you must seek extreme ownership and find ways to understand everything you do.
When I hear the name of a technology I never heard before, I immediately google it, go do some readings, and ofcourse POCs(proof of concepts). In order to get familiar with. We cannot operate with dozens of things we don't understand. So it's your job to keep learning about things, all the time.
Sometimes people think they are studying too much, but in reality, they do not take into account that:
1. The companies use dozens to hundreds of technologies they do not know.
2. There is technical debt they don't understand and are underestimating it (how much it can slow them down)
3. Companies always keep buying companies (new tech comes with that).
4. People constantly change teams (new tech comes with that).
5. Business is technology; you must master it as well
6. Modernization is required, therefore, more tech will be used
In the top of all that, businesses always have they own domains and terms, if you never worked in a health care company you will not know what the terms will means and the same for all domains you never worked before.
In the end, most business code is simple—it's some ifs, loops, and APIs here and there. This is usually not the biggest barrier, but do you understand what they are doing, why they are doing it, what the corner cases are, and how things can go wrong?
Doing Better
Here is some advice to make things better.
For leaders/managers:
1. Know the level of each engineer on the team; do not assume all are seniors.
2. Seniors are defined for behavior and results not by years of experience.
3. Make sure documentation is getting better over time, as the team grows will make a lot of difference.
4. Either spend time with people doing support or write very good tickets.
5. Give feedback weekly, be on top of things, do not assume people are doing well, ask questions to validate understanding all the time(like unit tests).
6. Improve your onboarding, make sure people are ready to do your tasks.
For Engineers:
1. Ensure you understand the business, what you are doing, and why.
2. Ask questions - assume nothing, ask questions all the time.
3. Search on wikipages and tickets for information, read the code, and go debug the application.
4. Avoid using LLM all the time for delivery; otherwise, you will be learning less and less. Prioritize learning.
5. Do POCs for all the things you don't know, you should be doing lots and lots of POCs.
6. Do not suffer in silence, ask for help if 30 minutes pass and you are stuck.
7. Track your work. Know when you started your ticket, when you finished, and how long it took. The more you know your numbers, the better you can beat them.
8. Do not be afraid or ashamed to ask questions. There are no issues with asking questions; I ask questions all the time. Again, assume nothing.
9. Do not assume you understand, ask questions, do not assume you got it, explain and ask people to validate, always apply unit tests into your knolowdge, how do you know if you know? Go do a unit tests, ask people to validate what you say if is right or wrong.
Understanding is the key to get things done and to become a better engineers. The faster we run this cycle the faster we fix problems and get better. Fast feedback might be painful but payoff as you can learn much faster.
The best time to do something new is always NOW. So let's do it.
Cheers,
Diego Pacheco
