[Typo3-dev] The Right Crew

[Kasper Skårhøj]

Thank you Erik,

I like the direction you took on the subject. I'm not sure what the next
step to take is? I'm also in the middle of development so in fact I don't
have much time for this focus at the moment. 

What does Robert think? Robert, as the R&D team leader, do you see your role
being the motivating leader of the "workers"?

- kasper


Erik Svendsen wrote:

> 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

-- 
Kasper Skårhøj