When a team is too big

https://blog.alexewerlof.com/p/when-a-team-is-too-big

by gpi • 1 year ago

123 145 1 year ago

blog.alexewerlof.com

bobek• 1 year ago

I would recommend a slightly different approach to written/async standup. Issue I have with stand-ups is the ad hoc nature of proving a report, instead of making it a collaboration space

https://www.bobek.cz/the-power-of-written-standup/

cplan• 1 year ago

The solution arrived on here sounds a lot like the original meaning of the term "devops", and Amazon/AWS' concept of a T-shaped engineer - a generalist with deep knowledge in one area (or a least, AWS is where I personally got acquainted with these terms).

JoshTriplett• 1 year ago

https://en.wikipedia.org/wiki/T-shaped_skills - around since at least the 1980s. Broadly speaking it seems like an accurate description of good engineers. (I've also heard "pi-shaped", to more explicitly suggest that experienced engineers probably have multiple areas of deep expertise.)

agge• 1 year ago

Laughed when I read ”We where 11 engineers that could be fed with 2 pizzas”. But you are in Sweden? You can feed maybe 3-4 engineers with 2 Swedish pizzas. Which is also coincidentally a very decent team size ime!

cess113• 1 year ago

I've assumed the 2pizza-thing was based on something like 'familjepizza' rather than the regular swedish size.

I agree about team size, 3-5 is good, any larger and people will start wandering off on their own or create cliques.

I'm also not a fan of "sync standups", that's micro management garbage. A three minute 'i'm blocked, who can help?' or 'no blockers today' session, that's the sweet spot. If someone wants a report on progression and so on they can book a meeting with a clear agenda in advance and the relevant people can prepare and do a succinct description of where they're at. No meeting that takes more than five minutes and doesn't have a set agenda should ever be held.

Propelloni• 1 year ago

I'm mostly with you. However, dailies are little "dayplanners" for the team, too. For the benefit of the team as a whole, I'd suggest more context, like "I'm still on the state machine, but should be done today. After that I'll start on the DB migration. Jenny, I'll ping you then." or "Still fighting the runtime for the Box ticket. I need a second opinion."

Takes only a few seconds more. Of course, the Dev should know beforehand what he is going to say ;)

frollogaston5• 1 year ago

I've been in many 15min meetings that I felt were a good use of time, cause everyone was involved the entire time and the topic was important. Not so many 30min ones; those usually end up being 2 people talking while the rest spectate.

The 2-pizza thing coined by Bezos means 6-8 people.

diggan3• 1 year ago

You can feed maybe 3-4 engineers with 2 Swedish pizzas

I dunno, we (Swedes) tend to do personal pizzas (1 per person), at least where I grew up. They're most likely talking about family size pizzas or something, but even then it sounds like too little, you'd feed maybe 3 people tops per family size pizza.

Or maybe me and my friends were just overly excited about our pizzas.

twic• 1 year ago

One of the under-appreciated impacts of Ozempic is that we can make two-pizza teams much bigger.

dagw• 1 year ago

Another 'hack' to increase the size of your two-pizza team is to buy crappier pizzas and 'forget' to buy enough drinks.

asplake• 1 year ago

Could have been titled "When a team lacks sufficient reason for colleagues to care what others are up to"

abhaynayar• 1 year ago

This article speaks to me a lot because I have been meaning to become more of a generalist, cause my role in security (specifically web-bot detection) seems to be too narrow of a niche, which is fine while it lasts, but doesn't seem too resilient to change..

But I also do not wish to get into leetcode type-stuff.. so I have been thinking maybe getting some devops/sre/cloud-infra type-stuff.. not-sure.. if anyone else has been through this, it would be great to hear how you transitioned..

lknuth• 1 year ago

If you have or can make the time, some side projects can go a long way. Mainly to find out what you are actually interested in. I usually give myself some guard rails as to not spend too much time one one thing (perhaps say a month) and then see where that takes me.

Then, I write about the project for two reasons: I get an article out of it that I can share _and_ I get to digest the project as a whole.

Just pick anything that seems interesting and build something. Later, you can even build on top of earlier projects.

FinnLobsien2• 1 year ago

One aspect this article doesn't feature that's super important imo is the difference between a team that's figuring something out and a team that's keeping something going.

An internal billing team requires entirely different people and ways of operating than a startup's growth team iterating to product market fi.

hanifbbz5• 1 year ago

Please elaborate

FinnLobsien2• 1 year ago

Basically, there's a spectrum which has at its ends two extremes:

1. R&D 2. Maintenance

These aren't about the actual activities performed; R&D could also be something like finding product-market fit at a startup and maintenance could also be working in product/engineering on, say the MS Word team. Just two opposite ways of operating.

In R&D mode, you want to encourage diverging ideas and err on the side of just trying if something works, which typically means you hire small teams of people who think differently, don't anchor too much to the past and avoid excessive layers of management and bureaucracy.

This is because you want to EXPAND the scope of possible actions and outcomes.

In maintenance mode, you want to get things just right every time and minimize the downside. For example, a radical redesign of MS Word would be a horrible idea because the entire world is used to a design they've known for 20 years. Here, you want people who keep things more or less the same. The same is true for internal infrastructure like billing, APIs, etc. This requires people who are less creative, but extremely thorough.

This is because you want to CONTRACT the potential scope of actions and outcomes.

mettamage• 1 year ago

Solution: people become full-stack developers.

The story is interesting and gave a lot of value but the end result is underwhelming.

Any dev worth their salt can learn enough of a different discipline in the dev field. Or maybe I am biased because I was “raised language agnostic at uni”.

Wait, it’s not the result that’s underwhelming. It’s that it almost reads as an insult that people have the expectation that learning different dev disciplines might be impossible. I just can’t see what is impossible about a different discipline when you are already an experienced software engineer with a CS education.

If one came from a coding bootcamp, yea then I get it (I taught at one).

NilMostChill2• 1 year ago

A possible solution, perhaps, but i personally wouldn't consider it a good one.

I can full stack dev, i choose not to because i don't like the current state of the front end ecosystem but that's a preference not a limitation.

I can also do devops, standard sysops, data engineering/analytics to a degree and some other misc stuff.

I would absolutely not expect that to be a *requirement* to be a member of a functional team.

Any dev worth their salt can learn enough of a different discipline in the dev field. Or maybe I am biased because I was “raised language agnostic at uni”.

Setting aside the true scottsman of that statement, the technical ability needed to learn other disciplines isn't always the limiting factor.

Not everyone has (or chooses to allocate) the time to keep on top of the multiple sets of ecosystems needed to keep up with all the disciplines, being language agnostic is one the least important parts of being effective in multiple dev disciplines.

owebmaster• 1 year ago

but you are fullstack, it doesn't mean you work in all steps of the software lifecycle but you potentially could. That's the point.

dangus3• 1 year ago

It’s a flawed solution because it only works for this specific technology. It only works with full stack web developers because the breadth of the subject matter isn’t too wide.

Sometimes a team has to consist of people who have very different specialities that simply do not intersect and are too burdensome for all team members to gain proficiency in. There is often no budget to split the team or the team is already very small. This article doesn’t offer a solution to that problem.

Example: you’ve got an operations team of four people plus a manager. Most of the company runs on a containerized application using modern open source technologies, but then there’s an important legacy cash cow application that involves an Oracle stack running on Windows VMs. Are you really going to make your Kubernetes/Linux team members learn to operate the Oracle database and Windows servers that your specialists on the team manage? Will they even want to do that work without quitting and working somewhere else?

Vinnl• 1 year ago

Oh I can do backend work, but I'll easily introduce performance issues, log too much or too little, get lost as soon as I open one of our observability dashboards, or design an inefficient database migration.

Likewise, I've seen more backend-focused people introduce horrible accessibility issues, completely misunderstand the client-side lifecycle, or produce a giant mess of intertwined global state.

It's useful to be able to wield all the tools to some extent, but I've found true full-stack to be a mess. (Where "true" already means "works on web APIs and in-browser code", i.e. still ignores large parts of the stack.)

62951413• 1 year ago

By the time you acquire enough experience to do it in 25+ years of lunches the job market starts showing less interest in you. But that's the only promising strategy in the LLM-dominated world I guess.

frollogaston5• 1 year ago

There are plenty of projects where frontend/backend is a logical way to separate things, in which case it can be much more cost-effective to hire frontend specialists. Not only are they more familiar with all the specialized tools, but they can also do it with only bootcamp education.

I've been in teams with generalists only, and yeah we can all deal with UI, but it takes longer. No matter how good someone is, they can't have every detail fresh in their head all the time.

Or what about a full stack that's backend-backend, in a large corp with multiple internal services talking to each other? Only the higher-tier engineers have a good understanding of all the teams' moving pieces, even then not so deep.

Etheryte• 1 year ago

This was less disruptive than taking 30 minutes (less than 3 minutes per person) for the daily standup, which often dragged to 45 minutes and sometimes even an entire hour!

More than anything, this sounds like no one was actually leading or moderating the standups. If you have standups daily, you should be able to give an update on what your status is in a minute tops, given it's business as usual. If there's any followup discussions to be had or questions to be resolved, the startup is not the right place to do that, everyone who is interested or affected can continue the discussion after the standup. This requires discipline from both the person leading and the participants, but we're talking about a professional setting here, this isn't a big ask.

Having spent some time living in Sweden, the situation described in the article is not too surprising to me. Swedes are incredibly nonconfrontational and even the thought of politely cutting someone off because they're talking too much in a standup would be faux pas for some.

piva00• 1 year ago

Not my experience working in Sweden for the past 10+ years. Likely that I had outlier experiences here but standups have always been short, the person leading it had complete autonomy to call out "I think this should be discussed after stand-up" whenever some discussion started to go on for a little longer (usually about 2-3 minutes is too long).

The thing I noticed being culturally different is that you just don't cut off someone while they're speaking, you raise your point by politely asking for the space and sharing your opinion, and decisions about it are made through some consensus (which never failed when a discussion is going on for too long).

mcv5• 1 year ago

It's definitely possible that culture matters. I wonder if there's something about American work culture that makes their standups so often dysfunctional. I'm Dutch and I have pretty good experiences with them in most projects.

cweld510• 1 year ago

Reading between the lines, my guess is that the standup was the only forum for communication that the team had, and lots of communication was required because people weren’t working on the same things. The only real solution to that is to get people talking outside the standup.

marcosdumay2• 1 year ago

Turns out that when you already have a meeting scheduled every single day, people (except for a few) just stop seeking each outer at other times.

As much as this looks like a good thing superficially, dailies aren't fit for solving any kind of coordination problem, and that's the only meeting you will get.

cainxinth• 1 year ago

More than anything, this sounds like no one was actually leading or moderating the standups.

One of my clients hired a former U.S. Marine. I so enjoyed attending the meetings he ran. He managed the clock with ruthless efficiency.

alistairSH2• 1 year ago

Tangent: Way back when I was in Scouts, the scout master was a USN missile submarine captain. He was a quirky guy, not the least of which was his ability to schedule things to ridiculous levels of detail... cross-country trip to go backpacking, and he'd have a lunch stop at 13:14, gas stop at 17:29, on base (we would stay in open barracks at military bases across the country) by 16:09. And wouldn't you know it... we were usually within a few minutes either way. And he managed to pack a lot of side-trips/value into the days we were on the road. It was really wild.

watwut4• 1 year ago

One problem with efficiently running standups is that ... they are the most useless meeting in the world. It is short, ok, but nothing whatsoever would change if it did not happened.

imiric• 1 year ago

From my experience as a SWE over the past ~15 years working in teams ranging from 10+ engineers in large companies doing daily in-person standups, to ~5 engineers in small remote-first companies doing daily videocall or async standups, and everything in between: the standup ceremony is a waste of everyone's time. Its only purpose is social/political as with any meeting, and giving micromanaging managers something to do and something to report to their higher-ups (I've been part of teams where the "Scrum Master" and even "Product Owner" attends the standup...). Which is fine if that's the way the company works and the participants enjoy the ceremony for personal reasons, but there are no tweaks to the standup formula that makes teams more productive or functional.

If I'm working on a solo project, nobody cares about the details of my progress besides the users I'm building it for. Whether this is an API for someone who is part of the standup, or a feature for someone in the company, I would communicate with them directly when needed. They would already be aware of my progress, and they usually don't need to be informed of it on a daily basis. If I'm stuck on something, then I would also communicate directly with the person who can help me.

If I'm working on a team project, the team members would already be aware of the project status, whether that's via pull requests, issues, or direct communication (in-person, chat, email, etc.). The users of the project would be notified of the progress as needed in this case as well.

So the standup ceremony is redundant for the few people familiar with the context, and completely useless for those who are not. The standup assumes that teams aren't communicating already, which is ludicrous.

It's about time that the industry accepts that the Agile manifesto, while noble in principle, has been completely misunderstood and corrupted in all its implementations, and that the modern software development process is not an improvement over the Waterfall one it aimed to replace.

To me the only process that makes sense is giving engineers autonomy, assuming they're self-sufficient and capable of making good decisions, and providing them with a very lightweight set of tools for collaboration (issue/task tracker, code review, chat, email, meeting, etc.). A process that works best for that team will emerge by consensus. Anything that's imposed from the top down or by cargo culting some process that worked for some other team will inevitably cause friction and be of little practical value.

lepolas• 1 year ago

As with many things, it depends on the team. Some teams and people really do seem to need some amount of daily direction to have confidence in the work they are doing, and that does have a meaningful impact on productivity.

My bias is always to only participate in frequent recurring meetings as a last resort, but sometimes they seem to be necessary.

lovich• 1 year ago

giving engineers autonomy

That is almost as offensive as a slur to management in 95% of companies

sirwhinesalot2• 1 year ago

If everyone gives status updates that are either "Task is progressing as expected" or "I'm blocked as I mentioned on slack yesterday", then what is the point of the standup?

WorldMaker2• 1 year ago

Presenteeism check. Roll call, just like grade school.

To be entirely unfair, I think that's always been the real reason for the standup "ceremony" to get a daily roll call because developers doing "agile" apparently can only be trusted if treated like school children. I feel that way because that's always been a part of the point of why it is called a standup: it's supposed to be as boiled down as just "progressing" or "blocked, who can help?" and it's supposed to be done standing up so that it is intentionally uncomfortable and everyone moves quickly to get back to their seats and get back to actual work getting done.

I continue to advocate that standups are mostly useless and should just be a Slack message at most.

ctkhn3• 1 year ago

I've had them go 90 minutes because they branch off into tangents from people's updates and they become a solution session between one dev and our manager. Info is pretty silo'd (not required for security or anything, just bad management) so usually nobody else knows what's up with their ticket and manager is in other meetings all day so he never responds to dms to help on stuff. I've tried cutting people off to keep it moving and have been reprimanded about it, now I attend with camera off and do my dishes during the meeting.

There is a value to standup in calling out "my PR needs eyes and nobody responded on slack" or "hey I'm blocked on X who wants to pair later" but outside that it's useless.

jahsome• 1 year ago

I get so many chores done during sprint ceremonies, including standup. Every session is a continuation of the same horribly inefficient planning/refinement/status update combo which doesn't effectively accomplish any of those things, and I've stopped caring because I just go to town with a mop.

mcv5• 1 year ago

90 minutes is not a standup. Keep it brief. If something needs to be discussed in more detail, take it outside the standup with just the people interested in that issue. A good standup is often followed by a bunch of smaller meetings to discuss details or help people who are stuck.

cbm-vic-20• 1 year ago

they become a solution session between one dev and our manager

This happens when the manager doesn't understand the point of daily standups.

I've been on both sides of this. Ideally, the daily standup should be able to operate without a manager even being there: it should be a session between the team members who are actually doing the work, to give them a bit of time to come up out of the weeds of what they're working on to make sure that they're not getting themselves stuck, or to unstick their teammates. The meeting is only as long as it needs to be. In practice, people aren't really good about keeping Jira up to date, or will bury themselves into a rut to power through a problem.

If it becomes a solution session between a manager and a dev, while everyone else on the team stays on mute to witness all of this, that belongs in a different meeting.

mcv5• 1 year ago

Interesting observation about Swedes. I'm Dutch, and I've noticed Swedes and Dutch people and culture are very similar in many ways, very egalitarian and everything, but the Dutch are not hampered by politeness. And our brutal honesty might help keeping standups efficient.

I've been part of several "too large" teams, and one in particular, with 20 people, I was really surprised it worked so well. Standup would take 20 minutes, everybody paid attention. There were informal subteams that would discuss details outside the standup.

The most official subteam was the testers (first 2, later 4) who also controlled deployment, because everything had to go through them.

Somehow it was a very efficient chaos. Not scrummy at all; technically we had sprints, but everybody ignored them and it was more kanban. Some features would take months, others would be done quickly. Some would restructure much of the code base. I've seen PRs that touched hundreds of files. Somehow it all worked and it worked very efficiently. We even took over another project from a team in the US that was going nowhere, and we managed to deliver it within their original deadline despite the other team wasting a year doing nothing.

I still wonder how that team could work so well. We weren't all generalists; I was, but others would do only fronted, only backend, or spend most of their time thinking about taxonomies. The team did seem to foster a culture of friendly but brutal honesty without any punching down. Main tester and main backender would rib each other a lot. People eagerly took responsibility for fuckups. Everybody was considered an expert on something and nobody knew everything, so we'd consult each other a lot.

elktown5• 1 year ago

but the Dutch are not hampered by politeness. And our brutal honesty might help keeping standups efficient.

Anecdotes are fragile; I've had the exact opposite experience, Dutch people taking offense for being direct when reviewing code.

PeterStuer• 1 year ago

'This requires discipline from both the person leading and the participants, but we're talking about a professional setting here, this isn't a big ask'

In my experience anything that requires discipline is too brittle to last. You can argue it should not be so, but it is.

Instead of discipline, an extrinsic force, robust motivation should be intrinsic, born from delivering a real value feeling to all participants.

abc-1• 1 year ago

Surprised these people had to iterate and run these experiments. I thought all of this was common knowledge in books. Maybe it was an experience before this was common knowledge, but it’s not uncommon to see “painfully figure something out instead of cracking open a book, write a blog post about it like it’s some new found knowledge”.

hanifbbz5• 1 year ago

Could you be more specific about which book and chapter talked about this problem and how the solution was different or similar?

cenny• 1 year ago

Of the top of my head I can think of Extreme Programming Explained, The Art of Agile Development, Software Teaming, The Pragmatic Programmer.

madaxe_again2• 1 year ago

There’s another aspect that the author doesn’t touch upon that seems to materialise when a team reaches a certain size - politics.

For whatever reason, whenever you have more than about seven people in a team (in my experience, anyway), office politics seem to appear as an emergent phenomenon, and instead of people pulling together to a common goal they’re suddenly trying to undermine one another.

My best theory as to the why is that too many direct reports result in vying for attention of a manager, and people rapidly realise that outperforming others in their team doesn’t work nearly as well as throwing shade at one another.

Our solution was to constantly rotate - task oriented teams formed and dissolved on a per-case basis. This broke the cycle of power-brokering, and limited the fallout from whatever petty drama was manifesting this time.

jodelamo• 1 year ago

My best theory as to the why is that too many direct reports result in vying for attention of a manager, and people rapidly realise that outperforming others in their team doesn’t work nearly as well as throwing shade at one another.

This just sounds like a more deeply rooted work culture problem to me.

sillystu04• 1 year ago

I suspect it's more of a human nature problem. Perhaps a good work culture might allow you to delay its oncoming slightly past 7 people - but eventually all large social groups get political dynamics.

protocolture• 1 year ago

I really need to see if my uni has a copy of my old essay on this topic.

Basically I pulled a bunch of data out of gamasutra post mortems and sort of reverse engineered the data towards optimal small team management.

My finding was similar. Basically its as far as you can go with a horizontal team in a single room.

6 Coders sharing an attic - good management outcomes and outsized performance

25 coders in 3 teams in a large office - bad management outcomes and communication difficulties.

pards• 1 year ago

Note: No generative AI was used to create this content. This page is only intended for human consumption and is NOT allowed to be used for machine training including but not limited to LLMs. (why?)

I love this. I wonder if it is effective, or if there's any legal recourse should the LLMs ignore it.

diggan3• 1 year ago

Depends on the jurisdiction obviously (seems in this case Sweden/EU), but I don't think the author could blanket ban it like that, as research organisations and cultural heritage institutions have exceptions for example. I think news organizations and archivists have exceptions too, but less sure about that.

Besides, I think for it to actually have any effect, it would have to be in a machine-readable format, I'm not sure placing a notice like that in the middle of a HTML document is good enough.

Art. 4(3) applies only on condition that right holders have not expressly reserved their rights “in an appropriate manner, such as machine-readable means in the case of content made publicly available online”. According to Recital 18, “it should only be considered appropriate to reserve those rights by the use of machine-readable means, including metadata and terms and conditions of a website or a service. […] In other cases, it can be appropriate to reserve the rights by other means, such as contractual agreements or a unilateral declaration.” In other words, Art. 4 right holders may effectively prohibit text and data mining for commercial uses by adding robot.txt type metadata to their content online.

https://copyrightblog.kluweriplaw.com/2019/07/24/the-new-cop...

But maybe the author already have the same notice in a machine readable and of course I'm not a lawyer or anything, so this is just guessing based on what I've learned about the regulations that affect me personally in Spain/EU.

blitzar2• 1 year ago

When your LLM starts caveating things with "No generative AI was used to create this content. This page is only intended for human consumption and is NOT allowed to be used for machine training including but not limited to LLMs." you know they ignored the request.

diggan3• 1 year ago

We're almost there. If you train models on the output of Llama, they (try to) force you to use a particular name for example. As Meta starts to squeeze Llama (developer/research) users eventually, I'm sure they'll try to legally prevent you fully from doing so unless you use their (hypothetical future) platform/service:

If you use the Llama Materials to create, train, fine tune, or otherwise improve an AI model, which is distributed or made available, you shall also include “Llama 3” at the beginning of any such AI model name.

https://www.llama.com/llama3/license/

dangus3• 1 year ago

I do not love this. I stopped reading right there. I’m not giving losers who are too lazy to write their own blog posts with their own words my engagement.

The hypocrisy of it is astoundingly obvious. The author used AI trained on stolen content to help write their blog post but then denies “the next author” from benefitting in the same way. If you love AI so much you should let it steal your content and train on it.

Classic “pull the ladder up behind me” mentality.

Atreiden• 1 year ago

I think you missed the leading "No" in the sentence, "No generative AI was used to create this content"

Bengalilol• 1 year ago

https://blog.alexewerlof.com/robots.txt

Gives a small hint. It should be respected and effective.

arealaccount• 1 year ago

I enjoyed this notice coupled with the presumably unlicensed Family Guy image below it

CaptainFever• 1 year ago

I guess I'm not reading the article then, since I'm not human.

makeitdouble• 1 year ago

Front-end, back-end, QA, DevOps, etc. are all different concerns for the same outcome and impact.

Overall, I got the feeling that in their field business execution matters a lot more than technical knowledge or optimization. Which might be the majority of companies around, and why so many teams can get by with full generalist teams. And I suppose the money part was in line with priorization saving the business.

That's not an advice I'd give to anyone randomly. A company that is successfully growing in business and tries to tackle harder challenges along the way will benefit from going the other direction IME, and progressively push for more specialization to get better results without having to aggressively grow the teams.

teeray• 1 year ago

The main value of a standup is to have a dialogue about blockage and spark opportunities to work together.

I never understood this about “blockers” as classically presented during the rites of standup. If you’re waiting up to 24 hours to voice a blocker or work with someone to resolve it, you’re waiting too long. Jump in chat with your team, tell them how you tried to unblock yourself first, then ask for help.

mgkimsal2• 1 year ago

It's odd, because I've known folks who 'wait', but most of the time, when I hear someone voice a blocker in a standup, it's notice that "this is already something I've tried unblocking by ABC, and have talked to persons XYZ, and it's still a blocker". Or sometimes, people saying "I was blocked yesterday on X for Y hours, which is putting things back a bit, but now moving forward again".

So yeah, waiting until a next meeting to get announce that you're going to start working on a blocking issue is nuts, but I don't actually see that specifically all that much.

alistairSH2• 1 year ago

This is what I see as well.

"I ran into X, tried Y and Z, then asked Bob, Bob wasn't sure, anybody else have ideas?"

"We discovered a dependency on Team Z to complete Q, Mr Bossman, can you talk to their manager, as the engineers weren't sure what to do?"

And yes, both of those could be handled in Slack. But, as a manager at a medium/large company, the amount of Slack messages I get daily is MASSIVE (both direct and in channels), so a face-to-face has some value in getting the issue front-and-center (and not lost in a pile of clutter).

Yes, in a perfect world, there isn't all the clutter in Slack. But, in 25 years in industry, that's rarely true.

rendaw• 1 year ago

What's the value of saying you were blocked but now you aren't?

The other case is you're saying it's a reminder. But that should be obvious from any ticketing system - the issue for what you're working on should be set to Blocked and the manager should get a status update email or be able to check it next time they're free.

I think the answer is some managers prefer to have people tell them things in a call.

frollogaston5• 1 year ago

This is hard in big teams/departments because people end up getting pinged constantly to unblock random stuff. They want to batch up and schedule things. People work on 2-3 things in parallel anyway so they can switch tasks when blocked, like Javascript. So 24hr can be the sweet spot, but as I said in another comment, I've seen the mistake of picking 7d instead!

fxwin• 1 year ago

There are people who are reluctant to ask for help with things (i know i can be), and end up wasting time trying random (non-)solutions. The standup puts these people "on the spot" and enables them to move forward within a reasonable timeframe.

crazygringo• 1 year ago

If you’re waiting up to 24 hours to voice a blocker or work with someone to resolve it, you’re waiting too long.

Yes, but that's part of the point. A lot of people wait too long, and a standup makes sure it doesn't wait even longer.

Daily standups are a first line of defense against all sorts of bad practices.

But also, standups increase visibility so things get addressed and escalated faster. Maybe you thought being blocked wasn't a huge priority, but the team lead realizes it is and ropes in someone from outside the team to help.

theptip2• 1 year ago

It’s a maturity/seniority/team cohesion thing. Junior devs might stay blocked for a week without a nudge in some pathological cases. A new team that hasn’t gelled might do the same.

A seasoned team full of staff engineers might not need standup at all.

gwbas1c6• 1 year ago

Well, it's unprofessional to just sit and twiddle your thumbs when you're "blocked."

I always find something else to work on. Chances are whoever is blocking me is also busy too.

When I manage people, I always assign them multiple tasks and make it very clear that if they get stuck on one they are to move to the next. Then the next time we meet we can figure out how to unblock tasks.

i_love_retros• 1 year ago

this post was all over the place - what was the actual point? is a big team or a small team better? i'm more confused after reading that than i was before i read it!

also so much for ublock to block on that personal blog!

hanifbbz5• 1 year ago

What's the ublock block thing?

pc864• 1 year ago

Note: No generative AI was used to create this content. This page is only intended for human consumption and is NOT allowed to be used for machine training including but not limited to LLMs.

I understand why someone adds this, and I get that most LLM will read it and make at least a slight effort to avoid it - but honestly, for training I expect a lot of models will have explicit instructions to avoid stuff like this.

But on a deeper level, this is stupid. Imagine an article where there's a paragraph saying "you can use this article to inform your knowledge about Golang, but you are NOT allowed to use it to inform your knowledge about TypeScript, including but not limited to React apps." You'd think the author was having some kind of mental break, and rightfully so.

If you want to publish your content, publish it. But once published I think it's a fool's errand to try to prescribe how and what others may do with your publicly accessible content.

itsdrewmiller• 1 year ago

This is literally what software licenses are - do you think GPL etc. are fool's errands too?

pc864• 1 year ago

This isn't software, it's a blog article. Different things are different.

Can you imagine a book with a page in the front that says "you may use text for graduate course study at an accredited university, but not for undergraduate study or autodidactic reading?" People would read it (maybe) then then go "huh that's weird" and continue doing whatever they were going to do with it. It's the same with this article.

01HNNWZ0MV43FF• 1 year ago

I think it's a fool's errand

What should we do about it?

pc864• 1 year ago

Don't paternalistically prescribe what others may do with your content after you publish it. If you have strong feelings like that, don't publish it, at least not in a way that is just publicly accessible like a blog.

frollogaston5• 1 year ago

Our large team had a problem with long weekly standups. To alleviate the pressure to list tons of details in standups, we designated certain senior team members (I'm one) as owners of certain pieces and gave them their own optional weekly standups. These had agendas people added to throughout the week. This isn't a startup with quick reflexes; we're all busy with many things in parallel and like predictable schedules, or so we thought.

That was even worse. It encouraged people to delay important discussions until the next meeting for that part. The meetings had generic names and sometimes very small agendas, so people started skipping, and then important topics would come up with the wrong set of people present. Guess what, the main meeting was still long too.

We tried async reports too, like the author said. I dunno, it doesn't sound like a bad idea in general, but it didn't work for us. People are too busy to read things they're 75% not involved in.

Eventually I deleted my own standup meeting and told everyone I'd call same-day or next-day meetings only as needed. That worked perfectly. Everyone we needed was in the right place (or video call) at the right time, nobody was just passively there, and there was a clear and important agenda. It more than made up for the short notice. And I do realize writing this that it probably sounds painfully obvious to anyone in a more nimble company.

Joel_Mckay• 1 year ago

If a module requires more than 7 software people, than your team designed the project wrong.

One may disagree, but that likely means they are pontificating instead of coding. =3

ivan_gammel7• 1 year ago

When daily sync is a trigger for changing org. structure, this is a classic case when the symptoms hide the real sickness. The engineering team was struggling, but it was not their fault and their "solution" in the end forced some people to leave. It is sad. The actual sickness: inexperienced middle management, not aware of best practices. 11 direct reports are too many to maintain awareness of their work and their well-being.

How it should have been solved?

1. 2 or 3 smaller teams supported by product manager. More cohesion, more focus on long-term business objectives, more end-to-end long-term ownership (but high enough bus factor). Have daily sync within those teams and let someone well-socialized steer it, do not make it a report, instead focus on cooler talk and one big task that is currently in their mind. Force them to omit details and schedule ad-hoc talks or go async if they want to go into details. The primary objective of daily sync is to keep people connected, not to keep them updated.

2. Maintain specialization and expertise. When there is a dependency, people are forced to collaborate, build bridges and improve efficiency of communication. When one generalist completes the whole task, the smaller is the knowledge transfer. Generalists are good for one-off tasks, but building a product requires a team.

3. Use horizontal organization for engineering excellency. Call it chapters or whatever you want, but make engineers from different teams working on the same stack meet regularly to present ongoing work, discuss technical topics and technical strategy. Have async channels for that communication too (e.g. pull requests for something noteworthy).

4. People over processes, processes for people. If something does not work, use retro to fix it. Sometimes applying solution to the whole team won't work, but it may work on personal level - do it, as long as everyone remains productive and happy.

People should at least understand that "generalist" route with modern frontend and backend is nearly impossible today, especially when stacks are different. They are vastly different domains developing at a high speed. Nobody is able to maintain up to date knowledge of them both while doing sufficient amount of work without getting burned out quickly.

ownagefool3• 1 year ago

Honestly, I think there are no "best practices" here, there's simply "patterns I've seen work before".

If we put people over processes, you might actually find you can manage a much bigger org. Like if the standup is really killing large parts of the week, you might find killing the standup to be the preferable option. The fact that that's sacrilege and constantly evokes the no true Scotsman tells you all you need to know about people over processes.

ivan_gammel7• 1 year ago

Honestly, I think there are no "best practices" here, there's simply "patterns I've seen work before"

I have been working in the industry for more than 25 years and in many very different companies, even different cultures. Yes, that may be my own experience. I have been in continuous exchange with my colleagues in a big network of European CTOs and I validated it enough to say, that it can be considered a best practice. What it makes different from a law of nature is that best practices do not always work in every possible situation, but they are expected to work in similar environments.

If we put people over processes...

Do not forget the second part of the sentence in my comment. Processes must exist - you cannot eliminate something that serves some real need and expect things to get better. By reducing number of meetings you cannot make management job easier or scale it to a bigger team, on the contrary, you will be doing a shitty job. The sole purpose of a manager is to be an oil in the engine, to facilitate the efficient process, and that includes information exchange and empathetic connections. Not to code, not to move tickets, not to write down the requirements. To talk. If people do not talk, do not engage with each other, you fail at that, because the social fabric of the team will rot. Everyone in the team and in the company has their own agenda and their own goals. If they are not aligned continuously, all sorts of toxic environments may emerge.

Like if the standup is really killing large parts of the week, you might find killing the standup to be the preferable option

15 minute meeting cannot kill large parts of the week by the definition of time measurement units. It's 3.5% or less, depending on how long is your working week. If this meeting takes more, the solution is to stick to the time frame, not to cancel.

surajrmal• 1 year ago

Every situation is different. It really depends on so many factors: what are skills, traits, and preferences of the individuals? How top down are requirements vs bottom up? How distributed is the team? Does the team work on platform, product, or infrastructure? There is no one sized fits all answer to what works best in all situations.

gwbas1c6• 1 year ago

I think your approach would work for a larger company than the article was about.

Edit:

"generalist" route with modern frontend and backend is nearly impossible today

This is simply not true; it all depends on design and organizational priorities. An organization can choose to use the same language in the UI and server, and prioritize the compromises that come with same language development. (IE, C# + Blazor, or Typescript + NodeJS.)

ivan_gammel7• 1 year ago

11 engineers is a big enough company to split the team.

In some cases it may work, however building great UX in browser is not the same job as performance optimizations or security of a server application even on the same stack. Generalist can build a CRUD app, sure, flex layout and ORM are not rocket science. Going beyond that is like finding a unicorn. Such people do exist, but they are rarely found in an average company. C# or Java UIs are a different story, of course, but I’m not sure they should be called “frontend”.

jillesvangurp• 1 year ago

The team notion doesn't scale. Open source software doesn't require teams or managers. They just have developers. Lots of them typically. Since they are not part of a team, they need to figure out how to work together. And they have to do that without the typical things you would have in a corporate setting (like a boss that can dictate and re-assign people).

That sounds nice and utopian. But of course a lot of OSS software is actually being developed by companies. Most open source that matters has corporate backing. So, the two models are not mutually exclusive. Many large corporations have to figure out ways to scale development. And often they have to work with other companies or even rivals on some stuff. When you have hundreds of thousands of employees, hundreds/thousands of different software packages and components with hundreds/thousands of people involved each, things get very complicated.

A lot of successful organizations emulate a lot of what happens in large OSS projects. Not surprising, because many large OSS projects take contributions from those same organizations. So you have a large intersection of OSS developers that also are part of a large company.

Regardless, any sufficiently large software will just have lots of people working on it. Many more than fit in a traditional team. So, you need coordination mechanisms. The persons that release and integrate software have a lot of power. They get to gate keep what goes into the software. In the OSS world, git repositories are read only for most developers. You don't push changes into them, you ask for your changes to be pulled into them. Politely. And then you work with whomever is deciding about whether to do that to ensure the change happens. It's a good model. If you don't like it you are welcome to fork and create your own release.

It's how Linus Torvalds can impose deadlines on releasing a new kernel while working with thousands of people. It's brutally simple: provide your patches before the merge window closes. It's your problem if you don't make that deadline.

That's not the only way but a lot of large projects use the calendar to coordinate and release regularly as clockwork. And many companies seem to do the same. People simply self organize around that. You can't have stability if a lot of people are running around with their hair on fire around every deadline. So, a lot of the self organization relates to vetting and rejecting bad changes before they become a problem. You push the problems back to the source of creation and wait for things to be sorted out there. And then you simply bundle things up and ship them.

The rest is just Darwinism. Bad developers/teams won't get their changes in and will eventually lose their funding (and motivation). And better ones will get more of their changes in. It requires collaborating with other stakeholders, it requires effective communication, and it requires some skill.

neom2• 1 year ago

I've always used this as my basis for thinking about team sizes: https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus... - personally I say teams are ideally 4 -/+ 2 only.

In Leading Teams[1] J. Richard Hackman says 6 max based on this research: https://www.jstor.org/stable/2786271

[1]https://books.google.com/books/about/Leading_Teams.html?id=w...

hanifbbz5• 1 year ago

I don’t know. With the advent of AI-productivity tools (regardless of where we stand in how much the actual boost is), EMS should be able to offload part of their admin work and devs should be able to deliver more and faster. Long way to say that I'm skeptic if those numbers still apply in modern or near future environment.

neom2• 1 year ago

That's a really interesting perspective that I hadn't considered!! Per the first link, a lot of these ideas are based on how well a human can manage in their head what another human knows/doesn't know/is doing/isn't doing/etc. We can only manage so much of that. I still don't think a human can manage more than 6/7 complexities, and so I don't know if I think 1 human would be able to work with say 30 AI agents as 1 team, for example. Could 1 human work with 1 agent who controls 1000s of AIs, I think so, is this the part you think changes?

spenrose• 1 year ago

Some headlines, such as this one, are catnip to up-voters* despite the article's contributing nothing to the established discussion c. 2015, let alone 2025. I don't know how you disrupt this dynamic and redirect to "go read X", where X is _Team Topologies_ or whatever, but it would improve HN.

* (not a criticism; the topic is important to hackers)

theptip2• 1 year ago

I think “going full generalist” is perhaps not a generalizable solution, though directionally it’s good advice if you have more than two dev roles (or maybe two plus Q) in a 10-person team.

No mention of task composition, but I wonder if framing stories in terms of user needs was another missing piece. It sounds like you were giving updates on low-level eng tasks not user stories.

When I ran a team of this size, sure the implementation details of a technical task wouldn’t make sense, but generally we had a frontend and backend engineer buddy up to own a user story, and reporting to the team was mostly at the level of “we are shipping feature X for customers Y,Z - API work turned out to be gnarly, let’s break out and have a backend guild design session asap”.

If you have QA then the “three amigos” approach is nice, product owner, dev owner, and tester all sit down and craft a story that is mutually comprehensible. If you achieve this then you can feel confident that others on your team will also understand the framing of the story. Takes discipline though!

gwbas1c6• 1 year ago

This morning I was recently reflecting on a similar experience. I worked on a project where client and server were different teams. A problem we had was that a lot of server tickets were accidentally labeled as client tickets.

Should we have busted down that silo and said that there are no longer separate client and server teams? Ultimately, what I realized was that we started shipping multiple different clients that used the same server, and that it was impractical for everyone to be on the same team and have a hand in everything.

I do wish that we siloed a lot later and remained generalists longer; or at least that part of the team was generalist and floated between the two teams.

iwontberude• 1 year ago

The consent message about AI was completely undermined by including AI art. Hypocritical posturing rather than any coherent values.

When a team is too big

Related Stories