Remote software teams - setting the culture

The pandemic has validated the concept that remote work is not only sustainable, it is actually better in some cases than onsite work. This is especially true for software development phase, where the work is very much supported by collaboration tools and the work products are digital and wire transmissible by it’s very nature. And the biggest benefit that came out a fully remote operation is that the key factor that makes software projects difficult - availability of talents - is resolved easily. Remote software resources can be found from anywhere in the world as and when needed. Given this state companies all around the world has embraced remote work and remote teams.

Although this paradigm shift geographically distributed remote team is happening at breakneck speed somethings remain the same. A software team is still a team of humans that must work together with passion to create great software. There is no way out on that theme. So the new challenges that companies are facing are the challenges of keeping the remote team motivated and connected. This is indeed a big challenge as team members from far away, from different time zones and maybe from different cultures make for a difficult setting for create an unified “team feel”. The usual strategies for bringing on the team feel can’t be done and you need to come up with new solutions. We wrote about our best strategies in a recent article about remote team building. Today’s post is about the other side of the equation - the changes and considerations of workflow, processes and policies that enhances the collaboration and the team feel of a remote software team. Here are some out biggest hit in this area:

Create a culture of empathy and collaboration

Empathy is the key to a sustainable creative culture that enhances and enforces the values of great software teams. With processes and talent in place the only factor that makes a software organization excel is its culture. This is absolutely essential for creative organizations and this one factor differentiates companies that are performing at the highest level with quality, scalability and repeatability of performance. And of all the strategies culture is the hardest one to get right.

The schematic here shows some of the guiding principles we aim for in setting up the culture for remote teams. If we can get these key features right in a remote software setup then we are usually on the right path of creating a culture that works. Remember, the culture of a remote team doesn’t happen overnight, it’s not like switch you can just turn on. You have to create the right environment, take the actions that moves the team towards the right direction and then hope that it will all work out and the team’s work culture will be the right one for software development. Every team will have it’s own unique way of doing things - it’s own culture. In the 18 years we have been running remote software teams hundreds of companies around the world we’ve seen hundreds of variations on team culture. Each one of them were different, some worked better than others but overall the environment for the team were more or less the same. So it’s like throwing a pair dice, but you can improve your chances of winning by getting the playing field tilt the right way! Here are those key factors in more detail:

Consensus driven

We usually start with a consensus driven decision process where all team members have equal say in major decisions for the software project or work process. The goal is to introduce by policy and with explicit management preference a process where a vote is taken on all decisions. There is not feel of someone having more power than other just because they are at different level of seniority or from different area of work (say someone from HR). This consensus driven culture will enhance the feeling within team member far from each other that they are individually valued and their thoughts are taken into consideration. We’ve found that it’s really easy for a remotely distributed team to start feeling that they have some disadvantage being away from a certain core group or geographic location. This is especially true when a certain portion of the team is onsite working together whereas the rest are remote.

Low red tape

There needs to be a strong concern to setup everyday work policies that require the least amount of red tape. The less cumbersome the process for say taking a holiday or reporting a project status is the less the team will feel that their time is being wasted. This is true for onsite teams (all of these points actually are relevant for onsite team) but it becomes very important for remote teams. Because of time zone differences or just the availability of the right person to move the process forward, any red tape becomes hugely frustrating very fast. This is something that’s totally avoidable. Remember that the goal is to take away as much as possible the “pains” of working remotely and red tape is the easiest evil to take away. You might have to fight a few battles with the management or the HR but it’s worth that fight.

Flat hierarchy

Software teams just don’t need a lot of hierarchy. Usually a team lead who looks after a bunch of developers (maybe with different levels of experience) is all that’s required to make progress. So, essentially at an everyday level there should be just 2 levels - the lead and the rest. On a reporting level the lead might have a layer or maximum two above her. But that should be it. Having a flat hierarchy just makes for a fast and efficient decision making ability and that creates an efficient team. Now in this mix when the remote team comes in, every problem related to complex hierarchy magnifies ten times. Every decision making start percolating on the layers, bouncing up and down the layers before something final can be achieved. So flat hierarchy is the only sane way of running remote teams. Ideally, individual remote team member should only have one level of management to worry about - so, for example, a remote developer should take instructions from just one team lead somewhere, etc.

Gelling events

These are events where the team members are brought together virtually and if possible physically to connect as individuals. We talked about some great strategies for gelling a remote software team in different post. These are essential in creating a culture within the software team.

Fun, relaxed and creative

This is for the overall tone of the workflows, communications and practices of remote work. By setting a tone of informality the management creates the feeling of ease within the remote software developers. This is essential for moving team forwards in creating the right work culture. In essence this is the background to all the other activities and actions that a company must do for a great software team that works remotely.

Living with bugs in released software products

Bugs are the reality of software. We hate them, we do everything we can to get rid of them but they are always there and we have to learn to live with them - that is we have to manage the bugs and fix them in a sane way. This is important. Actually trillion dollar important. in study done by the Austrian software testing firm Tricentis, software failures cost the worldwide economy over $1 trillion annually!

The same report also found that software failures have caused more than 315 years of lost time and have affected approximately 4.4 billion customers. Software failures also have a massive negative impact on the reputation of companies. The companies surveyed by Tricentis lost an average of $2.3 billion of shareholder value just on the first day after announcing a software failure. No wonder that so many companies keep quiet about bugs. Yet that is probably the biggest mistake. The trick is to learn live with the bugs as a reality and have a practical and realistic process for managing bugs in live products. Today’s post is an attempt to summarize some of the strategies we found as the best for managing bugs on live products.

Accept bugs

This may sound obvious, but you’d be surprised how many companies treat bugs as something totally unacceptable and creates all kinds of penalties and punishments when bugs start surfacing on a product. This behavior comes from not understanding the nature of software products. Yes, the goal is always to have a bug free software release, but the reality is that there will always be some. So the goal should be:

“Release with as few deadly bugs as possible”

Accepting bugs opens up the possibility of a realistic software development process with healthy bug identification and resolution strategy. So this is the first step - for the management and for the technical team leadership.

Make finding and reporting bugs easy

Real life story:

A group of security researchers were prepping for a major reveal in 2013: They planned to disclose at a D.C. cybersecurity conference how a security flaw in luxury vehicles could let bad guys break in without keys and start the cars.

But Volkswagen stopped them, winning an injunction in a British court after arguing that publishing a paper detailing the problem would "allow someone, especially a sophisticated criminal gang with the right tools, to break the security and steal a car,"

https://www.theguardian.com/technology/2013/jul/26/scientist-banned-revealing-codes-cars

After you’ve accepted that there will always be bugs the released products your next sane thing is to setup a process and workflow for identifying and resolving bugs. It’s just crazy how many software companies out there try to hide their bugs or try their best to make it difficult for people to report them. There are literally hundreds of known cases where large companies tried to stop reporting bugs in their software - just making their users suffer even more.

This line of thinking is stupidity defined. You just cannot stop people from finding bugs. What you should do is make it easy for people to find them for you. Have easy ways for reporting such bugs - such as customer support emails that can easily turn into bug reports, a bug reporting page like Facebook’s Report a Bug feature.

On your development team’s side also have the tools for keeping track of all bugs that are being reported - both by customers and your QA teams. Tools such as Jira are absolutely essential, just as important as the software development tools or issue trackers when the actual software was being developed.

Involve customers in the bug finding journey

This needs to be a management and marketing level decision - involve your customers in the bug finding process. Ask them for feedback, have formal ways of checking back for issues, reward them with freebies when they find bugs. Customers are the ideal QA of a software, they use it everyday and they use in ways that your dev team would not even think about using a software (e.g using MS Word for image editing or Power point to make web pages!).

Microsoft has a thing called bug bounty which literally inspires users to spend time to find bugs and be rewarded for such efforts. Google has it’s various reward programs for finding defects, these are all examples of far sighted companies who have not only accepted bugs in live products and made it easy to report - they are actively involving the customers in their journey to find and ultimately fix those bugs.

Have workflow for updating users about bugs

As you accept bugs as reality, your wording and communication will let your users also accept them and make them expect you to come up with fixes as soon as they are found. They also expect you to be mature about bugs found in the current system and have a place to know about such bugs and the status of those fixes. User forums are great for such things and modern ones like Zendesk or Uservoice and many others like them do a great job of updating users about bugs, getting their feedback and letting them know when things are fixed. They have also the feel of user communities and can lead to bigger and better things such as users helping each other out and users forming their own groups to teach each other.

Create a culture for celebrating finding and fixing bugs

Finally, the most important thing of all - within your company and your development team create a culture of celebrating the finding of each bug and fixing them. Some companies make the fatal mistake of making the dev team feel bad each time a bug is found - this creates the negative emotion that takes away the enthusiasm and spirit the team needs to polish off a released product over time. To a dev team the release product is their own creation - any bug would sound bad to them anyway, it defeats the purpose if the company culture is to make them feel worse. The culture should be that bugs are unfortunate yet inevitable - but once found how fast they are resolved and an updated software is released is the true sign of a great software company.

Trust me on this, after more than two decades in this bug creation, I mean software development business, this culture fix is the biggest thing that differentiates a great software company from the others.

16 Years of Kaz Software: The work smart and love work way

I think we have a weird relationship with work.

We honor work yet we hate it.

The society is awed by people who are workaholics, yet that same thing destroys lives and families. We would rather not work, yet we are at work most of our waking hours.

When Kaz started, we said:

it doesn’t have to be that way. Work needs to be something we love.

And our strategy was that if we can work smart we will love our work. That was the goal and that’s what we always stuck to, and look at us 16 years later. We have enjoyed each and every moment of those years yet we have worked hard, making hundreds of great software. It all happened because we loved our work and we worked smart.

No secrets here. I’m surprised every time I get asked about our little secret of how we make work so loved. How we achieve high quality in our software time and time. I’m surprised because there is no secret. It’s obvious, it’s common sense. Judge for yourself, here are some of those “secrets”.

Let people choose their work

This is the big one. Everyone has their own soft spot for tasks. Some people love writing up precise documents whereas most hate documentation. Some developers can only relax when they are doing algorithms yet some great developers I know would rather die than think of maths. If you can come up with a team structure, a work plan where everyone can choose their own piece of work you are on your way to creating love for work.

What happens to the pieces no one likes? Easy. Once everyone has got a pick of their own the left overs people don’t mind so much to divide up between them and just slog it. Try this, I have tested this a thousand times before and I know it works like magic.

Cut out the red tape

Red tape - all the “process”, sign offs, authorizations, email acceptance, form fillups or whatever time wasting, soul sapping, life destroying stuff that organizations have come up with must be take out. Red tape takes away the fun from real work. The only thing it adds is just delays. I’ve found that all the promise of red tape that is supposed to make a project work according to plans are complete myth. Throw them away and you’ll find that a group of smart individuals working on a project they love will always deliver on plan.

Say no to politics

Politics is when a team needs to appease certain groups within the company. Politics is when saying what’s on your mind makes things difficult for you in the team. Politics is the single most harmful thing that a project or a company can have, yet it is something that exists in most teams. Maybe it is in the nature humans. You have to work hard to keep politics out, but it’s worth it. Take it out and then work becomes so much stress free. And stress free work leads to work that you love.

Risk takers are celebrated (even when they fail)

I’ve kept the best one for the last. Working smart and loving work means you have to own your work. You have to be responsible for the decisions you take and you need to take them without fear. If you in a work environment where failure from a decision leads to huge repercussions and pain, you end up in an endless process of authorizations and double checking. This leads to wasted time, but more detrimentally to a feeling that you do not own the work, you just happen to be doing it for the company. A psychology like that will never get you smart work. And it will never get you great, amazing results.

OK that’s about it. Simple, isn’t it? For the past 16 years we have proven over and over that these simple techniques give you great results. This is our work smart and love work way of doing things.

The cookbook for a hearty company

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

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

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

I didn't have that.

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

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

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

Idea: People need to feel safe to feel trusted.

Actions:

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

• ...

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

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

The hearty company

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

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

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

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

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

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

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

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

The recipe

The secret to a hearty company is simple.

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

So here are those ingredients.



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

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

Stay safe in these uncertain times. Stay home!

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.

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.

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!”

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.

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!

4 Software team strategies that work

Flat hierarchy

It's important for the team to feel that they are not bogged down with management. We try to build this into the system by having very flat hierarchy in the teams. Usually a team a has a team lead and everyone reports to her. The team lead can decide pretty much everything as much as day to day operations of the team is concerned. This empowering of the teams help increase both our ingredients. Empowered teams feel more gelled because they feel their actions navigate the whole team and they feel more responsible for the whole group. Less hierarchy makes it easier for the team members to speak out and voice their concerns - increasing openness.

Small Teams

Lines of communications as the team size increases (source: Lines of COMMUNICATION)

Small group sizes are natural. If members of the team cannot know each other on a level where they consider each other friends the team’s ability to cooperate drops. The more people you have in a team the less a single team member contributes to the project - this was known as far back as 1913 when Maximilian Ringelmann discovered that the more people who pulled on a rope, the less effort each individual contributed. 

Smaller teams lead to more social cohesion, that leads to more individual responsibility and more productive work done per capita.

There is another strong reason for smaller teams: less time spent on communication. There’s a formula for this, the number of ways conversations can flow between person to person is:

n(n – 1) / 2
where n = the number of people in a team

So this builds up very fast as n becomes larger and larger. The graphic here shows this - things get messy quite fast. And the messier it is the more noise there is to get information across the team and thus more time spent in getting things done.

What’s the ideal team size?

It depends of course on the nature of the project. Jeff Bezos has the famous Two Pizza rule that goes - “If you can’t feed a team with two pizzas, it’s too large.” You’ll have to find out your own rule, but as long as you keep the team small you should win.

A great read when you are thinking about the optimal team size is: Productivity and Team Size: Less is More

Culture of openness

Software is all about discussions and debate. No single person, no matter how many years he has been “doing software” or how many fancy places she has worked in, will always have the correct plan. Yes experience helps but sometimes experience leads to “this is how I did it in 1997” type sentences that usually lead to badly designed software. The only way to solve this is to have discussions and debates (we call them “fights”) where everyone has a chance to voice their concerns. Now this only works if everyone has a say, or rather feels free voice their ideas. If the culture of openness is not there in a team, junior members of the team will always stay silent, or people with louder voice will always be the only people speaking. This gets you nowhere. So cultivate the culture of openness in the team. Take steps that make the team members feel free and relaxed. Our strategies are always to take them out of work environment say in a fun party or in one of trips or adventures and break the ice particularly between junior and senior members of team.

Culture of excellence

Cultivating a culture of excellence is very important for the performance of the team. This is why elite commando forces have “we are the best” motto. A culture of excellence builds a bond between team members that is commitment towards keeping the standard up. This is a basic tribal need of humans - we don’t want to let our tribe down. And when the tribe’s culture is being the best at what they do - that is what everyone strives to do. HBR had a great article about the culture of excellence in companies that’s a good read: Creating a purpose driven organization.

And here’s the customary stolen Dilbert…

How to find a good software developer?

Finding good software developers is probably the most important thing for any software venture be it a micro startup, a giant bank starting a new project or software company like us adding new developers to its team.

A good developer makes a software possible, it’s as simple as that. You can find a developer (there are millions out there just go to any jobseeker or freelancer site) with all the certificates in the world, you can pay him well, you can give her the more time than you had planned for, you can give him the best tools that money can buy but the output - the software she makes depends only on one variable - is she good at what she does. In most other professions as long as you get someone who has been trained to do his thing he will get the job done at some point - some faster than others, some better than others but the job will be done. But with software the number of years of training or the number of framed certificates is in no way a guarantee that your software will be made. Some people can make software (without a single certificate on his wall) and others just can’t.

Given this situation, finding a “good” software developer is critical. But how do you find one? How do you know that someone is that “good” developer? Not easy questions to answer and even after 16 years in this business of finding developers we get things wrong sometimes, but I’ll try to share some ideas that might help.

1. Good developers are “get the job done” people

The first thing is to define what is “good”. The easiest is to say “good” software developer is someone who gets the software made :) But we would not know that right at the beginning when she hasn’t had the chance to make the software (and we definitely can’t wait for the project to fail and find out she wasn’t our choice after all). So let’s define “good” based on qualities we are seeking in a coder which we can somehow test:

Good is someone who gets the job done.

“... the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”

You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.”

— Joel Spolsky

In our profession you’ll find many (too many in my opinion) who are at the level of a University professor with deep theoretical knowledge about design patterns or Java history. You do not want them. They are going to waste your time by thinking too much about what’s right and what’s not. You want someone who might know everything about Java but can go into a piece of code, use google to find answers to his questions and put in a band aid like fix without any guilt complex about his lack of knowledge! You need someone who gets the job done. Someone who can play a multi-hatted role in the everyday business of software development. Joel used to call these rare people the “duct tape programmers”. A good read in this line of thinking is Eric Sink’s superb little timeless piece You need developers not programmers.

2. Good developers are not afraid to write code in front of you.

“Would you hire a magician without asking them to show you some magic tricks? Of course not.

Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them.”

— Joel Spolsky

You hire developers to write code. So it is a very natural expectation that they should be able to write code right in front of you, right? You’ll be surprised about how often great resume holding (and of course certificates… OK you get my irrational bias against certificates…) people will just be too scared to write code in front of you (say during an interview). Or they’d just be all over the place with the code and come back to say something like “this will need to be refactored of course” or something fancy like that. Run. Run like mad from any developer who can’t start writing code at a moments notice. Good developers should be better at expressing themselves in code rather than in language.


3. Good developers come with references

Joel Spolsky

Author of the best blog in the world for software development experience www.joelonsoftware.com

This one so obvious that I won’t delve too much into it. But leave by saying that before a developer is called the quality of their reference from someone you can trust (rather than their resume) should be the big marker. You see good developers easily make themselves felt. So every manager, team lead, business owner knows who is good very easily just from experience. Because they have gone through and got (or did not get) their software. Only downside is most manager don’t want to lose their good developers and want to get rid of their bad ones, so you got to be careful about whose words you trust! Our trick has always been to find our own references from peers rather than bosses.

4. Good developers are found in forums

Good developers are often found lurking around in tech forums asking and answering questions. Stackoverflow is definitely the big one, but there are many others. So finding links to their stackoverflow status or contributions should be a good thing and similarly if you are desperate forums are a good place to seek these rare individuals out. Microsoft is infamous with this trick, we’ve lost several of our super stars with MS poaching on them all the way from Redmond. Imagine getting a call from MS one night? Who can fight with the gods? D… the Internet :(

OK before I lose it I’m off. Hope you find your good developer and if you can’t just get us to build your software for you, we are best after all :p

To cubicle, or not, that is the question.

Most things in life has the Shakespearean ambivalence, but I can say without a shred of doubt that there is no uncertainty about the cubicle:

Cubicles are bad.

So “or not” is the right answer.

But if not cubicle, what?

That is where Shakespeare has the upper hand.

Companies large and small, universities and architectural firms have been trying to answer that question with mixed results. Let’s try to approach this with some data that proves quite strongly two things:

1. Proximity matters even in the age of digital

It has been found over and over that the physical proximity of people bring in more positive interactions and collaboration. Team that has team members on the same floor, same room are more efficient than team where the members are physically disbursed (yet connected with all kinds of communications platforms). MIT media lab has done extensive studies on effects of proximity on collaboration a summary of this was done by one of the researchers as follows:

“…the probability that any two people on a corporate campus will interact physically or digitally is directly proportional to the distance between their desks…”

— Ben Waber, Scientist MIT Media Lab

2. Interaction between different work groups reduces productivity

If there are separate groups within the company that work on completely different projects or areas no benefits come in making them interact more, in fact it reduces overall productivity of both teams. Research carried out in a major German bank showed that increasing interactions between teams undermined performance. So they moved teams into separate rooms. 

If you take the above 2 points as gospel then what is the logical conclusion? Keep individual teams together but separate from other teams. Simple.

A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series)

By Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel

And…drum roll please…. we have always known this answer. The answer has been in page 414 of our favorite book on work space design - A Pattern Language by Christopher Alexander.

“The fundamental learning situation is one in which a person learns by helping someone who really knows what he is doing.

…

Therefore:

Arrange the work in every workgroup, industry, and office, in such a way that work and learning go forward hand in hand. Treat every piece of work as an opportunity for learning. To this end, organize work around a tradition of masters and apprentices: and support this form of social organization with a division of the workspace into spatial clusters - one for each master and his apprentices where they can work and meet together.”

With our offices in older brick built houses with small rooms in the older part of Dhaka adopting this pattern has been easy. We can take a group of adjacent rooms (sometimes converting a connecting veranda that is very common in the older designs of Dhaka houses) to form the team space. We try to give the team lead some space of her own, ideally a room all by herself if possible. This makes it easy for her to act as the “mentor” when needed and also acts as the defacto meeting room where conversations (and noisy debates) can happen without disturbing the rest of the team members.

Brick walls ensure that interference from other teams and completely unrelated conversations don’t hinder the flow of the work of the team.

So as I said, Shakespeare has nothing to say to us when it comes to office layout. We got it figured out. But we love him anyway :)

Here’s the famous page 414 btw…

A/B Testing the culture of your company

Wouldn’t it be great if you could A/B test the policies that you take for your company just like you A/B test user adoption for your designs? If we could somehow try our decisions out and then take the one that works better it would take the heartache out of a lot of everyday decisions.

Let’s face it, the way we run our companies, and I’m talking about everyone - from the mini startup to the mega corp., is purely a version of gambling. Let me break down some of the common “rationale” for our policies for the company -

Excuses for bad policies:

“That’s the way it’s done everywhere”

And probably that’s why most companies have dismal work cultures.

“If we don’t do this now, things will go out of control”

As if it’s a kindergarten we are running or worse a prison :(

“There must be checks and balances”

Yeah, but when you have to say it out to justify a policy chances are you are forcing something in that’s no check and no balance.

Anyway, you get the picture (and this is just a rant post). Getting back to my point, A/B Testing - most of the times we are never sure if the policy we are putting in place is a good policy that makes the company efficient and makes the people happy (yes, you can have them both!) or if it will just sap the soul out of the people and lead to inefficiencies and backstabbing. Take the classic “Performance Review” the classic “That’s the way it’s done everywhere” thing. Is it good or bad? Without a performance review your best people will not feel they are being prized or valued. But with performance review aren’t you bringing in competitiveness? Particularly in software development doesn’t the best coder in the world go through a patch of really bad performance (which is offset by 10X performance at other times)? There is no solid gold answer - only “buts” and “ifs” and “depends”. btw if I’ve got you riled up here’s a good read from HBR - Why More and More Companies Are Ditching Performance Ratings

So if we just had a simple way of trying out a policy (maybe in part of the company) and trying something different (with another part) and the checking for the results and pick the one that’s better. Anyway without a foolproof system for A/B testing here’s what we do at Kaz whenever we we trying to put a new policy in place or change an existing one:

Have a “feel out” phase

Every policy we adopt goes through a “feel out” phase where it’s discussed formally and informally during team meetings, lunches even hallway discussions. This gives early feedback about the policy, get amazing ideas of what might work and what might not work and works as great PR campaign for the policy.

Introduce incrementally

All policies are introduced very slowly and in parts. This makes it easy for us to find our mistakes and fix them without making a huge mess. It’s amazing how many times we have fallen face in even when the plan sounded great during our feel out.

Seek feedback

This is the important one - seek feedback from the people who are most affected by the change. There might be some very good ideas about tweaks that might work.

Be prepared to change or roll back

Nothing should be set in stone. As long as we achieve the goal we should not bother about how we achieve it. So if something doesn’t work just change it or roll back. Remember that it’s not a prison that you are running and there is absolutely nothing wrong for a company to admit that it was wrong.

Measure company culture

Now this is hard one. If you can’t measure and put numbers on culture you can’t find out if something is working better or making things worse. But it’s not easy and some would say next to impossible. Our thinking is that you don’t really need perfect system (there is none), as long as you have some measure it’s better than none. So a simple poll might be a good way out, or you can go the full Titanium card path and try something like MIT’s sociometrics (MIT being MIT had to come up with device to measure culture):

We wrote a series sometime back on how we do and did things in quantifying culture The method doesn’t matter as long as you have some way of understanding the effects that you policy changes are causing.

But still, we would love a scheme where we could do those A/B tests easily. Maybe MIT will come up with something? :)

Software without anger: managing yourself

After our first two articles ( Software without anger: managing the development team and Software without anger: managing vendor relationship ) in this series of anger management in software projects we got a lot of feedback asking us about how to manage anger on a personal level. What can we, as software professionals, do to reduce anger in software project? Be it within the team, with stakeholders and even with ourselves ( this last one becomes obvious when you think about how many times you’ve wanted to bang your head on the table when you realized that you should’ve written that generalized class to validate the data before an insert or something along those lines… ).

So today’s article is about us. Us the software professionals (ahem).

We know we can do a lot (and we should’ve done a lot) to make software projects anger and stress free. Maybe we have our own list of those to-dos. Here’s our attempt at that list…

1. Expect and accept anger as normal in software development.

This one is the same for all of the articles... Since the situation is the same, so I’ll do another ctrl+C and ctrl+V from the first article:

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

It is the sudden rush of anger that you don’t expect in the otherwise calm and civil workplace (well for some I hear) that makes us go off balance. Instead of managing it we fumble and make it worse by being irrational and in many a case damage our relationships with others in the team and damage the chances of success in a software project.

The moment you expect anger as a natural outcome, you’ll be able to address it with strategies you know that work for you in other circumstances in your life. The particular strategy that works is very personal. Some people just takes a deep breath, someone I know takes a toilet break! For me the best thing is to stop saying whatever I was saying for a minute or so.

But expecting anger as a natural expected “artifact” doesn’t only mean that you can snuff it out when it comes. It also means that you can take steps to make sure situations that create anger do not happen, I discuss some such ideas below. And apart from snuffing it out, or avoiding it completely, anger can be channeled for the good of the project too! Anger is in essence passion and there is always a good use of passion in software projects! Good project managers us this passion all the time in situations like brainstorming or technical architecture discussions.

2. Prioritize, prioritize and prioritize

This is probably the most important single step you can do on a personal level to manage anger in your software project. There will always be way too many tasks coming towards you and there will always be a looming deadline that’s just too close for comfort. The only way to reduce stress (your own and the team’s when others are waiting for your work for theirs to be done) is to know what tasks are the most important.

Prioritize your tasks. Discuss them with your tech lead or manager. Discuss them in your daily stand-up. Scream (ok, maybe not scream in anger, that would defeat things ) if you feel you’ve been told to do something that you feel should not be high priority. Setting the priority of you tasks should be your highest priority :)

3. Read the spec!

OK, I probably mean understand what you are supposed to do in a task before jumping in to code it or test it. This might mean just reading the task ticket, or watching a video that explains things. But investing a little time to understand the task properly saves a lot of your time later on. It sounds very obvious, but I think we all know that we can be drifting with the flow on a lot cases and just jumping in to the code feels a lot easier sometimes rather than talk to a product manager about something that’s confusing. But that is a recipe for a heated conversation somewhere down the line. Not worth it.

4. Keep an open mind

Nothing in our field is set in stone. No technology is the final word and nothing is perfect. And today’s greatest stack will be the trash of tomorrow. That’s how our space is like, we knew it when we got into this. So there is absolutely no reason at all to be a staunch supporter of a technique, stack, idea, “pattern”, DB, __ (fill in the blanks). If you keep reminding yourself this fact then keeping an open mind is easy, and then discussions and debates about technology becomes finding out good solution for the problem at hand with the currently available skills and technology - rather than a religious war that these discussions sometimes warp into :)

5. Remember that there is always a next version

There will always be scope in your work. You will never be able to finish all the things you wanted to do. Scope your work, do what’s needed now and plan the rest for the next iteration. This helps move the project forward, keeps your boss and your teammates happy and you out of anger.

I’ll keep to the pattern of this series of articles by using a 3 stooges picture. This just one of them.

Software without anger: managing the development team

Isn’t that a great title for an article about software development? If you’ve ever been involved in a software development project this would ring bells!

This was the starting in the first article on this series - Software without anger: managing vendor relationship which goes over the distilled wisdom of 15 years or so that we’ve been around in this business of making software for our customers. That was all about how to manage the relationship with the software team that’s outside your company, say for an outsourced project, or for a team of yours that works offsite away from regular face to face interactions. Today’s blog is about managing your in-house team of software developers, designers and QA professionals. I can never decide if it’s easier if the team is in-house, but I think an entrepreneur is just faced with a different set of problems which require a different set of solutions. So here goes…as promised - a list of - “distilled wisdom” :)

1. Expect and accept anger as normal in software development.

Umm, this the same as with the vendor relationship. Since the situation is the same, so I’ll do the infamous ctrl+C and ctrl+V

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive, that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

The only thing to add to this for an in-house team is, since you see the anger first hand, as it starts to pick up steam you have to move quickly. You should never leave a conversation that started moving to anger without diffusing it in the direction of a creative conversation. Striking while the iron is hot is the name of the game for this.

2. Create a culture of celebrating a dissenting voice

A dissenting voice is a voice that checks assumptions, tests logic and make the overall process stronger. It is almost always good for a software development process. The only time you don’t want a good “fight” in software discussions is when ego is getting involved and the discussion becomes a war of words rather than a debate based on logic. So you should make it easier for people to voice their concerns, actually make it welcome and celebrated. That way people will speak out, and feel that it is accepted and is part of the healthy brainstorming that goes on in a team all the time. Taking the taboo out of the dissent makes it feel like professional skill and somehow takes away the purely negative “anger” component out from a discussion where two sides have opposing view.

It’s a delicate balance, but once you create that culture life becomes so much better and your software too!

3. Have a clear and readily available set of requirements at all times

When I say requirements, I don’t exactly mean like spec documents or a bunch of mock-ups. I mean at any point of time the team should have access to resources that make it crystal clear what they are supposed to be making at that point in time. So, to do that you’ll probably need a task management system (e.g. a Jira board), a set of mock-ups that have been scoped and discussed for the task in hand, a meeting or two beforehand that clearly goes over what you are trying to build over next few days/weeks, etc.

As soon as the team knows exactly what they should be making you’ll find that the destructive anger that comes from confusion and that always leads to a blame game goes away. That’s the type of anger you can never manage and resolve easily. Take that out and half of your job is done in anger management in a software project!

4. Always have a confident “supreme court” for final decisions

That’s probably the team lead or the founder or even the designer. It’s not very important who it is as long as there is only one at all time, whose decisions, people know, cannot be overturned and obviously someone who is just (most of the times).

Most tech debates (aka anger) have multiple possible resolutions. Usually more than one of the solutions being debated works great as long as everyone accepts it. But tech debates comes with people who are married to their ideas (“I’ve got a unique solution that no one has thought of”), philosophies (“Java is the best”), past (“It worked for the last project”) and the worst - latest fads (“micro-services is the future”). Many times the only way out of a prolonged discussion, that starts to loop over the same few arguments, is a judge making a call and putting an end to the debate. Not easy to find a judge who can instill that confidence but it’s not impossible.

5. A gelled team is the only way out

At the end, nothing is better than a team that trusts each other, considers each other as friends and are happy to work with each other - a gelled team. Just as in a family or a group of friends high emotions and anger fizzle out because of the strength of their relationships, a gelled team can absorb and diffuse any anger. We have written extensively about gelled teams. This is our big mantra, our grand unified theory, our secret sauce at Kaz Software. This is what makes us good at what we do over and over. Read some of our past blogs for some idea, Two ingredient recipe for a great software team or 5 Easy steps to kill the deadly PDI in your software team or Burn the cubicles - in the pursuit of happiness or the ever so famous Barbecued dog is good for software :)

Since I have the 3 stooges always fighting in this series, let me end with one where they are a happy gelled team which they actually are.

Two ingredient recipe for a great software team

Great software teams are hard to define, yet they are very easy to recognize when you see one. There is energy, enthusiasm, excitement and everyone in such a team feels like they are on a mission. Things just get done and software launches feel robust and predictable.

Great, I need a dozen, but how do I create one?

Now that's a really hard question. We've spent a long time building software products and the teams behind them. And have managed to create a reputation for building great teams. So we get asked this question a lot. After answering numerous times at different levels of hand waviness we have come to realize that we can boil it all down to just a single a basic recipe with just two ingredients:

1. Gelling - how close the team members feel to each other and how strong they feel for the whole group.

2. Openness - how easy is it for team members to criticize each other or themselves or voice concerns without worrying about propriety.

The funny things about our recipe is the the exact measures of these ingredients don't matter. The more you have the better things will be!

There are many things you can do to get these ingredients into your team. You will need to experiment and see what works for your team. If you asked us to name just one thing that works (for us), we'd say it must be our: 

Team events

We arrange events where some kind of group activity is needed. I think it's essential for these events not to have the explicit feeling that it's a "corporate team building" event - that feeling makes the gelling less natural. We try to make the events fun but include some elements that necessitates the group's input.

A classic at Kaz is our yearly trip where the overall planning is left to the team to finalize. This gives the team to come together and work together to create fun for the entire team as well as their families (as families are welcome too in these trips). We intentionally leave some constraints, a shoestring budget is typically the a big one but also there could be others like "ensure that the kids are not bored". These restrictions make the team members think in terms of the whole team which is a big thing for gelling. 

Good luck with your team building efforts, but before leaving, here are some pictures from our recent trip to Nepal!

Barbecued dog is good for software

Sorry for the show of the bad taste in the title. It is however not completely done for the sake of sensationalism. The idea for the title comes from a trip by the sea that we at Kaz software went to. We did a big barbecue of a whole lamb spit roasted on top of an open fire on the beach. Somehow someone claimed that it could easily pass on as a barbecued dog and that phrase caught on. So in the folksonomy of Kaz a barbecued dog party is where we do a barbecue under the open sky - something that we do at every chance we get.

So why is  it good?

It's good for different reasons. But at the core they are all the same - it brings people together and creates a bonding. There is something in making food together sitting around the open fire with smell of burnt meat in the air that brings out a very innate human bonding. Maybe it's the left over traces of a hunter gatherer tribe, maybe it's the psychological security and assurance we feel in the act. Whatever it is, it works like magic in making friends. And as we are all aware, a gelled team is the biggest factor for a successful software.   

5 Easy steps to kill the deadly PDI in your software team

PDI or power distance index is deadly for your software team.

Don’t know about it? You must read up all about it from our article about the power distance in software teams. Here is how I define power distance in the software teams:

How likely is a junior programmer to tell a senior about an error in the latter’s code?

Teams with large PDI will end up with those errors not discussed and resolved and thus with a buggy and at the end of the day a failed software. Thus it is of utmost importance that PDI be reduced in a software team.

The big question is: is it possible to reduce PDI? A valid question since PDI has been shown to be tied with cultures. But it has been shown that with the right effort and plans the cultural hard wiring can be overridden and PDI can be reduced and lives saved as it turns out:  in the case of Korean Air in late 90s. 

Korean Air had more plane crashes than almost any other airline in the world for a period at the end of the 1990s. This trend was finally pinned down to essentially power distance in the Korean culture which makes co-pilots very deferential towards the pilot and effectively cutting off the check and balance in the cockpit. Korean Air completely changed the trend by recognizing that PDI exists and taking steps to counter it. The success can easily be seen by the sudden reduction of the air disasters from the early 2000.

Although no study has been done in Bangladesh on PDI, but I can tell just by knowing our culture (and also looking at PDI scores of neighboring India) that the story is bad. So we’ve been very careful to take steps to reduce our PDI here at Kaz Software. Over the years we’ve tried lots of things but I can distill them all down to 5 steps that I know works likes magic. Here you go:

1.    Make your team aware about the risks of power distance.

The great thing about software team members is that they are uber smart. If you can make them aware of the risks of power distance and how it affects their work product it immediately has an effect. This is something we do at every chance we get – starting from the day someone joins us and continuing at almost all the team meetings and brainstorming sessions. The awareness gives the team members to speak out when they worry if speaking out against a senior might be being rude. Which takes me to the 2nd step.

2.    Train your team to be rude!

Well at least train them to speak out. Being nice and well behaved is the worst things that a developer can do to his team! Train them to have a strong voice of dissent, of being not nice when it comes to reviewing code or software design. A big tradition at Kaz is to “introduce” a newbie to the fine art of saying “you are dumb” in multiple ways!

3.    Make self-deprecating humor common

This is slightly more difficult. But if you can plot this with the seniors in the team this becomes the easiest way to break the ice. A common joke at Kaz is that seniors can’t code that well because they are slowly losing their grey matter. It’s brought up at every chance we get when we worry about code – and soon enough the juniors in the team start to use it.

4.    Do events that break down the barriers

These could be during the ubiquitous “team building” events or events specially designed to reduce PDI. The aim is to create a feeling that we all make mistakes – so the goal is different from the usual team building event’s goal – different enough to make special plans for them. The idea is simple, setup a situation (in a game, a show, etc.) where juniors have an edge over the seniors or where the seniors intentionally make a fool of themselves for fun. At Kaz the team leads dressing up as dodgy looking ring masters of a game are a good example.

5.    Make team structures as flat as possible 

This is the most important one. It’s the strongest message that you can send to the team about your intentions of keeping the PDI low. The whole gamut of hierarchy and respect just doesn't work in software and the sooner you kill it the better.