Archive

Archive for the ‘Team Work’ Category

On Teams: Religious Debates Erode Respect

July 15th, 2010

“religious debates … consist largely of people expressing strongly held personal beliefs about things that can’t be proven. … they rarely result in anyone involved changing his or her personal view. … besides wasting time, these arguments create tension and erode respect among team members, and can often prevent the team from making critical decisions.” – Steve Krug, Don’t Make Me Think

There we have it, religious debates erode respect.

Author: Adam Kahtava Categories: Software, Team Work Tags:

On Teams: Leadership and Group Organization Matters

October 14th, 2008

This experiment draws some strong parallels to the software realm.

the experiments … organized some public school, middle-class eleven year olds into [clubs] with five boys in each and a carefully trained college student leader. 

Some of these collegiate club leaders were told to become autocratic. They gave detailed directions to the boys, telling them exactly how to paint their clubhouse signs or build model airplanes. Other, the laissez-faire leaders, stayed out of the way, and in the third group, “democratic” leaders helped the boys execute their own ideas, with as much non coercive guidance as possible.

Laissez-faire leadership, letting the boys do whatever they wanted, bred frustrated cynicism. Under authoritarianism, some boys became extremely obedient … while others fought, bullied each other, and destroyed their own toys. In the democratic groups, boys became more conscientious, more tolerant of each other, less selfish, and more adult.The Age of Heretics, Art Kliener

The reactions these groups exhibited, is similar to what I’ve experienced while working in software teams. The best experiences I’ve had have consistently been in democratically structured teams – with a very fine balance of aristocracy from a team lead or architect. it also follows that the most challenging teams have been rigidly autocratic or Laissez-faire (hands off, with no guidance).

If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology. … In an unconstrained implementation group, most thought and debate goes into architectural decisions, and implementation proper gets short shrift. – The Mythical Man-Month, Fred Brooks 

The balance between democracy and aristocracy is delicate. A team leaning too much on aristocracy runs the risk of undermining the team, while a overly democratic team can fall into paralysis which places the project’s completion in jeopardy.

Author: Adam Kahtava Categories: Personal, Team Work Tags:

Living The High-tech Illusion: Software Development is Not Rocket Surgery

June 15th, 2008

#CalgaryBarCamp was swell. It was refreshing to meet such a diverse group of like minded people that all essentially do the same thing (create software), but do it in different ways using different tools, platforms, and languages. The ad-hoc discussions both in the bar and between sessions were my highlight. A reoccurring theme in our conversations was that technology, tools, and platforms don’t matter that much. What really matters is: people, communication, ideas, taking risks, and motivation.

The topic of our discussions reminded me of something David Heinemeier Hansson said when talking about software development:

You don’t need to be a f***ing genius to make any of this stuff work, it’s not rocket surgery! – David Heinemeier Hansson at Startup School 08

DeMarco and Lister also echoed this outlook back in the 80′s, and publicized: the High-Tech Illusion:

the High-Tech Illusion: [is] the widely held conviction among people who deal with any aspect of new technology … that they are in … high-tech business. [These people] are indulging in this illusion whenever they find themselves explaining at a … party, say, that that they are “in computers” … The implication is that they are part of the high-tech world. [These people] usually aren’t. The researchers who made the fundamental breakthroughs in those areas are in the high-tech business. The rest of us are appliers of their work.Peopleware : Productive Projects and Teams

If we were in the High-Tech business, then we’d be the bottom feeders (the parasites, the grunts), because our daily activities revolve around consuming other peoples research and work (programming languages, platforms, frameworks and the like). We are consumers, we’re not on the cutting edge nor are we in the high-tech world.

Perhaps building software could be much like outfitting yourself for a day in the snow. You head off to the local shopping mall, you acquire the functional items to keep yourself warm, but brands and store choice don’t really matter. Whether we’re buying winter boots or choosing a programming language, technology doesn’t really matter. There are an infinite number of ways to solve any problem, as well as an infinite number of technical permutations to form a solution. If we can solve the problem within the constraints of our problem domain then we’ve succeeded.

On Teams: Thoughts, and Quotes related to Team Work

January 31st, 2008

Team work and interpersonal skills are absolutely essential for the present day knowledge worker (software developers, and the like). If you don’t like working in teams, don’t know how to work in a team, then you may not be able to find work.

In the larger software community, most agree that:

programming is a social activity, … being the lone wolf … is not what we do anymore - Douglas Crockford

And most of us have come to understand that:

Team dynamics; how well a team works together has a bigger impact on a project than the developer’s individual capabilities. [And that no] individual is a success who hurts the team, and no individual is a failure who helps it. – Software Project Survival Guide

So, it should come as no surprise when large companies that depends almost entirely on team work, lists Team working and interpersonal skills as the VERY most important business skill. – Computer knowledge ‘undervalued’

However; it’s often hard for the those in management to understand that you can’t force people into a team environment – let alone change or mold them. So, if someone doesn’t like working on teams, has never worked on a team, or doesn’t agree with your existing team’s cultural views, then you should ask why. Because:

the people that work for you through whatever period will be more or less the same at the end as they were at the beginning.  If they’re not right for the job from the start, they never will be. – Peopleware: Productive Projects and Teams

In reality, we have very little influence on our team members, poorly matched cultural values will likely result in poorly functioning teams, which in turn negatively results the projects success. Joel Spolsky takes this train of thought a little further and suggests that:

it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort – The Guerrilla Guide to Interviewing (version 3.0) 

However; most organizations don’t have the exposure that Spolsky does, and can hardly find candidates period – let alone the very best candidates. Often in the real world, the only chance you’ll have to guide (influence) any team of developers (or anyone), is to lead by example. Jeff Atwood offers some great advice: 

Cajoling and berating your coworkers into compliance isn’t an effective motivational technique for software developers, at least not in my experience. If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn’t to brainwash everyone you work with, but to negotiate … So much of leadership is learning to give a damn about other people, something that us programmers are notoriously bad at. We may love our machines and our code, but our teammates prove much more complicated. – Leading by Example

Team work and interpersonal skills are more important than technical skills. The ability to work in a team is absolutely mandatory for today’s software developer.

Author: Adam Kahtava Categories: Musings, Software, Team Work Tags: