Socratic Method for Advocacy

In disassembly of how I approach a zero-knowledge situation, a few key dynamics emerge. The goal of this simple framework is to accelerate the bond-forming process of dialog between individuals.

Not everyone has an appetite for the full menu of techniques here, and right-fitting takes sizing up others in real-time, which itself takes practice. If you’re really interested in how to have more effective conversations that leave all parties feeling positive, this is what I can currently offer.

  • Introductions
  • Exploratory Listening
    • Open-ended questions (a.k.a. “double-clicking”)
    • Challenging to understand how topics relate and handling skills
    • Confirming what was shared with close-ended questions
    • Synthesizing the crucial point
  • Identifying the “as-is” current state
    • Share “the Summit”
    • Assess the journey to date
    • Materialize motivations (unearth drive)
  • Planning the “to-be” desired state
    • Identify milestones, past and future
    • Hunt for and prioritize gaps in order of risk to reach the summit
    • Summarize approach and obtain permission
  • Co-develop a plan of action
    • Goal-Strategy-Objective-Tactic
    • Visualize the timeline to reverse-engineer milestones
    • Socialize with key stakeholders


Be cordial, clear about your role, short about your background, and quickly move to questions that help the other person(s) engage about themselves.

Present well. Shave, brush your teeth, wear a bit of a smile. Smell like someone you’d want to be around. Be attentive, particularly in the eyes, and suppress the urge to look like you’re anywhere else but this conversation right now.

Make sure that the person has time to talk a little. If not, politely ask when. If so, ask them how they arrived here, where they’re headed, and what’s got them going this direction. Build a basic rapport in the first few moments. Start off well and build on the previous moment at every opportunity

Exploratory Listening

Ask far more questions than the number of statements you make. Extroverted learning prefers information you don’t know over suppositions you could make alone.

Use open-ended questions when you want to explore directions. If you don’t know enough about what someone’s describing, open more windows. When the way of conversation is unknown, let them talk and learn how they communicate. There’s a lot of ‘meta’ information in human speech.

It’s important to challenge people, in no abrasive manner, but through asking how the current conversation point or branch relates to another topic or branch. The dichotomy of human behavior is that what is unknown represents simultaneously a source of both intrigue and fear. Questions can either encourage people to engage or to retreat, and our job is to engage.

Asking a question that someone doesn’t have an answer for leads to insight no matter what. How someone deals with unknowns will become useful later. When the question is right-timed and right-fit to the context, people without an answer are likely to explore with you. Poorly-timed or out of context, a question where no one has the answer feels awkward and often causes people to retreat.

When something seems very important, narrow down the scope of the questions you ask, never coerce. Close-ended questions confirm that what you think you heard was actually what was said. Don’t ignore non-verbal cues. Look for expressions of emotion surrounding quantities. Form a mental map of how these points affect their recipient and which seem relevant to them, not just you. Verify their relevance to others with close-ended questions.

Once a branch of exploration is sufficiently developed, synthesize the crucial point uncovered back into the main theme of the conversation. By understanding it’s impact, you can bring the point of the branch back to the goal of the conversation: to understand and support what the person is currently working on, suffering from, or driving towards.

Anyone can voice the crucial point, but it’s better if it’s someone else. You don’t have to be the one with an answer. This is why being curious about their perspective is so incredibly effective. Questions (open or closed) guide the conversation, even though people tend to think that an idea is original and their own simply because they voiced it. When someone thinks the idea is theirs, they tend to champion it with banners and bugles. Questions help steer champions in the right direction.

Identifying the “as-is” current state

The first move in any consultation should be to gain situational awareness. In other words, qualification of what dynamics and decisions are currently in place. Before a hypothesis and plan of action can be formed, observation.

To make broad and holistic observations, you must share the summit. As the landscape of context emerges from your listening expedition and as you process that landscape together into a shared construct, a key state will emerge, “what we have accomplished so far.” This is often coupled with pains and challenges regarding where the person currently is in their journey. Point and click with the camera in your mind because later we’ll be doing a before-and-after photo collage. The highest point achieved is a summit, even if it’s not the tallest peak visible.

You may need to know more about how they arrived at their current summit in order to fully flesh out gaps in context. This sense is highly subjective and experientially developed, so practice earning the right to get to this point. It’s important to step back and assess their journey every so often. This helps to uncover information gaps.

These gaps of context, though you may be the one to bring them up, must be accepted by others before they can be addressed. You can’t convince someone of a solution if they don’t think there’s a problem. And if something really isn’t a problem, it’s important for you to know that too. This is just another form of permission. The best way to ensure people show up to a party is to bring them with you.

Equal parts collected context and ‘meta’ (appetite, capabilities, deficiencies) makes for a very good peep into what motivates someone, either to stay in the current state, migrate to a future state, or even drive a future state. Motivations are imperative to materialize about others. An accurate understanding of someone’s motivations is worth more than developing a trust between you and them.

Planning the “to-be” desired state

Moving from what is to what could/should be the summit, start with our friend, an open-ended question, about where they want to be. In a group, this may get complicated; everyone communicates differently, and everyone has a different perspective. Quantize. Start with one person at a time. Give them non-verbal cues about length, but let them finish. The smaller the group, the easier this process is.

With a shared vision of the future summit, ask what it would take to get there. Searching for important, measurable future achievements is called identifying milestones. Again, not something everyone knows up front, and while some people have immediate intuitions or ideas, others take time to form their thoughts and answers. Since humans are notoriously bad at predicting the future, extrapolating future milestones may be difficult. If stuck, revisit past milestones, the ones that brought them to the current summit. This will help form a ‘meta’ understanding about how people categorize just-busy-work from notable achievements.

Make sure that the flow of questions to answers at this stage is 100% you questioning to 100% them answering. Questions may come up, but anything can be put in the “parking lot” provided it is suggested politely by you and agreed to by them.

With a set of milestones laid out, reorder them based on which events are dependent upon others. Ask about which milestones enable other milestones. Build the most efficient decision tree. As always, pause at junctures that feel important to obtain agreement. For those that don’t obtain consensus, circle back once, but otherwise parking lot it to keep the conversation flowing in the forward direction.

Now that you have a map of the landscape and have sketched out a path to the new summit, hunt down gaps (unstated objections, parking lotted details, well-known deficiencies) to arrive at MECE (mutually exclusive, collectively exhaustive) on a list of variables that exist between knowns. There will always be another iteration, so “exhaustive” simply means when people seem like they are happy with moving on.

With this list of gaps, ask how people would prioritize them. Root the conversation in terms of establishing priority based on relative risk to achieving the milestones and accomplishing the goal, getting to the summit.

There is no one right answer so long as those in the conversation express their perspectives on what order things should be prioritized. The how and the why they prioritize things the way they do is not key to this logistics exercise. Though useful meta information about individuals, justifications and disputes drag down the goal, which is alignment and on an approach to confidently arriving at positive outcomes together.

With a sense of how to prioritize milestones and gaps, circle back verbally to summarize the approach to moving from the old summit to the new one. This should take no more than 60 seconds. By now you should have mentally wordsmithed the goal, the milestones, and the approach such that you can do this. Those involved in the conversation up to this point will very likely unanimously agree because the summary incorporates their perspectives and terminology. When you do this effectively, you fade into their view of how to accomplish the goal. You are part of their team. You’re in.

Co-develop a Plan of Action

With all this context and alignment under your belt, it’s time to whip out some artisan management tools and have at it.

Crystalize the new summit into a single statement/slide/executive summary structured as a Goal-Strategy-Objective-Tactic (GSOT) framing. This progression properly organizes information in an approachable hierarchy that stakeholders and sponsors can grok quickly. Everything in it will be defensible because it came from the people that know how to accomplish the new goal and they’re already aligned with the details.

There typically should be only one goal, otherwise, the approach serves more than one master and the purpose of the objectives become muddied. An approach (or strategy) should express a strong point-of-view about the objectives that is fundamentally different from the prior approach which led to the current summit, even if the prior approach was good at decision time.

Every leg of the journey requires a pivot to ensure the direction is correct. Once a GSOT is constructed, make it easy for humans to visualize the timeline of objectives and key tactical events that support forward motion. These should be expressed in relative timeframes. Ranges, not absolute dates/times, are best at this point.

Reverse-engineer where/when to place milestones progressively. Start by placing the biggest rocks in dependent-events order, then layer in tactics that support various objectives. Adjust as necessary when tactics are tight (risk of slippage) or clustered too closely together (work bottlenecks). Do this with one slide, and you have the most effective meeting with an executive sponsor you’ve ever had.

Finally, with your ducks in a row, with everyone aligned, it’s time to socialize with stakeholders one at a time. Don’t present an idea for the first time in a boardroom. Objections are a fixture of the boardroom, so make it hard for them to maximize negative impact. Start with individual stakeholders. Do this under the auspices of collecting feedback, but then actually incorporate the feedback so you’re not a liar.

Pick your early stakeholder reviews carefully. A troll will turn around and proclaim your incompetence, but people with the most to gain will become your champion army when it comes time to fight the trolls. I wish you zero trolls, but living under bridges makes it hard to see them in advance.

On a Personal Note

The narrative above is a reflection of my observations and collaboration with technical engineering teams, boardroom executives, investors, sociologists, bartenders, and wolves. I broke my finger pretty badly two months ago which helped me deeply understand what would really hurt someone else. Likewise, as we exercise empathy and effective patterns of communication, we better understand how they improve us and their importance in our work together.

Thank you for your time, and as you may guess, I’m also on a journey. We all are. If you found anything in this post useful, connect with me so we can journey a bit together.

What a Site Reliability Engineer Really Does…in DevOps

We really, really build ourselves into a corner with the internet and mobile and cloud and Agile “at scale”. Good news is, we’re engineers that can invent ourselves out of anything, or at least that’s what’s made all this money so far.

What Is a Site Reliability Engineer?

Srsly. Wikipedia. Too lazy? Fine, from Wikipedia (please donate):

Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to IT operations problems. The main goals are to create ultra-scalable and highly reliable software systems. According to Ben Treynor, founder of Google’s Site Reliability Team, SRE is “what happens when a software engineer is tasked with what used to be called operations.”[1]

What kind of this ninja trickery is this? Using common sense to make learn how to hire the best people in technology? Why would Google spill the beans on this hiring secret? Maybe they’re sick of dealing with our broken shit.

Our digital systems are ALL distributed and complex now. How can we still expect that having some ignorant code-jockey in a cubicle who never uses what they make control the entire business with the stroke of a keyboard? Because: we are cost-accounting brainwashed and forget that the job to do needs the right experience and skill to do it well. Meanwhile, we keep under-hiring operations and over-hire developers such that there’s a 1-to-who-knows ratio between the people that press one button and the people that press another.

If You’re Offended By What I’ve Described, Congratulations!

I am too. Things that are so complex no one person can understand them, those things are dangerous. Banking apps that aren’t secure, mapping apps that get us lost and late, social media apps that show our kids their first porn, CGM devices that cost more in maintenance fees than their worth…it offends me when these things don’t work. Technology that works is how I make sure I have money for a family, sponsored, biological, or otherwise.

Our tech industry should be hiring people that can comprehend the things they deliver. People pay for things that work. If you don’t care about others, at least you’ll care about making money, and “right” software in a customer-obsessed market makes the most money.

It’s particularly offensive when the hybrid phoenix of a job title that ‘Site Reliability Engineer’ embodies goes largely unnoticed in high tech corporate mindsets. “What the hell is that, your latest professional title advancement scheme? Just because you mashed these words together doesn’t mean you deserve a raise!!!” If you know the following things, you deserve a salary that rivals an enterprise VP of marketing:

  • What your software should do
  • How your software does what it does
  • How to communicate the value of the things you’re working on
  • Don’t mind being woken up when it’s broken for someone
  • Ignore those around you that don’t think the above is relevant to do their jobs

Go forth and make your first salary million in a few years, y’all who can. Do this well and grow.

Why Do We See Site Reliability Engineering on the Rise?

The tech industry is now at the point where we completely forgot that the persons who build software should know how to operate that software when it other people depend on it. Big money, consumer insatiability, customer centricity, and digital transformation has skyrocketed the imperative to make the modern enterprise business engine their engineering teams. We build shiny, complicated, and highly profitable things. What did we expect?

We, the nerds, lured jocks in with our shiny things such as the Altair, BBS, and the entire mobile revolution…and they brought their friends. CFOs, ‘professional CEOs’, and other people that look at a hoodie like its pajamas that violate the corporate dress code. We allowed things to get this way #waterfall #agile #WomenInTech by being egotistical, lazy, impatient, and unkind. These are our chickens coming home to roost.

And now we have to reinvent a way out of the ‘shallow engineering’ tech culture that looks skeptically at #DevOps as a management problem. I don’t mean that everyone on your engineering team has to code, but the people who do code should understand the impact of what they do. This is ethical and this is practical. This is how you make your next billions.

This is the new horizon for impactful, profitable, and scalable tech culture:

On #InternationalWomensDay, I guess that is all for now.


FUEL for Your Brain: On Focus, Usefulness, Execution, Learning

I hate acronyms. My dad used to use them far too much, the kind of guy that was more smart in retrospect than the kind of boy I was understood at the time. Kind, thoughtful, quiet, and invested in people around him.

My current thought product is an acronym, “FUEL”, based on a few key practices that I find are valuable to my current line of work as a Change Agent. These practices take time to develop and are only truly useful when used in parallel.

  • Focus: ability to right-size activities to close the task(s) currently underway
  • Usefulness: ability to gauge effectiveness of work and reprioritize based on new ideas/objectives/activities
  • Execution: ability to match skill to task, collaborate the plan, and resolve blockers as they arise
  • Learning: ability to observe outcomes and refactor them into useful ways to improve all of the above

Real-time Example of FUEL

Last night after a meetup, I had a beer with someone I’d met before at a local conference but hadn’t dived into. The opportunity presented itself, so I stayed a little later than I normally would. They are a CTO for a 50-person startup in town. Net-net:

Paul: “What’s weighing on you right now man, work related?” (L)
Them: “Kind of glad someone asked…we have people issues.” (E)
Paul: “You’re not alone…what kind?” (E/F)
Them: “There are a few ‘senior’ engineers that don’t produce like others.” (U)
Paul: “What’s your plan for them and the rest of your team?” (U)
Them: “We just laid off one after giving him a path, but the other two, I don’t know…maybe add metrics, visibility…they’re kind of SPOFs.” (U)
Paul: “…so you can quantify what you already know? How did we arrive here?” (U/L)
Them: “They were here at the beginning, hence ‘senior’, but one guy hasn’t committed code since Sept (5 months)!” (E)
Paul: “Got it, they don’t ‘git’ it. [laughs] How are you and the leadership team  helping to coach other junior engineers?” (L)
Them: “Well that’s the problem maybe. We don’t exactly have a culture yet, but our C-level relationships with each other are solid.” (U/E)
Paul: “I once heard that great leaders define their success by fostering other leaders. Do you know who your real ‘senior’ engineers are?” (F/L)
Them: “Well I kind of already know who deserves the chance to step up.” (E)
Paul: “That’s good, but not enough. People often hesitate on new things simply because they haven’t experienced how it works yet. Your coaching needs to help those people get over any blockers to proving one way or the other if they can do the job well/right/better.” (FUEL)
Them: “I’m going to talk to our CEO about this. Can I get your card?”
Paul: “Only if you intend to use it.”

Good enough exercise and learning for me for one night.


Technical Recruitment 101 – Advocates vs. Evangelists

What’s the difference between a technical evangelist and an advocate? What are these terms even? If you’re a technical recruiter, I encourage you to know the answer to all of these questions by reading this piece for the next 4mins.

What is a “Technical Evangelist”?

A way to simplify the definition of an evangelist is to onboard people to their particular topic, do whatever it takes (hackathons, sponsorships, contribution, enablement sessions, flights…lots and lots of flights…blogging, interviews, code samples, research, t-shirt design, customer support, server setup). They wear all the hats, usually at the same time.

What is an “Advocate”?

An advocate defines their job based on the success of the customer (or anyone really) at the job they most need to do. Deep listening, directed dialog, metrics extraction, change impact quantification, being kind, and work framing are all tools in an advocate’s toolbelt. It’s caring about the other person first, then of course yourself secondly.

Advocacy vs. Evangelism

Advocates are good facilitators. Unlike evangelists, they don’t assume that because a hat needs a wearer, that it must be them to wear it. They see the whole field, not just the ball in-front of them. Advocates identify what needs to be done cross-functionally and help to match people who want to and can do a thing to get that done. They think about the problem that people are trying to solve, and put resources into motion to reach that goal.

Naturally, when I frame advocacy this way, it’s easy to see why evangelism leads to burnout. Advocacy leads to faster burndown (e.g. sprint burndown charts) because facilitation, a scalability reinforcer, is at the core of advocacy. What problem are you trying to solve? What’s required to get there? What challenges will arise? How can we most effectively help each other?

How to Qualify Who Should Apply For Which Role?

If someone demonstrates that they can differentiate between facilitating needs over taking on things as a personal responsibility to accomplish, you may just have the potential for an advocate. If a candidate lists off all the things they do without a clear definition of why first, you’re better off funneling them into an evangelist role so they can either learn a better balance or burn out and find something else.

Advocates build plans and often play a significant role in driving those plans to completion. Internal, external, independent, or consultative. When they do take ownership over a goal, you know that it will get closed, even if it wasn’t achieved to expectation, it will get closed and retro’d.

In Practice, I Say “Advocacy over Evangelism”

Evangelists talk about their product and rarely take full responsibility for anything. They are often driven by others to do things, go places, speak under sponsored time, build samples, and be engaged with customers. It’s right in the job title. “Evangelism” in Latin can be translated as “messenger”. In other words, they have been told to deliver a message. Usually the messenger has nothing to do with the crafting process of the message, and would you want someone whose job is to talk rather than listen involved in what your message to people should say? I wouldn’t.

Put another way, an evangelist mindset attempts to frame the problems of the world into terms that their product can solve. Their focus is the product that they’re incentivized to proliferate. If it doesn’t quite fit a customer’s situation, too bad, we’ll make it fit. I don’t know the job you’re trying to accomplish because I didn’t bother to ask, but I’m going to offer you a random solution anyway. And naturally, introducing a wrong-fit solution produces negative consequences (like lost time, lost money, and lost opportunity).

An advocacy mindset exfoliates information required to make decisions about how to best accomplish a customer’s true goal. Your product is not your software. Your product is a right-fit of people, process, and technology for a customer to successfully accomplish their goal. Your overlap to their situation in strictly wheelhouse terms might only by 10% or just one specific job. But if you can understand how important (or not) what you do is to completing the job they have at hand, then you can quickly fit what you offer to their needs.

This is the heart of the way product teams should “go to market”. They proceed as explorers and caretakers, not “disruptors” simply because it sounds cool. In this world, caring about how to help someone with their job better every day is disruptive. It’s honestly disruptive, to sales, to marketing, to product management, and to vision holders in technology.