Bytes that get stuck in your teeth.
Jason Yip:
Good relationships facilitate future support and creates advocates. Being able to get something done is not just about your individual capability but also about your influence with the stakeholders and teams that you depend on.
The art of naming what’s happening in the room to get things back on track.
Mary C. Murphy on the culture around growth mindsets.
Johanna Rothman:
But instead of placating the managers and trying to estimate, consider starting with this question:
How do you plan to use this information?
That might offer you ways to answer the question that does not require any prediction.
Also read part one and part three.
The Trusted Advisor is a book focused on trust and relationships in professional services but feels applicable to any work partnership.
I’ve collected a few choice quotes below.
To make anyone believe something about you, you must demonstrate, not assert. What you claim about yourself, your colleagues, or your firm will always be received skeptically, if it is listened to at all. In Emerson’s words, “Your actions speak so loudly, I cannot hear what you are saying,”
We must listen effectively, and be perceived to be listening effectively, before we can proceed with any advisory process. Cutting to the chase without having earned the right to do so will usually be interpreted as arrogance.
…if the listener breaks up our sense of story (insists on interrupting, or rearranging, or imposing his or her own sense of story line), the meaning we intend is disrupted. It feels inappropriate when someone jumps to a conclusion, or misses a connection, or gets things out of sequence. All these are forms of not “getting it.” Good listening respects the speaker by respecting the sequence of the story he or she chooses to tell us.
At the core of earning someone’s trust is convincing them that you are dealing with them as a human being, and not as a member of a group or class or subset. Accordingly, as you listen to a client talk, the question on your mind should be, “What makes this person different from any other client I’ve served? What does that mean for what I should say and how I should behave?”
Unfortunately, this is hard work. The natural tendency for most of us is to do the exact opposite: We listen for the situations we recognize, so that we can draw upon past experience to use the words, approaches, and tools that we already know well. It’s the way most of us work, but it doesn’t always serve us well.
So much of our time is spent focusing on ourselves, and so much of other people’s time is spent focusing on themselves, that it is a rare and surprising event whenever someone breaks the veil. Sincere interest in another person comes across strikingly simply because it is unusual.
One of the biggest mistakes that advisors make is to think that their client always wants their advice. This is dangerously wrong.
…
What the advice receiver wanted was a combination of a sympathetic ear, emotional support, an understanding of the difficulties faced, and the opportunity to collect his or her own thoughts by talking them through in a non-threatening environment.
It’s near impossible for any professional to hide his or her true motives, whatever they may be. And if those motives are rooted in naked self-interest, they will be duly noted and reciprocated. We are not loyal to self interested people we don’t trust them. Which means we are always likely to leave them for a better price-or for someone we actually trust.
Which in turn means longterm success is compromised by such behaviour. And since the long term is nothing but a series of short terms, short-term results themselves are being harmed, not improved, by slavish adherence to short-term goals.
The truth is, both long-term and short-term results are maximised by long-term behaviour on our part. The old Goldman Sachs mantra expressed this well: “We are longterm selfish.” It is in the long-term that our goals and our clients’ goals merge and that merging reveals itself over a series of short terms.
We suggest that there are five distinct steps in the development of a trusted relationship. In this chapter we will define each of these In the succeeding chapters, we will explore each stage in detail.
Expressed in their simplest form, the five stages are:
- Engage. “Let’s talk about…”
- Listen. “Tell me more…”
- Frame. “So the issue is…”
- Envision. “Let’s imagine…”
- Commit. “I suggest we…”
I was having an after-work chat with Simon a while ago. We were discussing how we can cultivate a more resilient culture at work, specifically enhancing the capacity of individuals to constructively handle feedback.
He mentioned that he’d been reading Thanks for the Feedback which emphasises that, contrary to popular advice, it’s better to focus on helping people get better at receiving feedback rather than giving it.
This reminded me of a design principle in software engineering called the “Robustness principle” or “Postel’s law”. This principle guides how software systems should be designed to communicate with each other.
It’s often summarised as: “Be conservative in what you send, be liberal in what you accept”.
It felt like when it came to feedback and people working better together we were talking about the same thing, i.e. Postel’s law for people.
This makes me wonder what other software design principles might be useful when applied to people.
Jessica Kerr:
There’s collaboration overhead to get interrelated pieces working together. Design, product, and engineering don’t “coordinate,” they collaborate. They work together every day, on a single output.
…
Then there’s alignment overhead. Alignment means we all know why we’re doing this work. This shared understanding lets us make the thousand detailed decisions of the day in ways that support the real purpose of our shared effort.
Product development is a team sport mostly carried out through meetings and conversations.
Two practical things you can try to help create clarity and reduce chaos in particularly complex conversations:
These might seem obvious, but they don’t happen as often as I’d hoped.
Do you find yourself in meetings with multiple people discussing complex topics?
Does a series of tangents and related issues emerge as the conversation progresses?
In the end, are you unsure of where things are at?
Are you confident that you understand the situation but are uncertain if it’s the same for others?
Taking complex, meandering conversations and providing clear, structured summaries throughout is incredibly valuable 1.
I think of each summary as incrementally locking in consensus or taking a collective step up the ladder of inference, as described in Crucial Conversations.
Sometimes the state of play seems obvious, and therefore it feels unnecessary to summarise. I suggest pushing through this feeling and doing it anyway to ensure alignment and avoid pluralistic ignorance.
As soon as you leave the conversation, you are immediately misaligned again 2.
You can reduce this misalignment by sharing a written conversation summary including decisions and actions.
Given the volume of conversations leaders tend to be in, capturing the outcomes becomes essential for rebooting context later or remembering which decisions were made and why.
This can be as simple as listing the facts established to date, assumptions, trade-offs available, or agreed actions. ↩︎
It’s ok. This is normal. Read more on autonomy and alignment from Jean-Michel Lemieux. ↩︎
It’s not particularly useful debating the value of anything in isolation.
Considering programming languages, tools, processes, or product decisions on their own is a mostly philosophical exercise.
Things start to have meaning when we assess them against other available options.
That’s where the rubber hits the road, and things get spicy, friends.
A tool from Hashicorp for adding document review and collaboration workflows over Google Docs.
Dan Rockwell:
Smart people have lousy meetings. Keeping meetings on track is like organizing a barrel of hummingbirds.
I especially like the “fill in the blank statements” strategy.
Cam Daigle:
I’m hoping this system helps you have better meetings – that the people running the meeting feel like it’s worth their time to run them, and that the people in attendance feel like their presence there matters.
Richard Mironov:
Prioritization is more than an analytical/intellectual exercise. It’s an organizational challenge with natural disagreements among stakeholders. Product leaders need to think about motivating the right kinds of participation and addressing the emotional issues that arise. Spreadsheets and models are necessary, but not sufficient.
Kara Cutruzzula:
Why is defensiveness such an obstacle to collaboration? When we get defensive, “we put way more into self-preservation than we do into problem-solving,” Tamm says. “We’re trying to prove that we’re right rather than search for creative solutions.” When this happens in a workplace, it can be a recipe for chaos and failure.
…
OK, now that we understand the dangers of defensiveness, here’s what we can do about it. You can start by learning to spot the warning signs of defensiveness in yourself. When you feel yourself experiencing them, pay attention and take action. According to Tamm, here are the 10 most common warning signs that you may be getting defensive: A spurt of energy in your body; sudden confusion; flooding your audience with information to prove a point; withdrawing into silence; magnifying or minimizing everything; developing “all or nothing” thinking; feeling like you’re a victim or you’re misunderstood; blaming or shaming others; obsessive thinking; and wanting the last word.
Jason Yip:
- Authority-focus: “Not my job, not my problem.”
- Responsibility-focus: “What is the right thing to do? How can I help?”
Responsibility-focus reflects the belief that “we’re in it together”.
Jason Yip:
When you work in team-based product development, you will need to deal with drift.
By drift, I mean an increasing mismatch in understanding about:
- the problem we’re trying to solve;
- the solution we’re attempting;
- each other and how to relate.
- Drift in shared understanding creates confusion, mistakes, and generally a bad working experience.
…
Daily standups ensure understanding is integrated across a team at least once a day.
Suggestions for how to make meetings worthwhile.
Jessica Kerr:
This is participatory sense-making. When we want to work on a thing together, and we need a shared understanding to do it right, then everyone gets to participate in constructing that understanding.
…
Shared understanding doesn’t come from “I share my understanding, and you adopt it.” it comes from “I share my knowledge, you share yours, and we construct a new understanding together.”
Jason Yip:
Alignment and autonomy are not two ends on a scale but two dimensions on a 2x2 matrix.
Andrew Harmel-Law:
The moves in software delivery towards ever-increasing team autonomy have, in my mind at least, heightened the need for more architectural thinking combined with alternative approaches to architectural Decision Making.
Ensuring our software teams experience true autonomy raises a key problem: how might a small group of architects feed a significant number of hungry, value-stream-aligned teams? Why? Because in this environment Architects now need to be in many, many more places at once, doing all that traditional “architecture”.
…
The Rule: anyone can make an architectural decision.
The Qualifier: before making the decision, the decision-taker must consult two groups: The first is everyone who will be meaningfully affected by the decision. The second is people with expertise in the area the decision is being taken.
Pete enumerates some patterns of teams and code ownership.
Being right was something that we were taught was the ultimate pinnacle of knowledge, and there’s a reason, culturally, that so many of us care so deeply about being right. But it’s time to get rid of that. It’s no longer the currency that separates who does the really great work in life from who doesn’t.
James Clear:
Convincing someone to change their mind is really the process of convincing them to change their tribe. If they abandon their beliefs, they run the risk of losing social ties. You can’t expect someone to change their mind if you take away their community too. You have to give them somewhere to go. Nobody wants their worldview torn apart if loneliness is the outcome.
RC has four social rules. They help create a friendly, intellectual environment where you can spend as much of your energy as possible on programming.
The social rules are:
- No well-actually’s
- No feigned surprise
- No backseat driving
- No subtle -isms
One thing that often confuses people about the social rules is that we expect people to break them from time to time. This means they’re different and totally separate from our code of conduct.
Dan Abel:
Feedback is someone is trying to help. Listen. Then ask questions - to gain understanding of their point of view.
I also enjoyed the idea of treating Slack more like Twitter.
Stuart Sierra:
The purpose of a meeting, then, is not to convey information efficiently. It is to force an audience to pay exclusive attention to one thing, to get that creative focus pointed in a particular direction.
A look at negotiation and how to avoid the pitfalls associated with debate.
Roman Imankulov:
Rough consensus relies on the distinction between two types of objections:
“Not the best choice” feedback: “I don’t believe Solution A is the best choice, because XYZ. I believe Solution B would be better, but I accept that Solution A can work too.”
Fundamental flaws: “I believe Solution A is unacceptable because XYZ.”
…
A chair who asks, “Is everyone OK with choice A?” is going to get objections. But a chair who asks, “Can anyone not live with choice A?” is more likely to only hear from folks who think that choice A is impossible to engineer given some constraints. The objector might convince the rest of the group that the objections are valid and the working group might choose a different path.
Gregor Hohpe:
First and foremost, autonomous teams need to live with the consequences of their decisions.
Yep.
David Gasca:
“Silent Meetings” are meetings where most of the time is spent working and not talking. When done correctly most of the meeting is spent silently working together.
Jessica Kerr:
If you think about it this way, you might recognize that in many software teams, our limitation is not how much we can do, but how much we can know. To change a sufficiently complex system, we need more knowledge than one or two people can hold. Otherwise we are very slow, or we mess it up and the unintended effects of our change create a ton more work.
Henry Ward:
I have long felt there is a shadow org chart, much like a shadow economy, where employees trade ideas, give direction, offer help, and spread culture. This shadow org chart is built bottom up by employees and is very different from the top down hierarchical org chart set by me.
I wanted to map this shadow org chart and find employees who have disproportionate levels of influence relative to their hierarchical position. I also wanted to see the influence centers and decision makers, and the directional current between them and the rest of the company.
Some fascinating analysis and data visualisation of a graph of influence.
John Allspaw:
In my experience, when an architecture review brings attention to a problem and proposed solutions from multiple perspectives, decisions become less controversial. When a decision appears to be obvious to a broad group (“Question: should we (or should we not) take backups of critical databases? Decision: Yes.”) how a decision gets made almost disappears.
James Ross presenting concept maps.
Good tips for structuring your Slack channels.
What is the CAP theorem for teams? Moving together balanced against moving forward.
Envato teams are responsible for the operation of the systems they build.
My team is trying something different to help onboard new people. We’re creating a set of infrastructure koans for them to complete. The koans are tasks that—once completed—will help folks navigate our infrastructure and systems, and thereby acquire skills that are essential for supporting our services.
When someone joins the team a new issue is created in one of our team’s Github repos using the koans document as a template. Once the new team member has completed all of the koans they are added to the on-call rota and assigned a buddy who can help if things get tricky whilst on call.
The koans are not meant to be layed out step by step unless the task is complex or requires unusual knowledge. We hope this encourages folks to explore and internalise more than they would if following a todo list.
Set yourself up on PagerDuty and read through past incidents.
View metrics for each of our systems in New Relic.
Look up each of our services in Rollbar.
Open the AWS CloudWatch console.
Open the AWS ECS console.
Look through our Stackmaster templates and find the results of building stacks from them in CloudFormation.
Access our ELK cluster and run some queries.
Run queries against our production database replicas.
Decrypt some database backups.
SSH into various servers in our infrastructure.
Chris Beams:
A properly formed git commit subject line should always be able to complete the following sentence:
If applied, this commit will your subject line here
For example:
- If applied, this commit will refactor subsystem X for readability
- If applied, this commit will update getting started documentation
- If applied, this commit will remove deprecated methods
- If applied, this commit will release version 1.0.0
- If applied, this commit will merge pull request #123 from user/branch
Mike Caulfield:
Wiki is a relentless consensus engine. That’s useful.
But here’s the thing. You want the consensus engine, eventually. But you don’t want it at first.
It’s funny, I was looking over this keynote last night, and I saw this line and realized — this is the simplest explanation of federated wiki.