More on this book
Community
Kindle Notes & Highlights
claims by using the elements of analysis we covered earlier. These might include: Using inductive and deductive reasoning, syllogisms Stating your hypotheses and the reasons for it Stating your method to proceed in proving your hypotheses Stating the metrics you’ll use to measure your progress and how you’ll source them Probabilities and ranges, confidence levels
The inverse of the ad hominem fallacy is the blind authority fallacy, which is equally common, especially in business. It states, “A is the ultimate authority. A made claim B. Therefore, claim B is true.” It mistakes a military leader, business leader, or impressive corporation as a sufficient condition or valid and sound premise unto itself. This is false. The businessperson’s version of this is to cite someone’s title as the reason they are right. We sometimes see this referred to as the HIPPO: the Highest Paid Person’s Opinion. The technologist’s version of this is to substitute “big
...more
Avoid blind authority! Set your path
Sometimes called “converse accident,” the hasty generalization is a common fallacy for inductive reasoners to misstep into. It is very common for technologists as well, who look at data and are frequently pressed to give answers before having enough time to collect relevant samples. Hasty generalization means making an unjustified conclusion based on very limited data, an anomaly, one special example, or biased evidence. You can recognize this fallacy because it always proceeds from the particular to the general. Examples:
There are many more logical fallacies (a frightening number, actually—it’s amazing anything works at all given how frail our arguments can be), and many good books devoted entirely to the subject. A really fun read on logical fallacy is called How to Win Any Argument: The Use and Abuse of Logic by Madsen Pirie (A & C Black). But being armed with these popular ones should go a long way.
In this pattern, we’ve covered the three elements of a strong argument: the logical, ethical, and pathetic appeals.
3 elements of strong arguments
When the good leader’s work is done, his aims fulfilled, the people will all say, “We did this ourselves.” Lao Tzu
After you’ve done the work of crafting a strategy with tools we discuss here, you will be faced with a meeting to present your findings to the board of directors, the senior leaders in your department, or some other deciding managerial body, depending on your place in the organization and the scope of your work. This pattern is about how you handle that meeting. You can have the greatest strategy in the world, but if you let this meeting get away from you, you can really damage and dilute the chances for your good work to thrive.
What’s in it for me? They immediately start calculating. How does this message affect me, my teams, and my chances for success; encroach on my territory; or signal the coming of some change that I might find incredibly disturbing or rife with opportunity?
Think about what is in it for me
What you need is a fait accompli. Put simply, you have the meeting before the meeting, in a bunch of little meetings, to line everyone up. Then the big meeting where everyone is ostensibly there to hear
You need to have the meeting with each of the key stakeholders, individually, before the meeting, to get them on board separately.
In essence, you need to suck the drama out of your own meeting, before it happens, so no one else can add their drama and undermine your work. If you don’t do this, some person who is the most threatened,
But unless you’re Steve Jobs, this is probably not a great approach. As the business cliché goes, you want to be positioned not as the “sage on the stage,” but the “guide at their side." When
Then, like a salesperson, ask them bluntly, “If we incorporate these changes, does this direction make sense to you? Is this something you can support?” Recognizing later that they already have signaled their clear approval to you, they’ll be loath to reverse that publicly at the big meeting.
Your strategy will get approved, and you will have made a fait accompli of the proposal. Nicely done. This pattern is not about manipulation.
The plan is how we state the way out. This is the “therefore” moment.
ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so. after Josh Billings
When you are faced with solving a scalability problem within an application, consider the very meaning of “scalability.” Consider it across contexts. What other functions constitute the set of conjuncts of propositions that make up the domain of discourse?
The category that this problem is in, the set this is a member of The associations in which this problem arises in other contexts
When looking at the problem
- local
- The category that this problem is in, the set this is a member of
- The associations in which this problem arises in other contexts
When given a problem, we seek solutions and seek to find problems in our own history that match this one. We are implicated in our own histories, which can harm as much as benefit us. We solved X this way in the past, so we might be able to apply that to new problem Y. We assume constraints, taking as necessary what may be contingent. Because of the way we bound the problem within a domain of discourse, we miss rich signals from other nearby clusters. We can upgrade to the latest version of some software and increase capacity on some server to solve a local problem of this bug or that
...more
Don’t just jump into the problem, tackle what we are attempting to address
semiotics
Liskov substitution principle Objects of a derived class should always be substitutable for a parent
The project is a system. You can apply what you know from designing technology systems to business systems, like structuring the processes or the projects. The valued properties are similar across all of these system types. When you’re designing a process, keep the architecture qualities in mind: I know of at least one Infrastructure department I’d love to have learn the principle of interface segregation.
Summary In this chapter, we looked at several innovative ways to make a logical, persuasive argument and weave it into how you show the value and impact of your strategy. We examined the following patterns: 30-Second Answer (see “30-Second Answer”) Rented Brain (see “Rented Brain”) Ars Rhetorica (see “Ars Rhetorica”) Fait Accompli (see “Fait Accompli”) Dramatic Structure (see “Dramatic Structure”) Deconstruction (see “Deconstruction”) Scalable Business Machine (see “Scalable Business Machines”)
up its radar-making tool so that you can generate your own radar using your own categories and list of items. This is a terrific way for you to visualize and share with your teams how you’re thinking about the set of tools out there. Depending on your culture, this can be more of a dictum or more of a guide. The radar is not merely a frozen perfect tech future represented in boxes and arrows, but shows the tools and techniques together and presents them in a clear, easy-to-understand framework, and presupposes that you will evolve and update it. The radar is a set of concentric circles
...more
What should be on our radar
Sometimes we’re brought into conversations with the business development folks who do mergers and acquisitions. We can use the Build/Buy/Partner pattern as a way of framing our conversations with them. It’s important to align these decisions with your technology strategy. Let’s take an overview of each of the three options in turn.
The Buy option represents the quickest time to market. You still have to face integration challenges, but not on top of making the system in the first place.
This is an assessment of the technology and operational aspects of the target company. It’s very important, because it’s used to determine if the company should be bought at all.
The Template There are five primary sections to the Architecture Definition template I use: Metadata or Front Matter Business Architecture Application Architecture Data Architecture Infrastructure Architecture Metadata
building. Such a template could look like this: Major Features Describe the purpose of the system and its high-level feature set. What will this system do? What current capabilities can we draw on? What must be repurposed or modified? Strategic Fit What aspect of the business and/or technology strategy does this effort and design support? How does it help realize strategic goals?
Strategic, assumptions
Governance How will the project be governed? Is there an executive steering committee, or a responsible stakeholder committee? What cadence and form will they take, with what explicit purpose?
Data Maintenance Describe how data will be maintained, data retention policies, scripting to offload, data restoration. How will data be populated for different environments for this application? Will data be truncated? At what interval? How will data be encrypted? Are there GDPR or PII/PCI requirements to be stated for dev teams or infrastructure admins?
presented here: One-Slider (see “One-Slider”) Use Case Map (see “Use Case Map”) Priority Map (see “Priority Map”) Directional Costing (see “Directional Costing”) Technology Radar (see “Technology Radar”) Build/Buy/Partner (see “Build/Buy/Partner”) Due Dilligence (see “Due Diligence”) Architecture Definition (see “Architecture Definition”) The next chapter will show you different types of slide
The whole interest of reason, speculative as well as practical, is centered in the three following questions: What can I know? What ought I to do? What may I hope? 18th century German philosopher Immanuel Kant,
