I forsee a really busy month coming out. Rushing out not just the typical academic workload but a whole flurry of events.
Lists its benefits and its problems. Expected something more of an explainer of what a DAG-based crypto framework would look like when implemented.
So a few of these tools exist. What makes this one unique?
Visible commitment: They articulate authentic commitment to diversity, challenge the status quo, hold others accountable and make diversity and inclusion a personal priority.
Humility: They are modest about capabilities, admit mistakes, and create the space for others to contribute.
Awareness of bias: They show awareness of personal blind spots as well as flaws in the system and work hard to ensure meritocracy.
Curiosity about others: They demonstrate an open mindset and deep curiosity about others, listen without judgment, and seek with empathy to understand those around them.
Cultural intelligence: They are attentive to others’ cultures and adapt as required.
Effective collaboration: They empower others, pay attention to diversity of thinking and psychological safety, and focus on team cohesion.
Level 1: The listener creates a safe environment in which difficult, complex, or emotional issues can be discussed.
Level 2: The listener clears away distractions like phones and laptops, focusing attention on the other person and making appropriate eye-contact. (This behavior not only affects how you are perceived as the listener; it immediately influences the listener’s own attitudes and inner feelings. Acting the part changes how you feel inside. This in turn makes you a better listener.)
Level 3: The listener seeks to understand the substance of what the other person is saying. They capture ideas, ask questions, and restate issues to confirm that their understanding is correct.
Level 4: The listener observes nonbverbal cues, such as facial expressions, perspiration, respiration rates, gestures, posture, and numerous other subtle body language signals. It is estimated that 80% of what we communicate comes from these signals. It sounds strange to some, but you listen with your eyes as well as your ears.
Level 5: The listener increasingly understands the other person’s emotions and feelings about the topic at hand, and identifies and acknowledges them. The listener empathizes with and validates those feelings in a supportive, nonjudgmental way.
Level 6: The listener asks questions that clarify assumptions the other person holds and helps the other person to see the issue in a new light. This could include the listener injecting some thoughts and ideas about the topic that could be useful to the other person. However, good listeners never highjack the conversation so that they or their issues become the subject of the discussion.
Saddening. And yet, we are all unconscious victims of bias.
Quite long-winded but the sheer grit and determination shines through. The ability to humble yourself and start from scratch once again can be such a cathartic and refreshing experience.
LESSON 1: OPEN STANDARDS SPARK INNOVATION AND GROWTH
LESSON 2: BUILD A SIMPLE SYSTEM AND LET IT EVOLVE
John Gall wrote: “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true. A complex system designed from scratch never works and cannot be made to work. You have to start over beginning with a working simple system.”
LESSON 3: DESIGN FOR PARTICIPATION
Likewise, we can be misled by the notion of participation to think that it’s limited to having government decision-makers “get input” from citizens. This would be like thinking that enabling comments on a website is the beginning and end of social media! It’s a trap for outsiders to think that Government 2.0 is a way to use new technology to amplify the voices of citizens to influence those in power, and by insiders as a way to harness and channel those voices to advance their causes. Participation means true engagement with citizens in the business of government, and actual collaboration with citizens in the design of government programs.
Perhaps most interesting are applications and APIs that allow citizens to actually replace functions of government, in a self-service analogue to Craigslist. For example, FixMyStreet, a project developed by UK nonprofit mySociety, made it possible for citizens to report potholes, broken streetlights, graffiti, and other problems that would otherwise have had to wait on an overworked government inspector.
LESSON 4: LEARN FROM YOUR “HACKERS”
But advances don’t just come from entrepreneurs playing by the rules of new platforms. Sometimes they come from those who break the rules. MIT professor Eric von Hippel has written extensively about this phenomenon, how “lead users” of a product push it to its limits and beyond, showing vendors where their product wants to go, in much the way that rushing water carves its own path through the earth.
There are potent lessons here for governments opening up access to their data via APIs. Developers may use those APIs in unexpected ways. This is a good thing. If you see signs of uses that you didn’t consider, respond quickly, adapting the APIs to those new uses rather than trying to block them.
LESSON 5: DATA MINING ALLOWS YOU TO HARNESS IMPLICIT PARTICIPATION
A Gov 2.0 analogue would not just be a “holy cow machine” for transparency; it might, for example, be a new, dynamic pricing system for Medicare. Currently, an outside advisory board makes recommendations to Congress on appropriate Medicare reimbursement rates. As David Leonhardt noted in the New York Times, “Congress generally ignores them, in deference to the various industry groups that oppose any cuts to their payments.” Leonhardt’s solution: an independent body, akin to the Federal Reserve, empowered to set reimbursement rates in the same way the Fed sets interest rates
LESSON 6: LOWER THE BARRIERS TO EXPERIMENTATION
But far too often, government programs are designed as though there is only one right answer, and with the assumption that the specification developed by a project team must by definition be correct.
You can conceive of the technology marketplace as a series of competitive experiments. But even within a single company, one of the advantages of webbased business models is the ease of experimentation. Companies routinely run A/B tests of new features on subsets of their users. They add and subtract features in real time in a process of constant improvement that I’ve sometimes called the “perpetual beta.”
Finally, it is essential for best practices — and even working code — to be shared between agencies of the federal government, between states, and between municipalities. After all, as Justice Louis Brandeis wrote in 1932, “It is one of the happy incidents of the federal system that a single courageous state may, if its citizens choose, serve as a laboratory; and try novel social and economic experiments without risk to the rest of the country.”
LESSON 7: LEAD BY EXAMPLE
If the government wants buy-in for government-run health care, we need the equivalent of an iPhone for the system, something that re-envisions the market so thoroughly that every existing player needs to copy it. I’ve suggested that an opportunity exists to reinvent Medicare so that it is more efficient than any private insurance company, and to make the VA better than any private hospital system. But being realistic, technology teaches us that it’s always harder to refactor an existing system or application than it is to start fresh.
PRACTICAL STEPS FOR GOVERNMENT AGENCIES
- Issue your own open government directive. San Francisco Mayor Gavin Newsom has done just that. You might consider his Open Data Executive Directive as a model.
- As Robinson et al. propose, create “a simple, reliable and publicly accessible infrastructure that ‘exposes’ the underlying data” from your city, county, state, or agency. Before you can create a site like Data.gov, you must first adopt a data-driven, service-oriented architecture for all your applications. The “Eight Open Government Data Principles” document outlines the key requirements for open government data. 36
- “Build your own websites and applications using the same open systems for accessing the underlying data as they make available to the public at large” (Robinson et al. again).
- Share those open APIs with the public, using Data.gov for federal APIs and creating state and local equivalents. For example, cities such as San Francisco (DataSF.org) and Washington, D.C. (Data.DC.gov and Apps.DC.gov) include not only data catalogs but also repositories of apps that use that data, created by both city developers and the private sector.
- Share your work with other cities, counties, states, or agencies. This might mean providing your work as open source software, working with other governmental bodies to standardize web services for common functions, building a common cloud computing platform, or simply sharing best practices. Code for America is a new organization designed to help cities do just that.
- Don’t reinvent the wheel: support existing open standards and use open source software whenever possible. (Open311 is a great example of an open standard being adopted by many cities.) Figure out who has problems similar to yours, and see if they’ve done some work that you can build on.
- Create a list of software applications that can be reused by your government employees without procurement.
- Create an “app store” that features applications created by the private sector as well as those created by your own government unit (see Apps.DC.gov).
- Create permissive social media guidelines that allow government employees to engage the public without having to get pre-approval from superiors.
- Sponsor meetups, code camps, and other activity sessions to actually put citizens to work on civic issues.
Okay are there any moral implications in this? I’m a bit baffled…
Not in one currently but i’ve seen this… frankly i can’t even remember what mine was like but some of these habits seem strangely reminscent
- The Map is not the territory
- Circle of competence
- First principles thinking
- Thought experiment
- Second-order thinking
- Probabilistic thinking
- Occam’s Razor
- Hanlon’s Razor — do not attribute to malice that which is more easily explained by stupidity
The language of hypothesis formulation was part of their process. Each week, Seven-Eleven Japan counselors visited the stores and asked salesclerks three questions:
- What did you hypothesize this week? (That is, what did you order?)
- How did you do? (That is, did you sell what you ordered?)
- How will you do better next week? (That is, how will you incorporate the learning?)
Now to apply this…
First-order thinking is fast and easy. It happens when we look for something that only solves the immediate problem without considering the consequences. For example, you can think of this as I’m hungry so let’s eat a chocolate bar.
Second-order thinking is more deliberate. It is thinking in terms of interactions and time, understanding that despite our intentions our interventions often cause harm. Second order thinkers ask themselves the question “And then what?” This means thinking about the consequences of repeatedly eating a chocolate bar when you are hungry and using that to inform your decision. If you do this you’re more likely to eat something healthy.
- Always ask yourself “And then what?”
- Think through time — What do the consequences look like in 10 minutes? 10 months? 10 Years? 1
- Create templates like the second image above with 1st, 2nd, and 3rd order consequences. Identify your decision and think through and write down the consequences. If you review these regularly you’ll be able to help calibrate your thinking.
- (Bonus) If you’re using this to think about business decisions, ask yourself how important parts of the ecosystem are likely to respond. How will employees deal with this? What will my competitors likely do? What about my suppliers? What about the regulators? Often the answer will be little to no impact, but you want to understand the immediate and second-order consequences before you make the decision.
- The desirability of a change (D): How much do you want to do the change?
- The value of a change (V): How much value does this change bring or how much does this help your users?
- The effort required to perform the change (E): How much work will the change require?
The equation is simple: D=V/E
There was a lot to cover but essentially the crux of being a good deliver is clear thinking, discipline and drive.
1. Align your products with how the world is changing. Taylor and Gibbs were able to predict how the technology sector was changing — e.g., moving away from individual productivity tools toward collaborative, team-based tools — and aligned Quip with those changes. This helped them launch the right product at the right time, targeted at the right market.
Take a look at your product and its place in your sector or vertical:
- How will broader shifts in technology affect your target market’s needs, positively or negatively? How can you align your product to leverage and take advantage of these shifts?
- Are there any opportunities you haven’t explored because you thought they were too ambitious? Quip wanted to effectively replace Microsoft Office — not exactly the easiest incumbent to beat. But Quip’s genuine innovation in combining work-based productivity with social functionality was brilliant, and an opportunity most companies overlooked or dismissed. How can you do the same with your product?
- Many founders spend too much time worrying about how their market is changing and completely ignore why their market is changing. Think about the last major shift in your industry. Why did this happen? Did you anticipate this shift, or did it take you by surprise?
2. Have a crystal-clear vision for your product. Timing was important to Quip’s success, but Taylor and Gibbs’s clearly defined vision of what Quip should be was the driving force behind the product. They knew exactly what they wanted Quip to be from the outset, which helped them stay focused on achieving ambitious goals — e.g., developing for multiple platforms in multiple languages very early on.
Think about your own product and be honest:
- Is your current product significantly different from the product you set out to build? If so, how and why did your product diverge from your original vision? Is your product better or stronger as a result?
- Taylor and Gibbs may have had an ambitious vision for Quip, but it was always tied to specific, tangible problems that were prevalent in almost every workplace — too many meetings, too many emails, too much time wasted. How closely does your product vision align with specific customer problems?
- There’s no shame in pivoting, and many wildly successful companies have done so — sometimes more than once. However, it is important to evaluate why a pivot was necessary. If you have pivoted from your initial idea, was your original vision too ambitious or too impractical? If you could go back in time, how would you approach your situation differently?
3. Consider your options carefully in the event of a possible acquisition. Quip was a smart, highly strategic acquisition for Salesforce, but Quip could have easily remained an independent, likely highly successful company. Salesforce’s considerable resources have likely made Quip’s mission to penetrate the enterprise a little easier, but they certainly didn’t have to sell.
If an acquisition is a viable or possible option for your company, answer the following:
- Which companies would be good, logical candidates as buyers for your product? Why?
- If you sold your company to, say, Salesforce or a similar company, how would your users benefit? Would you be able to preserve your company’s culture? How would taking care of your customers differ from your current approach to customer success?
- Many founders focus on what they hope to gain from an acquisition, and understandably so. But what would you stand to lose if your company were acquired by a much larger, wealthier organization? How much control or direct input would you be willing to sacrifice to close an acquisition offer?
What they did: Build a model that labels issues and launch it as a product!