Jenna Pederson

[Works in Progress] makes the case that England's 18th-century growth came from replacing fragmented land rights with clear ownership. We're relearning the same lesson with agentic systems: teams ship faster once someone has real end-to-end authority over an angentic trajectory, not more reviewers in the loop. https://lnkd.in/gzgBpgaa

3

What does it cost to run Drupal's infrastructure? About $10 per site per year. Today the Drupal Association funds roughly $7.50 of that, with the gap showing up as technical debt. It’s time to start brainstorming about how we might fix that. More details and thoughts at https://lnkd.in/eThPsJaR.

124

25 Comments

I thought this was a good and very reasonable talk by Eleanor Millman on how to prioritize projects for a platform engineering team: https://lnkd.in/gaYtUHRH A few insights I took from it: - Unlike product features which can be more directly tied to revenue, platform engineering work is a couple steps removed. But that doesn't mean it's unimportant! Far from it, platform engineering projects can make everyone at the company more efficient, able to produce higher quality software, etc. - While "urgency" is always going to be a factor, you don't want to just be putting out fires, you want be able to prioritize work which is "high impact" ... even if that impact isn't felt immediately. - Good rule of thumb: prioritize "highest impact for lowest effort". - The talk has some ideas on what factors to choose for impact, and how to blend them. For instance "speed of development" is one factor, "cloud cost optimization" might be another. The weighting of different impact factors can change over time, depending on the needs of the business. I would say that a lot of companies don't have much methodology here but I can really see the value in codifying it. You can always change the methodology or the weighting if it's spitting out results that don't pass the smell test or you really feel it is leading the company astray. Clarity can give the org more freedom to put resources behind projects that would otherwise never be taken on. When things are unclear, prioritization still happens implicitly, but the decisions tend to be a lot more random and fear-based and the org is worse off as a result.

14

3 Comments

Anthropic just released Cowork (Jan 12), and it validates something Claude Code power users have known for months: the agentic paradigm works for EVERYTHING, not just coding. They literally observed users treating Claude Code as a general-purpose agent and thought "let's make this accessible to everyone." Cowork gives Claude access to a folder on your Mac. It reads files, edits them, organizes them, creates spreadsheets from scattered data. All sandboxed with Apple's Virtualization Framework running a custom Linux filesystem. It's Claude Code without the terminal. Same agent SDK underneath, less intimidating interface on top. The agent is becoming the default interface. ref.: https://lnkd.in/dd6MXEYF

18

To be fair, sometimes it *is* the seed. Not all seeds are going to sprout, thrive, or survive to bear fruit. But you can't control the seed, you can only control the conditions. Sometimes seeds fail to thrive because they are in a poorly fitting environment, and sometimes the environment is just poor, and no one really thrives. Wow, you can ride that analogy all kinds of distance. A culture that is direct and kind can be a great asset to a business, but it does not guarantee success. If the culture does not serve the business and help ensure its survival, the culture is not achieving its most important job.

62

13 Comments

Several people know about this problem but nobody talks about how to solve it. I was asked one time to help fix this issue at a company. The fix lies in breaking the work down to a few critical steps. First, never just hand off work in its entirety and expect you'll get anything you can use. Regardless of how good or bad the team is, always ask, always, the offshore team to pseudo code their approach. They should explain which files they'll touch, which systems they'll touch, integrations, which areas or layers of the application, etc. I call this the first pass. Why is this important? This tells me they're thinking about the problem right and if there are any gaps in their understanding, or any pieces they're missing. After that, they'll do a second pass. That is stubbing out which functions or code will need to be added or modified, maybe even making the functions and service calls work but with mock data. This is the "prove it to me" moment. This second pass also helps me as a dev manager gauge how fast or slow the offshore team is working, giving me indications too if they're stuck somewhere. Only after this second pass, do I actually turn them loose to go execute and "deliver" the solution. Only now, because I did some diligence on my managerial end, I've got greater confidence that what I'll get will be something on par with what I'm expecting and can use. This partnership and collaborative arrangement also fosters trust and over time the offshore team will learn how your organization operates, critical thinking, and that nothing should ever be done in a vacuum or cowboy way. For more helpful tips like this, follow me. I'm paying it forward in 2026 and will be sharing gems most people aren't talk about with a focus on the solutions, not just problems.

1