From Dune, "The flesh shapes the day, and the day shapes the flesh"
From Dune, "The flesh shapes the day, and the day shapes the flesh"
In 2015 I would have been High/High for ggplot2 - but these days I'd find myself in Low/Low for sure - and I think we all can relate to the experience of someone getting rusty in their actual skill set but their Confidence stays sky-high!
Like I said - much to consider here. More to come!
Time isn't just represented by individuals/teams moving into that high/high quadrant - but time itself can pass and have an effect on the overall status!
It can also help explain a person or a group's incentive structure (which, as has been pointed out, is so important in a professional setting) - if they're competent but not confident for some reason, it can offer some light into behavior, and also how to help guide it to a new conclusion.
This 2x2 status in a given area - maybe, "Node.js" or "Public Speaking" - understanding whether performance outcomes are a result of in-fact a skills issue or a motivation/confidence issue, can help us define next steps for ourselves, for our teams, for our firms generally.
Probably eventually a blog post, but consider a 2 x 2 grid with Low / High Confidence and Competence - for a person considering themselves, for a team you're leading, even for teams and organizational units that you're working with.
Thinking a lot about the interaction of Confidence and Competence, and I think it has a lot of interesting places to go.
AI-Generated βWorkslopβ Is Destroying Productivity
"The insidious effect of workslop is that it shifts the burden of the work downstream, requiring the receiver to interpret, correct, or redo the work. In other words, it transfers the effort from creator to receiver."
share.google/T3MXl3ReTw7V...
...& a blog post explaining what it is and why I built in in the first place:
s12k.com/2025/03/21/i...
Here's a link to More Good Work Talk if you missed that one:
saouderkirk.github.io/MoreGoodWork...
As 2025 starts to wind down, I'm trying to spend some more time hands-on with some new technology - ideally open source.
I'm going to convert my vibe-coded More Good Work Talk app to being powered by the Kixx framework (by @kixxauth.bsky.social ) & post the journey!
youtu.be/2ePd9pAQDfg?...
It has to start at the top - as an org leader you need to encourage folks to make their calendars reflect their priorities, and a priority of the org should always be, Do The Reading.
Like a lot of organizational problems though, you won't solve it by changing your individual behavior - if you're the one informed person on a call with 8 folks who didn't have time to be prepared, you've fallen victim to a prisoner's dilemma.
It's a vicious cycle. You need to make time to do the reading - carve out focus time, make your calendar reflect your priorities.
Then, since half of every call is spent on a read-in, you have to have twice as many calls to get the same effectiveness - which of course takes even more time away from being able to do the reading.
Folks are too busy (mostly on calls!) to do a thorough review of their pre-read artifacts, so when they arrive on the call, they need to spend half of that time being read into the documents they haven't been able to get to.
One of the great unspoken velocity killers in organizations greater than 100 people: Not Doing The Reading.
Could maybe be akin to tech debt in a way - a temporary shortcut to achieve important known goals, but you can't build a long term stack on it?
Product/Engineering orgs that are able to scale up their discovery efforts to not only write more code, faster, but are able to leverage the emergent technology and tooling to build great things that customers want - will win the day.
Improvements made to a process that aren't made at the bottleneck, aren't improvements.
When we see AI products out in the wild - already evoking waves of meme disdain about "clanker customer support" and "AI slop," both of which sound like a product that's not finding great product market fit! - we already have a wide landscape of solutions desperately scrabbling for a problem.
Discovery is one of the essential ways that mature Product/Engineering organizations work together to make great stuff out in the world.
The bottleneck today - and I expect in the future - is more about understanding the right idea, and the predictable tools that help guide us to deploying our scarce resources to the best possible product - that's Product Discovery.
It's not a lack of code being written that keeps the other 98 from being explosive successes, and creating machines that write more code, faster, isn't going to change that ratio.
Early stage tech investors have known this for a long time - look at how angel investors talk about The Power Law, where they'll make 100 investments and expect to make huge returns on only 1 or 2 of them.
Well, at least, it hasn't been the bottleneck in the overall software development landscape, if the end result that we're looking for is a profitable, valuable firm with products that customers want.
But, if what AI turns out to be efficient at, and can do at a roughly human quality at a multiplicatively high rate, is produce code that results in usable and useful software, it's interesting to reflect that "writing the code" has not typically been the bottleneck.
(it can and may be a bad thing for a lot of other reasons - this isn't a broad-brush abdication of skepticism and application of economic morals, trust me)
Listening to Lenny's podcast, watching the tech industry social streams, awash in my algorithm, I am thinking that the growth of AI isn't necessarily a bad thing for the careers and job market for either Product folks or Engineering folks.
How does this metaphor extend to hiring contractors or offshoring work - other common pathways to avoid hiring & onboarding engineering talent?