How to be the best software team lead

Software team leads have a difficult job. On one side they are expected to be the top developer in the team, cracking every technical challenge that comes their way with the snap of a finger yet on the other side they are expected to be the “manager” of the technical team. Now this “manager” bit is the one that is always fuzzy - it ends up meaning a lot of different things to different people and the team lead also ends up trying to fill all those roles that is expected of her. Being a manager will definitely mean she has to coordinate the activity of the software developers in her team - for example assign, distribute and redistribute tasks, help out team members with tasks, resolve conflicts, resolve technical challenges, prioritize activities and tasks. But being a manager also may require her to interface with customers, other teams within the company, attend meetings with the management teams, fill out spreadsheets for accounting … the list is really endless. With all such disparate responsibilities the question becomes what do you do to become good at becoming a software team lead. Here are my top tips from years of managing software teams and progressing through the career from a software developer.

1. Always plan first

   Obvious, isn’t it? But you’d be surprised how often the software team lead is under so much pressure that she just jumps in and tries to “winging it”. This strategy may work once in a while but it’s a recipe for disaster. ALWAYS plan, even if you feel there is no time for planning - force yourself to do it. This is a habit thing rather than a natural thing. By forcing yourself to plan things out you are ensuring that you give yourself a chance to think through things and prepare for overruns, disasters and failure. I’ve this as the first one in the list because I feel that if you don’t take anything from this list you should at least take this one. This single habit can change how good you are as a team lead. You’ll come out to be confident, your leadership will be valued and you yourself will be less stressed.

2. Mentor and delegate

   Notice how I just don’t say delegate? Delegating is really the core skill of a team lead. It is what makes her successful. But just by delegating tasks that she cannot do to others she is actually harming the project. She has to ensure that people she is delegating to has the ability to do those tasks. And for that to happen she has to mentor her team. The best software team leads are great teachers - team members come to them to learn. They start getting a reputation for turning out great professionals and developers want to join their teams. The best team leads know that without investing in her team members’s skills all her delegated tasks will fail and the everything will eventually roll up to her, increasing her tasks at the end. So mentor your team, teach them what you know and then start delegating task with the assurance that they have the ability to do those tasks. A recent HBR post does a good job at explaining this well: How to stop delegating and start teaching.

3. Communicate clearly

   Communicating clearly the exact things that need to be done is extremely important. This is where the best team leads shine. The team lead has to interpret, break down and decide what needs to be done. It is the team lead’s job to then clearly communicate those task to her team. If done well, the amount of to and fro in understanding and clarifying the tasks reduces to almost zero saving time and increasing efficiency of the team. So setup good process for communications, use tools that help and setup standards. For example, an issue management tool like Jira can make a huge difference to a team performance if used properly. Putting up stories, breaking them down to features, tasks and grouping them to milestones is investment that will more than pay itself down the line in saved time in communications and mistake free implementation.

4. Avoid micro-management

   Good team leads learn to trust their team. Trusting team members means you don’t have to micro manage. Micro management is one the biggest mistake that a team lead can make. It wastes everyone’s time and destroys morale and confidence. Team members start feeling undervalued, and worst of all they start feeling less responsible as expressions like “the boss will change this anyway” or “the lead will help me finish this code” start floating around. Your team will become more dependent on you as you micro manage and you’ll find that over time you spending more and more time doing micro management rather than useful work. Avoid at all costs.

5. Stay on top of technology

   Big one for technology leads. Software teams have an inbuilt hierarchy - a pecking order - based on technical ability. Respect within the team is handed out based on this pecking order. As a team lead you need to be on top of that pecking order and the only real way of doing that is to keep up with the technology. It’s hard, given all the pressure of managing teams and managing customers but if you don’t keep up you’ll eventually lose the respect of the team. Even just reading a few articles and discussing with the team about what they are using can help in this regard. Another tried and tested way is go setup a tech seminar system within the team where team members share their knowledge - it helps you learn things quickly and also helps the team improve their skills.

6. Take some dev tasks

   This may sound counter intuitive for large dev teams. Team leads in larger teams tend not to take any dev tasks themselves simply because they just don’t have enough time. Yet taking on some task, even very small ones are of immense value for team lead. On the surface level it shows that the team lead is “one of us” to the developers, but more importantly it gives the team lead an idea about what’s going on at low level which she may miss out completely if all she does is high level architecture or team management.

7. Learn to say “NO”

   Last but not least - learn to say no. At the end there will always be too many tasks being thrown towards a team lead. A good team lead has to prioritize tasks and figure out what tasks can be done at a later stage or not at all. Coming out and saying no is an essential skill that enables a team lead to manage this process. Say no to task that has no immediate value to the project in hand, say no to non essential tasks the management sometimes send your way a classic example is the performance review in the middle of a dev cycle. Avoiding non essential tasks will lead to a better project, better delivery and at the end a better result for the company.

   Oh this one was way longer than I planned (see always plan first :) ), OK here’s a Dilbert strip that works great with the theme. Happy team leading everyone!

Code your own robot

“There is a part of a humanity that loves to worry about robots taking over or being weaponized or something like that. We definitely want to counter that narrative. We’re not interested in weaponized robots. ”

— Marc Raibert , ex-CEO BostonDynamics

You may not have to wait that long to start programming those amazing robots you saw from Boston Dynamics! One of their top models, SPOT is now available for sale (there’s even a contact sales button the page :)) with its open source SDK

So those scifi movies that we’ve been consuming all our lives are starting to be not so scifi anymore! We’ve not played with the SDK yet, but would love to if we can ever get our hands on one those dog-robots, but here’s a quick summary of what we know from our reading up. Could be wrong on some and definitely things are moving fast here so keep an eye on their site for news if you are as excited about this as us (and you should be).

The SDK

The SDK is in Python!

The SDK let’s developers and hobbyists to interface with the robot and develop custom applications that lets Spot to do tasks. Developers who doesn’t have the actual robots can still be able to view the SDK and existing early adopters can open source their applications that can then be built upon by the community. With the SDK, developers can create custom API for controlling the robot, io on sensor information and feed into into data analysis tools/AI, and design custom payloads to expand the capabilities.

Googling around gives one example of a company already using the SDK to do something - HoloBuilder is using the SDK to integrate Spot into their existing app - that lets workers use a phone to teach Spot a path around a construction site and then Spot will navigate that path and take 360 images.

Robots can be rented!

Great, we have the SDK, but how do we get the robot? The good news is that if you manage to become a member of their Early Adopter program (there must be a million contenders for it already :( ) then you could actually get “leased” robot from them. Here’s them saying it in their own word: “Developers will still need to become part of the Early Adopter Program to lease the robot to execute their code…”.

SPOT is loaded

Spot comes with a lot of features - VR control, automated registration of laser-scanning, connecting Spot’s data to cloud work order services, using Edge computing to help Spot semantically understand its environment, and much more.

The first user conference

In addition to open-sourcing announcing their SDK release BostonDynamics also said they are arranging the first-ever user conference for their platform, Actuate 2020. Set to take place May 12-13 in Boston, Massachusetts. Sadly it will be invite only. But that’s expected. But May is only a few months away.

Exciting times!

Talent is everything in software

I come across a lot of NDA (non disclosure agreements) in my work with startups with the next big ideas. And NDAs are good since it give both sides a sense of confidence in sharing information. But at it’s core I sometimes find a feeling that it is the idea that’s super precious and a big secret. I think that’s a mistake.

Ideas, are easy - “a dime a dozen”.

It is the implementation of it that makes all the difference.

And it’s the talent that makes the implementation possible.

This might sound controversial. After all if Mark Zuckerberg gave out his idea of a social network that can connect friends and family (and random virtual “friends” who might or might not exist) wouldn’t someone else have built Facebook? Or if Elon Musk told everyone about his electric cars wouldn’t GM be building something called Gelsa today? Not really, you know this right? Friendster (with that golden metric - MAU - monthly active users in the range 3 million as early as 2003) , Myspace, Hi5(?) are just some other equally social and equally good at making strangers friends were already around when FB cam along.

Source: MySpace’s Rise and Fall – A Timeline of Highs and Lows

Actually as late as 2008 when FB was more than 4 years old already, Myspace was the top social networking platform, and consistently beat FB in traffic. Facebook did little harm to Myspace's popularity; at the time, Facebook was targeted only at college students. At its top, when News Corp attempted to merge it with Yahoo! in 2007, Myspace was valued at $12 billion! And if you look at the chart here that shows visitor counts for MySpace, as late as 2011 it was fighting out ( and losing) with respectable numbers.

Myspace is definitely a story of how not to do things. There is a lot to learn from it’s demise and there has been a lot written about it, I urge you to read some. But I digress from today’s topic.

As for stealing Musk’s idea, electric cars are obviously nothing new. There working models even in the early 1960s! For a great video about a quick recap about this space check out the video here.

Anyway, getting back to my point, there was nothing unique or even new about FB or Tesla. They just made it right, their implementation was better than others.

If you look around you would find this to be true for almost any idea you can think of or any successful software startup you see you’ll find that the idea had been around, maybe no one built it or others built it but they built it wrong. Just check out Kickstarter the amazing quality, uniqueness and breadth of some of the ideas are just mind blowing. But how many makes it big? And when they do why? You’ll always find that it’s because of their implementation.

And behind any good implementation is the team that build it. So using simple logic we have:

Talented team -> Great implementation -> Success

This may sound obvious, but you’d be surprise how many startups gets lost in thought that they have the best idea in the world and whatever team works on it, they will make it a big success. I would strongly argue the other way and say:

Hire the best team -> Think of an idea -> Success

OK that probably doesn’t work for a lot of startup owners since obviously its idea first for most founders. But if you believe in that formula of talent first you’ll probably morph into something like below:

Idea -> Hire the best team -> Morph the idea -> Success

That to me is the best formula for a founder thinking of making her ideas come to life. Oh, btw, I have the perfect Dilbert for today’s post…

Do not disturb a software developer in "flow"

“The trouble is, getting into “the zone” is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity.”

— Joel Spolsky

Source: THIS IS WHY YOU SHOULDN'T INTERRUPT A PROGRAMMER

The world is full of distraction, particularly in this point in time. Facebook keeps enticing us with yet another friend’s trip to the tropical paradise we always wanted to go, Twitter pings us about Mr. Trump’s newest normal and that infernal device in our pocket keeps buzzing and beeping. Yet as software developers we are most in need of concentration, we need to think, juggle hundreds of ideas and pointers in our head and let our brain do its magic. A single distraction during this process is like a shrill cry in the middle of the silence in a temple.

I saw an amazing cartoon sometime back that explains this in very funny terms, I’ve copied it over here and keep it as the entire right column for today’s little rant about why coders should not be disturbed yet they are at every possible moment during their typical work day.

Here are some of the things we remind ourselves every day to stop disturbing ourselves and our colleagues at work.

Don’t ask a random question

The random passing question to a code deep in work is the number 1 culprit for distraction and loss of flow. It’s tempting to ask how the party went last night for example but asking it while someone has just managed to understand a weird for loop written years ago is a major sin. Please don’t ask randomly without checking if that person is free or not.

Keep developer rooms silent

Noise and particularly the someone speaking on the phone is horrible for anyone trying to concentrate. Developer rooms should follow the silence rule that libraries have. Discussions, debates, phone calls should all be taken out of the dev rooms into the verandas or the meeting rooms.

Open offices are bad

Large open offices where many different teams are working at the same time (and the worst of all developers working with sales teams sitting close by) are bad for concentration. We feel strongly about having semi private offices where only a single small team sits together with their lead in a separate space or room in that area. We’ve written many times about workspace layouts that are good for software companies. Here’s a recent article: To cubicle, or not, that is the question.

Optimize meeting start times

Work meetings in the middle of workdays are a major source of distraction. It prevents developers from concentrating and working on a large piece of software in the fear that they will get distracted in the middle. And most meetings lead to a long time settle back to full concentration. Meetings should be timed at points when the developer has not yet started to pick up tasks (say beginning of the day) or has had a natural break in work (say right after lunch).

Self discipline goes a long way

Last but not least: funnily enough studies show that we ourselves are a major source of distraction. With all the social media and youtube just a click away this isn’t too hard to understand. This is where the self discipline comes in, prioritizing our work and keeping set timeline for launching FB or even checking our emails has a huge impact on our productivity.

5 UX rule every software founder should know about

I’ve found that in my chats with founders I keep coming to some common themes. And it doesn’t matter if the founder has been working on technology all his life or if he has no idea about software. One of those common themes is the discussion about how to make decisions about the actual user interface of the features that she has been dreaming up. For the technically minded founder it becomes a thing of do I use this pattern or that, or a strong bias of of some type (e.g. “less is more”, “pop ups are banned”, or something along those lines) and for the non technical founder it’s usually a more dangerous situation of absolute certainty about how the feature should be (usually with at least 20 buttons and a lot of color). The recurring theme follows a common script where we listen to the instructions, we try suggesting some changes and are met with strong opposition and sometimes dismay and we then suggest we draw this up (hoping that we might tweak things during that process). In most cases at some point we can convince the founder to have an open mind and make decisions about the user interface and interaction based on a rationale and sometimes also a debate. I used to point everyone to my favorite Alan Cooper’s About Face, it’s one of those books that equally valuable to the professionals as it’s to someone with a passing interest in UX. But now I find it easier to point to the amazing https://goodui.org/ as first step about thinking about patterns and rules of thumb in UI/UX (probably a sign that many of our new founders are from a generation that is more used to online content, quick reads and youtube).

Over the years, there are some UX wisdom that kind of made sense the moment we shared them with someone who didn’t know about them (or someone who knew but just haven’t thought about that for a while). These “instant hits” are really good to keep in mind when you are thinking about software interfaces but they are equally good to impress someone over a drink! So I thought it would be a good idea to do a quick and easy list of great UX wisdom today. Here’s my list of 5 of the easiest (and probably greatest too):

1. Fitt’s Law - larger and closer click-ability is better

Simple and logical rule of thumb which says you should always make the clickables (buttons, links, menus, etc.) large and close to where your mouse is currently. It’s so strong and has so much data to support it that it’s a “law” ! To implement Fitt’s law here are the two simple things you have to remember:

• Most used UI elements should be on the edges of the screen. Because the cursor automatically stops at the edges, they will be easier to click on.

• Make clickable areas as large as possible. Larger targets are easier to click on.

Fitt’s law is why tapping on those bigger commonly used buttons at the bottom of the iphone screen (where your thumb is) is so satisfying.

2. Hide your “ejector seat lever”

This one is from Alan Cooper. Again, very simple, you would never put the ejector seat lever button which ejects the pilot from a plane next to a common thing like light switch - just because accidents might happen. Same in software, don’t put major decision action elements (aka… buttons e.g.) next to and in similar level as other lesser ones. See how gmail keeps the trash option far away from the others and make the send button significantly different it’s neighbors? Great job.

Here’s the section from the man himself. If you haven’t got this book, buy it, if you have anything to do with software you should treat this as your religious text.

About Face: The Essentials of Interaction Design

By Alan Cooper, Robert Reimann, David Cronin, Christopher Noessel

3. Fewer is always better

GoodUI

Not sure if there is “pattern” with that exact wording, but there are many patterns and rules of thumb that can be distilled into this simple rule of thumb. The rule is just what it says, if you have an option between two sets of UI both of which gets the job done then the better one is the one with fewer elements, fewer actions, fewer buttons, fewer picture, fewer .. ok you get my point. You’ll find many versions of this rule, say if for a form GoodUI just has it as idea #13

This is why Google’s insanely simple home page for search was and is still the winner.

4. Progressive disclosure

Sounds fancy but all this is saying is that you should not show all your features to the user in one go and overwhelm him. Just delay displaying advanced or rarely used features, push them secondary screens, this will make your software easier to learn and keep your users engaged.

By hiding complex things, you are making the initial interfaces clutter free. You are also giving the user the time to learn your software, get small dopamine hits of success as they successfully use the software to get their job done. For some of the features there might be no other way but to get the user to do all the screens, but use this pattern to just split it up and show the screens in steps - keeping the user happy and engaged. The goal is to show only essential information. Then get the users to take the next step. When the user completes a step, reveal the information in that new step, keeping current state visible. By keeping previous steps, users can change what they have put in. Here’s a much more detailed version of this pattern.

5. A clear primary action for every interface

Every interface you build must have a single action that it wants the user to accomplish - the primary action. Focusing on splitting the interfaces up so that they don’t offer a multitude of actions each leading to a new path saves the user from confusion and the complex task of remember where they are within your software. The primary action button (or element) should focused, highlighted and obvious. All the wording, graphics of that interface should support that single primary action.

If the interface is for submitting generating an invoice, there should a big highlighted button called “Generate Invoice” for example. Well, life isn’t always that clear cut, but you’ll find that you can always find a solution that pays respect to this single (or at least clear) primary action. And this makes the interface so much easier to use. Something as complex as gmail’s logged in home screen, that probably has at least 100 clickable elements and action item can still offer that primary action feel. Almost the first thing you notice is that significantly different Compose button that’s inviting you to click it.

An easy way to inject energy in your team

A recent HBR article discussed how having a “Shadow Board” of younger employee empowers and energizes a company. I think this is a brilliant idea, the act of bringing younger staff into limelight and positions of power amplifies their voice and views, engages them in the companies initiatives and injects a huge amount of energy into the company’s every day actions. As the article shows in real life how this injection of energy makes a big difference, the fashion giant Gucci started a shadow board from 2015 composed mainly of Millennials. “The shadow board includes people drawn from different functions”, CEO Mario Bizzarri says “with the most talented people in the organization — many of them very young.” and their feedback has “served as a wakeup call for the executives”. Gucci’s sales have increased by 136% between 2014-2018 during the time this board had been active.

This idea of a shadow board and the idea of empowering the younger members of a team and giving them a role in injecting ideas and direction of the company may be new to large corporations but for many smaller software companies this is pretty much a tried and tested method of making the team dynamic. At Kaz we have been practicing this right from the start. Every new group of “freshers” (or “freshly hatched” as they are called by senior team members as a friendly jest) have had a chance to be part of some important decision making over the years. We have benefited a lot by this injection energy and idea. I want to share how we do this and hope this might give you some ideas to try out at your company.

Making a young “alt tech lead”

As with any software company, Kaz runs with small groups (ideally below 7) or teams developers led by a tech lead. What we encourage actively is for the younger (usually the youngest) members to become a kind of alternative tech lead. An open culture where their is no walls between individual team members obviously help with this. The “alt tech lead” then has a voice and feels like she can point out errors and come up with new ideas much better than the senior members of the team. This alternative voice is excellent in breaking down bias in software design that sometimes creeps in because of the past experience of senior members who tend to drive the same ideas and technology on every new project. Giving the younger members the role of this alt tech lead also encourages her to pick up skills and knowledge that she has to use to defend her ideas. A perfect win win situation, particularly in the fast moving software development world where everything changes in a matter of a few years and keeping up on new technology is a must for every team.

Giving younger members leadership on events

We usually make younger members of the company manager for various events that happen at Kaz. These events can range from tech workshops to multi day trip outside the country. This leadership helps younger members in meeting other staff outside their immediate team and also for developers this is very good opportunity to learn management and collaboration skills for working with non-tech members. This is essential for a software developer since at some time of their career they will have to interact more and more with the customer and other stakeholders of the software project.

Giving junior staff a forum to voice their ideas

This comes in many flavors. At its simplest it’s actually a software forum or group where everyone has a right to say what they feel. We call this the underground - almost like separate power center where the management doesn’t have full control. This is superb to hear new ideas, or more importantly criticisms and gripes about management policy, practices etc. This is an invaluable source of information and acts as pulse to check how things are going and what needs to change.

The ideas and energies of the younger staff members is an amazing source of dynamism for any company. Particularly in software companies the young comes with new ideas and skills about technology that the older staff members just don’t have. Not to harness this power is a big loss, yet I feel it is not utilized as much as it should be. Remember the lines “Eternal sunshine of the spotless mind!”

Multi-tasking is a crime (at least in software projects!)

Fact of life: More often than not a software team will have more work than they can juggle. What can a team lead do to get things done in the most efficient way?

Coming from a logical point of view she has the following algorithm:

1. Prioritize things and get the high priority things done first (of course! We have a no brainer here).

2. Given the prioritized list of task from #1 she can get her team members to

   a) do one feature at a time

   or

   b) ask them to multi-task as in work on several features at the same time, switching between them.

The real debate is:

Is multi-tasking better than single tasking?

Multi tasking has been hailed as great solution to modern life’s challenges. Books, articles and research papers have been written showing it’s benefits for efficiency and performance. A little googling will lead you to articles such as this one aimed a entrepreneurs: Why multitasking has become the need of the hour? As you go through these you realize that it may indeed be a good thing and may solve your every day challenge of get different features of a software made (because you need to show different stakeholders different parts) in parallel.

However, in the world of software development there is a strong indication that multi-tasking is harmful. Let me quickly define multi tasking in this context - it is the act of getting the same resource (or a group of resources say a small team) to work on one part of the software and then move to another part within short intervals (hours, days but maybe not weeks). The effect of this kind of multi tasking is context switching - getting the developer(s) to load up one set of code, logic and idea in her brain and then after a while asking her to forget that and load up a completely different set. There is absolutely no question about this, context switching is bad for a software team’s performance.

Source: The Multitasking myth

In the book Quality Software Management: Systems Thinking, Gerald Weinberg writes how context switching affects performance. He showed that just like computers, humans often incur overhead when context switching between multiple parts of code or between multiple projects. He came up with a rule of thumb to calculate the overhead and showed that you lose 20% of your time by just adding one extra new context due to the overhead. And By the time you add a third project, nearly half your time is wasted in task switching.

If you think about it its quite obvious. When you are managing a software team, task switches take a long time. That’s because coding is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at coder. A programmer coding at full speed has in her head a huge amount of random yet useful bits of information that range from variable names, database tables where the variable will go, APIs that she will need to call next, the names of functions the team wrote in the library, the URL of the git directory, a stackoverflow article she read that uses a trick to solve the problem, the list goes on and on. The moment that programmer moves to a different task or worse a different project everything is lost and a complete new set has to take over - incurring that wasted time in the scheme of things.

So multi tasking makes a software team slow rather than fast. Your deliveries come later than sooner. So just like we can say with absolute certainty that cubicles are bad in a software company, we can say without a shadow of doubt that multi tasking is a crime in a software project. Here’s a good Dilbert for today…

Web development in Bangladesh

The software industry in Bangladesh is making huge leaps in recent years. BASIS the lead association for software companies Bangladesh showed that the export earnings was over $600 million in 2017-18 and was approaching $1 billion in financial year of 2018-19 with a CAGR of 39.54 percent. It is expected to grow to $4.6- 4.8 billion by 2025. A significant portion of this export industry is in custom software development in for online services. Apart from the export market the domestic market for web application and thereby web development has been accelerating very fast. This is evident in the growing number of online services that are now coming to the market such as e-commerce sites, social networking sites and forums, business services etc. The corporate sector has also focused mainly on intranet based web solutions served by internal web servers or firewalled clouds. Overall this huge push towards web application has obviously led to a large pool of web developers and designers making Bangladesh an ideal destination for custom web development.

Strength of numbers

Source: Where Are Online Workers Located? The International Division Of Digital Gig Work

In a research piece done by Oxford Internet Institute Bangladesh came out only second to India in availability and scale of freelancers for software development (and also for cumulative skills). And majority of this large skill set is for web development work.

We could not find a similar study on the skills distribution on the current professional software developers in Bangladesh but even from informal discussions, marketing materials of BASIS members it can easily be assumed to be the main skill set they are offering. So it can safely be suggested that the cumulative total for freelancers and professionals for web development skills sets Bangladesh easily as one of the top 3 nations for web development outsourcing.

Breadth of skills

With a substantial pool of resources working on online solutions in thousands of local and international projects the breadth of skills is really large in Bangladesh. We experience this regularly when we search for resources for our projects, almost any web technology weather it is a very exotic Javascript library or brand new unheard of cloud technology there is always resources available. There are two major reasons for this, the first is the substantial freelancing projects that prepare students and junior resources for web technology from projects outsourced to them from all over the world. This exposes resources to new technologies and with a very low barrier to entry into freelancing projects (e.g. with sites like upwork.com or freelancer.com) students and graduates of CS programs around the country find access to such experience easy. This leads to tremendous growth in skills with a wide variety of web development skills.

The other reason for the breadth of skills is the current trend in higher education institutions in Bangladesh to include programs that are job ready (read: web development ready). Whereas most CS departments around the world would treat a course on web development or web design not crucial to it’s program, most CS programs in Bangladesh includes these topics. This is mainly for the “job readiness” need for the programs that students and the parents push for. In a recent study by ADB about the higher education programs for IT in Bangladesh found this correlation with industry.

This double power of numbers matched with breadth of skills makes Bangladesh a powerhouse for web software development projects. Kaz has been in the forefront of this move, with our first project in 2004 on ASP.NET (relatively new technology those days) we have worked on more than a hundred web applications in technologies as diverse as .NET, Python, Node.js, Java, PHP and even Perl. Web is one of our big focus area for skills development. We have also been some of the first companies to work on Azure or AWS working on early adopter projects for our customers. We are happy to keep this tradition of leading the industry in Bangladesh in this exciting area.