This blog has been about my search for answers which have profound meaning in my life. As I write and learn, the goal, dear reader, is to involve you in my search for these answers. One of the things that has confused me as far as software development and life in general is concerned is 'success'. I've seen teams of really programmers having the best of the academic background fail project after project when a simple catalyst and a small teams of humble hard workers manage to break the infinite loop of failure as they cruise through projects; successfully.
In my career I've been a part of quite a few projects. I've observed others from the outside and analyzed them like a black box is analyzed after a plane crash. A huge number of them fail because of lack of a kick-ass team; however, the more I analyze these failures and the more I 'grow' as a person, I continue to learn that of these huge number of failed projects that I've witnessed quite a few of them had teams comprising of some really smart individuals, who were strangely and weirdly, acting like perfect clowns leading their projects into the path of failure.
When I sit back to reflect on some of these projects I realize that none of the posts about successful projects that I've written in this blog, till date, explain some of the failures I've witnessed. I've seen small teams with technically competent developers fall flat on their face and their project snowballed into a massive failure because of little things. All of them were fairly competent individually; but when they came together they started acting like perfect clowns.
What is it then, besides competence, that results in successful projects?
I'll give you a hint - it's not RUP or CMM. No, it's not even 'just competence'.
Jeff Atwood describes the secret sauce of successful teams and does a good job at describing the source of all problems in software development:
|
Let's say I was tasked with determining whether your software project will fail. With the responses to these three questions in hand, I can tell you with almost utter certainty whether your project will fail:
That last question isn't a joke. I'm not kidding. Do you like the company of your teammates on a personal level? Do you respect your teammates professionally? If you were starting at another company, would you invite your coworkers along? Do you have spirited team discussions or knock-down, drag-out, last man standing filibuster team arguments? Are there any people on your team you'd "vote off the island" if you could? It may sound trivial to focus on the people you work with over more tangible things like, say, the actual work, or the particular technology you're using to do that work. But it isn't. The people you choose to work with are the most accurate predictor of job satisfaction I've ever found. And job satisfaction, based on my work experience to date, correlates perfectly with success. I have never seen a happy, healthy, gelled, socially functional software development team fail. It's a shame such teams are so rare. |
Happy, healthy, gelled, socially functional teams where the team members not just like working with each other but actually like each other as human beings and hugely respect for each other, are rare indeed. In my entire career till date, I've been a part of two teams that truly and fully, one-hundred-percent, fall in this category. While working with both these teams successful projects seemed like a destination towards which we were mostly cruising towards; on auto-pilot.
While working with, and being a part of both these teams, I personally delivered three projects with genuine value added and hugely happy clients who became allies in our success. What I also did during my work with these teams is a lot of soul-searching on why we were being successful.
Was every single individual in these teams a kick-ass programmer and a one man army?
Not really.
In fact, quite a few of us, me included, were pretty average programmers.
We were faced with the same perils of war that most software development teams face and we committed our share of stupidities. However the fact that team members liked each other and the 'mutual-trust-and-respect' factor made it that much more easier for people to become thick-skinned about their weaknesses and let someone else complement those with his strengths.
If you're responsible for hiring people in your organization, always remember, asking yourself if you would love to work with an individual is just as important as rating the individual on the technologies they are expected to work on.
If you are leading a team that you inherited or hired without this knowledge, besides your team members being amazing professionals, look around. Ask yourself some fundamental questions about the team and the team members in particular:
- Is there a silent, subtle competition happening internally within your team? Are members of your team are indirectly competing with each other?
- Do members of your team make you uncomfortable in social gatherings outside of office?
- If an individual was to resign and quit, would you feel secretly happy and relieved about the resignation?
If you answered yes, to any of the above problem, chances are your projects will fail one after the other; if you're really lucky, you will fumble your way to successful failures; but none the less you'll find software development very complicated and hard. If you answered with a confident no however, chances are that you and your team will auto-pilot their way to successful projects.
While Jeff questions - "If you were starting at another company, would you invite your coworkers along?" - I leave you dear reader with an even deeper and profound litmus test of the team that you are working with: If you were to start your own little dream venture that you really believed in or pet open source project, would you invite your team to join in? Would they accept your invitation?
Two way relationships involving respect, liking and mutual trust are the secret sauce of successful teams and successful careers around the world. There is not much you can do to ensure respect, liking and trust from the other side, but working on these qualities for yourself is as important as learning the next version of the programming language or the platform you work on. May I suggest, dear reader, you give conscious effort in this direction; even if you think you are the most liked person around.
Are you 'working with' a team? Do you consider them a part of your life vision and your extended team or just this current job? If your relationship resolves around just this gig, you probably don't have a well-gelled team. On the other hand if you can think of them as your extended team and a part of your life vision, you might be building projects that cruise on auto-pilot towards success when you work with such teams. Yes, competency is important; but the mutual-liking-and-respect factor is equally important. It's the secret sauce of the delicious success that amazing software development teams often achieve.
Comments are closed.