For those who might skip this because the title sounds like a generic tegeltjeswijsheid: it is a very concrete case study of what problems Soundcloud experienced, how the amount of work in progress was part of the problem, which things they did and which things they measured to reduce the amount of work in progress, and what effect that had.
tl;dr of the above: article is interesting though its title isn’t.
[edit: I code-switched for a moment, there. Tegeltjeswijsheid = hoary aphorism; advice that may be correct, but is too familiar to be insightful.]
What’s the etymology? (sounds like “little-tile wisdom” to my untrained ears)
You must have some kind of training I don’t.
You would be correct. AFAICT the heyday of these tiles was 1900-1960? For a plethora of modern hits, see the non-photo images.
Oh, haha, that makes so much sense now :)
I like the quantitative approach they took to proving what many of us know intuitively–too wide of a pipeline overwhelms engineering. I wish they would talk about what lead their management to the point of being able to talk about the issue. Many organization’s management doubles down on “All tasks having highest priority,” so what made Soundcloud able to look at the work in the pipeline’s effect on their workers in the first place?
For further reading I recommend The Phoenix Project, its a great book
Also, Slack by Tom Demarco (one of the author’s of Peopleware) talks directly about this issue, though not as entertaining as The Phoenix Project.
If you liked this post, you’ll like this book. A trove of scientific thinking (dense at times) about project management.
I rather enjoyed this article, and was impressed at the attempt to scientifically manage development.
That said, their company is failing and failing hard by all accounts. This seems rather like polishing the brass on the Titanic as it goes down. :(
It’s really too bad, I was always extremely impressed by SoundCloud. Being able to register and login and navigate smoothly without ever interrupting the music was nice.