List of management resources, and my thoughts about them.
Writing an essay
People from various backgrounds won't have ever had to write an essay. This is a simple format to write something well structured and engaging.
Learning to write well is a skill that pays long term dividends. It helps build common ground, and is the fastest way to convey complex topics.
This is a list of resources I've found useful for my own reference, and to send people.
gov.uk is quite broad, it's good because it is specifically about writing for the web which is different from a book, or paper.
Stanford Engineering - Writing Clearly and Concisely is a good short introduction to technical writing.
Focussed on wordcount, but provides good worked examples of removing waffle from text.
Structuring text and documents
Although the next couple of links aren't about writing. Thinking about a piece of writing as a journey that you're leading the reader on helps with structuring it.
- TFL's wayfinding guidance written for physical navigation applies equally to digital navigation.
To ensure signing is clear and simple for customers passing through the station there should be a logical progession of information.
This should be based around the customer needs
at key decision points, keeping messages concise
and signs as simple and legible as possible.
There are interesting parrallels with the design of Mario World 1-1 each element of the game's mechanics are gradually introduced. It's a great example of intuative design and progressive disclosure. Which was achieved by watching people play and adapting the level, based on what they did.
I often think that a well written text enables speed running, you can very quickly run through it and pull out the information required. Clear flowing text enables, and supports just in time knowledge and skill acquisition.
Annual Performance Reviews
As I've researched how to do annual reviews better. I've found there's growing articles and thought about how they're counter productive. None of them have provided a good answer for how to manage pay rises. In tech this matters, it's much easier to move jobs and get paid more, than get a pay rise. For a company, it's a false economy not increasing pay. When a good developer leaves you lose domain, and company knowledge. It also creates additional work and cost from recruitment. Recruiting good engineers is hard.
Couples feedback and growth to remuneration ignoring the broader business context, being set up for success or failure. There was another article I read about this that went into more detail about how combining feedback and compensation into the same discussion was counter productive
The nub of the problem is it's almost impossible to evaluate if someone was given a poison chalice of a project or it was really easy. A large amount of this relates to the context they operate in, which isn't within their control.
There's also strong evidence that it re-inforces stereotypes, and disadvantages people that don't speak up or advocate for themselves.
Don't use Kubernetes Yet - Matt Rickard
Start with containers built locally - strongly agree with this you get most of the benefits of re-producable build without having to spend the effort to set it up.
The benefit of running code with serverless compute e.g. AWS Lambda breaks down as soon as you have long running tasks or need something outside the constraints of the system. Often you'll then need a container service, at which point you've mitigated the benefits and now have two ways to run and deploy code.
For very small companies managed Kubernetes has always felt like a foot-gun, one click to deploy. As soon as something doesn't work perfectly you have all the complexity and someone needs to understand it.
However overtime you often end up building a custom API for defining services. In my case this looked like a terraform module, which handled defining services in ECS. It's badly documented and custom. It also doesn't integrate with the Kubernetes ecosystem which means we can't leverage existing tools for example to do blue/green deployments.
What I find most interesting is how much of what I like about Slack, overlaps with the thinking from Stripe, from 2014.
- Ability to have full history searchable history
- Being able to @ someone in an existing thread