The engineering teams are being established, where I recently joined a fantastic company. I wanted to learn more about mission teams before a meeting I have regarding the future team structure (now, there are certain developers who cover each area, including front end, back end, and full stack).
In my previous role as a PM, I worked with teams that shared expertise in a single domain, such as back end teams, front end teams, and full stack teams. As a result, I am familiar with how to divide backlogs into teams and how to handle cross-functional requests.
The mission teams’ strategy, where each team has a front end, back end, and a full stack engineer, has me a little confused.
How does this strategy function? Is it typical for some team members to be given less work than others? Do huge backend projects, for instance, get divided into smaller tickets and handled by various teams?
What do you mean in your example when you refer to “fullstack” as a distinct area? The best teams are made up of three to five members, each of whom is capable of handling their team’s area of responsibility and has a broad enough range of skillsets to work on whatever the most essential issue at hand may be.
@VladPodpoly, I’m relatively new to the company, but I think that from their point of view, having a full stack means being able to handle everything from the UI to the backend.
My greatest concern is probably how mixed-team situations are handled. My knowledge is strongest when one team had a specific set of talents rather than a combination of numerous “areas,” like my former company had teams for video players, backends, ads, etc.
However, due to the size of the company, initiatives frequently either spanned numerous teams or were confined to a single region, as in the case of strengthening the stability of supported APIs.
Because I’m still missing certain information regarding how the teams will be organized and because I’m attempting to go a step ahead of the game, I believe my confusion here is somewhat unfounded and will work out perfectly.
The majority of items that genuinely provide value to customers need both frontend and backend functionality. Therefore, both skill sets must be present in a team that is expected to deliver value.
Thank you for the comments @JoelSchuman! Very helpful, I think my brain is somewhat lodged into my past experience in some aspects, and I need to do some more reading and get first-hand experience of smaller teams which cover the whole ballpark.
Your new company seems to operate somewhat like Teresa Torres’ stated Product Trio. If so, you can learn a lot about how these roles work well together on her website and in her book Continuous Discovery.
Except for a team with full stack and data science engineers, where we faced the issue you mention, I’ve never worked on a team that had such strict separation of engineering roles, and in my opinion, that kind of hiring looks strange for a company. It appears more ideal and prevents this issue to hire developers with a wide range of skills but perhaps better understanding in one area of the stack. Numerous engineers are able to work across the stack and do so.
Do you propose that I work with my manager to change the teams so that they are made up of groups of engineers with similar skill sets, such as a backend team, as you suggested in your response?
Value stream operations are made more difficult by skill-based teams.
I can give you an example of a difficulty I faced when working with skill-based teams. I have organised teams by talent for project management, editorial, user experience, and web development. Each team has its own sprint cycle, so when I need to post a new blog, it must move from one team to the next. It takes 3 to 6 cycles until it is truly published. When all you need to do is write a blog post and everything else—including communication, status updates, and many other things—operates in silos, this is completely absurd. However, a cross-functional team may finish it in one to two cycles.
It is also difficult to transition from skill-based to mission-based teams. It requires a lot of mental effort and will have to interfere with the reporting structure.
In some situations, cross-functional teams are primarily designed to be swift and mission-focused.
Since the existing developers aren’t teamed up, the procedure should presumably go smoothly in that area.
We now have an overall backlog of various types of work for those teams (bugs, UI etc.). Do mission teams, in your experience, each have a separate backlog from which to build sprints? To put it another way, all of the tickets are in one backlog, and then “x” project tickets are assigned to each team and placed in their respective backlogs.
Great question @AnaRodriguez. Usually there’s an Epic level backlog above the team backlog. Teams could own Epics and all/some tickets within the Epic. Other teams can pitch in for items within an Epic.
In your context, Epic could be synonymous with mission.
So. Consider it this way: Teams with specialised skills are mission-driven in major corporations. Now, with a much smaller scope, you are managing what a director or vice president would oversee.
Therefore, plan each mission independently. For instance, I supervise two mission teams. I take use of that to manage one using kanban and the other using rigid sprints. It’s enjoyable and difficult. Just keep in mind that you’ll need to delegate to others or give them the authority to take on your duties. Soft skills are therefore the most crucial now.
Please concentrate on implementing EDIT or any other platform for value stream distribution. You’ll thank me later, but it will free up your engineers’ time so they can work on solving business problems rather than creating new wheels.
Mentioned EDIT deploys containerized apps on Kubernetes pods and works with any infrastructure provider (AWS, GCP, AWS, on-premises, bare metal). Real-time logging, multi-cloud/hybrid clouds, managed services, scaffolders, and cloud native technologies are all open source, preventing vendor lock-in.
However, spare no effort in developing CI/CD, automated testing, or static analysis. PLEASE.
It really annoys me when startups spend 20% or more of their budget on repeatedly revealing the wheel. It’s simply so dumb.