Proper Villains - Work Style
“High stakes? Okay. I’ll play. But it ain’t your game, and it ain’t your rules, and it ain’t your world — and I brought my crew.”
There’s no one-size-fits-all way to create team culture. Because teams are made up of individuals, any configuration of folks is going to present unique challenges. Adding or subtracting people will threaten existing culture. For this reason, if I’m trying to instill a generative culture on a team, I focus on four things:
Work Style — Find the power of We Don’t Care About That Shit
Staffing — Recruit for fit, not just horsepower
Tooling — What do we have to spend time and money on to succeed?
Identity — Bonding and picking each other up when it gets hard
I’ll have a separate post for each section, but will include links above as they are finished so you can navigate between sections easily. For today, we’ll focus on…
Work Style
Despite all the factory metaphors we use for development work, putting together a team isn’t building equipment. You can’t use the blueprint from the last team to build the new one, even if they are in the same company using the same technology stack. When you’re putting together a team, you need to think about it like product design — what is the outcome I am looking for? What are the nonfunctional requirements/constraints imposed on me by my org or industry? What is the minimum version I need to start testing my hypotheses about how this team will deliver?
I call this category “Work Style” because I believe the hardest part comes down to something squishy that is mostly captured by that phrase — put a little longer, this section is about how management designs the mission, agreements, and assumptions a team will be built upon. It’s the table stakes that need to be explicit, because they are the most likely things to create culture mismatches.
There are non-negotiables depending on company and business model, the afore-mentioned constraints and nonfunctional requirements. Does this team need to use Scrum because of company mandate? Do you need an SRE group that has consistent, well-defined on-call schedules? Are you a professional services group that bills on time and material?
Given the constraints you cannot fight, your job as a manager is to find a sustainable path toward the outcomes you need from this team. This sounds extremely formal, and I guess you could get real nuanced — lay out every possible positive feature of a team and stack rank them based on impact on your outcomes. For me, that’s usually unnecessary. Of course, given the opportunity, we all want teams that
Release often
Have predictable velocity
Have few bugs
Communicate well
Have ample time to focus via flow time
and all the rest of general wisdom about “good dev teams".
But it’s more important, in my mind, to figure out what pieces of an ideal work style you don’t care about for this team. I have had a lot of trouble learning to accept this — am I really okay saying the culture of my team, for instance, is based on not limiting context switching? Do I really want to institutionalize the idea that we’ll code bugfixes faster than a majority of users will see them? Am I actually cool with developers building tools to circumvent existing release processes?
It took coaching professional ultimate frisbee (www.strikeultimate.com) with defensive coordinator Dooby Helm to give me the language to get really comfortable with it. Without getting too deep into frisbee, when concerned players asked Dooby why a certain defensive strategy didn’t try to take away something usually seen as a threat, Dooby somewhat indignantly said:
We don’t care about that shit! The whole point is making them work with that, because we’re deciding what we’re attacking. They’re gonna take [that action] and we’re gonna get blocks because we know what they’re about to do next.
As a manager, be like Dooby. Decide what you’re attacking. Said another way, consciously decide what weaknesses you’re comfortable with. Design your work style around finding an advantage through strategically killing your darlings. Start from the desired team outcome instead of hefting the baggage of every trauma-driven assumption you have about what makes a good team. The next three articles in this series exist because doing so will piss off a lot of team members if you don’t hire, tool, and coach them for it.
But what does that even look like?
For an engineering example, one of my highest performing teams was designed as a ‘startup within a startup’. We needed a team that could deliver new features, often barely proofs of concept, to capture customers in a brand new market. The work to get those new clients may not even end up as long-term features, just enough to prove we could do something. We also needed to be responsive in a way that would not fly in the larger business — when you only have five clients, two of them facing a major bug is catastrophic. Two customers in the larger business would not even warrant a support ticket.
So the work style of this team had to be one that was intensely amenable to change. Change in priorities, change in mission, change in code. We needed engineers who weren’t precious about flow time. We needed the ability to make changes in production often, And we needed to be willing to throw away work when priorities changed or new information came up.
Ultimately, what we chose to attack was rigidity and consistency.
I know! I KNOW! From an agilist, that sounds idealistic — “we chose to attack consistency and gained agility!” Like most business blog posts, it sounds like it’s all highlight reel.
But there are downsides to this — moving fast, with sometimes sketchy requirements, means developers could (and did) build things we didn’t need, which led to a scramble. That sucks.
Spending two weeks hammering out a project with a bunch of heat from execs, only to find out a customer churned before it released? That sucks.
Having to justify every technical solution that skirts an existing process because we need it outside of regular release cadence? That sucks.
But listen to Dooby.
We don’t care about that shit!
We have chosen to not let those issues be the sorts of things that ruin our days, our weeks, our quarters. And that isn’t easy. That’s why this series is about establishing a culture, not how to implement a series of meetings or process flow diagrams or whatever.
“We don’t care about that shit” has to be in your team members’ bones. It has to be something (see: Identity) that you take perverse pride in getting burned by. If you name the pain you’re comfortable with up front, and get buy-in, teams will even brag about the failures you chose to allow, because it frees them up for the successes you really wanted.
For all that to work, though, you need the next three sections.