Software Teams

This is a crash course on software teams, of what is commonly expressed but by no means accurate across all contexts nor generalizable. Only use the information presented here as a starting point. Please use a combination of research skills to find more detailed information about specific roles and expectations surrounding that role.

Roles & Responsibility

Software development is done differently at each organization so it is difficult to simplify into neatly quantifiable processes and roles in a single set of terms that all practitioners can agree on.

However, despite these changes there are some things that remain the same. There will always be a need to understand the business problem, convert that problem into an architecture, convert the architecture into a solution, test the solution, and deploy the solution. One person may be filling all the roles or a handful of the roles, or one very specific role.

There is a need for all of the roles -- each serves a purpose. Some times on a smaller team an individual may wear multiple hats. The organization chart below gives you an idea of how each position could fit together within an organization.

Image Credit¹

A new team may need some time to figure out how each individual fits together.

Generally on a larger team of (say, over 50 individuals), there is a core group aiming to meet the collective needs of the project’s primary stakeholders. The core team relies on and turns to an extended groups of people who can provide context. Both groups are needed to do well.

Hierarchy

Some teams have hierarchy in their decision making structure. Other teams operate as flat structure. Often one can find a Project Manager (PM) for a team to help coordinate communication. Sometimes with more client facing companies you may find the PM is a product manager, who helps make decisions to shape the end product and coordinate team efforts to move toward each iteration.

Usually one can quickly determine a separation on a team of those who are very green from those who are more seasoned. This may lead to having a technical team lead who takes on more with the deciding of technical details of the overall project, such as making careful consideration of the organization structure and code style.

Job Titles

"Software Engineer" is a generic job title that comes with several connotations depending on who you ask.The best thing you can do for yourself in the long run is to take the time to figure out your personal definition of a job title.

To help you get started with knowing what's out there, a list of possible job titles can be found at 1 and 2.

You can look for surveys and reports such as the Stack Overflow Annual Developer Survey to find latest trends on what general expectations are skill-wise.

Class Project Teams

The class project will be a large project, ~20 individuals per team with small groups within the larger team.

There are common roles on a generic web development team, but it’s not a comprehensive list. The recommended teams are:

1. Specifications - deciding on metadata, such as any controlled vocabularies, data types, and documenting the requirements.
2. Database - create and maintain database, update as necessary and curate content
3. Back end* - connecting data to front end, designing API endpoints, handling user input/sanitation.
4. Front end - building ui, works closely with product owners
5. Quality Control - decide testing specifications based on specifications documented, come up with testing procedures and perform tests
6. Product team - decides features and user experience and documentation related to using the product. Works closely with the front end team.

Putting it all together

Getting a team to work together cohesively is a major challenge. Getting a team of undergraduate BC students to work together towards a common goal is more challenging than herding cats. Despite the major obstacle that presents itself under present conditions, we will still make a heroic attempt to try the impossible this semester.

It is rare to find a unicorn in the wild, someone who has a wide array skills and could contribute to multiple areas. In the following paragraphs, a few ideas are presented to show how hiring managers and team leads might try to find a way to build cohesiveness in the absence of unicorns.

T-Shaped Skills

A related topic to working on teams is the technical capabilities and aptitudes of each team member.

One of the metaphors brought up in startups/agile environments is of folks are specialists versus jack of all trades. The latter group has what they call the “T-shaped” skill set as they are rather easy to plug into teams. The t-shape refers to having a broad range of basic skill level mixed with one or two expert level skills.

It is not necessary for one to be t-shaped for career success, however it may be a term you come across in industry. With regards to software development, it can mean for example someone is much stronger in algorithm creation but can get by with graphic design. Or another mix of skills.

Of course, even if one had the skills to pitch into multiple areas, they may not want to.

Splitting tasks

Delegating tasks to a team is a challenge. One way to do so is to list out all the possible tasks, then divvy up in a fair way.