Komunikasi Level Dewa: Macam mana nak terangkan pasal “Technical Debt” dekat bos yang bukan budak IT?

Aku pernah buat silap besar.

Aku explain technical debt dekat top management dengan ayat macam ni:

“Code ni dah serabut, architecture tak clean, refactor sikit baru scalable.”

Muka bos kosong.

Dia tak peduli code cantik atau tak.
Dia peduli benda ni saja:

• Akan break tak?

• Data customer selamat tak?

• Duit bocor tak?

• Brand rosak tak?

Kalau kau nak approval untuk fix technical debt, kau kena tukar bahasa.

Bukan bahasa programmer.
Bahasa risiko bisnes.

1. Jangan cakap “code tak cantik”. Cakap “ini boleh meletup”

Technical debt bukan isu aesthetic.

Ia isu:

• Downtime

• Data corruption

• Security breach

• Wrong calculation

• Customer trust jatuh

Contoh real case aku.

Dalam satu sistem Laravel, aku setup Telegram alert dalam ->withExceptions().

Bila error yang “tak sepatutnya berlaku” berlaku, aku terus dapat notification.

Bukan tunggu client complain.

Bila aku tunjuk dekat bos:

“Dalam minggu ni, ada 17 error yang patutnya tak wujud.”

Terus dia faham.

Sebab sekarang ini bukan cerita code.
Ini cerita sistem dah mula retak.

2. Categorize technical debt macam classify penyakit

Bos tak nak dengar 100 isu.

Dia nak tahu priority.

Aku selalu categorize technical debt kepada 4 level:

1. Not Urgent

Contoh:

• Query boleh optimize

• Duplicate function

• Naming tak konsisten

Impact:
Tak effect revenue sekarang.
Cuma memperlahankan future development.

Ini kau boleh schedule.

2. Urgent but Not Critical

Contoh:

• Validation tak lengkap

• Minor logic flaw

• Calculation rounding issue

Impact:
Boleh create silent bug.
Revenue boleh lari sikit sikit.

Ayat untuk bos:

“Ini tak bunuh kita hari ini, tapi setiap bulan kita bocor sikit.”

3. Urgent and Critical

Contoh:

• Permission role leak

• Endpoint tak protected

• Business rule tak enforce

Impact:
Data boleh salah.
User boleh access benda tak patut.

Ayat untuk bos:

“Kalau benda ni kena exploit, kita bukan repair code. Kita repair reputation.”

4. Emergency

Contoh:

• Security vulnerability known

• Payment callback tak reliable

• System boleh crash under load

Impact:
Boleh break anytime.

Ayat direct:

“Ini bukan technical improvement. Ini survival mode.”

3. Gunakan bahasa duit, bukan bahasa clean architecture

Bos tak kisah:

• SOLID principle

• Refactor service layer

• Event driven pattern

Bos kisah:

• Kalau sistem down 1 hari, berapa RM hilang?

• Kalau data leak, berapa trust hilang?

• Kalau wrong commission payout, berapa cashflow rosak?

Kalau kau nak convince, convert technical debt kepada:

• Potential revenue loss

• Potential legal risk

• Potential PR disaster

4. Tunjuk bukti, bukan teori

Telegram alert tu game changer.

Sebab bila aku cakap:

“Ada error tapi user tak nampak.”

Bos rasa itu hipotesis.

Bila aku tunjuk screenshot:

• Timestamp

• Error message

• Frequency

Terus conversation jadi real.

Technical debt yang invisible jadi visible.

5. Jangan jual “refactor”. Jual “risk mitigation plan”

Salah satu mistake paling common:

“Bos, saya nak 2 minggu untuk refactor.”

Refactor bunyi macam luxury.

Instead, tukar framing:

“Saya cadangkan kita ambil 5 hari untuk remove 3 critical risk point sebelum scale marketing.”

Sekarang ia jadi strategic move.

Bukan kerja backend yang nerdy.

6. Align dengan growth plan

Ini paling power.

Kalau bos tengah nak scale:

• TikTok Ads

• Franchise

• Multi branch

• Add new agent

Kau cakap:

“Dengan architecture sekarang, kita boleh scale sampai point tertentu saja. Lepas tu kita akan start patching instead of growing.”

Sekarang technical debt bukan isu developer.

Ia jadi bottleneck growth.

Formula mudah untuk explain technical debt

Jangan cerita code.

Gunakan formula ni:

Risk x Probability x Impact = Priority

Kalau probability rendah dan impact kecil, schedule.

Kalau probability sederhana tapi impact besar, escalate.

Kalau probability tinggi dan impact besar, itu emergency.

Bos faham benda macam ni sebab ini bahasa bisnes.

Real Talk

Technical debt bukan masalah IT.

Ia masalah komunikasi.

Kalau kau explain guna jargon:

• Clean code

• Refactor

• Technical restructuring

Kau akan kalah.

Kalau kau explain guna:

• Risiko bocor duit

• Risiko kena hack

• Risiko reputasi rosak

• Risiko tak boleh scale

Kau akan dapat green light.

Penutup

Komunikasi level dewa bukan tentang pandai bercakap.

Ia tentang translate complexity kepada consequence.

Bos tak perlu faham code.

Dia cuma perlu faham:

“Kalau kita tak buat sekarang, apa benda paling buruk boleh jadi?”

Kalau kau boleh jawab soalan tu dengan jelas,
technical debt bukan lagi isu backend.

Ia jadi agenda board meeting.

Dan masa tu, kau bukan lagi programmer.

Kau dah jadi strategic asset.

P/S: nak buat sistem automasi bisnes anda? jom cuba Servis buat sistem automasi custom