Hypotheses

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…

2021
Hypothesis: When scaling, “time” is the vector most easily forgotten and most dangerous to ignore.[↪]
Bats are just hamster fairies.[↪]
“Gaming the system” is not about trust or no trust. People behave based on the way they perceive they’re measured. It’s an optimisation thing. So best to have metrics that, even if people find shortcuts, make the system better. Or else, for eg, OKRs which focus first on outcome then on metric[↪]
The best way I know how to manage this is to work in small increments of customer value with continual feedback loops between product vision, strategy and tactics. Functional increments/agile delivery are not the ticket. And, easier said on twitter than done in reality.[↪]
It always surprises me how little we do this, and how much it helps. Also, nb: The sequence is important, don’t skip a step. So are the words “people” and “to”. As well as the separation between people and work.[↪]
Such a correlation between humbleness and ability to learn, adapt and grow. Which are way bigger levers for success that “smart”, or “educated”, measured over the long term. At least that’s become my belief, through personal experience.[↪]
Being aware of Conways Law, sadly, does not negate the effects of Conways Law. When it comes to systemic effects, “wanting really hard” (even if everyone in the system is all wanting hard together), while possibly necessary, is definitely insufficient.[↪]
If you’re reading for learning, “finishing” a book is a meaningless concept. Particularly if you plan to do that by reading to the end of it.[↪]
Human civilisation is just slow devops.[↪]
I don’t believe Messi has been successful despite this, I think it’s because this. As a leader, I try to make it safe for people to amuse themselves and be happy at work, and I’m at my best when I do the same.[↪]
When it comes to systemic effects like Conways Law, “wanting really hard” (even if everyone in the system is all wanting hard together), while possibly necessary, is definitely insufficient.[↪]
When you find yourself trying to convince someone they’re using a word wrong, it’s time to go up the spine together. Up to Principles. To Values. To Needs. You’ll come away with agreement and both having learnt things.[↪]
You measure impact of hiring another software engineer the same way you measure the impact of putting another potato into a stew. Make sure it’s not a rotten one. Check to see more potatoes will improve the stew. Don’t add too many at the same time or the cooking will slow down too much. A good stew is not just potatoes. Maybe more than one kind of potato would be nice for a change.And as long as it’s a healthy well grown potato it’s mostly going to soak up the flavour of the stew anyway, so focus on that.[↪]
Here’s the problem: In for-profit companies, high quality code does not matter. What matters, and even then only sometimes, is having poor quality code. The challenge for software people is that when that does matter it matters hard, and it’s on us to account for. [↪]

2017
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.

2016
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.

2015
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.

2014
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.