The Cookbook: Inspiring and Engaging People

At the heart of passion is love, this is as true for work as it is for our personal lives. Realizing this fact is key to keep people in your team passionate, engaged and happy.

So, how do you create love for the work? Not an easy question, but you begin to find answers when you realize that we instinctively love our own. It’s an evolutionary trait that has kept our species going. When you get people to see your vision, then make it their own by creating parts of that vision, you latch on to that evolutionary trait and create love (yes, even for that measly project management tool of yours!). And love leads to passion. When you hire people you look for passion for their everyday tasks, their craft and then it is your job to inspire them to be passionate about your product. This is how you do it.

Create a clear vision

The trick to great visions (aka mission statements, aka motto, etc.) is that they are honest. It should ring true. People are smart and if you come up with a vision that sounds phony then you’ll go nowhere with them. My favorite quote for this comes from Michale Hyatt

Leadership is more than influence. It is about reminding people of what it is we are trying to build—and why it matters. It is about painting a picture of a better future. It comes down to pointing the way and saying, “C’mon. We can do this!”

Show and sell everyone your vision

You have a vision, a plan, and a destination to go. It is only in your head. It is not something that’s tangible. It is your job to show people your vision. Convince them. Inspire them. Make it their own vision. In the game of business your view of things is significantly different from someone you are hiring. Fact of life: you are driven by your desire to get things done so that your rewards come to you. You are motivated primarily by pursuing your ideas, your vision and your version of reality. Your rewards are not only the significantly higher monetary benefits (which matters a lot of course) but your psychological need to achieve the success that everyone expects from you. You are already sold to the idea, that’s why you are there. But this is completely different from someone you are hiring. She hasn’t seen your vision yet, she is not sold on the idea that this is almost like the cure for cancer.

The only way to sell your vision is by repetition. Create two versions of the vision, a long one and very short one. The long one you use during speeches and when you elaborate and explain. Use the short one as a mnemonic to remind everyone, every day. Have the short one show up everywhere, on your website, on the walls of the office, on your business card, everywhere. At Kaz our short version vision is super simple: we are the power to make great software. The long version includes our goals of making software development fun and creative and about creating a workplace where we are excited to go every morning.

At the end it doesn’t matter how many times you repeat your goals, unless you really believe it and use it as the principle for everything you do. There’s a great little section about mission statements in that wonderful rebel of a book - Rework by the founders of 37Signals:

Standing for something isn’t just about writing it down. It’s about believing it and living it.

Make it everyone’s vision by participation

Communicating and selling your vision to your team is great but it is still yours. Your job is to make it everyone’s vision. The only way that this will be possible is to ask everyone to participate. When you’ve done your job well in spreading your ideas and goals by repetition you’ll start seeing people who are aligning with your ideas. You will also see people who don’t fully agree or have their own versions of a similar vision. The only way forward is to bring all the ideas together. Adapt your ideas to the new thoughts – include them in the longer version of the vision. As long as overarching vision is not altered there is no reason not to. More ideas bring more honesty into your goals. And in the process of this adaptation what was purely yours becomes everyone’s. Remember – people love their own.  

Let everyone define the work scope

As part of creating ownership you have to make sure that the work items, scopes, plans and even the roles for doing those work comes from the team. There should be an overall feeling that we are doing this together rather than this is something we are told to do. This is actually a very easy action item. It saves you from being the big genius who has to come up with everything. You are essentially asking your team to help you structure the work. The moment your team creates its own tasks and work structure they will automatically own it. And by that formula they will love it because it’s their own. Well, it isn’t always like that – what is more likely to happen is that there will be mistakes in the that structuring, there will be disagreements and compromises. But if you expect them, make sure there is scope to change things as the team progresses and realizes what works and what doesn’t work, it will always work out.

Assign roles based on interest and ideas

Once the work structure is in place people need to pick up their tasks. It is extremely important that resources pick up the work they find most interesting. This is what will lead them to engage more with the work and love it. In most work scenarios you’ll find that people are capable of working happily in many areas of the project. But that is not what you are looking for – plain old capability. What you want is love and you get it only in drilling down and finding the right match. A classic example in the software world are full stack developers who can work on pretty much any part of the software development. But every full stack developer I’ve met had a special interest about a particular section of the application. They would have worked effectively in any section but only in that special section will they put in their best effort. And it is not just the best effort that you get out of this, by enabling them to work on areas they love you are bringing in the passion that will get you work outputs that are far beyond the sum of their individual parts.

Keep work goals human sized and own-able

Most giants are not lovable. And most products are giants. They are too big for a single person or a small group to own and identify with. The work needs to be broken down to sizes that individuals or small teams can take over. This way of breaking down a complex work into smaller individual ownership means that the full ownership of work can happen.

Let the team members be the owners of the tasks they do. Which means you create a process where work items and outputs can fully be taken over by a person or a group of people. They define how they get the job done and what they do to deliver the output. The alternative to this would be some kind of central ownership, levels of management where what an individual group does and how they do it is defined by someone outside that group and that is the beginning of the disconnect from the work at hand. In the software world this is actually quite easy, you can always break down that big product of yours to a module that manages data, another which displays the data, etc. But I would argue this model of breakdown is possible in any industry if you are willing to think along those lines. A related theme in this thinking is the concept of keeping the company small even though there are commercial pressure and possibility to be big. Many of the rationales for that theme works for this action item of keeping work structures small, human sized and creating ownership. A classic in this genre is Small Giants: Companies That Choose to Be Great Instead of Big by Bo Burlingham.  

Create opportunities to show off work

It’s important, for human psychology, to show off the output of you passion. It makes us proud, it rationalizes the seemingly irrational passion have for what we do. It creates pride – one of the biggest signs of a hearty company.

Create as many opportunities you can to show off work. These could be in meetings with the management, a little internal seminar to showcase features, a page in the intranet for the group, posts in the blog. Make one off events to show off major successes. These act both as an opportunity to show off and also as closure for the teams.

Celebrate Victories

Celebrating major wins and deliveries signals the team the importance of their work. This reinforces the feeling that what they are doing is valuable and so their love for their work is justified. In human relationships, love may not need external justification but for work it is essential. There is a constant need for encouragement and reinforcement for a team to feel that they are doing the right thing. Celebrating major deliveries is a big encouragement. The celebrations don’t need to be anything big, a surprise pizza or a team dinner treat might be just perfect. At Kaz we have small celebrations like pizzas for a big bug fix along with bigger ones like small break at the beach for a big launch.

Use we and us and never you and them

With all the talk of smaller teams and individual ownership there is a chance of creating a feeling of little islands within a product team. So you as the leader need to make sure that doesn’t get out of control. At the end the teams or individuals need to feel that together they are achieving their goal. That they all have a common love. The most important way this feeling of commonality spreads and stays is by the simple use of the pronouns everyone use in everyday conversation. You as the leader will need to monitor this and nudge it in the right direction. Always stay in the inclusive us, our and we and never you, their and them. If you hear you or them fix them right away, this cannot wait. If someone says “they created the bug” immediately repeat that sentence, with an inclusive pronoun, like “we have a bug we need to fix”. As you practice this you’ll find that it’s pretty easy, most of the time replacing the pronouns and slightly modifying the sentence so that it doesn’t sound that you are correcting someone directly works just fine.

Further Reading

1. Rework - Jason Fried & David Hansson (Founders of 37Signals)

   Here’s a book that you should read anytime you feel like you are agreeing with everything you hear. A complete rebel that comes up with lines like “meetings are toxic”, “ignore the real world”. Read it now before you read anything else!

2. Small Giants: Companies That Choose to Be Great Instead of Big - Bo Burlingham

   Interesting read about companies who stayed small intentionally. Some very interesting stories and thoughts.

Software beyond the pandemic: The Rise of the Online Explorers

This infernal COVID 19 pandemic isn’t going away so easy - we just have accept this fact and move forward. Moving forward means - adapting. We are all adapting. Most companies in the world has adapted to the concept of work from home. It felt like a very difficult task, specially for the industries that were not IT driven, but as with any new concept - once the wrinkles has been ironed out it’s working out fine. In every industry, in every country in the world people are coming up with innovative solutions of adapting their work and life around the facts of social distancing and lock down. Software world is probably the most prepared for that adaptation, we after all are the facilitators for most of the adaptation with technologies like online conferencing, project management, file sharing, come to think of it, online (and offline) everything! But beyond the facilitation and the continuation of the old paradigms we also have to start thinking of how the world will change, how the new world beyond the pandemic (yes there will end to this someday, there has always been one, even black death) will change it’s behavior for consumption, software usage and living it’s life.

We don’t know. We can only predict. But what we know for sure is that there will be many permanent change to how we lead our lives. And as the leaders of change, us software people have to come up with new ways of doing things.

Online concerts and events

Here’s one change that has already started: online experiences for what used to be face to face events. With the lock down in place events like stand up comedy, football games or concerts can’t take place anymore. The alternative is to have them online of course. And we see that happening in many platforms. A great starter event for this new way of doing things came when the greats like Lady Gaga, Stevie Wonder, Shahrukh Khan, and many others came together to support the WHO with an online streamed show recently that raised almost $128 million for the COVID-19 Solidarity Response Fund, as well as local charities that are fighting the coronavirus.  

This overall movement towards online events is a natural progression from where we where before the pandemic. The virus only pushed us more and accelerated us in this direction. What is more interesting is:

“Will this become the new normal beyond the pandemic?”

I would argue yes. The pandemic will change our mindset about online entertainment, it is giving us a taste of the ease of online live streamed events and we like what we taste. On top of this our habit in consuming such events over prolonged time of the social distancing along with residual fear that will likely to remain for a while after the dust has settled will cement the success of these online experiences.

In line with that thinking online venues (the alternate of concert houses and stadiums) are coming up everywhere. Facebook pages like the billboard are picking up huge views. Pickathon launched the series "A Concert A Day" on April 8, which raises money for the MusiCares COVID-19 Relief Fund. Every day through June 7, at 1 pm PST and 4 pm EST, a new performance will be premiered or livestreamed via the Recording Academy's Facebook page, Amazon Music's Twitch channel, and Pickathon's YouTube channel. Featured artists include Margo Price, Mac DeMarco, Tyler Childers, and Foxygen. This is just the beginning.

Beyond online concerts

The interesting trend is that the online experience is going far beyond the old concerts and event streaming that we were used to in the good old days of pre-pandemic world (aka ancient times of 2019). Airbnb for example has focused on hosting “online experiences” as an alternative to their hosting your house for strangers mode. In their words:

These online experiences are as varied as their hosts are imaginative. You can cook with a family from Morocco or go out with someone and check out how the dogs are doing in the post nuclear accident Chernobyl.

This is the face of the new online exploration. This is just the beginning. There is so much more that can happen in this space that is unexplored. Take trips to interesting places for example. The obvious space for that is arm chair based world travelers who asks local experts to visit places they want to see, look at things they want to look. This already existed with 3D videos (and VR apps) like visiting Angkor Wat virtually or Vineyards but the post pandemic world will likely see an explosion of interest for such online explorations.

VR and AR technologies will need to catch up with human expectation for such online experiences. So that is the new horizon for hardware improvements for sure. Again it was going that way anyway, but the pandemic just pushed it harder and the demand for this will be much more stronger than the lukewarm early adopter space it was hovering around in.

Looking forward to that brave new world of online explorations. Life will be interesting. One little pesky virus will not put the spirit of human exploration down for sure. We are working on it but stay safe for now though :)

The Cookbook: Finding and Hiring People (part 2)

This is the part 2 in the section about finding and hiring talent in a hearty company. Check out the previous section with the button above. And click here read from the start.

People are passionate only about jobs they love. And jobs they love are the jobs their personality, intellect, skill, habits, worldview and most importantly their mindset is a good fit for. Every job role has a certain fit. Some people fit it, some don’t. What you hope to find is the closest fit amongst the people you get sufficiently interested to apply for the role.

#1 and #2 are about pinning down the requirements for the fit. When you need to hire people your first action should be to define the job role. Create a detailed list of tasks that the person doing the job will do. Without this list the job advertisement will be wrong, which will lead to the wrong people applying (or too many applying) and at the end you will not be able to test the candidates for the fit.

#3 of having a filter in the application process is a neat trick to check for the fit earlier on in the application process. There are many ways to do this and you need to think of one that works for your industry or job role. Our trick in a typical software job post would be to ask the applicant to solve a certain programming problem and apply with the answer to the problem, or for quality assurance job posts we might put in some typos and ask them to tell us what was wrong with the job post. The beauty of this filtering tricks is that it immediately cuts out people I call the “robo-applicants”, people who are not really interested about your job in particular (hence pretty good chance they are not a good fit) but are applying just because it’s easy to send an email. This early filtering also gives you hints about the candidates who might be a good fit but would otherwise have been rejected for their poorly construed resume or cover letter. This is usually a big problem in engineering and technical jobs. One of the best developers we ever hired at Kaz was someone who had sent a poorly formatted Word document CV that misspelled most of the technologies he had worked in. Yet his email had the right subject line deciphered from our cryptic instructions of how to submit the CV, which I give below:

Please email with your resume with a short description of why this job is right for you ZW1haWwgc3ViamVjdCBzaG91bGQgYmU6ICJOZXh0IFN0ZXZlIEpvYnMi   

This may look like some kind of error in the copy but to the people we were interested in it was just a base64 encrypted string that said - email subject should be: "Next Steve Jobs". All they had to do was use an online decoder to find that string and put that into the email subject. An instant free and crowdsourced filtering for us! Obviously base64 encrypted instruction might not be the right thing for your industry but you can always think of something similar that does this kind of filter early on in the application process.

The audio only interview of #4 is important for a low cost filtering but also more importantly to assess someone without any visual ques. We get biased by visual factors, how a candidate looks, how she dresses, how she smiles, etc. There are considerable data to prove that we tend to like and thus hire people who look or behave like us. A classic in this area is chapter on liking in Robert Cialdini’s book Influence the psychology of persuasion where he relates:

In one study, done in the early 1970s when young people tended to dress either in “hippie” or “straight” fashion, experimenters donned hippie or straight attire and asked college students on campus for a dime to make a phone call. When the experimenter was dressed in the same way as the student, the request was granted in more than two thirds of the instances; but when the student and requester were dissimilarly dressed, the dime was provided less than half the time. [The dime-request experiment was conducted by Emswiller et al. (1971)]

Impressive clothing, posture or even sometimes perfume can bias our decisions. An audio interview reduces the chances of this bias during the initial phases of filtering candidates.

#5 is about avoiding the classic mistake many make. The candidate you are considering must actually do the tasks she is supposed to do during the interview rather than talk about those tasks. This is the only way to really judge if the candidate is a good fit or not. It’s easy to say how you would do something theoretically, answer interview questions that are mostly leaked on sites out there but unless the candidate actually does some of the tasks, you will never know how good or bad she is at doing them. Joel Spolskey sums it up nicely when says “Would you hire a magician without asking them to show you some magic tricks?” in his superb Smart and gets things done… book. The ideal way you should do it is get them to do a simple task in front of everyone and then give them a bigger task to do where the candidates gets some time to finish it by themselves. The first simple task is so that you can see quickly in a granular way if that person’s work style and thinking fits with the rest of the team. It also lets you check the confidence level and the ability to take in stress while actually doing a typical task. At Kaz we sometime ask the candidate to solve simple programming problem like sorting an array of numbers by writing it out on a whiteboard. Great way to see how she is thinking about it, how focused she can be with the stress of people staring at her work, how she handles the stress of writing the code without the help of an IDE which would help her with the syntax of the code, etc. The longer task is more to test a normal situation and see what the end result is both in terms of time it took and the quality of this relatively stress free task. If you are from the software world, Joel’s book or his blog is a must read in this space.

#6 point of creating at least one stress situation is all about testing the candidate for their ability to handle stress. Most interviews tend to be a very congenial affair, which is expected – we meet people we don’t know at all in business settings. So people stay nice and reserved. But most jobs are not like that, you absolutely need to know how this polite and nice guy will react when he is under stress. That is why you have to ensure that your interview team creates a stress test of some kind. Without your instruction or plan that just won’t happen. An easy way we do this at Kaz is by having one of us be the bad guy and try opposing everything that the candidate is saying – intentionally being wrong in some cases to see if and how the candidate counters this. This tactics only works well if you do this after breaking the ice a bit, so that the candidate feels comfortable voicing their concerns. In the software world this is relatively easy as you can say something that is obviously technically wrong and see how the candidate responds to that.

#7 is the take home task which lead to the possibility of seeing, if the stress of the onsite interview and the time constraints are taken off, how the candidate performs. In some sense this mimics a typical situation for the candidate after she has joined the company and have become more relaxed as she becomes familiar with the work and the teammates. This also tests a bit of how remote work might work out with this person.

#8 is to ensure that everyone agrees on the fit. Decisions on fit is always difficult, and it’s easy to be biased. I, for example, always like someone who can think of quick ways of fixing things in a programming problem. Great trait for sure for a startup trying to get their first prototype up but not a good fit when you are building a software that needs to be very stable. As a person it’s very hard for me to change my tests for fit and not be biased. This is why having multiple interviewers helps address that issue. And putting a rule that everyone needs to agree about a candidate for a hire ensures that a dominating bias doesn’t dominate hiring decisions. But when I say multiple how many do I mean? We’ve settled for a maximum of three. Keeping the number odd helps us from getting ties. But there are some interesting research work available in this front. For example in a study to find how many reviewers it took to achieve good decisions on candidates it was found that with a group of three the chances of making a wrong decision falls to just 6%. So that number of interviewers doesn’t have to be too big.

#9 is also about avoiding bias. References in a resume are pretty much guaranteed to tell positive things about a candidate. Listening to that feedback before the actual interview skews your view of the candidate and prevents you from independently making an assessment. So if you do want to check references (we rarely do), check after you’ve found the candidate to be a good fit and you are just checking to find if there are anything that you might have missed.

#10 is a bit controversial, but makes sense if you think about how much time and energy you’ll save by choosing a candidate early. The goal of the hiring process is finding the fit. If you find a fit it’s usually good enough. Yes there is always a chance that there might be someone “fitter” in your list but most of the times the benefits of choosing the current fit offsets the risk of losing out on a talent you haven’t interviewed yet. Obviously for this to work your test for fit needs to be good, but if you followed all the others in this list you should be there!

Once you have found the person you want to hire you have to make him an offer he can’t refuse. But what is that offer supposed to be? Having a fair reward structure is core to keeping people happy and content – the cardinal goal of a hearty company. People are not solely money driven, so happy people doesn’t necessarily mean the most paid people. Money obviously matters but it is only part of the fairness equation. People need to feel that they getting paid fairly for the value they add to the company but they also need to feel that their pay is consistent with others around them. Having a consistent pay scale that you stick to no matter what is much more important than being the highest payer in the block. I would argue that being branded the highest payer is actually detrimental to the concept of the hearty company because you then highlight money as core value and also attract the wrong set of people.

#1 and #2 are about the concept that a hearty company should not highlight money. Money should always feel like it’s a side benefit of following your passion. Conversations about your company should not lead to the fact that you are the top payer or that your benefits packages are the best. Don’t get me wrong here, you should definitely try to be the top payer – that is your insurance for hiring and retaining the top talents – but you never advertise it as such. You should absolutely make sure that you never mention money internal conversations. People should never feel like that the only reason they are with you is that you pay well. The reason for this is simple, money is single dimensional. It’s a number and anyone new in the block can increase that number and take away your spot. If that number is your only advantage, if that is what your people feel is the only reason to be with you then you will always lose. Aside for this simple business logic, there is something about the single dimensionality of money that destroys the feeling of belonging in a group. It reduces the bonds that hold a team together and reduces the feeling of passion people bring in. It is one thing that destroys the feeling of a hearty company the quickest. In the context of hiring, when you offer someone a job she should feel that she is getting the chance to become a part of a family where she can feel safe and add value. Part of that feeling will come from the offer you place in front of her but part of it should come from your existing reputation as an organization, from stories she has heard about your company and from the experience she herself has gone through during the interviewing process.

#3 and #4 is the most important action you can take to create a feeling of fairness. Fact of life: people will know the salaries the company pays whether you keep it a secret or not. If you have structured scale where people are paid by the value they add then it all feels fair. Having a scale also means that there is no fun in a discussion of salaries since it pretty obvious. The trick is to make sure you put people in the right spot in the scale. The key to putting people on the right spot is to assess, fairly, what value they add and make sure that the person is in spot in the scale where others in that same spot adds similar value. This is very hard. Try to make this value calculation as objective as you can. This is where you need to come up with your methods. In the software world it’s relatively easy, if the hiring process is good then people coming in would have the same kind of skill for a given number of years of experience. So you can, almost, place them purely on the number of years of experience. This probably works for most industries. However, remember there are more dimensions to the value a person adds than just her number of years of experience. Some people are just plain and simple geniuses in their abilities, the value they bring cannot be just a function of years of experience. In multiple studies over the years it’s proven that “there are order-of-magnitude differences among programmers" (Great read in this area for the software world - Code complete 2), here’s quote the original study from the 60s [Sackman, Erikson, and Grant (1968)]

“Impressive clothing, posture or even sometimes perfume can bias our decisions. An audio interview reduces the chances of this bias during the initial phases of filtering candidates.”

— Steve McConnell (from Code Complete)

Another not so easy to pin down value is the emotional quotient of people. Some people are just great at bringing a group together, they are good communicators or good people to inspire the team to go through hard times. These are very tangible values that needs to be factored into your calculations. When you find people with exceptional qualities, you put them at a higher point on your scale to reward them for the value they bring in. You are still sticking to your scale, but your calculation for the value is just multidimensional. It’s easy to get things wrong here, and create a feeling of unfairness in this space. A common situation is where similarly experienced resources are suddenly in different points of the scale which creates dissatisfaction. You need to do two things to address this, a) you make sure that only exceptionally gifted resources are moved up the scale and not just a bump up to make the offer better for someone, b) make everyone aware, in whatever way it feels right, that this person is exceptionally gifted and so that everyone knows about the possible bump in the salary. Not easy, but doable. There is one way to avoid this problem completely: only hire exceptional people, then you can stick to the scale religiously on some single dimension!

#5 may not feel right for a lot of people. We are used to “bonuses”, “cash incentives” even little plaques and prizes for good work. But my own experience and a lot of research in this space shows that such performance tied rewards are actually detrimental to the quality of work. Rewards bring out the feeling of money that we try to avoid in a hearty company. Again – you are doing what you do because you love doing it and because you are helping your friends at work and your company in the process. This is what you were hired to do, and you were hired because you are good at this. So success is expected, good work is by default. Reward is also guaranteed by the salary you received. No external reward should dangle in front of you to make you work harder, you work hard because you want to. Putting special bonuses destroys this and makes the bonus the main objective. When there is no bonus it starts to feel less important. These external rewards are also demeaning to the people as it starts to treat them as children whom you can bribe with toy here and there. There are also ample research data that supports this point. A great read for a summary of these research work is Punished by reward by Alfie Kohn.

“For nearly half a century, research has raised troubling questions about the practice of dangling rewards in front of people to get them to do what we want. It doesn’t matter whether the people in question are male or female, children or adults. It doesn’t matter whether the rewards are stickers, food, grades, or money. It doesn’t matter whether the goal is to get them to work harder, learn better, act nicely, or lose weight. What the studies keep telling us is that rewards, like punishments, tend not only to be ineffective — particularly over the long haul — but often to undermine the very thing we’re trying to promote.”

— Alfie Khon (Punished by Reward)

 #6 is about not giving the feeling to the candidate that you are trying to give her a bad deal. Offering the best offer you can afford (and with a scale in place that’s easy) right away sets the tone of a resources involvement with your company. They feel that they are being valued, and there is no feeling of distrust where you trying to con them into a lower salary. At the end of the day the little that you might have saved in giving a lower salary you would lose a hundred times over by the loss of trust that you create. You will pay a compound interest on that loss of trust over the full length of the time that resource is with you – in lost enthusiasm for work, in feelings of not being safe and most importantly in the distrust in your words and vision. Every resource should feel like you are doing the best you can within the business economics you are restricted in.

#7 is again about avoiding money driven individuals I hinted about in #1 and #2. I bring up the point again because after the initial offer you will have an early test of how money driven this person is. If the only matrix the person is interested is money then it should be an easy decision on your part to not go forward with the hiring. With the action of #6 you already don’t have an option to change the salary – the only option you have is to re-evaluate the spot in the scale. You can always check if you have missed any experience or some exceptional skills of the resource during your calculations. But also test how money driven that person is during this phase. Remember that a money driven person will always be on the lookout for another opening out there offering even more money. A hearty company can never be built with this mindset.

#8 is about making sure that the investment in time and energy you made in choosing candidates do not all go waste when you fail to hire someone. Always keep the options open to hire that person somewhere down the line. Stay connected. Put them in your mailing list. Drip market them with stories about your company – about how good you are doing or what great things you are making. Passionate people will always be interested to re-consider – maybe not right away but at point in the future. And when they do reconsider you save a lot by bypassing most of the hiring process. Some of the best employees at Kaz are people we couldn’t entice the first time round but came back to us later. One of them seven years after the first offer!

Further Reading

1. Blog: Joel on Software https://www.joelonsoftware.com/

   Joel Spolsky’s writing in this blog has inspired me to do a lot of experiments at Kaz. Many of my greatest hits come from here. But many of his ideas failed badly too. Whatever the case it’s are a must read if you are in the software world. And some of his ideas work for pretty much any domains. Really good read, sadly he doesn’t write anymore on the blog.

2. Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent - Joel Spolsky

   Book version of his blog on topics specifically about hiring. Perfect thing to have when you want to quickly check some ideas.

3. Influence: Science and Practice - Robert Cialdini

   A classic in the psychology of persuasion where the author comes up with a list of common persuasion techniques based on extensive research work in this interesting area. A good read on it’s own, but superb also to build up your skills for convincing people to follow you - must skill in this business of setting up an organization!

4. Code Complete: A Practical Handbook of Software Construction - Steve McConnell

   A wonderful classic for writing good software. It has some timeless sections on software team dynamics. Here’s a section that relates to how years of experience doesn’t tell you anything in the software engineering talent world:

   “They studied professional programmers with an average of 7 years' experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1. They found no relationship between a programmer's amount of experience and code quality or productivity.

   Detailed examination of Sackman, Erickson, and Grant's findings shows some flaws in their methodology... However, even after accounting for the flaws, their data still shows more than a 10-fold difference between the best programmers and the worst.

   In years since the original study, the general finding that "There are order-of-magnitude differences among programmers" has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000)”

5. Punished by Reward - Alfie Kohn

   Must read for those who think that dangling a bonus or little plaque is the only way to get people to be more productive and effective. At the very least this post on his blog is a great read: Bonus effect

The Cookbook: Finding and Hiring People (part 1)

Ingredient: Passion

Passion comes from the people. So getting this ingredient right is really about hiring the right people and keeping them motivated, engaged and inspired.

When you are building your team and hiring people, you are really hiring their passion. You’d think hiring someone with the right resume, the right experience and skill should be your goal. But it is not. Your goal is to find the person who has the passion to do what you want her to do. Without that passion all those certificates, skills and references mean nothing. Passion is what makes us do things right, it is what makes us not just finish a task but make sure that it really solves the problem that it is supposed to solve.

Fact of life is whatever you are making, it is probably not the cure for cancer. You may stay awake thinking about how your software platform will change the way people will manage projects in the future, but someone you are hiring will not be so enthused. So your job is to find the people who are passionate about their craft, everyday work – the immediate little task they have to do. That’s how you start and then if you take the right of steps you’ll be inspire them to see your version of reality, sell them your vision that will lead them to be passionate for your product. This is the end goal. But this second level of passion doesn’t happen without the first, the more granular level of passion for every day work.  The good news is that the first level of passion is easy to identify if you follow some steps. And then once you have the right set of people, the second level is once again just as easy. I will go over the list of steps to achieve both those levels in this section. But first let’s take the fuzziness out of the word “passion” in this context (once again, my promise in this cookbook is to take out all the hand wavy things and make them as concrete as possible).

People with passion for what they do are simply people who are a good fit for those tasks.

This essentially means that for any set of tasks there’s a certain type of personality, mindset and skill required to make someone be passionate of those tasks. That is the good fit you are looking for. If you find the fit, you are guaranteed to have found the passion. This also means that someone who is passionate for some parts of the work that needs to be done will not necessarily be passionate about other parts. So you will always have to balance your test for good fit (aka passion) so that your team as a group has passion for everything you need them to do. Classic example in my world: someone who is passionate about the look and feel of a website may completely hate working on the server side codes that generates the data that shows up on that website. And for me to succeed I need both these types of passion.

OK, enough of theory. Let’s get to those action items I promised. I’m going to break down this ingredient into a series of topics and then put in the actions within those topics.

Finding and hiring people

Hiring decisions are the most important decisions you will make in an organization. It is the single most significant factor that determines chances of success for an enterprise. This is one place you cannot cut corners or take a short cut. Save time or money on other things, skip a few meetings, get rid of the free coffee if you absolutely must (actually scrap that, it’s a really bad idea) but don’t skimp on the hiring process. If you don’t get the right people you’ll never get the right product. And if you hire someone who is not a good fit, then firing her is way more expensive (cost, loss in productivity and the hit in morale) than the cost of running a good hiring process.

#1 and #2 are about making sure that you and your team choose the person you are hiring. Hire directly and let the team, which is the hire for, make the final decision on the hire. Why? Because a third party such as an agency or even your HR department, will never have a proper understanding about your team’s needs and culture. They will always go by certain metrics like certificates, degrees and experience of a candidate. Good agencies may even try to understand your work culture and try the fit but it will never be as good as your judgement. Work relationships are dependent on human relationships. Only your team will be able feel if of a person will fit with them or not. Not just in work habits but also as a person. Some companies try to counter this point by saying that they let the agency just filter out people so that they can choose from a selected few. But isn’t that just the same? An agency will never be able to identify a candidate who can spot a single weird bug in a page code in a minute, when she has no formal education in software. A candidate like that will be lost during most third party filtering effort.

#3 point about a face to face onsite interview is extremely important. We use much more than our voice to communicate. A face to face interview brings those nonverbal modes of communication out for a check by the team. How your face changes when someone challenges you in a technical debate has huge implications as to if you’d play a good part in that debate or if you’d intimidate (or be intimidated) and reduce the value of the debate. It’s important to test these reactions during the onsite interview.

#4 and #5 is to ensure that the team understands the importance of the hiring process and gives it enough attention. The hiring process takes time and energy of the team. It’s also very distracting, taking the team away from important work at hand. And the worst of all it’s a pain and no one likes to do it. Hence, you as the leader need to make this the priority task. Pushing everything out of the way and making this the most important task is the only way you’ll get the team motivated enough to concentrate on the hiring process. It is definitely bad for the project at hand, in the short term, delaying things but you know that in the long term it is the best thing for the team. So this prioritization is correct.

#6 is all about making the sometimes tedious interview process more enjoyable. When you running a hiring process a team could be spending days going through resumes, interviewing, checking results of a test, etc. If you don’t make it fun for the team somehow there is no way this will run in full steam. Remember you team was never a good fit for running interviews! So they will never have the passion for this. So think of ways of making it interesting. Throw in a few pizzas in the process or even a little party celebrating a good hire This is one area that you should read up to get ideas, there are a lot of books on hiring that goes over this topic, my personal favorite is chapter 8 in Building Great Software Engineering Teams.

#7 is about not settling for a sub optimal fit just to get out of the hiring process – a shortcut. Sometimes you’ll find that none of the candidates fit the role. You’d be tempted to compromise but every time I’ve made that compromise I’ve regretted later on. It is much better to not hire, suffer the consequences of delays and more interviewees than to hire someone who is not the right person for a role and hope things will work out.

Great resources are always in demand. And since they love what they do they are very unlikely to move jobs a lot. Combine those two facts and you’ll realize that the chances of you finding great resources are very slim. You have to take definite action to attract the attention of great resources, create interest and keep them interested so that when the time comes they feel they should try out a new job opening at your place. Chapter 2 in Joel’s book is a must read (or the blog article where it came from) for this if you are in the software world. Here’s a great quote from there:

Instead of thinking as recruiting as a “gather resumes, filter resumes” procedure, you’re going to have to think of it as a “track down the winners and make them talk to you” procedure.

#1 is all about creating assets that will work for you to attract talents to your company. These days these assets probably are platforms like Twitter, Facebook and Linkedin but obviously new platforms and modes are coming up and you have to be aware where your target talents are. Posting interesting and informative posts on our Facebook and Linkedin pages has been one of the best ways to create interest in the developer community about us. This has gone to a point where sometime we don’t even advertise a job at all on job sites – a post on our page gets us the very filtered, interested and engaged resources we want to consider. And the beauty of using a social media asset is that the candidates are already convinced that they want to work for you. Remember that you have to have a plan on social media posting. You’ll first need to identify the topics that would interest your target talents. Then use that to create interesting post that people will engage with. It will take some time, but it is absolutely essential.

#2 and #3 is an extension to the idea of creating an interest in your target group that goes beyond some posts in social media. By contributing and building your company’s image in the community you are investing in your branding and helping create the right perception in your target talents. In the software space this could be creating an open source project that is used by a developers all over the world or helping a school for the under privileged like we do. Being active in online forums (and obviously offline ones) takes up time. So this has to be part of the job responsibility of someone in your team, ideally you.

#4 is about creating great content that helps your target group. This content could be in a blog that people visit or videos that you host on youtube, etc. The goal is to make the content become really useful part of daily work of people you want to hire. The value of this in creating a positive impression about your company and registering to stay updated is significant.

#5 is the best option you have if you are fine with accepting fresh new candidates. An internship process is really an extended interview, or it should be. Your goal for an internship program should never be to get some cheap labor to do some of your grunt work. It is a complete waste of everyone’s time that way. You should instead think of the intern as a possible hire, whom you are helping to achieve the fit you require and in that process evaluating her success and ability to learn. Since they are possible hires, all interns should go through a filtering process, so that you only start with the most likely hires.

 #6 is to ensure that you always have a way for people to send you’re their resumes at any time. If you do your social outreach properly you’ll find that people remember you and they reach out to you when they want to switch jobs or just want you to consider them. This is a great way for you to build up your library of resumes and also to find great talents you might have missed.  

OK, I’ll stop here today, watch out for part 2 where I go over the list of ideas and actions for finding the best fit and what to offer them.

Stay safe, stay home, we will win against this coronavirus.

Further Reading

1. Blog: Joel on Software https://www.joelonsoftware.com/

   Joel Spolsky’s writing in this blog has inspired me to do a lot of experiments at Kaz. Many of my greatest hits come from here. But many of his ideas failed badly too. Whatever the case it’s are a must read if you are in the software world. And some of his ideas work for pretty much any domains. Really good read, sadly he doesn’t write anymore on the blog.

2. Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent

   Book version of his blog on topics specifically about hiring. Perfect thing to have when you want to quickly check some ideas.

3. Building Great Software Engineering Teams

   A book that I’ve used a lot for tuning my interview process. Not so sure about the rest of the book, but chapter 7 & 8 are superb.

The cookbook for a hearty company

Staying at home when there's a beautiful day waiting just outside the window is never my thing. But that's my reality, our reality, now with this coronavirus in the air. I woke up this morning and decided that now is my only chance to write that little cookbook I always wanted to write. A book that I wish I had when I started my company sixteen years ago. A handbook that would not be a lot of theory but would give me clear actionable ideas for creating a great company, that is compassionate during good times and resilient during bad times.

When I started my company, I assumed that there would be a bunch of books like that telling me what I needed to do to make such a strong company. Like a cookbook that I follow to make a hearty soup, I would just follow the recipe step by step and end up with a hearty company. A place where people would actually love to work. A company built to last.

My hope of finding such a book was not unexpected. As a software developer all my life I was used to "missing manuals", "cookbooks", "cheat sheets" for learning a new technology and getting things done quickly. I was extremely surprised to find that there were no such "cookbooks" around. Sure, there were great books on teamwork, about company culture, HR or organizational behavior, even software teams but none that would cover the wide range of issues that a new entrepreneur faces every day. None that would give her the answers to her questions quickly and with facts and data to support those answers when she needed the rationale. The fact of life is that when you are in the whirlwind of creating a new business you just do not have the time or energy to read through and assimilate theoretical books about company structure or project management. At times like those, you want, just as I did, a cookbook that just gives you the steps. You want someone else to have read through, try and test all the theories and just let you know what worked, why it worked and what you should do if you want it to work for you.

I didn't have that.

I had to, just like millions of others before and after me, plod through with whatever I knew, whatever I could read up and whatever my mentors could tell me. I made a lot of mistakes and learnt from them. But I also did a lot of things right. Today, Kaz is a company that is widely admired for its workplace culture, for the quality of our work and most importantly for the bond between its people. I am happy with what I have achieved. Yet I feel I've lost a lot of time doing things that others before me have done and failed. If I had only known, if I had that book I would have been miles ahead. I could've achieved even more in this time.

So that is what I want to write. That missing cookbook.

I want my handbook to be exactly the way I wish I had it. In each chapter I will start with a section - Ideas that will be the summary of the principles that matter and the actions you take to fulfill that principle. This would be what I'd have used when I was on the run and just wanted to quickly check what I needed to do in a certain situation. A good example is:

Idea: People need to feel safe to feel trusted.

Actions:

• Place the seats where there is a wall at the back and someone can only be approached from the front.

• ...

I will then have a section to explain those ideas properly - Explanation. This is for when you have more time to understand the rationale behind the ideas. This is where I will try convincing the reader why these ideas matter, why they work. I will share my own experience and any data I have to support the idea.

And lastly I will have a section for further reading - this is for people, like me, who are always skeptical about anything they read and want to form their own opinions (when they have the time to read up!).

The hearty company

Let me first define what I’m trying achieve, what do I mean when I say a hearty company.

The hearty company is an organization which has the following qualities,

• Happiness: a hearty company is an organization where the people are happy to work. Happiness starts from the point where an employee feels excited and happy in the morning to go to work. It continues in her experience in working on projects at the company, in her conversations with her colleagues, in her interactions over the digital space. Happy is the workplace where the employees actually bond outside of the company's time.

• Resilience: a hearty company does not break down during bad times. It's easy to be strong when the business is good but being able to survive when the business is bad, when resources are difficult is the biggest test. That is resilience and it is the biggest insurance that a company has to survive hardship.

• Strength: a hearty company is strong. It has the strength to take on new challenges, it is confident that it will deliver and it will always win. You see that strength everywhere you go within the company, in every conversation you have. People feel like they know exactly what they are doing and what they are supposed to do. They feel they and their team has the ability to pull anything off and they have control over their work.

• Fearlessness: a hearty company is fearless in it's actions. It can change directions quickly and move to new things and take up new challenges. People in such companies brag about how open and relaxed the work environment is. How they can voice their concerns without worrying about repercussions. You don't hear that there are political struggles going on in such organizations.

• Flexibility: a hearty company is not rigid about it's rules and modes of operation. It knows that there are no perfect set of rules that a company can run by and it knows that rules that worked in the past may not work as the time and context changes. So it adapts, adjusts and transforms itself without a lot of red tape. The changes it makes to itself can also be to adapt to the changes in the business landscape.

• Pride: and at the end a hearty company is proud of itself. People feel good working at the company. They feel good to tell their friends and family what they do and the company they work. They share with pride how they are different from others around them.

The recipe

The secret to a hearty company is simple.

A hearty company is made of just four ingredients in equal amounts. Get those ingredients right, get them balanced and you are guaranteed to get great results. It is at the end one of those recipes you just can’t get wrong if you have the ingredients right and do the steps right. It's been proven time and time, over hundreds of thousands of companies all around the world. There is no need to reinvent the wheel, no need to do a doctorate in organizational behavior. Just follow the steps to make sure you've got the four ingredients covered and you've got a winner.

So here are those ingredients.



In the rest of the posts on this thread I'm going to go through each of these ingredients and give you the exact steps that you need to take to make sure you have the full portion of that ingredient in your mix.

Looking forward to meeting you on my next post where I start with my favorite ingredient Passion.

Stay safe in these uncertain times. Stay home!

10 Tips for effective work from home

We started work from home from last Thursday (19th March 2020). An adaptation with the new reality of the COVID 19 pandemic that wreaking havoc. This is a new mode for us, we’ve never had work from home option since we strongly believe that software projects need a lot of collaboration that is always best when the team sits together. So the transition was difficult to imagine, we made all kinds of plans to ensure that we had an easy transition And the result is really amazing. We moved to being a fully on site, face to face interaction organization to a fully remote working from home and through digital interfaces organization overnight without a single issue. We had our facilities and IT teams on standby for any emergencies, and the only big emergency they had to handle was shipping a beloved chair that developer wanted at home! So this is wonderful news for this #stayathome world.

After spending a few days in this work from home mode, I’ve been collecting suggestions and advice from everyone. There are some great articles online too about staying productive while working from home. I’ve summarized here the top 10 tips from our experience. Hope this helps someone out there…

1. Setup the IT stuff first

Whatever profession you are in you are probably using your computer to access your work and collaborate with your co-workers. And if you are like us a bunch of software developers then that computer is probably the most important thing in your work life. So getting the computer and related IT things sorted is the first priority to be an effective remote worker.

Not having any computer or internet connection is enough here. You absolutely MUST have the correct one. Make sure your computer has the right hardware to compile your code fast enough or generate those cool 3D models, etc. The next thing on the list is the fast internet connection and checking that that work with our office access points.

2. Set a fixed space at your home for work

Productivity to a large extent is also a mindset thing. When you go to work at an office building your mind sets a switch that changes your mind to a work mode. This does not happen so easily when you are working from home. So setting up a specific space at home as your work place helps to tell your mind that you are now at work. Sounds weird, I know, but it works like magic.

This doesn’t mean you need to create an exact office like space in your house with bland furniture but just to have a space at the house dedicated for work goes a long way. It’s important, obviously, to keep that space in quiet part of the house and ideally it should have a door that locks.

3. Have a fixed work time

When you are at home it’s hard to stay focused on the work when there are distractions that take you away from the work at hand. This leads to you working beyond your usual working hours to finish off the tasks. If this happens often soon it becomes a habit and you find that your work time and your personal time are blended together and you can’t really be focused on anything. This is a real problem that you need to be aware of and address fast. Set yourself a fixed work time, make sure you work within those hours without getting distracted. Stop working when that time is over and leave your designated work space. By leaving your work space you signal your mind to switch off from the work mode. Remember working from home just means your work space is at home - work type, time and process should remain the same as working at the office.

4. Plan your work day

Working from requires good work plan for the day and the discipline to stick to that plan. Structure your day by working out which tasks are the priority and the number of hours you are going to spend on each task. Also routine in your days about breaks, lunch helps structure your day at work at home. It’s important to set some rules that you would follow to stick to your planning since it’s very easy to stray from you scheme when you get distracted.

5. Communicate more than ever

The biggest negative for working from home when you are part of a team is that you don’t get to easily reach out to people, see their expression or hear a conversation that can help you. You address this negative by using technology to fill in the gaps. Use chat/voice tool like Skype, whatsapp, even Facebook messenger to stay in touch with the rest of the team. Reach out to them as you would if you were in the office. Setup some rules about what to do when there is an emergency information that you needs to happen as opposed to a something that can wait. Face-to-face and voice interactions are very important, you should do video calls as much as possible. This helps set the mindset of working and also seeing facial expressions has a huge impact on conversations that we don’t always think of.

6. Be transparent about work

There is no need to hide from your team members or your lead if you are lagging behind on something. This could’ve happened just the same if you were at your office desk. Just because you are working at home doesn’t mean you have to be perfect all of a sudden and no one assumes you slacking off at work. Communicate any problems or issue immediately with your team mates or your lead or Clients just as you would have if you were at the office.

7. Monitor your work

When you are working from home it might sometimes be hard to know if you are being effective at all as you don’t get as much feedback from other members of your team. This is where tracking your work becomes important, tracking leads to monitoring and it tells you how much progress you are making. There are many apps for tracking your work which helps monitor your progress. These keep you accountable and more productive. Once you have some data you can actually review your work and see if you are prioritizing at the right places, working according to the schedule you set, etc.

8. Avoid Distractions

With no colleagues or managers around to check in on you, it’s easy to become distracted. You are usually your biggest enemy here, a doorbell ring might get you out of your developer’s flow when someone else could have easily opened the door. You can easily resolve this by setting some standards, ask family members not to ping you during working hours unless is absolutely important. Make sure you stay away from sources of distraction like the TV or the land phone. You family members will happily help you if you tell them you plan and ask them for their help. You just have to make the move.

9. Dress appropriately

Working from home may give you the feeling that you can be relaxed about what you are wearing or how you groom yourself. But dressing as if you are going to work at the office when you start work at home makes a huge difference to the mindset. You signal to yourself that you are shifting to work mode now. This helps immensely in getting you in the right frame of mind. And a side benefit is that when the video turns on you don’t have to hide!

10. Take breaks

Just as you need breaks when you are the office you need them when you are working at home. Slaving away at your code just because there is no colleagues to means you’ll get tired and the quality of your work will suffer. Breaks are needed for a refresh, for a reset and has nothing to do with your work settings.

OK here are some stolen gems on work from home from Dilbert!

Adapting to COVID 19 reality

The COVID 19 pandemic is creating havoc all around the world. We have be relatively lucky in the Bangladesh, there hasn’t yet been a major spike in cases. But as with all other places it is very likely to increase, we are all worried.

It’s proven over and over that “social distancing” the right approach for stopping the spread of the virus. An excellent read with very visual proof of this is a recent article in the Washington Post: how to flatten the curve.

At Kaz we started working from home from today. This is the first time the whole office went into working from home mode so it is a new experience for us. We’ve been working hard to make the transition absolutely smooth. Here’s how we are doing it.

Support in setting up home work environment

Our tech support and facilities team has been busy last few days helping developers setup work quality environment at home. This includes making sure the PC at home is fast enough (if not we are supplying them with their PC at work to home), the internet connection is good, VPN setup works, etc. Being a software company most of our people have a great computer at home, that helps, but it is not always setup for professional development work. So that means we have to ensure that it’s virus free, has the right IDEs and other tools setup, etc.

Work environment is also the physical environment at home. The place you work should be in quiet part with as little distraction as possible. The chair and the table should be appropriate for the working hours. Our facilities department has been helping our staff with setting up such an environment at home.

On call tech support

We’ve assumed that right at the beginning we’ll have a whole bunch of tech support issues. So our tech support team will actually be at the office for a whole week supporting people. The support procedure we are following is we try to solve the issues online or over phone first. If that fails we would send one member of the tech support to the staff’s house to help out on site. We plan to continue this for the whole of next week and then the tech support team will also work from home.

Guardian for IT infrastructure

We have one tech support person who lives next to the office (this is by design, we’ve always ensured that a tech support person can at the office within minutes 24/7) so that means our servers and other IT infrastructure has a guardian while we are away.

Keeping the office space accessible

The office space itself will be accessible at all times during this work from home mode. This is possible as we have administrative staff living next to the office. We will have one member of the management and facilities working at the office next week to support any unforeseen issues during this transition. Beyond this the office space will still be accessible by our staff by calling our administrative hotline and arranging for an administrative personnel onsite to open the doors. This is essential, as there are likely to be situations where a developer might have to access her desk for something.

Recurring status check

We are introducing a regular status check on a team level. The goal of the status check is to make sure on a daily basis that everyone in the team has access to the resources they need. The check also works a health check on the working environment and the communications of the team.

Skype groups for teams, leads and all

We are using Skype as our main form of communications. This is because Skype was the common communications tools across the teams and it’s great for quick conversations and screen share. Every team has setup its its own group but the company also has setup groups to coordinate with the team leads, administrative staff etc.

That’s about it, I’ll update as we continue this mode and come across issues and solutions we use for those issues. Let us hope and pray that this great calamity that we are going through all over the world will be over soon and we will be back to normal. What a party we’ll be throwing to celebrate that!!

By en:Siouxsie Wiles, en:Toby Morris (cartoonist) - https://thespinoff.co.nz/society/14-03-2020/after-flatten-the-curve-we-must-now-stop-the-spread-heres-what-that-means/, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=88017093

Remote work - what could go wrong?

Amidst the global pandemic of Covid-19, software, and technology companies are thinking about their employees’ safety. Companies like Google, Apple, Microsoft, all have allowed their workers to work from home to fight with the novel coronavirus.

Not going into the specifics of the virus but more discussing the steps that software companies can take to protect their employees and still function as a business entity. One of the biggest advantages, specific to this situation, is to be able to promote “Social Distancing”.

But what that mean for the Software Companies. Companies where teams have to work with each other, interact, communicate and process together. Some of the biggest challenges that Project managers and team leads have to face could be:

Distractions

When you are working with people in an environment where it is more professional, there are fewer distractions. When you talk about working from home, you may not be able to avoid the distractions that arise. Interruptions from children, work, neighbors, friends, and family members may be very disruptive and special efforts must be made to make it known that you are working and unavailable for interruption within work hours despite your physical presence at home.

Distinguishing between home and work

The temptation to engage in household matters since you are at home is often very strong. Suddenly you may start to feel obliged to clean the home, do a little shopping, take a little more time with your child, do a little bit here and there around the house, and socialize. Not to mention the riskiest factor, “being a little lazy”. You must be able to draw the line between home and work to avoid both areas suffering.

Communication

Communication is the most to be affected, as concerned by the project managers. Teams will have to follow scrum and communicate between timelines to discuss their progress and determine the task loads. When you are working as a team and physically present in the same location, communication is easy and straight forward. Now think that you have to work where you have to communicate with all your 10+ team members on Skype. That seems more time consuming and loses productivity.

Maintaining a work schedule

Since no-one is looking over your shoulders or enforcing your hour strictly, you may feel tempted to work endlessly, or worse, try to skip a few minutes surfing Netflix. This pressure to work endlessly or without supervision may be compounded by the fact that you feel there are greater expectations made of you as a home-worker or by self-imposed pressures to prove yourself and your abilities in this arrangement. Moreover, the lack of physical separation between home and work may add to this pressure to work endlessly or supervision.

I’ll finish with WC’s tradition of using a Dilbert cartoon :) Stay safe in these uncertain times and let us all hope and pray that this will be over soon.

How to manage difficult software developers?

Software developers have a reputations for being “difficult”. But from my years of working with literally hundreds of developers I know that what is considered “difficult” is just a wrong way of looking at things. You can completely change the interaction and behavior of a “difficult” developer if you just adopt a few easy changes in your thinking and action. These “software people skills” are super easy and it’s really painful to see how many project managers or team leads don’t these. I’m going to do a series of software people skill going over them one by one. These are skills that are extremely easy to learn yet effective right away.

Instead of my usual of just listing them out, I’m going to make this series more hands on. I’m going to pickup pieces of conversation that are common between a manager and the “difficult” developer to show you the scenario and show you how you can completely change that conversation. You’ll notice that the manager will always be reasonable in his requests in the scenarios I talk about since I’m not talking about irrational or abusive interactions.

OK, to my skill #1

Software people skill #1: Always criticize code in private

Scene: Mr. Dev is in front of the his computer, Mr. Manager is standing next to him staring at the computer and speaking while pointing to the code. The last build of the product had some major bugs, most of the bugs on Mr. Dev’s area. Mr. Manger wants them fixed quickly so that they can meet the deadline (and also wants to air out his anger for the bugs hoping that the anger will make Mr. Dev create less bugs next time round). Other developers are within earshot.

Mr. Manager: Hey, there are way too many bugs in your part in this build. Can you please fix them asap so that we make the deadline?

Mr. Dev: You cannot blame it on me, I had way too many tasks, I told you they were impossible to finish and you are now seeing the result. So it’s your fault not mine and I’m not cleaning up your mess.

The mistake: Code is a developer’s craft. It is his creation, almost like his child and he will always identify with it. There is no way you can criticize his code and not get him emotionally affected and be defensive. And if you criticize in front of his peers and with his creation right in front of the conversation it is the worst you can make things for her. This will get you nowhere and will only make things worse down the line.

The solution: Know the sensitivity about criticizing a developer’s code. But that doesn’t mean you should not criticize or not take any action in the hope it will be sorted somehow. You just have to do it with some care.

• Make sure you have the discussion in a private space away from the peers of the developers. Ideally your office or a meeting space with the door closed. The developer will appreciate your care about keeping it private and also feel the importance of the need to address the issue.

• If the developer’s room is itself private, you should do the conversation away from his computer. This is purely from experience and a bit weird but there is definitely a psychological effect of receiving criticism right in front of the code that is being criticized.

• You should use inclusive language like “we” “us” rather than direct “you”. This gives the developer some relief that he is not the only one involved - because in a lot of situation he feels (and he might be right) that he was not the cause for the failure. Inclusive language moves the interaction to a feeling of working together to fix the issue.

• Softening the accusation a bit may help. This is case sensitive but the fact of live in software development is that people will make mistakes, there will always be some use case not thought out, some requirements will always be vague, etc. So once again if the language feels like you understand the complicated nature of a developer’s job, his reality of dealing with all kinds of unknowns and variables of a project, he will feel more understood and be less defensive.

Tech fights the coronavirus

The novel coronavirus that first appeared in China and it’s now all over the world, the current (9 March 2020) status is as below: 

Johns Hopkins Coronavirus tracker

The coronavirus is putting a lot of new tech, including robots and artificial intelligence, on display. The world of AI and robotics have made huge strides in the last few years and are ready for the challenge. This virus has become a test for the limits of the technology and also a proof that technology can help us win the war against global pandemics like the COVID 19.

The following is a quick summary of the highlights!

AI

The power of Artificial Intelligence (AI) has been shown during the initial phases of the coronavirus outbreak. AI flagged an early warning about the outbreak, and algorithms have been used over flight data to predict the novel coronavirus spread.

Leading in this field are the analytics companies Metabiota and BlueDot who use publicly available health data as the input for their AI engines. The Canadian company BlueDot, which runs “automated infectious disease surveillance,” alerted its customers about a rapidly spreading infectious disease by at the end of December, way before CDC or WHO started warning people.

BlueDot’s founder, Kamran Khan, explained how the company uses AI that leverages natural-language processing and machine learning, to track over 100 infectious diseases by parsing and analyzing more than 100,000 articles in 65 languages every day. Now, the same algorithms are used to monitor social media and other news content to detect the disease’s spread.

At the same time, the coronavirus scare has pushed drug companies to accelerate their research on AI based drug discovery tools. AI can be used on such platforms to find entirely new molecules capable of treating the COVID 19 related disease, or analyze large data of approved medicine that might also work.

Robots

With a virus like the COVID 19 that spreads primarily through contact robots are godsend. The robot tech of 2020 is at a stage where it can handle this challenge head on, for instance, in US a robot helped doctors treat a person with the coronavirus. The robot used a stethoscope and also was the conduit for communications between the patient and the medical staff limiting the exposure to the virus.

Chinese hospitals are using robots from the Danish company UVD Robots. These robots are specialized for high exposure risk tasks such as disinfecting patient rooms and operating rooms. These roving robots emit ultraviolet light over an area, killing viruses and bacteria, including the coronavirus. The robots are remotely controlled by a device operated by hospital staff.

Other uses of the robots have been more as mechanical beasts.

Coronavirus tips for software developers

With COVID 19 wreaking havoc globally I thought I should write about precautions that a particularly important for us the screen hugging software developers. I know this is horribly politically incorrect thing to say: but one good thing about software developers are that most of them are not that much of social being. Hence they are likely to go out less and expose themselves less :) Maybe all that will left of the mankind are a bunch of software developers after the virus finally leaves us - hmmm!

Anyway, back to reality, here are some things that software developers need to be careful about when it comes to coronavirus.

Be careful about surfaces of phones and monitors

In a recent study in the Journal of Hospital Infection found based on 250 mobile phones of hospital staff, that pathogens like coronaviruses can survive on smartphone glass surfaces for up to nine days. With the smartphone right next to our face a lot of the times and with us tapping on its surface all the time its an easy way to spread the virus. So make sure you clean those smart phones as much as you can and the same goes for those computer monitors.

btw, interesting trivia if you are into that sort of thing: A 2019 survey found that people touch their phones 2,617 times per day on average!

 Avoid touching your face.

Not sure if you’ve noticed, but a lot of developers tend to put their fingers on their face or fiddle with their hair when they are thinking (which is something they have to do a lot). Your mouth, nose, eyes and ears are all routes into your body for viruses. And your fingers are the most obvious part of the body that is likely to pickup the virus, so in effect the touching of the face is a fast way to transfer the virus to your respiratory system. This simple measure of avoiding to touch your face is very hard to maintain consistently, but is essential for infection control.

Skip those meetups

One big social event that developers really like joining are the tech meetups - both formal and informal. That’s an obvious thing to avoid right now. As with any large congregations you are just increasing your chance of exposure. Here’s where online meetups and skype call are great - you get all the benefits of the meetups yet don’t face the risk.

Avoid travelling

Many of us have to travel for work. To meetup with other teams, business teams or customer site visits. That would increase your chances of exposure exponentially. A sad example is the first coronavirus case in Bengaluru - a software developer who had to visit client site in Dubai.

OK, I’ll finish off with an ineresting twist on coronavirus for developers. With the huge interest and concern about the virus there has been a surge of software applications related to the virus. Take Corona 100m as an example will alert a user if they come within 100 m (328 ft) of a location visited by someone who’s had Covid-19. “The installs are increasing about 20,000 every hour," said Bae Won-Seok, one of the developers of Corona 100m.

New apps are coming in almost every day on the mobile apps stores for an obvious reason - there is a huge surge in interest. Apart from mobile apps there are some really cool web apps that tracks the virus. The best of the lot is by Johns Hopkins Center for Systems Science and Engineering that tracks the spread almost real time. The red dots are getting scary close to Bangladesh, btw :(

OK, I just realized I can never leave this post on a happy note, so I might as well give up. Stay safe my friends we have a lot more software to build!

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!

Cost of offshore software development for 2020

We are a software development consultancy based out of Bangladesh. One of the big reasons companies from all over the world approach us for software projects is the relatively lower cost of production in countries like Bangladesh. The risk of getting your software made by an external team located literally thousands of miles from you is always big. But sometimes your budget makes your options limited and selecting a good external software consultancy can keep the cost in control without taking too much of a risk.

A common questions we get asked how do our costs compare with the rest of the world. This is always very hard to answer because even within a single country the cost of software development varies by a considerable margin. Take US for example, even when you take a large sample and average out you get a variation from $20 - $80 for the same experience and skill set.

Source: How much do software developer jobs pay?

However knowing a ball park number always helps and makes your search for finding the right software consultancy easier. I wanted to share the result of our own surveys and googling today, this is a ball park chart we keep to share with our would be customers and also for ourselves too make sure we offer competitive rates to our customers.

Here goes, range of costs per hour (in USD) for 2020 based on regions where there are considerable software development consultancies. The costs are based on “blended” teams in mainstream technologies such as .NET/Python/Javascript development, etc.

Eastern Europe: $25 - $55

Custom software development rates in Eastern Europe vary by a very large margin between countries. For example rates in Ukraine are significantly lower compared to Poland.

The following chart shows the highest hourly rates in our data country by country:

Latin America: $35 - $50

Latin America is the fastest growing (CAGR of 5.84% over the period 2015-2019) software development destination currently with Argentina, Brazil, Colombia, and Chile leading the way. With time zones matching all major cities in North America the industry has a huge advantage over other offshoring destination when it comes to software projects originating in US and Canada.

We found the hourly costs to be on the relatively higher side during our research, the following shows the highest rates for standard tech stacks from only the large providers.

Africa: $15 - $35

Africa is emerging as a big offshore software destination with a young population set to double by 2050. In GitHub’sState of the Octoverse report, developers from Africa created 40% more open source repositories over the past year— bigger growth rate than any other continent. Morocco is leading the in this stats, but others are catching up. The following shows our data for highest hourly rates:

Asia: $12 - $50

Asia has a lead on the number of developers and companies that work on custom software development. India obviously is the clear leader but many other countries such as Bangladesh, Vietnam, Cambodia, Pakistan are also become major providers of offshore development support. Given the large number and variation in skills and maturity the very large variation in hourly pricing is expected.

The following shows the highest hourly rates in our data for countries in Asia:

Conclusion

There is a large number of offshore software development companies available to any company looking for new software partner. The most important factor for a successful software project at the end of the day is to find a good software partner. Software development rates will vary over regions, this is to be expected. But more interesting metric to follow is how the rates and skills change over time. An example is Bangladesh, which used to have very low rates about a decade ago but was also lacking in skills and experience. As the industry matured the resource on offer become more skilled and experienced and obviously that led to much better quality. Better quality leads to a growth in the industry as more projects starts feeding into the market. This obviously leads eventually to a rise in cost as the demand for the skill increases. Finding the optimal balance of cost vs. quality that fits a software project’s budget is the key.

Top 10 Software Product Manager Skills

This is part 3 of the defining products series. If you are still interested, part 1: 3 Questions to define a software product and part 2: Documents every successful software project needs.

Today’s article is about the skills and the daily task every product manager has to carry out in order to build a software product. If you have already read it, you will know that a product manager is a part of every stage of the product – design, build, testing and/or launch. Even if the product is an outsourced project, a PM’s role is involved in all the steps.

According to Josh Elman, a product manager who worked with Twitter, Facebook Connect, LinkedIn, Robinhood the job of a product manager is to:

“Help your team (and company) ship the right product to your users”

The only result any company expects from a product manager is the delivery of a great product. The qualities between each PM varies. And for these qualities, a PM can succeed or fail with their products.

Here are some of the best qualities to have in order to succeed as a PM:

1. Thinking Big

“The top 1% PMs’ thinking should not be constrained by the resources available to them. They’ll describe large disruptive opportunities, and develop concrete plans for how to take advantage of them”

— Ian McAllister, Director of Airbnb

Most of the times, PMs have to work with limited resources to produce the perfect product. For PMs it should be the first challenge to build their product. We all have to work with limited resources, but for a successful PM, the job can be done if he/she can utilize the resources in hand.

2. Prioritizing the list

PMs have to work with the customers constantly, even when they are building a product and also have to demo the features that are already been worked on. Gather feedback from the customers and put them to the list of features that will be done on an up coming cycle. They also have to test features that are being worked on in the previous cycles. Time is short for the whole cycle.

Good PMs know how to sequence projects. They can balance quick wins vs. platform investments appropriately. They should be able to balance offence and defense projects appropriately. Offence projects that grow the business, whereas, defense projects are the ones that protect and remove drag on the business. 

3. Speak with ease

PMs are the ones who talk to the customers, and/or users, to understand the requirements for the product to be built. Talking to customers will give you the best insights about what type of solution they actually want from your company.

Most of the product managers think their customers “don’t know what they want”. But successful product managers know, “customers may not know the ideal solution to their problem, but they are experts in their problems”. They can always describe their frustrations. The top 1% PMs knows how to guide their customers in to understanding the right solution to their ideal problem.

As the product manager, you are the voice of the customer within your company. It’s your job to have an intimate understanding of your customers’ needs, so you can effectively advocate for a solution.

The shortest route to deep customer knowledge is talk to them directly and in plain context, not too much techie not too much business. Take time to get to know your customers. You need to be able to get in to the heart of the value they experience in a way, as if, you are facing the problems yourself.

4. Have know a few more things

As you may know by now as the product manager you have to work multiple teams to develop a product, meaning with techies, designers, testers, customers and analysts. You will have to understand the language each of these teams are talking with. But it doesn’t necessarily mean that you have to be a coding wizard to talk to a software programmer. But having a certain level of technical proficiency will make it easier to talk to them.

A few tips to keep in mind:

• Don’t be afraid to ask question. If don’t understand something, don’t hold back. You can’t support the team or offer solutions if you actually don’t understand the situation.

• Pay special attention to technical limitations. The most common sentences you will hear on the coding side, is that “it’s not technically possible” and “it will require more time to build”. A relation between a PM and an engineer is to debate on how long certain tasks should take. As a PM, you are responsible to set reasonable deadlines, and you have to be realistic about it. And I won’t forget to mention, it’s important to understand the dependencies and constraints of different technologies.

• Make an effort to build on your knowledge. While most engineers don’t mind answering technical questions, but it can also help you to improve your skills if you do your own research on the topic in hand. Most of the time, engineers are too busy to projects so asking them a question, that you can figure out yourself, will take up their valuable time.

5. Not to think too much of yourself

A successful PM is the one with the thickest of skin, rhetorically speaking. You have to keep the status quo of any situation to the product’s favor. Sometimes discussions can turn up the heat in any room. It is your job to keep calm and maintain the situation in favor of the product to be defined properly. As product managers, you have the control to shape the product, but it doesn’t mean you can do whatever you want because of arrogance.

Achieving that level Zen will help you to deeply understand your target users’ use cases and frustrations. As PMs, you are the advocate for your users and you have to represent their frustrations in such a way that your engineers can also get the picture.

6. Organized and consistent

Good time management is a basic skillset of any professional needs. But the top 1% of the product managers will take the best out of this skill, and it is very critical for them in the sense that they always have many different demands on their time.

Product managers have to touch so many different parts of the company. In nature of the job, PMs must be organized with their own scheduling and have to consistent when they are working with different teams.

Keeping you time organized in respect to your tasks will be more efficient. Stay focused with the schedule you have created and set tasks aligned to your core product management responsibilities first.

Remember to keep some time for yourself to regroup with your own work.

Priorities your meeting according to their importance. You should be able to reject meeting requests if you think its purpose is conflicting with your scheduling.

7. Able to understand feedback

It’s critical to be constantly changing that same vision or strategy in response to feedback from your users/customers. But this doesn’t mean you’re doing whatever they say. PMs are responsible for making decisions that affect tech, UX, design and business strategies. It’s unrealistic to think a single person will be the most knowledgeable in all these areas. To make these decisions responsibly, it important to ask for your customers’ feedback. Listen carefully to what they have faced in the build you provided them with. And humbly accept information that goes against your assumptions.

Remember, as a product manager, you are listening to their concerns hidden in their ideas and feedback.

8. Efficiency in UX

UX is the usability of any product and considers areas like interaction design and human-computer interactions. As a product manager, you can’t only focus your time and energy only on the business and technology elements. You need to be able to figure out and work with UX experts.

Keep yourself up to date with latest User Interaction (UX) technologies and practices in the market, and they change more frequently than technologies. A product manager doesn’t necessarily don’t need to be a product designer. But to be a well-rounded product manager, you really need to understand the underlying principles of UX. Having a greater appreciation of UX will enable you to make better and more informed product definition decisions.

A 1% PM is always thinking about how everything can be improved, not just the things in his/her domain. It’s a lifestyle, not a job.

9. Proactive

A good product manager is the one who can glue all the other teams together and keeps moving in the same direction. For this skill, you need to know where the team is going and the greatest sense of urgency about getting there. Successful product managers are proactive about driving action.

Often, moving forward requires gracefully managing competing interests. Staying on top of what’s happening, what needs to be done next, and where the team is encountering friction requires regular meetings.

10. Attitude to solve any problem

Product management is a complex role that requires deep domain expertise, commitment and mastery of myriad interpersonal skills. There is always more than one responsibility for one personnel. When you are applying for a job at a new company, you will see there is a huge list of job description that the company expects you to deliver.

But the most important skill and the primary role as a product manager is to have passion and the right attitude to solve any user problem.

Technical, communication and UX skills can all be taught – but every successful product manager brings their own passion for problem solving. Without this passion, you are just another employee with a title.

Conclusion

In conclusion, the top 10% of product managers excel at a few things. The top 1% excel at most or all of them. If you are a product manager, you may want to start building on these skills. Don’t worry if you haven’t mastered all the prerequisite skills. Bring your passion for making other’s lives bet

Hofstede's cultural dimension and software company culture

Geert Hofstede left us a few days ago (12 February 2020), I dedicate today’s post to this great thinker. His ideas has had a huge impact on our thinking about how a software company should operate, particularly in the cultural context of Bangladesh. We wrote sometime back about Geert’s cultural dimension and its importance for software company and how we at Kaz manage the power distance . In today’s post I’ll revisit some of those concepts and also look at it from a larger perspective.

Culture′s Consequences: Comparing Values, Behaviors, Institutions and Organizations Across Nations

By Geert Hofstede

Geert Hofstede

First a quick intro to the man himself. Born in 1928 he was a Dutch social psychologist who worked in IBM and was also a Professor at Maastricht University. He is well known for his research on cross-cultural groups and organizations culminating on his theory of cultural dimensions. His extensive research resulted in the publication in 1980 of his seminal book Culture’s Consequences. It was written for the academic world and made very controversial theories that challenged the validity of established theories in psychology, organization sociology, and management theory. A 1984 paperback edition of the book left out the base data and the statistics but was otherwise identical to the 1980 hardcover version

Theory of cultural dimension

The theory of cultural dimension is a framework used to understand the differences in culture in different countries of the world and to find out the ways that work is done in different cultures. In other words, the framework is used to distinguish between different national cultures, the dimensions of culture, and their impact for businesses.

The theory is based a study of 117,000 IBM employees. With this very large data set Geert showed that how we operate in a corporate environment is very much dependent on our national culture. And these culture dependent biases lead to business decisions, attitudes and at the end business operations and success. Hence knowing about the cultural dimensions, how to manage those for optimal business performance is of major importance for a business.

Power Distance Index

Of Geert’s cultral dimensions, the concept of power distance index the most important for software companies, we feel. Power distance index (PDI) is defined as the extent to which the less powerful members of organizations and institutions (like the family) accept and expect that power is distributed unequally. This is what defines how team members feel about voicing there concerns and having a say in the overall business process. As you can understand for a software development team this is the most important thing. If team members cannot voice their issues the overall software team starts becoming an authoritarian environment where the team leaders govern how things are done, what technical decisions are correct and what kind of architecture to follow. This leads to huge bias on technology, making it next to impossible to make software error free. Apart from the obvious effect on the work output the power distance has an important effect overall team culture and happiness. For a creative work such as software development not having the ability and the flexibility to work with your own ideas or getting put into doing things that you feel are incorrect lead to less job satisfaction which eventually leads to bad performance.

I recently found some great info graphics about the cultural dimensions across countries of the world. Here’s the graphics that shows PDI across countries of the world. I can relate with Bangladesh being so high up around the end of the spectrum. This is why we take so many measures to address this issue of high PDI and try to make it low.

Source: A Six-Dimensional Model of Cultural Difference

Experiment and evolve - the best way to improve software company culture

A Short History of Nearly Everything

By Bill Bryson

Experimentation in nature - Burgess Fossils

I am reading Bill Bryson’s (one of my all time favorite author) A short history of nearly everything and came across the discovery of Burgess Shale Fossils. These are fossils (literally thousands of them) that had been discovered in 1909 and scientists have been finding, categorizing and theorizing about them ever since. Even as late as 2015 a whole new set of fossils were found. These fossils are important not because of the sheer number (although that’s always welcome) but because of the extraordinarily preserved state of soft bodied organisms and the extremely wide variety of them found together. They show amazing body shapes and structures that seem to have been completely lost in later ages.

Burgess Shale Fossils

The great biologist from Harvard Stephen Jay Gould wrote an amazing book Wonderful Life in 1989, and made Burgess Shale fossils famous. He suggested in that book that the diversity of the fossils indicates that many of the unique body types were just evolutionary experiments that became extinct because those “models” failed. If you look at the completely out of this world weird nature of the shape and structure of the life forms in the Burgess finds, you’ll probably agree too. If we try to fit it with a modern day design success: it’s as if, instead of hiring the legendary designer John Ive , Steve Jobs just asked his engineers to come up with randomly designed iPhones in millions of different shapes and waited for the best one to come out from that.

Wonderful Life: The Burgess Shale and the Nature of History

By Stephen Jay Gould

Experimentation in the organization

Reading this made me think how an organization’s culture has strong similarities with this idea of random experimentation and evolution. There is almost no sure shot way of making an organizatiio’s culture be good. There are obviously a lot of commons sense ideas and historical facts about what works and what doesn’t. But exactly what steps, behavior, formal and informal rules and policies will work for a particular team in a particular context and in a particular industry is very much a chance thing. In the software space, culture is extremely important. So this is as important a concern as say skills of the team. Yet without any strong process and guidance most companies just seem to gamble away at the culture issue. A lot of the times it’s just how that company picked up the first set of hires or how its CEO thought the world should be. But always pretty random and the success very much given to chance.

I think one huge thing that most companies miss out is the possibility of experimentation. Think through and try out controlled experiments on culture change. See what the results are. Discard if that particular change is bad and keep if it has hope. Just like the Burgess fossils keep changing the models and let the effects decide what stays and what doesn’t. I see most companies staying rigid on culture - “this is how we are”, “this is how it’s always done” etc. I know that for the management, however progressive they are, not having a tried and tested best practice means it’s hard to decide, so they just decide on something and stick with it. Yet I think for fluid and intangible thing like culture staying rigid is the worst thing possible. If the experimentation is allowed, even better if it’s planned and executed there is much higher chance of reaching a better point where culture fits the team and company’s goals the best.

Just as the Burgess fossils must’ve been weird (and wonderful) life that led to much better and yet more sophisticated life forms - experimentation or more importantly allowance for experimentation will lead much better forms of culture at your company. And that’s of vital importance for any software company.

Why software startups fail?

Did you know that most software startups fail?

Yet majority of the startups that fail actually have great business ideas. Take the failed startup Kettlebell Kitchen for example (shut down Nov 2019 after 11 years of trying). If you think about their idea it sounds fantastic - people want to eat well or use a particular diet -> It’s hard to maintain it yourself -> use the software to receive meal kits based on nutritionist’s advice and stay on the program. Takes on the restaurant/food business as well as the health and fitness industry in one single idea.

Yet with more than 30 Million in funding, 11 years of coding (and I’m guessing struggle) we have a company that has always lost money and is now dead. The end result is an email to its customers:

But why do software startups like Kettlebell fail?

That is a fair question. And after helping startups for the past 16 years we have some idea about what works and what doesn’t. Let me try answering that question today.

But before I do I’d like to share an amazing study done on 339 failed startups (and counting). There is so much to learn from these stories and after finding this I ask all my new startup customers to read through them. In entrepreneurship failure is the key to making it big, you fail, you learn a way of not doing something and you move to the next things slightly better at what you do. And what better way than to have a list of why and how others failed - it’s almost like a shortcut through the fail -> learn -> success route (although I think there’s no shortcut in that game :( ).

Source: Top 20 reasons startups fail

OK, back to my original question about why software startups fail and also how we can address that reason. I’d like to use another great article from the same data set where the researchers have tried to go through the stories and pin down the reasons and create a graph of the reasons. I share that on the side to give ourselves a reference based on data. I list our own list of reasons from our experience below, some of which map pretty well with the graphic and some don’t that much. But it’ll give you food for thought.

Forgetting the main goal of a software

Every successful software platform solves a particular pain point. Even Facebook solves a problem (creates others on the way though :) ) of staying in touch with people busy in their daily life. The success of the startup depends on how well the pain point is solved. Many startup founders lose their way during the build out process of a startup and start trying to solve too many things at once or sometimes imaginary pain points that has no use. Having a clear goal about the pain point that the software will solve is essential for startup success. This maps very much to the #1 item in the list above “no market need” - since not solving the pain point leads to exactly that.

Spending too much too early

No one has the crystal ball to tell the future and no startup founder knows what will work and what will not. You have to start with a hunch or a niche and then figure out how much of your initial idea actually was useful. So spending most of your budget on the initial idea, without leaving enough for the changes that need to be made for sure down the line means that the startup never gets the chance to meet the need in the market and dies. Again this maps well with the #2 in the data - “ran out cash”.

Obviously if you plan well you can make your money go a long way and get more out of it and thus get more done all the way through. Being smart with money is the most essential skill in startup leadership. KettleKitchen in my example above died after burning through 30 million in investment and millions in revenue it was earning itself. The fact that it survived for 11 years mean it had something going for it, lack of money management is what killed it.

No wonder a lot of smart startups use software teams like ours to keep their cost in control. They can dial up or dial down the cost as needed as they try things out in the market place. And using a company like ours which offers great rates because of the fact that we are in a low cost country makes a big difference. One of our all time best service product is the “Launch under 10K” we offer to startups.

Getting a software team that’s not a good fit

This is a big one. At the end of the day, whatever idea you have, however much focused you are about your goals if you don’t have a great software team that fits with your work culture and your way of doing things your startup will always fail. So if you are hiring, spend a lot of energy in the hiring process, since you’ll be stuck with this team forever and you make and break based on this team. If you are getting an outside company like us to make the software for your, spend time to find out if the outside team is a good fit for you and your product (and not just the price they are offering). Check out our great little post about this topic: How to select a software vendor?

This is #3 in the list based out of the stories above.

Not having a price for everyone

Every restaurant you go to you’ll see that they have a range of prices. Why? Because they don’t want to turn customers away just because it’s too pricey (or too cheap!). Same for software products, not having a range of options to fit different software budgets is a common mistake. Remember you can always upsell but getting the user to try your product and get to know it is a big deal for an unknown new startup. So have a range of packages, and always, always have a way that the user can try it for free - maybe a free 14 day trial, maybe a free basic edition. That’s essential to remove the barrier of “I don’t want to spend without know if this is what I need”.

Waiting too long to get the “perfect” first product

This is the other big one, especially for first time entrepreneurs. They just won’t release something that’s not perfect. Perfection here is what they have in their mind - an unattainable beast formed out of a hundred other software that the founder has seen, a mixture of Steve Jobs and Bill Gates videos about how software should be and sometime even a book on design. Waiting too long to release your product is sure way for death in this fast paced, fickle reality of the Internet, short attention span and crowded app producers. You just can’t wait, and not only because you want to get things out before your competitors do (or before your marketing message is lost) but also because you need to experiment and find out what you need to change, what you’ve got wrong. Release early, get feedback early, release often.

Not giving enough thought about your UX

With the wide choice out there for users sometime it takes a single bad interface element to put your customers off your product. If startups focus only on the engineering or the features and think of UX as an afterthought thinking that the utility of the software is enough to make it big they are making a big mistake. No software is that important or essential anymore in this world. Sometimes you’ll find great startup success stories that just had very little features at the beginning but good user interface to attract and retain people as they put the features in gradually. I remember using Hubspot when it first came out and thinking it has nothing but look at it now as a business. User UX and that includes the onboarding makes for a successful software startup. Read our UX cheatsheet for startup founders.

Jumping in too early

“Unfortunately, the VR market never developed as quickly as we all had hoped, and we were definitely ahead of our time. As a result, Vreal is shutting down operations and our wonderful team members are moving on to other opportunities.”

— Founder, Vreal

With all the hype about the “first movers advantage” many startups feel that it’s never too early to start something new. Yet from our experience you can always start too early, it’s actually hard to be too late! When you are too early on a technology you might have spent up all your budget before you see any revenue, or adopt users or even get any media interest. Take this quote from the founder of a VR startup that failed, Vreal

It’s much harder to fail because you came in too late. Coming in late means the technology and the mass users have ready to accept your product. It’s easier to find what others have made mistakes on and get your product to be launched without those mistakes. It’s easier to market too. Sounds weird, but it’s true. This is why Facebook wasn’t the first social media mover, it’s why Lyft and others still make it with a fight with the uber elephant in this space.

OK, I’ll finish today or this will start getting boring. I’ve put in my top ones above. There are other smaller ones, but if you can fix the ones above you are on the way to success. Starting up a new software business is the most exhilarating and fun thing in the world. Do it! I wish you all the best!

Our top tips for startup product strategy

During the past 16 years (and counting) of our work with hundreds of startups and small businesses we have come across a lot. We’ve seen single students starting with almost no money but amazing skills and dedication make a simple idea become a great success (with a little help from us). We’ve also seen very senior and experienced groups with loads of money with really good software idea fail miserably (and taking us down with them).

Startups represent about half of our everyday business. So they are super important for us and we just love working with them - for the energy and optimism they usually bring, for the quickness in their decisions and the cool technologies they work on. But every new startup we meetup we try to warn them about how difficult the path in front of them are and share our ideas about survival and things we’ve learn works really well for startups. We’ve written about many such tips in the past, here’s a popular one about 5 things that the founder should keep in mind One thing we see a lot is that many startup founders are all over the place about product strategy - how they are going to put up the product, what should they focus on to bring in more customers, etc. Here’s a short list of such strategy advice we share with our customers. These are tips that we know works 100% of the time…
 

Make sure you know the pain point you are solving

Every new technology is (or should be) to solve an existing pain point. If there is no pain to solve, then the new technology and startup that is making it will fail. So first make sure there is a pain point that your solution solves and know it well. That should be the sole focus of everything your software does.

Keep things simple

Your software will be new to users. It’s interface and probably all of it’s features are likely to be alien to every user you manage to acquire. If you don’t keep things simple you’ll lose them fast. Don’t hide your features in complex interfaces with features after features. Show them one thing that you do well (your pain point solution) and only show that. Things like simple UI, obvious CTA buttons, easy to organize dashboards can make or break your software business.

Offer different levels of subscription

Making packages that are modular or subscriptions that offer features that expand upon the base level, allows your software to cover a variety of budgets. You should always, ALWAYS, offer a trial or free level so that the decision for the initial buy is without any barrier.

Offer integration with other applications whenever it makes sense

Your software is not the only thing that your user will use. Your application need to talk with other applications that your user will use. At the very least there should be an export feature of the data. Without the option to integrate or with the fear of locked down with a particular software most new users will decide not to buy.
 

Consider additional services

Always consider if there are any non software services you can include for added value. Things like 24/7 support, or initial customization, or free setup will give you a big leading edge. They sometimes become the reason why customers will take your software instead of your competitor’s.
 

Plan for a great customer service

Ultimately, one thing you know can set you apart from the competition is great customer service. Offering ways to interact with customers, answer questions and guide them to new solutions is a sure way to retain customers, and get new ones via word of mouth. You’d be surprised as to how many startups in out there think of customer service as an after thought (or sometimes not at all) - yet it’s usually the cheapest HR cost in the budgeting.
 

Analytics and data will help you show the right direction

For any new software it’s hard to find out what needs to change to make it better. The hard way to find this out is give it enough time to fail and let your customers complain and leave. A much easier way is to setup data analytics to keep track of the metrics and act on them. Setting up things crash analytics, google analytics for visits, on page statistics are extremely easy and usually takes less than 1% of the full effort of making the software, yet they are extremely important for the survival of the startup at it’s early days.
 

How soon to start coding?

Today’s post will be slightly different from my usual them of “life and times of a product manager”. And it was inspired by my daughter.

The picture above is of my daughter when she was about 2 years old. She started drawing on the walls of our house with her crayon set. Her artwork was absolutely gibberish to us, but she explained that there was a car and a baby shark in her masterpiece. We understood that she has own creative thoughts and her own language and appreciated her uses of different colors.

In the digital age, whenever we hear the “Codes”, we understand the computer languages that we use on a daily basis but don’t mostly understand, such as C, C++, Java, PHP, Swift, and many more. Whenever we hear the phrase “Coding”, we imagine a person sitting on a chair and writing gibberish on a computer screen comes to mind, with years of practices and a college degree.

Similar to a programmer’s code will look absolutely gibberish to you once you see the code below. Fun fact it is a part of the backend of Google search. 

Interestingly, coding is not just about learning a computer programming language and how to write lines of codes. There are so many advantages of coding that support the development amongst growing children.

“I taught myself how to program computers when I was a kid, bought my first computer when I was 10, and sold my first commercial program when I was 12”

— Elon Musk

Advantages of teaching coding to children

Creativity and logic building

Learning to code allows the coders to be creative. Coding also helps to apply different logics to solve a single problem. Learning to code at an early age allows our growing children to be more creative and this can benefit them to apply their creativity to solve an issue. 

Makes a team player

Students get the opportunity of building projects as teams. They have to communicate with each other and this can also help them to get involved in project management in an early age. Project management can help with communication, compromise, discussion and negotiation between the players.

Influence to learn more

Allowing your children to solve an issue their way influences them to learn new ways, and logic. In a way solving one issue gives them more opportunity to learn new things. This also allows children to learn patient and observant.

The ability to understand and share

It highly in children, when they learn about something, they share with you and other. This improves their communication skills and develops them to understand different situation. Sharing also allows them to improve their presentation skills.

Boosting confidence

Once they get to solve an issue, their confidence is boosted to try another issue solving. This way you an introduce to learning materials for them to look into.

How to teach your child coding

It not going to work if you give your 2 years old a book on Java programming for Dummies. But there are a lot of materials in your time that can help them to learn more about coding.

Using Toys

I tried something like this on my daughter when she was just old enough to stand up herself.

A very simple toy to start learning about logics. It took her a long time to get it right but she did. After this we tried the ones with the Alphabets and this allowed her to learn to put the shapes in their rightful holes faster but in the process, she also picked up the English alphabets as well.

Now that she just turned 3, I came across this toy called “Code-a-Pillar”. This toy allows kids from 3-6 years of age to learn about directional logics, solving obstructions in the path.

But with toys, you can allow your kids to learn about coding and other materials faster and they have fun in the process.

There are so many toys available that can help your kids to learn coding at a very early age. The next device I am interested in looking in to is called Cozmo, a robot that listens to you and builds structures with blocks. Face it, I am more interested in it than my daughter. The point is there are so many toys that will allow your kids to learn more than just pushing a car or just dressing up a doll. I read this article and this helped me decide the type of toys that I must introduce my kid. Please give it a read.

https://www.gearhungry.com/coding-toys-for-kids/

Programming languages

I have seen my cousin influence his 5 years old learn programming in a fun way. He used Scratch, a programming language designed by the great minds from MIT specific for kids. Using scratch, I have seen my nephew design a game. And he used logics very creatively that we have to brainstorm for days, at this age.

Arduino, the world’s leading open-source hardware and software ecosystem, is also involved in creating kids smarter and more involved in coding. They have projects those which they have designed for kids to enjoy and learn with, please give this a read as well, Arduino Kids.

There are so many resources out there, like Python, Blockly, JavaScript, Lua (Roblox) and more programming languages out there those which are tailor designed to get the attention of children. Give this article a read, Top 9 Kids Coding Languages of 2020

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!