Table of Contents
TL;DR
Skills vs degree became personal for me on 13 August 2026.
I completed my Bachelor of Information and Communication Technology Honours at the Vavuniya Campus of the University of Jaffna in 2022.
Almost four years later, I finally received my transcript and degree certificate.
But something interesting had already happened.
My career had moved forward without waiting for those papers.
I started my professional journey in IT administration at EDUS Lanka. I later moved into the Information Technology Administrator role.
In parallel, I joined Yarl Ventures as an IT & Digital Solutions Expert.
More projects followed. More systems depended on my decisions. More responsibility came with them.
Eventually, I became Chief Technology Officer at Yarl Ventures.
Today I still work closely with EDUS and Yarl Ventures, and I have spent almost three years growing with these startup environments.
During that time, I have worked on real products including EDUS LMS and MediMan, along with internal systems, integrations, infrastructure and client projects.
That experience changed my understanding of skills vs degree completely.
My degree matters to me. Education matters. But education alone did not build my career. Real work did. Responsibility did. Solving problems did. Making mistakes and fixing them did. Learning technologies because a production system needed them did.
Most importantly, earning people’s trust did. My simplest lesson is this:
A degree gave me a foundation. Skills gave me responsibility.
That is the message I want young people to understand, especially students spending significant money on private university education.
Get your degree.
But never spend three or four years collecting only a certificate.
Build something while you study.
There is something satisfying about finally holding your degree certificate.
You remember the lectures. The assignments. The exams. The difficult semesters. The people you studied with. The uncertainty about what comes next.
My degree has an effective date in September 2022. My formal University of Jaffna convocation took place later, and in August 2026 I finally received the transcript and degree certificate that documented that chapter properly.
I was happy.
But when I looked at those papers, my first thought was not about graduation.
I thought about everything that had happened after it.
The certificate represented my education.
My career represented what I did with it.
Those are different things.
This is where the skills vs degree discussion becomes useful.
I do not believe degrees are useless.
I would never tell a student to ignore education.
I completed my own four year honours degree, and the academic foundation helped me understand computing, programming, databases, networking, software engineering, information security and other areas that later became relevant to my work.
But university was the foundation.
It was not the finished product.
The real transformation happened when theory met production.
A database assignment at university and a production database behave differently when thousands of operations depend on the data being correct.
A networking lesson feels different when an application cannot reach a service.
Software architecture feels different when your choice affects developers, infrastructure, cost and future maintenance.
Security feels different when the data belongs to real users.
Deployment feels different when people are waiting for the system to come back online.
That is where practical skill begins.
And this is why I think young technology professionals need a more useful way to think about skills vs degree.
Do not choose one and attack the other.
Use education to build your foundation.
Use real work to prove what you understand.
Skills vs Degree: What My Journey Taught Me
My career did not start with a CTO title.
It started much closer to the ground. At EDUS Lanka, I began in IT administration.
The work forced me to understand systems from an operational perspective.
Users do not care whether the architecture diagram looks beautiful.
They care whether the system works.
Staff do not care how modern the technology sounds.
They care whether they can complete today’s work.
A customer with a problem does not want a lecture about frameworks.
They want the problem solved.
That environment taught me something university could never fully simulate.
Technology exists to serve a real purpose.
As my responsibilities grew, I moved into the Information Technology Administrator role.
Then another opportunity developed in parallel.
I started working with Yarl Ventures as an IT & Digital Solutions Expert.
That exposed me to a wider range of work.
Software development. Infrastructure. Product planning. Client requirements. Deployments. Support. Cloud systems. Marketing technology. Content. Project delivery. Operations.
The boundaries disappeared quickly.
That is common in startup environments.
You rarely get the luxury of saying, “This is outside my job description.”
A problem exists.
Someone needs to own it.
If you understand enough to solve it responsibly, you step in.
Over time, that behaviour created something more valuable than another certificate.
Trust.
From IT Admin to CTO
Career growth often looks clean when somebody writes it on LinkedIn.
IT Admin.
Information Technology Administrator.
IT & Digital Solutions Expert.
Chief Technology Officer.
Four lines.
It looks simple.
The reality between those lines is much messier.
There were deployments that needed attention.
Support problems. Development decisions. Unexpected bugs. Client changes. Infrastructure decisions.
Requirements that sounded simple until development started.
Projects where technology was only half the problem.
Situations where communication mattered more than code.
Days where planning mattered more than development.
And moments where I had to learn something quickly because waiting was not an option.
That is the part a job title does not show.
I did not move forward because somebody looked at my certificate and decided the next title was due.
Responsibility increased first.
The title followed. That distinction matters.
If you chase titles without responsibility, your career becomes fragile.
If you chase capability, responsibility tends to find you.
My path from IT administration to CTO happened because the scope of the problems I could handle kept increasing.
That remains one of the strongest lessons from my own skills vs degree journey.
Real Projects Changed Everything
There is a major difference between a tutorial project and a production system.
A tutorial usually ends when the feature works.
A production system starts there.
After launch, you think about reliability.
Monitoring. Security. Performance. Costs. Backups. Permissions. Data integrity. User behaviour. Support. Logging. Third party failures. Deployment safety. Updates. Compatibility. Scaling.
And what happens at 2 AM when something fails.
Real projects forced me to learn those questions.
Two important examples in my journey are EDUS LMS and MediMan.
These are not projects created only for a portfolio screenshot.
They are products built around real users and real operational requirements.
EDUS publicly describes a technology driven learning ecosystem supporting thousands of students, with live classes delivered using its web and mobile applications alongside Google Meet.
MediMan operates as a telehealth platform where users find doctors, manage appointments, consult through video or in clinic, receive electronic prescriptions and maintain family medical records.
When real users depend on a product, your definition of “working” changes.
That was one of the biggest accelerators in my career.
What EDUS LMS Taught Me
Education technology looks straightforward from the outside.
Create users.
Create classes.
Add a timetable.
Let students join.
Then reality arrives.
Students need different access.
Tutors need different access.
Staff need administrative control.
Classes change.
Schedules change.
Payments affect access.
Recordings need to appear.
Attendance matters.
Notifications matter.
Parents need information.
Support needs context.
Mobile users behave differently from web users.
Internet quality varies.
Third party services fail.
Operations continue regardless.
Building and supporting EDUS LMS exposed me to the connection between software architecture and everyday operations.
The public EDUS platform now includes live online learning, recordings, assignments and parent updates through its application ecosystem.
Behind what users see are many smaller systems and decisions.
Authentication. Permissions. APIs. Databases. Payments. Notifications. Integrations. Logs. Infrastructure. Deployment pipelines. Monitoring. Backups. Support workflows.
None of those areas exists alone.
A change in one place often affects another.
Working around these dependencies taught me more about software engineering than simply completing another course ever would.
It also taught me to think beyond code.
A technically correct feature that creates operational confusion is not a successful feature.
A fast system that exposes data incorrectly is not successful.
A beautiful interface that users cannot understand is not successful.
A feature nobody needs is still waste.
That thinking came from production.
What MediMan Taught Me
Healthcare technology increases the responsibility again.
MediMan deals with a different type of user journey.
People need to find doctors.
They need appointments.
They need consultations.
They need prescriptions.
They need records.
Families need continuity.
The public MediMan product supports doctor discovery, video and in clinic appointments, electronic prescriptions, reports, reminders and family records.
Building around healthcare workflows forces you to think carefully.
Reliability matters.
Privacy matters.
Permissions matter.
Auditability matters.
Communication matters.
The user experience matters because the person using the application may already be worried about a health issue.
The engineering mindset changes when the consequences become more serious.
This is where practical experience creates depth.
You stop asking only, “How do I implement this feature?”
You start asking:
Who should access this?
What happens if this request fails?
What gets logged?
What should never be logged?
What happens if an external service is unavailable?
What happens if data arrives twice?
What happens when the user changes devices?
How does support understand the problem?
How does the business continue operating?
What will this cost when usage grows?
Those questions are part of engineering.
They rarely fit neatly inside one university module.
A CTO in a Startup Wears Many Hats
My current title is CTO.
But if you work in a startup, the title does not describe your whole day.
Some days I work like a Support Engineer.
A user has an issue.
Nothing else matters until we understand it.
Some days I work as a Project Manager.
Requirements need to become tasks, priorities, owners and timelines.
Some days I work in DevOps.
Infrastructure, deployments, monitoring, DNS, cloud services, logs and reliability need attention.
Some days I work as a Scrum Master.
The team needs clarity, blockers removed and work organised.
Some days I work as a Solution Architect.
A business requirement needs to become a system design that developers can build and maintain.
Some days I am the Project Planner.
Dependencies, releases and resources need to line up.
Sometimes I step into marketing.
A good product nobody understands will struggle.
Sometimes I create content.
Sometimes I edit.
Sometimes I work around video production.
Sometimes I sit with developers.
Sometimes I speak with management.
Sometimes I deal with clients.
Sometimes several of those happen on the same day.
This breadth is not always comfortable.
But it has been one of the strongest parts of my development.
It forced me to understand technology as part of a business system rather than as an isolated engineering activity.
That perspective matters in leadership.
A CTO does not only choose frameworks.
A CTO needs to understand why the company is building something, who depends on it, what risks it creates, what it costs and how the team will support it after release.
That is another reason the skills vs degree debate cannot be reduced to coding ability.
What Works
1. Build things people use
The fastest learning in my career happened when something I built reached real users.
Production creates feedback you cannot fake.
Users click things you never expected.
Networks fail.
Payments behave differently.
Requirements change.
Performance bottlenecks appear.
Support tickets reveal assumptions.
That feedback improves your judgment.
If you are a student, build something small and put it online.
One real application with ten genuine users can teach you more about product behaviour than ten unfinished tutorial projects.
2. Learn one technical foundation properly
Being practical does not mean skipping fundamentals.
You still need to understand programming.
Databases.
Networking.
Security.
APIs.
Data structures.
Operating systems.
Version control.
Testing.
Architecture.
The difference is how you learn them.
Do not learn an API only to answer an exam question.
Use it.
Do not learn database indexing only as a definition.
Measure a slow query.
Do not learn Git only to list commands.
Use branches, reviews and rollback workflows with a team.
Skills vs degree works best when theory and execution support each other.
3. Learn outside your title
One reason I progressed was simple.
I kept learning whatever the current problem required.
That did not mean pretending to be an expert in everything.
It meant refusing to become helpless when a problem crossed a role boundary.
Backend developers benefit from understanding deployment.
Frontend developers benefit from understanding APIs.
Engineers benefit from understanding users.
Technical leaders benefit from understanding finance and business.
Developers benefit from learning communication.
That combination creates leverage.
4. Solve problems before collecting credentials
There is always another certificate available.
Another course.
Another badge.
Another bootcamp.
Another qualification.
Some are useful.
But there is a point where learning becomes a way to avoid doing.
You keep preparing because shipping feels uncomfortable.
I would rather see a young developer complete one serious application than collect ten certificates showing they watched ten courses.
Learn.
Then apply.
Then fail.
Then fix.
Then document what you learned.
Repeat.
5. Build trust
Technical skill gets attention.
Trust creates responsibility.
If you say something will be completed, complete it.
If there is a delay, communicate early.
If you make a mistake, own it.
If production fails, investigate the cause instead of searching for someone to blame.
If you do not know something, say so and learn it.
This sounds simple.
It is not.
Reliability over time changes how people see you.
That played a major role in my own career.
I am especially grateful to Mr. Sugeevan for trusting me with responsibility, giving me room to learn and allowing me to prove myself through work.
A manager or founder who trusts a young person with meaningful responsibility can change that person’s career.
The young person must then justify that trust.
Why Skills Matter More Than Ever
This is not only my experience.
Recruiting data increasingly shows a movement toward skills first evaluation.
LinkedIn’s 2025 Future of Recruiting research found that 93% of surveyed talent acquisition professionals considered accurate skills assessment crucial for improving quality of hire. Companies conducting the most skills based searches were also 12% more likely to make what LinkedIn classified as a quality hire.
LinkedIn later reported that recruiter searches in OECD countries filtered for skills far more often than for degrees.
That does not mean degrees disappeared.
It means employers increasingly want stronger evidence of capability.
For technology professionals, evidence is easier to produce than in many other fields.
Build an application.
Publish code.
Deploy a service.
Document an architecture.
Contribute to a project.
Complete an internship.
Work with users.
Solve a business problem.
Write a technical case study.
Show what changed because of your work.
Your portfolio becomes proof.
A Message to Students Paying for Private Degrees
I want to be specific here.
This is especially important for students and parents spending significant money on private university education.
There is nothing automatically wrong with studying at a private university.
There is nothing automatically superior about studying at a government university either.
The institution alone does not decide what you become.
The problem starts when the certificate becomes the entire goal.
If your family is investing heavily in your education, you should demand more from those years than a graduation photograph.
Use the time.
Use the labs.
Use lecturers.
Use internships.
Use communities.
Use student projects.
Use every opportunity to build practical ability.
By the time you graduate, you should be able to point to evidence.
A working application.
A GitHub history.
A deployed project.
A client problem you solved.
An internship.
A contribution.
A technical article.
A system you helped maintain.
Something.
Do not graduate with only a PDF resume full of technologies you have never used outside tutorials.
Do not pay for another certificate simply because you are unsure what to build next.
Do not confuse course completion with competence.
Your degree should support your skills.
It should never become a replacement for them.
Trade-offs
There is another side to the skills vs degree discussion.
Some people turn “skills matter” into “education does not matter.”
I disagree.
A degree provides structure.
It exposes you to areas you might not choose yourself.
It teaches theory that becomes valuable later.
It creates relationships.
It demonstrates that you completed a long academic commitment.
Some employers still require qualifications.
Some professions require specific formal credentials or licences.
Even in technology, a degree can help during early career screening, immigration processes, postgraduate study and some corporate hiring paths.
Skills also have weaknesses when pursued without structure.
A self taught developer may become excellent at one framework while missing important computer science fundamentals.
A person who learns only through urgent startup work can become good at fixing immediate problems while neglecting deeper engineering principles.
Breadth creates another risk.
Working across support, development, DevOps, project management, marketing and architecture teaches you a lot.
But nobody becomes deeply expert in ten disciplines at once.
You still need areas where your technical depth is strong.
So my conclusion is not degree versus skills.
It is degree plus skills, with skills proven through real work.
The certificate should represent what you studied.
Your work should represent what you can do.
Next Steps
If you are a student or early career developer, I would approach the next twelve months differently.
First three months: strengthen your foundation
Choose one development path.
Do not learn five frameworks simultaneously.
Learn one backend stack.
One frontend stack.
One database.
Git.
Basic Linux.
HTTP.
APIs.
Authentication.
Testing.
Learn enough networking to understand how your application reaches a user.
Learn enough security to understand what should never be trusted.
Months four to six: deploy something
Stop keeping every project on localhost.
Put one application online.
Use a real domain if possible.
Configure HTTPS.
Set up a database.
Add logs.
Handle errors.
Create backups.
Connect analytics.
Invite users.
Even a small project becomes valuable when someone else depends on it.
Months seven to nine: operate it
Do not abandon the project after deployment.
Watch what happens.
Fix bugs.
Measure slow requests.
Read logs.
Improve permissions.
Update dependencies.
Talk to users.
Write down recurring problems.
This stage turns development knowledge into engineering experience.
Months ten to twelve: take ownership
Choose a bigger problem.
Work with a business.
Join a startup.
Take an internship.
Contribute to an open source project.
Help a local organisation.
Build something for a real customer.
You need pressure from reality.
That is where judgment develops.
Then document the journey.
Explain what you built.
Explain the problem.
Explain the architecture.
Explain what failed.
Explain what you changed.
Explain the result.
That becomes your portfolio.
Not screenshots.
Evidence.
What I Would Tell My Younger Self
I would still complete my degree.
I would still study ICT.
But I would worry less about collecting proof that I had learned something.
I would spend more time proving it through work.
I would build earlier.
Deploy earlier.
Talk to users earlier.
Learn cloud infrastructure earlier.
Write about my projects earlier.
Ask for responsibility earlier.
I would also understand sooner that communication is an engineering skill.
A technically brilliant idea explained badly often loses to a simpler idea everybody understands.
I would learn that documentation matters.
Planning matters.
Customer understanding matters.
Cost matters.
Reliability matters.
Leadership matters.
And I would understand that career growth rarely comes from waiting until you feel completely ready.
You become ready by handling increasingly difficult problems.
Micro FAQs
Is a degree useless for a technology career?
No.
A degree gives you structure, fundamentals, academic credibility and access to opportunities. My point is that a degree alone is rarely enough to build a strong technology career. Combine education with projects, internships, production experience and continuous learning.
Should I skip a private university and learn technology myself?
Not automatically.
Choose based on your goals, finances and learning style. A good university can provide useful structure and connections. But if you choose a paid private degree, do not spend several years focused only on passing modules. Build practical skills alongside it.
What skills should a young developer learn first?
Start with problem solving, one programming stack, databases, Git, APIs, debugging, testing and deployment. Then add Linux, cloud basics, security and communication. Your goal is to move from “I know this technology” to “I used this technology to solve this problem.”
References
This article combines my first hand career experience with current hiring data and public information about the products discussed.
LinkedIn’s 2025 Future of Recruiting research reports growing emphasis on skills assessment and skills based hiring.
LinkedIn and OECD related analysis shows recruiters increasingly use skills as a search signal rather than relying only on educational pedigree.
EDUS publicly describes its live online learning model, applications and student ecosystem.
MediMan’s public website documents its live doctor booking, consultation, prescription and medical record workflows.
My own public portfolio documents my technology leadership work across full stack development, cloud, DevOps and product development in Sri Lanka.
CTA
Today my transcript and degree certificate are finally with me.
I am proud of them.
But I am even more proud of the systems running in production, the problems solved, the mistakes learned from, the users supported and the trust earned along the way.
Almost three years with EDUS and Yarl Ventures have taught me one lesson I will keep repeating to younger developers:
Do not spend your youth collecting proof that you learned. Build proof that you can do the work.
Get your degree.
Respect your education.
Then level up your skills much harder.
Because your certificate will eventually sit inside a file.
Your skills will keep building your career.
If you are a student or young developer reading this, do not tell me which certificate you plan to collect next.
Tell me what you are going to build in the next 90 days.
