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!

Talent is everything in software

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

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

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

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

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

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

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

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

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

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

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

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

Talented team -> Great implementation -> Success

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

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

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

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

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

Do not disturb a software developer in "flow"

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

— Joel Spolsky

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

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

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

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

Don’t ask a random question

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

Keep developer rooms silent

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

Open offices are bad

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

Optimize meeting start times

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

Self discipline goes a long way

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

5 UX rule every software founder should know about

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

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

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

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

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

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

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

2. Hide your “ejector seat lever”

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

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

About Face: The Essentials of Interaction Design

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

3. Fewer is always better

GoodUI

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

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

4. Progressive disclosure

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

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

5. A clear primary action for every interface

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

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

An easy way to inject energy in your team

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

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

Making a young “alt tech lead”

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

Giving younger members leadership on events

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

Giving junior staff a forum to voice their ideas

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

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

How to reduce the cost of making a software?

As a custom software development company a common question we get asked is about reducing the cost of development. Software development is expensive. Even using relatively lower cost countries such as Bangladesh or Cambodia, a startup owner is likely to spend the largest portions of her funds on making the software. Yet software is only a piece of the story and usually the one of the first ones, huge costs waits for her in marketing and sales that she has to budget for. Hence cost optimization and reduction is an important strategy for the software development, and if done right can be a deciding factor for the success of the startup.

Here are some strategies we suggest to startups (and even established and large companies) to manage, optimize and reduce their software development costs:

Use an outside development company

Salary cost, particularly development salary cost takes up the largest regular cost of a company. An in house software team is invaluable, there is no question about it but when budgeting becomes tight, using an outside development team that can be dialed up and dialed down on short notice is the single best move a company can take. This gives them immense flexibility to adjust and control the cost on a regular basis and defer the risk of financial commitment of an in house dev team (which I think is essential once the software and business is established).

Source: Inc article

The graphic here shows the social sharing and marketing company Buffer’s average monthly costs. Thanks to Buffer’s open book policy this information is available for a live 7+ million dollar annual revenue company and will give a rough picture of how the costs are laid out. As expected about 69% of cost is spent on salary (for 64 employees when this data was taken).

In case of this example, the company has already produced its flagship product. The initial time when the product was being built would incur a much larger cost. For many software projects and startups this initial injection of fund can a big problem or might lead little or no funds for the marketing effort that will follow the launch of the product.

Finding good software development vendor and utilizing that vendor in an optimal way can give startups a huge edge over its competition yet keep the overall flexibility in its business operations.

Advancing the project tasks by non developers

Many software project tasks can be done in house by the founders or members of the existing team. Getting these tasks done would mean that the total effort by the software development team (in house or outside vendor) would be reduced. This leads to higher productivity for the team and obviously less cost per feature.

A great example of project tasks that can be done by a founder herself (or non developers in the team) is the creation of initial product ideas and wire frames. Sometimes founders approach dev teams just a list of ideas say in an email, this means the development or product team has to work to turn those into usable specification. This requirement analysis cycle can be quite prolonged if the founder or key stakeholder hasn’t fleshed out the ideas well and has to go through prolonged sessions involving members of the technical team or the outside vendor. The whole process can be fast forwarded and compressed if the founder can think through the ideas and use an easy to use mockup tool (our favorite is of course balsamiq ) draw out the ideas. The whole requirement process then gets cut down by as much as 80% in our experience.

Non development stakeholders and founders can also help out on many other areas of the software development process like testing, helping with documentation etc. All of these add up to create substantial reduction of costs for making the software.

Keeping the requirements stable

One of the biggest way of increasing cost of a software project is feature creep or constantly changing requirements. When a software development team has a clear specification it can plan and implement the features at a very fast pace. But as soon as those initial specifications start changing or new features start creeping in (because “business demands it”) the cost of rework and changed priorities will also pile up. Over time this single cause lead to cost increases by 100-200% if not controlled in our experience. So this is a single big area to be concerned about and control to keep the cost of software development under control.

8 top tips to save your team from burning out

Teams burning out because of a too much work load is a common story in the software industry. Yet if you take some easy measures you can easily avoid this without reducing your team’s productivity (actually increase it sometimes). Here are our top 8 tips that has worked for us and our customers over and over:

1. Manage the workload (obviously)

When the work to do fits with capacity, the team can effectively get their work done and still have time to rest and recover. Remember that a team’s time is not just about the task list, it is split between work in hand, coordinate and communicate, their need to take breaks, their need for professional growth and development among others. So your balancing act between the business’s need to get things done with a deadline and the team’s ability to take on workload has to be much more than a spreadsheet or a fancy project planning device. Apply your EQ and your IQ to find that balance.

When you fear your team’s burnout remember you can always say no - read this superb article on HBR to sharpen your skills of saying no - 9 was to say no busywork and unrealistic deadlines.

2. Let your team have work-life balance

We sometimes burnout when we focus only on work. You as the leader drive that focus. If the life of a coder is to sleep only a few hours and be back at work, with barely any engagement with rest of life that coder will only go down the path of burning out. Even if you are doing for selfish reasons of making the project successful so that you look good you will fail badly - your team will lose their productivity as they go along the path of burning out. Work life balance is the key to team’s ability to take on stress yet stay productive. Keep an eye on the team, even if there is no huge workload, if the sole thing they focus on is work. If they do, talk to them, make them understand that you are OK if they take a break and do something with their family or go play a play a ball game, etc.

3. Take care of life’s little tasks

Little things like filling out form, buying a plane ticket, doing the laundry all take up time of your staff. Without doing them life becomes stressful. If there is any way you can take care of some of them, it does wonders in freeing up your team’s time, reducing their stress. Sometimes this “taking care” is very low cost compared to the high cost of the developer having a “downtime” from getting these done to getting stress about not finishing them. Google offers laundry service, FB has bike repairs , maybe you can’t afford things like giants but you can do something else that makes slightly easier for your team.

4. Make vacations a must

Vacations are essential for software developers. It’s as important as taking a training on a new technology or finishing off the tasks at hand. Vacation recharges them, makes them look forward to coming back to work, helps them think about problems in a new way. Without this regular recharge, refresh and rethink a software team loses it’s edge and individual team members slowly burns out losing enthusiasm and productivity on the way. Vacations should be made mandatory by policy.

5. Set realistic deadlines

Some companies use the mantra like "think big" and set unrealistic deadlines for developers. This may sound great in theory (or in a youtube video about getting rich) but it is a guaranteed way to burn out your team in the long run. Software development is a creative process at the end and you can’t use these artificial work more motivational strategies to get more juice out of the system. It may work one time or two but ultimately it will fail.

The only sane and long term strategy is to set realistic, achievable goals and deadlines for the project.

6. Recognize contribution

Recognizing a teams contribution and achievements go a long way towards the satisfaction and self-worth that a hard working team needs for it’s health. Recognition is simple and honest way of rewarding hard work. And it helps the team come out feeling better about themselves and take them out of the frustrations of working too hard for nothing.

I’ve found many startup founders have an idea that if they recognize the team’s performance their team will become slack, instead putting stress on them, pushing them and reminding them that they failed or might fail gets them to work harder. This is one the biggest mistake that a founder can make. The constant stress and feeling of failure destroys morale and reduces productivity and eventually lead to a burnt out team.

7. Encourage physical activity

Plan on giving enough time with the work day for some kind of physical activity. Even a little time to go for a walk or play a game of foosball is a great help. A break from the computer screen helps refresh the developer's head and allow them to see new solutions. It also helps her stay fit and healthy which eventually leads to a much energized team. And biggest of all it helps avoid burn out.

At Kaz we are big fans of cricket, no work day is complete without our daily cricket match. In winter cricket sometimes is replaced by badminton or something similar.

8. Bring variety in work

You should aim to have mundane or easy project priority tasks mixed with challenging, creative work. This mix helps the developer stay interested in her work. Interest is everything the creative space, if a developer becomes bored with the tasks in hand it will lead to burn out. Doing the same task over and over destroys motivation. Yet, if you mix it with a different set of tasks you’ll see your team producing more yet becoming less burnt out. Paradoxical but very true.

How to talk about your software before launch?

Buzz is everything these days. I blame Apple for this, remember those lines to buy an mp3 player called the iPod or worse a mobile phone called iPhone? But to be fair “buzz” as a marketing tool - to build up anticipation about products has always been there. Building up of anticipation leads to people talking and that leads to that most coveted of words “viral”. A famous example is the "Get your free email at Hotmail" that when MS started adding to their customers’ email circa 1996 to “talk and hint” about hotmail led to 12 million users in 1.5 years! Wouldn’t you love that for the software you are bringing out the world tomorrow?

“ ... could you put a message at the bottom of everybody’s screen.?”

“Of course we can technically do it,” Smith said.

“Oh, great,” Draper said. “And it can persist, right? You can put it on one message and if he sends an email to somebody else you can put it on that one, too, right?”

“Yeah, yeah,” Smith said, not convinced.

“So put ‘PS: I love you. Get your free e-mail at Hotmail’ at the bottom....”

— Conversation around how news about Hotmail might leak

So if you want to sell your that piece of software that you’ve been dreaming of, spending most of your time, money and energy on then you a have to talk. But how much do you talk? What do you say? Here’s some of our ideas from our 16 years of helping startups build, launch and market their software.

Always under promise and then over deliver

When you talk about the upcoming product to potential customers they will inevitably imagine that your product will do all kinds of things that it may not actually do. Since you are all hyped up and you obviously think your product is the cure for cancer you transmit that enthusiasm in your description. Which is great but if you aren’t careful the picture that your potential user is getting is beyond anything your product will ever be able to deliver. When you finally deliver the actual product, they are bound to be disappointed. Which will lead to bad reviews by word of mouth or worse over the Internet. This will hurt your sales in ways you cannot control. A recent classic (but completely unavoidable though given the situation) was the MagicLeap product. With billions of funding and amazing stories told the actual first version of the product could only disappoint. But if you consider the product by iteself it still is unique and amazing.

The only solution is to make sure you are under promising with the tacit knowledge that when you over deliver the surprise and delight will help.

Keep your dates flexible as much as you can

If you want to keep your promises, you can’t talk about upcoming release dates unless you’re willing to gamble. Software projects have inherent risks of delay. Something can and usually does go wrong, Murphy’s law always wins. Missed release dates leads to disappointment and frustration. And that leads to disregard. In these days of low attention span, once you’ve lost the attention, there is very little chance of you getting it back. So when you talk about your upcoming product keep those dates fuzzy - well you have to tell at some point obviously but say it as late as possible so that the date you say is a reliable one. “Coming soon” probably is too fuzzy but coming this summer is superb.

Keep the story consistent

Classic feature creep. Need to do a course to understand how to use your remote?

Right at the beginning think through what you are going talk about and how much. Keep to that script. If needed practice it. Every external touch point from the website to your chat with a vendor should stick to the original script. Slipping a product feature out means you better have that product feature just the way you described it - so describing it in different ways with ever so little bells and whistles added on is a disaster waiting to happen.

We see this a lot with new founders, who has been dreaming up their product for a while. The actual product that will go out on a 1.0 is usually just 10% of the founder’s original vision. It is a scoped, sane, planned set of features that led to a project plan and timeline. If the founder now drops in his ideas from the 90% that’s left out he has finds it extremely difficult to leave out - leading to the infamous feature creep that destroys software projects.

I have feeling that most TV remotes around this world are results of crazy CEOs bragging about how many things his TV can do over a drink too many :) I can never figure out what most of those buttons do…

Have a company policy about leaks

I know, most startup products are not as famous as Apple or MS and don’t have to have the dramas of leaving as yet unrevealed phones left on at bars. But still, if you are to stick with your story and your plan of keeping to under promise and over deliver you’ve got to put in a policy of what to share about the upcoming product in the company. Developers or designers working on the product will talk about their work with their friends and family. That’s normal human behavior about creative output. So if you don’t lay out a plan, that better be simple, of what and how much to leak you are likely to face a lot of heartache.

OK, I’m done for today. Here’s a great Dilbert for today’s feature creep fear that every developer has nightmares about.

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

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

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

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

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

   a) do one feature at a time

   or

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

The real debate is:

Is multi-tasking better than single tasking?

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

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

Source: The Multitasking myth

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

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

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

When your developers don't speak to you

What do you do when your developers don’t speak to you?

Not that unusual situation in the world of software development. Software developers in general have managed to earn a reputation for being difficult people to lead. A cursory glance at Amazon for software team management book will get you dozens of books dedicated to this subject (with the veiled theme of managing difficult people), including books with titles like “Herding Cats”! If there is a market for that many books then there must definitely be a need.

It’s obviously wrong to generalize and say software engineers are unsocial and don’t usually fit well with non techie rest of the world. That just isn’t true, spending all of my working life of more than 20 years being a developer, then hiring, managing and leading them I know that for sure. However, its also true that more often than not you’ll find it difficult to be friends with techies if you are not one yourself. Yet in an industry like software development, where communications and teamwork is essential to get products out properly, it’s important to have good relationship with team members. So how do you solve this problem? How do you make sure that your software team maintains good relationship with you (you = pretty much any role from an owner to a lead)?

Here are some tips from our experience that will lead to happy software teams and a team that trusts your leadership:

1. Shelter developers from “business stuff”

“With a software company, the first priority of management needs to be creating that abstraction for the programmers.

If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.”

— Joel Spolsky

OK “business stuff” is a horrible choice of words. What I mean by it is anything that a software company needs to run as a real business in this world. This includes things like sales, marketing, office management, making sure there that the air conditioning is running, even seemingly tech stuff like installing an antivirus or installing a hard drive. The idea is that development is a creative and high focus activity. Making developers do tasks that takes them away from this activity means you are making them lose their focus, it means you are making them do things that they are not good at. So although putting a developer on a sales call with a high profile customer might sound great because she can answer any tech question that can come up, you are actually wasting everyone’s time and making a dent on the developers ability to be effective probably for the whole day. Just as you’d shelter your accountant from debugging the latest issue in the code, shelter your coders from stuff that will only waste their time. You’ll be a star, you’ll make a huge impact on the quality of the code and find that the deliveries are happening on time. Joel call this sheltering the “the development abstraction layer”.

2. Trust your developers

Software development is really a craft. There is always an element of chance, an element of uncertainty in it. Which means there are times your team will be great, make you proud, produce the right piece of software at the right time and sometime they’ll make a total and utter mess. If you give them a feeling of trust - where you basically saying that you trust them to do their best, they in return will do their best. This is common in all team activity - sports for example. Trust empowers a team, makes them comfortable with you as their leader and makes the relationship with you simpler. DeMarco and Lister called it the “Open Kimono” (in their must read book: Peopleware) in a time when that phrase wouldn’t make you cringe. OK, cringe but follow their principle because this trust leads to better relationship and better teamwork.

Page 162, PeopleWare

3. Know that screen time is not equal to software

There is no relationship with the amount of time a developer spends in front of a computer screen with the quality and quantity of code she writes. She will write code that gets the a feature done sometimes in hours and sometimes in minutes - here’s the twist: for the same feature. Many things come into place that determines how much time is actually spent on writing a single piece of functionality. Sometimes it’s fast simply because a library was ready to go, sometimes it’s takes hours because a silly network issue made the IDE freeze, or sometimes it’s fast because a recent blog post by a favorite coder suggested a new algorithm. It’s impossible to predict. Yes definitely there is a tendency of some developers to be much better at coding than others, but that’s a hiring thing, the moment you chose to hire someone your are stuck with that person’s abilities and the inherent uncertainty of the software world. So if you see your coder “wasting” time in the lunch room when a super important bug is waiting to be fixed don’t go on hyper crazy mode - maybe she is just getting her brain to work things out in the background. Never use the quantity of time a developer spends in front of the screen (or even worse stays late for work) as a marker for performance for a developer. Getting out of that mindset will enable you to have a level headed conversation with your team and lead to a much better relationship with the team.

4. Break the ice

This is a big one if you are a non techie. There is an inherent “us and them” in the tech vs. non tech world. This leads to all sorts of weirdness and assumptions. A common misconception of a software team about their non tech manager (or worse old tech manager otherwise known as dinosaurs) is that they just would not understand how things are done. This often leads to a situation where the team is not communicating essential information (e.g. “there is no way in the world we can get that shipped by end of the month”) to you. This happens mainly because the team thinks you are just too different. The only way out for you here is to break the ice somehow. Go to a fun party with the team, make fun of yourself, admit you are indeed a dinosaur, whatever it takes to bring the wall down and make your team think they can talk with you.

5. Defend your team

“...the true price of leadership is the willingness to place the needs of others above your own. Great leaders truly care about those they are privileged to lead and understand that the true cost of the leadership privilege comes at the expense of self-interest.”

— Simon Sinek, Leaders Eat Last: Why Some Teams Pull Together and Others Don't

This is the ultimate one, if you just do one thing then do this. Let your team know that you have their back. You’ll defend them if things go wrong, if the boss screams he will be screaming at you and you’ll take the blame, if you lose the customer you’ll take the pain and not start venting your anger on the team. A good read along these lines is Simon Sinek’s Leader eat last.

The creation of software has so much uncertainty, so many moving parts and so many things that can go wrong that the team will always feel unsure of itself. Having a leader that understands this inherent risk of failure and acts as shield that lets them take that risk without worrying about the failure too much means a world of difference in the performance and morale of a team. And the team will forever be grateful for a leader like that.

OK, I’m off for today. Here’s the stolen Dilbert that does a good job on today’s topic! Good luck with your software team!