How many times have you looked at a job profile, or been in an interview and heard things like we want you to hit the ground running with no oversight, or we want people who are flexible with their skills, or we want to hire cross functional talent? When I read, or hear such things it does not inspire confidence in me about the management.

I will not lie, I was one of those leaders at a point in time, because I accepted them as a norm. And then I learned that I was wrong, and that I had to put in the effort to plan, learn to think strategically, if I wanted to build a team that grows.

Here is what most organizations/teams/managers need to understand about hiring the right people and how to build a team for growth.

Cross functional teams are a myth

Any skill is hard to develop, and it takes years to master something. You cannot just hire someone for one skill, ask them to do something they have no experience of and then expect them to deliver quality work in that area. More so, if you as a leader cannot help them get better in the new skill. Have you ever heard of a hospital hiring a dentist, and then telling him/her to also do a kidney transplant. That is the because the dentist does not have the right skills, and most probably they will screw up.

This thing about cross functional teams, is a myth created to make leaders feel comfortable by making short term tactical decisions without worrying about long term impacts. Does a hospital ever say, we run a dental clinic, but we have cross functional doctors, so we can go and promise a client that we can also do kidney transplant. One of our cross functional dentists, can just learn it over night and do it. Yeah, thats not how it works !!!

Hire only when you have role, and long term plan for the role

There are enough quality consultancy companies to help you out with any of your short term needs. Yes, it might cost you more than hiring a person in short term, but hiring a person who does not fit your long term plan, is a higher cost than you imagine. The problem with cost is, it is always associated with $ figures, what people fail to understand that time wasted by people also is a cost because that can be utilized somewhere else to make or save more money. Imagine you hire someone for short term, and now you have to let them go because they don't fit your long term plans, people in the team will have to spend time transitioning that knowledge, you will spend time as a leader managing expectations, cost of hardware & software that you procured for them, cost of time you spent trying to get them up to speed. All that for 2-3 months of work, it's a waste of time & energy, not to mention that bad rep your company gets, if you keep doing this over and over.

But I found a rockstar candidates

Another reason, why a lot of managers hire before having a long term vision, is because they found a rock star candidate. Well that person is only a rockstar most probably because they are in a stable environment, focusing & doing their best work. That means that when you put them in an unstable, unfocused environment and you might not get the same output from them. So, don't create a role just because you found a rockstar, hire a rockstar because you have role for them.

People are not cogs in a wheel

Another problem is the philosophy that, everyone is replaceable and a team is like a machine where you can replace a person without any impact. Well, skill wise yes most people are replaceable but the true cost of replacing a person is not the skill gap, its everything else that makes a team successful.

A team, is not an emotionless machine, it is a combination of people working towards a common goal. Which means, the chemistry they have with each other, the culture that makes them successful, their mutual respect for each other, everything is as important as the skills of the people.

If you keep replacing people in your team/organization, it will create a false sense of flux that has a very adverse impact on productivity. Your team will spend a lot more time training people, than doing actual work.

No one hits the ground running

For starters, you only hit the ground running, when you are trying to get off a moving bus or train. And, that is very dangerous because if you are not careful you will get into a terrible accident. Secondly, that momentum is not something you can carry forward always, because friction!!

Now, that we have clarified the physics part of this term, let's talk about why it is not practical in an organizational context.

There are a few reasons for it, first every organization is different, their product/services are different, their culture is different and their processes are different. There is a learning curve to go over that hump, before you can start doing actual work.

You need a lot less people than you think

The last thing to remember as a leader, is that if everyone in your team is doing their best work in a stable, productive environment, you can achieve a lot more with small teams. If you learn to be realistic in your goals, and prioritize them correctly you don't need a large team to achieve them.

What small teams also give you is a box that you need to fit your ideas, priorities in. Trust me this is very important for any team, because to deliver a great output you need to prioritize things. If you spread your net too wide, you will end up spending time on things, that should be your priority.

Today, I was on an interesting project management call for a client, where 7 people spent almost 1 hour trying to create a project status tracking dashboard. That's 7 hours spent on trying to create a dashboard to track progress of a project, the end result of which was a dashboard with 20 status columns for each task. Now imagine each developer working a task having to spend that extra time just tracking project tasks. Also, how can anyone get any information about the project status from such a cumbersome dashboard ?

Unfortunately I have seen disasters like this over and over again throughout my career. Most project status dashboards that I have seen are poorly maintained, and developers require push to keep updating them.

Here is what I learned about how to make project status tracking, simple, efficient and meaningful.

Status Dashboard will not provide you answers to all your life's problems

The first thing to understand is that a status dashboard is supposed to only provide you status of the project, its tasks and anything critical that the team needs to be focused on. If, you need more answers it can be tracked as comments, discussions on specific tasks, and anyone who wants to know those answers will have to go to that detailed level to get them.

The problem starts when people start adding more columns to a project status dashboard to avoid spending the time & effort, trying to dig down into what work has gone into a task. And like that to save  5 mins of someone's time, your team is spending 10 hours maintaining a status dashboard. When you look at those numbers, isn't the solution obvious !!!

Keep your project status dashboard simple, and have a comments/discussion board linked to each task for tracking more details. Updating just the status of a task should be the priority, so that your team can brace for any issues. The easier you make it for your team, the better situation you will be in.

Use status dashboards to solve issues, not lay blame

The status dashboard should be used to quickly identify issues, and brace for any fallout because of those issues. But, in most cases they become a tool for laying blame of one person or team. This then leads to team members trying to move the hot potato off their plate by creating a complex dashboard, that can lay blame on someone else for the smallest issues. This then leads to people spending more time trying to move the blame around, than doing actual work.

Successful, teams only use status dashboards & meetings to highlight issues and how to solve them, rather than trying to find some to take the fall for that issue.

Automate

The more you can automate status tracking, the easier it will be for you to maintain it. Also, your status will always be up-to date, and give you the exact picture.

I have consistently used, code pipelines to track which environment a feature/bug has moved to. It gave me an up-to date, and real picture rather than relying on individuals to update a dashboard.

There are enough tools, and automation solutions in the market to help to automate your workflow.

Below are a few tools, that I have used to achieve this :

1. Atlassian JIRA & BitBucket : We were able to automate our development process to a large extent, by tracking code commits, and their movement from one branch to another.
2. Monday.com : There are a lot of good integrations, and automation options available on Monday.com which makes the process of status tracking easy.
3. Zapier : Zapier has a lot of options for integrating different systems. It helps if you want to track status of things like support tickets, customer queries etc. from different platforms into a single place.

Iterate

Like everything else in life, a status dashboard will also never be perfect. You will have to continuously iterate upon it to make sure it evolves with your project and team.

All of us have failed more than once in our lives, at a personal level, professional level or both. I myself have learned a great deal from my failures in life. The best lesson though has been, is no matter how hard you try there is a chance that you will fail, and the best thing you can do is embrace when that happens. Get up, make sure you understand what went wrong, and try to not make the same mistake again.

It's the same when it comes to organizations. A lot of organizations want to be innovative but they want to punish people when they fail, which is counterproductive for innovation. Good innovation only comes when your team is not afraid to fail, when they know they can push the boundaries without worrying about what happens if they fail.

So, how do you build a culture that supports innovation and embrace failure ?

Teams don't succeed or fail because of one person

When a team fails, more often than not it is a collective failure. So, trying to find one person to pin it on is the worst way of handling failure. The sooner you understand this as a leader, the faster your team can move on to being a high performing, innovative team.

A good example of this is, when say the team pushes a software release to production which has a bug that got missed. Generally, everyone is quick to pin it on the QA engineer, or the developer who worked on it. But, if you think about it, first the developer who wrote the code didn't take care of the scenario, then the person who wrote unit test cases failed to identify the scenario, then the person who reviewed the code failed to identify the scenario, and then then the QA engineer failed to test the scenario. Whose mistake was it ? Everyone involved in the process.

You as a leader have to build a culture, where the whole team accepts responsibility for a failure. So, why can't most organizations and teams do it. Simple when something fails, they get into a blame game !!

Stop the blame game, introspection is more productive

The first thing to change is get rid of the blame game. It is a waste of time, and builds a toxic culture. It builds a culture where no one wants to take ownership, and everyone is trying push the hot potato of their plate.

Also, this culture leads to people hiding their failures because they are worried about the repercussions. And, by the time you as a leader find out that something is wrong, it might be too late to fix things.

Instead, create a culture where the team introspects each failure, documents it and learns not make the same mistake again. This makes sure that with time, you iron out major issues, and become a better, more innovative team. It also leads to more collaboration within the team, because everyone is focused on the goal without worrying who will be punished if they fail.

Reward efforts, not just outputs

Another thing to understand is that just because someone failed a few times does not mean their effort is less than someone who did it in less tries. You have to build a culture of rewarding efforts, and not just outputs.

Now, this is not a very easy thing to do, because you have to build processes around measuring effort, along with output. But, trust me that effort of coming up with the right process and tools, will pay off in the long term. It will lead to people picking up even the hardest tasks without hesitation, because they know their efforts will not go in vain even if they can't get the desired output.

Also, when you only reward outputs, you are sending a message that don't pick up something where you are not sure of delivering. Innovation, does not work that ways, and also change is inevitable. Every team, big or small will encounter a scenario where they will have to look at doing something they have never done before. More often than not, teams that have the culture of rewarding efforts and not just outputs will succeed at embracing this change.

Track Learn Optimize

Next part of the process needs to be a robust mechanism to track, introspection meeting outputs, and learnings every time you encounter a failure. This helps in obviously  making sure new members of the team know the pitfalls and old members do not repeat the same mistake. But more importantly, for the team to identify process gaps, and places where you could do more optimization either by process, or technology to make sure you avoid those issues.

A good example of these are coding standards, and static code analysis during the check-in process. Those are common places where programmers make mistake, and by optimizing the process and tailoring it to your product you can make sure that mistakes are not repeated.

As you and your team get better at this, you will see faster onboarding times for new members, reducing common pitfalls and an increase in overall productivity of the team.

Hiring for any company is a critical task, and a wrong hire costs much more in the long term. Over the course of my career I have hired close to a 100 people for various software engineering positions, and I have had my share of challenges. It has taken me a  lot of hit & trials to get to the right approach.

Below is how I approach hiring for my software engineering teams.

Resumes are a waste of time !!

Resumes are good way to summarize someones experience but there is no way to objectively judge any person by their resumes. I have tried bunch of tools to filter candidates based on resumes, but eventually I have realized that resumes are not something anyone should be looking at. It's just a waste of time !!

So, now I don't look at them in most cases. Even when I do, I don't judge anyone's skills by the resume. At most the resume tells me how good the written communication of the person is. I much rather prefer candidates send me the link to their GitHub public repository, where I can look at the actual code they have written.

Judge people on practical skills they have

At the end of the day the primary goal of a good software engineer, is that they should be able to write code, and have an aptitude for problem solving.

If a candidate has  a repository, where I can look at samples of their codes, they go on the top of my pile for people I would like to talk to. I will go ahead and look at all the code that is in their repository, and judge them on the quality of that code.

Next step is talking to them, my first conversation is generally 30 mins, just to understand the candidates communication skills, and their ability to solve problems. I would generally use an example from any of the projects they have worked on, change some requirements and see if they can think of how they would approach that change from a solution perspective. I don't look for right answers, just an ability to think and not be stumped by a change.

Why is this important ? Because I am big believer in the fact that the best output for any software product comes when everyone involved can bring some ideas to the table.

Show me the code !!

Once I want to move forward with a candidate, I would typically give them a problem statement for which they have to write code.

For interns, freshers, and junior developers I prefer using my online testing platform QuodeIT. It is simple to use, and gives me quick results of how many test cases were passed for each code submission. That is all I want from a junior developer, I don't expect them to know architecture or tons of technologies. I expect them to know 1 language, and be able to write code in that language to solve a simple problem, thinking through all the scenarios from a unit testing perspective.

For senior developers, I would give them a bigger problem for which they would have to think about different aspects like architecture, logging, interaction between layers etc. I expect senior developers to be someone who can independently take day to day architecture decision, and help junior members of the team with their issues. I would ask them to first give me an estimate of when they would be able to submit the code. This tells me if they are good at planning, and can they stick to the deadlines they commit to. I don't reject people if they are delayed, as long as they let me know. Also, I ask them to create a README file for the project, which should cover how to setup the project and run it. This tells me about their communication skills, and the ability to articulate their thoughts. This is an important skills for people you would want to groom as leaders in your engineering org.

Code review

Then I do an interactive code review over a call. Where I would go through their code and ask questions about why did somethings. Also, challenge them on their decisions and hear what they have to say about it.

For senior developers this process goes further to challenge them on their choice of tech stack, frameworks etc. It's important for me to know their opinions and thought processes. I don't mind people having strong opinions about technologies, as long as they are patient listeners about conflicting opinion. This becomes a good thing when the team is making decisions.

The code review process is the longest of my whole hiring process, because this is the time where I can accurately judge the person. Sometimes, I would ask the person to change some small feature,  just to again make sure their ability to think and problem solve.

Culture

I always say that you should not hire a person who is not a cultural fit, no matter how good they are. A wrong cultural fit will do more harm to your team, than the value they can add. I have seen this in many organizations, where people who do not fit the culture are hired which ends up costing more to the team.

Earlier I used to do a detailed face to face interview, to try to judge the person culturally. But as technology has evolved, I was able to productize this as part of our QuodeIT platform. It also makes my decision making very objective, as opposed to just depending on my gut feel.

This seems to be a lot work !!

Yes, hiring right is a lot of work. It's not easy, and you should spend that time to make sure you build a team that can deliver for you. The idea for me is simple I spend time hiring the right person, in the longer run I will not spend time/money in trying to get the best work out of them.

Hirings should never be a quantity game, its about quality. 1 right hire, is worth much more than hiring 10 wrong employees.

As the world changed a few months back, and organizations had to adapt to a new completely remote work environment, I saw a lot of organizations buying remote employee monitoring software. The spend on those softwares is actually one of the long term costs of wrong hirings. As, I said when I started this post cost of a wrong hiring is much more in the long term !!

Last week, I was helping a startup founder review his technology architecture and helping them move cloud providers. One of the points that came up in the review, was how do I make sure this platform scales. It sent me thinking to my first year as a CTO for tech product startup. I had just left my job a large investment bank, where I had built large scale solutions. Definitely I was feeling confident that I could build a good scalable product. 4 months into the task, I realized I was so wrong !!

Here is what I learned from that experience.

Your product will evolve very quickly

When you are working for a large established investment you have the liberty of spending a lot of time talking to all your customers, and then have detailed requirements of what you want to build. This is something that most tech startups don't have when they start working on their product. Which means that from MVP to a product that is accepted by your consumers it might change completely. We went through 5 iterations of the product before we found the right solution for the problem that we were trying to solve.

So your technology and architecture have to evolve with the product, and it has to evolve quickly. If you build something very rigid, you might have to start over when iterating on a product, which is what we had to do when we went onto our 2nd iteration. We were over confident about our MVP, and we built it so rigid that we had to go back to the drawing board for our 2nd iteration.

Always consider your team size, and money when designing the architecture

When I was building platforms for an investment bank, team size and hardware capacity were never an issue. You can build a complex architecture, because you have the money to back you up.

In the startup world its not the same. Your resources are limited, and you have to adjust your approach accordingly. E.g. I had a dedicated DevOps team always during my career so I depended on them when it came to hardware decisions, security and scaling. This is not something I had the liberty of when we were building our first few iterations, so I had to evolve into learning those things, and picking the right tools, hosting and architecture so that these things don't become a burden on the team as we are moving forward.  

Cloud provider and scale of the hardware is also something you need to consider. Again money will be limited, so you need to start small, constantly monitor and scale accordingly where required. Things that I had no experience on, when I started this. Somethings I learned the hard way, like over procuring cloud servers and then realizing that we don't have enough users, and we need to be more agile in terms of scale as well.

End users don't care if your tech stack is future ready

Quite often I found myself getting drifted into building the best technology solution without thinking of the actual end user. As I spoke to more people I realized a lot of tech background founders had the same problem. We focus to much on which tech stack, what framework, what database etc. Although these are important decisions, but in your early days its more important to have stable working product that you initial users like. It should be something that is easy to use, solves the end users problems and something that you can quickly iterate on. Till you reach a critical mass of users focus more on user experience, than on what tech stack is future ready.

Another thing to consider is how easy it is to find good talent in the tech stack you are about to use. As you build your engineering team, you will good talent and you will need them to get accustomed to your stack quickly so that they can start helping out. As a startup you will not have the liberty of a long onboarding period, so if your application is too complex scaling your engineering team will become a challenge that might stop you from growing fast.

Build something that a small engineering team can manage

One of my biggest mistakes was I looked at the Googles, Netflixes and Facebooks of the world to find good design patterns and how they were doing it. Why was it a mistake, simple they have 100s of engineers to manage single products/services, while I had 5 !! So where things like microservices might work for them, it became a disaster for me because managing & maintaining them was a huge cost. I could not afford to keep multiple versions of the services running, for me the changes had to move together with every piece in sync, else I would end up spending more cloud costs.

Never look at organizations that are not at your scale or size for technology architectures. It will most of the times end up in unmanageable product, which will require more money to maintain than you can afford.

Do what makes sense for you

Overall what these last 4 years have taught me is that my product is unique, my requirements are unique, and I have boundaries that I need to work within so I will have to do what makes sense for my product. My end users don't care if my UI framework is the coolest one in the industry, they care that their experience is nothing like any other product

Also, for me I can manage scale because mine is B2B product so I will always know how many licenses are being sold and how many new users I should expect to be on the platform. I can plan easily, and I don't have to worry too much about a sudden spike, so why worry about that instead I can spend energy on something else.

Finally, always remember when you have 1 Million users, you will have enough money in the bank to hire people smarter than you to fix any scaling issues that you might have !!!

Some of my best work has come when I am focused. For a long time I thought of this as a shortcoming, because everyone around me was able to multitask, so that felt like a required skill. As, I have matured I have come to realize that multi tasking is not as cool as it looks, and that best output only comes from focus.

It becomes even more important as a founder for me to give focus to things that are important, and ignore all the white noise, because the output of the business depends on my decisions.

The book "It Does not have to be crazy at work" gave validation to this idea of mine. I would recommend reading it if you have the time.

Time is Money

You should value your time like you value money. Most of us tend to see time as an infinite resource, when the fact is that you probably have only 8-9 hours of good productive hours in a day. Which means you have to spend them very judiciously.

When you are constantly multi tasking, you are wasting precious time trying to context switch. Time that can be spent at the task at hand without having to context switch. Also, time spent focusing and making a good decision today, can save you a lot of money tomorrow, than making a decision just because you were pulled into a meeting without enough time to think about it.

14 hours days are not sustainable

To be honest I have done my fare share of crazy work hours and sleepless nights. When I introspect, none of them lead to good quality output. I have created some of the worst technical debts working at 2 AM high on caffeine. Now when I look at some code and ask why did I do that, the late night code check-in timestamp is probably the answer.

There is a reason that 7-8 hours of sleep is recommended for humans. Your mind needs rest, for it to make sound logical decisions. When you build a culture that expects people to constantly work long hours, eventually their productive and quality will go down.

You are measuring the wrong output

So, if long hours are not good for productivity and quality, why do a lot organizations still embrace it as a culture ? My simple answer, they are measuring the wrong output.

I have worked with enough managers, who used to measure productivity in terms of number of hours spent in office, and then wonder why the project had delays or so many bugs !! Simple because your measure of productivity does not guarantee efficient and quality output. The goal should be efficiency and quality of the output, than something as subjective as productivity.  If someone can deliver the most efficient and quality output with the time/cost constraints, why does it matter if they wrote 10 lines or 1000 lines of code, or if they spent 8 hours or 14 hours in office.

The calendar, emails and  chat hell !!

All the technology that has been built around communication, was supposed to make our life better. But, I think all it has done is make it worse. Why? Because people have stopped considering that the person on the other end of the communication might be focused on something else. Everyone expects that they send a message and get a response now.

Calendar invites are a probably the most abused of these technologies. Just because my calendar shows I am free 30 mins from now, does not mean you go ahead and schedule a meeting. For the most part I do no accept meeting invites that are scheduled the same day unless it is something extremely critical. Everything else can wait a few hours.

Do you really need a meeting for this ?

Meetings are another aspect of the modern work environment, which I think force people to lose focus, and try to be part of a discussion at a fixed point in time. A meeting which does not give its participants enough time to think before the discussion, and that ends without a decision is a waste of everyone's time. Also, a decision cannot be having another meeting to discuss the topic further !!!

Think before you schedule a meeting. If your discussion is not world ending, and you want people to think before they provide ideas, maybe give them time to respond to an email when they have bandwidth. You will probably get better output through an email, than the false sense of urgency to make a decision that a meeting forces. And then use a quick meeting to reach a consensus after you have had a thorough discussion about the topic over emails. And always end the meeting with a concrete decision, and next steps.

Todo Lists do not work !!

A list of things to do in the day gives me anxiety. I tried it for sometime to plan my day with lists, and tasks etc. What I realized eventually is that some tasks were either constantly getting pushed from one day to another or I would take shortcuts just because I could strike tasks out of my list. The reason for this is that Todo lists give a false sense of accomplishment by telling you that you have checked off all your tasks, and hence driving the goal to finish the tasks and not quality. It also forces you to meticulously plan each task, which is not practical. So, you plan your day and then realize that some task took more time, and that screws your plan for the day and makes you feel bad about that unfinished list at the end of the day.  

So, what do I do now. I divide my into long continuous stretches of time where I just focus on one task at hand. That helps me focus on the task at hand, and make sure it is completed before I move onto the next task. Since I made this switch, I have been getting more done but most of all the quality of my output has increased and stress levels have gone down !!!

Let people get into their zone

There is a reason why most great artists talk about getting into their zone before they produce a masterpiece. It is important for people to focus on the task at hand, without distractions to deliver the highest quality output. So, as as leader one of your primary job should be to let people get into their zone by giving them long stretches of focused work hours. Time when there are no meetings, no emails, no multitasking, just getting the job at hand done.

Once you start doing it, people will get better at planning their work and deliver high quality results efficiently.

I am one of those people, who believes coding is more art than science. I like to think that there is an inherent level of creativity that is required to be good at coding. I enjoy it till date, because I feel happy when I able to create something new through my skills. From my school days, programing was the only thing no one forced on me to learn, so I learned it at my own pace. That I think became the biggest reason of why I enjoyed it, because there was no pressure of marks, or deadlines. It was the first sense of independence that I experienced.

When I first started coding, a lot of people did not believe that technology will become so important in our lives and that coding will become a much sought after skill.

So how did it all start ?

My dad - The visionary !!

When my dad bought a computer for our home (we were one of 2 homes that had a computer at home in my town), everyone was like 'Why do you need a computer at home ?'. His answer was computers will run the world one day, and I want my kids to get used to them. A lot of people thought that was not possible, and mocked him, saying that schools have computer labs, if he wants me to learn computers 45 mins once every 2 weeks should be good enough. 30 years later I am glad he did not listen to them.

The computer at home gave me access to a toy that I could play with and would never get bored of. Something I got better at every time I spent time on it.

The first thing I wanted to do was play games on it. My dad showed me Wolf 3D, and I was hooked. Then he was like if you can turn on the computer find where the game is, and figure out how to start it, you can play it. It was DOS based system (4 MB of hard disk space), so to do that I had to learn DOS command line interface, and basic commands. At first I could not figure it out, one time I ended up deleting directories in DOS. We had to reinstall the operating system !! My dad was not angry though, he taught me how to install the OS, and he was like from now on you should be able to it yourself. I can't remember how but eventually I was able to figure the DOS command prompt interface, open directories and run DOS commands. Spent long hours playing Wolf 3D, after that.

Eventually I got interested in writing code in Basic. My first program was simple calculator for adding & subtracting numbers. It was fun, writing a few lines and seeing an idea come to life. This is what made me keep going back, and trying new things.

The first coding night out

I still remember, it was a project submission for my class 10th computer project. I had 2 options, take the easy way out i.e. copy it from someone, or build something on my own. I wanted to explore how you could build a full Hotel Management System, so I decided to build something. Obviously, I had grossly underestimated the work required, so I reached out to the only other person I knew could help me finish it, my father.

We spent the whole night writing code for the project, and then printing out the code for the submission report (Yeah, we had submit hard copy of the code, and its output !!). That feeling of accomplishment, along with exhaustion from working all night, is something that still pushes me till today.

Windows 95, internet and my first deployment

The next phase in my learning came with Windows 95 and the dial up modem. I was fascinated by websites, and I wanted one as well !! Time to learn HTML.

Took me about a week to have a basic page ready, and then create navigation to other pages. But this is too boring, just plain paragraphs and tables. How do these other sites add colors, animations and jazz ? Time to learn stylesheets.

Another week, and the website was looking good with loads of colors, blinking links and marquees (I cringe about that design now when I think about it !!). Then I found some cool websites which had funky things, like some popovers when you took the mouse over an image. And I wanted that on my website as well. This was the first time I learned that I could right click on any website and look at their source. I started copying pasting styles, javascript from other sites and adding it to my site.

Once the site was done, I wanted to show it to everyone. So, for the first time in my life I hosted something on a server. That was amazing feeling to see something you created on your computer come to life on the internet with everyone having access to it.

Computer Science, the only thing I wanted to do

When it was time for me to start college, we had to pick our top 3 priorities for a branch of engineering. Everyone was filling the priorities based on career prospects, and I had picked only 1, Information Technology, my only other option was drop off and try again next year. My choices were binary even then !!!

By the time I completed the second semester, I was very clear in my head, that this is something I enjoy, and I wanted to learn more about it. So, as we started getting options to pick our elective courses, people were thinking about which ones would get them better grades, and I just picked subjects that interested me. I was one of only 5 people in the AI course one semester, and had to talk to the dean to make sure the management did not cancel the course due to low registration.

My first job

By the time I finished college, I had an offer from one of the large IT outsourcing firms in India. I was happy that I had a job, but I also was a little skeptical. My interview did not talk anything about the programing skills I had learned, and I felt like I was ready to work on live projects, as opposed to going into another 6 months of training.

So, when the opportunity presented itself in the form of niche consulting company which I had heard did cool tech work for its clients, I decided to go for the interview. It was a coding test, followed by a tech interview. The interview experience was so fulfilling, that I was sure of taking the job if I got selected, and I did.

My first project

I still remember when I first started on the project, I looked at the code base and was just amazed at the shear size of it. Then I started digging, and realized I could not figure out most of the stuff !! I was like damn, this seems harder than I thought. It took me almost a week to find my way around it, a week that felt same as what I felt when I first started using a computer. Then a week later, I submitted my first check-in for review, and deployed my first code for QA testing.

14 years since, I have been writing code every single day. And I cannot think what life would have been like if I was not doing this.

For the last one month I have been looking at Tableau extensions as a way to add more interesting analytics for a client's dashboards. They are great tools to enhance the functionality of existing dashboards by adding  visualizations that are not provided by Tableau. In this blog I will explain how to build your first Tableau extension using ReactJs

Development Environment Setup

Before starting with Tableau extension development, you will need to setup your development environment.
Following are some of the tools you will need to setup :

• NodeJs : I will be using NodeJs version >= 12 for this tutorial. You can download NodeJS package for your operating from the below link.
  • https://nodejs.org/en/download/
• Yarn (Optional) : I prefer yarn over npm for package management. Just a personal preference, you can use either.
  • https://classic.yarnpkg.com/en/docs/install
• Code Editor : I use WebStorm to setup and edit my NodeJS code. You can any editor which has support for JavaScript code editing (e.g. Sublime Text, Atom, Visual Studio Code)

Once you have all these tools setup on your machine, we are all set to start building our first Tableau extension.

Create a new ReactJs App

Run the following command in a terminal to create a new ReactJs app

npx create-react-app first-tableau-extension

Once the script finishes running go into the new first-tableau-extension directory

cd first-tableau-extension/
yarn start

The yarn command should give an output similar to the one below

Compiled successfully!

You can now view first-tableau-extension in the browser.

  Local:            http://localhost:3000
  On Your Network:  http://172.31.98.101:3000

Note that the development build is not optimized.
To create a production build, use yarn build.

Open a browser and enter the url http://localhost:3000 in it. You should see the following output in the browser.

Now that we have successfully setup the ReactJs app we will go ahead and start adding features for Tableau extension.

Add copyfiles node package to the project

We will need the copyfiles node package for adding the tableau extension library when we build the project

yarn add copyfiles

Adding Tableau extension library to the project

Create a new folder called lib under the tableau extension root directory.

Download tableau.extensions.1.latest.min.js from https://github.com/tableau/extensions-api/tree/master/lib and place it in the lib directory

Update the package.json file to change the start and build scripts, to copy the tableau extension library JS into the public folder before starting the server/building the package. Below are the changes that need to be done to start and build scripts.

 "start": "copyfiles -f lib/tableau.extensions.1.latest.js ./public && react-scripts start"

"build": "copyfiles -f lib/tableau.extensions.1.latest.js ./public && react-scripts build"

The updated package.json should look like the one below.

{
  "name": "first-tableau-extension",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.3.2",
    "@testing-library/user-event": "^7.1.2",
    "copyfiles": "^2.2.0",
    "react": "^16.13.0",
    "react-bootstrap": "^1.0.0-beta.17",
    "react-dom": "^16.13.0",
    "react-scripts": "3.4.0"
  },
  "scripts": {
    "start": "copyfiles -f lib/tableau.extensions.1.latest.min.js ./public && react-scripts start",
    "build": "copyfiles -f lib/tableau.extensions.1.latest.min.js ./public && react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

Finally go public/index.html and add the below under the head tag, to import the tableau extension library when serving/building the project.

<script src="%PUBLIC_URL%/tableau.extensions.1.latest.min.js"></script>

Creating extension configuration file

Tableau extensions require a .trex file to load the configuration of the extension into the Tableau dashboard. We will now create the .trex file for our extension. Create a file named first-tableau-extension.trex in your extension project directory.

Copy the below contents into your trex file. You can then customize properties like author, extension id etc.

<?xml version="1.0" encoding="utf-8"?>
<manifest manifest-version="0.1" xmlns="http://www.tableau.com/xml/extension_manifest">
    <dashboard-extension id="com.nerdyandnoisy.tableau.extension.first" extension-version="0.1.0">
        <default-locale>en_US</default-locale>
        <name resource-id="name"/>
        <description>First Tableau Extension</description>
        <author name="Sunny Dave" email="sunny.dave@nerdyandnoisy.com" organization="Nerdy And Noisy"
                website="https://www.nerdyandnoisy.com"/>
        <min-api-version>1.0</min-api-version>
        <source-location>
            <url>http://localhost:3000/index.html</url>
        </source-location>
        <icon>iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAlhJREFUOI2Nkt9vy1EYh5/3bbsvRSySCZbIxI+ZCKsN2TKtSFyIrV2WuRCJuBiJWxfuxCVXbvwFgiEtposgLFJElnbU1SxIZIIRJDKTrdu+53Uhra4mce7Oe57Pcz7JOULFisViwZ+29LAzOSjQYDgz1ZcCvWuXV11MJpN+OS/lm6179teqH0yDqxPTCyKSA8DcDsyOmOprnCaeP7459pdgy969i0LTC3IO/RQMyoHcQN+3cnljW3dNIFC47qDaK3g7BwdTkwBaBELT4ZPOUVWgKl4ZBnjxJPUlMDnTDrp0pmr6RHFeEjjcUUXPDGeSEwDN0Xg8sivxMhJNjGzbHd8PkM3eHRfkrBM5NkcQaY2vUnTlrDIA0NoaX+KLXFFlowr14tvVpqb2MICzmQcKqxvbumv+NAhZGCCIPwEw6QWXKYRL/VUXO0+rAUJiPwAk5MIlgVfwPjjHLCL1APmHN94ZdqeYN+NW/mn6I4BvwQYchcLnwFhJMDiYmlRxAzjpKWZkYkUCcZ2I61wi37tLbYyjiN0fHk5Oz3nGSLSzBbNHCF35R7f6K1/hN9PRhek11FrymfQQQKB4+Gl05P2qNRtmETlXW7e+b2z01dfycGNbfFMAbqNyKp9Jp4rzOT8RYFs0njJkc2iqsCObvTsOsDWWqA5C1uFy+Uz/oXJeKwVT4h0RmPUXhi79vuC0Ku6yOffTK3g9lfxfDQAisY516sg5kfOCiJk7HoLt2cf9b/9LANAc7dznm98PagG1fUOZ9IP5uMB8Q4CPoyNvausapkTt3rNMuvdf3C/o6+czhtdwmwAAAABJRU5ErkJggg==</icon>
    </dashboard-extension>
    <resources>
        <resource id="name">
            <text locale="en_US">First Tableau Extensions</text>
        </resource>
    </resources>
</manifest>

Update the ReactJS code to interact with the Tableau dashboard

For the UI of this extension we will be using the react-bootstrap package. You can use the below yarn command to install the react-bootstrap package.

yarn add react-bootstrap

The thing to note when creating extensions is that the only way to access data is through an existing sheet on the dashboard. So, next we will need to create a component which can be used to select the sheet which will be used to access to the data.

Let's start by creating a JavaScript file named SheetListComponent.js. In the code below we are iterating through all the sheets in the dashboard and creating buttons for each sheet, which can then be used by the user to select the sheet they want to use for getting the data for our extension.

import React from 'react';
import { Button } from 'react-bootstrap';

function SheetListComponent(props) {
    const makeSheetButton = (sheetName) => {
        return (
            <Button key={sheetName} variant='light' block
                    onClick={() => props.onSelectSheet(sheetName)}>
                {sheetName}
            </Button>
        );
    }

    const sheetButtons = props.sheetNames.map(sheetName => makeSheetButton(sheetName));

    return (
        <div>
            {sheetButtons}
        </div>
    );
}

export default SheetListComponent;

Next up we will creating a small component which will be used as a loading screen while the extension is loading configuration or data.

import React from 'react';
import Spinner from 'react-spinkit';
import './styles/LoadingIndicator.css';

function LoadingIndicatorComponent(props) {
    return (
        <div className='loadingIndicator'>
            <h3>{props.msg}</h3>
            <Spinner name='three-bounce' fadeIn='none' />
        </div>
    );
}

export default LoadingIndicatorComponent;

We will need a CSS file along with the LoadingIndicator just to add little style to the loading indicator.

.loadingIndicator {
    width: 200px;
    height: 200px;
    text-align: center;
    position: absolute;
    left: calc(50vw - 100px);
    top: calc(50vh - 100px);
}

Now that all of our basic components are ready, we can start wiring them in. Let's create a new JS file called Extension.js. The first thing we will do here is initialize the tableau extension, and get selected

tableau.extensions.initializeAsync().then(() => {
        //Here you can write code that needs to be executed post the extension initialization
})

The first thing we will do inside the initializeAsync promise is to get all the sheet names from the dashboard on which this extension has been added.

tableau.extensions.initializeAsync().then(() => {
            const sheetNames = tableau.extensions.dashboardContent.dashboard.worksheets.map(worksheet => worksheet.name);
})

Now let's create a state variable to store these sheet names

const [sheetNames, setSheetNames] = useState([]);

We can now add the sheetNames to the state variable

tableau.extensions.initializeAsync().then(() => {
            const sheetNames = tableau.extensions.dashboardContent.dashboard.worksheets.map(worksheet => worksheet.name);
            setSheetNames(sheetNames);
})

Next step we need to create a sheet variable to store the selected sheet. We will also use this variable to determine if a sheet has been selected or not. Along with it, we are also going to determine a state variable to manage the loading state of the extension.

const [isLoading, setIsLoading] = useState(true);
const [selectedSheet, setSelectedSheet] = useState(undefined);

Now let's add the logic to show the Sheet List component we created in case no sheet is selected. For this we will use the Modal component in react-bootstrap, and the SheetListComponent we created above. So make sure you import those dependencies.

import {Modal} from "react-bootstrap";
import {SheetListComponent} from "./SheetListComponent";

We will now create a variable that we will use for setting what needs to be shown on the extension UI based on our conditions, and set it to show a modal window to select the sheet when no sheet is selected.

    let output = <div>Sheet Selected : {selectedSheet}</div>;
    if(!selectedSheet){
        output =
            <Modal show>
                <Modal.Header>
                    <Modal.Title>Choose a Sheet</Modal.Title>
                </Modal.Header>
                <Modal.Body>
                    <SheetListComponent sheetNames={sheetNames}/>
                </Modal.Body>
            </Modal>
    };
    return (
        <div>{output}</div>
    );

Now that we have this in place, let's try to test if this works fine. One last step before we can test this in Tableau is to edit the App.js to add the new Extension component we have created to it. The updated App.js should like the one below

import React from 'react';
import './App.css';
import Extension from "./Extension";

function App() {
  return (
    <Extension/>
  );
}

export default App;

Launch Tableau desktop, and open your Tableau workbook. On a dashboard view use the left Dashboard Objects pane to select Extension. Once done drag and drop the extension into the dashboard. You should see a popup like the one below.

Select My Extensions, and then select the trex file we created above, to load the extension. Once you open the trex file Tableau should give you a popup asking to allow running the extension.

Once you click ok the extension should load and show you a list of all the sheets that are in your current dashboard

Wallah !! The extension is working fine.

Save settings

Now we are going to look at how we can save some of the extension settings so that when the dashboard loads the extension does not ask the end user for configurations, and hence making the interaction feel more native.

We are going to save the selected sheet into the extension settings and pull it from the settings the next time the extension reloads.

First we will create a function to store selected sheet that is returned by the SelectSheetComponent.

    const onSelectSheet = (sheet) => {
        tableau.extensions.settings.set('sheet',sheet);
        setIsLoading(true);
        tableau.extensions.settings.saveAsync().then(() => {
            setSelectedSheet(sheet);
        });
    };

In the above code we are using the settings property in  tableau extension. Settings is a key value pair object where you can save string properties as values. Once done you can save the setting, using the saveAsync function which returns a promise, inside which you can do other operations post saving of the setting. We set the selected sheet in the state object once the setting has been saved.

Next we will update the SheetListComponent tag inside the modal window to pass this function to the component

<SheetListComponent sheetNames={sheetNames} onSelectSheet={onSelectSheet}/>

Finally we will update logic within the promise for initializeAsync function of the extension to pick up the selected sheet from the settings.

    useEffect(() => {
        tableau.extensions.initializeAsync().then(() => {
            const sheetNames = tableau.extensions.dashboardContent.dashboard.worksheets.map(worksheet => worksheet.name);
            setSheetNames(sheetNames);
            const selectedSheet = tableau.extensions.settings.get('sheet');
            setSelectedSheet(selectedSheet);
        })
    },[]);

Now reload your extension and select a sheet from the dashboard.

You should see something like this in the output.

Now try reloading the extension again, it should pick up the selected sheet from the setting and directly take you to the above view without you have to select the sheet again.

Get data from the selected tableau sheet

So finally, we can now pull our data from our selected sheet.

First we need to get the selectedSheet object using the tableau extension API. We will create a function for this.

    const getSelectedSheet = (sheet) => {
        const sheetName = sheet || selectedSheet;
        return tableau.extensions.dashboardContent.dashboard.worksheets.find(worksheet => worksheet.name === sheetName);
    };

Then we need to know what rows (marks) are selected, and also when that selection is changed. Tableau extension API has a function

Let's create a function to load the selected marks from the selected sheet.

    const loadSelectedMarks = (sheet) => {
        if(unregisterEventFn){
            unregisterEventFn();
        }

        const worksheet = getSelectedSheet(sheet);
        worksheet.getSelectedMarksAsync().then(marks => {
            const worksheetData = marks.data[0];
            const rows = worksheetData.data.map(row => row.map(cell => cell.value));
            const headers = worksheetData.columns.map(column => column.fieldName);
            setRows(rows);
            setHeaders(headers);
            setIsLoading(false);
        });
        unregisterEventFn = worksheet.addEventListener(tableau.TableauEventType.MarkSelectionChanged, () => {
            setIsLoading(true);
            loadSelectedMarks(sheet);
        })
    };

One interesting thing in the above code is the line where we add an event listener to the worksheet. Tableau extension API provides different events that we can tap into to update our extension UI, for this example we have used the MarkSelectionChanged event.

We will also have to update initial loading code (initializeAsync) and the sheet selection code to add a call to the loadSelectedMarks function.

    useEffect(() => {
        tableau.extensions.initializeAsync().then(() => {
            const sheetNames = tableau.extensions.dashboardContent.dashboard.worksheets.map(worksheet => worksheet.name);
            setSheetNames(sheetNames);
            const selectedSheet = tableau.extensions.settings.get('sheet');
            setSelectedSheet(selectedSheet);

            const sheetSelected = !!selectedSheet;
            setIsLoading(sheetSelected);

            if(!!sheetSelected){
                loadSelectedMarks(selectedSheet);
            }
        })
    },[]);

    const onSelectSheet = (sheet) => {
        tableau.extensions.settings.set('sheet',sheet);
        setIsLoading(true);
        tableau.extensions.settings.saveAsync().then(() => {
            setSelectedSheet(sheet);
            loadSelectedMarks();
        });
    };

Now we will create a simple grid to display the selected data. For this we will use a react library called react-virtualized.

yarn add react-virtualized

Next we will create a simple data table to display the selected data.

import React from 'react';
import { AutoSizer, MultiGrid } from 'react-virtualized';
import './styles/DataTable.css';

function DataTableComponent(props) {
    const cellRenderer = ({ columnIndex, key, rowIndex, style }) => {
        if (rowIndex === 0) {
            return (<div className='cell header' key={key} style={style}>
                <button type='button' className='link-button'>{props.headers[columnIndex]}</button>
            </div>);
        } else {
            return (<div className={'cell ' + (rowIndex % 2 === 1 ? 'odd' : 'even')} key={key} style={style}>
                {props.rows[rowIndex - 1][columnIndex]}
            </div>);
        }
    };

    return (
        <div className='dataTable'>
            <AutoSizer>
                {({ height, width }) => (
                    <MultiGrid
                        key={props.dataKey || -1}
                        fixedRowCount={1}
                        className='grid'
                        cellRenderer={cellRenderer}
                        columnCount={props.headers.length}
                        columnWidth={150}
                        height={height}
                        rowCount={props.rows.length + 1}
                        rowHeight={30}
                        width={width}
                    />
                )}
            </AutoSizer>
        </div>
    );
}

export default DataTableComponent;

Let's add the DataTableComponent to the Extension component and add as part of out output.

    const mainContent = (rows.length > 0)
        ? (<DataTableComponent rows={rows} headers={headers}/>)
        : (<h4>No Data Found</h4>);

    let output = <div>{mainContent}</div>;

Reload the extension and you should see a message saying "No Data Found"

Now try selecting some marks from your selected sheet, and the data should start appearing in your extension view.

And there we have our first tableau extension, which can interact with the tableau dashboard and pull data from the sheets.

The code for this sample extension is available in the below GitHub repository.

https://github.com/sunnydave/first-tableau-extension

Everytime someone comes to me with a new idea asking for my advice on how to turn it into a business, the first thing I tell them that start a business not because you think your idea is great but because you think you are the only one who can turn this idea into a successful enterprise. Everyone has a good idea, but what separates successful entrepreneurs from unsuccessful ones is execution.

Here are few things I have learned during my journey as an entrepreneur, which I believe are important to build a successful business

Value before valuation

Businesses who have been able to create long term value survive no matter how small or big their valuation is. I am a literal guy so for me value is, are people ready to pay for using your product/services, and does that money cover the cost of running your operations.   This makes sure that then you can focus on building a good business and not on arranging money from external investors for it. Trust me raising investment is hard, and not needing to do it will save you a lot of time & stress.

If you build value and sustainability into your business from day one, then investments become tools for growth and not keeping the lights on.

Rome was not built in a day and neither will you business

Building a successful sustainable business is a marathon not a sprint. The first thing you need to be ready for is that turning your idea into a business will take time. There is no shortcut to building a sustainable business, and you will have require a lot of perseverance to get through day to day challenges.  Companies like Basecamp, WorkDay, SalesForce, Shopify are great examples of how long it takes to build a successful billion dollar sustainable business.

Winners do one things that losers don't - They focus

Any business has only finite amount of resources but start-ups have even less resources. Sometimes you only have those 4-5 hrs a day to work on your idea. This means that you will need a razor sharp focus in everything from deciding which problem in your business area you want to solve, to which feature should be part of your releases. Focus then becomes a tool for you to prioritize your work, making your decision making easier.

As your business grows, focus makes sure that everyone in the team knows what is the end goal they are working towards, and your organization moves as one cohesive unit.

Every business is a services business

This is specifically important because a lot of people think that they don't need to build a customer focused, or service mindset because they are offering products and not direct services to their end customers. This assumption cannot be farther from the truth, from the time a customer buys your product, or logs into your platform they become a customer who expects everything that a typical service customer would expect. You can automate end user services by using bots, emails, automated phone calls, but you cannot escape the fact that retaining customers requires a customer focused mindset.  

The first thing I learned when venturing into my entrepreneurial journey is that you will find a lot of people trying to copy your ideas. Some of them will tell you that your idea will not work and then go out trying to replicate it in their products. Few of them would go one step further and blatantly copy exact lines from your discussion, website and pitches.

At first this used to irritated me, make me really angry. My defense mechanism was to go in my shell and share less with the next person I met. But, eventually I realized something, my ideas benefited more from having an open discussion with people, than they suffered from copycats trying to replicate them. This lead me to another conclusion, ideas are easy to come by what matters is the execution and the passion to keep working on the idea until it transforms into a great product.

You are doing what you because you are passionate about it and you believe that there are better ways of doing something, than the approaches available today. That is something no one can ever copy. You are the only one who can sacrifice everything to turn that idea into a reality, you will keep working on it forgetting things like hunger and sleep till you see yours users happy with what they are using.

Once you stop worrying about people trying to copy you and focus on refining your ideas, make a better product for your users and continuously innovate upon it, the copycats will always play catch-up. People copy because they are too lazy to come up with the next best idea, work with their users to refine their experience. For them a few extra bucks is better than building a sustainable product and great user experience. They can never match your never give up attitude and drive, to get better with every experience.

Now when I see someone trying to copy my ideas I go read feedback from my end users and see how/why my approach is better than anyone else's. I keep my focus on my idea, my product rather than trying to out smart a copy cat. Time and time again I have seen this pay off when clients try to compare our products to a copycat and realize how much better, innovative our offering is without us even having to spell it out for them.

To all those entrepreneurs who worry about copycats winning, I would say they can copy an idea, not your grit and thought process which turns that idea into a reality. Don't worry about the noise, focus on what your clients/users are saying about your product, keep innovating and perfecting your idea. See your copycats trying to play catch-up as the distance grows because this is a marathon not a sprint. Also remember, imitation is the sincerest  for of flattery !