First Do No Harm

I should start by saying that pretty much everything I have to say in this post applies to pretty much every workplace I’ve been in, technology or no. I don’t intend for this to be a dig at Chef in particular, Chef customers, or any of the Chef community. Any criticism I level is meant to trigger introspection, with the intent to enlighten and improve.

Context

In the past year, the Support team had two members move on to greener pastures, one member join another team at Chef, and the team supervisor moved on as well. The experience of being one of the more senior members of the team, and gaining ever more context in the company, has reinforced some of the learning I wrote about last year, but shown me some new things as well.

I found myself relying more on long-past experience managing other folks, and working with other managers to improve cross-team collaboration, than on direct technical skills. That being said, I’d guess that I submitted more PRs and technical feedback over the past year than during my first year at Chef. Having the context to know where and how to contribute is quite meaningful, and I hope to be able to guide new folks through their own journeys as well.

Customer-Facing Teams

It’s interesting that some of the most innovative work being done at the company right now seems to be coming from customer-facing teams (CFTs). Some of that might be due to the restrictions of having some folks in the engineering org directly tasked with Project Management and Product Management, although I expect to see some major benefits from that over the next year. On the flip side of that is remembering the way I wrote about this last year, and my ongoing recognition that there are some clear divisions between CFTs and product engineering. I do get the sense that there’s a lack of coherence in how a business commits to product objectives vs the reality of how things get implemented by field teams. I can’t say that I have a strong sense of what would be better, but I can call it out when seeing it and I think the rest might have to be up to the high-titled folks at a company like this. From talking with folks at other product businesses, this doesn’t seem to be a problem unique to Chef or to the infrastructure-as-code business. There’s a limited amount of money investors are willing to burn in order to see a return, and in order to attract the next funding round or look good for IPO you’ve got to deliver some whiz-bang presentations at your conference and for the investors. It does seem to be the consensus among product companies that a lot of what customers say they need isn’t actually what they want or need, which seems at least somewhat misaligned with keeping your product functional for their use.

Walk Like a Duck

One catchphrase that gets a lot of mileage these days is “Assume positive intent.”

Another goes something like “People tell you who they are when they interact with you. If you don’t believe them, it’s on you.”

Remember to be on the lookout for ducks. If it waddles, quacks, and appears ducklike, take some time to consider whether it is, in fact, a duck.

I used this heading last year to talk about customer interactions and hard-earned operations pattern-matching, this year I’m using it in a slightly different way. The “assume positive intent” phrase was one of the things I heard during my interview process at Chef, and I’ve heard it elsewhere as well. I think that it’s perhaps okay to give people you don’t know a chance to show you through their behavior who they are, and it’s very important to know that it is entirely okay to stop assuming that someone’s intent is positive. This shouldn’t be taken to mean that I look on my experiences at Chef as negative, just that bringing rose-colored glasses to every interaction doesn’t serve folks who experience neutral or negative intent on a regular basis particularly well. It’s probably more important for folks who might ask for others to assume positive intent from them to do some thinking about the other person’s circumstances to understand why they might receive such an appeal with skepticism.

I think this comes from the same sort of thinking that a company’s leadership can say “we read The No Asshole Rule and liked what it had to say, now we can tell everyone to read the book and now we won’t have assholes in the company!” That is a nice feeling for some people for a small amount of time, but it probably doesn’t do much to improve the experiences of the folks who need it most. Concentrate on improving the experiences of the folks who need it most, and you’ll improve the experiences of the folks who need it least as well, is my thinking.

Silos

It’s amazing to me how many perspectives there are on what this devops thing is. I tend to think of it as a practice that emcompasses the learnings embedded in The Phoenix Project, The DevOps Handbook, and The Unicorn Project. I consider those fundamental reading for anyone who wants to “do devops”, and it’s amazing to me how many people haven’t done so yet call what they’re doing “devops”. The fact that things called DevSecOps, DataOps, FinOps, etc. exist make me think folks didn’t read The Phoenix Project, because it’s very explicit in the book that Security, Finance, etc. are all included in the practice.

It’s impressive how sneaky organizational silos are. Folks mean well when they create a thing inside an organization in secret, only inviting a few folks, then get blindsided at how the thing they’ve created to improve the organization doesn’t function outside the original silo. Conway wept.

Wrap It Up, B

I think that’s it. Happy New Year, all!