14 ms·

> Is this preventable? I think not. If you look closely, all these problems fundamentally come from… It is preventable. I built an ISP in mid-90s, a digital

> Is this preventable? I think not. If you look closely, all these problems fundamentally come from… It is preventable. I built an ISP in mid-90s, a digital agency in late 90s, another digital agency and a streaming CDN (world's first VDN) in 00s, as well as worked as chief architect for cloud at world's largest hedge fund and CTO of world's second largest bank. I'm currently an entrepreneur again, co-founding and building a hedge fund from scratch. My experiences across these, particularly at the digital agencies (where I got to help hundreds of clients go through growth) and the mega bank (where I got to see how things working when small can also work somewhere global), tell me all the goodness from the initial list can be built into the operating model, with a couple caveats. These are hard[^1]: 1. No domain versus technology divide. If you hear "The business wants..." or "I need I.T. to..." it's not going to work. At a fintech, for instance, all teams should have both fin and tech on the team, owning their outcomes. 2. No command and control managerialism better suited for piecework than building. No project managers. No scrum-masters. Importantly, and apparently pure heresy: no projects.[^2] Instead of projects, think, what should we do better? Instead of controlling for budgets and delivery dates, control for focus (like priorities but mostly about saying "no" to things instead of "yes" to everything with stack ranking) and outcome value (e.g. RoI or RoE instead of hitting dates). Then you can manage the money as investments in teams delivering outcomes, instead of budgets for projects. Hitting dates well becomes easy and fun/rewarding when you scope using focus instead of pre-defining all (probably imperfect) requirements and you ensure teams are equipped with people (will, skill), and resources (tools, space) to own outcomes. (If people are called resources, run away.) It is preventable, and I'm happy to talk live with anyone building a work management tool that is interested in our approach. --- [^1]: see wicked problems: https://en.m.wikipedia.org/wiki/Wicked_problem https://en.m.wikipedia.org/wiki/Wicked_problem [^2]: You can do time-boxed work with an outcome. That could look a lot like a project. But the word “project” tends to bring with it a pile of practices that all kill the intrinsic motivation for building things you're proud of. It's interesting even companies as smart as Linear (the Jira alternative, check out their Linear method pages for a lot of better than usual thinking) don't want to even listen why they should (and could just by allowing renaming a few terms in their tool) support a non-project-centric view of building your company and enjoying doing it.

flappyeagle 3y ago
What pile of practices are you trying to avoid? When I see time boxed work with an outcome, that’s the very definition of a project to me. There’s nothing else. I had a weekend project building a desk. It’s timeboxed to the weekend. There’s an outcome. What am I missing?
- Terretta 3y ago
  On the contrary, "time box" means the time is fixed, the work achieved is variable. Projects: the project comes in "on time and under budget" or is "late", but the work is fixed. Time boxes: The difference is if you are targeting an RoE curve, you can decide when to continue investing in that or pivot to something else. You pick a date to re-evaluate. This is how VC work with startups. You also make sure have minimum viable outcome well before that re-eval date, and then viable increments. It's effectively just CI/CD for outcomes! I should mention that by running a video streaming VDN, in the 00s we carried the world's largest streaming events white labeled for other CDNs. TV deadlines are real: the Oscars, or the State of the Union address, are happening when they happen. So you can have to deliver outcomes in a time frame. The way to always always hit that, never miss it, is let the work within that outcome, the "definition of done" be the variable. Somewhere inside the effort is a minimum viable outcome. Ship that, then iterate until your date or additional effort is below your RoE bar. Managers love to invent deadlines to "motivate" a team, and everyone pretends they don't know the deadlines are nonsense. Actual deadlines -- if you're not working, you're dead -- teach you a different way to work. A project tries to fix both work and date, which doesn't work and is rarely on time. A time box fixes the date, not the work. Iterative delivery always hits the date and generally works. --- Using your weekend desk example: You could want a wood inlay desk. For the "job to be done", the desk has to support you doing work. In this toy example, the wood inlay is a desired constraint, not a required constraint. Business analyst will still call "wood inlay" a requirement, even though that "requirement" might lot let you ship a viable desk within the weekend. If you do the work project style, you might work the wood inlay for each panel before assembling them into a desk. The problem is, until you assemble it, the desk isn't a desk, it can't do the job to be done. If inlay takes longer than you thought, because it's your first time doing it and you had to research and built a couple test panels to throw away, then when the weekend is over, you have no desk. If you do it time-box style, and if "usable desk" is the required constraint, you might assemble the desk first, then do the inlay. Or you might design the desk where panels can be removed and inlaid whenever. Either way, if you ran out of weekend, you can already use the desk, just not fully inlaid. Certainly, doing the inlay after assembly will require more effort. So then ask yourself, was the deadline real, or was the inlay requirement real? If you know in advance that desk with inlay is the absolute requirement, you're willing to take two weekends instead of one, so then the deadline wasn't real. --- What's funny about this is, within a firm, everyone would jump on me and say the desk and the inlay are requirements. But if you don't know how to build desks, and need a vendor to provide it, you suddenly become tolerant of the differences in soft and hard requirements. Say you have to work from home, and you want a desk with inlay, but can't get one in time. You will iterate instead! You'll work at a table (the minimum viable desk) immediately and for a while, then maybe iterate to an Ikea desk while the custom one is ordered and hand crafted, then iterate to your custom desk with inlay when it arrives, with the added flexibility of arranging shipping to deliver when it's most convenient. If we handled work among groups internally the same way we understand we have to handle work among groups when we can't control them, companies would have a lot less jank.

flappyeagle 3y ago

What pile of practices are you trying to avoid? When I see time boxed work with an outcome, that’s the very definition of a project to me. There’s nothing else. I had a weekend project building a desk. It’s timeboxed to the weekend. There’s an outcome. What am I missing?

Terretta 3y ago
On the contrary, "time box" means the time is fixed, the work achieved is variable. Projects: the project comes in "on time and under budget" or is "late", but the work is fixed. Time boxes: The difference is if you are targeting an RoE curve, you can decide when to continue investing in that or pivot to something else. You pick a date to re-evaluate. This is how VC work with startups. You also make sure have minimum viable outcome well before that re-eval date, and then viable increments. It's effectively just CI/CD for outcomes! I should mention that by running a video streaming VDN, in the 00s we carried the world's largest streaming events white labeled for other CDNs. TV deadlines are real: the Oscars, or the State of the Union address, are happening when they happen. So you can have to deliver outcomes in a time frame. The way to always always hit that, never miss it, is let the work within that outcome, the "definition of done" be the variable. Somewhere inside the effort is a minimum viable outcome. Ship that, then iterate until your date or additional effort is below your RoE bar. Managers love to invent deadlines to "motivate" a team, and everyone pretends they don't know the deadlines are nonsense. Actual deadlines -- if you're not working, you're dead -- teach you a different way to work. A project tries to fix both work and date, which doesn't work and is rarely on time. A time box fixes the date, not the work. Iterative delivery always hits the date and generally works. --- Using your weekend desk example: You could want a wood inlay desk. For the "job to be done", the desk has to support you doing work. In this toy example, the wood inlay is a desired constraint, not a required constraint. Business analyst will still call "wood inlay" a requirement, even though that "requirement" might lot let you ship a viable desk within the weekend. If you do the work project style, you might work the wood inlay for each panel before assembling them into a desk. The problem is, until you assemble it, the desk isn't a desk, it can't do the job to be done. If inlay takes longer than you thought, because it's your first time doing it and you had to research and built a couple test panels to throw away, then when the weekend is over, you have no desk. If you do it time-box style, and if "usable desk" is the required constraint, you might assemble the desk first, then do the inlay. Or you might design the desk where panels can be removed and inlaid whenever. Either way, if you ran out of weekend, you can already use the desk, just not fully inlaid. Certainly, doing the inlay after assembly will require more effort. So then ask yourself, was the deadline real, or was the inlay requirement real? If you know in advance that desk with inlay is the absolute requirement, you're willing to take two weekends instead of one, so then the deadline wasn't real. --- What's funny about this is, within a firm, everyone would jump on me and say the desk and the inlay are requirements. But if you don't know how to build desks, and need a vendor to provide it, you suddenly become tolerant of the differences in soft and hard requirements. Say you have to work from home, and you want a desk with inlay, but can't get one in time. You will iterate instead! You'll work at a table (the minimum viable desk) immediately and for a while, then maybe iterate to an Ikea desk while the custom one is ordered and hand crafted, then iterate to your custom desk with inlay when it arrives, with the added flexibility of arranging shipping to deliver when it's most convenient. If we handled work among groups internally the same way we understand we have to handle work among groups when we can't control them, companies would have a lot less jank.