Header image

TypeScript – How To Avoid “Any”?

26/09/2022

2.44k

  • The harmful effects of any
  • Avoiding any
TypeScript - How To Avoid "Any"?

How to avoid any?

In the previous blog – Typescript and “any” type, I introduced TypeScript and what exactly is any type.

In this blog, I’d like to show more about the harmful effects when using any and introduce some built-in types, features and customs types that you can use to avoid any.

The harmful effects of any

While TypeScript is a type checker, any type tells TypeScript to skip/disable type-checking. On the other hand, due to the nature of JavaScript, in some cases providing accurate types isn’t a simple task. In such situations, programmers are tempted to use any.

In most situations using or implicit any – a type that allows to store anything and skip type checkers, programmers can’t guarantee what type the value is stored and how it will be used. Furthermore, when the code is executed at runtime, errors may occur even though they were not warned before. For example:

let result; // Variable 'result' implicitly has an 'any' type.
result = 10.123; // Number is stored at 'result'

console.log(result.toFixed()); // `toFixed()` is a method of `number`

result.willExist(); // `willExist()` isn't a method of `number`, but no errors appear.

Because of that, the use of any is something that should be minimized as much as possible, to ensure the source code does not encounter any errors.

Avoiding any

Based on the basics of TypeScript and Everyday Types, in this blog, I’ll be sharing what I learned and used to write code without any.

Type aliases & Interfaces

A type alias is exactly a name for any type, you can actually use a type alias to give a name to any type at all, not just an object type. For example:

// Type alias
type Point = {
  x: number,
  y: number
};

type ID = number | string;

An interface declaration is another way to name an object type:

// Interface
interface IPoint {
  x: number,
  y: number
};

Differences between Type Aliases and Interfaces:

// Override
type Point = { // TypeError: Duplicate identifier 'Point'.
  a: string
};
interface IPoint {
  a: string
};

Union & Literal types

A union type is a type formed from two or more other types, representing values that may be any one of those types.

// Union types
let anyNumber: string | number;

// Usage
anyNumber = '123';
anyNumber = 123;
anyNumber = true; // TypeError: Type 'boolean' is not assignable to type 'string | number'.

In addition to the general types of string and number, you can refer to specific value of strings and numbers.
By combining literals into unions, you can express a much more useful concept. For example:

// Literal types
let direction: 'top' | 'left' | 'right' | 'bottom';

direction = 'top';
direction = 'top-right'; // TypeError: Type '"top-right"' is not assignable to type '"top" | "left" | "right" | "bottom"'

Type assertions

Sometimes you will have information about the type of a value that TypeScript can’t know about.

For example, if you’re using document.getElementById, TypeScript only knows that this will return some kind of HTMLElement, but you might know that your page will always have an HTMLCanvasElement with a given ID.

In this situation, you can use a type assertion to specify a more specific type:

// Type assertions
const myCanvas = document.getElementById('main-canvas') as HTMLCanvasElement;

Generics

// Example
const getRandomNumber = (items: number[]): number => {
  let randomIndex = Math.floor(Math.random() * items.length);
  return items[randomIndex];
};
const getRandomString = (items: string[]): string => {
  let randomIndex = Math.floor(Math.random() * items.length);
  return items[randomIndex];
};

// Generics function
const getRandomGeneric = <T>(items: T[]): T => {
  let randomIndex = Math.floor(Math.random() * items.length);
  return items[randomIndex];
};

// Usage
const teams: string[] = ['frontend', 'ios', 'android'];
const numbers: number[] = [1, 2, 3, 4, 5, 6, 7, 9, 10];

const randomResult1 = getRandomGeneric<string>(teams);
const randomResult2 = getRandomGeneric<number>(numbers);

In the example above, the getRandomGeneric is the generic identity function that worked over a range of types.

The type of generic functions is just like those of non-generic functions, with the type parameters listed first, similarly to function declarations:

const identity = <Type>(param: Type): Type => {
  return param;
};

When calling identity a function, you now will also need to specify the type of param that the function will use.

The detail above just Generic identity functions, you can read more generics Generic link

Unknown

unknown is what should be used when you don’t know a proper type of object. Unlike any, it doesn’t let you do any operations on a value until you know its type (skip/disable type-checker).

When you unknow something, you need to check before executing. For example:

const invokeAnything = (callback: unknown): void => {
  if (typeof callback === 'function') {
    callback();
  }
  if (typeof callback === 'number') {
    console.log(callback);
  }
  if (typeof callback === 'string') {
    console.log(callback.toUpperCase());
  }
};

// Usage
invokeAnything('typescript'); // Result: TYPESCRIPT

Record for basic object

Probably, nearly every JavaScript developer at some time has used an object as a map-like collection. However, with strict types, it may not be that obvious how to type this. So, you may use interface, but this way you can’t add anything to the object. Then, you need to think about using Record.

The definition:

type Record<K extends keyof any, T> = {
  [P in K]: T;
};

And the usage:

// Usage
const dict: Record<string, number> = {};
dict.a = 1;
dict.b = 'a'; // TypeError: "a" is not assignable to type number

let obj: Record<string, number>;
obj = {
  a: 1,
  b: 2
};

As you can see, it means that the developer can enter any key, but the value has to be of a specific type.

Conclusion

The TypeScript compiler is so powerful. There are so many things we can do with it.

any type can be avoided with more advanced technics such as interface, type intersection, and the use of generics, etc.

Hope you like it! Enjoy TypeScript and make the code without any!

Author: Anh Nguyen

Related Blog

prd-thumb-draft-product

Software Development

+0

    TypeScript And “Any” Type

    TypeScript is a strongly typed programming language that builds on JavaScript, giving you a better ability to detect errors and describe your code. But sometimes you don't know the exact type of value that you're using because it comes from user input or a third-party API. In this case, you want to skip the type checking and allow the value to pass through the compile check. The TypeScript any type is the perfect solution for you because if you use it, the TypeScript compiler will not complain about the type issue. This blog will help you understand the any type in TypeScript, but before doing that, let's begin with some basic concepts! What is TypeScript? TypeScript checks a program for errors before execution and does so based on the kinds of values; it’s a static type checker. Superset of JavaScript TypeScript is a language that is a superset of JavaScript: JS syntax is, therefore, legal TS. However, TypeScript is a typed superset that adds rules about how different kinds of values can be used. Runtime Behavior TypeScript is also a programming language that preserves JavaScript's runtime behavior. This means that if you move code from JavaScript to TypeScript, it is guaranteed to run the same way, even if TypeScript thinks the code has type errors. Erased Types Roughly speaking, once TypeScript’s compiler is done with checking your code, it erases the types to produce the resulting compiled code. This means that once your code is compiled, the resulting plain JS code has no type information. An easy way of understanding TypeScript A languageA superset of JavaScriptPreserver the runtime behavior of JavaScriptType checker layer JavaScript + Types = TypeScript Basic typing Type annotations TypeScript uses type annotations to explicitly specify types for identifiers such as variables, functions, objects, etc. // Syntax : type Once an identifier is annotated with a type, it can be used as that type only. If the identifier is used as a different type, the TypeScript compiler will issue an error. let counter: number; counter = 1; counter = 'Hello'; // Error: Type '"Hello"' is not assignable to type 'number'. The following shows other examples of type annotations: let name: string = 'John'; let age: number = 25; let active: boolean = true; // Array let names: string[] = ['John', 'Jane', 'Peter', 'David', 'Mary']; // Object let person: { name: string; age: number }; person = { name: 'John', age: 25 }; // Valid // Function let sayHello : (name: string) => string; sayHello = (name: string) => { return `Hello ${name}`; }; Type inference Type inference describes where and how TypeScript infers types when you don’t explicitly annotate them. For example: // Annotations let counter: number; // Inference: TypeScript will infer the type the `counter` to be `number` let counter = 1; Likewise, when you assign a function parameter a value, TypeScript infers the type of the parameter to the type of the default value. For example: // TypeScript infers type of the `max` parameter to be `number` const setCounter = (max = 100) => { // ... } Similarly, TypeScript infers the return type to the type of the return value: const increment = (counter: number) => { return counter++; } // It is the same as: const increment = (counter: number) : number => { return counter++; } The following shows other examples of type inference: const items = [0, 1, null, 'Hi']; // (number | string)[] const mixArr = [new Date(), new RegExp('\d+')]; // (RegExp | Date)[] const increase = (counter: number, max = 100) => { return counter++; }; // (counter: number, max?: number) => number Contextual typing TypeScript uses the locations of variables to infer their types. This mechanism is known as contextual typing. For example: document.addEventListener('click', (event) => { console.log(event.button); // Valid }); In this example, TypeScript knows that the event the parameter is an instance of MouseEvent because of the click event. However, when you change the click event to the scroll the event, TypeScript will issue an error: document.addEventListener('scroll', (event) => { console.log(event.button); // Compile error }); // Property 'button' does not exist on type 'Event'. TypeScript knows that the event in this case, is an instance of UIEvent, not a MouseEvent. And UIEvent does not have the button property, therefore, TypeScript throws an error. Other examples of contextual typing // Array members const names = ['John', 'Jane', 'Peter', 'David', 'Mary']; // string[] names.map(name => name.toUpperCase()); // (name: string) => string // Type assertions const myCanvas = document.getElementById('main-canvas') as HTMLCanvasElement; Type inference vs Type annotations Type inferenceType annotationsTypeScript guesses the typeYou explicitly tell TypeScript the type What exactly is TypeScript any? When you don’t explicitly annotate and TypeScript can't infer exactly the type, that means you declare a variable without specifying a type, TypeScript assumes that you use the any type. This practice is called implicit typing. For example: let result; // Variable 'result' implicitly has an 'any' type. So, what exactly is any? TypeScript any is a particular type that you can use whenever you don't want a particular value to cause type-checking errors. That means the TypeScript compiler doesn't complain or issue any errors. When a value is of type any, you can access any properties of it, call it like a function, assign it to (or from) a value of any type, or pretty much anything else that’s syntactically legal: let obj: any = { x: 0 }; // None of the following lines of code will throw compiler errors. // Using `any` disables all further type checking, and it is assumed // you know the environment better than TypeScript. obj.foo(); obj(); obj.bar = 100; obj = 'hello'; const n: number = obj; Looking back at an easier-to-understand any: A special type.Skip/Disable type-checking.TypeScript doesn't complain or issue any errors.Default implicit typing is any. Note that to disable implicit typing to the any type, you change the noImplicitAny option in the tsconfig.json file to true. Why does TypeScript provide any type? As described above, while TypeScript is a type checker, any type tells TypeScript to skip/disable type-checking. Whether TypeScript has made a mistake here and why it provides any type? In fact, sometimes the developer can't determine the type of value or can't determine the return value from the 3rd party. In most cases they use any type or implicit typing as any. So they seem to think that TypeScript provides any to do those things. So, is that the root reason that TypeScript provides any? Actually, I think there is a more compelling reason for TypeScript providing any that the any type provides you with a way to work with the existing JavaScript codebase. It allows you to gradually opt-in and opt out of type checking during compilation. Therefore, you can use the any type for migrating a JavaScript project over to TypeScript. Conclusion TypeScript is a Type checker layer. The TypeScript any type allows you to store a value of any type. It instructs the compiler to skip type-checking. Use the any type to store a value when you migrate a JavaScript project over to a TypeScript project. In the next blog, I will show you more about the harmful effects of any and how to avoid them. Hope you like it! See you in the next blog! Reference TypeScript handbookTypeScript tutorial Author: Anh Nguyen

    07/09/2022

    2.07k

    Software Development

    +0

      TypeScript And “Any” Type

      07/09/2022

      2.07k

      Our culture

      +0

        Tour “Đại lộ QC” – Hành trình khám phá nghề kiểm thử cùng ST

        Chào mừng bạn đến với series “Chuyện ngành chuyện nghề - Team QC”, nơi chúng mình kể lại những câu chuyện thật nhất về hành trình làm nghề, những niềm vui và… những pha “dở khóc dở cười” phía sau mỗi bản build. Để bắt đầu nghề QC thì không khó, nhưng để trở thành QC giỏi không phải điều dễ dàng. Trước khi lên đường khám phá, hãy cùng mình “bóc tem” một vài hiểu lầm kinh điển về nghề QC nhé! Có phải bạn đã từng nghĩ rằng: - Ai cũng học QC được? - Ai cũng làm QC được? - QC chỉ cần bấm bấm test test và report bug? Vậy thì hôm nay, hãy cùng gặp gỡ hướng dẫn viên du lịch - Nguyễn Quang Vũ (QC Team)  - người sẽ đưa các bạn tham quan một con đường huyền thoại mang tên “Đại lộ QC”. Thắt dây an toàn, cầm vé trên tay và chúng ta sẽ xuất phát ! Km 0 – Cổng “Khởi Đầu” Trước khi trở thành “người gác cổng chất lượng”, mỗi QC đều bắt đầu bằng giai đoạn… bấm mọi thứ có thể bấm. Đây là lúc bạn làm quen sản phẩm, hiểu người dùng, và tập làm bạn với bug. Bạn sẽ cần mô phỏng hành vi người dùng, bấm - nhìn - ghi để xem sản phẩm có chạy đúng như mong đợi. Tưởng đơn giản mà không hề đơn giản: phải quan sát và đặt câu hỏi đúng chỗ. ❓ Vì sao ai cũng nên dừng ở đây? - Đây là nơi hình thành tư duy kiểm thử và hiểu quy trình phát triển. Như học lái xe: nắm vững gương, đèn, phanh rồi mới tính chuyện đổ đèo. 💡 Mẹo sống còn: - Học cách viết test case rõ ràng. - Biết phân biệt bug vs feature (phao cứu sinh tình bạn với dev). - Ghi chép gọn gàng, ảnh/chụp màn hình là tem visa cho mỗi phát hiện. 🔌 Trạm tiếp năng lượng:  Kiểm thử các luồng “hơi đời” như mất mạng, pin 2%, nhập emoji vào ô số, đổi ngôn ngữ giữa chừng. Đây là nơi rất kích thích sự tò mò của các bạn! Km 10 – Ngã rẽ “Phát Triển” Ở Km 10, bạn chọn đường mình muốn đi, miễn đi sâu một nhánh: ⬅️ Nếu bạn chọn làn trái: Automation Test, nơi còn gọi là “Làng Code”. Bạn sẽ nhận được: - Bản đồ: biết code và tư duy code để tự động hoá những thứ lặp lại. - Điểm check-in: Script chạy qua đêm, CI/CD, báo cáo xanh lè sáng sớm. - Quà lưu niệm: Khả năng đọc API, log, mock data, dựng pipeline nhoáng cái là xong. ➡️ Còn nếu bạn chọn làn phải: Performance Test, được ví như “Thung lũng Hạ Tầng”. Bạn sẽ có 1 chuyến trải nghiệm thú vị khác: - Bản đồ: cần hiểu hệ thống, kiến trúc, infra logic; đo độ bền, độ tải, độ chịu nhiệt. - Điểm check-in: JMeter/K6, profiling, bottleneck, tuning database. - Quà lưu niệm: Biểu đồ đẹp như tranh, nơi có lời giải cho câu hỏi vì sao “chạy một mình thì nhanh, có người xem livestream thì… khựng”. 📍 Nguyên tắc vàng của Km 10:  “Biết nhiều một chút, nhưng phải biết sâu một phần.” Có chiều rộng để phối hợp, có chiều sâu để gánh trách nhiệm.  Ở đoạn đường này, QC không chỉ tìm lỗi mà còn đề xuất cải tiến, thiết kế trải nghiệm, góp phần tạo ra chất lượng toàn diện. Related Blogs: > Must-Have Tools for Business Analyst > How to Step Out of the “Forwarder” Shadow? Km 25 – Quảng trường “Tư Duy Làm Chủ” Sau một thời gian quen tay với việc test bug và viết test case, bạn sẽ nhận ra: QC không chỉ là người tìm lỗi, mà còn là người giúp sản phẩm tốt lên từng ngày. Đây là lúc bạn bắt đầu bước ra khỏi “vùng kiểm thử” quen thuộc để nhìn sản phẩm ở góc độ rộng hơn: người dùng đang cần gì, team đang gặp khó ở đâu, và giá trị thực mà sản phẩm mang lại là gì. Bạn bắt đầu làm gì? - Điều phối nhịp sprint, push tiến độ, sắp hàng ưu tiên, nhìn rủi ro bằng ống nhòm và nói chuyện người dùng như hàng xóm thân. ❓ Để ở lại quảng trường này lâu, bạn cần: - Hiểu quy trình từ yêu cầu → phát triển → phát hành. - Nắm sản phẩm & người dùng hơn cả tên thú cưng nhà mình. - “Thấu” team sản xuất: dev cần gì, design lo gì, PM sợ gì, khách hàng kỳ vọng gì. Bài học đường dài: QC giỏi có “la bàn hệ thống” - biết hướng về giá trị người dùng, không chỉ về “màu xanh của report”. Km 40 – Ghé thăm đặc khu “ST QC”  và Về đích  Sau khi băng qua những chặng đường đầy bug và deadline, mời bạn ghé trạm dừng chân tại đặc khu “ST QC”. Đây là nơi những người làm kiểm thử thật sự trưởng thành và tìm thấy hướng đi cho riêng mình. Tại đây, bạn sẽ được “đi tour” qua đủ mọi cung đường nghề QC. Từ Manual Test đến Automation hay Performance Testing, thử sức để biết bản thân phù hợp với hướng nào. Ở ST luôn được khuyến khích học hỏi, có mentor tận tình chỉ đường, và rất nhiều ngã rẽ nghề nghiệp cho bạn mở rộng: từ QA, QC Technical Lead, cho đến BA hay PM. Chúng mình tin vào văn hoá “đi thực chiến trước, giáo trình hoá sau”. Nghĩa là không học để biết, mà học để dùng, để làm cho sản phẩm tốt hơn mỗi ngày. Vé VIP cho người mới Mentor thâm niên luôn đồng hành cùng bạn.Starter Kit “xịn”: test template, bug report, release checklist, sample pipeline.Nhớ câu thần chú:  “Chất lượng là thói quen mỗi ngày, không phải phép màu cuối sprint.” Phụ lục cho hành khách yêu khám phá. Trên “Đại lộ QC”, bạn sẽ bắt gặp những biển báo quen thuộc: ⚠️ Cảnh báo dốc: Thiếu kiên trì, kỷ luật hay tư duy hệ thống rất dễ tụt dốc.🆘 Làn khẩn cấp: Khi hoang mang, hãy quay lại acceptance criteria và dữ liệu gốc.🏥 Trạm y tế: Nếu burnout, dừng lại nghỉ, xem lại ưu tiên và xin hỗ trợ đoàn mình không ai bị bỏ lại. Combo “Túi đồ nghề QC” Checklist / Test Case, Mindmap risk, Template Bug Report, Common Edge Case, Script tiện tay. Trang bị đủ hành trang để bạn tự tin băng qua mọi sprint nhé. “Đại lộ QC” không phải đường cao tốc thẳng tắp, mà nó còn có dốc, có đèo, có khúc cua tay áo. Nhưng đổi lại là một hành trình đáng nhớ: sản phẩm chạy mượt, người dùng mỉm cười, team tin tưởng nhau hơn. Con đường này dễ xuất phát nhưng khó về đích. Vì thế hãy  luôn vững tin với chiếc vé mang tên kiên trì, kỷ luật, tư duy hệ thống, chúng sẽ giúp bạn đến được nơi mình muốn. Nếu bạn đã sẵn sàng, mời lên xe chuyến sau. Hướng dẫn viên “trái ngành” vẫn ở đây, tay trái cầm bản đồ, tay phải cầm… checklist. Hẹn gặp bạn ở một cột mốc mới trên Đại lộ QC!

        12/11/2025

        29

        Our culture

        +0

          Tour “Đại lộ QC” – Hành trình khám phá nghề kiểm thử cùng ST

          12/11/2025

          29

          Knowledge

          Others

          +0

            Must-Have Tools for Business Analyst

            In today’s fast-evolving tech world, working smart has become even more crucial than working hard. In IT environments — and in any modern business — managing a growing amount of complex work can’t rely solely on memory, scattered emails, or individual Excel sheets. One of the most effective ways to boost productivity intelligently is through the use of supporting tools.This isn’t just a trend anymore — it’s quickly becoming the standard in many companies. For Business Analysts (BAs), the right tools don’t just make you more efficient — they make you more professional. Let’s explore some essential tools every BA should have in their toolkit 👇 1. Draw.io A free, intuitive diagramming tool to visualize processes, systems, data, or ideas.It’s ideal for modeling workflows and mapping business logic. Key Features: Free and no registration required — just go to diagrams.net.Flexible storage — save files locally or to Google Drive, OneDrive, GitHub, GitLab.Rich icon library — supports UML, BPMN, flowcharts, network diagrams, and more.UML & BPMN ready — perfect for use cases, activity diagrams, and business flows.Easy collaboration when stored on shared drives.Cross-platform — available on web, desktop, and as a VS Code extension. Limitations: Real-time collaboration isn’t as strong as tools like Figma.Performance may drop with very large or complex diagrams. 2. Miro Miro is an online collaborative whiteboard designed for teams to brainstorm, plan, and visualize ideas in real-time. Key Features: Infinite canvas — visualize projects without space limits.Real-time collaboration — comment, vote, and co-edit instantly.Rich templates — includes user story maps, journey maps, mindmaps, Kanban boards, and wireframes.Integrations — connects with Jira, Confluence, Slack, Teams, Google Drive, and more.Great for mapping processes, use cases, roadmaps, or even UI mockups. Limitations: Free plan limits the number of boards.Large boards with many assets may slow down performance. 3. Trello Trello is a Kanban-based task management tool that helps teams visualize and track progress easily. Key Features: Simple drag-and-drop interface.Highly customizable boards, lists, and cards.Each card can include checklists, attachments, labels, due dates, and assignees.Seamless integration with Google Drive, Slack, Jira, GitHub, and others.Real-time updates across all team members.Works on web, desktop, and mobile. Limitations: Free plan limits the number of integrations (Power-Ups). 4. Jira Jira by Atlassian is the industry-standard project management tool for Agile teams. Key Features: Built for Scrum and Kanban teams.Highly customizable workflows, fields, and automation rules.Transparent tracking of tasks, blockers, and progress.Integrates with hundreds of DevOps, CI/CD, and testing tools.Scales from individual tasks to enterprise-level project portfolios. Limitations: Steep learning curve for beginners.Can be costly for large teams.Requires experienced admins for setup and maintenance.May run slower on large, complex projects. 5. Typescale A handy tool for generating consistent typography systems (font size, line height, spacing) for web or app design. Key Features: Automates type scale creation.Multiple presets and flexible customizations.Preview and export CSS directly.Ensures responsive and accessible typography. Limitations: Not suitable for all design systems or content types.Limited control over detailed responsive behavior. 6. Adobe Color An intuitive color palette generator to create harmonious and accessible color schemes. Key Features: Easy-to-use color wheel with real-time updates.Auto-generates color harmonies based on color theory.Supports HEX, RGB, and CMYK formats.Integrates seamlessly with Adobe tools like Photoshop, Illustrator, and XD.Community palette sharing and inspiration gallery. Limitations: Contrast still needs manual checking for accessibility.Some auto-generated palettes may need manual tweaking.Colors can look different on various screens. 7. Contrast Checker A simple but vital tool to ensure readability and accessibility by checking text and background contrast per WCAG standards. Key Features: Simple interface — input colors and get instant feedback.Ensures compliance with accessibility guidelines.Real-time updates as you adjust colors.Bridges design and development — everyone can validate contrast easily. Limitations: Doesn’t reflect results accurately for complex backgrounds.Doesn’t account for font size, spacing, or user testing conditions. Why Use These Tools? Transparency: Everything — from tasks to deadlines — is clearly tracked. For example, Trello helps answer questions like “Who’s doing what?” and “What’s the current status?”Visualization: Tools like Draw.io help transform abstract logic into clear, easy-to-understand diagrams.Collaboration: Integrating tools like Miro, Jira, or Slack ensures everyone stays aligned and reduces miscommunication. Tips for Getting Started Start small: You don’t need every tool at once. Begin with Jira or Trello, then expand.Build shared habits: Tools only work when the whole team uses them consistently.Learn by doing: Explore free trials and tutorials, then apply them directly in your current projects.Stay updated: Tools evolve fast — keeping up helps you stay ahead. Using tools isn’t just about having more software — it’s about changing the way we work.They make our processes more transparent, our teamwork more seamless, and our output more efficient. For Business Analysts, these tools are not just “nice-to-have” — they’re what turn you from a task executor into a strategic enabler for your team. Read more related articles from SupremeTech!

            31/10/2025

            124

            Sang Ngo

            Knowledge

            +1

            • Others

            Must-Have Tools for Business Analyst

            31/10/2025

            124

            Sang Ngo

            Knowledge

            Others

            Our culture

            +0

              How to Step Out of the “Forwarder” Shadow?

              Have you ever, as a Comtor or Business Analyst (BA), felt like… a messenger? Every time the client asks something, you turn to the team, copy their answer, translate it, and send it back — just passing messages instead of actually owning the conversation. At SupremeTech, our BA team jokingly calls this role the “Professional Forwarder.” Through many “lost in translation” moments, we’ve learned valuable lessons on how to step out of that shadow — to become real connectors between the client and the team. Let’s hear from our BA team as they share practical tips to help you move beyond being a “forwarder” drawn directly from real project experience. Signs You Might Be Forwarding Too Much 1. The classic line: “Let me check with the team.”It’s not wrong — but if you’re saying it too often, it might mean you don’t fully understand the issue. 2. Lack of confidence in meetings: Many new BAs struggle with open-ended questions. When you don’t fully understand the product, you can’t confidently answer questions from both the client and your internal team. The PM asks about progress, you look at the Sprint Backlog full of numbers — and still don’t know where to start. 3. Avoiding technical talk: The moment you hear technical terms, you “pass the ball” to the PTL — without really understanding what’s being discussed. 3 Steps to Escape the “Forwarder Manager” Role So, how can you move from being a Forwarder to becoming a true communicator — someone who understands, connects, and leads discussions effectively? Here are three simple but powerful steps you can start practicing right away: 1. Before Forwarding, Ask Yourself: Do I understand at least 70% of this content?Have I tried to reproduce the bug, test the feature in the DEV environment, or explore the possible cause myself?If I were the dev/tester receiving this message, would I have enough context to understand it?Can I classify the issue — is it about UI/UX, logic, data, or business flow?Can I try to answer part of it first, then confirm later? 👉 This habit helps you learn something new every day, instead of just finishing tasks every day. 2. In Every Meeting – Observe and Lead What is the team really discussing? Do I understand the big picture?If the conversation is technical, how does it relate to the overall context?Is anyone confused? Can I help clarify? If you find yourself unsure about all three — take notes, take notes, and take notes.Meeting minutes and your own notes will help you retain details and follow up later for deeper understanding. 3. Build Strong Foundations Whether you’re a Comtor, BA, or PO, a solid foundation in product knowledge, business logic, and basic technical understanding helps you make better decisions — and lead your team effectively. Don’t get stuck thinking “that’s not my task.” Instead, learn actively by: Reading about technical keywords used in your project.Redrawing the business flow yourself to truly understand it.Asking devs, QCs, PTLs, and clients for their perspectives.Finding a technical advisor who can review your understanding and answer your tech-related questions. Every time you’re about to forward a message, pause for a minute — dig a little deeper.Each pause adds to your knowledge and analytical mindset. These small daily efforts will sharpen your skills and confidence — helping you grow not only as a professional BA, but also as a potential Project Leader who truly adds value to the team.

              31/10/2025

              134

              BA Team

              Knowledge

              +2

              • Others
              • Our culture

              How to Step Out of the “Forwarder” Shadow?

              31/10/2025

              134

              BA Team

              Customize software background

              Want to customize a software for your business?

              Meet with us! Schedule a meeting with us!