The deadly power distances in a software company

/

It all started with a Geert Hofstede, who in the late 60s did extensive experiments to prove that how we operate in a corporate environment is very much a function of our national culture. He measured responses of 117,000 IBM employees (he was working with IBM at the time) across different countries and showed that there are distinct biases about our reactions based on where we are from. He grouped the attitudes he was measuring in four types and called them the cultural dimensions. 

Of these dimensions Power Distance index (PDI) is the most interesting, I think, for software companies. Power distance is in simple terms how submissive (or not) is someone to his superiors in a hierarchy. For a software company it boils down to a simple question:

How likely is a junior programmer to tell a senior team member when he spots an obvious error in the latter's code?

If he is likely scream at the first chance then the power distance is low and if he is more likely to not raise an alert the power distance is high.

Hofstede showed that PDI is directly correlated with the country you are from. And this makes perfect sense - some countries have culture of strict hierarchy where are elders are honored without question. These cultures imbibe its children with that value of respect and submission to seniors that obviously shows up in work culture. Countries with high PDI include India, South Korea, Malaysia (sadly no data for Bangladesh, but it is without doubt a high PDI country). Countries with low PDI are US, UK, New Zealand etc.

So what is wrong with high or low PDI? 

Well, it depends I guess in which work area you are in. I'm sure high PDI is great for families (oh how I wish my word be the law for my two unruly sons - high PDI is definitely welcome at my home!), high PDI is probably good for places like the army (when you tell your soldiers to jump in front of machine gun fire you don't really want them to point out the futility of war, e.g.) but for some industries it's downright a disaster (literally). In 1994 Boeing published safety data showing a correlation between a country’s plane crashes and its score on Hofstede’s dimensions. And it is easy to understand why - in such a complex operation as flying a modern aircraft the chances of error are high for the captain. The first officer's major role is as a second pair of eyes for error detection and mitigation. Yet in high PDI countries the first officers (much lower in the hierarchy of things compared to the captain) finds it difficult to voice their concerns. And when you have that over millions of flights you start getting statistically significant effect of the high PDI causing crashes to happen.

And so it is for software. One of the basic facts in the game of software is that everyone (including the uber geek who has been programming since the 90's - well specially him!) will make silly mistakes. The only way to save a piece of software from these mistakes is by constant double checks. Software QA is a double check for sure, but that as we know is way down the path. The earliest double checks are the screams of team members during the design sessions and coding. And this is why a software company craves (or should crave) for ultra-low PDI. This leads us to a simple statement:

Software can only be made faster and less buggy by having low PDI.

So the most important question for a software company then becomes 

Can PDI be lowered?

  And thankfully the answer to that is 

YES!

The important thing is to recognize that there is a need for lower PDI and then there are many things that can be done to lower it. There are documented proof of such efforts and the resulting wins in the airline industry. We at Kaz Software have been doing that for the past ten years in our little niche! 

How? The answer to that question will be another blog coming soon.

 

Lessons in creating a software business

/

We are ten years old this month. We started out on June morning in 2004 as a “company” where we had no rules, no goals and no clear plan of what we would do to sustain ourselves – we only knew that we just have to make it a place where people are happy. Over the decade we have learnt many lessons on what to do and what not to do in the business of software. And today I want to write about the lessons we value the most. It would have been great if someone gave me this list ten years ago, but I also wonder if I would have believed it enough to follow it!

Creating a company based on a single vision works

For us it was the vision of: “work should be place of happiness”. It sounds nice, it sounds right but is it good enough to carry a company to profit and permanence? I honestly feel it is – in these ten years a lot of things have happened, many business decisions had to be made and many a crisis had to be overcome, but it was always this single vision that guided us in all our thoughts. Having a single vision meant we could easily decide among multiple options that we had in front of us. It gave us the road to travel and the strength to walk that road fast.

I am not sure if our particular vision is important, it was for us and it worked great. But I think any overarching simple vision that you truly believe in, that everyone in the company can understand and embrace would have worked. Having a simple vision is important. Without it (or with too many of them) I feel we would have been lost.

Software business is all about the right people

Selecting the team members in any company is important. But I feel in the business of software this one thing can make it or break it. You could have the lousiest idea about a software product in the world, but if you have the right people they change it into something amazing – and obviously the other way round. I think in no other modern world business is the product of the business is so malleable, so sensitive to the craftsmanship of the people building it.

So, hiring decisions are the most important decisions in a software company. We learnt to be patient, to be more exact and to be more careful when hiring new team members. If this meant that we lost important business we learnt to live with it – that’s how it is in this world.

Think only in the long term

All our decisions that have been based on short term thinking have failed or have haunted us. Somehow this very ephemeral world of software requires a very non-ephemeral structure to stand on. So we learnt that buying this server “just” for this six month project doesn't mean we can compromise on the quality. We learnt that bending the rules “just” this once to meet this deadline backfires pretty soon. There is nothing short term in software business – it’s hard to believe that this is true given how software projects work.

If you are not hiring a great C++ guy now since you don’t have any projects right now, it’s probably a big mistake. If you are saving a few dollars on a server you’ll probably regret it next month. The list is really long and scary – but if you do want to be successful you just have to believe that you will be around for a very long time.

Only thing that works is an environment of trust

Software is so inherently a collaborative effort that only if people feel safe in trusting others that the whole thing works. Otherwise you spend all your energy trying to force external systems and rules to make that collaboration happen – and it keeps failing. Only an environment of trust can achieve software products that are on time, relatively bug free and usable.

An environment of trust builds up primarily from the actions and policies of the company. It builds up from the actions that people in positions of power take and how those actions are perceived. Any system or rule that you bring that has an impact on that perception has to be considered carefully before it is put in place. So if you thought that nifty time tracking tool you just bought will turn the company around, think again, it might be the first nail in the coffin.

Never, ever be “set in stone”

Software is always a moving thing. And no wonder that a software company should also be like that. What works today, what worked so well last time, has every chance of failing to tomorrow. You will always have to adapt your rules, policies and business practices. If you are doing great as a business now, beware tomorrow the technology might change or the customer’s need for a certain feature might evaporate. That’s how it is in this game. And the only way is to be able to adapt.   

people software company


Cat on a hot software company

/

If you are curious about the title (and you should be!) the explanation is easy:

The blog is about Ms. Meow the cat - the official Kaz Software mascot. The blog is also tangentially about the importance of making a place of work, particularly a place of creative work, feel like a real human habitation (as opposed artificial "corporate" one). And last but not least the title is a shameless attempt to push a picture of Elizabeth Taylor and Paul Newman in of their finest moments :)

The mascot

Ms. Meow is a cat with a strong personality. She knows what she likes (techies and food) and she knows what she doesn't like (admin droids and banana). She is very conscious about her career improvement, as can be seen below - she learning the art of SQA with full dedication. (I'd like to point out that she is far from an ornamental mascot - she is the savior who protects us from the clutches of the evil mice :)  

WP_20140128_bw.jpg

The workplace like a real human habitation

I agree, this paragraph looks suspiciously like a weak attempt to bring credibility to this blog post. But I assure you it is not. From the day we started ten years ago, we made innumerable decisions to make sure that our place of work feels, as close as possible, like home. This is not an easy task, mind you. It is not as easy as putting some pictures on the wall or setting up a comfy place to sit, etc. Well I should say it not just those things - there are many reasons why home feels like home. The visual aspect is only a small part of this big story. 

But why make it like home at all? Well that is a long tale with no definite story-line. But it is really a point of view (amongst many) about workplace. But it is a view that we at Kaz subscribe to very passionately.

I can't do it justice, so let me quote something I read recently in a book review (and I quote without credit - in the world view that in the post Google world there is very little need for such a thing): 

“Understanding that humans biologically evolved to cooperate and that leaders emerged to protect the group, organizations that create environments paralleling those early conditions will bring out the best in us. This means taking steps to avoid the allure of abstraction in modern life by keeping it real and avoiding the perils of scale by keeping team sizes that mimic those of human tribes.”

The picture

OK, cutting to the chase, here is the picture. It is from the movie Cat on a hot tin roof made in 1958. When the monochrome was at its best in human history and when nothing could beat the sizzle of Elizabeth Taylor and Paul Newman. (As a last attempt to justify it, I'd like to note that it goes with our theme in this blog of putting up old b&w pics of movies that are notionally connected with the content of the blog).

Elizabeth-taylor-cat-on-a-hot-tin-roof-1958.jpg


 


Experiments in software teams: Camping for the geeks!

/

Adventure activity and software - not the best combinations those two you'd think. People in software tend to be less the "adventure sort", if I am allowed a sweeping generalization (once a month is ok!).

There is a lot of folklore about what happens between team members in the stresses of an adventure. There are countless stories of old friends fighting it out and separating because of a tough trekking trip. About people changing into very different personalities in the extremes of environment and physical strain. Gurus claim that a group only works in such stresses if the personalities match or complement each other and when there is strong pre-existing bonding between the members. Many have warned that in the dry and lifeless corporate work groups such a strong bonding is not possible and thus it is not advisable for such groups to undertake extreme activities.

We are not famous for listening to sound advice. So we wanted to test this out - as part of our philosophy of experimenting with culture to find that Nirvana of software.

 We wanted to see what really happens when a group of techies with the famous pre-existing bonding of Kaz go through physical stress of a relatively difficult adventure trip. Today's blog is about that experiment. 

The Goal

See how techies function as a group in a physically and mentally challenging adventure. And see how that experience effects their work relationship and team bonding.

The Monkeys

We wanted to test with a diverse group. So we chose a team of six who are:

  • Software Developers
  • SQA Engineers
  • Systems Engineers

The Setting

The trip was to be a 3 day camping trip in Nijhum Dwip - an island at the south of Bangladesh. 

 

The island is, very unusually for Bangladesh, nearly empty. Most of it is forested and there are a lot of deer. No dangerous animal except some dogs who moves around in packs and attacks the deer!

The camp was at the southern-most tip of the island.

There was no road transport to the campsite - the only access was with a boat from the nearest bazaar and then walk across a very muddy path. 

To reach the dwip from Dhaka the route involved a 18 hour trip via an overnight ferry (called লঞ্চ locally) and then an unknown route of reaching the southern tip (the unknowns where intentional parameters in the experiment).

The Parameters

  • The team will not be able to stay in a roofed building (they were given tents).
  • They need to stay far from any inhabited area.
  • They will have to cook all their meals while at the island.
  • They cannot research the area too much for before going to the trip - to bring in an X factor.

The Results

During the trip:

No noticeable fights erupted (sadly!), there were occasional friction between the team members which were at a magnitude higher than the usual workplace friction. We saw the effects of the professional diversity of the team in their roles during the trip. Systems, for example, took up the responsibility of arranging battery power (via solar cell panel they carried their).

After the trip:

The team came back to Dhaka with a great sense of achievement. This sense of well being has continued and has had a noticeable effect on the bonding between the team members. So none of the warning about possible long lasting effect of friction happened - quite the reverse actually.

Let me leave with some pictures of the trip!

 

 

 

 

 

A software company and a retreat in the sands

/

Every year we do a trip outside the country to celebrate our anniversary.

This year we went to the white sandy beaches of Krabi, Thailand. For eight blissful days we forgot all about computers, null pointer exceptions and presentation layers! Soaking in the sun, kayaking in caves of the limestone formations that jut out in the crystal clear waters in the Andaman in that region and snorkeling over the corals. 

The value of such a retreat is huge - especially for a software company like us. The retreat relaxes and refreshes us, forming new bonds and strengthening old ones. When we come back we seem to take on our challenges with a fresh burst of energy. The stories and pictures of the retreat form conversation topics for a long time - creating relief and diversion from our daily grind.

We've been doing these trips for the past nine years, and here are some things we are mindful of to make a trip great: 

Location

A retreat has to be in a place where there is something for everyone (including family and kids). Beach resort towns are big winners (our biggest hits have been Goa, Phuket and Krabi) but other places like mountain resort towns such as Pokhara (Nepal) has also been a success. 

Activity

There needs to be a variety of activity available so that people can choose. Some of the easier ones we arrange beforehand (e.g. trip to a nearby sight) but others we leave people to decide according to their taste. So some of us do Kayaking whereas others go to a nearby museum. 

Food

This is ultra-important - especially because we are Bangladeshis (who are known to live to eat). We aim to be in a spot where there is a great variety of restaurants available. We make sure dietary restrictions such as halal meats, vegan food are covered by some of the places. 

I leave you with some of the pictures of this year's trip. 

 

Foundations for a career in programming

/

One thing we get asked often is how we train our junior coders. And the answer is never an easy one, since we don't have a set training program for this. But we follow some principles, which over the years have worked remarkably well in creating top professionals. Kaz developers are highly valued in the industry - a sure sign that our principles are working. Here are some of the basic principles we use for developing our younger technical staff.:

Charlie Chaplin - The Kid

Charlie Chaplin - The Kid

The master and the apprentice

Coding is a craft, and it needs to be learnt just like how any other craft in this world is learnt - through working as an apprentice to a master craftsman. Using this as the guiding principle, we put our new recruits into a team where there is a guru lead to guide them through their work. The freshers are put on real projects as soon as possible, typically starting with back-end tools working in a pair with a more senior resource - usually the lead. The pair programming model works like magic and we have noticed that within the first few weeks we can transform a not-so-sure person to a very confident coder who can contribute directly to our code. This master-apprentice approach is really a long term process and as the junior programmer works through a wide range of challenges the professional skills improve greatly.

A Swiss knife 

One of the first thing we ensure about freshers is that they are not put in a single technology for too long. The idea is to give them a taste of various technology/programming languages/domains/problem sets so that they can have a balanced view. Our fear is that if a fresher is stuck with a single thing for too long, she might try solving every problem with that single tool rather than choose the correct one (or look for a correct one that she doesn't know about). The aim is to create a Swiss knife rather than a single blade knife. We think after two years of experience in this mode, a resource can be put in a technology where she can start being an expert - by that time she has gained enough experience to know that there are other things out there.

So our freshers go from doing a .NET based auction site this month to a Javascript heavy social app the next month. They may be doing xml conversion the month after. With the wide variety of programming skills available at Kaz this is easily achieved.  

The art of disagreeing 

A major skill in a life in software is the ability to argue well. It is a skill that has to be learnt, practiced and perfected daily. We teach our freshers to be fearless in putting their views across. We teach them to overcome their worry of being wrong - which is typically the biggest block for new comers. We try breaking the ice in every way we can so that they feel comfortable in voicing their disagreements to seniors within the team.    

The loss of ego

Ego kills a great software career - it as simple as that. Ego pushes a person to make irrational decisions about technology. Egos also mean that technology meetings never come to a compromise. Since great coders come with great egos this is a huge problem in the professional software space where teams need to make decisions together and work in harmony.   

It's also one of the hardest thing to get rid of! We try breaking the ego by examples. Our senior resources make a show of displaying that they can be wrong. Saying "Oh I see your point now and I was totally wrong" is something that is pretty common in our culture - and this helps freshers a lot. In some cases individual counseling may also be given - always by someone who is respected for her technical skills.

Creating a tech addict

A life in software is also a life of constantly staying in touch with the latest developments. We take active steps to motivate our freshers to keep reading up new technology and try using those in their work. We move our new recruits into projects that uses new platforms that will challenge them and make them read and learn the new API sets or new paradigm of coding. Our culture of technical excellence also brings in the peer pressure for staying on top of new things - which soon becomes a habit, an addiction! We think this addiction is a must for a great career in software.

So those in short are our secrets for creating great developers. Are we missing anything?  

 

Planning the perfect company event

/

We've been arranging trips and other company events for the past nine years. And we think we are experts in this field now - at least in arranging  events for software companies.

 We do our yearly anniversary trip which is usually a 8-10 days' trip outside the country, we do a 2-3 days' trip, called the picnic for some long forgotten reason, every year. Apart from these big regular ones, we do several weekend trips to various places within Bangladesh and dozens of smaller events like the borderline insane "hudai party" (see our fb page at fb.com/kazsoftware for more pictures and stories) or more mundane stuff like release dinner parties, training workshops, various sporting events, brainstorming off-sites, etc.

We know pretty well when an event is far from perfect, and we've learnt a few things about what makes a company event approach perfection.

 While planning and finalizing the Thailand trip for this year's anniversary party (Yesssssssssss.... its going to be super cool with 8 days of fun in Ao Nang Beach Krabi) I remembered some of the things we have learnt and thought it would be good to share with my readers. So here goes:

1. Think BIG

It's best to think big. Because if you don't your plan keeps getting budget cuts and will start losing it's charm. Budget will always make things difficult for you whatever the size of company you are - but if you don't aim high the trip/event plan will never be great. So we think seriously big, I mean HUGE and then cut things down one at a time to fit with the money in hand. For example, the moment we thought we could do Thailand this year the first thing we said was that we would never do the old and tired Bangkok-Pattaya thing. It's just not us, 2 days in a crazy city and 2 days in a crowded dirty beach. We searched for the most pristine beach out in Thai coast, found the most expensive looking resort and said we wanted to stay there for 7 days (since 2 days is just too little and saying 8 days would have killed our boss). The resort seemed very happy that about 40 nerdy guys wanted to stay over there, and gave us the cost - a figure which can easily be the deposit for personal jet to fly us out there. So we googled again to find the next best one out on the beach... and the cycle went on.

2. Never underestimate the power of a group

Group travel or group booking does wonders to bring the cost down in any place. Use the group's number to bring down hotel prices, make the bus company give out free seats and make the restaurants give out extra special menus. The power of the group does amazing things to an event plan - use it and over use it. 

3. Have a high up champion 

Make sure someone from the management (or any decision making group) is a strong supporter of the event. Having a powerful champion will solve your problems of fighting the enemy within in the struggle to organize that perfect event. You'll need her support for sure. Since you are thinking big all the time - you will run out of budget, ideas that are real fun may not seem all that good for the company to powerful people, and the list goes on. Your supporter will help you sail through the red tape and make things possible. Without a champion at the right place, you will compromise at all levels and soon end up with an event that is just plain boring.

4. Involve everyone in the group

All decisions should have a feeling that it came from the group. This is vitally important to break the "us and them" feeling that creeps up in company events. The group should be consulted at every point of decision making like venue, things to do etc. This makes the group feel that they are part of the event's planning and that feeling helps them overlook a lot of issues that might otherwise sour the event and draw criticism from the participants. So run surveys, impromptu meetings or just plain group discussions on email to ask for ideas or help.

5. Have an element of surprise

Obviously company events need to be formal to a certain degree. There would be memos describing the event in as boring a way as memos describing appropriate dress code in a business meeting for the nudist resort's website :) But an element of surprise as in the sentence before (hopefully there was one) help liven up the actual event. A surprise could be as simple as ice-cream that wasn't in the menu or a little gift - but it should be done around the beginning to have the right effect.

No longer that much of surprise these days, since we do  it all the time, but we did a branded T-shirt for our trip to Goa a few years back and gave that as gift.

No longer that much of surprise these days, since we do  it all the time, but we did a branded T-shirt for our trip to Goa a few years back and gave that as gift.

6. Create hype

Hype is probably more important than the event itself. The right kind of hype when mixed with the right kind of planning can make a very low budget event a great success. A great thing for a company is that most of the hype can be done for free. Free hype could be as simple as a group emails describing how good the event would be or some aspect of it which is likely to be exciting for the group ("we will see the new VS from MS - still in secret beta!") . Posters in the hallway or even whiteboard screaming out messages can create a lot of hype. But one thing to remember is that hype should be matched somehow in the event itself - or it would be a disaster! So only hype things you know will happen. 

For example, for our Anniversary party at Thailand a series of amazing pictures of sights around Thailand does a great job at building up the excitement which makes the party much more fun.  

 

A picture of the reclining Buddha at Wat Pho in Bangkok, circulated over email or FB page does a great job an creating hype for the upcoming party.

A picture of the reclining Buddha at Wat Pho in Bangkok, circulated over email or FB page does a great job an creating hype for the upcoming party.

7. Create an icon for larger events

Iconography is something people understand. Using a theme, wording and icons help promote an event, makes it more interesting and easier to talk about. For a custom software company like us creating icons, posters and themes is relatively easier since we have our own design teams. Here is our banner for the Thailand trip this month...

 

banner.jpg

Where the wild things are

/

The title is a tribute to Maurice Sendak whose birthday is today.

Maurice wrote and illustrated amazing children’s books. And his famous “Where the wild things are” is a classic – if you have read it as a child (and actually even as an adult) the images of wild things and the little boy’s reactions to them leaves an indelible mark on you.

Where the wild things are is about a boy (Max) who fell asleep in his room and his dreams. He dreamt that he travelled to a land far away where the wild things are. He conquers the wild things with his look and becomes their king. But he starts missing his home and decides to come back home. When he wakes up he finds his supper waiting in his room.

So what’s the connection between a custom software company in Bangladesh and the children’s picture book? There isn’t a lot really, but I really wanted to introduce Maurice (many of my readers are based in Bangladesh and may not know him that well) and made up my own little connection.

The land of the wild things represents our fears. For a software company like us, that hires the best in the market, the biggest fear is the fear of loss. Our fear of losing our talents to other companies locally is not that great – because we are genuinely a great place to work in Bangladesh and thus represent a top choice for people to work. Thus we rarely lose our talents to other Bangladeshi companies. But those wild software companies in far off lands in the West are a different thing altogether :(

The West has a magical hold on the imagination of people living in developing countries. We tend to think of the West as the fairy tale land where every wish comes true. Our constant exposure to western media from movies to songs to news enhances that magic every day. And in the tiny world of software, is there any other monster more awe inspiring than the likes of Google or Microsoft or thousands of other fabulous software companies that we read about, hear about and watch pictures of everyday?

So where the wild things are for us is the West – those beautiful magical shores of California or fiery autumn forests in New England. And the wild things are those monster software companies that live in that land.

See that’s a good connection! And to extend the connection even more, I hope that our children will one day come back from the land of wild things again to their own little rooms in their own land where their supper waits for them.  

Side note: So how many of our talents have we lost to the wild things? Too painful to answer accurately, so let me just say “many”. We’ve lost so many to the wild things like Microsoft, Amazon or LinkedIn  that I keep seeing their logos on Maurice’s drawings every time I turn open his book to read to my sons…

 

The boy in the picture (second character with the crown) is Max who goes to where the wild things are in the story and he represents our lost talent.

Custom Carrom Board for a Custom Software Company

/

Our annual Kaz Carrom League is in the offing. Carrom is a game we love to concentrate our passion on during the rainy months of June and July. If you know anything about Bangladesh's rain you'd know why :)

With the carrom fever coming up we've been in search of the perfect carrom board since our old ones are dying out. But one of life's lessons was the fact that there are no perfect carrom boards out there.

Just as some problems in this world just needs a custom software, we needed a custom built carrom board.

So work is in progress for that perfect board. I list some of the spec items for this perfect board for your reference.

 

kaz-carrom-league.png
custom-carrom-board-varnish.JPG

Varnished sides with grains that contrasts well with carrom men

Did you know that the carrom disks are called men?  They are are and they deserve the proper varnished sides to settle down.

Extra wide sides

Because you need need your hands to relax while you wait for your turn.  Basic primal requirement.

custom carrom board extra wide edges
custom carrom board corners

Smooth rounded edges

There is no insult in life greater than being pronged by the sharp edge of the board when you've just missed your chance to grab the queen. 

custom-carrom-board-joints.JPG

Strong joints to last a lifetime

Some people say that the strength of the joints transmit to the spirit of the game. 

custom carrom board back

Extra strong back support

These boards will last a long time as will Kaz and we want to make sure posterity remembers us.  

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.

Quantifying culture in a software company - part 2

/

In my two previous articles I have gone over how we come up with a working definition of workplace culture and how we measure the first dimension the T-index of that definition. I must reiterate that the definition is a very narrow one and even at that only an approximation, but it helps us move forward in our goal towards measuring the fuzzy concept of culture.

Today I will try to cover the formidable second dimension that we call the S index – a measure of spontaneity in the population.

Let’s make a few more approximations. Let’s define spontaneity as the quality among individuals in a group to be enthusiastic about group’s activity and well-being. And we say that we can get a sense of it from their activity in raising concerns about issues around us or taking steps to improve things, in a spontaneous way.

With this level of pinning things down we come to a plan that if we can track and categorize the number of issues that people raise, of a type that cannot normally be called an action of normal workflow, over a period of time and somehow normalize it properly then that number would give an indication of how spontaneous (in our definition) people were in that time relative to other times.

Enters our formula for spontaneity measurement – the S index.

S = iN/T

i = number of issues discussed in a category in a quarter

N = number of participants in such discussions

T= Total employee at the time

So to increase S either more individuals need to raise issues or more discussion should happen or both.

So how do we track issues? Even more difficult question is how to differentiate issues that are result of normal work to spontaneous ones?

The answer to the second question is that it is very subjective and coupled to the person making the judgment. But if it’s the same person making the judgment and if that person is more or less consistent then it roughly works. As for tracking things, it’s a question of setting up a process and a habit.

At Kaz (like most places) we have the following forums for discussing issues

    • Official email (to management/HR/etc.) for a formal, urgent issues.
    • Email to group addresses (e.g. teams or technology groups) for a less formal yet important issue.
    • Email to an informal group (in our case in google group) for fun/anything that isn't for office mail proper.
    •  Informal/formal conversations with team leads/managers.

    For the emails we try to categorize them immediately with outlook folders for internal mail and for the google group it is much easier using the tag features of gmail. For conversations that reach HR/management they are turned into email items and then treated similar to others. And once every three months someone spends a horrible hour or so putting the numbers in an excel file. But we keep the categorization in the data since that is very important to find meaning in the numbers. We plot these numbers in an excel graph and compare it with past ones and try guessing why the graph is going up or down.

    Below is the graph of S index for five of our categories. What makes this graph very interesting is that it’s from the period at Kaz when the T index (which shows togetherness within the teams as explained in the part 1) went down to all time low and even without graphs we knew things had turned really bad.

    sindex.png
    • S1 =  Work related (e.g. “The server needs a patch that I have recently read about”)
    • S2 =  Environment related (e.g. “Can we get some plants to make our room a bit more colorful?”)
    • S3 = Concern about loss (e.g. “What’s happening to our Thursday evening meetups?”)
    • S4 = Ideas to make things better (e.g. “Can we get whitboard markers with pelicans on them, they last much longer.”
    • S5 = Action on own accord to fix something (e.g. “… that noisy UPS thing is fixed now with a bookcase I pulled in front”)

    The interesting thing to note is that S1, S3 surged before Q2 2009 and went into gradual decline, which tells me that this was an auto correcting attempt by a culturally strong group. The decline is probably a sign of frustration – both eventually picked up when we took corrective measures over the next few quarters.

    Similar story for S2 but it surged throughout the crisis and leveled off only after things were getting to normal. S2 is the environmental feedback – and it makes sense for it to try auto correct during the full crisis period. It too would probably have trailed off as a sign of frustration if we did not take corrective steps but it comforting to know that it is stronger than S1 and S3. So the immediate question to ask is what can we do so that S1 and S3 would show similar strength as S2 should a future crisis arise?

    S4 and S5’s sudden rise after our corrective steps is a sign that people tried to come forward and help out more in the organizations own effort to heal. This is a natural reaction of a group when they see strong steps being taken to fix things around them.

    Now is a good time to leave. The whole point of measurement is for interpretation and how an organization interprets is how it introspects. What we did and how we interpret things, we think, worked for us but may not work for your organization at all and that may need a different way of looking at the problem, a different set of inputs and most importantly a different interpretation.

     

                                           

    N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.

    Quantifying culture in a software company - part 1

    /

    Kaz has always had a reputation for having a great "culture" for software development. We treat culture as an object, we have formal and informal processes to ensure that this thing "culture" is maintained and kept alive the way we think is good. To do this we have to quantify culture properly so that it can graphed, compared and our measures to modify it can be judged for its efficacy. 

    What do you measure to quantify culture?

    The first thing is to believe that it's not impossible to measure it! We truly believe that it is possible to quantify culture, track it and tweak it with measures. But to do this you need to define what culture at workplace means to you. The definition does not need to be perfect for all people over all software companies over the world - it just has to be something that works for you. We've done just that - and the first post this series on culture in software company was about that definition. 

    Let's repeat the definition here for convenience:​

    Culture at workplace is that thing that brings among employees: togetherness, spontaneity and a better perception about the company.

    So the things that we want to measure are the bold items in this working definition. So we know what we want to measure. The big question now is:

    How do you measure them?

    Here are some techniques we use to measure culture in our workplace.

    Measuring Togetherness - the T index

    Togetherness is the quality among a group to stay together in everything they do.

    A reflection of this is felt on how much of an interest there is in our people to participate in group activities.​ This is very easily measurable. 

    We have a lot of events that are unrelated to work. For example, the company arranges for all paid trips several times during the year (we've gone to trips to places like Kathmundu, Goa, Delhi, Darjeeling, Bangkok, etc.), there are Kaz Underground arranged events like the infamous pool party (during the peak of the summer) etc, there are all sorts of parties all throughout the year (joining party, leaving party, late in the meeting party, early in the meeting party...you get the picture!). What we consciously do is collect stats on participation in these events. This is typically done to arrange the party itself (to know how many are attending, arranging hotel rooms etc.) but this data is also put in spreadsheets for culture measurement. We use the date in these spreadsheet to calculate a value that gives us an idea about togetherness - we call it the T index.

    The T index is the average participation over a period of time as a percentage of total employees.

    Increase in T index is good. So, say for example if the month of April saw T index of 60 and on March it was 50 - it probably means the togetherness in the culture is improving - more people are turning up in group activities. One thing to note here is that in this field of hand wavy numbers absolute values aren't that important - what you want to do is plot T index on a graph and see if it's increasing or decreasing over a large period of time (say 3-6 months). Thing to remember is that you need a lot of events to aggregate so that your averages are better and you are not looking at any exceptional local spikes or troughs.

    We actually do several T indices. We differentiate between types of events to find separate T index values. This is valuable since it gives you a better understanding of how things are. We can look for correlations and anti-correlations to give us more information.

    For example we differentiate between T index of events that are fully or partly funded by the office and events that are totally private (e.g. party that has a ticket you need to buy, late in meeting party)​. For private parties, you expect the T index to be lower but it still tells you how much the group wants to gel outside the office (or outside the company's plan of things). Here is a chart of these 2 T indices for us from 2008 to 2012.

    ​

    tindex.jpg

    In the T index plot above, T1 = T index for company sponsored events, and T2 = privately arranged events.​

    The biggest thing to note is that around middle of 2009 things were really going downhill for our culture. And this was really palpable; we felt that we were losing something great. We took a lot of steps that fixed it as can be seen by the rapid rise in the index over next few months. But a big thing to note for us was that the T2 was not really as low as T1 ​, and as a matter of fact it was actually rising! This told us that although our people felt less inclined to join office events they were themselves socially connected and were just bypassing the office in their togetherness. This gave us hope, we knew that if we took some corrective steps we can bring the culture back.

    How we did it is the story of a article later in this series on software company culture.

    I'm going to stop now, the part 2 of this article will go over the measurement techniques of the other 2 indices. So stay tuned. ​

    ​I leave you with some pictures of our recent pool party. Our plot says that the graph is on the rise right now for us! I think I agree :)

    5WH2ZCREK7A9

    ​

    Defining Culture at Workplace

    /

    This is an easy topic to write about and at the same time it’s a very difficult to write about.

    It’s easy to write about culture at workplace since we all have a “gut feeling” about it (more often the absence of it!) – I can write pages about what I think culture is or should be etc. But it’s extremely difficult to write something that is concrete, meaningful and that gives my readers (and me) the feeling that they have truly learnt something new.

    Knowing this I will try a completely new tact – a bottoms up approach. I will try defining culture by what I think is its best outcomes in a software studio. So this is defining something by what you expect its results to be – like defining a jet by saying it is something that leaves white trails in the sky. This is by no means a good way of defining things precisely – but it does its job and I will show in a separate article that this definition opens up the unthinkable possibility of measuring culture!

    Without further ado – I present to you my definition:

    Culture at workplace is that thing that brings among employees: togetherness, spontaneity and a better perception about the company.

    And here are my definitions of the keywords in the above:

    1.       Togetherness: The quality among a group to stay together in everything they do. It’s the property in a team that people often refer to as “gel”. If a group has this, then if one of them is in trouble just about everyone comes over to help. The benefit of “togetherness” in a software team is obviously huge and for difficult projects it is absolutely essential.

    2.       Spontaneity: The quality among individuals in a group to be enthusiastic about group’s activity and wellbeing. It is the quality that brings innovations, ideas and an attitude of “I care” in a software team. More importantly it breaks those impasses in the technical meetings! Not quite an obvious side effect of this quality is the gradual improvement of the company’s way of doing things and thus its culture. So this plays the crucial role in a positive feedback loop.

    3.        Perception about the company: This is simple and straightforward. It obviously improves the morale of the workforce – but in the software studio context it plays a more important role of retention and ability to draw talents who are in the social circle of the individuals to the company. For a software company that last thing is its lifeline.

    I concede that this definition misses a lot of things that other people may consider just as important. But from my experience in the context of a software studio these are the only things I should care about. Note the crucial word “context” – so my context apart from the software studio probably also includes more specifying phrases such as “in the tropics, in the third world, in a land that rains most of the time and where people are crazy about mango…” :) Joking, but definitely context is important. (Our context is: we are a software company in Bangladesh mainly working on outsource custom software development doing everything that is needed to get your software built and deployed).

    With my working definition set I can then think about quantifying these properties – thus measuring culture. And with anything I can measure I can start doing A/B testing to improve things! So with such humble beginnings I am suggesting I can be (and we are for some time) doing what most people consider next to impossible.

    All of that in some future posts here someday. I’m off to bed.

    ​