Thread regarding Allstate Corp. layoffs

It seems the majority of the DPMs I work with are barley one step above mentally re--rded. At this point just turn on the AI agents for Teams, Service Now, and Agility. I can code an AI agent to ask me useless questions, get in the way, and hullicante with bullsh-t. The ones who are fully blown re--rded are the ones who are too stupid/scared to admit that they dont know how their tech or any tech works at all.

@2em
Yep. The irony is that Allstate wants to be an 'agile' company, which should foster innovation and new ways of delivery but with the egos involved in middle and upper management, you can only be 'agile' within a very narrow set of parameters. And it doesn't matter whether what you're doing delivers actual customer value, it matters whether or not it fits in the narrow constraints of the OBD model and governance-which is nothing more than a giant antipattern. The people who supposed to be preventing this from happening are a-s covering paper tigers so they're not every going to be any help and the DPMs are stuck in the middle being (as someone else mentioned) the single throat to choke for the continued failure to deliver. Even thought they are allowed the least influence.

@2eh unfortunately a lot of the DPMs have ended up in the role without much say in the matter and are thoroughly fed up with the situation too. I personally know a number who think the current way of doing things is ridiculous but their hands are tied - they have very little say in how things are run because each team must be adhering to the very rigid rules of this OBD model

The DPM’s are a joke, All they are are middlemen who get in the way of you doing your job. They think they know the answers than they come to and ask for clarification. Let us do our job and get out of our way.

All I can say is if are worth a damn in tech or cyber leave this sh-t show! I dont see how DPM will translate well to much in the outside world in a world where they are cutting management jobs left and right esp at real tech compaines. You might pick up some buzz words but good luck explaining how the things work in meaninful detail. Experienced engineers who know how to use AI to make their work more productive will be fine. DPM not so much. Most of the time DPMs are nothing more than glorified note takers, so-so PM's, and Murial designers.

Company is a joke now. It always had a poor reputation in Belfast within the software companies but now it’s dropped even lower. Good luck to anyone trying to leave Allstate to find work in a real software company is all I can say.

Job listing with skills, responsibilities and requirements are in Workday as I've looked at them before. IIRC, go to career hub then explore job roles.

It’s a failed model

Zulfi and Kamal are still at Allstate! There is your problem.

To be considered a good fit you have to accept the Hot Fish Curry as compensation.

@qc "There are times when it appears that management places more emphasis on demonstrating adherence to the operating model than on improving the actual engineering work."

DING! DING! DING!

That's why product teams are audited on their OBD compliance to bronze, silver and gold. Zulfi and Kamal are more interested in being seen to be delivering, hence the somewhat authoritarian response to the recent Allstate Asks surveys, auditing teams on OBD etc.

A good, well-run, company where employees are empowered does not get you massacred in a company-wide survey. A good, well-run, company does not throw a massive sulk when survey results are sub-par. A company-wide way of working shouldn't require strict auditing around adoption because if it was good, teams would adopt it.

Never mind that this new way of working is costing hundreds of millions of dollars, that the new products are simply awful and not in the customer's interest and that, even without the mass layoffs, company morale would still be rock bottom.

Any successes produced are despite Z & K, not because of them, regardless of how Z & K dress up compliance to their new system structure or how bruised their egos are when their ideas are given constructive criticism.

As a past DPM who came over from the NatGen side….yeah, the other comments are spot on.

Around the time that the NatGen rebranding to AS occurred, they made a huge push for DPMs to start using, and creating AI agents. We had a whole training on it, and follow-ups to that training.

At one of my team meetings, a senior leader let it slip that “we have a lot of work and job security for the next 1-2 years with the merge” insinuating that a layoff or reorganization structure would likely happen after that when they no longer need us and can replace us with AI.

It’s why I left the company earlier this year.

Or in the obsession Zulfi has with AI doing everything, maybe its a move to eventually replace the majority of developers. Get DPMs who know the products inside out and who understand the requirements. Allow AI code generation to mature to the point where DPMs can feed in requirements and have AI generate and deploy the code. And once they've reached that point, get rid of the majority of Developers and maintain the more elite ones to keep the lights on. I wouldn't put it past them to be planning something like this, the way they're pushing AI code generation.

@fr sounds like the majority of people who work in the organization. Not just DPMs. I think that is a psychological control more than anything. Why do you think they removed the "do you trust senior leadership" question from the Asks survey.

My experience working with DPMs has been mixed. DPMs who have spent significant time at Allstate, understand the “Allstate Way,” and have established relationships across the organization can make a meaningful difference in getting things done. Unfortunately, many of the DPMs I work with lack a deep understanding of the products they support and do not have the internal connections necessary to effectively coordinate across teams.

I rely on my DPM to help navigate organizational bureaucracy, coordinate stakeholders, and remove administrative roadblocks so I can focus on the technical accuracy and quality of my work. Too often, that support falls short. Instead, engineers are expected to manage the coordination themselves, leaving the DPM functioning primarily as another person who needs technical explanations and takes generalized notes. This creates additional overhead rather than enabling the engineering team to work more efficiently.

The current product model seems to have compounded these problems. Rather than empowering engineers and improving delivery, it often feels like an additional layer of management built around a product structure that leadership has already committed to. DPMs were presented as enablers, but in practice, many do not have the authority, organizational relationships, or technical understanding needed to fulfill that role. They can end up serving as intermediaries who are held accountable for unrealistic delivery expectations without having the ability to resolve the underlying obstacles.

I agree that writing clear, well-defined stories is an important part of the process. However, it raises a broader question: Are senior leaders actually reviewing these stories and using them to make informed decisions, or has story writing become another process requirement? If the organizational priorities are speed to market, technical accuracy, and quality, we should evaluate whether our processes genuinely advance those objectives.

Our change management process is a good example. Allstate talks about automation, artificial intelligence, and moving faster, yet engineers must navigate a complicated, dated, and bureaucratic change process. Excessive reviews may create the perception of control, but they can also slow delivery without necessarily preventing unforeseen problems. We should be evaluating which controls meaningfully reduce risk and which exist primarily because they have always been part of the process.

There are times when it appears that management places more emphasis on demonstrating adherence to the operating model than on improving the actual engineering work. Process, documentation, and organizational structure become ends in themselves rather than tools for delivering better outcomes.

I also find the aspiration to operate with a startup culture difficult to reconcile with Allstate’s size, regulatory environment, and organizational structure. Large enterprises will always need governance and controls, but that does not mean they need excessive layers of management. Many technology companies deliberately flatten their organizational structures to empower engineers, accelerate decisions, and reduce unnecessary coordination. At Allstate, it can feel as though we are adding layers of management while failing to provide engineering teams with the resources, authority, and support they need to succeed.

Ultimately, I believe the organization needs to evaluate whether the current model is delivering its intended benefits. DPMs should be empowered to coordinate across teams, remove organizational barriers, and facilitate delivery—not simply document discussions or relay status updates. Change management should be risk-based and as automated as practical. Most importantly, engineers should be trusted and supported to focus on producing technically sound, reliable solutions.

If Allstate genuinely wants to improve speed to market and foster a more innovative engineering culture, it needs to measure success by delivery outcomes, quality, and reduced friction—not simply by adherence to the product model or completion of its associated processes.

I could see a big backtracking on DPMs in 2027, the same Scrum Masters got backtracked a few years. Being a DPM is a thankless task and if you get the chance to be one, don't. Poor worklife balance a lot of time, and uncertain future. Plus every team has at least 1 member who gives you a weekly headache.

I wish I'd taken the severance offer

@a6 You nailed it. Exactly right.

Kamal and Zulfi's 'product model' was in no small part an excuse to reimagine some people off the payroll and just dump their duties on the DPMs.

The DPMs now act as project/program/portfolio management since Allstate reimagined the PMO roles off the payroll a few years back. So they are now the single throat to choke when delivery doesn't happen.

Adding to this hilarity is Allstate's thick layer of middle management, which ensures that the day to day reality of DPM life and delivery NEVER reaches the senior managers who are making the strategic decisions. The break in the circuit between the strategic and the tactical, strictly enforced by middle managers who have their own agendas; ensures an ongoing discord in the company with DPMs taking the brunt. The middle managers who for years have caused this disconnect are themselves connected enough that they never bear the accountability for their actions.

When Allstate initially rolled this model out, the DPMs formed a 'Community of Practice' which was to be the voice for the body of DPMs and escalate things to senior management. This body was very quickly quashed as a 'rogue element' (read: They were bypassing the bogus messaging/reality that middle management sycophants were feeding senior management) and since nobody had the guts to advocate for them (least of all the Enterprise Agile people who trained the DPMs) they lost their voice. Now, it doesn't matter who ends up a DPM because they are fodder for the Kamal and Zufi ego machine.

I think there are actually two problems here. The first is the role itself. The DPM role is a combination of several roles that used to exist separately in Allstate: product owner, business analyst, project manager, manager, etc. That's a pretty big ask of one person, particularly when those roles can each require quite different skills.

The second is the people who have moved into the role without necessarily developing the broader skillset that the role now requires. It's not necessarily that they haven't worked in technology. IMO a lot of DPMs have come from one of those adjacent roles within Allstate, but they've sometimes brought the skills from their previous role without expanding beyond them.

My current DPM is a good example. They were previously a product owner and are actually very good at understanding the application from both a technical and business perspective. But they couldn't write a decent user story to save their life. That might sound like a minor issue, but it has a real knock-on effect. Developers end up having to fill in the gaps, work out what the actual requirement is, challenge assumptions and essentially do part of the analysis themselves, all while still having their own technical work and problems to deal with.

So I don't think the question is simply "why are there so many DPMs?" I'd be more interested in asking what we're actually expecting a DPM to be responsible for, what skills they're expected to have, and whether we're assessing people against the full breadth of that role. If we're going to combine several previously distinct roles into one, we shouldn't be surprised when there are capability gaps, and we shouldn't expect others to pick up the slack for them.