Working as a technical support engineer

From being an unemployed that wanted to leave the country, to launching my career and becoming the “Golden boy”

Working as a tech support engineer may seem easy, and it is considered among the entry level positions in IT, but it can be pretty difficult, especially if you work as tech support in a startup. Big companies with complex processes and proved products on the market, may have everything organized and documented and you just need to read the manual, or at least have a sense of where you could find specific pieces of information. In a startup however things are a bit different, little or nothing is documented and everything has to be figured out: many difficulties, many challenges, but a lot of growth, both personal and professional.

When I was 20 years old I paused college for a while, to start working and become an independent man, without having to rely on my parents. After they worked so hard for so many years to put food on the table for their 4 children, I figured it was time to take some of the pressure off their shoulders. It became awkward for me to ask my mother for money, to buy clothes or anything else that was of use to me only and not for the entire family. Initially I wanted to go to Spain, just like many people in Romania were doing at the time including my oldest sister, going to Italy or Spain to find better work, because jobs in Romania were poorly paid. But I didn’t want to go to Spain without taking my driver’s license, I thought maybe I needed it, or maybe I could work as a driver. So I started taking driving lessons and I continued to apply to different jobs in my city, every once in a while, just to see what’s out there and if anyone notices me. After a few weeks I got called to an interview for technical support. I think it was the first and only interview I went to, at the time, as I didn’t have any working experience and just a few were noticing me, so it had to be an entry level position.

The day of the interview came and I was heading towards “the office”, which was situated in some apartment building at the 3rd floor (out of 4). As I was heading there I started wondering: “Where on earth am I going to a company that’s based in an apartment? On the 3rd floor? What kind of company is this?” But I took the risk and went there and they were actually friendly people and had a nice conversation, they asked me a lot of questions about my technical knowledge, but also asked me about personal life. They made me feel welcome and even though I didn’t have experience, they seemed more interested in my English skills and what do I actually know to do on a computer. Thankfully I always enjoyed English and I always thought about it as ‘The universal language’, since every little piece of software and every README and How To’s were in English. So my English was pretty good, I think, and it was quickly and easily checked off the list, that was a plus. Now onto technical skills; I basically started talking about the things I enjoyed doing on a computer, from messing around with the Windows OS and different programs, to networking and messing around with Linux. As a kid I was some sort of nerd, spending a lot of time in front of my computer and not just for playing video games. I had a curiosity to discover new stuff and see how things work. This helped a lot and I actually got the job! I was thrilled!

I started working and the first thing I had to do, was to get familiar with the products. I was told the basics and how things work or *should* work, encouraged to read manuals and I was reminded the universal rule that “Google is your best friend“. And that was it! So I started playing around, pushing buttons to see what they do. After I covered the basics, I was shown how to watch the logs in the SSH console and was given a task: start documenting what happens in the logs so we have an easier way to understand what’s going on, and of course to make it easier for future newcomers to learn the system. Basically  I was pushing a button and then checking the logs, trying to understand what the relevant lines were and what was really going on in the backend, and then I was saving them as samples in a document with explanations. It was like some sort of reverse engineering, pretty complicated and sometimes frustrating without any documentation, though for me it was generally fun: every discovery was keeping me motivated and I constantly wanted to learn more.

Then the time to take customer calls came, and even though I was a bit nervous at first, I had to adapt quickly. I encountered all kinds of people, from inexperienced users that were not that familiar with a computer, to the “tech savy” folks that thought too good of themselves, to the actually real technical people from which I even learned new technical things. However I had something to learn from all of them. With some customers I was spending a lot of time over the phone testing and reading logs in real-time; not the most efficient method, I know, but I was forced by circumstances; at that moment we were only 2 guys in support and we were switching shifts, so any customer that wasn’t addressed in the same day, would’ve added to the load of the next day, something to be avoided as it all had to be handled by us anyway, there was nobody else to delegate or transfer to. We were forced to learn to become efficient and not have to come up with excuses and explanations as to why it took us a long time to respond. It’s generally much more efficient to focus on doing your job better only, than having to focus on both: doing your job better as well as also having to come up with explanations and arguments. It’s win-win for everyone. 

I was trying to do my best over the phone, then reply to tickets providing as much relevant information as possible including different options (e.g. if a. doesn’t work, then try b. and if that doesn’t work either try c. etc.) avoiding a lot of the back and forth email exchange and trying to improve the customer’s chances to solve his own problem with my instructions and minimal effort from my side. The tickets back-then were being handled through Gmail only, with filters in place, making sure we always would CC our support address so that the other colleague knows to which cases we replied. It was all a game of balance between staying in sync with the coworkers, answering calls and tickets promptly, keeping customers happy by solving their issues fast, gathering technical details about the bugs encountered so the programmers can fix, reverse engineering the system so you understand what’s going on behind the scene, keeping yourself informed about technologies and new products on the market that customers were using … etc. There was a lot of pressure, but it came with many rewards along the way, not only of learning new things, but also feeling the accomplishment that we were able to actually help people and make their lives slightly better.

I treated everything with enthusiasm and didn’t say “no” to challenges and opportunities. I kept an open mind and I stayed positive. I understood what our developers needed in terms of bugs, so rather then sending a bunch of logs saying the problem is in there, somewhere, and let them do the heavy lifting of digging through the logs and finding where the problem is, I tried to do it instead. So I would send the logs saying something like “It seems to me the problem is at line 74, because ……. I may be wrong, but please take a look and let me know what you think“. This way I was forcing myself to think and understand how things work, but I was also getting feedback and validation if my thinking was right, or explanation if it was wrong. It all contributed not only to my learning process, but also helped me be noticed by people in the company. At some point I was able to figure out a long standing complicated issue, pinpointing it in the logs and impressing the lead developer that sent an email to everyone saying something like “Gold starts for our new expert: Daniel”, which afterwards turned into me being called the “Golden boy” LOL. Though not for a long time as it all lead to a new opportunity: growing the team and becoming the team leader, which meant my time to focus on technical things started to decrease as I was focusing more and more on people, but that’s another story… 

It was a great time of my life and I learned a lot of things, and if I were to sum it up shortly, I would say that….

  • Think in ‘challenges’, not in ‘problems’. Being at the beginning of a new journey may be daunting and challenging, confusing and maybe even frustrating at times. But staying positive and treating difficulties as opportunities to learn and grow can have a real positive impact. Positivity beats negativity, not only because you will feel a lot better by staying positive, but it also helps you more easily go through tough times. A negative person may say “This is all wrong and nothing works and never will work”, while a positive, open minded person may say “This didn’t seem to work, but there may be other things I can try, there has to be a way. What am I missing?” . You choose which one you think has better results in the long run. It’s not about thinking everything is going to be perfect, it’s about not focusing on the negative parts, minimizing their impact, focusing on what you can control and figuring out the best way to move forward.
  • Practical knowledge > experience > papers (diplomas). In many cases nowadays I think the most important thing is to have practical/actionable knowledge. Yes, theory is good, but if you don’t know how to put it in practice, that’s not of great value. In our fast changing world immediate results are expected from people that have the ability to figure things out easily and independently without needing micro-management. This is of much greater value altogether as it leads to a faster growth and scalability. Without this kind of people it’s easy for managers to fall into the micro-management trap.