Logo-wear And Its Importance.

During its glorious days; Multiplitaxion Inc; was giving out amazing logo-wear --- T-shirts; pens; mugs; watches; clocks and toys. As an organization it was interestingly  popular when it came to free logo-wear given out to employees.

Irrespective of who you were; if you worked at Multiplitaxion Inc; there was always enough logo-wear going around and you could grab some too.

Then as we 'grew' in terms of team-sizes and number of employees; something funny happened.

The concept of giving out logo-wear stopped all-together. All of a sudden you could not get any logo-wear --- even if you wanted to buy it.

All logo-wear just disappeared out of the organization.

Not many missed the logo-wear though. Interestingly; however; the few who missed these logo-wear items had one thing in common. They were genuine builders deeply connected to the organization and their projects.

Every single one of them.

The incident was an interesting insight into what alpha-geeks and genuine builders expect out of their organization when it comes to logo-wear and toys.

There Is Something About Logo-Wear.

The whole-logo-wear-not-being-available-within-the-organization-incident happened slowly; but even months after the culture of giving logo-wear had completely stopped; every now and then some of us would talk about the good old days when there was always some logo-wear with cool slogans and wordings on it. 

The cost of these swags in terms of monetary value --- peanuts.

Yet there was something about cool company T-Shirts and logo-wear that was causing the genuine builders to go bonkers and drool over cool logo-wear.

Why?

Because having amazing logo-wear which you can, carry, wear or use says a lot of about the organization that gives it out.

Logo-Wear Reflects Your Organization's Personality.

Remember the famous 'Ninety Hours A Week And Loving It' T-shirt worn by the Macintosh team? All the controversy around that T-shirt apart; the T-shirt was a reflection of Steve Jobs passion towards build amazing software.

Amazing; wild; funny; crazy or down-right-hilarious; the logo-wear your organization gives out; to a large extent; is a reflection of your organizations attitude and personality.

If you organization has no  logo-wear; it has no personality.

Logo-Wear Allows Builders To Be Loud.

As developers we are much more comfortable talking to the compiler than we are comfortable talking to human beings. We are usually not very loud when it comes to marketing ourselves or our organizations.

Go compare the number of posts on Power-shell that are out there and with the number of posts where developers are talking about how much they love their current organization. If you have done your Google searches correctly chances are --- you will find that not a whole lot of developers are talking about how much they like their current organization.

There are three reasons why the post count of how much developers like their current organization is so low:

1. Most developers do not like their current organizations and are either tagging along as a 501 programmer or looping in the infinite loop of failure.
2. The ones who genuinely love their organization would rather talk about the work that they are doing in their organization.
3. As programmers we are usually not very loud of vocal when it comes to complaining or talking highly about the organizations we work for.

While you cannot address the first point by giving out logo-wear; it does help programmers and builders who are quite for the second or third reason to go out there and spread the word about their organization.

A Natural Extension Of Being In A Vibrant Tribe And Flaunting It.

More often than not; Tribes work by exclusion. If everyone can be a part of it; your tribe probably isn't interesting enough to join in the first place. You have built a remarkable work and play environment --- now it is time to give your builders a chance to flaunt the fact that they belong to rare tribe through remarkable logo-wear that grabs attention and makes non tribe members go wow.

If you genuinely believe your organization picks the best of the best; allow the best you have picked to flaunt the fact that they belong to a rather rare tribe.

Logo-wear is a natural extension of being in a vibrant tribe; being able to flaunt the fact that you belong to such a tribe; and use 'exclusion' to spread the word about your tribe or organization's personality so that you can nudge other smart builders to join the tribe too.

Logo-Wear Is Fun.

If all the above reasons do not make sense to you --- this one should.

Everything about Logo-wear is fun.

Designing it; getting it; wearing or using it; giving it out to your team members; all of it is fun. If you organization does not have logo-wear you might be missing out on a whole lot of this fun.

Most genuine software developers out there; are in it; for fun. Most genuine builders notice little things and small things like your business card or logo-wear can have long lasting impacts on your overall organizational environment.

If You Cannot Give It Out The Least You Can Do Is Sell It.

Early on in my career I spent some time in the Microsoft campus. One of the things that I liked about my stay there was that there was quite a bit of free-logo-wear and toys that we received. Apart from that the premise had a special store which sold logo-wear at discounted rate if you wanted to buy more logo-wear than what you were given for free.

At the end of the day; your employees are doing you a favor by wearing your logo-wear and spreading the word about your organization around. If they are genuinely connected to your organization they might even go out there and buy the logo-wear; the least you can do --- is make it available to them when they want to buy it.

The more I look at organizations out there; the more I continue to be amazed by the number of organization that do not even have a decent logo-wear based T-shirt. Quite a few organizations actually have pretty amazing logo-wear but you get some once a year and there is no way for you to get or buy more.

Not having logo-wear or not making is readily accessible to your employees shouts out loud that your organization lacks the passion; the commitment and the zeal to form tribes of truly connected employees.

Remember; logo-wear will not take a screwed up environment and fix it.

They are much like an icing on the cake that is already well baked and delicious. Having said that; I am yet to meet one builder who does not like this icing on the cake of his professional life.

Now go print some T-shirts.

Go figure out how you will make them accessible to your employees or team.

Does Your Organization have Logo-wear you feel good about using?

Does Your Organization give or sell the logo-wear and make the logo-ware readily accessible to you when you need it?

How strongly do you feel about logo-wear and it's impact on how the employees feel about the organization in general; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

The Stupidity Called 'Working Together'

At Multiplitaxion Inc, every time I was close to getting in the flow a monkey would pop his head out of somewhere or a bunch of jokers would giggle over a stupidly funny conversation.

Because of the classical cubical-farm design of the office; I jumped from meeting room to meeting room trying to focus and getting stuff done.

As I hopped from meeting room to meeting room there were three things that I learnt about meeting rooms:

1. Located next to every meeting room are other meeting rooms.
2. Other than meetings; these rooms are often occupied by teams of software developments indulging themselves in an insanely stupid act; which they refer to as --- 'working together'.
3. Human being are social animals and when they 'work together' they tend to talk about their wife and their life much more than they talk about their code.

Every now and then I would have a bunch of developers 'working together' in the meeting room next to the one where I was hiding to get my work done.

By 'working together' in a meeting room; I do not mean the regular five minute standup. I also do not mean the famously stupid three hour meeting. These guys were in an insanely fu@#ked up self-organized meeting; eight hours a day; five days a week conducted under the name of 'working together'.

In this eight hour meeting; multiple things ranging from favorite movies of individuals; to what a variable should be called; could be brought up and discussed at length. Somewhere in the middle when when people were tired of discussions and wanted to take a break; the talking stopped. That is when people tried to write some code.

Of-course this was not a real meeting.

These were a bunch of developers taking the initiative of 'working together' --- so everyone actually liked it and encouraged it.

Of all the discussions that happened; one of the discussion that was brought up every now and then was why their project was slow and how it could be speeded up.

Shut the F@#k up and do some work.

To be honest; and candid; any computer science graduate; fresh out of college would have told him why their project was slow and what they could do to speed it up.

What they had to do to speed it up was something rather simple.

They had to --- shut the f@#ck up and work.

Coming from someone like me; who encourages flocking and a strong bonding in a team; asking developers; who sit in the same room and work; to shut up; go to their cubicles and work in their own cubical might sound like contradictory statement; but it is not.

As developers every single one of us needs two fundamental things from our work environments. On one hand we have a strong urge to 'belong'. Put simply this is what Seth Godin describes as building tribes. On the other hand however; what we also need as developers is quite time where we think; reflect; exercise our brains and try to solve really complicated problems by simplifying them.

If you are building a genuinely remarkable work play environment; it is your responsibility to provide your team both of these. Taking your team out to lunch; project dinners; and having x-boxes in offices is important. I have even gone ahead and suggested the nine-ten rule.

Having said that what is also important is that your team members get quite working environments and are mature enough to realize that while parties; games; chats in cafeteria; brainstorming sessions and whiteboard sessions are important; at times it is also important to shut the f@#k up and do some work alone.

Now; stop the chit-chat; go to your cabin; try to focus in a quite environment and do some real work.

Seriously.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

It All Begins With A Demo Or A Road Show

'We have an application that does not do much and we have a marketing road show lined up next month. We need to build a few new features quickly.' --- The Vice President of marketing at a fairly famous multi-functional scanner company; which for the purposes of this post shall be called Multiplitaxion Inc; tells us.

When the messages reaches me; my ears perk up.

I can clearly hear and sense the direction of our project changing abruptly and suddenly because someone from marketing pointed in a different direction for the fifth time.

I suddenly become attentive --- in a meeting where I would have otherwise dozed off.

The Negotiation.

You have mastered the art of saying no. With your amazing story-telling and articulate explanations you convince the vice-president that all your team can build till the road-show; is a prototype.

What you mean; when you say all your team can build is a 'prototype'; is that your team needs is a license to build crap that they will neither have to build-on-top-of; nor support in future.

Something that gets thrown away after the demo.

What your vice-president-of-marketing means; when he says you can build a 'prototype'; is that he needs a version-1 of a fully functional product which he can show to potential customers.

Something that gets sold after the demo.

Marketing demos or road-shows alter and change your product backlogs all the time.

Marketing demos or road-shows change priorities all the time.

Marketing demos or road-shows result in creation or 'prototypes' that will be 'thrown after later' all the time.

And there is nothing wrong with that --- till the time you, your team and your organization does not start indulging in what I like to call --- 'Demo Driven Development'.

Demo Driven Development

Every time you are about to do on a product demo or a road show and flaunt your product you will be faced with strong temptations to add new features that might woo your potential customers in the next demo or product road show.

When your vice president of marketing tells you that you have a demo or a road-show coming and that you need to build something really 'quickly' what he is tell you can translate into one or more of the following:

1. We are now going to move to deadline-driven-development.
2. Sky is going to start falling and things are going to get ugly.
3. The famous negotiations between marketing and development teams are going to now begin.

Usually; dear reader; it translates into all three.

The next time your vice president of marketing comes up a set of features that you absolutely must have during the demo; exercise your very own personal judgment and ask yourself if the feature is worth building before you try to 'squeeze-it' into the product backlog.

When you say 'yes' to building something; you accept the responsibility of supporting it for a very long time. We have all seen requests to add features or requests to change things on a prototype that was built to prove a point in a demo and was supposed to be thrown away later.

We have all seen these prototypes snowball into version-1 products and then a three year project needing a lot of fire-fighting.

Remember; you do not 'have to' have every single feature your competition is going to demonstrate in a road-show. There is nothing wrong with going to a demo or a road-show with product that is crappy and incomplete.

If your product is built on a strong idea; if it is genuinely remarkable and if your story-telling is genuinely good; your customers will connect to your organization and flock to product; even if your product has elements of crapiness or incompleteness attached to it.

Don't let 'Demo Driven Development' become the development methodology for your next product; dear reader.

I wish you good luck.

The Lame Whiners Programming Universe

The Lame Whiner; who for the purposes of this post we shall refer to as Fred; is at my desk wondering if Multiplitaxion Inc, has signed up any new short term consultancy projects or will be signing up any new ones in the recent future.

I cringe.

Watching Fred at my desk means that he is going to spend a good half hour talking about why Multiplitaxion Inc, should sign up new short-term consultancy projects. Then he is going to cry like a baby.

He is going to cry like his career; his life and his universe depends on Multiplitaxion Inc, signing up new projects.

He equates new and more short-term-consulting projects to 'growth' and wants to work on something 'billable'.

Putting Fred on a research project doesn't make him happy.

The very words --- 'on the bench' makes him feel insure.

Working on an awesome product and giving long term commitment to it makes him feel nervous.

Long story short; he is not happy --- and he is out to spread the viral-dissatisfaction to anyone who has time to listen to him whining.

The lame whiner looks up to his organization, his client, his colleges and everyone else to make dents in his very own personal little programming universe.

He lacks participation; but seeks opportunity on a golden platter; nicely laid out  --- just for him.

The Problem With Whining About Your 'Circumstances'

Hidden deep down in the archives of Joel Spolsky is a discussion where Joel nails the essence of whining about every little 'excuse' for not making a dent in the universe. Joel talks about the problem with whining; finding lame excuses for your being a mediocre-replaceable-developer and then quitting. While answering one such question about quitting he explains:

Although the tech industry is not immune, programming jobs are not really being impacted. Yes, there are fewer openings, but there are still openings (see my job board for evidence). I still haven't met a great programmer who doesn't have a job. I still can't fill all the openings at my company.

Our pay is great. There's no other career except Wall Street that regularly pays kids $75,000 right out of school, and where so many people make six figures salaries for long careers with just a bachelors degree. There's no other career where you come to work every day and get to invent, design, and engineer the way the future will work.

Despite the occasional idiot bosses and workplaces that forbid you from putting up dilbert cartoons on your cubicle walls, there's no other industry where workers are treated so well. Jesus you're spoiled, people. Do you know how many people in America go to jobs where you need permission to go to the bathroom?

Stop the whining, already. Programming is a fantastic career. Most programmers would love to do it even if they didn't get paid. How many people get to do what they love and get paid for it? 2%? 5%?

If you read between the lines; it is not difficult to understand that what Joel is doing here is giving tough-love to his fellow programmers; and nudging them on the side of righteousness.

It is easy to whine about your organization; your manager; outsourcing; recession; or stupidity that surrounds our industry in general and blame one or more of these external factors for your inability to build anything interesting.

It is easy. It is convenient; and if you get your whining-act right; you can even get away with it.

However; there is just one little problem --- it is your first step at becoming what we officially call a --- whiner.

Time To Look At The Mirror

The next time you whine about not being on a billable project or not having enough work to do; get up and go for a walk to a rest-room or any place that has a mirror; once there; look at the mirror really hard.

Staring right at you will be the person responsible for your inability to build or get involved with something genuinely interesting.

If you are genuinely dependent on your organization for giving you quality work --- and are lost when it does not; you are just one of the flock of sheep waiting to be herd.

Have you seen whiners getting lost, confused, scared and not know what to work on when they are on the bench for just a couple of weeks?

Have you witnessed whiners seeking 'opportunities' out of their projects, organization or managers and when then citing that as an excuse for not building anything; when they do not get their dream jobs, dream projects and dream managers?

Have you ever arrived at office; morning after morning; only to see Fred whining at your desk; telling you long winded stories about how his organization is hindering his progress?

Have you ever wondered why Fred doesn't leave and go find a better organization?

How many unhappy whiners surround you; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Builders Lead By Building. Not Managing.

Early on in my days as a young and budding developer at Multiplitaxion Inc; I heard a very mature individual talk about the philosophy of basketball and how that wisdom maps to software development teams.

His observation about the game was rather interesting:

When you are playing with a team size of five you need every player to score.

I've always advised young and budding managers roll their sleeves and continue writing some code. Scoring constant goals yourself is your only chance at keeping a team of genuine builders motivated and gently nudging everyone in your team to score too.

I've observed countless builders and story-tellers around the world and in all these years of observing them I am yet to find one genuine builder or story-teller who doesn't roll his sleeve and gets down to some real work himself.

Having said that; I continue to be amazed and surprised at how difficult most organizations make it for a builder; with just a few years experience; to continue remaining a genuine builder. James McGovern in his post on this topic; explains the issue rather articulately:

Being an architect in a large enterprise, the biggest challenge for most architects is in staying technical and grounded in reality. It is way too easy to become a buzzword parrot where one spends more time thinking of cool phrases that otherwise have empty meaning over focusing on producing credible architectures with integrity. I find it fascinating that we talk about business/IT alignment, cost reduction and other reasonable practices yet no one is asking the more difficult questions.

How can a business be successful in the use of technology if the vast majority of team members especially within IT don't understand it? I bet you work with teams that have one technical person, in the midst of various managers and other “developers” (usually off-shore) and find that one technical person does a majority of the work, takes the blame for the failures (of himself and/or others), yet is rarely credited for success. How come competent developers put up with nonsense and continue to take the rapings?

Should developers challenge their managers to look at their shiny, gold plated project plans that adhere to CMMI level 13, ITIL, Agile, garbage 2.0 and other worst practices and find a single item that someone else could take more than 10% credit for? At the end of the day, the vast majority of projects either still succeed or fail based on heroics. Sadly, we have realized that heroics are not the way an organization should be run, so instead of working on repeatable, sustainable practices for software development, we have morphed into repeatable, sustainable ways of doing perception management and throwing developers under the bus.

James ends his post with an interesting note:

I am proud to say that none of my reviews in the last ten years have ever had a single negative comment regarding my ability to deliver high quality work, in a timely manner and within budget. Much of the feedback is based on perception management.

The thing I think about almost daily is how I can live up to a  high standard not because of just personal motivation but because others are watching. This is the essence of leadership.

I don't want to be a manager nor should others be forced to report to one.

Early on in my career at Multiplitaxion Inc we ended up with a situation that was not planned. It was completely co-incidental; but then; having said that; the happening of the situation resulted in an observation that taught me the deep dark secret of management.

Smack in the middle of multiple projects; Multiplitaxion Inc; realized that a few of its managers were not working out well and got rid of them. Panic stuck and other managers; left on their own. In about three months since the firings happened; Multiplitaxion Inc; was a 'zero manager' company.

When I say 'zero-manager' I mean literally a zero-manager company. There was no-one in office who had a business card with the word 'manager' on it --- except one Quality Assurance Manager who was an amazing guy doing some serious hands-on testing himself. Given his way of leading a team; he had recently been promoted to the designation of a manager. People; including his own team; hardly knew the fact that his business card included the word 'manager'.

Other than this Quality-Assurance-Manager of ours; who continued to be a very technical-hands-on manager; developers at Multiplitaxion Inc, woke up one fine morning and literally discovered that all their 'managers' were gone. Just like that.

Any guesses on what happened when they realized that they suddenly had no managers?

The answer is what each one of us; as programmers; developers; builders or story tellers know deep down inside; but are too afraid to discuss or even say it out loud --- what happened is that the developers became much more effective and productive at what they were doing.

Things; dear reader; started getting done.

Am I saying that you go on a firing spree and fire all managers in your organization?

Of-course not.

Having said that; if you; dear reader; are a manager; try to see to it that when folks walk into your office wanting to discuss a problem; your monitor has a code-window open and not a Microsoft Project Plan.

If you want to lead a team of builder; you'll have to stand of the front lines of the battle march.

You can only motivate a team of genuine builders by building stuff and scoring goals --- consistently.

Remember; Builders lead by inspiring others to build stuff; not by managing them; and the easiest way to inspire others to build stuff is to build remarkable stuff yourself.

Now; dear manager; close that project plan of yours; open the integrated-development-environment and start talking the language the rest of the builders and story-tellers in your organization are talking.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Builders Fail --- All The Time.

"Let us talk about any one task or project which you consider to be your biggest failure" --- I ask a veteran programmer who; for the purposes of this post; we shall refer to as Fred.

Fred stares at me with questioning eyes wide open; as if I just asked him the famous-inappropriate-are-you-a-virgin-question.

Throughout the interview Fred takes great pride and speaks at length when asked to discuss his success stories but but behaves like he has been put on spot and asked things he cannot answer when asked about his failures.

After taking over a few hundred interviews and observing countless genuine builders at work if there one thing I have learnt about genuine builders who make small or big dents in our universe; it is that they  --- fail.

They fail all the time.

Genuine builders do not think of themselves as seriously kick-ass-rock-stars who can churn out zero defect code every time they are asked to. Most genuine builders indulge in decent amount of soul-searching; and have some a decent level of self loathing for themselves.

Most genuine builders aren't ashamed to openly discuss; analyze and learn from their failures.

If there is one video that describes the idea of flaunting your failures openly with class and glamour; it is the Nike-Commercial on Failure:

"I've missed more than 9,000 shots in my career. I've lost almost 300 games. 26 times I've been trusted to take the game winning shot and missed. I've failed over and over and over again in my life. And that is why I succeed." - Michael Jordan

If you haven't clicked on the link of the video you should.

As 'grown-ups' our fear of failure and the tendency to see it as a negative experience comes from the sheepish desire of being 'safe' and mediocre.

Michael Hunter; takes the remarkable lesser walked path. He nudges professionals around the world and encourages them to fail early and fail often. He explains:

If you're lucky, however, your family encourages you to fail early and often. If you're really lucky your teachers do as well. It takes a lot of courage to fight against this, but the rewards are great. Learning doesn't happen from failure itself but rather from analyzing the failure, making a change, and then trying again.

Over time this gives you a deep understanding of the problem domain (be that programming or combining colors or whatever) - you are learning.

Exercising your brain is good in its own right ("That which is not exercised atrophies", my trainer likes to say), plus this knowledge improves your chances at functioning successfully in new situations.

Has it been a very long time since you last failed?

If you answered that question with a 'yes' --- you need to find a problem bigger than what you are currently working on.

Get out of the boring territory of 'safe' --- fail like a child and learn like one; dear reader.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Let's Empower Teams To Have Fun.

During our early days at Multiplitaxion Inc some of us got a little excited about our work-culture and thought of taking it to the next level by introducing a little bit of a 'Google effect' to our very own work environment.

We tried to strive for an independent 'budget' that could be allocated to each project manger to use as he sees fit. Like all beautiful ideas, the concept was simple, pure and clean at it's very core. Every month, team leaders would get a certain budget which they could use to boost the morale of their team in whatever way they see fit.

Ways in which you could use it could include:

1. Buying gifts for top performers and genuine rock-star builders.
2. Organizing project parties.
3. Buying a X-Box for the team so that they could kick some alien-ass if they were tired of coding.

I could probably go on with that list forever but I am hoping; dear reader; that you get the general idea.

Assuming that Multiplitaxion Inc, was made up multiple Multiplitaxion Inc's that happened to be successful, we thought we aught to give some empowerment to the teams and see how they end up finding innovative ways of maximizing fun with a limited budget. This was an idea that would let us do just that.

The idea would also allow us to see how teams of genuine builders like to have fun; instead of taking them to a party and then 'hoping' that they enjoyed themselves when the dinner was over.

Lets Shit-Can The Shitty Empowerment Idea.

So a bunch of young and budding managers; me included; conceived the whole idea of this independent; 'fun-budget'. Three weeks later; we were sorry we had anything to do with the idea.

We were rotting in meeting hell and attending one meeting after another where we were answering what the basic idea of this 'fun-budget' was; what the scope of the budget was; what were the kind of expenses it was supposed to cover and what were the kind of expenses it was not supposed to cover.

After three months of conversations; the idea was finally approved.

Here are the specifics of the approval --- As managers each one of us were now allocated with three-dollars-per-team-member-per-month with which we were free to increase the team morale and make the environment (and the world) a better place to live in.

If you still did not get the ironic-humor in this; dear reader; allow me to explain. What this effectively meant was that if you had a team of five developers you had a full fifteen dollars a month to treat them, give them iPods, T-Shirts, organize project parities for them or even get your team a common X-Box.

None of us talked about the 'budget' after that day.

The budget that was allocated to us was never used and we decided to shit-can the idea.

Fun Is Serious Stuff --- And It Is Not Cheap Either.

The awesome part about being in a kickass team is that you do not need a lot of organizational funding to build great relationships with team members. Leave a kickass team of genuine builders and story tellers alone and they will attract other builders and story tellers.

Get enough insane trouble makers or rule breakers in your team and they will find out ways to have fun --- with or without the organization's involvement.

The interesting thing about hiring intelligent people is that even if they are not very articulate and expressive about what they see, observe and realize most of them understand the organization at a level that is much deeper than their managers even think they understand. So when the once hyped up morale budget was shit-canned by us; no-one in the team talked about it.

Everyone understood.

We just decided to forget it almost like failed childhood ambition.

Even though we lacked words to explain what had gone wrong with the overall idea; everyone in the  team; including the junior most engineer who knew about the idea; understood exactly what had gone wrong with the idea.

What this incident really did was teach me the level of importance most organizations out there give to the idea of 'fun' in the work environment. Some of the best organizations out there might spend hours talking about the idea of creating 'fun-filled' environments but talk about expenses associated with 'fun' and chances are that you might hear the sound of crickets chirping.

Fun Is Not Very Expensive Either - The Nine Ten Rule.

"So Pops; are you by any chance suggesting that we spend millions creating a fun work environment" - you frown.

What I really learnt from the whole 'fun-budget-episode' at Multiplitaxion Inc, was that there is a price associated with creating remarkable fun filled environments. It does not come cheap.

Having said that is it not the Hollywood-Dream that most organizations discard as unachievable.

To prove my point; dear reader; allow me to propose the Nine-Ten-Rule.

If you own an organization; or are responsible for budgeting; might I suggest that for every ten employees that you need:

1. Don't hire the tenth employee; just hire nine.
2. Take the average salary of the nine employees; consider it the salary of the tenth employee and add that to your overall 'fun' budget.
3. Allow the team of nine to decide what they want to do with this budget.

It's not exactly the programmers bill of rights but it's a good start.

Sometimes; Nine Is Much Better Then Ten.

Happy builders; build more and if you have spent enough time and energy at hiring the right people for the right job; chances are that with the fun element thrown in; your team of nine; will be much more productive than a team of ten mediocre programmers.

I don't know about you; dear reader; but I would rather have nine really happy tribe members over ten unsatisfied grumbling disconnected average employees.

At Multiplitaxion Inc; we were a closely knit team; having fun; meeting on weekends; going out together; but the passionate idea of adding fun to the overall 'organizational' environment was just not there.

With three-dollars-per-employee-per-month; we had seen; first hand; how seriously Multiplitaxion Inc; took the idea of 'fun' --- and having seen that first hand --- when it came to having fun at an 'organizational' level --- we hibernated.

The soul of this entire post; dear reader; if squeezed in a couple of lines; would come to this --- Two roads diverged in the yellow woods; and given the choice between a mediocre work environment of ten average employees and a seriously kickass fun filled environment of nine tribe members; Multiplitaxion Inc, walked the easy-safe and boring first path.

Which path has your organization taken?

Do you think your organization is 'man enough' to adapt the nine-ten-rule?

How seriously; does your organization take the idea of 'fun'; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

The Skip

Fred is at my desk on a Monday morning.

Fred; as usual has a problem with his manager.

I cringe.

What Fred is indulging in right now; can be otherwise referred to as a 'skip'. Put very simply; skip --- is a time when you decide to stop reporting to your boss and 'skip up' to your boss's boss.

Whether you are a manager or a young and budding engineer; chances are that you have either used 'skips' or have witnessed a couple of skips being used in your professional life.

Who has the ability to exercise 'skips' in your organization; to a large extent; will eventually define the whiner to builder ratio that ultimately prevails in your organization.

Positive Skips

During my young and budding days as an engineer at Multiplitaxion Inc; we worked on countless weekends and late nights for more than a year; only to discover when the year ended that no-one other than our reporting manager knew what we were working on. Turns out; this young and budding manager of ours had a history for quietly absorbing every single drop of credit without passing a single iota of it over to anyone in the team.

Months later; me along with a couple of engineers decided to exercise the 'skip' when our manager was out on vacation.

We slogged countless hours to finish a project three weeks before it's finish date; purely because we wanted to send the completion email before our manager returned from his vacation. Doing that allowed us to strike a conversation with a technical director of the organization and open up a new communication channel that did not exist before.

Put simply; it allowed us to ship; and show rather evidently; that we actually functioned better as a team without this manager of ours.

It worked.

Within weeks we had a lot more flexibility of taking decisions; dropping features and doing what worked best for the product. 

If I can think of the number of times I've exercised a skip in my; I would consider skips as 'isolated' and a rather rare events in my life. If I'm reporting to you; the only quality I expect out of you; for me not to even think about exercising a skip is --- empathy.

Unless you are a downright asshole; skips are off-limits in my professional life.

However; If you are an asshole and if you give me an opportunity to exercise a skip --- I will.

Negative Skips

Today; every once in a while I see a young and budding engineer like Fred; trying to exercise a 'skip' on his manager. Skips; which were a rare incident; and a rather powerful tool in the hands of builders when we were growing up as young and budding engineers seems to have transformed into a tool to jump up to the next level for ambitious but incapable programmers in the software development world of today.

I've seen:

1. A young and budding engineer take a shot at estimation where he was merely a part of an email alias that was CC'ed when a vice-president asked a technical architect to do the estimation. Turns out; the architect was off for a day and this young and budding engineer couldn't resist sending a 3x higher man-hour estimate only to make a fool of himself.
2. A young and budding developer gate crash into a Vice President's room to introduce himself and talk about what he was working on; only to find out that his manager had already kept the vice-president well informed about the great job this developer was doing.
3. A young and budding developer seeking help and advice from a technical director ever time he had any difficulties with an implementation; only to be gently requested by the technical director that it would be good if he asked his team lead before he approached someone else.

Handling Skips

If you manage managers; or team leads; chances are that every once in a while you will see someone attempting a 'skip'. Which skips you entertain and which ones you do not; will eventually decide who thrives in your organization --- builders or whiners.

Not entertaining a positive skip of a genuine builder is seeking due credit and recognition for his work can have long term catastrophic effects on your organization or your team.

Entertaining too many 'skips' or encouraging them as a general practice; can be equally catastrophic and destroy the very team spirit that is the secret sauce for success of your organization or your team.

I cannot give you rules to help you decide which skips you should entertain and which you do not; but every time I see a manager exploiting his team; I feel like gently nudging a member or two to exercise a 'skip'.

Every time I see a Fred; who isn't seriously a kickass builder himself; trying to exercise a 'skip' on his capable manager; by giving me details of every single line of code he wrote --- I cringe.

Skips are powerful tools; use them wisely and teach your team to use them wisely.

How many examples of skips have you seen in your professional life?

How many of them have been positive and how many of them have been negative?

Have you ever felt the need to exercise a skip yourself; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

A few months ago; we announced open sourcing of Crux; an application development framework and a lightweight workflow engine rolled into one; build on the .NET platform. If you want to know more about Crux; you can read more about it here.

Since it's birth and since we posted the initial code base that we wrote; the Crux development team has been putting in quite a bit of effort to roll out some fairly interesting features.

Here's a list of some features that you can try out today by grabbing a zip of the latest copy of the code base:

Application Injection

Crux is supposed to give you the basic framework to build applications on top of. A basic virgin deployment of Crux pretty much looks like this:

With Application injection; we make it easy for you to extend Crux without having to modify it's core or without having to modify the crux-code-base. By uploading one folder with custom ASP.NET pages and a single configuration file; you can extend Crux and inject your own application into it. If your application contains multiple modules or navigation items each one of them show up on crux as soon as your application in injected into Crux.

How this is different from multiple Portal frameworks out there is that while you inject Portlets into your portal; with Crux you will be able to upload full blown applications built using standard ASP.NET.

Currently you can inject just one application per Crux instance but we are working on features which will allow you to inject multiple application on Crux instance. We are also working on making Visual Studio Templates which will allow you to click File / New / Project / Crux Application - using Visual Studio - and start writing code for your custom application.

The idea of application injection is critical to the adoption and growth of Crux because we have multiple teams within eFORCE using Crux for their projects now and we want to allow them to upgrade the underlying version of Crux without impacting their own application.

The idea of application injection into Crux also becomes important because one of our ultimate goals is that developers outside of eFORCE should be able to build Crux applications; package them; share them with the rest of the community or even sell them if they want to.

We will be working on packaging this feature and will be giving you features to upload zipped installations of Crux-Applications into Crux using a web based user-interface which the Super-Administrator can use to upload Crux-Applications in later releases of Crux.

Extendable Dashboard

While the ability to inject applications into Crux is fine-and-dandy there are times when our project teams using Crux want an ability to extend existing crux screens (we call them dashboards). Here is what a typical dashboard looks like:

With crux you now have the ability to extend these dashboards and map them to parts of your injected application without touching the crux-code base. The application that you inject can contain configuration which allows it to add items to and extend the existing dashboards inside crux:

The same feature also allows you to create completely new dashboards inside of Crux without writing any code.

Other Features

Additional features we have added include Internationalization and the ability to create and manage your own roles instead of being satisfied with what Crux gives you. These came in as patches which have been reviewed; slightly modified and applied into the Crux code-base.

Crux has already seen multiple successful implementations at eFORCE.

The development cycles are fairly fast and we are adding new features.

We have not yet tagged Crux as 'version 1.0' and are going to be leaving it in pre-beta stage for a few more weeks; but we would encourage you; dear reader; to go grab the latest copy of the code base; play with it and send us feedback.

More features; posts and training videos on Crux will be rolled out as we move forward.

We will also be announcing more open source goodness around crux soon --- stay tuned.