23rd of October, 2009
In the summer I blogged about SOA and wondered out loud if true SOA was impossible to implement in some organizations due to the organizational structure itself. Janie Chang at Microsoft Research wrote an excellent article that touched on the subject.
To quote Janie:
The system will resemble the organization building the system.
I agree with this assertion completely. Team culture and structure can vary widely even within the same organization. Over the past ten years I’ve worked on a variety of teams. Some were incredibly flexible and passionate with a strong focus on best practices, evolving processes, geographically distributed workforce, and engaged developers. Others were quite reluctant — or unable — to change; waterfall to the core, a local workforce, no telecommuting or flex-hours, rigid processes owned at a high-level of the organization, and disengaged developers.
In my experience I’ve noticed that flexible and adaptable organizations produce flexible and adaptable applications. Rigid and inflexible organizations tend to produce rigid and inflexible applications. Co-incidence?
Another interesting observation Janie made is how the geographical distance of team members affects software quality.
I’ve worked in teams that have varying opinions on this. One team in particular stressed telecommuting as the norm; if you didn’t have a face-to-face meeting, you were encouraged to work wherever you felt you’d be the most productive that day. For me, telecommuting isn’t that big of a deal; I live and work downtown, so I usually walk to work. But rolling out telecommuting had a noticeable, positive impact on my co-workers. They seemed much less stressed and much more engaged.
As one of my colleagues put it:
I could spend three hours in the car, or an extra hour coding and two extra hours with my kids.
My own experience in this team was extraordinarily positive. Instead of measuring success by the number of hours spent at a desk, the team measured success by results. Communication was a highly-valued skill and team members tended to communicate heavily — via Skype, instant messaging, and the regular old telephone. Actually, the team tended to communicate with each other more when they were out of the office than when they were in the office.
Janie mentioned the same phenomenon:
Most people preferred to talk to someone from their own organization 4,000 miles away rather than someone only five doors down the hall but from a different organization. Organizational cohesiveness played a bigger role than geographical distance.
The days that everyone spent together at the office together simply re-enforced the overall cohesiveness of the team.
On the flip side, I’ve worked in a team where the motto was, “If your job could be done from home, your job could be done from India”. Needless to say the organizational structure was rigid, the applications they produced were of low quality, and morale was crap. It wasn’t necessarily the fault of the developers, they were just completely disengaged due to an old-school mentality towards development. It’s essentially the difference between an industrial age management style versus an information age management style. Time versus results. Warming up a chair versus building cool shit.
This leads me to believe that while the technology itself is a critical aspect of a project, organizations that fail to innovate structurally and culturally as well as technically are failing to see the big picture.