At the company I work at, we're definitely not autonomous. If as a team we have a goal, as a dev, I don't know what it is. We have roadmapped (read: itineraried) work items, basically handed to our team to produce. Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery.
So what does it look like? Well, as devs, we have specific feature requirements handed to us with little-to-no prior input, we're always behind schedule so we're never afforded the time and space to do things right, it's always "we'll fix it later". We occassionally have some kind of "our competitor is doing this, we have to do this" piece of work that comes in and shifts all of our roadmap items later of course. No one ever stops to ask whether we're having the impact we anticipated, or whether it's even worth keeping the work.
Combine this with a replatforming-through-new-work effort on the go, you've got a slow mutation from the old platform into an even uglier new platform that doesn't get the right effort applied to it.
But hey, we're "agile", we have mission teams, we have two-pizza teams, we're goal oriented. I mean, we say these things, but in reality it's planned out work, with deadlines, delivered by multiple generic teams named after areas of the customer journey that end up being the center of philosophical debate about whether this bit of work lives with _this team_ or _that team_.
Although I don't think the team size or the number of them is necessarily the problem, the article rings true in my experiences - but it's down to culture of the organisation, more than the topology.
This is why I hate Agile. It's much harder to convince management that they won't be getting a pre-determined set of functionality by a certain date (we will have feature x,y and z developed by October 13th) than to convince a team to stop doing upfront planning and design. So almost every project I've been on that was "Agile" was actually waterfall sans upfront planning and design.
My understanding about Agile is planning ahead for the next step instead of planning the whole project before starting and then hoping all your assumptions turns out true.
The product owner will create and prioritize the stories in the backlog(plan), the team will discuss and break down a story into actionable and weighted tasks(more planning), then they will fit those tasks into the sprint based on their previous performance(even more planning!)
I think the business concept missing from Agile is investment/ROI and risk. Until budgeting processes are also Agile, everyone will be operating on the idea that "we paid $x to get 'y', and now you aren't giving us 'y'. What the hell?"
Agile works (when it works) because it treats software as a complex system that is best studied and modified through experimentation after accepting a high initial degree of uncertainty (which is slowly reduced through the creation of knowledge). The only comparable things in business terminology are investment and risk. Each iteration (I hate "sprint") needs to be treated as an investment with some risk percentage of failing completely. Until the money is handled that way, business people will keep expecting to get exactly what they think they're paying for, exactly when they feel they were promised they'd get it.
Right and the fundamental issue is that the next step in agile is an iteration which occurs over 1-4 weeks. But most companies "iterations" are quarterly or yearly. So every quarter or year the business plans and discusses what money they want to spend and what they want to spend it on. And quite reasonably executives are going to want to know what they are purchasing with that budget allocation.
The key in communicating is that you give a roadmap, but not put the date into the sand.
Following the idea of the iron triangle, with Agile we fix budget and time, but we keep the scope flexible, however, we estimate a scope and refine that along the way.
If you follow an iterative Agile approach like Scrum, given you know your velocity and you have a backlog in good shape, you can work from one milestone to the other.
I'm sure some upper management is fine with "we will work on these features and some of them will be done by December."
But in a lot of organizations upper management asks middle management when those features will be delivered so they can plan client communications or internal teams around that.
IMO, the core principle of agile is “early feedback means smaller corrective action”. Everything else is just process to achieve that without running afoul of the evil twin “noisy feedback means constant corrections hunting for the solution.”
Agile goes wrong when you don’t get and use good feedback.
You do upfront planning and design, but you only do enough to establish your general course of action. Because good feedback requires context about your goals. If you don’t care where you’re going, then any direction will get you there.
I think I just realized the crux of why some folks dislike agile but weren't able to express it and it has to do with the idea of what-is and what-isn't and how much dominance the "isn't" has over the owner of the belief.
If someone tries to get you to believe something and part of that belief is the active suppression of certain types of thought, and those types of thought are what actually make us intelligent. Then in some regards, agile is trying to make us less intelligent. It might be accidental, it might be unintended, but it is there. Agile attempts to create a social norm where certain thoughts are banned. Yet our ability to anticipate and predict the future is one of our largest defining traits.
There are some aspects of agile that have cult like qualities. I think agile has _improved_ many software teams and projects, esp with how those teams approach planning, but it is still important to be cognizant of thoughts that have been removed from view.
I think he knows he's working in a feature factory. What's hard is knowing what you can do to change it.
Where I work, we happen to have a pretty relaxed management. While they always have a ton of deadlines and always push for more work, they largely don't care about the outcome, so you can just ignore it. Every once in a while something will be actually important, but mostly it's just dumb roadmaps for features that don't add value.
What my team has found helpful is to just ignore those fake tasks, and just create the features we actually believe will be valuable. Hopefully we can leverage our outcomes (and the collected data) to convince management that our way is better. Some day.
> Well, as devs, we have specific feature requirements
> Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery.
That’s “classical” fixing of all dimensions of the “magic triangle” (scope, budget, time), not agile by any stretch, rather a practice from waterfall management.
I argue that there’s a fourth dimension; quality. How do you see the quality of the teams’ work?
I actually prefer a systems lifetime as the 4th dimension.
Quality is just a function of the system time to live being fit against the other three constraints. Scope, budget and time. (I'd actually say time is a subset of budget.)
To be honest, most "deadlines" are really just cost boundaries in the first place.
If you're not publicly traded and made an announcement about something going live on a certain date, or have a regulatory body that requires something by a certain date, your deadline is just a cost-cutting measure.
Johanna Rothman, in 'Manage It', suggests these dimensions to what we usually think of as the 'triangle': features, quality, schedule, cost, team size, team members, and resources (infra, sw, etc...)
Both your comment and the article sound a bit like the inverse of the problem addressed by "Domain Driven Design".
In the case of the book/approach, the problem is that the IT side doesn't match the business side (in terminology, code organization, etc.). The solution is for IT to become more aligned with the rest of the company.
But in the case of your comment and the article, the mismatch seems to work the other way around. Out of some 'two-pizza methodology' or whatever, the business side now has to split up what should be a single problem/domain in a nonsensical collection of different domains.
I might be entirely off here, though. But if I'm not, is this problem perhaps particular to companies where IT is more in charge than in the types of companies where DDD has been a solution?
I worked at Amazon on two-pizza teams. I never thought the two pizza team was about reducing communication, but more allowing faster independent decision making. Once you work on something that is big and complicated enough that it requires dozens of engineers, there HAS to be communication and coordination. Hopefully you have good managers (and high level ICs) because they are supposed to do a lot of the coordination so that it is easy for the engineering team to focus on engineering. A goal of independent two-pizza teams is to have the independent teams define how their individual pieces will interface and then the small teams can independently decide on implementation details.
The two-pizza team concept is also about having a heuristic that tells you when to start looking into how to divide responsibilities between independent teams.
I don't really get what this article is proposing. Never work on projects complicated enough to require lots of engineers and thus coordination? It is not realistic to deliver the complex projects that big companies need to do with a single small team doing everything. It will just never get delivered.
The Two-pizza team concept is a very small part on how Amazon works. A few others on top of my head.
- Enable high-velocity decision making: Defining clear tenets that act as the north start for decision making at team level, and two-way doors thinking.
- Establish how you measure success, and how does relate to the goals of the organisation.
- Achieve team independency is a key factor, and having strong mechanisms such as the "away teams" concept, "communication is terrible" mental model and reducing cognitive overload by relying on platform teams
- Nominating a single-threaded owner for programs and business outcomes.
- Articulate how the organisation works across teams using mechanisms such as bar raisers, OP1/OP2, PR/FAQs, CoEs, WBRs, experiment-driven teams, ...
My company has brought in a lot of Amazon people and ideas, but unfortunately we go this one backwards. "Communication is great." Managers are explicitly encouraged to structure projects to maximize cross-team and cross-org meeting hours.
It is quite common to get communication wrong, even inside Amazon. It leads to design by committee, slow decision making, and increase team dependencies.
I would love to hear your experience adopting Amazon mechanisms.
Disclaimer: I work at Amazon. I help customers to adopt some of those mechanisms.
So many of the popular management techniques look at the output of well-trained, highly experienced and very motivated teams and think that if they can just replicate the outward characteristics of those teams, they'll get the productivity as well. Needless to say, the same practices with recent bootcamp graduates suffering under JIRA-inspired micromanagement from a manager who has zero training except "being a developer for three years" will not have the same output. It's cargo culting at its finest.
I agree. Looking at the "final practices" of a well-oiled team and just picking them up without any of the context about "why" they work "for that team" is half the reason no good idea (Agile, microservices, Jira) stays that way in software industry.
As an anecdote of this, I'm in an R&D department of a small company. I'm basically a team of one with an intern (which is its own challenge because he likes to be somewhat micromanaged). My manager just recently was finally convinced to shift from a waterfall module to something agile, except now it's just becoming a micromanagement tool... for a team of essentially 1.5.
We had a conversation the other day in which I was given to understand that if we thought some documentation was finished, but had to go back and make a tweak with no more than 15 minutes spent on it, we should be creating a ticket in Jira to do so. I'm currently cursing all the people who've sold agile because this is insanity (imo).
Feels good to get that off my chest haha.
That's literally not how it works too. Agile has a robust and rigid structure that you then pull from and adapt to make your team and processes better. Few teams have the same implementation. It's important to understand the full scale of agile practices and tools but do not try to do it 100%, that's not the idea at all.
A manager that has experience with development? I wish.
Our team of four (frontend development for our two main products) has a "team leader" (not included in the team), two "product managers" (one for each product) and a "director of IT" (our actual manager), none of which have a background in software development. They all have a background in our product's domain.
Yes, it's not about reducing communication, it's about keeping the number communication channels and coordination manageable.
The "two-pizza team" is like a squad/section in military organization. It's the sweet spot of having enough people to get things but not too many people so that communication and coordination starts to be a problem.
> I never thought the two pizza team was about reducing communication, but more allowing faster independent decision making.
The point of the article is that if you don't own a problem space you don't own the decision making; you require communication with other entities for their part of the decision. Requiring comms.
But I don't really agree. If you are a small team solving a small part of a larger problem and you have done a good job of defining your external interfaces, you can make decisions about how to solve your subproblem quickly and independently. Also, process/culture decisions (e.g. code style, automated tooling, code review standards, update cadence, etc) become easier because you only need to come up with a solution that makes ~10 people happy instead of a solution that serves the needs of 100+ people.
> If you are a small team solving a small part of a larger problem and you have done a good job of defining your external interfaces
I think that's where you and the other commentator are talking past each other. Amazon tends to have great managers and senior ICs that get the responsibility and technical divide right.
My experiences outside Amazon unfortunately point towards this being hard to get right in the first instance, and really really hard to fix once it has gone wrong.
These are all the same thing. Or at least, they all reinforce each other.
You can make quick decisions because you don't have to communicate with a large group. You don't have to communicate with a large group because you own your space. You own your space because you have clear external interfaces.
If the external interface needs to change (from your side or the other side), it requires external communication and is probably slow, so you (and the other side) try to get it right the first time and minimize changes.
I think the author is refering to communication outside of the team.
Sure, inside the team there is lots of communication, and the business is probably setting the stage on a quarterly scehdule or something along those lines?
That is correct. Wen I am wrote about "communication overhead" I meant having to talk to other teams to get the work done. Talking within the team (including PM, stakeholders etc.) is, IMO, desirable to set the overall team vision and to keep everyone on the same page.
I feel that once two teams, no matter how closely related, get the feeling of two different "mandates" (often personified by two managers, sometimes not), it becomes very expensive to keep them aligned. It is probably faster(wrt achieving the end goal) to go with fewer people in one team.
At least when the approach works, I think the goal is to not have to have the teams aligned, instead giving them independent mandates that lead to the emergent behavior being what the business needs.
But then actually it's people from multiple totally unrelated teams ignoring each other and taking turns talking at a manager, hoping same manager chooses to hover over someone else for the day and trying to ensure that happens by impressing them with a list of every little piddly thing they did yesterday that no-one on their own team even actually needs or wants to know about.
The OP is describing Conway's Law, and shows that half the battle is being able to define the problem space in a way that minimises communication and maximises utility. As such, it could be inferred that beginning with a monolithic organisation, and splitting off a new team at the appropriate time when a useful problem space had been defined could be a possible best practice, assuming the organisation was flexible enough.
That is well put, and I'm going steal some of those words in the follow-up I'm writing. I essentially feel that teams should grow when tech and process initiatives have led to creation of a whole new problem space that can be explored independently.
Consciously applying Conway's to identify communication boundaries sounds like a good way to get there.
Thanks! Indeed, it's the interfaces that are hardest to define. I don't know a good heuristic to determine it I'm afraid - everything I've ever done was on intuition.
Small teams that own and are responsible for products.
Teams expose any information they need to share via APIs (including data for reports)
Teams consume any information they need via other team's APIs.
My experience:
Teams that have 9-12 people on them, all working on different things/products, people external to the team completing some tasks that the team can't do, struggles to prioritize work since there is so many work streams coming into the team, members moving from one team to another, work moving from one team to another
My experience with this has been that when teams dissolve, new apis are created on top of the existing apis to avoid making changes to the original api. Debugging a production issue now involves a lot of finger pointing about which API is working correctly, and which one needs "the fix".
I feel that it really all comes down to good first-level management, and retaining engineers longer than 18 months (see "good management," above).
I don't think there's any "silver bullets." Humans, are, well...human, and that means there's a lot stuff like emotions, personal motivations, ambition, self-doubt/confidence, team dynamics, etc.
That requires managers that don't just follow buzzwords, but understand the humans they lead, and act as shields between the employees and upper managers that aren't very good at managing humans.
Armies run on their sergeants. The Captains, Majors and Colonels are necessary to implement strategy, and convert into tactics, but if you can't keep your teams trained, focused, and motivated at the sharp end of things, the finest generals in the world won't be able to take on a playground full of toddlers with water pistols.
But then, that's just my experience and opinion. YMMV.
The post makes a good case for why it's a bad idea to split a business problem into slices. Even though you have multiple small teams, they still need to closely coordinate with each other.
But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck?
It's a bad idea when the slices aren't independently achievable.
The military analog is the fire team (3-4 ppl) or the squad (5-14 ppl), depending on how hungry they are and what the current theater demands.
Squads can be assigned multiple discreetly accomplishable objectives. Each squad is assigned to secure a different building on a street, for example.
No one squad is necessarily codependent on the success of the other squads to meet it's own objective, but when you pull back a level, overall organizational success (securing the neighborhood, winning the fight in the city, winning the war) is dependent on the success of all of the squads.
The article argues, and I agree, that as a company grows, it's easy to shift from discrete squads to assembly line squads. Eg data ingestion => data transformation => data delivery. Platoon / company level objectives, not squad level ones.
I have the analogies, but not necessarily and better solutions.
> The post makes a good case for why it's a bad idea to split a business problem into slices.
Why it's a bad idea is indeed demonstrated. But why it happens in practice is not just to obey the "small team" mantra. It's also because as organizations and products mature, the law of diminishing returns kicks in: once easy gains have been made, achieving more gains requires tackling more complex problems - either because they are actually more complex in themselves, or because of the environment has become more complex.
> Even though you have multiple small teams, they still need to closely coordinate with each other.
> But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck?
That complexity actually means that whatever the way you organize, you're going to have more people involved. That's when you need good managers - what I call a good manager is not only competent to manage their own team, they're also good at making their team play in a more global picture without necessarily having a boss telling them to do so.
These are great points. I disagree with a lot of this article, because it oversimplifies the problem without considering things like this.
Another related problem it forgoes discussing is the idea of planning. Once these problems get harder, the need for people to sit down and design a solution grows, sometimes exponentially. Yes, you need good communication, but you also need something to communicate and agree on. How many small teams in big orgs have even a simple design doc to work from?
And perhaps the Product Owner vacuum is filled in the sequel mentioned above.
The other point I was awaiting was documentation. Thank you to the one who at least threw a ransom note into the wiki. My software archaeology project would be impossible otherwise.
I remember when we were expecting our first child, we went through a 'parenting school' - a course where all kinds of doctors, psychologists, nurses, nutritionists, etc. came to teach us, future parents, about parenthood. Since it's not maths, a lot of them had different views on different things, which confused people. Until one day, one future mother, all anxious (if you're a parent, you'll understand the psychological state of expecting a first baby in the next month or two) asked almost angrily: "You people give us conflicting advises, what should we do? How do we do good when even you don't agree what's good between each other???" The answer was simple: "We give you all views, all options. It's up to you which one you think is right and good for your kid. That's what parenting is. That's why we are all different people."
Same thing works for companies. Leadership shapes the company. There is no one-size-fit-all strategy. What works for one company, doesn't work for another. Two pizza team size can work somewhere. Somewhere else something else will. People tend to look for manuals, instructions on how to do things, expecting that someone will write it all down and they just need to do what's written. From time to time, we get to hypes about something (check under microservices for example), everyone use it because it's popular, fancy, buzz word. Without thinking - do we really need this? It's like an epidemic (or pandemic?) of paper pushers, no one wants to take responsibility. To take action. And there is no responsibility if you do things as it's written in the manual, right?
Best methodology is - work with your team. Talk to the team. Know how they breathe. And they will tell you what to do, how to organise them, which methodology to use.
"Take care of your people and they will take care of your business."
The observation that this pattern emerges recursively is totally valid. Just as we refactor code and add layers of abstraction, so we refactor org structures when certain teams become hotspots.
The crux of the matter is that as organisations scale up different teams have different "runtime complexity" (if you will).
Scaling up input 2x produces 2x more work for some teams and 100x more work for other teams.
And then we have ourselves the "how do we scale workloads?" discussion on our hands again. If your workload is stateless - you scale it horizontally (more humans).
If you workload is stateful you scale it vertically. I don't know how to scale humans vertically.
Fascinating. Over here (NL) whenever any group orders pizza's, the default is to just order one for yourself. At 'best' we might make a deal with another person to swap a quarter or half of the pizza. It's definitely not a 'group food' though.
EDIT: well, with the exception of the occasional event/party organizer, but that applies to all foods.
In Brazil it's definitively a group thing, specially families. Friday night is pizza night in a lot of homes. I left Brazil 7 years ago so maybe some things have changed, but never once I have ordered a "smaller" pizza for personal consumption. They do exist here in the US, in some restaurants, or even takeout, so I suppose some people order them here.
Here (in TW), not only is a pizza a group food, but it's just a component in a meal with other group foods like chicken, fried potato balls, sausages, or noodles, etc.
In fact, US pizza chains struggled here until they started localizing and adding more foods to their menus!
Yeah of course, but isn't that generally how it goes with food?
You don't go out to a restaurant and order a "personal salad" or even a "personal lasagna" (even though the restaurant obviously makes a whole tray's worth).
> You don't go out to a restaurant and order a "personal salad"
You sort of do. There is a distinction between salads intended for the table to share, salads intended as a single person;s entree, and salads intended as a single person's accompaniment.
> or even a "personal lasagna" (even though the restaurant obviously makes a whole tray's worth)
If I saw "personal lasagna" on a menu, I would expect something that was baked as a single portion. Otherwise, I would expect a portion cut out of a larger tray. Essentially, "personal" here is a reference to the size of the unit that was prepared and cooked and not merely the serving size.
Same with pizza. I expect a "personal pizza" to be a complete pizza that is reasonable for one person.
Not really. It's a size. You can get extra large, large, medium, small and personal. It's something like 16 in diameter for an extra large, 14 in for large, etc. The personal pizza is around 6 in.
Delivery guy ain't comin to deliver you a 7 inch diameter pizza (about ~17cm). But when they're dropping off 2+ large pizza then it becomes cost effective.
Plus i'm not ordering a single large pizza and eating it all -- cold breakfast pizza is also good, and will serve me all week.
Pizzas in the US are pretty huge - they’re not like a classic pizza for one person as in Italy. I think a two-pizza team is up to about sixteen people.
I have generally noticed a "2 large slices" soft limit for people at my work place. Although, my team is generally quite fit and health conscious for folks in their mid 20s.
I'd say 2 pizzas for 6-8 people is totally fine assumption.
In Italy we have what we call "family pizzas" which are supposed to be pizzas that are large enough to feed a family. In practice it's double the mass of a normal pizza, so a two-pizzas team would be 4 people (or 2 particularly hungry devs).
The first time I tried to order pizza delivery in Singapore, I asked my friends, "So, how big are the pizzas here?" The answer left me stumped: "Small is six slices and large is eight slices." I retorted that I could easily slice a 6cm pizza into 16 slices and that wouldn't feed us any more than their large pizza. They looked at me kind of funny.
Would it not be more useful to size a pizza in terms of diameter, not number of slices or how many people its supposed to feed? As you point out, a 6cm diameter pizza can be sliced into 16 pieces, but also some people just naturally eat more than others anyway.
It definitely doesn't need to be a big crowd like that. 8 slices, maybe 3 or 4 people if it's a full meal (2 slices / person is probably typical). Leftover slices are good the next day too.
It depends. I'm not a big eater but I've at times ordered a 45 cm pizza. While I wouldn't finish it all at once, I'd probably finish it in half a day or so. Usually this was after not eating for at least 24 hours, or after enjoying a particular substance. It definitely did not leave me feeling happy in the longer term though.
Well, "thin crust" vs "deep dish" is a pretty huge difference, too. Pizza Hut has or had a "personal pan pizza" that's 15cm or so and considered a meal by itself.
> A pizza 2 inches deep? Surely there is another name for such a meal.
Yes, it's a tourist trap meal. We here in Chicago really do like deep-dish pizza, but many of the more famous brands exaggerate the thickness because it seems as though tourists prefer it that way. A typical Chicago resident isn't going to buy one like this more than once every few years, unless they have visitors that insist on it.
You eat it with a fork and knife. Despite the huge amount of cheese and sauce, a good one will have a really crunchy crust and it should be so good that you consider it one of the best parts of the pizza.
The flavor/preparation/ingredients are what make a good Chicago-style pizza and not the thickness. In more residential areas, you'll have pizza shops where the deep dish pizza is no more than 1 inch, which is really what a Chicago resident buys for themselves (but the thin crust is most definitely purchased more frequently).
As far as I can tell [Chicago-style | deep dish] pizza[1] is uniquely specific in describing such a preparation. No obvious alternative Pie-, Tart-, or Flan-based descriptor showed up when casually searching.
Area is pi x r^2, which for a 16" pizza would be pi x 8^2 = pi x 64, which is right about 200in^2
A few of the pizza places around here offer 20" pizzas, which would be pi x 10^2, or pi x 100 = 314in^2, which is actually big enough to feed a couple people.
That said, whenever I read "two-pizza team" (a term I've never heard before), I assume that means 4-5 people at most.
Surprisingly, I have found that to be true with people in tech.
Many folks going vegan, preferring public transport/bikes, eating very healthy (many of my colleagues were in high school/college sports teams), avoiding waste and actively observing the 3Rs.
Tech isn't what it used to be. It is trendy to be in tech now. It is the choice of career for the do-everything high school valedictorian that cares for the world with a 4 page resume.
> Tech isn't what it used to be. It is trendy to be in tech now. It is the choice of career for the do-everything high school valedictorian with a 4 page resume.
Oh god, part of the reason I went into tech is because I didn't have to be this (and partly vice versa)
yes - at those bigger "pizza by the slice" joints anything more than 2 slices for lunch will be driven by pizza-induced greed and I definitely won't get any work done afterwards. At dinner post-work I can maybe put away 4 slices...
Must be a regional thing; I've never heard the term "slice pie".
Almost all the by-the-slice places I've been to take slices from their large or extra-large pies. The only exception I can think of would be Pinup Pizza on the Las Vegas strip (30 inch diameter pie).
In my experience there aren't many more overweight Americans than there are overweight British or European people, but the difference is when an American is overweight they're impressively overweight. Need-a-golf-buggy kind of size. That's very unusual outside of America.
I've only experienced the southern part of the US (mostly Texas), and I was shocked to see how many more overweight people I saw, in general.
But honestly I'd say the same about specifically the UK compared to most of the EU. So maybe your experience of Europe is skewed by the UK?
Of course, statistics can probably provide a better answer. Maybe EU people have generally become just as overweight as Americans, but there is more of a stigma so they hide it better? And the 'impressiveness' definitely might play a role too. I can probably count on two hands the number of times I've seen someone in a supermarket so overweight that they needed a cart, while I saw multiple individuals every time I went to a wal-mart. Maybe I don't see them here because they simply don't fit into most of our supermarkets, or they're too ashamed?
Still, I'd be surprised if obesity is really just as bad in Europe as it is in the US, excluding the UK specifically.
So, this is _kind_ of true, depending on country. The UK and US have about the same rate of adults overweight || obese (about 66% each), but the US has a much higher rate of obesity, ~38% vs ~25%. However, the UK is the fattest large country in Europe.
Some countries really are much thinner. France is 40% overweight || obese and 10% obese, for instance.
Small, competent teams work well. Why do you find that incredible.
(disclaimer: it's my experience. Also, I've only worked for small companies on relatively small projects (a few man-months or man-years), things may be very different in large ones).
The problem described in the article is one the industry has developed a solution for: SAFe, which is explicitly designed to help small teams align their goals and yeah I can't finish this with a straight face.
Haha SAFe when you want the worst of all worlds around how to setup software development teams.
More seriously SAFe is trying to solve a real problem but to actually solve it involves much deeper organizational change because of Conway's law then most people are comfortable with.
Really like the article.
How do you approach a reverse situation. Where you are working with a small team and there are lot of moving pieces. I work for a small org which builds and maintains their own in-house software. It's not a single product, more of a duct tape of tools. Given a team size of 10 people and ~50 projects, like a bunch of cli tools, web applications, desktop applications, written by many people and passed down legacy stuff, how would one organise the team and drive the development effort.
I like this article a lot, it's a pretty good summary of the problem.
> Most developers, especially in larger organizations, complain about meetings,
I would quibble with this though - I think this depends a lot on your manager, your project, and some other things. I've been part of start-ups that have a daily standup that lasted over an hour and involved everyone in the company (~20 people), and the time in my career I had the fewest meetings was when I worked for Dow Jones (not a FAANG, but also not a small company). My experience working for a few different start-ups is that start-ups have as many meetings, they just tend to be more ad-hoc, less formal, and might not always involve a formal Outlook Calendar invitation.
I'm actually going through this at my current job. We have a team of 8 where some report to essentially the head of the team and some report to me, a "lead", who reports to the head. This makes absolutely no sense to me. I'm hearing that things are setup this way because having 7 direct reports is too many. Even if we ignore the weird org chart, having say two teams of four doesn't make sense to me if everybody is working on the same things.
Can someone please explain if I'm thinking of this the right way or not?
7 direct reports is very normal for a manager. One thing to dig into is whether they think 7 direct reports is too many for you (as opposed to anyone) and they just don't want to say it directly. This could be because they think you are spending too much time on IC tasks (coding) and won't be able to handle that many, you're too junior (recently started managing), or there are other issues going on with you or the other lead that your senior management hasn't been explicit about. You can do this constructively by asking more about what they'd be looking for to show that you could handle that scope and how to set goals/improve to get there.
7 direct reports actually seems fine if this person's role is primarily management. If they're also doing some combination of tech lead/product stuff they may want fewer reports to free up time for non-management activity.
Delegating some subset of direct reports seems less like it's about product or technical direction and more about aggregating and filtering management concerns. Presumably the whole team still works on the same thing and plans their work together, it's just that you do half the 1:1s, deal with what you can, and kick things up the chain if you can't.
I guess I'm jut having difficulty defining what my team does vs. others that are on the same larger team. There's also a weird extra level on the org chart where ICs on my team and ICs on the head of the team are on different levels on paper.
Looking for some bright minds, agile minds opinions how one should structure and how should Security Team work in an agile organization (100 devs).
Where I agree with the article, for software dev, I am not sure if this will be applicable to Security Teams.
Security Team ideally should deliver "security" of the company, however team cannot do it alone, we rely on other teams (devs for code, devops for infra), employees (phishing) and also need to collaborate a lot.
How would you tackle Security and Security Team in agile organization?
At a higher level Agile is about delivering value end-to-end as soon as possible, repeated a lot of times. The iterative part is important, because you're supposed to be measuring and learning based on past deliverables.
I don't know how your company organizes the security teams, but both at Yahoo and now at GoDaddy the security folks delivered a lot of software. Code scanners, patches rollout, monitoring, etc...
I agree you can't exactly deliver phishing protection, but for example I've seen fake phishing emails being sent by executives, and then the security team measures if employees are taking the bait. You do that every once in a while, measuring if things are improving or not. Maybe there are other angles you can use to approach how you measure the value your team delivers.
I think a company cannot run only on teams delivering features. There will always be some functions like HR, legal or sales. I think security fits in there nicely, it is quite similiar to compliance. A security team is not delivering security by itself, it is more like an HR department trying to prevent workplace harassment or a legal team trying to prevent GDPR violations.
You might also think of it not as a team at all, when you are consulting for other teams, you are delivering features as part of that team.
Maybe there are too many managers, that should be elsewhere. Because management is money and glory and this attracts wrong kind of people. And then all the adventures and problems with management start. Engineers, on other hand, with technical experience and some charisma are hard to find. These are doing well as solo entrepreneurs.
Not every country way of doing things is that rewarding for solo entrepreneurs and if one doesn't want to be dragged into management they need to be willing to fight against it at every opportunity, because on most companies it is not natural not wanting to be promoted.
A middle manager makes their career out of being present at the time, publishing their distilled wisdom in a best-selling tome, translated in 50 languages: Business at the speed of bacteria.
> What might have been a “Data Delivery Team” charged with delivering fresh data to customers unfortunately becomes “Data ingestion Team”, “Data processing Team” and “Data Release Team” (real world example).
This split is eerily similar to Backend, UI, Ops, which is the very thing the author criticized earlier in the post. It sounds like the teams they ended up with just weren't cross-functional teams.
There's another tell, too: "Data-Delivery". What does that even mean? From my perspective, I have zero clue. There's likely a dozen different ways to slice that up into discrete sets of user experiences of features. And then you can organize cross-functional teams around those experiences, like: reliability, visualizations, integrations, etc.
Of course, things aren't always that clean. The real world is much more murky.
>It sounds like the teams they ended up with just weren't cross-functional teams.
You are exactly right! And yet everyone thought they were organized by functions/objectives/OKRs or whatever. The blind spot is what I want to highlight here.
"Data-Delivery" is an anonymization. The team shipped a specific data set that I did not want to name.
This is exactly what I saw at Amazon. 6 teams working on the same thing, massive communication overhead/hoops to go through to get accesses, too many PMs bickering and trying to get buy in from other stakeholders which slowed down the whole process.
The basic premise behind two-pizza teams, at least as given here, is flawed. While it is true that if a task requires limited communication, a small team could complete it quickly, most significant tasks require more than a little communication, in which case, adopting a structure that limits it is counter-productive.
If you have a small team whose members all have a deep understanding of the goal, the strategy for achieving it, where the problems will be, and what trade-offs are possible, then they can achieve a lot with the minimal necessary communication, but you do not get any of that for free just by making small teams - that would just be cargo-culting the issue.
> The concept of the “two pizza”/”autonomous” team arose from attempts to minimize communication between multiple teams and empowering a single team to be in complete control of delivering customer value.
> Before this idea gained popularity, the most common way of organizing teams was in terms of Backend, UI, DBA, Ops etc.. Building any feature required a lot of communication, collaboration, and alignment between all these groups.
I always thought this was called cross-functional and saw the term way before anyone started talking about two pizza/autonomous teams.
When I was at Amazon, it was full of two pizza teams. Seems like a good enough strategy to me.
I don’t know that necessarily cuts down on “this meeting should’ve been an email”.
And I would often walk past conference rooms to see the TV showing four remote meetings of other two person teams. Which means in that meeting was a ten pizza meeting, IDK if that was the plan.
I don't really agree overall. Yes I understand a "two pizzas" team isn't perfect and does introduce new problems comparatively to whats its replacing, but when you look at the alternative which you call the "Autonomous team mission" you have a even worse set of problems.
If you're interested in team sizing, dynamics and communication streamlining, you might be interested in the book Team Topologies by Matthew Skelton. It's an (admittedly opinionated) approach that attempts to solve some common issues with (software and ops) teams.
Another issue in big companies: There are obvious inefficiencies as autonomous teams do redundant work. Some things should be centralized (eg payroll) but others not (eg design). Where to draw the line? For example, should autonomous teams create their own build tool chains?
This is the exact dilemma described in "High Output Management." Corporate organization is the art of deciding what to centralize and what to decentralize.
That's about the same as in Europe. I can't eat a pizza for dinner, I will be hungry after it, and I'm not even very big (about 6 foot, which is below average, and < 160 lbs)... (Maybe because I sport more than average?)
A 6' tall 160 lb man who does vigorous exercise 5+ times a week needs 2500-3000 calories per day to maintain weight.
So if you're still hungry it's because you didn't eat much else all day. Or you're training like an Olympian. Or you're on your way to getting fat. Or European pizzas are low in calories.
So what does it look like? Well, as devs, we have specific feature requirements handed to us with little-to-no prior input, we're always behind schedule so we're never afforded the time and space to do things right, it's always "we'll fix it later". We occassionally have some kind of "our competitor is doing this, we have to do this" piece of work that comes in and shifts all of our roadmap items later of course. No one ever stops to ask whether we're having the impact we anticipated, or whether it's even worth keeping the work.
Combine this with a replatforming-through-new-work effort on the go, you've got a slow mutation from the old platform into an even uglier new platform that doesn't get the right effort applied to it.
But hey, we're "agile", we have mission teams, we have two-pizza teams, we're goal oriented. I mean, we say these things, but in reality it's planned out work, with deadlines, delivered by multiple generic teams named after areas of the customer journey that end up being the center of philosophical debate about whether this bit of work lives with _this team_ or _that team_.
Although I don't think the team size or the number of them is necessarily the problem, the article rings true in my experiences - but it's down to culture of the organisation, more than the topology.