AI Amplifies Whatever Road You're On In July 2026, Perforce released a platform engineering report based on 820 respondents. Among organizations with mature internal platforms, 73% said that maturity was critical or significant to their success with AI. Among less mature organizations, 44% said the same. In May 2026, InfoQ covered a DORA report on the return from AI-assisted development that made a similar argument: the gains depend more on the quality of your internal platform and the clarity of your workflows than on which tools you buy. That’s vendor research, and it shows correlation rather than cause. Still, it matches what I’ve seen. AI is an amplifier. Put a bigger engine in a car on a paved road and you get where you’re going sooner. Put the same engine in a car on a rutted dirt road and you find the ditch sooner, and you hit it harder. The engine did its job both times. The road decided your final destination. I’ve worked on both kinds of road. There have been a few times in my more than a quarter century career building software for a living where I inherited a dirt road of software systems and services. There was no common definition of service health, and each service had its own needs. If someone had pointed a fleet of coding agents at them on day one, we’d have gotten a lot of changes very quickly and no reliable way to tell whether any of them helped. We had to grade the road first. The best paved road I’ve worked on is older than any of these tools. Over a decade ago, I was on the engineering team at a construction software company, and I managed the release schedule for a major release of its flagship estimating product. The release ran on two-week sprints with gates everyone could see: feature complete, code complete, an external beta, and a go or no-go meeting. Alongside it sat a readiness plan organized by division, from six weeks before release to after it, so training, marketing, sales, support, and accounting each had their own list. I owned one database readiness handoff myself. None of that is exciting. All of it is pavement, because it made “done” something people could check instead of argue about. The Perforce numbers carry a warning, too. Two thirds of organizations said they use AI in infrastructure workflows, but only 31% run it fully autonomously, and only 52% have fully automated audit trails. Organizations with formal governance reported trust in AI far more often (94%) than those with an ad hoc approach (51%). That tracks with my experience. Trust comes from being able to see what happened and undo it. Flags, staged rollouts, audit trails, and shared health scores are how you see and undo things. Here are two things to consider when planning your next AI investment. Your platform team is already an AI enablement team, whether anyone has told them or not. They own the guardrails the AI depends on. If you’re spending real money on AI tools while the platform team fights for headcount, you’re buying a bigger engine for a dirt road. Before your next rollout, pick one workflow you want to speed up and ask a few plain questions. Can we see what changed? Can we roll it back quickly? Do we have a shared definition of healthy for the thing it touches? If any answer is no, start there. Fund the road first. The engine can wait a quarter. https://anjuansimmons.com/blog/ai-amplifies-whatever-road-youre-on/ #road #organizations #perforce #among #july #ai #rss #feeds #linksharing #qwibbit

Not Everyone Wants Your Career Early in my career, one of the people I counseled didn’t want my job. I was a formal career counselor at a large consulting firm at the time. One of my counselees was a deep data conversion expert, the kind of person who makes sure years of records survive the move from an old system to a new one. She was very good at it. She was also uneasy. The next step up was Manager, and she was worried about the project management load that came with it. She was thinking about switching to a different workforce inside the firm. I was on the manager track myself, and it suited me. So, it would have been easy to assume she just needed some encouragement to grow into the path I was on. I think every manager has a version of this temptation. Our own career fits us pretty well because we’ve spent years tailoring it. When someone asks for advice, we pull it out of our closet and hand it over. However, a career is a lot like a suit. Mine fits me because it was cut for me. Hand it to someone with different shoulders and it hangs wrong, no matter how good the fabric is. So, instead of handing her my suit, I tried to do the work of a good counselor. I met with her regularly. I gathered feedback from three of her supervisors and wrote her annual contribution summary, so I had a real picture of how others saw her work. I was candid about one thing: I had seen few people thrive after leaving the consulting workforce, and I told her so. I also suggested she deepen her expertise and share it by teaching. Then I learned something that changed the conversation. The firm had created a new specialist career path, one that allowed promotion based on deep skills without the selling track. I brought it straight back to her. That’s the part I think about most. Advice is what I think. Information is what’s possible. She didn’t need my opinion about her career nearly as much as she needed to know about a door nobody had told her existed. I also made sure her work was seen. I used the firm’s recognition program to call out her expert work, and I represented her in calibration, which is where promotion decisions get argued. Advocacy in that room matters more than any pep talk outside it. She chose the specialist path. She was promoted to Manager. Within weeks, she took on a counselee of her own, which might be my favorite part of the story. Around that time I wrote to our HR team, “I strongly believe in the role of Career Counselor, and I would enjoy another opportunity to guide someone’s career.” I meant it, and I still do. However, the lesson she taught me was more specific than “career counseling is good.” A manager who makes copies of themselves ends up with a very boring team. The job is to help each person find the version of growth that fits them. Sometimes that means pointing someone toward a path you’d never choose for yourself. Sometimes it means going out and finding a path nobody has mentioned to them yet. If you have a strong person on your team who seems stuck, try a different question in your next one-on-one. Instead of “Where do you want to be in five years?”, ask “What part of the next step do you dread?” Then go find out whether there’s a version of the next step without it. https://anjuansimmons.com/blog/not-everyone-wants-your-career/ #career #manager #careercounselor #however #rss #feeds #linksharing #qwibbit

When the Lead Picks Up a Wrench The interface was tricky, I knew the system, and I was fast. So, I built it myself. This was around 2006, and I was leading an interface team of about 30 people on a big telecom program, building the links between a new system and everything around it. Some of those interfaces were hard, and more than once I did what a lot of technical leads do. I rolled up my sleeves. Not long after that, I received my annual performance review. It had plenty of praise in it. It also had development points that were very specific. There were times I stepped in to do some of the development work myself and, as a result, neglected broader duties like managing the defect queue and the production outages. My senior manager pushed me to delegate more and escalate earlier. That stung. In my head, I was saving the day and the team each time. However, the review pointed out that, in those instances, I had wandered away from core aspects of my job as a manager. A NASCAR pit crew is the best picture I have for this. During a pit stop, the crew chief isn’t the one changing tires. The crew chief is watching the entire environment: the fuel, the clock, the traffic coming down pit road, the driver’s voice on the radio. If the crew chief grabs an air wrench because the tire changer is a half second slow, maybe that tire goes on a little faster. But now nobody is checking whether the fuel can is still attached when the car pulls away. That’s what happened on my team. While I had the wrench, nobody was watching the defect queue closely. Outages weren’t getting the attention a lead should give them. The same review asked whether the offshore part of the team was producing at the same rate as the onshore part, which is exactly the question I should have been asking instead of writing code. There was another lesson in that review. To meet a deadline, my team implemented a faster stub solution that needed rework later. The client was open to a longer-term approach, but they “wished they were aware sooner.” I’ve learned that a shortcut can be the right call, as long as the person paying for it hears about the tradeoff early. If I had been watching the whole car, I would have raised it the week we made it. I’d love to say I fixed this habit right away. I didn’t. I love coding, and it took time for me to learn when to stay away from the temptation of “I’ll just fix it.” However, I learned a few things to help guide me when deciding if I should get hands on, and these principles are even more important in the age of AI. Now, when I pick up a wrench, I still keep an eye on the whole machine. Every hour I spend deep in a task is an hour my broader duties are at risk of neglect. Sometimes that trade is worth it. I just want it to be a choice and not a reflex. I’ve also gotten pickier about what kind of hands-on work a lead should take. Staying close to the work makes you a better leader, and I’d never tell a manager to stop understanding the code. However, the player-coach should take the work nobody is waiting on. If your piece runs late, nothing important should be stuck behind it. Regarding the feedback about communicating sooner, I escalate earlier than feels comfortable. Back then, my instinct was to fix a problem myself before telling anyone about it. A client doesn’t want to be impressed by your heroics. They want to know what’s happening while they can still choose. If a team keeps needing its lead to do the work, treat that as a staffing signal. Write it down and ask for help. So, the next time you reach for a wrench, look up first and check who’s watching the rest of the car. https://anjuansimmons.com/blog/when-the-lead-picks-up-a-wrench/ #leadpicks #wrench #rss #feeds #linksharing #qwibbit

One Clear Message Is Kind Several years ago, I had to tell an engineer that their performance was unacceptable. This is a conversation I’ve had several times over my career as a manager, and it’s never an easy conversation. However, this one was harder than most, and it took me a while to understand why. I inherited the engineer when I joined the company. Their work had real problems, and senior leadership had lost confidence in them. I could see that part right away. What I didn’t see at first was that for the last few years, this engineer received “exceeds expectations” on their performance reviews. They were also often publicly praised for their work in front of the entire company. So, the formal signals this engineer had received for years were positive. The concerns everyone above me seemed to share had never made it into those signals. So, from the engineer’s side, the story made no sense. A new manager shows up and says your work is unacceptable, while people more senior than that manager still seem to think you’re doing fine. Who would you believe? Picture a visit to a new doctor. The doctor tells you your blood pressure is dangerously high and you need to immediately make several lifestyle changes. Then, on the way out, the head nurse you’ve known for years pats you on the shoulder and says you look great. Which message do you carry home? Most of us carry home the comfortable one. We aren’t being foolish. It’s simply what we wanted to hear, and someone credible said it. That was the engineer’s situation. They believed they still had leadership’s confidence, and as long as they believed that, my feedback was one opinion against several. So, I did three things. First, I told the engineer directly and plainly where things stood. I didn’t soften the message and said it clearly with no ambiguity. Second, I went to the senior leadership team and made the case that they needed to give the same feedback directly, and that they needed to stop acting as a separate source of career direction for this person. This was the uncomfortable part. Nobody enjoys hearing that their kindness is causing harm. However, mixed messages let someone keep walking toward a cliff because everyone is too polite to point at it. Third, I put an improvement plan in place, with a contingency plan ready if it didn’t work. Both plans matter. The improvement plan tells the person you believe they can turn it around. The contingency plan keeps you honest with yourself and the business if they can’t. Having only the first one is hope. Having only the second one is paperwork for an exit. Once the messages lined up, things changed. The engineer became responsive and started to improve. My manager sent me a short note afterward: “Kudos for all the energy and work you’ve put into [their] performance. Thank you.” I appreciated it, but the engineer deserves most of the credit. They did the hard part once they finally had a clear target. I’ve carried a few habits out of that experience. I try to align the leaders before the hard conversation, not after, by finding out whether everyone with influence over someone’s career would say the same thing. If they wouldn’t, that’s my first job. I also treat silence as a message. When leaders have concerns and keep them to themselves, the person hears “everything’s fine,” and that’s the wrong message delivered by saying nothing. And I write it down, because a glowing review that doesn’t match reality is a trap for the next manager and, worse, for the person being reviewed. If someone on your team is struggling, ask yourself how many versions of the truth they’re hearing. If the answer is more than one, the kindest thing you can do is make it one. https://anjuansimmons.com/blog/one-clear-message-is-kind/ #clear #message #first #rss #feeds #linksharing #qwibbit

Nobody Lives in a Floor Plan Towards the end of my time at Accenture, I was the project manager on a launch for a large computer maker. They were starting a services offering for small and medium businesses, built on top of the CRM application they already ran. The go-live was a few months out. Requirements were still being written, and several vendors were involved. If you’ve been in this business a while, you know that combination costs a project manager some sleep. I built a bottom-up estimate and a 13-week plan, then brought on an application lead, two developers, a test lead, and an integration developer. At the peak we ramped up to nine people. We set up a deliverable matrix and a workbook for risks, assumptions, issues, and dependencies, and I sent a weekly status tracking our progress. That was all fairly standard project management. The part I’d repeat on any project was this: instead of whiteboarding designs, the team built working screens. We ran four conference room pilots where the business sat in front of something they could actually click. Afterward, the client’s project manager wrote, “the team seemed to be impressed with seeing actual screens rather than whiteboards!” I’ve held on to that line for almost twenty years because it explains something I’ve never forgotten. Home builders figured this out a long time ago. They don’t sell houses with blueprints. They build a model home. You can stare at a floor plan for an hour and nod along, but you don’t really know the kitchen is too small until you’re standing in it and walking around. Nobody lives in a floor plan. Whiteboards and software designs are floor plans. People nod at boxes and arrows and clicks because there’s nothing to push against. Put screens created in code in front of them and suddenly they have opinions. That field is in the wrong place. This screen is taking too long to load. We never use that status. Where’s the button for the thing we do fifty times a day? When people react like that, they’re finally telling you the real requirements. Showing something real also made the less fun conversation easier. As the pilots came together, I could see the go-live was going to overshoot the target date. So, I said so, early, while there was still time to plan around it. As a project manager, you can either announce the realistic date or wait for the deadline to announce it for you. The former is being responsible while the latter is a very unpleasant surprise. Nobody enjoys surprises in a steering meeting. The same thinking applied when the client’s architect sent us tough feedback based on the pilots. Some of it stung. I passed it to the team that day, because the software and the feedback were doing the same job: showing us the truth while it was still cheap to act on. We exited the planning and analysis phase on its baseline date with all four pilots delivered. I handed the project to a co-PM in December, and I like to think the habits went with it. If you’re leading a project, here’s what I’d try. Find the scariest unknown and build the smallest working thing that would expose it. A real clickable screen beats a mockup, and a mockup beats another diagram. Put it in front of the people who’ll use it, then stay quiet while they react. If what you learn moves the date, escalate immediately. https://anjuansimmons.com/blog/nobody-lives-in-a-floor-plan/ #rss #feeds #linksharing #qwibbit

I Bought a Very Expensive Hedge Twice a year an email lands telling me the enrollment window for the employee stock purchase plan is open. I always enroll. Buying company stock at a discount is one of the better deals a regular employee gets offered, and I’ve worked plenty of places that had nothing like it, so I know what it’s worth. Then there’s the part the money people keep saying. Ask most financial advisors about loading up on your employer’s stock and they’ll tell you to be careful. I’m not an advisor, but the reasoning is easy to follow. Your salary comes from that company. Your health coverage comes from that company. If a big chunk of your savings sits in its stock too, a bad quarter doesn’t just dent your balance. It shows up the same month as a hiring freeze and a thinner bonus pool. Everything you depend on moves with one ticker symbol, which is the opposite of diversification. Lately I keep seeing that same shape somewhere else. Most of us now get our AI through work. The company picked the vendor, signed the contract, and handed out seats. It’s convenient, it’s paid for, and it’s probably the model you use all day. So, what happens when the seat changes? I don’t mean that as a doomsday question. Companies adjust this kind of thing constantly, for boring reasons. Usage costs more than anyone forecast, so everybody gets a token budget. A model gets swapped for a cheaper one that’s almost as good. A security review decides which tools can touch the codebase and which can’t. Any of that can land on a Tuesday, and none of it requires a villain. It’s budget. Then there’s the bigger version. If you leave, or your role gets cut, your access walks out with your laptop. Everything you had learned to do with those tools, you suddenly can’t do, on exactly the day you need to show people what you can do. AI is becoming part of how work gets done whether any of us voted for it. If your only real access runs through your employer, you’ve stacked two things in one place: how you earn and how you work. So, months ago, I diversified. I bought a Mac Studio and started running open weight models on it. I want to be honest about the trade-offs, because this isn’t a pitch. It was expensive. Not an impulse buy, not a gadget, a real decision I thought about for a while. And the open weight models I run are not as capable as the frontier models. For some tasks the gap is obvious within one prompt. But I found a sweet spot. For a lot of what I actually do (drafting, summarizing, reading unfamiliar code, thinking out loud before I write) the local models are more than good enough. Nobody throttles me at the end of the quarter. Nobody deprecates the one I had gotten used to. There’s no renewal date and no seat to lose. The capability ceiling is lower, and the floor is mine. The privacy turned out to matter as much as the access. Nothing leaves the machine. When I’m working through something half-formed, or something I wouldn’t paste into a tool owned by somebody else, that’s worth real money to me. None of this means you should go buy the same hardware. That’s the expensive end of the range, and I went there because this is also how I tinker. A paid subscription you expense to nobody but yourself counts. A laptop running a small model counts. A cheap machine in a closet counts. The point isn’t the gear, it’s owning one path to AI that doesn’t route through your badge. Here’s the exercise I’d actually do. If your work AI access vanished tomorrow morning, write down what you couldn’t do anymore. Then find the cheapest way to cover the top two things on that list yourself. I still enroll in the stock plan every window. I just don’t want it to be the only thing I own. https://anjuansimmons.com/blog/i-bought-a-very-expensive-hedge/ #bought #rss #feeds #linksharing #qwibbit

The Bottleneck Moved to Review In July 2026, DX’s quarterly study of more than 500 organizations reported that AI wrote 52% of their code in the second quarter, up from 34% in the first. The same report found that the median pull request had nearly doubled in size. Then, in October 2026, the Stack Overflow developer survey found that 66% of developers who use AI now work with coding agents. So, more code, in bigger chunks, arriving faster. That sounds like a win until you ask where it all goes next. It goes to review. And review is still mostly done by people, at roughly the speed people have always read code. Restaurant kitchens have lived with this problem forever. Most busy kitchens have someone at the pass, the counter between the cooks and the dining room, who checks every plate before it goes out. If the owner hires three more line cooks and leaves one person at the pass, the restaurant serves the same number of customers, with a growing stack of plates under the heat lamps. The cooks feel productive. The diners still wait. (And the person at the pass starts updating their resume.) A faster machine upstream of a slow one just builds inventory. Agents made the cooks faster, and most teams haven’t added anyone at the pass. I’ve seen a smaller version of this long before agents. About ten years ago, I was the agile project manager at a small startup, and in one retrospective I wrote, “We carry potentially done work for several days because it is locked in a large user story… We need to get better at slicing stories.” The code was written. It just couldn’t move, because it was tied up with work that wasn’t finished. Big stories hid finished work. Big pull requests do the same thing, except an agent can now produce one in an afternoon. On that same team, when I wrote the release plan for the months after our platform went generally available, I reserved the back half of each release’s last sprint for a final acceptance test pass. I thought of that time as the plan admitting that checking work takes real capacity, and capacity has to be scheduled like anything else. That’s the shift I’d ask delivery leaders to make. Stop managing the keyboard and start managing the review queue. Start by looking. How long do pull requests wait for a first review, and how big are they when they get there? Most teams can pull that data in an hour. When LeadDev surveyed about 600 engineering leaders for its 2026 engineering leadership report, only 21% said they track time spent reviewing AI-generated code. If you’re in the other 79%, that’s your first project. Then plan sprints around review capacity instead of coding capacity. If an agent can draft three tickets overnight, the useful question in sprint planning becomes how much the team can carefully read, test, and own. Keep the batches small. DORA has recommended small batches as a way to reduce the delivery instability that comes with AI-assisted work, and that advice is older than any agent. Ask for smaller pull requests even when the agent could happily write a bigger one. Thin slices were good advice ten years ago. They’re better advice now. Finally, protect your reviewers. The people who review the most code tend to be your senior engineers, and they’re also the ones you need for design work and incidents. If review has become the main job, say so out loud, and give it the time and credit it deserves. I like the new cooks. I’d just like someone watching the pass before the food goes cold. https://anjuansimmons.com/blog/the-bottleneck-moved-to-review/