Afterthoughts on Hive Minding

It’s a powerful thing to understand how your brain works, what motivates you, and what you don’t care about. There are so many things that can distract, but at the end of the day, there are very few things measurable immediately worth having done. Shipping myself to Europe until next week, for example, has already had measurable personal and professional impact.

One thing I experienced this week after injecting a little disruption to conformity yesterday was what I now call “hive minding”, or otherwise assisting independent contributors in rowing in the same direction. The classical stereotype of “herding cats” infers that actors only care about themselves, but unlike cats, a bee colony shares an intuitive, survival imperative to build and improve the structure that ensures their survival. Each bee might not consciously think about “lasting value”, but it’s built into their nature.

Be Kind, Rewind

I’m always restless, every success followed by a new challenge, and I wouldn’t have it any other way, but it does lead to a growing consideration about plateauing. Plateauing is a million times worse than burning out. There are plenty of people and companies that have burned out already but are still doing something “functional” in a dysfunctional industry, and if the decision is to flip that investment, it’s an easy one to make. Fire them, trade or cut funding; but what do you do with a resource when they plateau?

I think you’ll know you’ve plateaued when you find yourself without restlessness. If necessity is the mother of invention, restlessness is the chambermaid of clean mind. Al least for me, like a hungry tiger in a cave, I must feed my restlessness with purposeful and aligned professional work. The only problematic moment with me…I like to get ahead of the problem of someone telling me what to do by figuring out what we (everyone, me and them) should be doing before someone dictates it with less context.

The sweet spot of this motion is to do this together, not in isolation and not dictatorially, but coalescing the importance of arriving at the “right” goals and in alignment at the same time. The only surprises when you’re riding the wave together is what comes next, and when you engineer this into the process, surprises are mostly good.

It took a while to arrive at this position. I had to roll up sleeves, work with many different teams in multiple organizations, listen to those whose shoes I don’t have the time or aptitude to fill, figure out how to synthesize their inputs into cogent and agreeable outcomes, and do so with a level of continuity that distinguishes this approach from traditional forms of management and group facilitation.

Don’t Try This On Your Own

The cost of adaptability is very high. If I didn’t have an equally dedicated partner to run the homefront, none of this would work. She’s sought out the same kind of commitment and focus on raising the kids as I do with what goes into pays the bills. There are very few character traits and creature comforts we share, but in our obsession over the things that make the absolute best come out of what we have, she more than completes the situation.

In this lifestyle, I have to determine day by day and week by week what net-new motions/motivations I need to pick up and which I need to put down, either temporarily or permanently. This can feel like thrash to some, but for me, every day is a chance to re-assess based on all the days before now; I can either take that opportunity or not, but it is there despite whether I do or not take it. If my decisions are only made in big batches, similar to code/product releases, I inherit the complexities and inefficiencies of “big measurement”…namely, granularity in iterative improvement.

Feedback Loops, Everywhere

As I explore the dynamics of continuous feedback loops beyond software and into human systems, a model of frequency in feedback and software delivery not as separate mechanisms, but as symbiotic, emerges. The more frequently you release, the more chances there are for feedback. The more feedback you can synthesize into value, the more frequently you want to release. One does not ‘predict’ the other; their rate bounds each other, like a non-binary statistical model.

What I mean is that a slow-release cycle predicts slow feedback and slow feedback predicts low value from releasing frequently; a fast feedback mechanism addicts people to faster release cycles. They share the relationship and depending on how extreme the dynamics feeding into one side of the relationship, the other one suffers. Maybe at some point, it’s a lost cause.

An example from the performance and reliability wheelhouse is low/slow performance observability. When you can’t see what’s causing a severe production incident, the live investigation and post-mortem activity is slow and takes time away from engineering a more reliable solution. Firefighting takes dev, SRE, ops, and product management time…it’s just a fact. Teams that understand the underlying relationship and synthesize that back into their work tend to use SEV1 incidents as teachable moments to improve visibility on underlying systems AND behavioral predictors (critical system queue lengths, what levels of capacity use constitute “before critical”, architectural bottlenecks that inform priorities on reducing “tech debt”, etc.).

The point is that feedback loops take time and iterative learning to properly inject in a way that has a positive, measurable impact on product delivery and team dynamics.

Going from Feedback Loops to Iterations…Together

All effect feedback loops have one thing in common: they measure achievement levels framed by a shared goal. So you really have to work to uncovered shared goals in a team. If they suit you and/or if you can accept the awesome responsibility to challenge and change them over time, it’s a wild ride of learning and transforming. If not, find another team, company, or tribe. Everyone needs a mountain they can traverse and shouldn’t put themselves up to a trail that will destroy them. This is why occasionally stepping back, collaborating, and reporting out what works and what doesn’t is so important. Re-enter the concept of “team meetings”.

Increasingly, most engineers I talk to abhor the notion of more meetings, usually because they’ve experienced their fair share of meetings that don’t respect their time or where their inputs have not been respectfully synthesized in a way they can see. So what, meetings are a bad thing?

Well, no, not if your meetings are very well run. This is not one person’s job, though scrumbags and mid-level management with confirmation bias abound, and especially so because they don’t have built-in NPS (net promoter score). A solution I’ve seen to the anti-pattern of ineffective meetings is to establish common knowledge of what/how/why an “effective” meeting looks like and expect these behaviors from everyone in on the team and in the org.

How to Encourage Effective Collaboration in Meetings

Learn to listen, synthesize, and articulate back in real-time. Too much time goes by, delay and context evaporate like winter breath. Capture as much of this context as you can while respecting the flow of the conversation. This will help you and others with remembering and respecting the “why”, and will allow people to see what was missing (perspectives, thinking, constructs), afterward. Examples of capture include meeting minutes, pictures of post-its, non-private notes from everyone, and even recordings.

But in just about every team and organization there’s a rampant misconception that ALL meetings must produce outcomes that look like decisions or action items. These are very beneficial, but I’ve seen people become anti-productive when treating themselves and others as slaves to these outcomes. Taking decisions too early drives convergent attitudes that are often uninformed, under-aligned, and often destructive.

Some of the most effective meetings I’ve had share the following patterns:

  • know why you’re meeting, provide context before, and set realistic expectations
  • have the “right” people in the room
    • who benefit from the anticipated outcomes and therefore are invested in them
    • who bring absolutely critical perspective, where otherwise invalidates outcomes or cause significant toil to refactor back in afterward; not to few
    • who contribute to functional outcome (as opposed to those who are known to bring dysfunction, don’t respect the time of others, argue over align); too many
  • agree on what positive and negative outcomes look like before starting in
  • use communication constructs to keep people on track with producing outcomes
  • have someone to ensure (not necessarily do all the) capture; note and picture taker
  • outcomes are categorized as:
    • clear, aligned decisions (what will happen, what worked, what didn’t, what next)
    • concrete concerns and missing inputs that represent blockers to the above
    • themes and sense of directional changes (i.e. we think we need to change X)
    • all info captured and provided as additional context for others

Trust AND Verify

One thing I keep finding useful is to challenge the “but” in “trust, but verify”. In English, the word “but” carries a negating connotation. It invalidates all that was said before it. “Your input was super important, BUT it’s hard to understand how it’s useful”…basically means “Your input was not important because it was not usable.”

My alternative is to “trust and verify”, but with a twist. If you’re doing it right, trust is easy if you preemptively provided an easy means to verify it. If you provide evidence along with your opinion, reasonable people are likely to trust your judgment. For me, rolling up the sleeves is a very important tool in my toolbelt to produce evidence for or against a particular position. I know there are other methods, both legitimate and nefarious, but I find that practical experience is far more defensible than constructing decisions based on shaky foundations.

All this said, even if you’re delivering self-evident verification with your work, people relationships take time and certainly take more than one or two demonstrative examples of trustability to attain a momentum of their own. Trust takes time, is all.

Takeaways and Action Items from This Week

Democratic decision processes are “thrashy”. Laws and sausages: no one wants to know how they’re made. In small teams going fast, we don’t have the luxury of being ignorant of outcomes and the context behind them. For some people, “democracy” feels better than dictatorial decisions being handed down without context; but for those who still find a way to complain about the outcomes, they need to ask themselves, “did I really care enough to engage in a functional and useful way, and did I even bother to educate myself on the context behind the decision I don’t like?”

Just like missing a critical perspective in a software team, in a global organization, when one region or office dominates an area of business (U.S. on sales, EU on security, for instance), this will inevitably bias outcomes and decisions affecting everyone. As the individual that I report to puts it, “scalability matters to every idea, not just when we’re ready to deploy that idea”. Make sure you have the right “everyone” in the room, depending on the context of your work and organizational culture.

Someone I once met and deeply respect once told me “it’s not enough to be an ally, you need to be an accomplice“. In context, she was referring to improving the epic dysfunction of modern technology culture by purposefully including underrepresented persons. Even if we make a 10% improvement to women’s salaries, hire more African-American engineers, create a safer place for LGBTQ, I still agree with the premise that doing these things isn’t good enough. Put it another way, receiving critical medical treatment for a gushing head wound isn’t an “over-compensation”, it’s a measured response to the situation. The technology gushing head wound, in this case, is an almost complete denial from WGLM (white guys like me) that there is a problem, that doing nothing continuously enables the causes of the problem, that leadership on this doesn’t necessarily look or think like us, and that this isn’t necessarily needed now.

Bringing it back to the wheelhouse of this article, true improvement culture doesn’t just take saying “sure, let me wave at you as an ally while you go improve the team”. It takes being an accomplice (think a getaway driver), we should ALL be complicit in decisions and improvement. Put some skin in the game, figure out how something truly worth improvement and your effort maps to your current WiP (work in progress) limits, and you may find that you need to put something less worth your time down before you can effectively contribute to improvement work. Surrounding yourself with folks who get this too will also increase the chances that you’ll all succeed. This is not an over-compensation, it is what everyone needs to do now to thrive, not just survive.

Crossing Cross-functional Chasms

Initialization Phase

My first evening in La Ciotat: I picked up a rental car in town due to the good graces of Giulia, the front desk assistant who was coming off of her shift. She called, then insisted she drive me to the pick-up office where the lady attending was on her way out to deliver a car. Thirty not so awkward minutes later after discussing dog grooming and training techniques in great depth, the attendant came back and shortly I had a car. It was just starting to rain and it had been years since my last stick shift. Crossed fingers and no stalls to get back to La Rose, but by that time, waters were pouring out in sheets. The sprint from car to lobby was in place of the shower I had hoped to take earlier.

The hotel restaurant was leaking everywhere and occasionally losing power. The great thing about room charges is that a full bar downstairs doesn’t require the internet to hand over all sorts of drinks. People outside the lower forty-eight seem to intuit what to do when the credit card terminal is out of service. The lightning was faster and closer than I’ve ever seen from my fishing town, so it was a good time to revert to battery power and write this.

My recent recipe is bourbon (or tequila) and a splash of each lemon juice, creme de cacao, absinthe, shaken and filtered into a highball with a thick peel of an orange. A few months ago it was half high-quality sake and half Prosecco with a flake of rosemary. In a pinch, anything works, and when your bartender has got flooding issues to deal with, you can ponder life under a canopy and try to stay dry. The following are my thoughts from underneath all of this.

Planning Phase

The thing about my work, it isn’t scalable because it serves different goals than other kinds of work. Like Kent Beck describes in his “3-x” model, there are modes of work that optimize for different localized outcomes but all serve the same high-order goal. What is that goal? As Eliyahu Goldratt states, “the goal of an organization is to make money”. Certainly commercial ones, but even non-profits need to do this in order to exist. I exercise aspects of each of Kent’s 3 modes: explore, expand, and extract. I dig holes to find gold and when I hit it I dig hard, and then try to scale that out to optimize efforts to extract that gold.

In his epic distillations, the Innovators Dilemma and Solution, Clayton Christensen puts a fine point on how if a company is not thinking of its next horizon at all points in the current extract motion, it has no lasting future. Despite the dilemma of where to divest funds and how to prioritize “next” work, I am looking to do that for whomever I work with. I want to help optimize what’s currently being extracted, translate learnings into gaps and undiscovered opportunities, and continuously listen and learn “what’s next” (ref: Tim O’Reilly in “WFT?: What’s the Future and Why It’s Up to Us”. If we’re not doing that, either homogeneously as all actors in an organization or as a unique sub-function, then we’re dooming our employees and product to obsolescence.

Implementation Phase

I do…a lot…of things in my current organization. Pre-sales guidance, analyst relations, strategic product planning, blog writing, speaking, webinars, on-site customer planning sessions, technical prototyping, automated pipeline and testing examples, collaboration with support on key customers, building examples, positioning and messaging assistance, customer engineering, amongst others. “Cross-functional” is an easy way of putting it. When friends ask about what I do, I just say “I help technology companies make better decisions.”

But when your cross-functional, you get to see how diverse people groups are and how differently they structure their goals. For some, it’s money, but for others it’s lead acquisition, and for yet others, it’s sprint deliverables and low-defect release cycles. For leadership it’s all of these things plus happy employees, happy customers, and happy selves. I want all of these things and more…happy me and happy mine (family) which requires balance. Balancing multiple objectives takes a lot of practice, similar to my experiences with Uechi Karate-do. Balance isn’t a static state, it’s an ability to re-balance and prioritize based on shifting needs and constraints.

In planning one of four strategy sessions with one of the founders, I found myself thinking “our goals are not the same, he wants to prioritize an existing backlog around reporting, but I want to define the new state of the art for our industry”. After realizing that he had a different goal, we played better together; but I am not distracted. Maintaining the status quo has never been my strong suit and I’m more useful when focused on what’s next, not just what already was.

This is my current approach to balance: understand what drives people (myself included), listen to everyone, provide value that’s aligned to these motives, and circulate what makes sense to the organization. Catching the moment when a founder’s goals and my own differ happens in real-time, but only if I’m exercising balance along these guidelines.

Deployment Phase

This week, the plan is to listen, a lot. Especially because of the language gap, but also thanks to my eclectic manners of verbal communication, as evidenced last time, less seems to be more here. I am working to lock down the details of a new position, focused on bringing the customer perspective to every area of business and a translation of my own invention. The activities performed today have a tendency to be…predictable, easily replicable, and therefore boring to someone like me.

Though billed as “strategy sessions”, my feeling is that current leadership understands the need for all elements of the business to be engaged deeply…”lean forward” as I often call it. The real strategy happens next week, in decision meetings amongst founders and key business owners separate from the rest of the employees. This is an interesting model, right-fit I think for humans who need time to digest and consider various perspectives and potential directions.

Though many ideas and directions will be discussed over the next 7 days, we’ll need to prioritize and I don’t own the company. All I can do is help those who do have a clear understanding of internal and external dynamics, provide requisite evidence for my positions, and improve relationships with my counterparts here in France.

Monitoring Phase

Feedback loops are important whether you automate them or not (but automating them is the smart way to do it). How do you automate human interactions though? The closest I’ve gotten is to “pull forward”…in my upcoming role, building in the demand and supply of effective internal and external collaboration. The partner channel is a significant dynamic in my current organization, much of it is channel but there is also a contingent technical element, as all good partnerships between tech companies should have. A colleague of ming is fantastic at tactical and technical delivery in this scope, but to scale these efforts out to the whole organization takes project/program management that he’s not particularly keen to deliver himself.

A key element to “monitoring” my effect is to A) have traceable inclusion in conversations (via Salesforce currently) and B) through volunteered backchannel context measure how many times my involvement improves what we’re doing, in the partner, sales, marketing, and development work. This week would be an example of execution, then after next week, I would explicitly ask my leadership what value they heard as a result of my presence. Pull forward isn’t a zero-effort enterprise, but is absolutely necessary if you take your individual impact lifecycle seriously.

Reintegration Phase

The bartender tonight quickly called for backup and started taking care of the flooding issues. I suspect this was because he knew that if he had just sat there and let the hotel restaurant get flooded, someone would ream the shit out of him the next day. He got ahead of the problem and solved it. This is what DevOps and SRE is all about, seeing that no one else is solving for the lasting value and putting patterns in place to help others to do exactly that.

In our current state, this organization takes its time to synthesize and integrate learnings. Faster than most other teams I see but not as fast as some, as with everything pace can be improved. More importantly, alignment and transparency must always be improved and that is not zero-effort in the slightest either. In a prior position, an SVP once stated that “alignment is about 50% of my time spend”. With marginal variance, I wish that applied across all roles and responsibilities in every team and every organization I work with. Imagine the impact you’d have if 100% of your 50% heads-down work was wildly effective. That is what rowing in the same direction looks like.

Reprise

For this post, there is no “call to action” other than if you want to leave a comment or engage on social channels. I can always find something worthwhile for you and I to do together. Drop a line and let’s chat about that.

On Volunteering for Tech Community Work

DevOpsDays Boston volunteers

This is my attempt to distill what I’ve learned over the past two years of contributing to maintaining and improving the local DevOps community in Boston. As in all cases, what we think we “know” at a point in time can/may/should change as our journey progresses. Rather than prescriptive, this article is descriptive of my current approach.

TL;DR

  • do it for ‘right’ reasons that align with community values
  • really know what you’re getting into and commit proportionally
  • be prepared to spend time and energy, particularly on personal adaptation
  • manage your life work-in-process limit carefully
  • expect something unexpected out of it

A True Community is Tangible

There are many definitions of “community”, but here’s mine at this point:

A group of people dedicated to sharing and improving along with each other.

– me, provisionally as of 2019

If helping to do this sounds easy, it is not. Dedication means graciously and humbly collaborating with other organizers, diligently following up with a million little details, listening and understanding where people in the community are coming from, actively seeking personal improvement and synthesizing into volunteer work, responding quickly to important issues in the community and of course, making/taking time from your personal and professional life to do these things reliably.

For an organizer, these things are very tangible because they cost us what we can never get back: time. For other community members, the value comes from elements like knowledge sharing, conversations, job opportunities, or even a sense of simply being part of a community. Showing up at a meetup event or a casual coffee chat is the first step, and understanding why you enjoyed brings you back.

One of the most concrete, tangible outcomes of being part of the community I work in is that there’s always an opportunity to learn something new and useful, which by definition you can’t predict. The more you give, the more you get. The more you’re open-minded, the more mindful and receptive to good ideas you become. The more you listen, the more you hear.

Fostering Unity and Diversity at the Same Time

We all come to the table with a variety of backgrounds, experiences, and perspectives. This is the true strength of a healthy community. Balancing time constraints and the distribution curve of appetites for themes is tricky, but doable when facilitators are dedicated and have the interests of each other (including the whole community) in mind.

There’s usually a unifying set of core topics and themes related to some common interests (such as learning new tech or how to deal with office culture or professional improvements). Straying too far outside this focus often contributes to our “variety” getting in the way of sharing and improving, though sometimes including topics seemingly unrelated to the tech side of the conversation can provide opportunities for divergent thinking and new knowledge.

An Organizer’s Roles and Responsibilities in the Community

At a small scale, this may happen organically, but as the group scales, this doesn’t happen without organizers. A community organizer is someone who:

  • looks out for the best interests of all members of the community
  • is dedicated to creating more value than they capture [1]
  • ensures that underrepresented perspectives have a voice
  • deals with the logistics of shared spaces (events, chats)
  • ensures that the values and principles in the Code of Conduct are respected
  • develops a plan of succession and redundancy in organizing responsibilities
  • insulates the community from negative or unwanted solicitations

I’ve had to great privilege to work with a bunch of other organizers and volunteers, and one of the key things I see make up for the aggregation of individual intents and sometimes dysfunctions is the willingness to come back and do/be better.

One thing that’s always a challenge is to maintain a pool of organizers greater than one or two active individuals. Think of it as resiliency engineering, a topic close to my personal wheelhouse. The more trustworthy and reliable individuals are involved, the more trustworthy and reliable the outcome.

Thrash vs. Progress

Everyone brings their own personal interests into a group equation. When the guiding principles include alignment and responsibility, it works really well for everyone. When someone puts their personal interests above the common good, all is not lost, but causes a lot of “thrash”. I define thrash as work which ultimately does not progress and improve the common good.

Some folks need to thrash around with new ideas and values, and this is okay too. Healthy synthesis of new ideas and values is important. Provided that there’s room for people to bring these ideas to the table and that progress on existing values is in play, we all win.

Getting Ahead of Toxicisity

I’ve worked in a number of places and communities where behavior is sub-par. When something is introduced which causes a body (or community) to make a backward motion towards it’s shared and the common good, particularly on a repeated basis, I would call this “toxic”. In a DevOps mindset, this can happen too, where anti-patterns such as burnout and distrust crop up because little details aren’t being addressed.

In DevOps communities, many are familiar with the Westrum model of organizational culture: pathological, bureaucratic, and generative. Though often misused to label groups and people at an aggregate level, the most useful employment of this lens IMO is around behaviors and activities. Those can be changed, those can be provided guidance where people have specific decisions to make.

Two examples from our local meetup come to mind: use of alcohol and meritocratic rhetoric. Though innocuous in small amounts, both quickly detract from community spirit and sense of safety in our culture.

In one thread, someone suggested that we bring our own bottles of scotch. I love my happy hours the same as warm-blood, but immediately before that, I witnessed and heard from a number of other community members that an unannounced and unplanned open bar at a meetup detracted from fostering a safe space. I quickly hopped on this, making sure that we all consider how this idea contributes to values in our Code of Conduct. Call me the culture cop, but after collaborating with other organizers on the approach, it was clear that we wanted to get ahead of where it was going and pivot the conversation back to the purpose of the community.

In another backchannel thread with community members, we discussed the rising trend of conversations assuming that everyone had the same opportunities leading to a notion that all people would be rewarded based on the merit of their works. In the current tech culture, meritocracy is rampant, most notably due to open-source mainstays such as the Linux Code of Conduct and revulsion of GNU founder R.M.S after a career of misogynistic and belligerent behavior. Not everyone can just walk up to a table and be valued by those there. As a common good of our community, we do our best to steer away from the ‘meritocracy lens’ and bring conversations back to a place that is useful for all members of the community.

Improvement Means Earning and Granting Trust

One of my biggest goals is to find someone better than me at these things that not only fulfills above bulleted organizer requirements but that I can trust to improve and grow the community in ways I can’t. Knowing that I probably won’t be able to keep up the same level of commitment to our community indefinitely, succeeding myself with other trustworthy individuals is not a zero-effort endeavor in the slightest. Nothing happens overnight, and the best time to do something truly good is always ‘now’.

It’s definitely been interesting to co-organize the meetup, facilitating events and threads, hopefully earning an amount of trust in our community about why I’m spending my time and energies on it. What I’ve learned is that granting someone trust is a very different proposition than earning it. One thing suggested to me in a backchannel was that “ally is a term someone uses on you, not something you “. After bouncing this around in the back of my mind for months, I’ve realized that I don’t need to focus on wait for people to ascribe community members (especially organizers) trust, we just need to do the best we can and demonstrate trustworthy behavior.

As one of 6 organizers of the yearly DevOpsDays Boston event, I was in a place to understand that forging an initial relationship with the Inclusive Tech Lab and Resilient Coders communities was a great direction (most props go to Laura Stone, another co-organizer of the meetup and event). The heart and spirit of these other groups align with the values and demonstrated levels of commitment that I know are required to drive the community forward.

Listening to and Integrating Feedback

Imagine all the times that someone spoke words that you didn’t understand…thing you weren’t in a place to receive. What a shame. What do you do about that?

Mostly always looking to get better, but one thing I’ve realized is that the moments my mouth is open should be marginal compared to time I spend hearing what others have to share. If doing it right, the times I speak should be guided by three questions:

  • does this have to be said (and why)?
  • does this have to be said by me?
  • does this have to be said right now?

Though everyone suffers from subjectivity (implicit in the above bullets), listening and empathizing with what you know about someone’s perspective increases the “you AND them” funnel for new and important ideas. Also, reading or listening to lots of books and blogs also widens perspective.

Get Involved, Be Good

Though not a requirement to attending, I’m surprised at the number of regular attendees who haven’t actually read the Code of Conduct but still naturally adhere to the values and principles within. I take this as a sign of common interest in the community but don’t take for granted the responsibility to make sure behaviors are inline.

If you’re thinking of helping, definitely reach out. If not, still, leave comments. I appreciate feedback and engagement on approach to facilitating in the community, always.