It's hard to develop a cybersecurity roadmap since several elements need to be considered, such as compliance and risk posture, policy framework, detection and response capabilities, resilience and recovery after a breach.

Let's discuss what executives typically ask...

Are we Compliant?

You can be compliant, but that doesn't mean you're secure, but you can get there and there's a lot in compliance requirements and standards etc. that'll help you out. In the end, it won't make a lot of difference unless you live and breathe it.

Are we Secure?

In the same token, you can be compliant and still be secure, and we see that quite a bit of the time, when people have very good security practices and operations in their organization, but they're bad at documenting stuff, so from a compliance standpoint, they won't be compliant but still secure.

How much progress did we make in making us more secure?

How did we do compared to last year? That's a tough one since the landscape in which we worked last year was different. As you know, the attacks that we saw last year might have been a few, but now we may see attacks that are vastly different from what we saw in the past. Information Security is a dynamic discipline, which means that everything changes and everything stays the same, so all the processes, procedures, and things we do from an operational perspective don't really change that much over time. However, attacks, how we respond to them, do change every day, so it's a bit of both.

In the last 12 months if you didn't change your security effort, you were doing a great job dealing with the types of attacks you were seeing, but if you're still doing the same thing, then there's a fair chance that the attacks have outpaced you.

What would we do in case of a breach?

This is a great question because they're trying to figure out if you're prepared for an attack since their awareness has been raised. Whenever there's an incident, we see people like you asking this question.

When executives ask all these questions above, there's actually a subtext to the questions that they're actually asking.

When they ask for “Are we compliant?” they're really asking...

• In order to achieve or exceed our goals, what standards must we meet?
• Have we met them yet?
• How are we doing? Do we continue to meet with them?

On the similar footsteps “Are you secure?”

• What are the current risks and how well do we understand them?
• Are we aware of our key assets?
• What are we doing to protect those key assets?

That’s the question really being asked!!

“How much progress did we make in making us more secure?”

• Over the past year, what has changed?
• What are we doing to meet these new challenges?
• What are the areas where we need to improve?

“What would we do in case of a breach?”

• How have we handled incidents that have actually occurred?
• What did we learn and how are we adapting?
• Were there any changes we made to ensure we met the challenge?

In essence, that's what the executive is asking when he's asking any one of these four questions, but if you ask them on their own they can be difficult to understand, but if you combine them, they give you a clearer picture of where the organization fits into the security structure.

What does good security look like?

Good security needs to be proactive

In a lot of companies, security teams are purely reactive, they react to new features and projects request for assessment. We've all probably run into the situation where someone comes up to your desk just before the weekend and says “hey, this project needs to go live in a few hours, can you please approve it? 😰”. Our security team needs to change from a reactive to a proactive one.

Security should not be Obstructive.

Often, in-your-face security generates obstacles to the business, so our role as security team is to ensure that the business is able to do what it needs to do in a secure manner. Nobody has ever thanked a security team for saying "No" constantly. Obviously there are times when saying No is the right thing to do because there are plenty of things from a security perspective that are bad ideas, but ideally you'll have a security team that can actually contribute to the success of the organization.

Security Coverage is one of the main pillars.

The right coverage needs to happen,with tools and solutions that are in place, we let it run and then in many organizations it is just there for the rest of the year. We come across systems that after it's been implemented it's never been touched, well it does what it's supposed to do but they do need kind of a little bit of love.

Implement technology/controls correctly

If your organization is at the point where you have firewalls and anti-viruses - for instance, if you have firewalls, then your next purchase won't be one that grabs everything and analyzes it all - there is probably a technology use between the two that you will want to consider.

Minimize the Risk

There is a need for us to understand what the risks are. We need to understand what we will be able to do about these risks in order to minimize them as much as possible.

Cost Effectiveness

Security solutions must be cost-effective. If it is going to cost 2-3 times as much as the annual revenue of the company, it is probably not going to be of much use to the company.

Responding to current threats

Having an understanding of what's going on in the world right now will give your security team a competitive edge towards proactiveness.

Repeatable process

You must be able to repeat whatever you do. If you discover an XSS, you may be able to find the same issue anywhere with the help of tools and scripts sooner, so you can focus on more interesting things rather than sweating over finding the same issue on different instances a week later.

Detailed documentation

Documentation is important and we all kind of stink at it a little bit. but it's okay to start small and then build slowly.

What does it take to get good security?

In an organization, four main functions must take place:

• Make sure you're taking some sort of Risk and Compliance/Governance to help identify what you need to protect. To do this, you need to know your assets, your risks, your controls, your metrics, your policies, etc., all documented in a rinse, lather, repeat manner.

• There is typically some sort of Security Architecture and Design component within an organization, this is a team that liaises with the business more closely to understand what the requirements are, what the impacts are, how I will protect it and how will I know it's being done well. We can't emphasize enough how important it is to get into a project earlier. Instead of finding out at the end that someone has put a database somewhere in the internet and you're connecting to it over HTTP. Or, code has been downloaded from a Russian website and embedded into your core application, it would be nice to find out at the beginning rather than at the end.

• The Security Administration function is all about adding users, giving them access, taking it away, and doing some reviews. In order to succeed in security administration, you typically need to have some defined processes, regular review, and maintenance procedures.

• Security operations role is to detect,respond and identify any threats. The goal here is to gain visibility on network servers and endpoints, and make sure that the tools that cover what you're supposed to cover are configured appropriately. Respond to threats, manage them, and analyze them.

Skills and services for all of these requirements are not necessarily confined to your organization, and it's fine to get someone else to assist you. You don't necessarily have to run a security business but some of these functions must be performed and they must be handled by someone, which you can outsource easily.

Where are we in terms of security maturity?

There's different ways of doing it and it’s obviously a very high level and to be honest the more immature you are the easier this process..

• Non-Existence: we have a Firewall we have AntiVirus if that's the answer to the question of what are you doing for information security then you're probably going to be in that non-existent. However, that makes life easy because your roadmap can take in whatever direction you want to be with minimal friction from the stakeholders.

• Immature: In general, you will have a Security Administration function and you may have some policies, or you might not have any policies at all but people just know what to do. People seem to know what to do quite naturally when it comes to this. You might have some technical controls beyond your firewall or your antivirus in place within the organization, you might do some threat management, we're still a fairly immature organization, there's no real strategy.

• Doing our best: In this case, the Security Admin function is pretty good, and you can add/remove users, modify policies, or even develop a little bit of a risk and compliance or security operations tool, these technical controls with some customization. In contrast to the default tools you bought on day one, these have actually had some thought and configuration assigned to them.

• Getting there: Everyone is aware of the Security Administration's policies. As part of security operations, you're getting some visibility into the network, you're having some logs and cloudtrail set up, and you're reviewing those logs. Your risk and compliance function is taking place throughout the year, and you're analyzing where you sit for the most significant risks. Getting involved in projects means you know it may not be at the end, maybe you're in the middle, but the objective is to get there as soon as possible.

• Mature: You start adding to get established and you've got things documented. Security operations are improved on your visibility. The policies are in place and they're regularly being reviewed. The technical controls are in place.

• Very Mature Organization: You're doing everything you were doing before, but now that you have metrics, you can determine whether or not things are working as they should. Your security architecture is documented. You have invested resources in automating some administrative or operational tasks. You're reducing the time it takes you to respond to incidents and noticing them more often. Perhaps you are evaluating the advanced tools deployed within your organization now that the policies are in place.

The next post - "part ii" of this series will discuss ways to improve security and the roadmap.

🙏

References:

• McAfee
• PurpleSec
• TechTarget
• Shearwater
• Tribe of Hackers Security Leaders
• Cybersecurity Leadership
• A Leader's Guide to Cybersecurity

This article is cross-posted from avinash's blog.

What was your career like before switching to tech?

When I moved to Asia from Germany, my primary source of income was the German language. I’ve worked as a translator, transcriber and language teacher for few years before making a switch.

What made you think about a career switch to tech?

Before switching to tech, I was working as a freelance German teacher in Singapore. Being a teacher was fun, but the job didn’t really challenge me anymore. I was always teaching the beginner level of students and it being language teaching, the knowledge required to teach becomes fairly constant over time. The job didn’t challenge me anymore.

Apart from job dissatisfaction, another factor that contributed to my decision was that with teaching, there was an income ceiling that I reached and I was looking for something new with growing responsibilities at home.

As to why I chose tech, I was always the computer kid of the block, burning CDs, building my own PC. I started building video game guide websites when I was 14-15 using HTML and inline CSS. This was pre-2000s, so I don’t think stylesheets were a thing back then. I continued developing some Wordpress websites later on here and there e.g. for my Gym.

How did you start your journey of a career switch?

Around 2018 or 2019, I really took serious the idea of a career switch to tech. I started self studying with some Udemy courses and other resources like FreeCodeCamp. After about 6-9 months of self-study, I thought to myself, I really want to do this now.

I was looking up bootcamps and the teacher of my Udemy course was a bootcamp instructor for General Assembly in U.S and that’s how I got to learn about General Assembly and I enrolled in their Singapore chapter for a 3 month Full time program

What benefits you got after enrolling in a bootcamp vs self study from online courses?

I think what really set apart bootcamp and self study from online courses was the intensity. If you’re at home studying, you maybe watch 30 minutes or 1 hour of videos for the day and get done for the day. But with bootcamps, you’re kind of forced to code more than 8+ hours per day. It helps put drastically more time into coding to hone my skills.

In addition to that, you have an actual class environment  where other people are there physically (this was pre-covid) and if you have problems, there’s people to help you. They guide you in your mental model in terms of approaching programming. Otherwise, you have to figure out all these things by yourself.

What was the balance between theory and practice in the bootcamp?

It’s a good mix. There’s theory sessions on premises for 5-6 hours with little exercises or mob/pair programming mixed in. After the class we have some homework exercises which was basically solidifying this work. In addition to that, we had a daily standup which helped us raise problems daily and get advice on solving them.

In parallel to that we had a project we were working on throughout the bootcamp with a total of 5 projects with one of them being a group project

Taking Glints as a reference, what were some of unexpected differences b/w bootcamp and the real job?

The first thing that really stood out to me was on the first step, the technical assignment. In the assignment project I had to deal with a data set of ~ 5000 rows, but in bootcamp projects, we dealt with I dunno - maybe 10 or 20 rows. Working with this huge dataset was like, wow, how to do that.

After joining, the codebase itself was overwhelming to me because it looked so gigantic compared to what we did in the bootcamp. With my bootcamp experience, it looked similar to what we learned, but since the size was so big in comparison, it was a different experience going through the codebase. I slowly figured those things out by some improvisation and help from my coworkers.

Another aspect that is not discussed really is the communication part of the job. We got together to discuss technical plans, details, product features and making plans for delivering those features. This was quite unexpected because I didn’t hear in bootcamp and there weren’t much resources on Google highlighting this aspect of collaborating with the team. Its the opposite of the stereotype of the typical programmer being alone, just doing their own thing. But I have to say, this kind of worked into my benefit since communication is one of my stronger suits.

Another surprising thing was the focus on error handling. In bootcamp, error handling was not a priority but at Glints, working on production applications, there was an increased focus on well defined errors.

One thing though that bootcamp helped a lot is the awareness of tools and what to search in the first place. Knowing that something like react dev tools exists makes a huge difference in understanding bigger codebases later on.

What is your definition of success from a bootcamp program and the qualities needed to achieve this success?

Taking the bootcamp as a means to gain independence in programming. I feel if you just sit in there and you expect the instructor to deliver everything and make you a good programmer, that would be an unrealistic expectation. The instructor can teach you all the concepts and everything, the syntax and the grammar for everything. In detail, but if you yourself, don't pick up your ass and like walk these steps, you will never become proficient.

At some point in the bootcamp, there’s gonna be moments when you feel like banging your head on the table because of some things not working. The definition of success from the bootcamp would be the ability to rely on my knowledge and the ability to work through these challenges.

P.S. This blog post is a summarised version of a fireside chat type call between Shubham and Robert.

As an aspiring software engineer, I am always on the lookout for interesting opportunities that would help me build practical knowledge, cultivate good engineering habits and expand my wisdom on managing domain-specific burnouts. Here are the 3 practices that I was able to apply to my life after my 5-month internship at Glints.

Extensive Use of Slack Emojis

Even though my primary role as an SWE intern was to learn and contribute code, my favourite activity was actually choosing the right emojis to respond to various situations. Emojis are awesome because they allow us to express ourselves creatively and concisely.

At Glints, emojis were used extensively to communicate support, concern, and more. Custom emojis were even created to immortalise memories. I guess in a Covid-19 situation, emojis really help people to connect more deeply. For me, it brightens my day when I see colleagues choose their favourite emojis to welcome newcomers, lighten the mood, or even express dismay tactfully.

Sometimes, emojis were used in a more subtle manner, like through a simple “ok” or “thank you” which ended conversations on good terms. An emoji can’t speak a thousand words, but it can certainly speak succinctly. It was pleasant to witness how emojis could brighten my day so I am excited to use emojis more mindfully in other areas of my life.

Establishing Active Channels for Support

Besides the use of emojis, I have benefited much from the active Slack channels established to facilitate communication between teams and allow engineers to seek help. These slack channels bridge gaps in understanding and foster a collaborative culture.

For instance, posting a challenging frontend bug on the #Frontend channel encourages engineers of various teams to share what they know on the same thread. This cross-team communication allows for engineers with knowledge previously exclusive to themselves to collectively arrive at a solution that 2 engineers could not achieve in a private message space.

When I was working on the upgrading of Styled Components on the Glints Job Marketplace, I learned much from discussions on the Frontend channel because engineers from other teams shared concerns specific to this task. Discussing approaches to the problem publicly saved me time and allowed me to resolve blockers quickly, while keeping various parties in the loop.

Biweekly Engineering Sharing

Engineering tech sharing is a biweekly practice meant to encourage engineers to share whatever they feel like sharing with their fellow engineers.

Such sessions included a Flutter crash course, a proposal of Kafka Stream Optimisation and an SEO introduction. This practice fosters a sense of curiosity and inspires engineers to try new things, be it recreationally or professionally. As an intern, I was also warmly encouraged to do a sharing - I gave a gentle introduction to Google Apps Scripting(GAS). Despite just delivering a high-level overview of what GAS could do, basic syntax and an illustration of small applications, I was pleasantly surprised when the security lead slacked me to clarify a GAS workflow he was implementing at Glints!

The practice of engineering tech sharing showed me that making time to share knowledge with your team could be an immensely helpful thing to your teammates so I’d like to carry on this spirit in my school projects.  

The above engineering cultural practices at Glints were just some of the informal observations that stood out to me. As I continue my SWE journey by returning back to school, I feel better equipped with systems to organise learning, handle working relationships in my school projects and add life to my future workplace when I secure a full-time job.

In the beginning of 2020, Glints was in need of an A/B testing platform for us to test out different variants of a feature and we settled on an open source solution - Unleash. We evaluated multiple platforms but decided to use unleash because of the following reasons:

• A simple UI for non-tech people to control the experiments
• Language agnostic with client libraries in multiple languages
• Actively maintained project (we started with Unleash v3 and now we are using Unleash v4 with significant improvement in terms of features)

What is Unleash?

Unleash is an open-source feature management platform. It provides a great overview of all feature toggles/flags across all your applications and services.

Architecture overview:

This is what our architecture with unleash looks like. We have the unleash server which is responsible for storing all the feature toggles, their strategies and their history along with all the unleash user info.

We do not directly access unleash via our front end clients. That would expose unnecessary information about the feature toggles that the user doesn't need to know e.g. which features have been disabled for them. The API server acts as a proxy between the front end clients and the unleash server.

The Glints API server connects to the unleash server to get the data of existing feature toggles. Using this data, the proxy endpoint gives a list of feature flags that have been enabled for the user along with the variant if it exists when requested by the client. Absence of a feature flag from the list should be perceived that the feature flag has been disabled for that user.

The API endpoint would return the feature flags based on the unleash-context provided by the front end client.

Would the unleash server being down affect my application?

Not at all. This is one of the things that we love about Unleash.

All of the Unleash SDKs (unleash-client-node in our case) do something called local evaluation. That means that only the information about a feature toggle is stored on the unleash server, but assigning a user to a variant A or a variant B happens via the SDK. This means that if your unleash server is down, your feature flags would still keep on working on the last known state without any updates possible to the existing state.

Does unleash come with built in tools to analyse the performance of each variant of the A/B test?

No, we use Amplitude at Glints to analyse how each of our variants in the tests are performing. We think its for the best since Unleash is a feature management platform and it does that 1 thing right instead of trying to dip its toes in multiple places.

Checkout https://docs.getunleash.io/ to get started on Unleash!

Software engineers have a natural aversion to non-ascii characters. Emoji in variable names? No thanks. However, when dealing with user inputs, this aversion turns out to be a big blind-spot.

Many languages use special characters like the Spanish ñ, the German umlauts (ä, ö, ü) or the é in café. Other languages such as Chinese, Japanese and Korean completely rely on non-ascii characters.

When Glints started operating in Vietnam, this blind-spot became particularly acute. User feedback started rolling in, mostly complaints about location form elements not working as expected.

The Vietnamese Alphabet

Vietnamese, like English, is based on the Latin alphabet, but uses diacritical marks to form seven additional letters, and to indicate tonality.

The additional letters are đ, ă, â, ê, ô, ơ and ư. While pronouncing them as if they did not have any marks works in a pinch, it is not correct. They are not interchangeable with the unmarked letters.

The same goes for the tone marks: There are six tones in Vietnamese, and they are marked with five diacritics: Má (acute), mà (grave), mả (hook), mã (tilde) and mạ (dot below). The sixth one is the absence a tone mark. Tone is the curve of the pitch of the voice when speaking a word. For example, the word má is pronounced with a rising pitch, similarly to how in English, to indicate a question, the speaker's voice rises in pitch towards the end of the sentence.

It is tempting to just ignore these diacritical marks, but if we want to fix our form inputs, we certainly can not. All marks have a meaning, and omitting them will either produce a non-existing word, or a word with a different meaning. For example, the word con dế means cricket, but con dê means goat!

As the word con dế above demonstrates, the additional letters can be combined with the tone marks. So, going from the base Latin alphabet, in Vietnamese letters can have zero, one or two diacritics. That makes for a lot of potential combinations!

Input Methods

There are multiple input methods that can be used to type Vietnamese on an (English) keyboard. We'll talk about Telex here, which is the most common input one, and Vni, which is the default input method for Vietnamese on Ubuntu.

Vni

This one is pretty straight-forward. With Vni, the number- and the square bracket keys are repurposed to either write one of the new letters, or add a tone mark to the last letter. There are some variants of the exact mapping out there, but Ubuntu uses the following:

For example, to write dế, type d38. The 3 produces ê and the 8 adds the acute diacritic.

To write người type ng[]5i. The [ produces ư, the ] produces ơ and the 5 adds the grave diacritic to the ơ.

Installation

This comes pre-installed on Ubuntu (20.04 LTS). To enable it, go to Settings > Region & Language > Input Sources and add Vietnamese. Switch between input methods with super+space.

Telex

The more common input method is Telex, where some letter keys can be pressed twice to produce the alternate version of that letter, and other letter keys are repurposed for adding diacritical marks. The latter works because the Vietnamese alphabet doesn't use some letters like J and W, and some letters like X can not appear at the end of a word. This is a really smart system!

The exact specs can be found elsewhere, but here are some examples. To write dế, type dees. The double e produces ê and the s adds the acute diacritic. Every word in Vietnamese can only have zero or one tone marks, so the tone mark placement does not really matter, and the rules are somewhat complicated. Luckily, Telex handles this for us.

To write người (person), type nguowif. The w transforms uo into ươ, and the f adds the grave diacritic. It is also possible to type nguwowif, transforming the two vowels individually, but Telex allows the shorter uow combination because Vietnamese never uses ưo or uơ.

This may seem cryptic at first, but is actually really easy to pick up. If you deal with Vietnamese text occasionally, install Telex and give it a try! You don't have to be fast with it for it to be useful to you.

Installation

To install Telex on Ubuntu (20.04 LTS) run these commands:

apt install -y ibus-unikey 
ibus restart

And then go to Settings > Region & Language > Input Sources and add Vietnamese (Unikey). Switch between input methods with super+space.

Mistakes Where Made

When we investigated the bug reports from the user feedback, we found that we had made three specific mistakes when we were coding our forms with English input in mind:

Mistake #1: Removing Diacritical Marks

Given that diacritical marks are important for the meaning of a word, it becomes obvious that removing them is not ideal. But this is what we were doing initially: To ensure that when searching for cafe and café, the same suggestions would be returned, we just removed the diacritics from the search input and the database entries before comparing them.

This approach is flawed in two ways: First of all, it makes the search less accurate. The user is no longer able to type in precisely whether they are looking for con dế or con dê, since both options will be returned.

Also, while writing an algorithm for turning café into cafe is relatively easy, doing the same for all possible combinations of diacritical marks in Vietnamese is not. This problem is exacerbated by the fact that when it comes to diacritics, there are multiple ways to write the same thing.

Mistake #2: Not All Diacritics are Equal

Unicode and character encodings are a topic in and of themselves, but let's take a look at what is actually written to your computer's memory when you type:

Assuming that we're using the utf-8 encoding, writing the Latin character a to a file, actually writes the byte value of 0x61 to the memory. For an uppercase A it's 0x41.

So lets see what this looks like when we try to type ậ with the Telex input system:

Typing a still gives us 0x61, but â is 0xC3 A2, ạ is 0xE1 BA A1 and finally ậ is 0xE1 BA AD.

However, when we try the same with the Vni input method, we see a difference:

Here, typing a gives us 0x61, but â is 0xC3 A2, ạ is 0x61 CC A3 and finally ậ is 0xC3 A2 CC A3.

The difference becomes clearer when we look at the byte values next to each other:

While Telex produces single characters for ạ and ậ, Vni actually produces the a and â character plus a modifier (0xA3)! This explains why some searches come up empty: If the entries being searched in have been written with Vni, but the user writes their query with Telex, the computer compares the byte values and only sees different strings.

Mistake #3: Bad Database

This one concerns the city of Dalat, or Đà Lạt as it is written in Vietnamese. For some reason, no matter with which input method the users searched for it, with our without diacritics, they couldn't find it. It was there in our database, but for some reason Sequelize just wouldn't return it.

Ultimately we found that for some reason, the entry for Đà Lạt in our database used neither Đ (D with Stroke) nor any combining mark. It was written using Ð (Latin Capital Letter Eth), which looks exactly the same, but as far as a computer is concerned, is a completely different letter.

Solutions

The fix for Mistake #3 is obvious: Fix the city names in our database by replacing all Eth chars with D with Stroke chars. However, from Mistake #1 we know that we can't fix Mistake #2 by removing the diacritics.

To fix this, we should use string normalization: This is an algorithm that is built into most modern languages. It transforms all those different byte values into one canonical version, which can then be used for comparisons.

You can find the reference for JavaScript's normalization method here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize

Further Reading

• A good article about the input methods: https://yourvietnamese.com/learn-vietnamese/type-vietnamese/
• The Telex Rules on Wikipedia: https://en.wikipedia.org/wiki/Telex_(input_method)#Rules
• A beautiful web book about the challenges of typesetting Vietnamese: https://vietnamesetypography.com/

There are two lessons that I learned the hard way when building Glints engineering team in this area.

My philosophy when it comes to building up engineering teams in Southeast Asia can be summed up in two words: intentionality and pragmatism. Five years ago when I first began scaling up the engineering team in this region, I had only the vaguest ideas of the frequently irreversible decisions that lay ahead of me.

Some of the painful results from these misguided decisions include my Indonesia engineering team quitting one after the other due to disengagement, simmering tensions and frustrations due to inter-country teams’ language barriers and persistent underperformance in remote teams left to fester over quarters.

I had some abstract ideals about the perfect team I wanted to build. But at the end of the day, I am at a company with a budget, hiring against a tight timeline in a constrained talent market with a thin history.

There are realities to contend with, many of which are unique to the fragmented and multi-cultural context that is Southeast Asia. If I could hop on a Zoom call with that eager hiring manager from five years ago, here’s where I would focus his precious and soon-to-be-frayed attention.

Reid Hoffman famously quipped that building a startup is akin to assembling an airplane in mid-flight. While flying by the seat of your pants is frequently the optimal strategy for finding product-market fit, designing and building a high-performing engineering organisation takes a great deal more intentionality.

Here are a couple of things I learned in building an engineering team in Southeast Asia.

Work out the nature and scope of engineering

Critically, the time to scale the team is after you have found product-market fit, which is also the time to plan out a longer-term product roadmap. Armed with this product roadmap, walk up the dependency graph to chart out the corresponding engineering roadmap, from which you can work backwards to figure out the engineering bandwidth and skill set required. This is necessarily a blunt operation, but the broad strokes alone will give you much-needed clarity downstream in the hiring.

A word of advice here is to be clear-eyed about the actual engineering bandwidth and skill set needed. While many startups pride themselves on proprietary, cutting-edge technology, don’t underestimate the long shadow of relatively ho-hum infrastructural and product engineering that trails behind these core asset developments. Plan for the manpower accordingly.

Split teams by communication lines

If you plan to scale the team past eight people, you will almost certainly need to split them up into sub-teams. The best way to do this is to group members with the most frequent and complex communications into the same teams. Frequently, you will find the most natural seams between teams to be product scopes.

At this point, you also have to decide if you are going for a fully remote or a multiple-hub hiring strategy. Both have its pros and cons, the important thing is you decide, and provision supporting processes and tools. If it is a hub strategy, then ideally each team is colocated for more spontaneous and high-bandwidth communications. If it is remote, then think through language requirements and market context.

Map out the regional talent market

Though relatively young as a whole, the Southeast Asia engineering talent market differs in skillset concentration, culture and size. It is crucial that you get a sense of both the top-down view and anecdotal, on-the-ground reviews of the different talent market.

When I was sussing out both the Vietnam and Indonesia engineering pool, it was incredibly eye-opening to speak to other engineering leaders who have built substantial teams over a multi-year period over there.

It gave me a pulse of the difficulty of hiring for different skill sets, and what candidates respond to. Quantitatively, I would also research on LinkedIn where the bigger companies are building their engineering hubs, including the tech stack, functional roles and seniority levels of each hub. The output of this research and the organisational design is that I can map out the most suitable region to build out each team.

Start by hiring the leader

If you realise that you can hire a full engineering team in just 1 country, you are in luck. In fact, there will be so much less complex that you should try to optimise for this arrangement if possible.

Practically, due to talent scarcity, required market context or simply cost, most engineering leaders will have to hire across at least 2 markets.

If that is your case, learn from the two painful lessons that I picked up the hard way. First, always hire from the top down, which means starting with the engineering leader.

There is frequently a huge pressure to hire individual contributors who can immediately add to product development bandwidth. Resist that temptation. I made that mistake by hiring a small team of engineers in Indonesia without a manager. In between managing the Singapore team and hiring in Indonesia, I was stretched too thin to properly manage that Indonesia team, which is crucial in the early stages of team formation.

Almost immediately, problems cropped up. The team was frequently unsure of the full product context, resulting in delays. They were also apprehensive about how to adapt to the backdrop of Singaporean workplace culture in the bigger team.

Eventually, they became increasingly disconnected from the company they were so excited to join in the first place, disillusioned that they were unable to make many meaningful contributions.

Investing the necessary time to hire the right engineering leader would have gone a long way to avoiding that outcome. Not only would they share the immense workload of bootstrapping a team, they would also help you solidify the desired cultural foundation through further hiring and personal influence.

Secondly, when building out a new engineering hub, that should be your sole focus, which almost always means you would need to be stationed there physically (after the pandemic, of course). It is already a tough sell for a candidate to join a company they have never heard of, much less a foreign one where they hadn’t even shaken your hands in person. Make that sell easier by sharing your plans for the team while looking them in the eye.

Much as Zoom and Google Meet are great products, nothing beats face-to-face rapport when it comes to trust-building. The same goes for onboarding the first few hires. Spending a prolonged amount of time in person with your critical first hires will set the cultural tone for a long time to come.

Eventually, of course, once you are confident of the hiring bar and management capabilities of your first engineering lead, you can increasingly peel yourself off for other priorities.

Even with the best-laid plans and the benefit of hindsight, building up an engineering team, especially as a startup in Southeast Asia, will never be easy. There are times when it feels like a grind and other times when it seems like there are no good options. At the end of the day, what you need is a clear-eyed appreciation of the realities on the ground, and the very real trade-offs you have to make.

My only hope is that you make these trade-offs consciously, and not bumble through them as I did five years ago.

Cross posted from https://e27.co/how-to-build-an-engineering-team-and-other-hiring-tips-from-glints-cto-20210504/

Have you recently found yourself in conversations on Slack that feel days to resolve when similar conversations would be resolved relatively quickly in person. If yes, this article will help you make your asynchronous conversations more efficient.

[Monday 4:00 pm] Michael, a backend engineer with very little knowledge of the frontend codebase gets stuck while trying to solve a frontend bug. In a normal working situation, Michael would go to John's desk, the frontend engineer in the team and clarify the doubt in person. But since the whole team has been working remote since the pandemic, he drops a message to John on Slack. He attaches a code block in the message and asks Hi John, can you guide how can I make this code work successfully?.

[Tuesday 09:00 am] John starts his morning routine of going through the previous day's slack mentions and notices the above message from Michael. Although John is the most experienced frontend engineer on the team, John has no clue how to respond to the question since he does not know what problem is Michael trying to solve. John drops a message to Michael asking for a link to the bug that John is trying to solve.

[Tuesday 03:00 pm] Michael is going through his slack notifs after lunch and notices John has asked for the bug link, so Michael messages that link to John.

[Wednesday 09:00 am] John notices the bug link from Michael in his mentions, he goes through the bug and thinks of an alternative solution to the one that Michael gave and drops a message to Michael with that solution.

[Wednesday 10:00 am] Michael has been more frequent to check his slack in anticipation of John's reply. He notices the alternative solution proposed by John, but turns out he has already tried that solution and it does not quite solve the problem due to a weird edge case. He gets back to John with the details of his previous attempt.

This back and forth keeps on going on till Friday when John finally realizes on how the bug can be solved from Michael's information. The conversation around the bug took them 4 days to resolve. If both of the engineers were working in person, would this conversation have taken them 4 days to solve with the questions asked same way line to line? The answer would be no, since all of John's question about the problem would have been answered immediately instead of waiting for hours. The conversation would have taken at most an hour to resolve instead of 4 days.

What's the problem here, is Michael just bad at asking questions? But that can't be, Michael has been asking questions the same way as he did before. The example here is a bit of an hyperbole on how expensive asynchronous communication can be sometimes if we follow the same rules as real time communication. Following are points to keep in mind when trying to ask questions asynchronously:

• Give the full Context. (Clearly state what you're trying to do)Instead of just trying to ask what's wrong with the code, Michael could have started his message with Hey, I was trying to solve [bug_link_here], where the popup doesn't appear on condition x . This message would give John more context on what's the problem in the first place. Additional thing to keep in mind when trying to give John context is to assume that John is completely clueless on the ideal behaviour of that part of the codebase, since John is not an all knowing deity.
• Outline your previous attempts to solve the problem.Michael had tried 2-3 solutions that didn't work before going to John for help. It would help John narrow down the problem if he was aware of those attempts and what Michael had already tried.
• Describe what's the problem that you're facing in your attempt.Just describing your attempts isn't enough, please describe what you've tried before.

Aside from the points described above, please be specific in what you are trying to point i.e. use this, that and it as less as possible. E.g. if you're referencing a column, explicitly name that column, don't assume the person on the other side knows what you're talking about. If you're referencing a commit, give a hash of that commit or even better, drop a link to a specific line of code at a specific revision on GitLab/GitHub.

Although these points might help you frame your better questions, the best way to get better at asking questions would be to ask a co-worker of yours to help you create a feedback loop. You agree that whenever you ask that co-worker any question, that co-worker would point out the flaws in your questions immediately and help you give feedback then and there on how you could you have better framed the question to help your co-worker understand the problem in the first go.

Cross posted from https://shubhamp.in/an-engineers-guide-to-asking-better-questions-on-slack/

Founded in 2013 in Singapore, Glints has empowered more than 1.5 million professionals and 30,000 organizations to realize their human potential. Last month, Glints announced the close of US$22.5 Million in an oversubscribed round led by Tokyo-listed PERSOL Holdings, marking the largest investment round into a career platform in Southeast Asia.

We're stoked to introduce our tech blog to share our learnings over the past years and the engineering challenges a fast-growing startup of our maturity faces. This blog will cover all things tech, from the nitty gritty tech challenges we face to the organisation wide challenges faced by us.

In the process of sharing our learnings and challenges, we hope to help people and organisations facing similar problems, get feedback from people who've been there done that and to give future engineers a peek of our engineering culture.

To know more about Glints, head on to https://glints.com/sg/about (We're hiring!).

Hope you have a fun time reading through our learnings and challenges :)