This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
For the 10/4 AMA: Company culture is a hot topic nowadays. We're currently at a point in the growth of our organization where we're very likely about to outgrow our "small" company culture. We're already at a size where not everyone knows everyone in the company, what roles they play, and how those roles affect each other. Team Topologies makes it clear the productivity benefits of a well-defined team API, but do well-defined team APIs also correlate to a more well-defined sense of purpose or belonging within an organization? Have you noticed positive changes not only in the productivity of a company but also in a company's culture when a company adopted more well-defined team APIs? I recognize that culture strength is a difficult attribute to measure, but I reckon yal are better equipped to measure it than I am so I figured I would ask đ
For the 10/4 AMA: Company culture is a hot topic nowadays. We're currently at a point in the growth of our organization where we're very likely about to outgrow our "small" company culture. We're already at a size where not everyone knows everyone in the company, what roles they play, and how those roles affect each other. Team Topologies makes it clear the productivity benefits of a well-defined team API, but do well-defined team APIs also correlate to a more well-defined sense of purpose or belonging within an organization? Have you noticed positive changes not only in the productivity of a company but also in a company's culture when a company adopted more well-defined team APIs? I recognize that culture strength is a difficult attribute to measure, but I reckon yal are better equipped to measure it than I am so I figured I would ask đ
<!channel> Final AMA for Book Club is in about 24 hours! Get any last questions in. Friday, October 4 @ 6:00â6:30 a.m. PDT â Matthew Skelton & Manuel Pais (video)
You note the need to avoid the remit of âmaintenance of softwareâ. How does this square with the goal of retiring older platforms that still need some support but are migrating to greener pastures? (Weâve got , donât laugh, a VB 6 application that is on its last legs and no one wants to maintain it but they have to)
You note the need to avoid the remit of âmaintenance of softwareâ. How does this square with the goal of retiring older platforms that still need some support but are migrating to greener pastures? (Weâve got , donât laugh, a VB 6 application that is on its last legs and no one wants to maintain it but they have to)
Good example, @andrew - I once worked at a company where the "legacy VB6 app" handled ÂŁ2bn revenue per year! I think the thing here is to recognise that it is going to be a bad experience for the team that owns these older services and find ways to compensate the teams: investment in automation, extra time to deal with legacy problems, reduced "new features" expectations elsewhere so they can make the old stuff as "nice" as they need to. There may also be a justification to see really old/weird tech as justifying a Complicated Subsystem team - VB6 is as old now as COBOL or FORTRAN was when VB6 was actually new đ¤
Oops, I answered this a day early! Too keen on the subject đ
Oops, I answered this a day early! Too keen on the subject đ
The Team of One. One of the approaches I have advocated in our teams is to treat the work âyouâ ( the dev) is doing as though you were in a team even if there is only one person there. This applies to our entire team as we are doing QA and deployment and allâ- in a small group where we used to have dedicated groups. We still scrum every day but areas of responsibility are split. Any thoughts or pitfalls?
The Team of One. One of the approaches I have advocated in our teams is to treat the work âyouâ ( the dev) is doing as though you were in a team even if there is only one person there. This applies to our entire team as we are doing QA and deployment and allâ- in a small group where we used to have dedicated groups. We still scrum every day but areas of responsibility are split. Any thoughts or pitfalls?
What is the best team topology for completing migrations? Where might these typically fit in? 'Migration' defined as a major rework of your technology stack to create technical leverage or reduce technical debt (ex: moving from VMs to containers, rolling out circuit-breaking, moving moving from on prem to the cloud). Article for reference: https://lethain.com/migrations/ I seem to always find myself on migration projects, that require contributions from folks across teams, but don't need a long-lived (consistent for more than one year) team.
What is the best team topology for completing migrations? Where might these typically fit in? 'Migration' defined as a major rework of your technology stack to create technical leverage or reduce technical debt (ex: moving from VMs to containers, rolling out circuit-breaking, moving moving from on prem to the cloud). Article for reference: https://lethain.com/migrations/ I seem to always find myself on migration projects, that require contributions from folks across teams, but don't need a long-lived (consistent for more than one year) team.
When there is a need for the transformation, but the HR, manpower/staff assignments and financial components of the organization are functionally siloed apart from the IT delivery part of the organization (government/military organizations), where and how would you start to begin reshaping the team topologies within the groups? What conversations would you recommend we have with the leaders to begin this initiative?
When there is a need for the transformation, but the HR, manpower/staff assignments and financial components of the organization are functionally siloed apart from the IT delivery part of the organization (government/military organizations), where and how would you start to begin reshaping the team topologies within the groups? What conversations would you recommend we have with the leaders to begin this initiative?
Here are some questions posted in the discussions channel https://itrevbookclub.slack.com/archives/CNAADFW11/p1570146396459500
Here are some questions posted in the discussions channel https://itrevbookclub.slack.com/archives/CNAADFW11/p1570146396459500
Photo from our Team Topologies Fundamentals training showing some different team structures using pieces of colored card. Makes it very easy to model!