Found 33 bookmarks
Newest
The art of the pivot, part 2: How, why and when to pivot
The art of the pivot, part 2: How, why and when to pivot
people mix up two very different types of pivots and that it’s important to differentiate which path you’re on: Ideation pivots: This is when an early-stage startup changes its idea before having a fully formed product or meaningful traction. These pivots are easy to make, normally happen quickly after launch, and the new idea is often completely unrelated to the previous one. For example, Brex went from VR headsets to business banking, Retool went from Venmo for the U.K. to a no-code internal tools app, and Okta went from reliability monitoring to identity management all in under three months. YouTube changed direction from a dating site to a video streaming platform in less than a week. Hard pivots: This is when a company with a live product and real users/customers changes direction. In these cases, you are truly “pivoting”—keeping one element of the previous idea and doubling down on it. For example, Instagram stripped down its check-in app and went all in on its photo-sharing feature, Slack on its internal chat tool, and Loom on its screen recording feature. Occasionally a pivot is a mix of the two (i.e. you’re pivoting multiple times over 1+ years), but generally, when you’re following the advice below, make sure you’re clear on which category you’re in.
When looking at the data, a few interesting trends emerged: Ideation pivots generally happen within three months of launching your original idea. Note, a launch at this stage is typically just telling a bunch of your friends and colleagues about it. Hard pivots generally happen within two years after launch, and most around the one-year mark. I suspect the small number of companies that took longer regret not changing course earlier.
ou should have a hard conversation with your co-founder around the three-month mark, and depending on how it’s going (see below), either re-commit or change the idea. Then schedule a yearly check-in. If things are clicking, full speed ahead. If things feel meh, at least spend a few days talking about other potential directions.
Brex: “We applied to YC with this VR idea, which, looking back, it was pretty bad, but at the time we thought it was great. And within YC, we were like, ‘Yeah, we don’t even know where to start to build this.’” —Henrique Dubugras, co-founder and CEO
#business#business/strategy#startups#advice#work/productivity#examples#profiles#case-study
·lennysnewsletter.com·
The art of the pivot, part 2: How, why and when to pivot
The Complex Problem Of Lying For Jobs — Ludicity
The Complex Problem Of Lying For Jobs — Ludicity

Claude summary: Key takeaway Lying on job applications is pervasive in the tech industry due to systemic issues, but it creates an "Infinite Lie Vortex" that erodes integrity and job satisfaction. While honesty may limit short-term opportunities, it's crucial for long-term career fulfillment and ethical work environments.

Summary

  • The author responds to Nat Bennett's article against lying in job interviews, acknowledging its validity while exploring the nuances of the issue.
  • Most people in the tech industry are already lying or misrepresenting themselves on their CVs and in interviews, often through "technically true" statements.
  • The job market is flooded with candidates who are "cosplaying" at engineering, making it difficult for honest, competent individuals to compete.
  • Many employers and interviewers are not seriously engaged in engineering and overlook actual competence in favor of congratulatory conversation and superficial criteria
  • Most tech projects are "default dead," making it challenging for honest candidates to present impressive achievements without embellishment.
  • The author suggests that escaping the "Infinite Lie Vortex" requires building financial security, maintaining low expenses, and cultivating relationships with like-minded professionals.
  • Honesty in job applications may limit short-term opportunities but leads to more fulfilling and ethical work environments in the long run.
  • The author shares personal experiences of navigating the tech job market, including instances of misrepresentation and the challenges of maintaining integrity.
  • The piece concludes with a satirical, honest version of the author's CV, highlighting the absurdity of common resume claims and the value of authenticity.
  • Throughout the article, the author maintains a cynical, humorous tone while addressing serious issues in the tech industry's hiring practices and work culture.
  • The author emphasizes the importance of self-awareness, continuous learning, and valuing personal integrity over financial gain or status.
If your model is "it's okay to lie if I've been lied to" then we're all knee deep in bullshit forever and can never escape Transaction Cost Hell.
Do I agree that entering The Infinite Lie Vortex is wise or good for you spiritually? No, not at all, just look at what it's called.
it is very common practice on the job market to have a CV that obfuscates the reality of your contribution at previous workplaces. Putting aside whether you're a professional web developer because you got paid $20 by your uncle to fix some HTML, the issue with lying lies in the intent behind it. If you have a good idea of what impression you are leaving your interlocutor with, and you are crafting statements such that the image in their head does not map to reality, then you are lying.
Unfortunately thanks to our dear leader's masterful consummation of toxicity and incompetence, the truth of the matter is that: They left their previous job due to burnout related to extensive bullying, which future employers would like to know because they would prefer to blacklist everyone involved to minimize their chances of getting the bad actor. Everyone involved thinks that they were the victim, and an employer does not have access to my direct observations, so this is not even an unreasonable strategy All their projects were failures through no fault of their own, in a market where everyone has "successfully designed and implemented" their data governance initiatives, as indicated previously
What I am trying to say is that I currently believe that there are not enough employers who will appreciate honesty and competence for a strategy of honesty to reliably pay your rent. My concern, with regards to Nat's original article, is that the industry is so primed with nonsense that we effectively have two industries. We have a real engineering market, where people are fairly serious and gather in small conclaves (only two of which I have seen, and one of those was through a blog reader's introduction), and then a gigantic field of people that are cosplaying at engineering. The real market is large in absolute terms, but tiny relative to the number of candidates and companies out there. The fake market is all people that haven't cultivated the discipline to engineer but nonetheless want software engineering salaries and clout.
There are some companies where your interviewer is going to be a reasonable person, and there you can be totally honest. For example, it is a good thing to admit that the last project didn't go that well, because the kind of person that sees the industry for what it is, and who doesn't endorse bullshit, and who works on themselves diligently - that person is going to hear your honesty, and is probably reasonably good at detecting when candidates are revealing just enough fake problems to fake honesty, and then they will hire you. You will both put down your weapons and embrace. This is very rare. A strategy that is based on assuming this happens if you keep repeatedly engaging with random companies on the market is overwhelmingly going to result in a long, long search. For the most part, you will be engaged in a twisted, adversarial game with actors who will relentlessly try to do things like make you say a number first in case you say one that's too low.
Suffice it to say that, if you grin in just the right way and keep a straight face, there is a large class of person that will hear you say "Hah, you know, I'm just reflecting on how nice it is to be in a room full of people who are asking the right questions after all my other terrible interviews." and then they will shake your hand even as they shatter the other one patting themselves on the back at Mach 10. I know, I know, it sounds like that doesn't work but it absolutely does.
Neil Gaiman On Lying People get hired because, somehow, they get hired. In my case I did something which these days would be easy to check, and would get me into trouble, and when I started out, in those pre-internet days, seemed like a sensible career strategy: when I was asked by editors who I'd worked for, I lied. I listed a handful of magazines that sounded likely, and I sounded confident, and I got jobs. I then made it a point of honour to have written something for each of the magazines I'd listed to get that first job, so that I hadn't actually lied, I'd just been chronologically challenged... You get work however you get work.
Nat Bennett, of Start Of This Article fame, writes: If you want to be the kind of person who walks away from your job when you're asked to do something that doesn't fit your values, you need to save money. You need to maintain low fixed expenses. Acting with integrity – or whatever it is that you value – mostly isn't about making the right decision in the moment. It's mostly about the decisions that you make leading up to that moment, that prepare you to be able to make the decision that you feel is right.
As a rough rule, if I've let my relationship with a job deteriorate to the point that I must leave, I have already waited way too long, and will be forced to move to another place that is similarly upsetting.
And that is, of course, what had gradually happened. I very painfully navigated the immigration process, trimmed my expenses, found a position that is frequently silly but tolerable for extended periods of time, and started looking for work before the new gig, mostly the same as the last gig, became unbearable. Everything other than the immigration process was burnout induced, so I can't claim that it was a clever strategy, but the net effect is that I kept sacrificing things at the altar of Being Okay With Less, and now I am in an apartment so small that I think I almost fractured my little toe banging it on the side of my bed frame, but I have the luxury of not lying.
If I had to write down what a potential exit pathway looks like, it might be: Find a job even if you must navigate the Vortex, and it doesn't matter if it's bad because there's a grace period where your brain is not soaking up the local brand of madness, i.e, when you don't even understand the local politics yet Meet good programmers that appreciate things like mindfulness in your local area - you're going to have to figure out how to do this one Repeat Step 1 and Step 2 on a loop, building yourself up as a person, engineer, and friend, until someone who knows you for you hires you based on your personality and values, rather than "I have seven years doing bullshit in React that clearly should have been ten raw HTML pages served off one Django server"
A CEO here told me that he asks people to self-evaluate their skill on a scale of 1 to 10, but he actually has solid measures. You're at 10 at Python if you're a core maintainer. 9 if you speak at major international conferences, etc. On that scale, I'm a 4, or maybe a 5 on my best day ever, and that's the sad truth. We'll get there one day.
I will always hate writing code that moves the overall product further from Quality. I'll write a basic feature and take shortcuts, but not the kind that we are going to build on top of, which is unattractive to employers because sacrificing the long-term health of a product is a big part of status laundering.
The only piece of software I've written that is unambiguously helpful is this dumb hack that I used to cut up episodes of the Glass Cannon Podcast into one minute segments so that my skip track button on my underwater headphones is now a janky fast forward one minute button. It took me like ten minutes to write, and is my greatest pride.
Have I actually worked with Google? My CV says so, but guess what, not quite! I worked on one project where the money came from Google, but we really had one call with one guy who said we were probably on track, which we definitely were not!
Did I salvage a A$1.2M project? Technically yes, but only because I forced the previous developer to actually give us his code before he quit! This is not replicable, and then the whole engineering team quit over a mandatory return to office, so the application never shipped!
Did I save a half million dollars in Snowflake expenses? CV says yes, reality says I can only repeat that trick if someone decided to set another pile of money on fire and hand me the fire extinguisher! Did I really receive departmental recognition for this? Yes, but only in that they gave me A$30 and a pat on the head and told me that a raise wasn't on the table.
Was I the most highly paid senior engineer at that company? Yes, but only because I had insider information that four people quit in the same week, and used that to negotiate a 20% raise over the next highest salary - the decision was based around executive KPIs, not my competence!
#jobs#hiring#tech#work/productivity#work-life#bureaucracy#bullshit#culture#interviews#ethics#careers#business
·ludic.mataroa.blog·
The Complex Problem Of Lying For Jobs — Ludicity
The most hated workplace software on the planet
The most hated workplace software on the planet
LinkedIn, Reddit, and Blind abound with enraged job applicants and employees sharing tales of how difficult it is to book paid leave, how Kafkaesque it is to file an expense, how nerve-racking it is to close out a project. "I simply hate Workday. Fuck them and those who insist on using it for recruitment," one Reddit user wrote. "Everything is non-intuitive, so even the simplest tasks leave me scratching my head," wrote another. "Keeping notes on index cards would be more effective." Every HR professional and hiring manager I spoke with — whose lives are supposedly made easier by Workday — described Workday with a sense of cosmic exasperation.
If candidates hate Workday, if employees hate Workday, if HR people and managers processing and assessing those candidates and employees through Workday hate Workday — if Workday is the most annoying part of so many workers' workdays — how is Workday everywhere? How did a software provider so widely loathed become a mainstay of the modern workplace?
This is a saying in systems thinking: The purpose of a system is what it does (POSIWID), not what it fails to do. And the reality is that what Workday — and its many despised competitors — does for organizations is far more important than the anguish it causes everyone else.
In 1988, PeopleSoft, backed by IBM, built the first fully fledged Human Resources Information System. In 2004, Oracle acquired PeopleSoft for $10.3 billion. One of its founders, David Duffield, then started a new company that upgraded PeopleSoft's model to near limitless cloud-based storage — giving birth to Workday, the intractable nepo baby of HR software.
Workday is indifferent to our suffering in a job hunt, because we aren't Workday's clients, companies are. And these companies — from AT&T to Bank of America to Teladoc — have little incentive to care about your application experience, because if you didn't get the job, you're not their responsibility. For a company hiring and onboarding on a global scale, it is simply easier to screen fewer candidates if the result is still a single hire.
A search on a job board can return hundreds of listings for in-house Workday consultants: IT and engineering professionals hired to fix the software promising to fix processes.
For recruiters, Workday also lacks basic user-interface flexibility. When you promise ease-of-use and simplicity, you must deliver on the most basic user interactions. And yet: Sometimes searching for a candidate, or locating a candidate's status feels impossible. This happens outside of recruiting, too, where locating or attaching a boss's email to approve an expense sheet is complicated by the process, not streamlined. Bureaucratic hell is always about one person's ease coming at the cost of someone else's frustration, time wasted, and busy work. Workday makes no exceptions.
Workday touts its ability to track employee performance by collecting data and marking results, but it is employees who must spend time inputting this data. A creative director at a Fortune 500 company told me how in less than two years his company went "from annual reviews to twice-annual reviews to quarterly reviews to quarterly reviews plus separate twice-annual reviews." At each interval higher-ups pressed HR for more data, because they wanted what they'd paid for with Workday: more work product. With a press of a button, HR could provide that, but the entire company suffered thousands more hours of busy work. Automation made it too easy to do too much. (Workday's "customers choose the frequency at which they conduct reviews, not Workday," said the spokesperson.)
At the scale of a large company, this is simply too much work to expect a few people to do and far too user-specific to expect automation to handle well. It's why Workday can be the worst while still allowing that Paychex is the worst, Paycom is the worst, Paycor is the worst, and Dayforce is the worst. "HR software sucking" is a big tent.
Workday finds itself between enshittification steps two and three. The platform once made things faster, simpler for workers. But today it abuses workers by cutting corners on job-application and reimbursement procedures. In the process, it provides the value of a one-stop HR shop to its paying customers. It seems it's only a matter of time before Workday and its competitors try to split the difference and cut those same corners with the accounts that pay their bills.
Workday reveals what's important to the people who run Fortune 500 companies: easily and conveniently distributing busy work across large workforces. This is done with the arbitrary and perfunctory performance of work tasks (like excessive reviews) and with the throttling of momentum by making finance and HR tasks difficult. If your expenses and reimbursements are difficult to file, that's OK, because the people above you don't actually care if you get reimbursed. If it takes applicants 128% longer to apply, the people who implemented Workday don't really care. Throttling applicants is perhaps not intentional, but it's good for the company.
#work/productivity#reviews#bureaucracy#burnout#jobs#tech#software#business#ux#history#data structures
·businessinsider.com·
The most hated workplace software on the planet
How Perplexity builds product
How Perplexity builds product
inside look at how Perplexity builds product—which to me feels like what the future of product development will look like for many companies:AI-first: They’ve been asking AI questions about every step of the company-building process, including “How do I launch a product?” Employees are encouraged to ask AI before bothering colleagues.Organized like slime mold: They optimize for minimizing coordination costs by parallelizing as much of each project as possible.Small teams: Their typical team is two to three people. Their AI-generated (highly rated) podcast was built and is run by just one person.Few managers: They hire self-driven ICs and actively avoid hiring people who are strongest at guiding other people’s work.A prediction for the future: Johnny said, “If I had to guess, technical PMs or engineers with product taste will become the most valuable people at a company over time.”
Typical projects we work on only have one or two people on it. The hardest projects have three or four people, max. For example, our podcast is built by one person end to end. He’s a brand designer, but he does audio engineering and he’s doing all kinds of research to figure out how to build the most interactive and interesting podcast. I don’t think a PM has stepped into that process at any point.
We leverage product management most when there’s a really difficult decision that branches into many directions, and for more involved projects.
The hardest, and most important, part of the PM’s job is having taste around use cases. With AI, there are way too many possible use cases that you could work on. So the PM has to step in and make a branching qualitative decision based on the data, user research, and so on.
a big problem with AI is how you prioritize between more productivity-based use cases versus the engaging chatbot-type use cases.
we look foremost for flexibility and initiative. The ability to build constructively in a limited-resource environment (potentially having to wear several hats) is the most important to us.
We look for strong ICs with clear quantitative impacts on users rather than within their company. If I see the terms “Agile expert” or “scrum master” in the resume, it’s probably not going to be a great fit.
My goal is to structure teams around minimizing “coordination headwind,” as described by Alex Komoroske in this deck on seeing organizations as slime mold. The rough idea is that coordination costs (caused by uncertainty and disagreements) increase with scale, and adding managers doesn’t improve things. People’s incentives become misaligned. People tend to lie to their manager, who lies to their manager. And if you want to talk to someone in another part of the org, you have to go up two levels and down two levels, asking everyone along the way.
Instead, what you want to do is keep the overall goals aligned, and parallelize projects that point toward this goal by sharing reusable guides and processes.
Perplexity has existed for less than two years, and things are changing so quickly in AI that it’s hard to commit beyond that. We create quarterly plans. Within quarters, we try to keep plans stable within a product roadmap. The roadmap has a few large projects that everyone is aware of, along with small tasks that we shift around as priorities change.
Each week we have a kickoff meeting where everyone sets high-level expectations for their week. We have a culture of setting 75% weekly goals: everyone identifies their top priority for the week and tries to hit 75% of that by the end of the week. Just a few bullet points to make sure priorities are clear during the week.
All objectives are measurable, either in terms of quantifiable thresholds or Boolean “was X completed or not.” Our objectives are very aggressive, and often at the end of the quarter we only end up completing 70% in one direction or another. The remaining 30% helps identify gaps in prioritization and staffing.
At the beginning of each project, there is a quick kickoff for alignment, and afterward, iteration occurs in an asynchronous fashion, without constraints or review processes. When individuals feel ready for feedback on designs, implementation, or final product, they share it in Slack, and other members of the team give honest and constructive feedback. Iteration happens organically as needed, and the product doesn’t get launched until it gains internal traction via dogfooding.
all teams share common top-level metrics while A/B testing within their layer of the stack. Because the product can shift so quickly, we want to avoid political issues where anyone’s identity is bound to any given component of the product.
We’ve found that when teams don’t have a PM, team members take on the PM responsibilities, like adjusting scope, making user-facing decisions, and trusting their own taste.
What’s your primary tool for task management, and bug tracking?Linear. For AI products, the line between tasks, bugs, and projects becomes blurred, but we’ve found many concepts in Linear, like Leads, Triage, Sizing, etc., to be extremely important. A favorite feature of mine is auto-archiving—if a task hasn’t been mentioned in a while, chances are it’s not actually important.The primary tool we use to store sources of truth like roadmaps and milestone planning is Notion. We use Notion during development for design docs and RFCs, and afterward for documentation, postmortems, and historical records. Putting thoughts on paper (documenting chain-of-thought) leads to much clearer decision-making, and makes it easier to align async and avoid meetings.Unwrap.ai is a tool we’ve also recently introduced to consolidate, document, and quantify qualitative feedback. Because of the nature of AI, many issues are not always deterministic enough to classify as bugs. Unwrap groups individual pieces of feedback into more concrete themes and areas of improvement.
High-level objectives and directions come top-down, but a large amount of new ideas are floated bottom-up. We believe strongly that engineering and design should have ownership over ideas and details, especially for an AI product where the constraints are not known until ideas are turned into code and mock-ups.
Big challenges today revolve around scaling from our current size to the next level, both on the hiring side and in execution and planning. We don’t want to lose our core identity of working in a very flat and collaborative environment. Even small decisions, like how to organize Slack and Linear, can be tough to scale. Trying to stay transparent and scale the number of channels and projects without causing notifications to explode is something we’re currently trying to figure out.
#startups#business#product strategy#companies/Perplexity#ai#search#future#project management#job-titles#business/hierarchy#tech#examples#work/productivity#workflows#tools
·lennysnewsletter.com·
How Perplexity builds product
Yes! And...
Yes! And...
Missed context - Because you’re not a full-time employee (even if you’re working 5 days a week) you may not be included on all-hands emails, announcements and so on and so you always have to work hard to gain the full context of a client. Tightly scripting a performance doesn’t leave room for new contexts to emerge during the performance. Instead there should always be room for new context to emerge and get integrated into the performance in real-time. Missed feedback - It’s not uncommon as a consultant to be the most proficient powerpoint user in the org (or at least your portion of the org). This has benefits but it also has the unintended consequence of making everything you touch look “finished”. And finished work gets very different feedback from people than raw materials and thinking. So sometimes it’s important to un-design and un-polish your work, to invite people onto the stage to co-create the performance - this way you ensure that you get the appropriate feedback.
“thinking on your feet” is about the balance between deflecting decisions for further analysis and providing the answer there and then.
learning to provide an answer that you believe in but leaves room for revision later is key. The real game that’s being played here is not one of being right or wrong - it’s the executive asking two questions at once - firstly “how much do you know?” and secondly “can you improv?” to understand how useful you’re going to be in the theatre of work.
There’s a fine line between reacting to a situation in the room and bullshitting. As a consultant this is especially hard to avoid. Your default mode of operating is the liminal space between industries, businesses and markets. A few times a year I’m forced to learn something new from scratch. This forces us to work in spaces where we’re often the least knowledgeable about a specific business (even if we are experts in the industry… And sometimes we’re experts at a discipline but neither knowledgeable about the business or the industry).
#work-life#culture#bullshit#business#work/productivity#consultancies#acting
·tomcritchlow.com·
Yes! And...
Flow state - Why fragmented thinking is worse than any interruption
Flow state - Why fragmented thinking is worse than any interruption
Both arts and athletics involve a lot of deft physical movement, and I could see why professionals in those fields would benefit from learning to resist overthinking so they can “just do it.”  Almost every profession involves some need for focus, however, so you can see why, over time, the idea of a flow state breached its original limits. Now, “flow state” has all sorts of associations—some scientific, some folk, and some a mix of both. For many, the term has just become a dressed-up version of focusing.
A 2023 study found, for example, that there is a huge range of barriers to flow—many of which aren’t just interruptions from coworkers. They categorized these as situational barriers, such as interruptions and distractions; personal barriers, such as the work being too challenging or not challenging enough; and interpersonal barriers, such as poor management and poor team dynamics.
A 2018 study found, in addition, that the most disruptive interruptions aren’t external—they’re internal. 81% of the participants predicted internal interruptions would be worse, but they were wrong. “Self-interruptions,” the researchers wrote, “make task switching and interruptions more disruptive by negatively impacting the length of the suspension period and the number of nested interruptions.”
But because no one literally interrupted your work, you might be unaware of the costs of that rote, mundane work. You might even castigate yourself over the day for not getting the work done: You fought for a distraction-free day, got it, and you have nothing to show for it. It can feel bad.
a seemingly individual problem, staying focused, is often downstream from an organizational problem.
#workflows#opinion#business#dev#work/productivity
·blog.stackblitz.com·
Flow state - Why fragmented thinking is worse than any interruption
Most bosses regret how they mandated workers return to the office
Most bosses regret how they mandated workers return to the office
One such example is Amazon, whose RTO plan was admittedly prompted by the feelings of senior leadership, not hard data. “It’s time to disagree and commit. We’re here, we’re back—it’s working,” Mike Hopkins, senior vice president of Prime Video and Amazon Studios, reportedly said of in-person work. “I don’t have data to back it up, but I know it’s better.”
On one hand, remote work is proven to be between 10% and 20% less productive and can weaken morale and bonding, especially among younger workers and new workforce entrants. But people still overwhelmingly prefer at least a few days per week at home, arguing that physical office presence is more trouble than it’s worth and is rarely necessary to complete a task.
Ideally, a mix of both options—at the workers’ discretion—should fix the problem. Workers are flocking to jobs with flexibility, which has quickly become a must-have for most white-collar industries rather than a nice-to-have.
#work/productivity#business#management#stats#trends#public-life
·fortune.com·
Most bosses regret how they mandated workers return to the office
Theory of Constraints 102: The Illusion of Local Optima - Forte Labs
Theory of Constraints 102: The Illusion of Local Optima - Forte Labs
This discusses how trying to improve each part of a complex system can lead to an overall under-optimized system. It uses the example of a company where each department is like a section of pipe, with work flowing from left to right. If the Engineering department is the bottleneck, with the lowest staff and capacity, then the rule to "stay busy" will lead to local optima, with departments starting new projects to fill their capacity. This causes work to pile up at the bottleneck, leading to decreased throughput, conflict, and inefficiency. The only way to improve the system as a whole is to optimize the bottleneck, not each individual part.
#work/productivity#business
·fortelabs.com·
Theory of Constraints 102: The Illusion of Local Optima - Forte Labs
How DAOs Could Change the Way We Work
How DAOs Could Change the Way We Work
DAOs are effectively owned and governed by people who hold a sufficient number of a DAO’s native token, which functions like a type of cryptocurrency. For example, $FWB is the native token of popular social DAO called Friends With Benefits, and people can buy, earn, or trade it.
Contributors will be able to use their DAO’s native tokens to vote on key decisions. You can get a glimpse into the kinds of decisions DAO members are already voting on at Snapshot, which is essentially a decentralized voting system. Having said this, existing voting mechanisms have been criticized by the likes of Vitalik Buterin, founder of Ethereum, the open-source blockchain that acts as a foundational layer for the majority of Web3 applications. So, this type of voting is likely to evolve over time.
#web3#DAOs#business#tech#trends#work/productivity#business/models#public-life
·hbr.org·
How DAOs Could Change the Way We Work
On Better Meetings
On Better Meetings
Look a week ahead: Towards the end of a week, I’ll start to take a look at what meetings I have the following week. For any that I’m responsible for, I’ll start pulling together some information for attendees. Sometimes this means updating the calendar invite with an agenda; other times this means starting a Google Doc for what we need to run through during the meeting, and I share it with edit rights for all attendees. Use meeting goals: If the meeting has a bunch of people in it (like, more than two), especially if those people typically have full schedules, then I’ll write down goals for the meeting. Often, I’ll put those goals in the calendar item, and I’ll mention them at the beginning of the meeting. That means that if we get off-track during our time together, I can hit pause and recenter on the goals, asking folks to continue that other conversation afterward. Find a plant: Once in awhile, it’s helpful to “seed” the meeting somehow. For example, in one meeting where there’s an “open questions” time and I want people to ask anything, I’ve asked a buddy to think up a super weird one to demonstrate to others that it’s a safe space. Don’t surprise people in the meeting: Additionally, I do a lot of prep to make sure there’s no surprises in my meetings, at least none coming from me. This usually means that I let a handful of people know about a big announcement ahead of time (or had a tough conversation), usually one-on-one, so they wouldn’t be surprised in front of a lot of other people. Gain consensus 1:1 beforehand, if possible: My goal with any decision-making meeting is to already have a sense, going in, of what issues people have, what their opinion is, and what they might need to come to agreement. I do as much legwork in advance as possible, so that the whole group is ready to make that decision more quickly in the room.
Few things bog down meetings more than an unclear process, or a lack of clarity about how people in attendance are supposed to participate. By sharing the goals of the meeting and a high-level overview of what we’re going to do there, I hope to make it clear what’s expected of folks in the room.
Setting up a form for people to add their questions to - including people in the shared physical space - so that the facilitator can run through them rather than prioritize the voices in the room
I cancel meetings if they’re unwarranted. I check-in every few months to see if a meeting’s goal still makes sense; I ask attendees how they’re feeling about the length of the meeting, how often it happens, and what we do during it. I iterate on meetings to make sure they’re still effective, or even necessary.
#work/productivity#meetings#business#advice#guides
·larahogan.me·
On Better Meetings
Urban Dictionary: bikeshed
Urban Dictionary: bikeshed
Bikeshed refers to topics which have never recieved concensus and are likely to generate side-discussions and flames unless all participants are well-read on all the past history. It stems from the idea that big changes (like the building of a power plant) go through quickly, since everyone assumes that someone else has checked it out, while simple changes (like building a bikeshed) often get mired in bureaucracy, since everyone has an opinion on it.
#words#business#definitions#work/productivity
·urbandictionary.com·
Urban Dictionary: bikeshed
Diminishing returns - Wikipedia
Diminishing returns - Wikipedia
A common example of diminishing returns is choosing to hire more people on a factory floor to alter current manufacturing and production capabilities. Given that the capital on the floor (e.g. manufacturing machines, pre-existing technology, warehouses) is held constant, increasing from one employee to two employees is, theoretically, going to more than double production possibilities and this is called increasing returns. If we now employ 50 people, at some point, increasing the number of employees by two percent (from 50 to 51 employees) would increase output by two percent and this is called constant returns. However, if we look further along the production curve to, for example 100 employees, floor space is likely getting crowded, there are too many people operating the machines and in the building, and workers are getting in each other's way. Increasing the number of employees by two percent (from 100 to 102 employees) would increase output by less than two percent and this is called "diminishing returns."
#philosophy#business#product strategy#economy#govt/policy#work/productivity
·en.wikipedia.org·
Diminishing returns - Wikipedia
Technical debt - Wikipedia
Technical debt - Wikipedia
In software development, technical debt (also known as design debt[1] or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.[2] Analogous with monetary debt,[3] if technical debt is not repaid, it can accumulate "interest", making it harder to implement changes. Unaddressed technical debt increases software entropy and cost of further rework.
Common causes of technical debt include: Ongoing development, long series of project enhancements over time renders old solutions sub-optimal.
When I think about Adobe's reliance on entrenched menu panels and new menus with new/inconsistent interfaces I think of this. They've lasted so long that new features are all stapled on as menus instead of integrated throughout the whole system. Some ideas require a rethink of the whole interface, something Adobe can't afford because they're moving too much and don't have the resources to dedicate to soemthing of that scale?
Parallel development on multiple branches accrues technical debt because of the work required to merge the changes into a single source base. The more changes done in isolation, the more debt.
Similarly, this reminds me of the Gmail redesign's "blue-gate" where designers on Twitter pointed out how many different tones of Blue were in different aspects of the redesign. It seemed apparent that each component of the interface had it's own dedicated team, and the inconsistencies in appearance/interface design came from non-thorough communication between the teams.
#product strategy#dev#business#philosophy#work/productivity#figma#companies/adobe
·en.wikipedia.org·
Technical debt - Wikipedia
Our distributed company is a garden
Our distributed company is a garden
I think Sanctuary, Hydraulics, and XXIX are proving this assumption wrong. As designers and developers, we create tools for a living. That includes tools for helping other teams make great decisions. Tools to help their coworkers ask and offer feedback. Tools to help their peers get clear on where they want to grow. We obsess over making tools that improve the way we work. When we see an opportunity to improve, we upgrade our tools. Or build a new tool, toss the old one, and thank it for serving its purpose (Marie Kondo style).
We intend to revise those skills so that they reflect what good leadership looks like in a distributed organization. Things like:Noticing a problem/opportunity and proposing an experiment to solve itKnowing how to offer and give helpful feedbackKnowing how to receive feedbackActive listeningHelping others get clear on where they want to growCoaching (rather than managing) others toward their goals
#business#mental models#work/productivity
·garden3d.substack.com·
Our distributed company is a garden
What I've Learned from Users
What I've Learned from Users
The reason startups are so counterintuitive is that they're so different from most people's other experiences. No one knows what it's like except those who've done it. Which is why YC partners should usually have been founders themselves.
the essence of what happens at YC is to figure out which problems matter most, then cook up ideas for solving them — ideally at a resolution of a week or less — and then try those ideas and measure how well they worked. The focus is on action, with measurable, near-term results.
A small improvement in navigational ability can make you a lot faster, because it has a double effect: the path is shorter, and you can travel faster along it when you're more certain it's the right one. That's where a lot of YC's value lies, in helping founders get an extra increment of focus that lets them move faster. And since moving fast is the essence of a startup, YC in effect makes startups more startup-like.Speed defines startups. Focus enables speed. YC improves focus.
However good you are, good colleagues make you better. Indeed, very ambitious people probably need colleagues more than anyone else, because they're so starved for them in everyday life.
#startup#business#product design#product strategy#work/productivity
·paulgraham.com·
What I've Learned from Users
Be good-argument-driven, not data-driven
Be good-argument-driven, not data-driven
An overemphasis on data can harm your culture through two different channels. One is the suspension of disbelief. Metrics are important, says your organization, so you just proceed to introduce metrics in areas where they don’t belong and everybody just ignores the fact that they are meaningless. Two is the streetlight effect. Metrics are important, says the organization, so you encourage your engineers to focus disproportionately on improvements that are easy to measure through metrics - i.e. you focus too much on engagement, growth hacks, small, superficial changes that can be A/B tested, vs. sophisticated, more nuanced improvements whose impact is more meaningful but harder or impossible to measure.
#metrics v humanities#business#agile#work/productivity
·twitchard.github.io·
Be good-argument-driven, not data-driven
Data-Driven Design is Killing Our Instincts
Data-Driven Design is Killing Our Instincts
It creates more generic-looking interfaces that may perform well in numbers but fall short of appealing to our senses.
It’s easy to make data-driven design decisions, but relying on data alone ignores that some goals are difficult to measure. Data is very useful for incremental, tactical changes, but only if it’s checked and balanced by our instincts and common sense.
It became clear to the team in that moment that we cared about more than just clicks. We had other goals for this design: It needed to set expectations about what happens next, it needed to communicate quality, and we wanted it to build familiarity and trust in our brand.We could have easily measured how many customers clicked one button versus another, and used that data to pick an optimal button. But that approach would have ignored the big picture and other important goals.
Not everything that can be counted counts. Not everything that counts can be counted.Data is good at measuring things that are easy to measure. Some goals are less tangible, but that doesn’t make them less important.While you’re chasing a 2% increase in conversion rate you may be suffering a 10% decrease in brand trustworthiness. You’ve optimized for something that’s objectively measured, at the cost of goals that aren’t so easily codified.
Design instinct is a lot more than innate creative ability and cultural guesswork. It’s your wealth of experience. It’s familiarity with industry standards and best practices.
Overreliance on data to drive design decisions can be just as harmful as ignoring it. Data only tells one kind of story. But your project goals are often more complex than that. Goals can’t always be objectively measured.
#design#business#opinion#trends#work/productivity
·modus.medium.com·
Data-Driven Design is Killing Our Instincts