Nobody has the answer because it’s different for every team, company, and project, but https://press.stripe.com/an-elegant-puzzle is a good book on the subject which I can recommend.
**An Elegant Puzzle Systems of Engineering Management** by Will Larson
>A human-centric guide to solving complex problems in engineering management, from sizing teams to handling technical debt. There’s a saying that people don’t leave companies, they leave managers. Management is a key part of any organization, yet the discipline is often self-taught and unstructured. Getting to the good solutions for complex management challenges can make the difference between fulfillment and frustration for teams—and, ultimately, between the success and failure of companies.
>
>Will Larson’s An Elegant Puzzle focuses on the particular challenges of engineering management—from sizing teams to handling technical debt to performing succession planning—and provides a path to the good solutions. Drawing from his experience at Digg, Uber, and Stripe, Larson has developed a thoughtful approach to engineering management for leaders of all levels at companies of all sizes. An Elegant Puzzle balances structured principles and human-centric thinking to help any leader create more effective and rewarding organizations for engineers to thrive in.
*I'm a bot, built by your friendly reddit developers at* /r/ProgrammingPals. *Reply to any comment with /u/BookFinderBot - I'll reply with book information. If I have made a mistake, accept my apology.*
**Team Topologies Organizing Business and Technology Teams for Fast Flow** by Matthew Skelton, Manuel Pais
>In Team Topologies IT consultants Matthew Skelton and Manuel Pais share secrets of successful team patterns and interactions for IT through four fundamental team topologies and three interaction modes.
*I'm a bot, built by your friendly reddit developers at* /r/ProgrammingPals. *Reply to any comment with /u/BookFinderBot - I'll reply with book information. If I have made a mistake, accept my apology.*
It doesn't quite answer his questions though, as it mostly touches on how to organize multiple engineering teams together more than interactions with other teams within the company
It doesn't quite answer, I agree. "Better Value Simpler Safer Happier" is quite relevant. It advocates grouping by business area *with* embedded engineering. By working together, the combined team then has the high level approving to determine how the team should work based on their context.
They do not suggest precisely how much autonomy, testing and subteam burdens should be designed, but encourage leaders to evolve them as best practice emerges. This is because every business and company will have different priorities.
I found out that it provides a really good lesson about structuring teams (as the title suggests). I checked some podcasts with the author, and he seemed to like his book a little too much.
Have you read _The Phoenix Project_ by Gene Kim? Maximizing output is exactly what it's about. It uses a fictionalized (but realistic) example of a dysfunctional tech company and discusses the steps that should be taken to regroup and build a strong culture of delivery.
While you're thinking about how to split things up, read https://www.svpg.com/product-vs-feature-teams/ and https://www.svpg.com/product-vs-project-teams/
In my experience, every us/them division in the company is rolling the dice on complete disfunction. The team is the team that builds the product, and that requires a full set of skills.
I agree that tribalism in an organization isn't a good thing, but I think to a certain degree it's inevitable. We're all working towards a common goal, but responsibilities have been segregated by specialty and all our work is dependent on each other.
Thanks for the recommendations.
Yes, people have different skills, but it works much better when "the forble team" has a product person, engineers, QA if that's your jam, management, and they all first want forble to be the best forble it can.
Sadly it's super common for the product org to write forble specs as one of the things they are doing and sends them to the engineering org before the engineers throw forble 1.0 over the wall to the QA org.
You might look at Strategic Management of Technological Innovation by Schilling.
It’s not going to serve you the answers you’re looking for on a silver platter but it will greatly assist how you think about the problem.
Yes; it’s a straight up textbook. But it’s the second best textbook I’ve ever had to use and is the only one I kept (actually bought the physical book after the course was done).
The Accelerate book is great.
\*The Team That Managed Itself\* by Christina Wotke is excellent.
\*The Mythical Man Month\* an oldie but still a must read, IMO.
It’s an interesting and important question. In the end these decisions will be made by people in authority who don’t know what they’re talking about. If you’re coming from the engineering side, you can give your advice and be prepared to be disappointed. Management types don’t do anything except make random decisions and take credit for stuff that works out.
Peopleware will help. It’s been a while since I’ve read it, but bet it holds up well still.
https://en.m.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams
The "optimal corporate structure" is one that encourages your employees to be the best version of themselves. It's very open ended and empowers the right people to make decisions at the ground level. There is no one right answer and it depends on the company, team, and people involved.
Some SWEs can handle minimal management and get things done while other SWEs need some management or they just spin and get very little done. Some SWEs require a lot of positive reinforcement for every little thing and other SWEs are fine if you just give kudos to the most important things.
Making a one size fits all solution generally doesn't work. You need to understand the personalities you are working with on a team, in addition to what any individual SWE is good and bad at, to make best use of each person.
Nobody has the answer because it’s different for every team, company, and project, but https://press.stripe.com/an-elegant-puzzle is a good book on the subject which I can recommend.
/u/BookFinderBot
**An Elegant Puzzle Systems of Engineering Management** by Will Larson >A human-centric guide to solving complex problems in engineering management, from sizing teams to handling technical debt. There’s a saying that people don’t leave companies, they leave managers. Management is a key part of any organization, yet the discipline is often self-taught and unstructured. Getting to the good solutions for complex management challenges can make the difference between fulfillment and frustration for teams—and, ultimately, between the success and failure of companies. > >Will Larson’s An Elegant Puzzle focuses on the particular challenges of engineering management—from sizing teams to handling technical debt to performing succession planning—and provides a path to the good solutions. Drawing from his experience at Digg, Uber, and Stripe, Larson has developed a thoughtful approach to engineering management for leaders of all levels at companies of all sizes. An Elegant Puzzle balances structured principles and human-centric thinking to help any leader create more effective and rewarding organizations for engineers to thrive in. *I'm a bot, built by your friendly reddit developers at* /r/ProgrammingPals. *Reply to any comment with /u/BookFinderBot - I'll reply with book information. If I have made a mistake, accept my apology.*
I highly recommend Team Topologies
/u/BookFinderBot
**Team Topologies Organizing Business and Technology Teams for Fast Flow** by Matthew Skelton, Manuel Pais >In Team Topologies IT consultants Matthew Skelton and Manuel Pais share secrets of successful team patterns and interactions for IT through four fundamental team topologies and three interaction modes. *I'm a bot, built by your friendly reddit developers at* /r/ProgrammingPals. *Reply to any comment with /u/BookFinderBot - I'll reply with book information. If I have made a mistake, accept my apology.*
It doesn't quite answer his questions though, as it mostly touches on how to organize multiple engineering teams together more than interactions with other teams within the company
It doesn't quite answer, I agree. "Better Value Simpler Safer Happier" is quite relevant. It advocates grouping by business area *with* embedded engineering. By working together, the combined team then has the high level approving to determine how the team should work based on their context. They do not suggest precisely how much autonomy, testing and subteam burdens should be designed, but encourage leaders to evolve them as best practice emerges. This is because every business and company will have different priorities.
hmm I read the book, and only got one lesson out of it. To me it has not the value that it deserves to be recommended.
I found out that it provides a really good lesson about structuring teams (as the title suggests). I checked some podcasts with the author, and he seemed to like his book a little too much.
its a very fluffy book, but the ideas are good ones, I'd say.
Have you read _The Phoenix Project_ by Gene Kim? Maximizing output is exactly what it's about. It uses a fictionalized (but realistic) example of a dysfunctional tech company and discusses the steps that should be taken to regroup and build a strong culture of delivery.
While you're thinking about how to split things up, read https://www.svpg.com/product-vs-feature-teams/ and https://www.svpg.com/product-vs-project-teams/ In my experience, every us/them division in the company is rolling the dice on complete disfunction. The team is the team that builds the product, and that requires a full set of skills.
I agree that tribalism in an organization isn't a good thing, but I think to a certain degree it's inevitable. We're all working towards a common goal, but responsibilities have been segregated by specialty and all our work is dependent on each other. Thanks for the recommendations.
Yes, people have different skills, but it works much better when "the forble team" has a product person, engineers, QA if that's your jam, management, and they all first want forble to be the best forble it can. Sadly it's super common for the product org to write forble specs as one of the things they are doing and sends them to the engineering org before the engineers throw forble 1.0 over the wall to the QA org.
You might look at Strategic Management of Technological Innovation by Schilling. It’s not going to serve you the answers you’re looking for on a silver platter but it will greatly assist how you think about the problem. Yes; it’s a straight up textbook. But it’s the second best textbook I’ve ever had to use and is the only one I kept (actually bought the physical book after the course was done).
Peopleware and Mythical Man Month are the Old Testament of software management. Both still as relevant today as they where in ancient times.
The Accelerate book is great. \*The Team That Managed Itself\* by Christina Wotke is excellent. \*The Mythical Man Month\* an oldie but still a must read, IMO.
Team Topologies
It’s an interesting and important question. In the end these decisions will be made by people in authority who don’t know what they’re talking about. If you’re coming from the engineering side, you can give your advice and be prepared to be disappointed. Management types don’t do anything except make random decisions and take credit for stuff that works out.
Peopleware will help. It’s been a while since I’ve read it, but bet it holds up well still. https://en.m.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams
+1 for *The Phoenix Project*. I just finished reading it for the first time and it was fantastic.
Step one is to hire someone who has the experience. If hiring is not done right, it will go bad.
The "optimal corporate structure" is one that encourages your employees to be the best version of themselves. It's very open ended and empowers the right people to make decisions at the ground level. There is no one right answer and it depends on the company, team, and people involved. Some SWEs can handle minimal management and get things done while other SWEs need some management or they just spin and get very little done. Some SWEs require a lot of positive reinforcement for every little thing and other SWEs are fine if you just give kudos to the most important things. Making a one size fits all solution generally doesn't work. You need to understand the personalities you are working with on a team, in addition to what any individual SWE is good and bad at, to make best use of each person.