Capital One axes 1k tech roles(theregister.com)
theregister.com
Capital One axes 1k tech roles
https://www.theregister.com/2023/01/20/capital_one/
186 comments
What is “agile” job role family?
"Scrum masters" and their managers the "Agile delivery lead". Pretty sure there was somebody in charge of the AGLs under each director too.
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.
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.
Also a former Cap1 employee here, the 3 people managing a team of 3 engineers is quite common.
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.
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.
What did the agile people do?]
You need that many people to properly manage Jira /s
Promote synergy, direct workflow, bring value to key stakeholders
> bring value to key stakeholders
Or not, in this case.
Or not, in this case.
See who could complain about this it sounds incredibly valuable.
So, nothing?
Eh, steel manning the role it kind of just sounds like a TPM. When roles are crisply defined, a good TPM has been a life changer for my job satisfaction. You basically get permission to farm out a lot of the most annoying parts of the job--status update forums, timeline management, and dependency wrangling--to another person who does it full time.
Afaik all my tpm does is create outlook events and occasionally come to our standup to bitch about how we aren't doing enough jira
A reflection of your TPM, I guess
I've seen both versions of these. A good TPM is extremely valuable though, especially for work that is highly reliant on coordinating other teams. The bad version was a net negative to team productivity.
They're getting axed while the engineers get to stay, so not much it seems.
something something conjoined triangles of success
My first SDE job was in a company with a dedicated Scrum Master role, and they were basically the lubricant to make Agile/Scrum teams fit into what was essentially a waterfall environment. It's roughly a TPM in Big Tech, but without those companies as industry peers for setting comp.
Weird that some companies have a dedicated role for that. My current gig doesn't talk about agile at all... we still have two week sprints and self directing teams and all of that, just none of the annoying buzzwords
That's as it should be. As soon as people start with the buzzwords, I tune out.
It doesn't sound to me like the product owner should be considered the developers' manager. Though I guess that depends on what the word "manage" means and these days it's starting to sound like it's lost all meaning.
What makes it a hard call is that, in an organization that's trying to be engineering-focused, the product owner typically has as much say in what work you'll be doing as the person the org chart says you report to. (They have the most relevant expertise - a "people manager" has to spend a lot of their time managing people, while the product owner's sole and full-time responsibility is understanding what work the product needs.)
Strong product owners controlling the workflow and prioritization of the team certainly feel like management when you're working under one.
They shouldn't. Otherwise, there's nobody to pushback against stupid client requests. Product owners should be managing the product, not the employees. Having an employee manager to butt heads leads to a better overall product because it leads to better discussion between the devs who know the system and the product owner who is helping to flesh out requirements.
And to think, Office Space came out 24 years ago. Funny how things come full-circle.
>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".
>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".
> It's not that I'm lazy, I just don't care.
My SO at the time didn't understand what I did at work all day until we saw that movie in the theater.
My SO at the time didn't understand what I did at work all day until we saw that movie in the theater.
These days, Office Space is downright aspirational.
His cube is so big and private, and he can push to prod without going through change management! Heaven.
His cube is so big and private, and he can push to prod without going through change management! Heaven.
Hilarious. First line of the Agile manifesto is lost irony on these people I guess. Scrum and safe and all that nonsense is basically just a cargocult but not even a cargocult or anything useful
> Individuals and interactions over processes and tools
> Individuals and interactions over processes and tools
"individuals and interactions" is how you make great things happen. "processes and tools" is how you make boring things happen at scale and with high quality.
very few teams are willing to admit that they need to be making boring things happen.
agile is not a universal tonic.
very few teams are willing to admit that they need to be making boring things happen.
agile is not a universal tonic.
The Agile manifesto is entirely about making boring things happen for loosed integrated teams. It was created by a forum of consultants that wrote CRUD for random companies.
It is certainly not universal. As an example, if you want to make something great, it has absolutely no relation to your problem.
It is certainly not universal. As an example, if you want to make something great, it has absolutely no relation to your problem.
Ohh wow. I have worked in tech for over a decade now and none of this makes sense for me.
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.
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.
> "Scrum masters" and their managers the "Agile delivery lead". Pretty sure there was somebody in charge of the AGLs under each director too.
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".
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".
Another variation on this I've seen is an 'agile' 'team' composed of several groups of engineers each reporting to different managers in the organization with a scrum master and product owner who reported to yet different chains of command.
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.
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.
Scrum masters
Usually the family of jobs you do not see any big tech company. These are the roles that are defined in SAFe framework!
This looks like they are cutting jobs like scrum masters and product managers.
Finally, a silver lining of the economic downturn!
Scrum master is a full time job?
I thought I had heard it all with Happiness Managers but this takes the cake.
I thought I had heard it all with Happiness Managers but this takes the cake.
Our scrum masters are pretty useless at my company but they do work with 2 or 3 teams. They are basically secretaries/administrative assistants for JIRA and outlook which is fine.
Aren't scrum masters usually individual contributors on the team as well?
I've never seen a scrum master code. Sometimes the daily scrum meeting is run by ICs when the scrum master is busy or not around.
We do it. Usually agile comes from above and the team only have to tick a box, say they re agile and show a shadow org around it. We even rotate the scrum master sometimes to spread the joy.
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 ?
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 ?
It just seems to me that "agile as directed by management" is pretty much an oxymoron.
I have. Half of the time, I’m glad it’s not their primary responsibility in this case.
i have seen a scrum master code.
ScrumMaster = NULL;
We have scrum master as a rotating hat with all the other senior developers on the team. 99% of my day is code or meetings on what I'm coding. The only burden is once a week I look at jira with some managers and help them click boxes. I'm not sure what a full time scrum master would really do.
No, they are not. In some cases, if an individual contributor is not good at contributing, if one has political capital, that one can become a scrum master. And you see this in mega tech companies all the time.
The original idea was that the ICs would take turns as the scrum master. I'm sure someone somewhere has actually done that, but it's unusual.
It seems pretty popular in big software-centric companies like the FAANGs. IME the turnover is usually every couple of months, as the sacrificial lamb gets tired of it and other team members start to feel like it might be time to take a turn in the bilges.
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.
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.
I've heard that is the theory- that it should be a role on the team, not a title, and (optionally) that it should rotate. Everyone on the team at some point contributes to leading the team, so everyone gets accustomed to communicating well.
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.
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.
You can get a scrum master certification in about an hour and the test isn't even proctored.
> The consumer lending company told The Register that its plan was to eliminate its "Agile" job family and integrate staff there into "existing engineering and product manager roles."
Do we dare dream?
Do we dare dream?
Funnily enough my company started an agile reorg last year, and it's going as well as you can imagine. Cant wait for the de-agiling next phase where we can go back to having 4 matrix managers instead of 5...
I can’t wait to see these scrum master charlatans eliminated from most companies.
A scrum master was one of the most useless people I’ve ever worked with. Not a product or project manager because they didn’t know the domain. Didn’t know all that much about building software because they didn’t have any skills. Devs were still writing and moving tickets around so they basically did zero productive work.
My team was forced to invite a scrum master to several planning meetings. She sat quietly, observed the process, and then a few weeks later disappeared without a trace. We didn’t get any feedback from her or the org. Still not sure what that was about.
Wow, I had almost the exact same experience with my team! The only reason I don’t think we work together is that ours was a he.
Still no idea what that was about, and it was never brought up again.
Still no idea what that was about, and it was never brought up again.
When this is done, probably after the next fad takes hold, I want a grim and thorough post-mortem of Agile, from its naive utopian vision to the various parasites the ecosystem attracted, down to the disillusionment and tears. I want names and I want shame. I want the nasty cultist tendencies exposed for everyone to see and hopefully (ha!) learn from. Perhaps not post-mortem, perhaps vivisection, so that a mirror could be held up to the abdominal cavity so that Agile could at last see the teratomas lurking inside of it since shortly after its conception, before the whole thing flickers out.
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.
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.
There's a pretty simple generic form of it:
{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.
{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.
its like this with many things.
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
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
This can actually be an unfair characterization: my company required some developers, who tended to be the stronger technical leaders, become certified scrum masters for their respective teams. Is hate to lose them all
People who are scrum masters as part of being a senior/lead engineer aren't really the problem.
And it's possible some dedicated scrum masters could simply drop into the somewhat similar role of technical program manager.
And it's possible some dedicated scrum masters could simply drop into the somewhat similar role of technical program manager.
grug happy shaman ritual loosing power in org
Nature is healing
I learned something like "agile" from two guys that had worked with Ward Cunningham. That was useful; but it was also useful that they moved on after they'd trained the team.
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.
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.
well... https://www.scaledagileframework.com/ has gone so far into the koo koo land that teams are dysfunctional because of them.
Is this a parody website?
That one appears to be earnest, but Scaled Agile DevOps is definitely parody.[1]
[1]: https://scaledagiledevops.com/
[1]: https://scaledagiledevops.com/
“All teams should assemble in the Convoy Alignment room for this multi-day celebration of detailed planning. It is important that the alignment happens in person and that everyone travels to a remote location to eliminate distractions from less important things such as family or pets.”
Wow, this is so fun to read!
I wish. It's the rational people back again, this time leaning heavily on agile to sell to the c-suite. Everything good here is common sense or stolen from elsewhere; everything else is at best absolutely terriblev and at it's worse permanently damaging
No, to the point that there is this website - https://safedelusion.com/
We're in our second PI planning session and beyond SAFe it's gone so far off the rails we're into week 2 of planning. So bad that I'm likely to quit over the experience
Used to work for C1. It was never really clear to me what scrum masters did, since our manager understood the technical and cross-team requirements of our product (I know this might not be universal) better than anyone else.
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.
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.
> story points (some vague relationship to days of work)
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.
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.
Story points in my experience almost always devolve into time estimates, but I don't agree they have to be the same thing (which is how I interpret your use of "representative"). They are related variables in the same way that temperature and pressure are related, but that doesn't mean they are identical.
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.
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.
But by "complexity" people pretty much always mean "how long it'll take", so it's still time. If something was complex in an abstract way but quick to implement, it would get a small number of story points, not a large number.
I don't disagree with you fundamentally, but maybe one way to reframe this is around the type of conversation we're looking to prompt when we point stories. The conversation you're describing (and to be fair that I mostly have experienced as well) is a one-way, "you owe us this, how long will it take?" conversation. The conversation I'm always hoping to have, and that I've seen happen before, is a bi-directional one in which tradeoffs are discussed, priorities are constantly shifting, thoughtful investments are planned, and engineering concerns are a first-class citizen. All of this can happen if you simply consider your estimates "time" as well, but I find that conceptualizing it as "engineering complexity" helps encourage an engineering mindset among the non-developers on a team.
I’ve never understood story points either. Somehow, the argument goes that if you take a process that involves an high level of uncertainty, and you replace clearly defined units of work (time) with vaguely defined units of work (points), this will magically make estimation and planning _more_ accurate. Maybe, since you’re using Fibonnaci numbers, that makes it scientific?! I’ve never seen it actually work in fifteen years of trying.
Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate?
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).
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).
> Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate?
Well, who's planning to do it?
Well, who's planning to do it?
Depending on the team, number of tasks, size of task etc, answer to this ranges from: guy who does the estimate, to: whoever picks it first.
Which is almost always known at the time of estimation, in my experience. In the cases where it's not, then ok, points could make sense, but only as an interim step towards getting to a real time estimate once you know who is doing it. Having a vague point estimate could then be a useful indicator of "we don't really know yet".
> Which is almost always known at the time of estimation, in my experience.
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.
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.
> "I think that looks roughly like twice the work of that one we estimated before".
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.
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.
So basically you say "two days", while knowing that won't be two days - it's "virtual day". At this point how is it different from story point? :-)
It's weird how people whose half of work is coming up with clever abstractions, have so much problem with that one.
It's weird how people whose half of work is coming up with clever abstractions, have so much problem with that one.
because everyone could have a different opinion on what it actually means instead of just a simple time based measurement.
The whole thing is just absolute bonkers
Well for a day I've already meet: ideal man/day, average man/day of the team, man/day of the guy doing estimate.
Maybe estimation is complex thing and therefore team needs to align opinions before doing it?
Maybe estimation is complex thing and therefore team needs to align opinions before doing it?
We never do that though, we have to estimate our own tickets. So we're always estimating time for ourselves, we just can't say it's time though. Drives me mad but scrum masters these days have fully drunk the kool aid, it's fixed adherence to meaningless fibonacci story points or you're not doing it right.
You don't know that it won't be two days. It's an estimate, it's possible that a junior will go quick or senior will go slow.
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.
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.
They do. It's just your subjective time not objective that entire team needs to agree on. Which - more we discuss seems more and more impossible because it's more or less random how long it will take specific person.
> Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate?
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.
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.
Pointing in general is not very helpful in my experience.
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
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
1000x yes. I feel like I’ve had the same conversation about story points since 2006.
Use story points. Succeed with story points. But don’t try to convince yourself (or me) they aren’t just an analogue for time.
Use story points. Succeed with story points. But don’t try to convince yourself (or me) they aren’t just an analogue for time.
Agree. Especially because they are used mostly to gauge a team’s velocity.
You’re looking at it all wrong, story points are a defensive tool for you the developer. It gives your team a made up unit that no one else understands.
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.
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.
I can see how that could be useful for some teams. I guess the teams I've been on just haven't needed that kind of obfuscation.
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.
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.
Agile and scrum is not a solution to anything. Participating in agile voodoo has no measurable impact. In fact, I think in many cases agile makes you immediately slower. Developers than realize they have to pad everything with bullshit estimates they pulled out of thin air so they're not getting punished for missing work or bad guesses.
I just assume if the company is doing agile they have lost faith in their developers when it comes to organizing or producing value.
I just assume if the company is doing agile they have lost faith in their developers when it comes to organizing or producing value.
You have been blessed to work on self-organizing and self-managing teams. When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features.
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.
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.
> When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features.
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.
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.
>> But as a manager of remote, distributed, international teams?
> 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.
> 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.
> 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.
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.
Good teams can succeed with both, but it's billed as a panacea for bad teams.
Do you realize you’re attacking a straw man? Has anyone in this thread said that Agile is a panacea? I think we can agree it is not, nor is anything a panacea.
The response was re: sanedigital's remark that it was a good way to minimally fix (implied) bad teams.
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.
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.
As my current, very pragmatic scrum master told me: we try to cover the failure to plan woth agile and wonder why nothing gets done (or something along that line). Well, now our chaos is agile...
What you are describing makes sense within Scrum, because scrum asks for commitment.
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.
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.
This is what I often describe as doing agile vs being agile. Most large companies are constitutionally incapable of being agile, for a while host if reasons I don’t feel like iterating here, but I’m sure you can fill in the blanks.
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.
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.
> Most large companies are constitutionally incapable of being agile, for a while host if reasons I don’t feel like iterating here, but I’m sure you can fill in the blanks.
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 $$$
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 $$$
If the execs and managers can't get out of the mentality of planning X deliverables for Q3, Y deliverables for Q4 and Z feature by December 10th to satisfy a $10m customer then it becomes hollow and fake no matter how genuine and well meaning the consultants are.
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.
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.
> If the execs and managers can't get out of the mentality of planning X deliverables for Q3, Y deliverables for Q4 and Z feature by December 10th to satisfy a $10m customer then it becomes hollow and fake no matter how genuine and well meaning the consultants are.
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.
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.
>Customers don't pay money today for products delivered on an indefinite, unspecified future timeline
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".
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".
> I happily waited a year for my bank to implement virtual credit cards.
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.
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.
>Not the kind of feature I'm talking about
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.
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.
Dave Thomas, one of the co-creators and co-signer of the agile manifesto has a great talk on the topic.
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.
https://youtu.be/a-BOSpxYJ9M
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.
https://youtu.be/a-BOSpxYJ9M
> This is what I often describe as doing agile vs being agile.
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.
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.
The fact that this confusing distinction even exists is testament to how unnecessarily complicated agile is.
Agile (EDIT: The Agile Manifesto specifically) is meant to solve a very specific problem. It's meant to solve the problem of describing software via a contract, taking a long time to build the software described in that contract, and then the software not being useful despite an enormous amount of effort/resources poured into it.
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).
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).
Agile (EDIT: The Agile Manifesto specifically) is meant to solve a very specific problem. It's meant to solve the problem of describing software via a contract, taking a long time to build the software described in that contract, and then the software not being useful despite an enormous amount of effort/resources poured into it.
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.
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.
[deleted]
The Agile Manifesto it’s a nice read but you cannot put it in practice. It’s like the Bible: everyone has its own interpretation.
Not sure why we still talk about it.
Not sure why we still talk about it.
This comment is totally opinion and no evidence. But also oh so cathartic to read. Rant on, sir!
I'm not a big fan of agile, especially the more formal it gets. The problem that engineers have with it is that it does make things slower. Moving fast is absolutely not the goal of agile. The goal of agile is to make the development cycle predictable, so that all the moving parts of the bureaucracy can be at the right place at the right time. All of this stuff around estimation is really intended to make sure that unknowns are minimized, so that the list of work in JIRA or whatever is somewhat reflective of the actual work required. That lets the rest of the organization react to whatever the engineers are doing in a somewhat intelligent way. You can look at the progress bar on an epic, look at the date, and reasonably answer that question from a customer in the form "XXX bug is ruining my life, I hate you guys" "that will be in our Q2 release" "oh wow, I actually love you guys". That sort of interaction is what is paying your salary, so spending time to make it easy is what keeps the sales and support teams alive.
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 ;)
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 that engineers have with it is that it does make things slower.
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.
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.
I think the process is poor at accommodating generalists, since most people are not generalists. You might want to design a new feature one day, talk to customers the next, and then refactor your CI system on the third. The org really has no way to accommodate that; the cost to bring you up to speed on all the details is too high and your request is too weird. There is already a product team, support team, and testing team. Nobody has ever wanted to do all those things; all they want to do is show up, work on some technical mumbo jumbo, and disappear at 5pm. Moving the business forward what that at the bottom is what the process focuses on. (And, yes, this is why startups exist and do so well. If you can figure out Capital One or Twitter and pick the 10% that actually matters, you're back to a 2 person team. It ain't easy, though.)
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/
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/
Very much disagree. Well-run, minimal Agile is an amazing way to organize, see, plan, and go fast.
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.
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.
What’s the overall feeling towards scrum masters? In my last company, everyone outside product tech never understood their actual value. My CTO was a big fan, he said they were the glue binding the teams together or something like that. I never had a strong opinion but I’m curious to see how much controversy there was around this role.
At an old team of mine at Amazon we would assign an SDE to that role and switch it around every few months or so.
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
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
> we would assign an SDE to that role and switch it around every few months or so... 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.
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 don't see the point of scrum masters personally. They create more work if anything and mostly act as a cargo cult leader. A manager, a tech lead / staff developer, product manager... the other tech leadership positions on a team i see immediate value. Scrum Masters I do not and never have seen their use.
It really depends on who they are and how good at their job they are. I’ve seen more bad ones than good ones.
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.
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.
It is rarely awesome for the lead or senior dev.
Anyone who doesn’t want to do it is the wrong person, and doesn’t sound like a good lead dev to me.
A lead dev isn't necessarily a team lead. They could be a technical lead, or an architect, or simply a senior dev with deep knowledge of one specific project. They may not have the interest, skill, or authority to deal with the situation. Even if they can do it you may be pushing them towards quitting or burnout; or creating a feedback loop where their technical contributions drop because they need to coordinate more people because quality is dropping because your top dev's technical contributions dropped.
Sounds weak. I wouldn’t call that person a team lead or a lead dev.
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.
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.
I thought Anton Oliver performed exceptionally well for the All Blacks in the 90s, and even his return in the early 2000s added a lot of much needed experience to the front row.
They are so 2010s. Hopefully the role will die soon in the 2020s.
> 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.
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.
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.
Also used to work for C1.
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.
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.
> They dragged the entire company into AWS,
And why/how is that a good thing?
And why/how is that a good thing?
I think if you rephrase it that they "dragged the whole company out of the particular IT hell that is associated with banks owning, running and procuring infrastructure" it probably makes more sense.
I interned there a couple years ago. It was nice to use tech that was more standardized than proprietary / internal so that the skills were easily transferable.
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.
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.
I get that and that is the selling point of the cloud and it makes total sense for some workloads like ML/Data Science.
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.
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.
Agree that strategically lock in is a concern, but getting on AWS at least removes the inertia of moving to cloud. It’s probably much easier to go from on prem to cloud to multicloud than on prem to multicloud directly - especially at the time C1 started the migration.
> 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 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.
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.
There is a major cost of switching cloud providers, which means it’s less of an efficient market than it could be. Since all of the costs are transparent AWS knows how much more they can charge while still being cheaper than switching. Push the break even point far enough out and few companies will even consider switching.
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.
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.
Switching costs are non-trivial but I would also keep in mind just how valuable “we don’t raise prices” is to AWS for getting businesses to adopt them. In practice that means they don’t lower prices as quickly when the underlying costs decrease but an awful lot of CIOs prefer that to volatility.
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.
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.
Get a job at any other bank that's been around since the 1980s and you'll know why that's a good thing.
> The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month.
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.)
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.)
[deleted]
scrum master is one of the greatest grifts of 2010s-2020s tech. Esp when org chart pencils them in as 'mgmt' level so they are payed more than intermediate engineers, and on par with senior engineers
Oh god, the Fibonacci numbers.
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.
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.
You can make it closed under addition by defining addition to round to the nearest Fibonacci number.
You can! But as a bit of an Agile cynic, I find it quite funny that you literally have to accept that 2+2=5 to use it.
I also regularly question the value of “project” and “product” managers.
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.
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.
I can't speak to C1 specifically, but scrum masters ARE useful in some scenarios, while in others they are totally useless.
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.
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.
I worked at a company partially owned by C1. Our culture was somewhat derivative in the Agile aspect (Scrum, moving to SAFe).
> 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).
> 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).
> 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.
As a Product Manager, fucking yikes. I'm sorry for that horseshit.
> The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month
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.
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.
I was something like that in a previous role. I had no official title, but I was a sort of JIRA secretary. I chased people around to gather clear requirements, and cut them into understandable tickets. I babysat tickets to completion and did QA as needed. I made meetings redundant by doing the backlog grooming and requirements gathering in parallel. I chased information on behalf of developers, and made sure they didn't get stuck. I attended meetings and passed the relevant bits to devs.
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.
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.
I’ve heard that cap one were the first people to truly do data based lending, how’s that holding up?
> Many Reg readers will know Capital One best for the break-in in 2019, where an attacker raided Capital One's cloud storage buckets and stole personal information on 106 million credit card applicants in the US and Canada. Stolen data from people who applied for credit products included 140,000 US social security numbers and 80,000 bank account numbers, as well as one million Canadian social insurance numbers, plus names, addresses, phone numbers, dates of birth, and reported incomes.
> 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?
> 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?
where do you see that she got rich...?
> 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.
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 hope it's at least the ones that are responsible for aggressively pushing that stupid shopping browser extension every time I check my credit card account online. What a nonsensical thing to build, and what an annoying way to market it, without a way to opt out.
Sorry for the people though that lost their jobs, I hope they all land on their feet.
Sorry for the people though that lost their jobs, I hope they all land on their feet.
Interesting, I remember hitting up their booth at AWS lovefest in Vegas in 2019, and being somewhat surprised/perplexed to see that they were getting into the cloud infra management business.
They did give me a pretty cool t-shirt though.
They did give me a pretty cool t-shirt though.
I wonder how many trees are killed so that the shortsighted people at Capital One can keep blasting their spam every day.
> It says it uses "ML applications, APIs and cloud products" to prevent online credit fraud.
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.
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.
When you are working fraud cases, you talk to zero people that are happy. Either you are talking to an actual scammer, a victim, or a victim who is very unhappy that the fraud system has flagged something. And then even when things are cut and dry it can take several days for a refund to go through, so if the customer is paycheck-to-paycheck they will need to make sacrifices until it all clears.
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.
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.
"FI"? "C1"? Sorry if I'm being dim.
[Edit] Can't delete! Well, Duh. C1 is what I called CapOne. I knew that. <slaps head>
[Edit] Can't delete! Well, Duh. C1 is what I called CapOne. I knew that. <slaps head>
FI: financial institution
c1: capital one
c1: capital one
Your anecdote is from 1997, 26 years ago from today. Do you really think there is remotely any overlap from your experience in 1997 to how things are done today?
In terms of turnover? Yeah.
Well, I don't know. Corporate cultures are quite "sticky", in my experience. If a company is founded to exploit banking automation, I suppose it's likely to go on focusing on that expertise until it doesn't work any more.
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.
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.
Ah. So, I expect my job interview to be cancelled next week...
Company I recently consulted for dropped 90% of their project management team to save money. Didn't hurt anything, except leads had to do more Jira. Pretty painless way to save money from their pov.
Very clear in the article:
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
IME the bot tier engineers who couldn’t code or think got into “scrum” and other BS to try and become engineering managers. Of course we know how that ends.
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.
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.