[Typo3-dev] The Right Crew

Erik Svendsen erik at linnearad.no
Thu Oct 27 21:23:35 CEST 2005


Hello Kasper,

My respond is maybe at bit different from others. Mostly because I'm not 
a developer (even if do some of it on spare time), and primarly working with 
strategic themes, team leadership e.g.

> A true concern I have is this; How do we channel all the great
> resources from
> the TYPO3 community into a unified effort on the development of TYPO3
> which
> does not compromise the quality or impose great levels of overhead.

The right question.
 
> THE RIGHT CREW:
> Does every member of our future TYPO3 crew need all of these skills?
> Vision: Not everyone needs to be visionary, in fact only a few might
> be preferable. I don't think visions are our problem. Maybe it could
> be a problem to agree on which visions to follow. Yet, a more serious
> problem is how the visions of functionality and code architecture can
> be adopted by those who are going to implement it (if we assume they
> are not necessarily the same as the visionaries)?

Visions are important, but not only visions, but also the ability to inspire 
others. Not everyone with visions have the ability to inspire. I think you 
have. And people with visions also need the ability to take a rest from new 
vision when the crew (team/group) need time to make the current visions work.
 
> Pragmatism: One a continuum from visionary-coder-releasemanager the
> visionary could do with almost not pragmatism, the coders would have
> to live with a mixture and release managers must be very pragmatic.
> The interesting focus is the coders in the middle, because their
> responsibility is to make sure things are working today and tomorrow
> but in the long term pay attention to the visionaries direction. How
> can this be implemented in a way that doesn't break backwards
> compatibility between each release and at the same time is inspiring
> to coders?

I agree. Be sure that every crew has people that are pragmatic, but not conservative. 
And certainly not idea killers. The right kind of pragmatic people are the 
people who are able to use it to ask the right questions or ideas to solve 
the problem the practical way.
 
> Stamina: This one is - unfortunately - necessary for every link in the 
chain.
> To build anything as teamwork it is critical that every team member can be
> trusted to carry his part to the end. The unfortunate thing is that most
> people involved in volunteer work think that they can feel less committed 
to
> the cause because they are not paid and usually prioritize their paid work
> and opporties higher assuming that everybody will understand. Maybe others
> will understand but it just doesn't solve be huge problem it creates: When
> people are constantly running in and out of volunteer commitments it 
> generates huge amounts of wasted overhead in the form of training, social
> investment etc. in the team! The impact on the volunteer context is even
> worse than for a company because a company could pay someone to deal with
> such overhead while in the volunteer context it is OTHER volunteers who 
waste
> their time on training a new volunteer that just disappears a few days, 
weeks
> or months after.
> To make matters even worse for our online community it has been the general
> experience that people slip out even easier because they don't risk to face

Lack of commitment are the main reasons that project depending om teamwork 
fails. And not only in volunteer online community. Even in other organisations 
with employes, and possibility to use sanctions and rewards, lack of commitment 
can be a huge problem. But there are ways to reduce this problem, even with 
voluntary work. To explain it in detail would be a bit to much for this post. 
(It's written hundreds of books and articles on the subject). But in short 
some of the point could be.
- How you organise and share knowlegde in the team (crew). The main point 
is to organise the work and knowlegde sharing in a way that minimize the 
effect of people leaving. Because you even with high commitment you can't 
avoid that some will leave.
- Pick the right crew if you have the opportunity (not always possible). 
The team should have a good mix of the neccessary knowlegde and abilities.
- Think about rewarding people. And rewarding isn't only money. A lot of 
people has values that make it possible to reward them other ways. I just 
read Peter's post about recognition his work. This is a prime example of 
negative rewards. To have fun are another reward for many.
- Leadership and coordination of the crew is important. Even in volunteer 
team this is important. The right leader/leaders can make the impossible 
to happen. Maybe the crew(team) should have a member who are a wiz in getting 
all practical things to work (like groupware, communicating channels), and 
follow up the team.
- The crewmember must accept and respect the associations decissions on roadmap, 
visions and future. It dosn't mean that discussions aren't allowed but that 
you accept the fact that someone has to take the decissions. Also as Peter 
write - guidelines.

I notice that most of the post are about development paths, visions and so 
on. Only focus on this will not getting future crew (teams) to success. Teamwork 
are a lot about social connections. Even in virtual teams. My own experience 
working in virtual and non-virtual teams for nearly 20 years. And events 
like the Snowboard Tour and TYCON3 have positive impact on these connections.

My approach are different, because the ability to have visions, beeing pragmatic, 
having stamina, commit and sosial ability are the same regardless of which 
development path or methodology who are used. Even if you use the second 
or third best tools, if you manage to succed in people commit in crew/teams 
you will have success. And there are people, regardless of their competence 
in programming or other skills who never should be in a crew (team) that 
needs to interact. Let it be said, I have dropped people from teams who without 
doubt was the best skilled, but who would ruined the team. 

Kasper, it looks really like you understand the problems getting a voluntary 
community form teams who are going to do the work. And if you or/and the 
active members find it helpful that I are broading my points, I will with 
pleasure do that. Either as a more complete document, or face to face.

Wish you all the best

WBR,
Erik Svendsen
www.linnearad.no






More information about the TYPO3-dev mailing list