Thank you for listening. I need to get a few items down; that I believe may be beneficial to many. The items I see across in my tribes.
Titles are for Reporting, Roles are for Teams
We all work hard to get established and successfully obtain titles, titles of honor. In any tribe, this is critical. In any situation where there is a badge system, I'm motivated to work towards obtaining that badge.
Roles, roles are defined in a team to communicate and identify, where we fit, in a given project. In this paragraph, I'm talking about a given project such as: create an application to track inventory. Our role may change, we may have many. Titles should not restrict the role anyone can perform. Sometimes one leads, maybe many lead, other times I may follow. Tribes must be connected to a leader, connected to an idea. In creative environments, a tribe must have and understand a shared interest.
*Get out of your Title and into the Tribe.
Tribe Synergy
Tribes must have a way to communicate. Tribes need movement – make things happen to get things done. This required leadership, desire to make something happen. Opportunity to lead, excel, and knowing that your tribe members will not drown you out. Many tribes are stuck, they settle, don’t commit.
Everyone can contribute. Maybe this is not the right time for you to lead, that’s OK. Understand your role and do your part to help your tribe grow, reach our goals. Below are 3 common elements that I have found to reach synergy in a tribe and enable successful execution of a project:
- Somebody (or everybody) maintains a list of everything that needs to get done, broken down into manageable chunks, with time estimates for completing each chunk;
- Every team member has a prioritized list of those chunks, which they are responsible for completing;
- There's at least one person who monitors the progress to make sure things are on track.
Follow Established Procedures or Processes
Procedures and processes are there for a reason: to avoid mistakes and to identify behaviors that make mistakes. Following the rules only makes sense. Avoiding mistakes is a good thing.
Well it might be a good thing, until your best team members start to fear the process; feel as though their hands are tied behind their backs. Feel that they don’t have the title to offer better ways to make things happen. See the process as rigid and no one can change it, without fear of disconnection from the tribe. If a given task can be done in 1/10th the time; we need to listen. Will our ideas always get accepted, NO, but the tribe will listen and provide a medium for change; it may not be used to get the current badge but it may be used for our next gathering.
Avoiding mistakes is a good thing, but at what cost? Software engineers are essentially problem solvers. That's what they do all day. The best of them enjoy and derive fulfillment from solving problems with the least amount of effort (both personal effort and computing resources). They are by nature very intelligent people. Every developer on the team probably possesses well-above-average intelligence. They will find ways to solve problems, but if they are bound by some arbitrary rules that prohibit them from deviating from standard procedures and processes, their productivity (and creativity) is limited.
This isn't to say tribes should avoid processes all together. But as a team, there are two ways to view processes: one is to view them as the laws of the land which should be followed at all times and the other is to view them as a set of recommended guidelines that seem to work well, but feel free to recommend and communicate change (and a way to recognize and make change happen effectively). The latter is far more productive for intelligent people.
To invoke another adage: The process is created for the team, not the team for the process.
Thank you for listening. 3 items: they are fundamental to any tribe.