Every software framework you've ever used is in the abstraction game: it takes a general-purpose tool, picks a specific set of common use-cases, and puts up scaffolding and guard rails that make it easier to build those specific use cases by giving you less to do and fewer choices to think about. The lines between these three are blurry. Popular abstractions become standardizations.

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.

You need to make your case for what the problem or opportunity is—most often validated with at least directional data and/or research insights—and why your specific solution could work. You need to ensure it weaves into broader company initiatives as well as goals for your team and org. And you need a plan to get your product out there in a timely manner along with ways you'll further learn and validate your approach. An executive team won't be thrilled to hear you want to spend a year building something based solely on a hunch.

People hire services not just based on what they can do but how it makes them feel. Quality has a direct relationship to that. Quality products can take your users from "I'm merely using this thing to accomplish a task" to "this is something I love using and I'm telling everyone I know about it."

To maintain a shared, company-wide understanding of the company's specific stance is on quality, how does quality get rewarded, celebrated and prioritized? Is there a process in place for delaying a release and having a retro when the quality bar slips? Who decides when quality has slipped? Who's accountable for addressing it?

What does quality mean to them? How does it tie into the career ladder, promotions and prioritization frameworks? Do they focus more on execution speed over quality?

Is quality baked into the normal product development process, or is it often relegated to low priority "polish" tickets that pile up.

Do different roles (like engineering, product, design) have different motivations for getting their work done? This, again, ladders up to what the org thinks about quality.

Liberal use of "MVP" or "it's just an experiment". Does the team use those terms to skirt around typical quality standards and ship something subpar? Does everything worked on, even experiments, demand the same care as a more mainstream release that goes out to all users? That's a slippery slope because it's all too easy to simply ramp up that experiment to 100% of your users if it performs well, without addressing quality issues that were neglected prior to shipping to that initial set of users. No one wants a slice of cake that is just a piece of the bottom layer. You need to have a taste of each layer with each bite, including the icing. So even if it’s not your entire vision, it has all the right pieces involved. Ditch the term MVP and use SLC (Simple, Lovable, Complete).

I’m not saying designers, PMs and engineers should be holding up their projects for months to “get it right”. I'm saying that teams should be working in a way where everything is considered and there's a framework for identifying, discussing and prioritizing quality-related issues so that quality is a bit less of a sisyphian task.

Does your team have the skills and incentives to identify and adequately fix those issues? Does the organization continually reinforce and celebrate work that ladders up to quality, craft and great design?

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.

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."

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.

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.

Purpose is the bedrock of a motivating role, but even if the purpose is there, disengagement can result from two other key issues: Lack of growth opportunity, or A poor feedback/improvement loop.

One of the top reasons for distrust and disengagement among employees is feeling like their needs are unmet, their feedback is not heard, and things will not improve

People have been known to put up with fairly egregious situations if they can see incremental progress toward improving them.

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

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.

Let’s say you present 3 directions to a client: directions A, B, and C. These are our initial 3 branches. You have a client review, direction C is the winner, and so you iterate again. 3 more branches: C1, C2, and C3. Another review, another winner, another round of iterations: C2.1, C2.2, C2.3. Branch out, choose one, zoom in, branch out, repeat.

Sometimes, the design process requires us to zoom out. Let’s say you present those 3 creative directions, A, B, and C, but nothing lands. Back to the drawing board. You might keep pushing forward with branches D, E, F. Nothing lands. You’re forced to zoom out and realize that you’re not even on the right parent branch.

Sprints don’t help organize things, they’re not a useful organizing tool, and if we were all honest with each other then we’d admit they’re designed for managers who don’t trust their employees

Good teams don’t need sprints to get good work done. They don’t need to point tickets or file receipts away once something is complete. This always leads to an endless backlog of crap anyway which is also a waste of time since they too only serve managers who are scared to say “ah yes, we have listened to this complaint and we believe it’s not important.” That’s what a backlog is; a list of useless tasks that makes people feel better.

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.

So using that hook of “simplicity”, the best advice for “doing agile” is: Read the manifesto Figure out what makes you happy. And do that.