4 ms·
One person can do the work of 3 and regularly does in startups. I think that what the MBAs miss is this phenomena of overconstraint. Once you have separate th
by nostrademons 2y ago
One person can do the work of 3 and regularly does in startups.
I think that what the MBAs miss is this phenomena of overconstraint. Once you have separate the generic role of "developer" into "developer, operations, and security", you've likely specified all sorts of details about how those roles need to be done. When you combine them back into DevSecOps, all the details remain, and you have one person doing 3x the work instead of one person doing the work 3x more efficiently. To effectively go backwards, you have to relax constraints, and let that one person exercise their judgment about how to do the job.
A corollary is that org size can never decrease, only increase. As more employees are hired, jobs become increasingly specialized. Getting rid of them means that that job function is simply not performed, because at that level of specialization, the other employees cannot simply adjust their job descriptions to take on the new responsibilities. You have to throw away the old org and start again with a new, small org, which is why the whole private equity / venture capital / startup ecosystem exists. This is also Gall's Law exists:
https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
- IgorPartola 2y agoI think there is another bit to this which is cargo cult tendencies. Basically DevOps is a great idea under certain circumstances and works well for specific people in that role. Realistically if you take a top talent engineer they can likely step into any of the three roles or even some others and be successful. Having the synergy of one person being responsible for the boundary between two roles then makes your ROI on that person and that role skyrocket. And then you evangelize this approach and every other company wants to follow suit but they don’t really have top talent in management or engineering or both (every company claims to hire top talent which obviously cannot be true). So they make a poor copy of what the best organizations were doing and obviously it doesn’t go well. And the thing is that they’ve done it before. With Agile and with waterfall before that, etc. There is no methodology (organizational, programming, testing, etc.) that can make excellence out of mediocrity.
- SoftTalker 2y ago> There is no methodology...that can make excellence out of mediocrity. And yet we keep trying. We continually invent languages, architectures, and development methodologies with the thought that they will help average developers build better systems.
- 1dom 2y ago> There is no methodology (organizational, programming, testing, etc.) that can make excellence out of mediocrity. This is a thought provoking phrase, and I liked that. Thinking a bit deeper, I'm not sure if it's accurate, practical or healthy though. I've seen mediocrity produce excellent solutions, and excellence churn out rubbish, and I suspect most people with a few years and tech jobs under their belt have. You could argue that if they turned out excellent things, then by definition, they're excellent, but that then makes the phrase uselessly tautological. If it's true, then what's the advice to mediocre people and environments - just give up? Don't waste your time on excellent organisation, programming, testing, because it's a waste and you'll fail? I think there's no 1 thing that can make excellence out of mediocrity for everyone. But I like to think that for every combination of work, people and environment, there's an optimal set of practices that will lead to them producing something better than average. Obviously a lot don't find that set of practices due to the massive search space.
- IgorPartola 2y agoI suppose I should have phrased that slightly kinder, and that’s on me. What I mean is that you can’t take your average jogger and expect them to win the 100 meter dash at the Olympics, no matter how much training and resources you provide them. Is that a real problem? No it certainly is not. Lots of people like rock climbing but you can’t expect an average climber to win a major competition or climb some of the toughest mountains. It doesn’t mean they shouldn’t enjoy climbing, but if they start training like they are about to free solo El Capitan they are very likely to get seriously hurt. Average developed, operators, sec. people can do plenty of good work. But put them in a position that will require them to be doing things way out of their area of expertise and no matter how you structure that role and what tools you give them you are setting them up for failure. Another thing I was thinking about was not individual people being average but rather organizations: an average mediocre organization cannot reliable expect excellence even out of its excellent employees. The environment just isn’t set up for success. I am sure most people here are familiar with having talented people working in an organization that decided to poorly adopt Agile because it’s the thing that will fix everything.
- romanows 2y agoThis is a great observation, thanks.
- namaria 2y agoHow does you explain the cyclical lay offs, if organizations aren't able to decrease in size?
- makeitdouble 2y ago> One person can do the work of 3 and regularly does in startups. Startup architecture and a 500+ engineer org's architecture are fundamentally different. The job titles are the same, but wont reflect the actual work. Of course that's always been the case, and applies to the other jobs as well. What a "head of marketing" does at a 5 person startup has nothing to do with what the same titled person does at Amazon or Coca Cola. I've also seen many orgs basically retitling their infra teams members as "devops" and call it a day. Communication between devs from different part of the stack has become easier, and there will be more "bridge" roles in each teams with an experienced dev also making sure it all works well, but I don't see any company that cared about their stack and performance fire half of their engineers because of a new fancy trend in the operation community.
- Aeolun 2y ago> Startup architecture and a 500+ engineer org's architecture are fundamentally different Certainly. The startup architecture is often better. I don’t know what exactly leads to those overcomplicated enterprise things, but I suspect its a lack of limitations.
- badpun 2y agoLarge org architecture is, most importantly, just much larger. The bank I worked in had 6000 _systems_. A lot of that was redundancy due to a lot of mergers and acquisitions that didn't get cleaned up (because it was really hard to do). Compare that to your typical SaaS startup, which typically has at most a couple systems.
- ghaff 2y agoRight. You can't run a 100 or even 1,000 person organization the same way you run a 25,000 person organization and many of the people roles are different. The 25,000 person organization can do more but it needs a lot more process to function. For example, the person just doing what they see as needing to be done in the small organization becomes a random loose cannon in the large one. Someone mentioned DevSecOps upthread. The breaking down of organizational barriers really was more of a smaller company sort of thing. Platform Engineering and SREs are a better model of how this has evolved at scale.
- nox101 2y agoI think it less to do with judgement and more to do with one person can do the work of 3 in startups because there's several orders of magnitude less coordination and communication that needs to happen. If you have 5 people in a startup you have 10 connections between them, 20 people = 190 connections, 100 = 4950 connections, 1000 people = 499500 connections. Sure you split then in groups with managers and managers managers etc to break down the connections to less than the max but it's still going to be orders of magnitude more communication and coordination needed than in a startup.
- renegade-otter 2y agoIn a startup you get significantly more focus time than in a large company. Especially if there is no production yet - there are no clients, no production bugs, no-call. In a larger company, literally 80% of your job is meetings, Slack, and distractions.