Petro Podrezo Software Engineer
Team Structure
Here’s an example of how a company might be structured. The example here is the product department of a product company (consulting firms typically look a little bit different) and we’ve got two teams, one is a smaller one that’s running a bit more lean (Team B) and one is a bit larger with a larger beadth of roles.
Here are some key concepts:
Product managers determine the direction of the product. What features should be built? What should the product look like? What should the user experience be like at a high level? They’re the ones who are responsible for the “what” and “why” of the product and often look to market research, customer interviews, and their own intuition to determine the answers to these questions.
Designers are responsible for the look and feel of the product. Often the same person will come up with both the graphical design (UI or User Interface) as well as the flow of interactions (UX or User Experience). They provide mock ups to the engineers of what to build and explain the more intricate details of how the product should look and feel from the more vague ideas that the product manager has.
Engineers build the software that the users will ultimately use. They take the designs from the designers and the requirements from the product managers and turn them into a reality. They’re responsible for the “how” of the product and often look to their own experience, best practices, and appropriate technologies to determine how to build the product. In addition to building the product, they will also coordinate with engineers on other teams or with architects and staff/principal software engineers for any shared concerns that might affect other teams. Engineers are also required to break down and organize work into small chunks to be able to progressively report on the progress of the project to the product and/or project managers.
Quality Assurance tests the product to make sure it does what its supposed to reliably and files bugs for engineers to fix. QA also makes sure the requirements that the PM & designers set out are being met (such as accessibility conerns).
Automated Test Engineer this is a role that is not as common, but depending on the company they may value having a dedicated person to write automated tests, usually end-to-end tests (as opposed to unit tests written by the engineers).
Project manager is a role that often gets conflated with the product manager role and ultimately the product manager is often left to “wear both hats” but these are two different roles. Unlike the product manager who is concerned with the direction of how the product looks, feels, works, and in general what to build next, the project manager is concerned with the logistics of building the product. They’re responsible for making sure the project is on time, on budget, and that the team is working efficiently. They’re also responsible for making sure that the engineers are not blocked and that the product manager is not changing their mind too often. Often the project manager will be the one to coordinate with other teams and departments to make sure that the product is being built in a way that is consistent with the rest of the company’s products. They will also be the ones checking in on engineers progress and timelines to ensure deadlines are being met.
Agile coach is not one of the squares on the chart but I wanted to throw this in there because while it is not super common to see a dedicated agile coach in my experience, they are a supporting role that can be quite valuable especailly when there are a lot of junior to intermediate people on the team. Agile coaches help people reduce inefficiencies in their workflow and help teams understanding how to thrive in the agile process. They’re often the ones who are responsible for making sure that the team is following the agile process and that the team is getting the most out of it. They might facilitate things like team retrospectives and do checkins across all product teams to report up to management the general sentiment of the teams and what they are lacking.
Note that I left out specific roles for the other departments because they are not the focus of this document despite being important roles to the company. As a side note, you may have engineers working in other departments. For example, it may be common for a company to have a designated engineer or team of engineers that work on the marketing website that sits outside of the product department since they do not develop the produt that the company is selling.
Daily Life
A typical day as a software developer is diverse and depends greatly on the work environment. I’ve always preferred medium-sized, established companies, valuing the balance they offer between salary, responsibility, and work pace. Regardless of where one works, certain constants remain pretty much everywhere, like daily stand-ups and a significant portion of the day dedicated to ‘heads down’ coding. Software development isn’t just about programming; it’s about coordination and collaboration, often involving numerous meetings to synchronize efforts across teams.
Alignment and Autonomy
In general, teams want to have autonomy over the “how” of a project, but they need to be aligned on the “what” and “why” or else you get trouble. This comic from Spotify’s Squad Framework (drawing by Henrik Kniberg) does a fantastic job of illustrating the concept of alignment and autonomy. The idea is that a team should be aligned on the “what” and “why” of a project, but should have autonomy over the “how”. This is a concept that I think is very important to understand and is a great topic to discuss with a mentor.
