That’s called churn—losing developers who know your product and replacing them with developers who don’t know your product. This is a massive source of maintenance load, because it causes context loss: when all the knowledge that the leaving developer had, but didn’t document, effectively evaporates. This is where abandoned houses come from, and this is one of the reasons that losing a dev can realistically cost the organization, all told, several times the outgoing dev’s annual salary. There’s a way to regenerate lost context, but it’s expensive. We’ll get there later.
Dans cet article d'une série de trois, Chelsea Troy renome la "technical debt" en "maintenance load" et montre en quoi cette perspective permet de mieux qualifier ce qui gêne les développements. Sans même lire les deux suivants, rien qu'à travers cette nouvelle notion, on a déjà une bonne idée de la façon on pourrait prioriser et traiter ces freins.
We have a ridiculous amount of people and resources, but we constantly self-sabotage and squander effort. There is no way to sugar coat this; I think our organization is operating at half the effectiveness that would make me happy. Some may scoff and contend we are doing just fine, but others will laugh and say “Half? Ha! I’m at quarter efficiency!” It has been a struggle for me. I have a voice at the highest levels here, so it feels like I should be able to move things, but I’m evidently not persuasive enough. A good fraction of the things I complain about eventually turn my way after a year or two passes and evidence piles up, but I have never been able to kill stupid things before they cause damage, or set a direction and have a team actually stick to it. I think my influence at the margins has been positive, but it has never been a prime mover.
Dans cette courte annonce, John Carmack (Wolfenstein 3D, Quake, Rage, …) explique les raisons qui l'ont poussé à quitter Meta.
Google gathers feedback from employees on their managers through a semi-annual Manager Feedback Survey. Googlers answer confidentially and managers receive a report of anonymized, aggregated feedback if they get at least three survey responses, to preserve anonymity. Reports used to require more responses to ensure anonymity and avoid manager retaliation but the People Operations team didn't see much of this behavior. By reducing the threshold for reporting to three, far more managers of smaller teams could benefit from the feedback.
Une courte page sur le formulaire qu'utilise Google pour que les employés évaluent les compétences de leur manager. J'ai tenté d'utiliser ce formulaire avec mes managés, mais dans une boite de conseil, où les managers de carrière ne sont pas les managers opérationnels, de nombreuses questions doivent être ignorées ou détournées pour en retirer des infos. Je pense toutefois que c'est une bonne inspiration.
This is not an accident. It’s an inevitability. Not all Bad tech companies are successful, but almost all successful tech companies are Bad. […] What you can know in advance, is that any startup that survives the maze found the Fastest Survivable Path. […] Winning startups operate in grey areas until they’re white, with a culture just bad enough not to kill them, and figure out the business model later. They take the fastest, riskiest path that actually works. They are the survivors of the Fastest Survivable Path.
Dans ce court article, Alex Crompton explique pourquoi, selon lui, les boites tech doivent prendre des risques en termes culturels, légaux, techniques, … pour atteindre leur marché cible. Sur l'aspect technique, ça m'a rappelé ce court article "You can always go faster" qui parle de quand utiliser la stratégie "move fast and break things" de Facebook.
