Building & Managing Technology Teams in Asia: Setup & Configuration of a Startup Team

How do we set up an engineering or technology team within a startup? What are the pieces that deemed essential or not? Upon hiring your first engineers, what are the best practices for the startup phase before you move into the intermediate setup?

After working, building and managing different engineering teams from startups to corporations, I have gradually come to work out what I deemed as the minimum viable setup, learned a set of best practices on how to scale an engineering team as the company grows. In a nascent environment, the best approach is to adopt the agile software development model in a startup environment, where the engineering team can build a set of features and iterate upon feedback and data from users. However, as the engineering team grows, the priorities of the organisation changes with the complexities of building not just for your customers but also your colleagues in your company.

There is a philosophy which has increasingly become appealing to me in building your engineering team: build something which people within your company love/want/need to use. It sounds simple but it is actually difficult to execute. What’s more interesting is that it aligns the business owners and the engineers in a collective mode of thought and execution. For business owners, it actually demonstrates you whether the word of mouth marketing model will work. Think about it, if people within the company does not want to champion their own products, how are they going to convince other people to champion them? If you are not convinced, try asking your engineers why they just loved Dropbox, Evernote and GitHub and advocate that you should use it.

Why is this important? In a nascent environment, you do not have the luxury of a quality assurance engineer who can devise tests to search for bugs and issues or “dogfooding” the company’s product. So, the early software engineers have to find ways to make testing not part of the hassle but in an automated fashion. In a startup, the test driven development (TDD) [1] is a process that is more crucial for both front-end and back-end engineers.

Setup & Configuration of a Technology/Engineering Team

When you start an engineering team, you need to set it up in a way that are suited to the needs of the organisation. Don’t be dogmatic about it because software development comes in all shapes and sizes. For example, the needs of a business to business (B2B) and a business to consumer (B2C) are very different. If that does not sound so bad, how about adding the complexity of a hardware (car, watch or Google glass) in the process or dealing with mobile operating systems (iOS, Android, Windows Phone 7)?

How should be the initial setup really look like? While I will dedicate a separate post totally on how and what to look out for in hiring engineers, here are some heuristics to how I think about the initial setup which I learn through my years of experience:

Hire two engineers at a time & not one: If the CTO is taking one of the software engineer roles, then you just need to hire another one. There are times where the CTO is being made to do the product management & growth hacking (as in my case for one of my past startups), then hire two. Yes, hiring two engineers accelerates the burn rate. The best reason I can offer is that the two engineers serve very different functions and if you don’t split it up at the start, the technical debt on your product grows quickly at the business expense. The other reason is culture and unless the software engineer or developer is a real lone ranger, having a pair can actually allow them to bounce ideas off each other and gradually they can also learn and grow together. For later stages, when you grow your team, you can also introduce pair programming which are the cornerstones of some top programming houses who practice agile methodologies. A disclosure on my end: I have not implemented pair programming to my teams and I often get mix reviews from my peers (fellow CTOs or Vice Presidents in Engineering) in the industry and it’s either really great or really bad.
The first 2 engineers should be a front-end and back-end engineer: If the CTO is taking one of the roles, then you need to find the other one. Most software development adopts the model-view-controller model. In layman terms to the business owners, this means that the product is built in a set of modules which clearly splits the business logic, the infrastructure and the presentation layer (where the marketing team make content changes without too much hassle). Having a specialised backend engineer means that he can focus on putting the right infrastructure layer in place which can be scaled up or down as the company grows. The backend engineer can focus on optimising the performance and build the components that the front end engineer will adapt and push it into the presentation layer i.e. the customer view of the product. The front end engineer is typically the person who puts the presentation layer that the customers faces and brings the designs from the UI/UX guy to reality. At the start of the company, both engineers are equally vital. If the CTO starts off as one of the roles, the key is to gradually find the replacement for his software development capabilities, transition the guy to be the head of engineering and subsequently to a chief technology officer of a corporation as the company grows.
Try to hire an user interface(UI)/user experience(UX) designer within your team: Having a designer right beside you is the best thing you can ever have within your engineering team. In the early stages, he helps to take your wireframes and produce the mockups on the look and feel. In US, the roles of the UI and UX are separate particularly in successful companies. However, given the dearth of talent in Asia, I often look for UI designers who has a passion to learn about UX and think about the flow of their designs and guide them by giving them interesting references and sending them on training courses (if the opportunity arises). For the UI designer moving towards UX, it’s a way to build their career and portfolio at the same time. Hence, it’s a hack which I have changed in the context for Asia.

The same would work for mobile development, except that you have to bear in mind the same principle of a front-end and backend engineer works as well. The complexity lies in the amount of devices that you need for testing and also making sure that you can provide engineering support if you expand to a second platform. One philosophy I have seen that it has consistently work for mobile developers is the following: always start from one platform (iOS or Android), work out the kinks and issues with the engineers who specialise in one platform before you extend into the rest of the platforms (Windows Phone, Blackberry).

As I have worked in both mobile and web, I have built my framework in thinking about the whole platform as mobile-web such that I see them as one piece rather than separate. To me, the desktop is another screen size and my web or mobile product must be responsive by default. If we are working on native applications, for example, within the iOS or Android framework, our focus is to make sure that we leverage on their software development kits (SDKs) and at the same time, optimise their performance.

In any case, my ideal first configuration is usually a team of four with three software engineers (including the CTO) and one UI/UX designer.

Best practices to build an Engineering Culture

Align them with the company’s business objectives: Through experience, it is often good to keep the engineering team in loop with the business objectives of the company. First, it aligns them with the rest of the company and also help to provide a sense of urgency and mission. Dogfooding the product is an essential characteristic of a good engineering team. The reason is that they are just not building but also using and improving the product.
Understand their work habits and maximise their input and output: It is silly to constrain the engineers to normal working hours. What really matters is that you emphasise on delivery and punctuality when it comes to important meetings. By giving them that flexibility, you give them the ease to focus on what they need to do. How about working from home? I do not start giving that privilege until I am absolute confident that they can deliver what they promise. In an early stage where you are building up team dynamics, it’s best to have the team together and slowly ease them if they prefer to work in remote.
Have very few meetings as much as possible and be part of their water cooler conversations: Unless necessary, it’s best not to have too much meetings. Often, an hour meeting on product discussions with the business owner, sales or marketing teams are good enough. Most engineering teams have a water cooler area, for example, a skype chat window which is shared among the team for internal discussions and chats. It’s important to let them vent out steam in the water cooler and be ready to help when they need it. Besides, a lot of interesting technology conversations often happened when the engineers go for a beer, and that’s how you can foster interesting synergies within the team.
Allow experimentation and let them articulate their expertise: Let your team experiment with new technologies and allow them to dedicate some time towards that. First, it improves their craft and sometimes, through serendipity, they might discover a way to apply the technology towards making the product better. Sometimes, to ensure that I get a complete picture of the technologies, I will check in with them on what technologies they would adopt for a specific problem, for example, optimising number of API calls, increase the speed of content delivery or securing an architecture against specific types of hacker attacks. In some cases, organise talks from other reputable software engineers within the ecosystem or get them to attend developers conferences where they can learn from fellow developers in the same space.
Give engineers time to refactor the code & optimise performance: Oftentimes, business owners under-estimate the issue of technical debt and prefer to use the engineer’s time to build more features. I have seen many Asian business owners (and some are even trained in top MBA schools) doing that. What they totally under-estimated, is the amount of technical debt that they are putting on the product. It’s important to give a sprint or a month to allow the engineers to refactor the code and optimise the performance in the product. If you want a good example, the case study of LinkedIn came to mind where Kevin Scott, the top engineer did a code freeze for two months so that they can refactor and optimise the infrastructure for the future.
Rest and recovery for engineering teams are crucial: Whether it’s a startup or an unit within a corporation, it’s important to manage the business owner’s expectations. As engineers are valuable resources, it is important not to overwhelm them or burden them with roles that are not in engineering unless necessary. The problem why it happens is that the business owners see engineering teams as costs that they cannot recover. If you are working with business owners who has the wrong set of expectations, you can prepare yourself for a lot of hell. As a manager of engineering teams, I have made it a point to avoid calling anyone on public holidays unless the server crashes (which only happens one in a blue moon) or a critical event. Here’s a story I can share with you: one engineer of mine has never experienced a proper Christmas and New Year holiday for years before he joined Chalkboard and I made it a point that he will not get a call from me during those two days. I told him that unless the server breaks down, he’s supposed to enjoy his holiday. Letting your engineers to go on a rest and recovery period is important so that they are more refreshed to deal with heavy lifting work.
For teams adopting Agile Methodology – Spend less time on stand up meetings but more time offline within engineers: Be strict about the standup meetings everyday and constrain it to fifteen minutes. It’s important that if there are blockers, the engineers can take it offline.
For teams adopting Agile Methodology – Gathering qualitative & quantitative feedback on the team after each release cycle: It’s essential to do a review meeting after each sprint and let the engineers provide feedback to what went wrong in the last sprint. For the manager, it will be good to gather metrics like burn-down charts and velocity graphs to look at how the whole team has performed as a whole.

What is important for business owners who are planning to build their engineering teams with the chief technology officer (CTO) is that they need to think about their career path. A lot of Asian business owners tend to treat them as workers rather than craftsman. Without the first step to rectify this cultural attitude, you will lose members of your team every now and then.

Notes:

[1] Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.