I want to talk about how an average freelancer can survive
(Note) This article is written for freelance IT engineers, but it also contains content that may be useful for other industries. Please take a look.
I was a below-average, mediocre freelancer.
(I'm not a freelancer anymore since I started my own business, though...)
Despite starting my career as an IT engineer, I had a fatal flaw: I had absolutely no interest in technology (lol).
The skill sets for projects (= required skills) were a list of technologies and tools I had never seen before. I didn't know them, but I had no choice but to do it.
With that kind of grit, I continued my freelance life for about 7 years.
For IT engineers who love technology, the freelance world is heaven. If you have confidence in your skills, I hope you will go independent and start your own business.
However, for an average freelancer like me who just works to feed their children, you need to think about a strategy for survival.
Although I say "you need to think" as if I'm an expert, I spent my time drifting along without thinking about any strategy. I just did the work I was assigned.
After about 7 years of freelance life, I'm just looking back and thinking that a strategy "was" necessary.
With some self-reflection, I would like to candidly talk about recommended strategies and things I wish I had done. I hope this will be helpful for those who are currently freelancers or those who are planning to become one.
1. Let's attack in high-demand technical areas!
Some people may have a technical area they are good at even before becoming a freelancer.
Of course, I didn't have anything like that (bitter laugh).
I just dabbled in Java a little bit and went independent immediately.
That is how a burden-to-society freelancer was born.
At the time, there happened to be demand for Java, so I found a project relatively quickly.
But this was just pure luck, so there was no strategy involved.
Which technical area should you attack? It is certain that it is best to just jump into an area with demand. If possible, it would be best to be involved in projects where you can touch high-demand technical areas before going independent, and write it down in your resume as practical experience.
I love this technology so much that I won't do anything else!!
It is common for engineers to insist on this, but I want you to analyze the needs calmly.
The technology you like is not necessarily in line with the world's needs.
I also had a tool I liked even though I was mediocre. I believed that tool was the No. 1 in the industry, but what was the basis for that? Because it was easy for me to use (lol).
Since it was a niche tool in the industry, the number of projects was overwhelmingly small. Because I turned a blind eye to this fact at the time, I had some trouble later on.
The only reason I was able to change my path successfully was that I was "blessed with clients."
Clients also have budgets, so even if you are an excellent engineer, you can still get fired.
To be able to switch to another project immediately,
I want to keep an eye on technical areas with as many projects as possible.
2. Let's write your skill sheet as detailed as possible!
A skill sheet is a resume.
It is a document that summarizes your work history so far, but I think there are many engineers who are losing out because of how they write it.
For an average freelancer, writing a good skill sheet is a lifeline.
Specifically...
・Project title and overview
⇒ Write concisely and clearly.
Background of development and application area to business (what kind of business you are trying to systemize) will also give a good impression as it shows a broad perspective.
・Assigned position (PM, PL, PG, etc.)
・Processes handled (requirements definition, basic design, detailed design, etc.)
・Development tools and languages used ⇒ List everything without omission.
Write in detail up to the version.
・Value demonstrated ⇒
Write about your contribution to the client and project members.
Write with numbers as much as possible where you can write quantitatively.
Such as reduction of work hours by system introduction: 〇h ⇒ ■h.
If you can write this, I think it's good for now.
It might be obvious, but if you broaden your perspective to include things like the background of development and the application area to business, and increase specificity by using many numbers, it will result in a good-looking skill sheet.
3. Let's ask questions and report frequently!
Engineers are often thought to be socially awkward.
It is perfectly fine if you are not good at small talk.
However, if you cannot communicate well while working, you will leave a very bad impression on the client.
In my experience, people who are poor at communication are often also lacking in skills.
However, even if someone lacks skills, if they work hard and have a desire to improve, that "enthusiasm" is often valued, and they are frequently kept on for further contracts.
Where is this "enthusiasm" evaluated? It is in basic communication, such as asking questions and providing reports.
Even in remote work, make sure to ask questions and provide reports frequently via chat.
Just doing that conveys a sense of hard work, and
they will think you are properly taking ownership of the work assigned to you
and you will gain their trust.
People in other industries might think, "Isn't that obvious?" but in the world of engineering, being able to communicate properly is highly valued.
(And it is not like exceptionally high communication skills are required.)
4. Don't try to handle everything alone!
It is common among people with strange pride (who, for some reason, have lower skills), but you should absolutely avoid trying to handle tasks all by yourself.
When a 40-something engineer who had just been assigned to the team was given development tasks, he boasted, "I can do this in a month!"
But even after two months, he still hadn't finished.
(By the way, that engineer was not on my team, so I couldn't track his progress.)
Around the 1.5-month mark, when the client's representative checked the status, it turned into a situation where he used the poor tool specifications as an excuse to spout reasons why development wasn't progressing as expected.
It is true that some specifications might have been poor, but he should have consulted with people around him about that early on...
Why did he bottle it up?
Perhaps he thought that rather than feeling embarrassed by being told, "You don't know that?", it would be better to just Google it and solve it himself without asking?
Whether you feel embarrassed or not is irrelevant to the team.
Not being able to ask questions prevents work from progressing, and causing the project schedule to go off track becomes a major problem.
If you can complete it alone, there is no problem at all, but if it seems even slightly difficult, raise an alert (i.e., ask for help) early. Well, I couldn't really do that until my first or second year either (laughs).
5. Do your work carefully!
In particular, people who are thorough with testing and troubleshooting tend to be preferred.
During test reviews, I always feel that people who can logically explain things in chronological order, saying, "I prepared this kind of data, and the result was this," are excellent.
Such people may have a plain first impression, but they gradually gain trust.
If you are fast but your work is sloppy, those around you will have to follow up, which lowers the productivity of the entire team.
I want to be conscious of completing each and every task reliably.
Ah, this is a boomerang (self-admonition).
6. Try and error as much as you can!
Research and solve things that seem immediately useful on-site or things you are currently struggling with right there.
In the process of researching, expand your repertoire by repeating the hypothesis-verification cycle.
Try to walk as many routes as possible to find a single answer. That will become your confidence.
The point is to form your own hypotheses, such as "Maybe it's like this?" or "Wouldn't performance improve if I did this?"
If you just copy and paste the answers you get from Googling or ChatGPT, you won't really learn. You will probably end up looking up the same thing over and over again.
To avoid looking things up repeatedly, it is important to repeat the hypothesis-verification cycle and accumulate many failure experiences.
7. Summary: Things that are important besides technical skills
Writing it out like this, I realize there are many things that are important besides mastering skills.
・Appeal strategy (such as skill sheets)
・Attitude toward work
There are more people than you might imagine who neglect these, so just being conscious of them is enough to differentiate yourself.
I will say it again, I think my skill level is below average.
But I think there are many things you can appeal besides skills, and in fact,if you are mediocre, you cannot survive unless you appeal yourself.
I heard from someone on the inside of a certain site that evaluates programming skills that companies prefer A-rank people over S-rank people.
It seems that a person's balance is what is evaluated.Being focused solely on technology is not good after all.
For a freelancer, the key is whether you can brand yourself.
Without straying too far from the needs of the world, polish your own weapons firmly.
Even if you are mediocre, you can be of help to someone with the weapons you have polished.
Focus on helping the person in front of you. Even if you are working for a large company, devote yourself to the "people" of that company.
The consciousness of using your skills for someone else.
I think that is what is important.
