Big organizations CAN motivate their software group

When working at a big organizations, developers are often siloed into working on one project and on potentially a legacy technology. Considering the speed at which the underlying technologies changes, what was considered cutting edge quickly becomes a thing of the past. As the developer grows in the organization, these legacy patterns and practices become standards and adapting to new technologies becomes that much harder. Managers at such organizations rely on these age old practices and especially on those who established them. New hires quickly get tired and look elsewhere for better opportunities. Keeping your current developer group motivated is probably the biggest challenge managers and the organization overall face.

Typically, highly motivated individuals along with individuals who have a passion for learning and adapting interesting technologies in their day to day practices, build a strong team and produce higher quality software.  In a traditional organizational structure that includes a manager, architect(s), developers and analysts, the patterns are practices do not change as fast as the trend observed in the software community.   Such a structure works against building a high performing team.  In such teams its hard to find architects and developers that agree on the technologies used for the project.  Eventually the team breaks down and the organization loses its talent.

In any project its easy to identify stake holders.

The managers are interested in completing project on time and within budget, the developers want to work on the challenging technologies and the architects want to design a perfect system and work with a talented team. If we take some notes for agile methodology and combine that with an auction, I think we can achieve better results. If we imagine the projects to be a tasks and the architects to be the implementors.  With the project pipeline visible, each architect has an opportunity to work on a system that he finds interesting. Now if the architects bid on these project using Time, Resources and Technology as currency – the managers have a better view of how they would like the project built. The developers on the other hand can choose to work on a choice of technology and level of challenge they are comfortable with.

Roles:
Manager: A manager should be a subject matter expert. He should provide a project description with any non technical dependencies. He should also provide a reasonable expected completion date.
Architect: An architect should be able to break down the project description into technological components, outline a plan of implementation and the desired skill-set. He should be able to estimate project completion date in man hours.  The architect is also responsible to select resources from the pool of resources that have committed to his design.
Resource: A resource can be a Business Analyst, Quality Analyst or Developer. The resource should be able to see the project designed by the architect and commit his time. There could be various reason why the resource would commit his time to a certain project, but that would keep the developer interested and motivated.  An intrinsic requirement for the resource would be to build his skill set necessary for the project.

Duties:

Manager: Provide overview for the architect.  Clear impediments while the project is being worked on and in general be an enabler.
Architect: Should be able to provide technological guidance. Design the project so as to generate maximum interest.
Resource: Should be able to commit time and be responsible to build his skill set as required by the project.

The managers would benefit from this practice, because they have the final control on how the project is implemented. The architects can design the project using newer patterns and practices. The developer are motivated and are likely to be excited to work on a project. The managers are architects agree on the time an technology as the manager chooses the architect. The architect and the resources are best aligned as the later has interest and more likely to be diligent on the producing high quality code. The collaboration between managers, architects and developers fill the gap of knowledge sharing that most organization of bigger size face. The organization as a whole grows technologically and is better aligned to retain talent.