the last useful meeting
i keep thinking about meetings as a temporary technology.
most of them exist because people dont share the same context. someone knows something another person doesnt, so you put them in a room and try to transfer it in real time. its expensive, noisy, and mostly inefficient, but for a long time it was the best option we had.
now a lot of that context can live outside the people. if the system can hold the state of the work, the open promises, the blockers, the recent decisions, then the meeting stops being the only way to get aligned. the information can just be present.
that doesnt mean every meeting disappears overnight. some of them are still useful for the social layer. you look at someone while they explain something and you can tell whether they actually believe it. you can feel the hesitation. you can push back in a way that text still makes soft. those moments matter. but they are a smaller percentage of meetings than people admit.
what i notice is that a lot of the recurring ones are just rituals for missing infrastructure. the daily standup exists because there is no shared, trusted view of what changed yesterday and what is blocked today. the weekly sync exists because decisions are not written down in a place that people actually read. the status update meeting exists because the manager does not have a clean signal without asking for it in person.
so the interesting question is not whether meetings die. its which ones survive once the information layer is good enough. the ones that remain will probably be the ones that still require judgment, conflict, or genuine presence. everything else starts looking like overhead that only made sense when the system was blind.
ive been building with that assumption in mind. if the product works, a certain class of meeting should feel slightly embarrassing to schedule. not because people became less social, but because the reason for the meeting got solved underneath them.
i dont know how long that takes. but i think the last useful meeting will not be announced. it will just stop getting booked.
tools that want your attention vs tools that want your outcome
most of the tools we use every day are not designed around the outcome. they are designed around attention.
slack wants you in the app. notion wants you writing and rearranging. dashboards want you checking. even a lot of the new ai products still pull you into another chat window, another inbox, another place where you have to go and manage the system. the product wins when you spend time with it.
that incentive is the root problem. if your business model depends on time spent, you will never fully optimise for time removed. you can talk about productivity, but the architecture will keep leaning toward engagement.
the tools that actually feel like leverage do the opposite. they disappear. the measure of success is how many hours they took off your week, not how many hours you spent inside them. the best ones leave almost no surface area. you set the intent, something moves, and you only get pulled in when a real decision is required.
i think this is why so many current ai tools still feel like work. they added a layer instead of removing one. you now have to prompt, review, correct, re-prompt. the cognitive load moved, it did not shrink. that is not a small difference. it is the entire difference.
when i was thinking about the ai manager, this was one of the constraints i kept returning to. if the product requires constant check-ins, it has already failed part of the thesis. the point is not another place for the manager to live. the point is that certain kinds of coordination should stop needing a human in the loop at all.
the hard part is that the market still rewards the attention model. it is easier to sell a dashboard people open every day than a system that quietly removes the need for the dashboard. so most teams keep building the former. the ones that figure out how to get paid for outcomes instead of attention will feel almost unfair once they work.
i dont think this shift is philosophical. it is practical. people are tired. they do not want more interfaces. they want the thing done. the products that understand that will not look like the current generation of tools. they will look more like infrastructure.
why “manager” is the wrong word
i keep calling it an ai manager and i am not sure that is the right frame anymore.
manager implies a person who assigns work, checks progress, resolves conflicts, and holds the team together. a lot of that is real work. but the interesting version of what i am building does not try to become a better version of that person. it tries to make a certain kind of management unnecessary.
that distinction matters. if you design toward “ai that manages people,” you end up with surveillance and status reports. if you design toward “system that holds context so people do not need to be managed as much,” you end up somewhere else entirely.
most of the pain in management is information asymmetry. the manager does not fully know what is blocked, what was promised, what changed since yesterday, or where two people are stepping on each other. so they schedule meetings, ask for updates, and try to reconstruct the state by hand. that reconstruction is the job for a large portion of the day.
once the state is continuous and visible, the reconstruction stops being necessary. the role shrinks. what remains is judgment, prioritisation, and the human parts that still do not compress well. that is a smaller and more valuable job. but it is not the same job people mean when they say manager.
so the word starts to mislead. it points at the old shape of the role instead of the new one. i still use it because it is the closest available label and because people immediately understand the domain. but i can feel the mismatch. the product is not trying to sit in the managers chair. it is trying to remove the need for that chair to be occupied as often.
maybe the better word has not shown up yet. or maybe we keep the word and let the meaning drift, the way a lot of job titles already have. either way, i keep noticing that the more the system works, the less it behaves like a manager and the more it behaves like shared infrastructure for a team that used to need one.
speed as a form of honesty
moving fast has a side effect that people underweight. it forces honesty.
when you ship slowly you can hide behind process. you can polish the story, delay the uncomfortable feedback, and protect the version of the work that still only exists in your head. slow timelines let unfinished ideas look more serious than they are.
speed removes that cover. if you are showing something every few days, the gaps become visible. the parts that do not work show up quickly. you cannot lean on the future version as hard because the current one is already out in the open. that pressure is useful. it keeps you from falling in love with the plan.
i have felt this while building. the demos are rough. the ui is incomplete. some of the language is still too technical. but putting it in front of people early has changed what i am willing to keep. features that felt important in isolation start looking optional once someone else has to use them. the opposite also happens. small details that seemed minor turn out to be the ones people actually need.
there is a version of speed that is just chaos. shipping without looking, changing direction every day, never letting anything settle. that is not what i mean. the useful version is the one that shortens the loop between belief and reality. you think something will matter. you put it in the world. the world answers. then you update.
that loop is a form of honesty with yourself. it is harder to maintain a private story about how good the work is when the work is already being used. the feedback arrives before the ego has time to fully attach.
i do not think everyone should move at the same pace. some problems need longer cycles. but for the kind of thing i am building right now, speed has been less about competition and more about staying clear. the faster the signal comes back, the less room there is for self-deception.
the part of work that still has to be human
after agents can write, review, coordinate, and follow through, what is actually left?
i do not mean this in a sentimental way. i mean it as a practical question. once the system can hold context, map intent, surface blockers, and move routine work forward, the list of things that still require a person gets shorter. the interesting part is what remains on that list and whether it is shrinking faster than people are willing to admit.
some of it is still judgment under uncertainty. deciding which of two good options matters more this week. choosing to ignore a metric that looks important but is not. absorbing a risk that the system cannot yet price. those decisions still feel human.
some of it is trust. people will take a hard message from another person in a way they will not take it from a system, at least for now. the social layer of work is sticky. it does not disappear just because the information layer improved.
some of it is taste. knowing what “good” looks like in a domain before the domain has been fully formalised. agents are getting better at matching patterns of quality, but there is still a gap when the standard itself is shifting.
and some of it is responsibility. when something breaks, someone has to own the consequence. systems can recommend. they can even act. but the accountability still sits with a person in most real organisations. that may change later. it has not fully changed yet.
the mistake is to treat these remaining parts as permanent. they are the current residue. each year the residue gets smaller. the work that felt essentially human five years ago is already partially automated. the work that feels essentially human today will look different in another cycle.
so the honest position is not “humans will always be needed for x.” it is “right now humans are still needed for x, and x is a moving target.” if you are building, you should be watching that boundary carefully. the value is not in defending the old list. the value is in noticing which items are about to fall off it.
i still do not know exactly where the line settles. i just know it is moving, and most people are arguing about last years version of it.