When a team is too big
blog.alexewerlof.com
blog.alexewerlof.com
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.
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.
Anecdotes are fragile; I've had the exact opposite experience, Dutch people taking offense for being direct when reviewing code.
The offense could have been the Dutch person being direct about their stubbornness to feedback.
Also possibly a point in favour of political speech vs directness. Much easier to politic a stubborn person than tell them to do something directly.
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.
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.
It's awkward to do this in person (although after so long I'm in the habit enough that I will un-selfconsciously just stand up in a room full of people slouched at desks to attend the same meeting in person) so I can understand why people don't form the habit but I am quite sure it has been valuable.
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.
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.
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).
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.
The key is to check your watch after you complete any activity. For example, you read that a 1000ft climb hike takes 2 hours and you do it in 2.5 hours.
Do this over months and you gain the ability to make perfect estimates. Turns out that feedback loops are useful.
Also applies to all other skills.
Funny thing is I’m mostly a buy tickets to fly next week and wing it kind of person but I wanted to try it one time for kicks. Winging it is a whole different set of skills. Get good at both and planning becomes your jam.
I need to keep my fingers on the pulse of what happened yesterday and what’s happening today, and what potential impediments might arise to make key decisions without asking everyone.
We’d stand around the managers office, take thirty seconds to say what we planned to do, what dependencies we had (eg, who needed the truck when) and then went off to do our tasks. Even though we also tracked project work in a time system.
A real standup isn’t that unusual, nor micromanagement. Though it can turn into that, when badly utilized.
So in practice, that's a truck-sync meeting that needs to happen every day due to shifting needs and thus actually useful. Seems like there is room for improvement there but might not be worth it for them?
I also don't think certain management cultures would ever want to skip reaffirming the workplace hierarchy on the regular, but that's certainly not a culture I'd want to work in - but at least that's usually honest that it's just status updates to the boss and not hidden behind some nice sounding methodology bs.
IME, a standup is just repeating JIRA tasks 99/100 that's not useful for anyone beyond perhaps the extroverts that just wants the face-time, people who rarely reads chats, and ofc management for said office politics.
Usually you've already had a weekly/bi-weekly planning meeting distributing tasks in a rather granular size that are available for everyone to see progress on. Then you have easy-to-access direct communication channels through Slack or similar for ad-hoc questions to anyone at any time. Have a question? Just ask? If that's not enough I'm a lot more inclined to believe that the team is dysfunctional.
I genuinely think it's a shame that the autonomy & trust that other fields can offer people with proven qualifications/past work is not being offered, instead you're stuck in various infantilizing rituals when you're building a house that you've already built multiple times and don't need hand-holding to do so.
But there's some serious amounts of gaslighting going on in the field to explain that a tracker on your car is trust & autonomy.
Someone running a standup meeting where people just repeat information is by definition not doing an efficient job at all.
It doesn't. :)
Stand ups are not for status reports, they're for syncing. "I have a big PR coming so please check it today". "I am still stuck with the sprongler bifurcator but I expect to be over tomorrow". "I need to involve someone from team X, their stuff is blocking me". "Ok, Y, let's chat after this meeting".
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.
My bias is always to only participate in frequent recurring meetings as a last resort, but sometimes they seem to be necessary.
But I worked for a Japanese company, and they take meetings very seriously.
One of my employees suggested daily standups. I tried to support my employees, when they suggested new stuff, so I said “let’s give it a try.”
The Japanese Liaison really liked the idea, but it needed just a little tweak…
In a short time, we were having hour-long meetings every Friday at lunchtime.
ToMAYto, ToMAHto...
That is almost as offensive as a slur to management in 95% of companies
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.
These meetings aren't really standups anymore though.
It can't "always" have been the reason. The original intent of agile was that it was by the developers, for the developers. It's unlikely the originators of agile decided they needed to treat themselves like "school children"
Scrum has always been the one with more "ceremonies" and more middle management involvement at each step, adding Product Owners and Scrum Masters as entirely new classes of middle management. Given how often teams devolve into "Scrumterfall", that sometimes seems like the "natural state" of Scrum. Scrum was designed to make Waterfall companies happier with Agile. Scrum has all these ceremonies and extra middle managers that are just Waterfall things done more often and closer to the engineering team.
It's so very easy with hindsight to believe that Scrum was the "wolf in sheep's clothing" among the Agile Manifesto writers that didn't always believe in the goals of the Agile Manifesto. Especially "Individuals and interactions over processes and tools": just because they are called "ceremonies" doesn't make them magically stop being meetings and processes and tools. It's kind of worse than that because ceremonies implies rituals implies religious tones of control.
I certainly feel like Standups are a bad idea designed to make Managers happy. The kind of middle managers, especially, that feel some command-and-control need to treat developers like "school children" because they don't understand what the developers actually do and don't really care. But maybe I've just had too many terrible "Scrum Masters" in my life (what a terrible term, what an awful job role, what a waste of middle management bureaucracy) and there's some "ideal" Scrum I've never seen where that isn't the case.
(We probably would be far better off if more developers had listened more to the Extreme Programming side of the Agile Manifesto house, despite being confused/turned off by things like Pair Programming that made it "extreme". Though it was also things like Pair Programming that made Standups seem especially silly to XP, since you never not had someone to bounce blockers immediately off of in Pair Programming.)
And go try to fit "required daily meetings" on the Agile Manifesto to see how well it fits. (The people that made this one were mostly developers. All working in a very specific area making very similar software, but developers nonetheless.)
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.
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.
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.
"I ran into X, tried Y and Z, then asked Bob, Bob wasn't sure, anybody else have ideas?"
Or
"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.
we need to reduce the number of slack messages. not increase the number of meetings.
i want to build something like that at some point.
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.
Going in to huge detail about it, not much, really.
A quick "hey, hit an issue yesterday with ABC, Kris helped me out - thanks Kris!" does a few things.
It reminds everyone we all might need to ask for help now and then.
Gives a bit of public recognition to Kris who might not otherwise get it.
Also lets people know Kris (and now you) know a bit more about issue ABC in case they might have a similar issue.
When I hit weird snags, they're not always things I'd detail out in a ticket, especially if unrelated to the specifics of the ticket. "Add links to help documents" as a ticket doesn't benefit much from me documenting out that I hit some weird issue because the security team didn't add accounts to a new policy group, meaning my emails to the accounting team were bouncing. "Kris confirmed it was an issue for her as well, and reached out to Kevin's group to let him know, and we got things resolved yesterday". Yeah, you could add that to a ticket, but feels useful to mention that in a status meeting. Larger discussion about the process behind those changes or scheduling impact should be taken offline outside the meeting.
"...should be set to Blocked..." do you do that the moment you aren't making forward progress on something? It's something I wouldn't typically do until after some amount of time understanding why I wasn't making progress, and trying to 'unblock' things first within a short period. Days of unblocking attempts without raising a flag are generally not good, but 3 minutes of 'being stuck' before pinging others is also not great imo.
Pattern detection. As a coder, your job is to get past blocks and deliver features at quality and on time. As a manager, your boss's job is to take information in from their directs, synthesize a picture of what's actually going on, and work to make your life easier (and thus, you more productive) in the future. "I was blocked for four hours yesterday because <x>" isn't a big deal, for you; but seeing the commonalities in <x> across the whole team, and over a longer period of time, motivates action to understand the /underlying/ problem and improve it in the future.
It tells management why a task is behind schedule, more or less.
A seasoned team full of staff engineers might not need standup at all.
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.
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.
This just sounds like a more deeply rooted work culture problem to me.
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.
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.)
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”.
I don't consider myself unicorn, and I do full stack, including UI work in C#.
Go update your assumptions.
> Is UI work on C# so different, that it requires introduction of frontend dev role?
First, where Xaml is the most up-to-date native Windows UI API, and primarily C#, it's not "different," it's normal.
But, to answer your question: That depends on the kind of application you're making, organizational priorities, and the need for slickness.
For example, if you're making a quick and dirty CRUD web app, it doesn't make sense to have a separate UI role. Razor or Blazor (the two ways to do HTML in C#.) will be plenty. This will basically be like what was done in the 1990s. It's extremely easy for a competent C# programmer to learn Blazor (and HTML) and make a functional web application. (As long as you don't care about if it's pretty.)
If you're making a pretty web app, the need for a separate role again relies on organizational priorities. In my case, my job is C# in the browser (through Blazor compiled to WASM) all the way to the database. (The definition of "full stack.") I established the patterns we use in in-browser C#, and the components, but I hand off day-to-day UI work to a developer with less experience than me.
Getting back to organizational priorities: We could have a dedicated "UI" role if we wanted significantly more polish in our UI. For our company, the fact that our current team can generally handle any area of the stack is far more valuable than someone who can make a pixel perfect UI but get confused in the database.
Likewise, we aren't going to agonize over our UI like some organizations do. If an organization is going to do that, they probably need a dedicated UI developer role.
> If not, you are not “full stack” developer just because you do UI on C#.
Wow that is an insulting statement.
So you do target browser and then you are a full stack developer. Do you feel yourself an expert in modern browser technologies, keep yourself updated on latest developments in JS, CSS etc and at the same time can do a hardcore backend work? If yes, congratulations, you are rare as unicorn. No jokes, it’s not easy to find such engineer.
I'm also not a unicorn, nor is anyone else on my team. We're generalists with various amounts of career experience, and we all learn from each other. Our UI is neat and functional.
You do not need to be a unicorn to make a reasonably good looking web application as a full-stack developer. If our company lasts long enough where we need to make the UI super pretty, and need to optimize our backend to handle massive scalability, then we will seek more specialized developers and specialize ourselves.
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.
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.
Of course, it is not. I doubt that there exist many management practices that were measurably proven to be effective. It's just an explanation why I perceive those as best practices. They have worked for me and my peers in a reproducible way.
>my suggestion that there's other successful ways to run a team >Learn to deal with dissenting opinion
Please elaborate on your dissenting opinion and try to avoid personal attacks. What are those ways?
Killing shitty meetings, including the standup, was one of those dissenting opinions, obviously.
Here's another.
PMs, or any other role that abstracts the developers from value, serve to infantilise the developer. Instead of owning the most expedient way service a customer or generate revenue, they're instead owning the minutia of frameworks, architecture, or tooling.
Of course, you can still make an argument for the PM via efficiencies and skill specialization, but when you effectively give a non-technical person control of what the team works on, you in many circumstances no longer have a person with a view across both commercial and technical realities.
And whilst there are many ways to try and plug this gap, like Engineering Managers or arguments like you're holding it wrong, where exactly are these tech leaders learning those skills when in the vast majority of teams the PM keeps them in the dark? Thus, propagates the cycle where the technical are not commercially mature enough to make business decisions, which necessitates the need for adults in the room.
Point being, it's a trade-off and there's circumstances where the trade-off makes sense, and others where it doesn't.
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.
I love this. I wonder if it is effective, or if there's any legal recourse should the LLMs ignore it.
> 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.
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.
Gives a small hint. It should be respected and effective.
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.
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.
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..
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.
maybe only serve milk or protein-shakes to further increase this effect.
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.
Takes only a few seconds more. Of course, the Dev should know beforehand what he is going to say ;)
Things like planning, ETA:s and the like that management roles are nervous about should be handled in another setting, because these are open-ended activities that might take one minute or thirty and making those decisions requires preparation that should absolutely not, ever, be done during the meeting. This takes discipline on the part of the manager, who has to figure out a clear purpose, who is a relevant participant, ask them individually when they have time, reserve the room or equivalent, write the invitation with agenda, send it out.
Commonly it's more done like 'we have a problem', 'ok, we'll meet after this', and then people waste half an hour doing a defective version of that process as an unnecessary group exercise.
The 2-pizza thing coined by Bezos means 6-8 people.
I'm guessing most of those fifteen minute meetings had a set topic, or agenda as I called it previously, and ended as soon as it became clear that it wouldn't be immediately productive or the relevant decisions were made. I've been in many, many fifteen minute meetings where someone spent the entire time in palpation for something that could drag it out for even longer.
It's not uncommon that people are brought into meetings to basically engage in parasocial comforting of someone in a position of leadership they don't have the maturity or competence to perform in, in organisations that did very little to support their assigned leaders. I find this practice quite offensive and that moving away from such ceremonies to people calling a meeting making clear in advance what they want answers to and giving the participants time to prepare paves the way for trust, accountability and flexibility in the work that allows the team to respond better to challenges.
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.
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.
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).
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.
"a solution is, everybody should be able to do everything, that way we don't have to do any actual skill based resource management because everyone is interchangeable"
with some vague allusion to "if they can't do everything then they probably aren't good at their job"
My reply was that i don't think that everyone being able to do everything is a good solution to what i think should be a skill resource management problem.
There are people who have the time, ability and resources to pick up (and more crucially , stay up to date with) all the disciplines, i don't think that should be a *requirement* and i don't think making it one is a good way of doing things in most circumstances.
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?
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.)
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.
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!
* (not a criticism; the topic is important to hackers)
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.
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.
What should we do about it?
An internal billing team requires entirely different people and ways of operating than a startup's growth team iterating to product market fi.
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.
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...
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.
One may disagree, but that likely means they are pontificating instead of coding. =3
also so much for ublock to block on that personal blog!
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.