The Trusted Advisor 📚

The Trusted Advisor is a book focused on trust and relationships in professional services but feels applicable to any work partnership.
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?
The Trusted Advisor is a book focused on trust and relationships in professional services but feels applicable to any work partnership.
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.
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.
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:
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.
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.
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:
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.
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.
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.
Dan Abel:
Feedback is someone is trying to help. Listen. Then ask questions - to gain understanding of their point of view.
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.”
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.
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.
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
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.