Capital One axes 1k tech roles
theregister.com
theregister.com
The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month. I put leading in quotes because there’s only so much leading one can do if everyone else knows more about the product due to the inherent transitory nature of the scrum master role. Are you really adding value by reminding people that story points (some vague relationship to days of work) can only be Fibonacci numbers?
Inside the company, the CEO loved to tout the “technical journey” they made which included things like moving to the cloud. Agile was on that list but it never really felt like it belonged. Depending on one’s tolerance of the kool-aid, some skepticism was always there.
Watching people insist that story points are totally not representative of predicted time spent working on a thing is the funniest shit. The mental gymnastics are incredible.
In a healthy environment, I think "story points" (horrendous name) should approximate "engineering complexity given the current state, skill set, and knowledge of the development team." Time estimates should then be derived from that number based on historical performance of the team in its current state (if you fuck with the team structure, all bets are off and historical data becomes less useful).
Ideally a team should use points to do thoughtful analysis of their backlog and think of ways to manipulate scope, invest in cleaning up technical debt, and learn new skills to cheapen the engineering complexity and in turn deliver faster. In practice, what you described is almost always what happens. Stakeholders keep pressing for time estimates, so shit just keeps getting added to the backlog and engineers estimate "how long?" because they are neither encouraged nor empowered to think of it any other way.
Story points are simply a way to say "I think that looks roughly like twice the work of that one we estimated before".
Usefulness depends on specific environment and who and for what interprets the output (usually, at some organization level, there's excel/Gantt, that will convert them into an exact date. That will fail spectacularly in 99% of the cases).
Well, who's planning to do it?
In mine - not so much. Two dev team? Sure, you probably know. 6 dev team? Not so much. Estimation, then back to customer to decide if they'll eat the cost and decision 2 weeks later? Good luck knowing what will happen then.
Point is answering question "does it fit into the sprint", knowing that usually you can fit 3 big tasks and 3-5 small. Then real time estimate is end of sprint.
And by "twice the work" they mean takes twice as long. It's still time.
Anyway you could just say "2 days of work" with the understanding that duh, a senior can do it quicker than a junior. It's just an estimate anyway.
It's weird how people whose half of work is coming up with clever abstractions, have so much problem with that one.
Maybe estimation is complex thing and therefore team needs to align opinions before doing it?
That's why points aren't really necessary. Using days is still an estimate.
That said, I don't really object to points, I object to the idea that they don't represent time, when they obviously do.
Who is doing the work? The senior? One day. The junior? Three days. The estimate should always be done by the person doing the work. This also forces people to have skin in the game when making estimates. When you have a full team coming up with points, then no one has any consequences for being wrong. But if you say one day, then you have some incentive to think things through. You want to live up to your commitment. Of course, this assumes that there are some consequences for being wrong, which usually isn't the case. I think this is where many people go wrong with time estimates. If you're repeatedly wrong, that's not because time estimates don't work. That's because you're bad at them. And like most skills, if you do them repeatedly and try to learn from the cases where you failed, you'll get better at it.
The engineering manager should know the product area and code well enough to gauge the LOE for tasks and plan, without the unnecessary step of estimation meetings (which likely aren’t going to produce accurate numbers anyway).
Could also be a tech lead that does this, but prefer that they’re one in the same.
Of course there are many aspects of “pure scrum” I don’t agree with, such as a single sprint goal shared among the team
Use story points. Succeed with story points. But don’t try to convince yourself (or me) they aren’t just an analogue for time.
If you told someone on Monday that a ticket takes two days they’ll ask you on Thursday why it’s not done.
Instead story points combined with team velocity give your team a sense of how much work you can commit to.
Of course we all have in our mind that a 5 point story takes a like 3 days.
If some director or product leader comes in and looks at these tickets the won’t see any time estimates on them and thus can’t hold you accountable to them. Sue they can look at your team velocity. But that’s generally a higher level moving average of several sprints.
Of course this is all imprecise and often isn’t implemented well. I’ve seen it work very well for some teams, where it gave us a good sense of our accomplishments and led to more ownership. It often doesn’t work and just adds overhead.
I’ve ditched it for my current team.
In any case, I was talking about the many devs who insist it's not time even though it is. Having it be a sort of abstracted or obfuscated time increment is fine imo.
I just assume if the company is doing agile they have lost faith in their developers when it comes to organizing or producing value.
Scrum isn't perfect, but its an "industry-standard" practice that we can use to get quick buy-in from client stakeholders, and then use to apply even the most basic level of process to these teams.
As an engineer at Google or a freelance developer it never made much sense to me.
But as a manager of remote, distributed, international teams?
It makes a lot of sense.
Sounds familiar.
Back in my consultant days, we would encounter companies that wanted to be “agile”. They’d insist they were waterfall and it wasn’t working.
Truth is, if they’d actually been doing waterfall they’d have been performing far better. Instead, they were just chaos, reacting to one fire after another with no plan to get out.
Additionally, many teams were simply staffed with poor managers and poor engineers. There’s no consulting-fu or process-fu that was going to overcome that. You can’t win horse races with pack mules, my dad (a basketball coach) used to say.
> You can’t win horse races with pack mules, my dad (a basketball coach) used to say.
You can boil it down to saying that Scrum is either (a) micromanagement or (b) an admission that your developers and their managers suck.
Fix the problem, instead of slapping a bureaucratic band-aid on that's going to attrit any remaining quality developers.
I don’t think this is right. It’s like a sports team: your system, your philosophy, your approach matters. Like in basketball, you might utilize the flex motion offense or you might use the Tex Winters’ triangle.
Good teams can succeed with both, but depending on your personnel and what you’re up against, you might find one strategy works better than the others.
And I've seen it used exactly that way in practice at bad companies.
It's not a strawman if it's lived experience and professed corporate IT strategy at a lot of non-tech companies.
It has nothing to do with "agile" though. In fact, the agile manifesto clearly says "individuals and interactions over processes and tools". An organization that follows processes that don't make sense to its employees is not agile, despite what they claim.
But they are more than capable of putting in rules and processes that allow them to do agile. The problem is that doing agile without being agile does far more harm than good.
There's a long list but only one really needs to be mentioned:
Payroll costs $XX,XXX,XXX and is due every 2 weeks.
I've sat through "agile training" and it's the most plain grift I've ever seen.
Selling developers on a deadline-less utopia, but walking it back just enough to not make management types paying for the whole thing balk. Switching which side of the scale their finger is on based on who seems the most engaged at a given moment.
But at the end of the day, it's always predicated on the idea that developers can always provide backpressure against clients.
Well you're free to do that, and clients are free to not pay, and unless your developers will work for client IOUs that's the end of the game.
Agile mentality is great. The idea of rapidly iterating and rapidly producing feedback is great. But "Agile methodology" has evolved into a productivity ponzi scheme meant to add a place for consultants and trainers to insert themselves for $$$
I dont really blame them. They've gotta eat, and occasionally they probably do get a client who is genuinely willing to enact a real transformation. Dysfunctional upper management is the real problem.
Dysfunctional upper management: maybe.
Customers don't pay money today for products delivered on an indefinite, unspecified future timeline: definitely.
More software engineers should have to be involved with customer conversations to internalize this...or just, I dunno...do a construction project or something. See how much you like it when you've paid money for something bespoke, and the people doing the work refuse to set schedules or tell you what you're getting. Suddenly you'll be a dysfunctional manager, too.
Agile works best when you have a consultancy situation, and the customer can be directly involved in the construction of the product while it is being built. This rarely applies. But even then, customers tend to make ridiculous demands like "advance notice before you change the software from under us so that we can re-train our large team of users", and as soon as you do that, you've got a calendar, a deliverable and a deadline. Probably some Gantt charts in there too, because only trivial projects have a single deliverable.
Then you say "OK, let's actually be agile, break down the project timeline using iterative deliverables and clear development cycles"...now you have sprints.
I'm not defending "Scrum" -- just saying that deliverables and deadlines are part of life.
They frequently do for features though. I happily waited a year for my bank to implement virtual credit cards. As a corporate user of software I have waited similar lengths of time for features I really wanted.
This reality usually doesnt stop some layer(s) of management from waterfalling the shit out of everything simply because they can't conceive of an alternative.
>See how much you like it when you've paid money for something bespoke, and the people doing the work refuse to set schedules or tell you what you're getting.
Yeah, this is why I try to avoid that type of software development at all costs. I got burned on it when I was young, thinking that nothing was more natural than treating software like a construction project.
Practically speaking, when you do ask for something bespoke - whether it's a skyscraper, crossrail or a bathroom remodeling or software, you've gotta be prepared for delays and budget overruns. Software is much the same, and waterfalling the shit out of this type of thing may be unavoidable, but so is the inevitable shitty result. There are entire sub industries that can't seem to produce anything good (e.g. healthcare software) and I think this model of operation is largely why.
This is why it's better for execs to treat bespoke deliveries as something radioactive and try to minimize them as much as possible even if that means saying the scariest six words in an exec's vocab "sorry, we can't take your money".
Not the kind of feature I'm talking about -- your bank isn't contracting with you, personally, to make a credit card. Apple doesn't care at all about my opinions on when to release their next phone. Google doesn't ask me what they should name Chat this week.
Nonetheless, the stakeholders for such a project are going to be internal to the company, and there will be many: customer support, billing, compliance, marketing and legal, just to name a few. There will also be many deadlines, simply because huge numbers of people have to coordinate to turn out a complicated project.
> As a corporate user of software I have waited similar lengths of time for features I really wanted.
Again, unless you are signing the purchase order, you're not the customer, and you don't set the deadlines. Someone else is setting the deadlines for you. Also, just because you had to wait a long time doesn't mean that deadlines didn't exist for the project.
> This is why it's better for execs to treat bespoke deliveries as something radioactive
All software projects are bespoke. Some are smaller and more tightly scoped than others, but if you didn't need custom work done, you wouldn't pay an engineer to do it.
I know. I expressly declared the type of feature you were talking about radioactive.
The tragedy isnt that this type of feature exists it's that some managers cant conceive of there being any other kind and will turn every feature radioactive. Thats how we get shit software.
Yes, the Agile Industrial Complex is a total grift and nothing to do with the manifesto.
Him warning about this may or may not have an effect though.
Highly recommended.
I just started a new role leading a 30 person Engineering team at a company doing Scrum. My very first questions to everyone was why are we doing this? Answers ranged from some expectations like regular/predictable delivery of product to "because that's how software is done." From there, it's figure out a process that makes sense and actually achieves objectives. Scrum provides a nice framework, but everyone needs to be bought into the goals of it first. (My next actions were to get rid of most of the useless workflow rules in Jira and build that accountability at the team level...it works amazingly well that way)
I agree that it's much more doable at a small company. Once companies get big enough, the need to centrally plan and coordinate seem to create an irresistible urge to apply identical processes to all teams, compare velocities, and all sorts of other bad habits.
If you are working in an optimized team, that understands the business, understands the customer, and efficiently and incrementally delivers business value building the right kind of software then these practices won't help you and as you point out may actually hurt you.
The above though is some minuscule fraction of software teams in the real world (and some may not know it).
The problem with Agile practices and Scrum is that despite their theoretical ability to improve the way we build software, and the good intentions of the original ideas, inefficient teams and companies will always find a way to adopt the practices they think are good (and therefore keep them inefficient) while rejecting the practices that may help them. That's the conundrum of pretty much any process (and funny enough "people over process" in a twisted way means people that have no clue will subvert any process that tried to push for doing things better in most orgranizations).
Really? The impression I get it's that it's geared towards internal teams who can "iterate" until the cows come home. Contractors work on a fixed time-frame and/or cost, agile doesn't jive well with that unless you're just labour augmentation.
Not sure why we still talk about it.
I don't have any evidence, but I think it's an undeniable fact that coordination effort is very expensive. We are all familiar with how fast our 1 person weekend projects go; you spend 12 hours on Saturday evenings on something, and it feels like it progresses faster than what your team of 30 people is doing at work 5 days a week. My opinion is that projects scale exponentially with complexity. A 1 person project takes 1 person. A 2 person project takes 2 people. But then, a 3 person project takes 4 people. A 4 person project takes 8 people. A 5 person project takes 16 people. By the time you are at big company sizes, you might have 30,000 people vaguely working on the same thing; by my rule above, that's a project that's 15x more complex than a 1 person project. That's why it feels like "my friends and I could make Twitter over the weekend, why do they need 30,000 employees!?" You're thinking that results scale linearly over the number of people, but it really scales logarithmically over the number of people. So now you're 1/30,000th of a 15 person project, and you don't feel as productive. You are 0.003% of the equation. If you work 10x as hard, you're 0.03% of the equation. It just doesn't fit with your mental model of productivity that you extrapolate from personal projects (where it's 100%, or 110% if you had a really good cup of coffee). That's why it feels bad, but it's also why management is not super concerned that you are spending 20 hours a week in meetings. Oh no, now you're only 0.0015% of the equation.
The final question is, why does society put up with this? The answer is, there is money in these projects that are just a bit more complicated than a software engineer's personal project. You will be remembered more for the 0.003% contribution you had to the moon landing than you will for making the absolute best ever music file organizer. It sucks, but that's how the Universe works. You can embrace it, or you can fight it. But if you want to stave off the heat death of the Universe, you might need a team and a plan and maybe a few meetings to share the plan with your team ;)
The problem I've seen is that formal agile processes substantially reduce individual engineers' autonomy—slowing everything down seems more a symptom than the core problem. (Of course, it's ultimately the symptoms that kill the patient, right?)
Coordination is both important and difficult, but a process oriented around tracking and directing individuals at a bite-sized-ticket level is not a necessary, sufficient or even particularly effective solution. It's an abstraction to make work legible in the worst way: it's restrictive to the people doing the work, encourages unhealthy patterns of top-down management, poorly reflects the ground truth while still giving managers the illusion of detailed understanding and control.
As for top-down, organizations try that approach because it seems like the problems could all be solved if people weren't coordinating with each other, but just did what they were told. It seems like it doesn't work like that; this presentation explains it pretty well (and was on HN last weekend): https://komoroske.com/slime-mold/
There’s a lot of gripers who don’t like feeling managed and attack it with all sorts of false criticism though. And of course, poorly-run Agile can be pretty annoying.
The key is to keep things minimal and fast: quick stand-ups, and as few meetings as needed. Who is leading it definitely matters too. Ideally it is a lead developer rather than a “product” or “project” person, IMO.
They were in charge of getting the right people together for any meetings, asking for extra info to be added to any backlog items, and telling teams when we were planning to deprioritise or drop the backlog items they asked for. It worked pretty well for us, and took maybe a day of time per week
The problem is if you are having a struggling team, it takes a lot more of a day of time and requires a lot more maturity than just leaving jira comments and sending meeting invites. But if you put your devs who are good at structuring problems/time on it, now they're participating in the actual development less, so the team gets even less functional (at best temporarily, at worst you're now in a death spiral). Furthermore if the root problem is not really the organizing but more fundamental (poor skills / skill alignment, understaffing, chaos agent, etc) the singular dev will rarely have the ability to deal with it and can even start drawing animosity.
Having a separate person responsible for this, in a different hierarchy with different ears, can be a lot more effective in these situations. (It can also make it worse, if the separate person is also shit at their job, has too much work, has very different attitudes towards work than the rest of the team, ...)
tl;dr: If your team is functional pretty much anything will work, these structures also need to be judged by how well they can get it back on track from non-functional.
I prefer a lead or senior developer to have the role rather than a dedicated non- or even former- developer.
When a good lead dev with good communication skills and experience has the role it can be awesome.
Agile doesn’t take much effort if you know what you’re doing. It’s just a card wall, standups and a planning meeting. This is not hard for a good lead dev. If you think it’s hard, you probably aren’t a good lead dev, or you don’t know how to do it right, which is the same thing.
100%
I interviewed with a company (not C1) earlier this year that had one of those “every team has a manager, every team has a scrum master” bits going on. I asked multiple times what the difference between the roles were, and couldn’t make sense of any of the answers I got (which were full of consultant-speak). I declined to move forward.
Like anything, I’m sure there are teams out there with this situation that make it work. But it sounds to me like a recipe for confusion, conflict, and atrophy.
You're right in the sense that the role was always awkwardly jammed into teams often when it didn't make sense.
Some were pretty good but most were of the certificate-chasing type that had bought into the commercialization (bastardization) of Agile.
Give C1 their due though. They dragged the entire company into AWS, mostly, which is something I don't think any other bank that's been around as long as they have has done.
And why/how is that a good thing?
From a business perspective it takes you out of the business of managing your own infrastructure. Even at big tech now we have to decide between managing our own infrastructure and “outsourcing” it to a managed service. Most advice I’ve gotten encourages the latter. It can cost more but if cost isn’t prohibitive it frees you up to deliver features and value for customers because you no longer have to develop (as much) expertise in ops.
However, once you move the companies infra to AWS (or any one cloud provider) and shutdown your infra, in due course AWS will keep increasing your price by x% every year. At the point you don't have a choice but to pay those price increases yoy. You have much less bargaining power.
I think hybrid cloud is the best way to go. You have lot of bargaining power and no one provider can hold you hostage.
I think you’re leaving out a key restraint: AWS is quite profitable now but has strong competitors and there’s still a much larger amount of IT spending which isn’t going to any cloud provider. If they abuse one customer, a ton of money is going to race to the exit. It’s also hard to see how they could raise prices enough to cancel out all of that lost future business without attracting regulatory attention, too — rearchitecting isn’t trivial but you’re still talking on the order of a year to profit before you’re not only losing the profits you had but also all of the future growth.
The other thing to consider is the substantially greater cost of a hybrid cloud: not just the obvious costs of extra resources, ops, security, training, application support, etc. but also the opportunity costs of restricting your usage to the lowest-common denominator cloud features. That’s a heavy cost to pay every month as a hedge against a low-probability event — I highly doubt that you’d lose money betting that you’d save so much money by using a single cloud that you’d still come out ahead if you had to migrate later.
And that doesn’t even get into the technical side of it, which is a logistical nightmare as you mentioned with multicloud. (I don’t even want to think about it for my personal projects!) If C1 has around 50k years of AWS experience among all its tech employees, it will take a long time to match that in Azure or GCP.
When the market is closer to saturation that could change but I think that’s going to hold for at least a decade or two: there is considerably more money being spent on traditional data centers than in the cloud and I’m sure they’re trying to give as few disincentives as possible to those potential customers.
AFAIK, scrum masters are supposed to be that one that goes from person to person, looking if everything is ok, if they need help, or if they should be doing something else.
That certainly is not "leading". It is indeed some kind of "managing", mostly because this word is incredibly ambiguous. It is also the problem solved by dailys, so if your dailys are useful, it means your scrum master is useless. As far as I can see, there is no reason to have both. (And I'm still doubtful about any reason to have one of them.)
Project planning does not get easier if you limit yourself to a number system that is not closed under addition. A strange thing to have to tell people, but here we are.
However I have noticed that when that figurehead person is missing the meetings and goals quickly disassemble.
In my experience the best leader of Agile or Scrum is always a lead developer, instead of a dedicated “project” or “product” person.
Where I've seen them provide huge value is in an organzation transitioning to agile, where the product manager/owner is more on the side of waterfall/sales, making unreasonable demands. The scrum master is the one who pushes back against this and "protects" the devs, and basically ensures that sprints run smoothly. Especially if you have thousands of developers transitioning to agile, hiring scrum masters that can each associate with 5-10 teams can make a huge difference.
On the other hand, if you have competent PM's (or even just eng team leads) who themselves serve as the buffer between the dev team and the rest of the org (sales, VP's, etc.) and who already know how to do agile, then yes, scrum master is entirely redundant.
But to be clear, leading agile isn't about reminding about Fibonacci numbers. In an inexperienced team, if one dev picks a different number, there's often peer pressure to just "change their number" instead of discussing the sources of disagreement, which is the actual purpose of planning poker. And there are a ton of situations like these where both devs and a PM might want to "play pretend" at agile rather than actually rigorously questioning requirements, negotiating better requirements with owners, and relentlessly surfacing blockers. So leading agile requires both real knowledge of the process as well as the courage to stand up against owners, groupthink and peer pressure.
> The scrum master is the one who pushes back against this and "protects" the devs, and basically ensures that sprints run smoothly.
That may be the ideal (of any leadership really) but our Scrum Masters reported to the PMO, which defined their agenda and financial rewards.
In fact, our weekly retros were not what we could do better, but what the PMO wanted us to do differently (like report time estimated / worked on stories in Jira down to the minute).
As a Product Manager, fucking yikes. I'm sorry for that horseshit.
But, are they supposed to do something else? Been in many companies, and scrum masters are the most useless role out there. Somehow, they seem to be hired for who knows what reasons. Slowly, they are becoming less popular though. Now the trend seems to be Engineer Directors (middle management between Engineering Managers and C-level executives). Total waste once again.
Basically, I kept the backlog in sync with reality, and vice versa. I was the facilitator I wish scrum masters would be.
However I also met my fair share of post it fetishists who don't seem to get much done. They seem like the priests of a modern religion, bringing their tabernacle filled with coloured markers and helping us pray to the productivity gods.
Do we dare dream?
Still no idea what that was about, and it was never brought up again.
The kindest interpretation one could offer is that it was a starry-eyed conception of how programming teams could constantly kick the blame-ball back to the stakeholders, as if the routine assignment of fault were somehow reasonable and rational in organizations, which it is not. At its worst, it looked like a solid grift, something that would last for several years as long as you kept smiling and promising.
{thing} is something we can pay money for, without making real changes or learning new information, to tell investors and competitors we're part of {new fad}
Big-A Agile (as marketed, certified, and hired for) is that for little-a agile (the manifesto and cultural practice). It also describes most consultant trends.
The root of it is the realization that nobody in positions of power wants to change or admit they don't know something. Highly structured Agile implementations promise to deliver agile without requiring either of those things of anyone in power, which is why they're CTO-down driven: hire for new roles, nod when report are presented, and pat each other on the back at how progressive your company is.
It's management attempting to feign involvement at a lower level, without really putting in the effort to do so productively.
DevOps - and the litany of industry darlings who have as many (conflicting) definitions as there are shades of the rainbow.
Cloud - or, the people whos only role is to understand at a high level what cloud offerings exist.
DE&I - more insidious as it is a noble and worthwhile endeavour, but constantly gets taken over by people who bully others and/or grows huge
And it's possible some dedicated scrum masters could simply drop into the somewhat similar role of technical program manager.
It sounds nuts to have an Agile job-family; I don't even know what that means. But hiring an Agile consultant for a few months can be transformative.
[Edit] I think it's worth noting that neither of these two guys functioned as a "scrummaster" - they sometimes ran the scrum, sometimes it was other people. Even I did it once. They both coded, and paired with roughly eveyone. They were both rather heavy, for my taste, but I learned a huge amount from them.
I thought I had heard it all with Happiness Managers but this takes the cake.
> Former Amazon engineer Paige A Thompson, who also went by the handle "erratic," was collared by the FBI the same week of the attack, and was convicted in June last year of pilfering millions of folks' data from the "misconfigured" storage buckets. In October, Thompson was sentenced to time served and five years of probation with location and computer monitoring.
So wait, he stole millions of dollars worth of data, got rich off of it and was sentenced to time served?
She copied the data but there was no evidence she profited from it. Capital One paid $250+ million in fines and legal settlements as penalty for not securing the data properly.
I worked as a contractor for CapOne for 9 months, in Richmond VA, in 1996/7.
I was a tech, but I worked mostly on applications to help the fraud team. In those days, I think CapOne was ahead of the curve in automating banking. The fraud team were working to a checklist, with lots of computer assistance. They were always frazzled, because they were customer-facing. They kept themselves to themselves, and they had a high turnover.
In the canteen, I sometimes tried to eavesdrop on their conversations. They were always just grumbling. It must have been a shitty job.
One of my earlier gigs was insurance claims and then I also did a stint in fraud. I think the only worse job could be debt collection or those guys from the military that visit you if your spouse dies.
I do technology in the FI space and pretty much all of my clients have a fraud process of "the customer notices their card is declined and has to call the number to find out why". C1 on the other hand will just send me a text asking for a yes/no and it works. Still ahead of the game as far as I am concerned.
[Edit] Can't delete! Well, Duh. C1 is what I called CapOne. I knew that. <slaps head>
c1: capital one
So are you saying that CapOne is nowadays completely different from how it was in 1997? That would be an interesting comment. But you haven't actually said anything; you've only snarked.
Honestly hope we see engineering manager title die off this decade as we go through these layoffs and reorgs.
Teams with a technical team lead should report to a director. It’s not that hard to slack someone if you’re blocked. We can even have an AI manager handle this kind of administrative crap.
I’ve had over a dozen engineering managers I’ve worked with and only two were any good. I mean, I keep in contact with them even years later. Rest were a joke at best or mostly terrible to work with.
Again I’m sure at some places this kind of arrangement works. But I’ve probably experienced more bot tier managers than bot tier engineers. And yea I’m mad about it so excuse my negative tone.
This was in addition to teams having product owners and an engineering manager as well at times. At times I had 3 people managing a team with 3-6 engineers.
Very interesting tech culture.
My last team before leaving had 3 engineers: tech lead, me, and a junior dev. It had 4 non-engineers managing us: a product owner, a head Agile Delivery Lead, a more junior agile Delivery Lead, and our manager.
Or not, in this case.
>And here's something else, Bob: I have eight different bosses right now.
>I beg your pardon?
>Eight bosses.
>Eight?
>Eight, Bob. So that means that when I make a mistake, I have eight different people coming by to tell me about it. That's my only real motivation, is not to be hassled. That, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
Cue some discussion about kids these days and "quiet quitting".
My SO at the time didn't understand what I did at work all day until we saw that movie in the theater.
His cube is so big and private, and he can push to prod without going through change management! Heaven.
> Individuals and interactions over processes and tools
very few teams are willing to admit that they need to be making boring things happen.
agile is not a universal tonic.
It is certainly not universal. As an example, if you want to make something great, it has absolutely no relation to your problem.
Like we follow agile principles (often take the core understanding and apply it in a way that works for the team). Usually the positions you mentioned are just EMs or tech leads with added responsibilities.
Honestly, what bothers me the most about this is the idea that "agile delivery lead" is abbreviated "AGL". It doesn't even make it any more pronounceable compared to "ADL".
All of these chains of command had different and conflicting priorities as well as political wars with each other. The product "owner" knew very little about the ill-defined product they owned yet they set the team's 'official' priorities based on wish lists from the business while the engineers also got different priorities from their chain of command and the scrum master was a glorified admin assistant.
The result was that no strategy existed and nothing of value was done but the engineers were still ground to a paste against the mill stones of the Jira board every two weeks.
It made me miss the simpler times of having a well defined waterfall project being done by a single team of engineers with a single engineering manager and a project manager to make the gantt chart and schedule the meetings.
Sorry for the people though that lost their jobs, I hope they all land on their feet.
The Agile role in our Tech organization was critical to our earlier transformation phases but as our organization matured, the natural next step is to integrate agile delivery processes directly into our core engineering practices
They did give me a pretty cool t-shirt though.
End of the day, we fill the client's need, as efficiently as we can without letting them run wild in expectations and keeping cost in line with budget: it's common sense and I dont get what the agile religions bring really. Turn idiots into mediocre people, maybe ?
ScrumMaster = NULL;
I can understand why the idea of hiring someone to handle that role would be appealing, but it really isn't a full-time job.
Plus, the last thing that BigCo engineering teams need is more politics; they have more than enough of that between the overlapping layers of engineering, project, and product managers.
That said, I've never actually seen it in practice.
At best, it has been a role someone in product takes on so they can act as a shit shield from above and let us know if there is something urgent, but otherwise stays out of the way.
At worst, it is a frivolous salary that takes the book-keeping notes from stand-ups and puts them in a report noone reads.