free html hit counter
Posted on: Saturday, September 11, 2010 by Rajiv Popat

Leadership Tip: Staying Away From Random Stupid Unpredictably.

What is your role in your organization?

What are you responsible for?

I know you are confused about your existence in your organization.

I know your designation means nothing.

But if you are a kickass programmer these are probably not the things that bother you as much as random stupid unpredictability in your work life.

Lets jump into the depths of time and bring from the ages that have rolled behind, the gist of what pissed off the best of the programmers at Multiplitaxion Inc. It was movement. Unpredictable, completely irrational and sometimes hugely irritating movement.

As a programmer you spent months working on a project. Putting in sweat and blood on the project and getting attached to it, only to be told one fine morning that you are now going to have an idiotic moron leading the project and you are expected to report to him.

Then there were historic moments where some of the most kickass programmers walked into office only to find out that they were expected to move to a different project all together and start their knowledge transfer effective the very same day.

As programmers we spend multiple hours a day talking to the compiler, where we expect the same consistent, coherent results for the same code written over and over again. We look for systems even when we are connecting to other human beings. The best of your geeks are afraid of unpredictability specially the kind that has 'stupidity' written all over it.

As a manager it is your responsibility that you reduce the element of unpredictability that gets thrown in your team's way to a minimum and if there is unpredictability it is positive unpredictability that challenges them and helps them grow stronger neurons. If you cannot do that the least you can do is be open about the changes in your organization and have no secrets. Transmit information openly.

If you must move them to a different project, do you have a genuine cause for doing that? Are you explaining your thoughts and your rational to them before you move them or are you basically passing orders from the ivory towers of management?

It takes years of solid teamwork, multiple streaks of good luck and a lot of stars have to align before you become a part of a project that is awesome, that rocks and that has the potential of making a dent in the universe of a small group of people or an industry.

All it takes to ruin that is a couple of stupid random unpredictable decisions that you impose on your team without discussing things with them, without listening to them and without giving them a chance to react.

There are multiple awesome projects that might be running in your team right now. A couple of programmers are spending their night time to work on aspects of your project that might take your project to the next level. The real question is, are you going to listen or are you just going to take random decisions and move people around like pawns on a chessboard?

Choose wisely, because your choice ultimately decides the future of your team and your projects.

posted on Saturday, September 11, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, September 10, 2010 by Rajiv Popat

Advice For Managers: Even If You Don't Have Work To Keep Yourself Occupied, Get A Life.

Back in the days at Multiplitaxion Inc, Fred tends to throw random ad-hoc work on our plates every time he sees us passing by the corridors of the office.

More often than once we find ourselves gathered in the cafeteria discussing what it is that Fred himself does.

Michael Lopp explains this rather articulately in his book, Managing Humans. He explains:

“What, exactly, do you do?”

Slack.
Jawed.
Amazement.

This question is coming from someone I trust. A trusted employee who has been working in my group at the startup for years. This guy always tells me the straight dope and now he’s asking me what I do with my day because he honestly does not know.

My first reaction to this question is the wrong one. I want to leap over the table, grab my friend by the shoulders, shake him, and yell, “While you were uselessly staring at that one bug this morning, I was keeping this organization moving, pal.” My second reaction is to take a deep breath, so I do.

This basic what-do-you-do disconnect between employees and managers is at the heart of why folks don’t trust their managers or find them to be evil.

But the real problem here isn't the fact that Fred is incapable of answering the what it is that you do here question.

The most evil of managers are not the ones who cannot answer that question. In fact, the stupidest of managers are also not the ones who do not have much work on any given day. Most developers are used to both these kinds. Add a little bit of empathy to their characters and these two kinds are not really all that dangerous after all.

In fact, they might be adding secret ingredients to your project and your organization, quietly and subtly.

These are not the kinds that typically do the most damage.

The ones who do the most damage to your project, work and your team are the ones who don't have any work and to add to that, don't have a life either.

This is the breed that goes around the office with a printout of a project plan, the breed that buzzes the development team three times a day, the breed that organizes meetings that run hours and the breed that pulls out the stupidest of ideas or features straight out of their ass and then insist that they get implemented even when no one really needs them.

So, if you are a manager, the next time you walk up to someone's desk with a project plan in your hand and ask him the status of his module for the third time in that day because you don't have any other meetings to attend, remember that while you might not have anything to do, others in your team might be busy doing some real work.

Don't have work?

The least you can do is stop inventing random work for others and get a life.

Find a video game, play Farmville, take your son out, spend some quality time with your family, go home and stop bothering your team. Consider working less, even if you think you are supposed to 'drive and manage' the team. Seriously.

posted on Friday, September 10, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, September 5, 2010 by Rajiv Popat

Leadership Tip: Too Many Drivers Will Not Take Your Car Anywhere.

We have all seen these emails. Emails from your Vice President where he wants a certain Fred to look at your project and provide “inputs”.

You know the famous architecture team story by Joel Spolsky.

That kind of inputs.

Before you know it, "consultants" with terrible blind spots who are awesome at playing the jargon game and who have zero knowhow about the domain, zero understanding of your team dynamics and zero expertise in the technical space are meddling in every decision your team is taking.

Well not exactly those consultants, but if you have been through an architecture review meeting with external consultants you know exactly what I am talking about here.

Every small change is questioned and discussed in meetings that no productive programmer would want to attend in the first place but then you suddenly find yourself in these meetings spending hours defending the most common sense driven decisions you took.

You know your car is going round and round in circles. You are not getting anywhere. The fact that you are going around in circles is common sense. You have too many drivers fighting to take control of the driving wheel.

Obviously, you are not moving ahead. Obviously, throwing in more drivers is not going to solve the problem. Obviously, you need to pick a single driver to drive your project. Obviously, you need to check his track record closely before you pick him. Obviously, you need to learn how to trust him. But then again, obviously, obvious is not so obvious, especially when it comes to big organizations that are trying to pretend to be even bigger than they really are.

If you run a team or an organization, remember that every time you get more than one driver at the wheel you run the risk of getting nowhere. So the next time you invite those external consultants to review a project that is moving just fine or fu@#k up a department that is moving along smoothly, think twice.

Here is my humble word of advice from the forefronts of software development: Pick a single capable trust worthy driver. It doesn’t matter who you pick, as long as the person is competent and trust worthy.

Then move to the back seat and let the person you picked drive without bothering him.

You may not get to your exact destination. You might get just a little closer to it. But then at least it is better than moving round and round in circles.

I wish you good luck.

posted on Sunday, September 5, 2010 9:25:20 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, September 4, 2010 by Rajiv Popat

Working On Enterprise Software Is Not An Excuse For Building Software That Sucks.

Do you want to really see the worst of software that exists on the surface of planet earth? A few funny examples aside, chances are, that you are not going to find it online. If you are looking for some genuine gems of stupidity, lack of vision, bad design or just down right stupid implementations,  go look at the applications that power the intranet of some of the so called big enterprises or the fortune five thousand.

Khoi Vinh takes the famous analogy of duck typing: "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck" and turns it into a rather interesting satire on enterprise software. He calls it: "If It Looks Like a Cow, Swims Like a Dolphin and Quacks Like a Duck, It Must Be Enterprise Software"

Khoi also provides his logic on why he believes enterprise software stinks even after the countless dollars that are poured into the efforts of building these applications. He explains:

This is partly because enterprise software rarely gets critiqued the way even a US$30 piece of shareware will. It doesn’t benefit from the rigor of a wide and varied base of users, many of whom will freely offer merciless feedback, goading and demanding it to be better with each new release.

Shielded away from the bright scrutiny of the consumer marketplace and beholden only to a relatively small coterie of information technology managers who are concerned primarily with stability, security and the continual justification of their jobs and staffs, enterprise software answers to few actual users.

Given that hothouse environment, it’s only natural that the result is often very strange.

Of course, most people who take the buying decisions in the enterprise world are going to have blind spots but If you are a programmer with basic ethics and self respect who happens to build software for the enterprise, the first question you need to ask yourself is this:

How do you take the same software, shred off the elements of complexity out of it, stop bitching about performance and add a touch of genuine magic, simplicity, genuinely kickass speed and interactivity to your applications.

Google Apps does it with its paid offering. They take the simple, easy to use, light weight applications designed for end users, tested by millions of live real life users and offer it to the enterprise with added features, more space and a premium price.

If you look into the approach it is rather simple and straight forward. You build for the end consumer. Then once you have enough people using it for free, you let enterprises adapt it and pay for it. You stop bitching about performance and you actually build fast applications. You focus on simplicity, ease of use, easy adaption and you build with the purest of intent.

As rework the famous book by the guys at 37Signals describes, the suits at enterprises that make the buying decisions and sign off paychecks don't wake up in morning wishing they had more slower, sloppier or complicated applications.

So if you are a developer or a technical manager, stop using the fact that you build an enterprise application as an excuse for slapping together random text boxes, drop down lists and option buttons, frameworks, building weird things and calling them enterprise applications. Continue to master the art of simplification. Even your enterprise users will love you for it. After all, working on Enterprise software is not an excuse for building software that sucks. Seriously.

posted on Saturday, September 4, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Friday, September 3, 2010 by Rajiv Popat

Advice For Lurkers: Adding Genuine Value By Being Raw And Completely Real.

You there; if you are reading this you probably have something you can teach us; something you can build or maybe a story to tell. Some insightful content, some meaningful software or a product that can change our lives in the tiniest of ways, maybe just for a couple of days.

Maybe you can make us smile. Maybe you can make us laugh. Maybe you can make us take a pause from our routine, mediocre, mundane lives and nudge us to think. Maybe you can give us a tool or a utility that you were working on last week.

The real question is, are you giving us any of that? 

If not, why?

You are afraid of failing. Aren’t you?

Actually, you are shit scared.

You already know that the 'I don't have time' is the lamest of excuses you have given yourself for years, haven't you? 'I want it to be really good before I release it' - that is a lame excuse too.

Of course you want to spend time and sign stuff you put online. Put finishing touches to it. Polish it. Make it the best you can. All you need is a little bit of time. Newsflash – you are never going to have that ‘little bit of time’.

Remember, you don’t have to be the best to have an audience. You don’t even need an audience. Just being loud, being opinionated and adding a little bit of genuine value with an intent that is pure and clean, is all we, you readers, followers, subscribers, audience (or whatever it is that you want to call us) expect from you.

Show us what you’ve got. We don’t want you to polish it for hours. We don’t want a formal website with professionally done videos surrounding it. We don’t want marketing weasels selling us crap. We don’t want impotent words or formal introductions of your product.

Show us a little bit of yourself through your product, service or whatever it is that you have to offer.

Make it Raw. Unedited. Real.

Even if it is as raw, unedited and real as the videos from Khan Academy.

Salman Kahn from Khan Academy explains this rather articulately in his video on the topic.

Normally, I would have quoted from the video, but this one is fairly inspirational and I would rather than you take the twenty minutes and see the video for yourself

The takeaway from all of this?

If your intent is pure and you are adding value, we will listen. And if you continue doing it long enough, consistently we might even spread the word for you.

Now go give us something meaningful, cute, smart, sexy, funny, or simple and informative.

Give us a little bit of you.

The you that moo's and the you that is purple.

I wish you good luck.

posted on Friday, September 3, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, August 29, 2010 by Rajiv Popat

Programmer Tip: Find The Momentum That Keeps You Moving And Learning.

I have blogged out the importance of consistency time and again.

Kickass builders and story tellers keep jabbing.

The metaphor is that of running or working out. If you are not consistently shipping, you are not in growing.

Having said that, every single one of us, go through bouts of nothingness and depressions where we are just not in the zone. Seth Godin describes the problem and the solution in a rather articulate and concise way in his post on the topic. He explains:

Some days, even the best dentist doesn't feel like being a dentist.

And a lifeguard might not feel like being a lifeguard.

Fortunately, they have appointments, commitments and jobs. They have to show up. They have to start doing the work. And most of the time, this jump start is sufficient to get them over the hump, and then they go back to being in the zone and doing their best work.

Momentum is incredibly useful to someone who has to overcome fear, dig in deep and ship.

Momentum gives you a reason to overcome your fear and do your art, because there are outside forces and obligations that keep you moving. Without them, you'd probably stumble and fall.

Slowly exercising your creative mussels and growing out of your comfort area is a simple way to get started. You can even use you insecurity to nudge you on the path. At times a counter which humiliates you in public might do the trick.  On other occasions a simple turn of switch in your brain or being shaken up by an idea might work too.

The tools are numerous. Pick a few that you are most comfortable with and use them. What ever it is that you do, always remember that nature designed us to become lion lunch the moment we became sedentary and that implementation hasn't been redesigned yet.

So keep the momentum going, even if it is just one step you are taking each day.

Oh and yes, a lot of talking is not a step forward. Do something real. Work on something concrete. Ship.

Consistently.

I wish you good luck.

posted on Sunday, August 29, 2010 10:30:48 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, August 28, 2010 by Rajiv Popat

Leadership Tip: Avoiding Blind Spots For Stupidity Within Your Organization.

You look at the stupidity that happens in your organization and you tell yourself, "WTF! Why cant they see something as clear and stupid simple as this?".  And then after a few meetings you stop giving a f@#ck, slip into hibernation and start doing your 'job'.

Scott Berkun describes the situation rather articulately in his post about the topic of fighting management incompetence. He explains:

The big incompetence crime committed by VPs is leaving incompetent managers in place for too long. My theory: by the time the CEO knows a VP stinks, the whole org has known about it for months. The smart people have been making plans to leave or are working to cover their assses. By the time the CEO gets around to taking action, it’s way too late. And often the action taken is whitewashed: no mention is made of how the VP or middle manager utterly failed (e.g. “Fred has decided it’s time for something new.”) The denial lives on, the lie propagates, making it easier for more denials and lies the next time around.

But then the real question that continues to confuse and amuse me is this; why do so many people so high up in the pecking order of really big organizations prefer to live in the state of denial? Are they complete morons, down right idiots or arrogant pompous fools who managed to peck on others and climb the corporate latter of prickdom?

The answer however, might be none of these. John Cleese on his video about creativity might have hit upon the answer using simple science and logic. He explains:

To know how good you are at something, requires the same skills as it does to be good that thing. Which means if you are accidently hopeless at something, you lack exactly the skills that you need to know that you are absolutely hopeless at it.

And this is a profound discovery. Most people who have absolutely no idea what they are doing have absolutely no idea that they have no idea  of what they are doing.

It explains a great deal of life. It explains particularly Hollywood. But it also explains why so many people in charge of so many organizations have no idea what they are doing.

They have a terrible blind spot.

And the problem with teachers may be that the teachers do not realize that they themselves are not very creative and therefore they may not value creativity even if they can recognize it.

The approach mostly explains why kickass developers find it painful when they are asked to work with non-technical managers who had never coded or were never really good at coding in their entire life.  It also explains why so many people high up in the pecking order of countless organizations around the world do not see what every developer who walks the corridor of the organization sees.

So the next time you are asked to lead a team, work on a project, or lead a department take a long pause and ask yourself if you are really good at what you are going to be leading people on. I know there is an impulsive voice within you dying to say - 'of course I know what I am talking about!' - but hold it. Relax. Give it some soak time. Be really honest about it. What are your credentials on that specific topic?

You might have been an amazing programmer. That does not make you a good manager. You might have been an amazing manager, that will not make you a good entrepreneur. You might have been a really successful entrepreneur, but that that may not make you the best programmer. You might have built an amazing system, that does not make you a person who can drive a community.

Before you decide to get actively involved and lead from the front, think. Sometimes handing the driving wheel to someone else who knows how to drive is a way better option. Seriously.

posted on Saturday, August 28, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, August 27, 2010 by Rajiv Popat

Programmer Tip: The Meaning Of Mentorship And How You Grow As A Person

Jack triggers a casual conversation about his need for mentorship

Yes, that mentorship where he is looking for an 'in office mentor' to handhold him and help him grow technically. He feels he is not 'growing' because he does not have a mentor who can train him.

He talks at length about the glory of his past mentors as you listen in silence. You happen to know and respect some of these guys that he is talking about, personally. Five minutes into the conversation and you have realized the absurdity of it all.

Respecting someone for his talents and wisdom is perfect but when people start putting other human beings on a pedestal higher than themselves and start hoping that these mentors will show them the way, strange things happen.

You look at Jack wondering if you should tell him to snap out of the Matrix. You wonder if he is ready for the red pill.

That red pill.

Then you do it. You ask him to name one hugely successful project of one of these mentors that he is talking about actually led from the forefront.

Silence. Crickets chirping.

Ok, how many times did this mentor of his actually conduct a training where he wrote code that inspired Jack?

More crickets.

Newsflash! These mentors were just as lost and confused as Jack himself or me.

Ours is a business where we mix way too many things together. We mix authorship with authority, years of experience with technical competence, a condescending attitude with power or wisdom and respect with mentorship. We see people with power or authority and assume that just because they were able to get themselves in a position where they can demonstrate power or authority, we need stop questioning and start following them.

The red pill in the software development world is about challenging the validity of every human being you learn from. Question everything that they have to say. Look for your own facts, take your own decisions and make your own judgment calls.

As you read this, you are either nodding your head in agreement or shaking it in disagreement. I am not going to try and convince you one way or the other because becoming your mentor is the last thing that is on my mind. I am not good enough to mentor anyone and I have no misconnections about that.

If I can just collaborate with a few interesting minds around the world, learn something from them, teach them a thing or two and exchange ideas worth sharing with them, I have done my part.

Now stop cribbing about not having a mentor at your workplace. Go find the best alpha geeks and loud characters out there and collaborate with them. Mentorship is not a one way street. It's cluster-fuck of hundreds of minds engaging in countless battles of ideas, facts or techniques and learning from  those battles. These battles can cause a few scars but once you get the point they are so worth the scars they cause.

Now the real question you have you ask yourself is:

Are you man enough to put yourself out there and participate?

Go on. Connect with the best of the minds you can find and then learn from them. I dare you.

posted on Friday, August 27, 2010 4:21:00 AM UTC by Rajiv Popat  #    Comments [2]