Short personal insights, observations and hypothesis over time.

I use these as thought experiments, and as test straps to see how my thinking has expanded or moved on over time…

Observation: Command & control style managers produce conditions in which only command and control management gets anything done.
You can’t predict a complex work system using metrics. You can use metrics to learn how to change a system to be more predictable.
Functional specialization of individuals destroys team agility. Functional specialization of teams destroys organizational agility.
Agile methods are techniques rather than objectives. It follows that techniques of Agile must not be allowed to obscure the goal of agility.
The true value of an Agile board lies in its ability to enable collaboration, not in tracking when the work will be done.
If a team is considering digitizing their retrospectives, it’s very possible they’ve not understood the original intent of the practice.
The longer I haven’t done something the more I have all the answers for doing it right.
The older I get, the more time becomes a vector in my understanding of how things work.
I prefer “core skills” to “soft skills” as a phrase.
Having a single person in command to control a group of people will create a performance bottleneck.
Hypothesis: the only reason most management structures in organisations are needed is because people believe they are (needed). Alter the dominant narratives and ways of thinking and you can remove the need for most of them. This would result in a massive increase in agility.
Hypothesis: Leaders are clear about what to optimize for, and collaborate on ways to measure it. Managers enforce targets.
I avoid calling people “junior” or “senior”. It’s too absolute and linear. I prefer “more experienced at X” or “less experienced at X”.
If you’re being sold an “agile transformation” that doesn’t include deep structural change to the existing org, they’re naive or lying.
The micro-silos of knowledge between team-mates block flow. Pair programming a great first step, and training wheels for deeper team collab.
The code you have today is your nuanced understanding of the context + the code you write. Tomorrow the code stands alone.
In business, “Wow that’s so simple” is the second highest compliment you can give a piece of software. “Wow that makes a lot of money” is the first.
Any significant new learning requires unlearning as well. Inability/unwillingness to let go of what you already know limits new learning.
Hypothesis: ability to slice work into valuable increments, and willingness + ability to throw away or refactor code is directly correlated
A 10x dev is’nt 10x because they’re 10x smarter. They’ve taken the time to learn & practice the skills that make them more 10x effective. On question of if there’s such thing as 10x: Definitely. There’s also -10x. And often those who don’t understand software confuse the two.
Hypothesis: If a human being leaves your team and you are not at some level sad about that, you were probably not a team in the first place.
Your organisation’s structure is perfectly designed for the speed it’s currently going.
Teams are at their most agile not when there are no more practices to add, but when there are no more to remove.
The idea that any practice could be BEST in ALL contexts is really quite ludicrous when you scratch under the surface.
When people resign or leave you can’t replace them. You may find someone to do the same work that they used to. These two things are not the same.
Manual labour has a symmetrical relationship between hours worked and value produced. Mental labour is asymmetrical.
Progress in mastery is a transcendence of the questions, not the answers.
We equate effort with value because effort’s easier to quantify and measure. In knowledge work they don’t correlate. Ever.
If at first you don’t succeed and you can’t afford to try again, you probably approached it wrong.
In every line of code you write you make design decisions. You make an asynchronous trade off between future effort and value.
It’s not the strongest who go forwards, it’s the ones who can adapt.
Team dynamics seem to be much healthier when the person leading what gets done and the one leading how are not the same person
Traditional Dev manager: show me your skills, if they fit I’ll hire you. Agile team: show us your values, if they fit we’ll teach you the skills.
If you want to find the person in an organisation with the authority to effect structural change, go up the management stack passing all those that can say no, and find one with the power to say yes.
To any employer: if you can’t afford to trade an hour of received labor for an hour of given mentorship you’re doing your maths wrong.
When someone tells me a tech is powerful but complicated I’m sceptical. When they say it’s powerful and simple then they have my attention.
Next challenge for mid-large enterprise: understanding they still need good software developers whilst good developers no longer need them.
It’s much harder to admit you have a problem when you don’t know how to deal with it. The converse is also true.

© 2020. All rights reserved.