On Windermere Sound, Part 2

If you have the opportunity to move into Windermere Sound in the Orlando area, don’t.

Also, specifically Cindy Riggs of Wemert Realty, you should know that she is a toxic enabling person who is not to be trusted.

You can do better.  And not far away, either.


On Windermere Sound

A little over a month ago, I moved to a new house.

When I mentioned that I was moving to people in the community (such as doctors, dentists, and other professionals in my area), the topic of "Why" would come up.  The answer was "Problems with the HOA".

This person would inevitably sigh knowingly and heavily, and launch into a story about the HOA notice that they received saying that their tree bark was exactly the wrong shade of grey-brown, but that tree had been planted at least 7 years ago.

That is not the kind of "HOA Troubles" that I was having.

I can honestly say that it's refreshing where "Crazy HOA Stories" involve notices that the Internet Cable is hung in an unsightly way, rather than "The HOA Board are having parties that exceed 80 decibles as measured inside my closed house, or setting off illegal fireworks", or "The HOA President is setting off a siren while a hurricane is approaching, or he's physically threatening residents".  It's refreshing.  I haven't had to call the Orange County Sheriff's in over a month.

If you are looking to move to the Orlando area, I would caution you to be aware of the HOA that you are moving into.  The HOA's behavior and demeanor can make life either wonderful or awful.  When looking at a home, ask who the board members are.

If the board includes a man who's first name sounds like he could be Dr. Frankenstein's assistant and who's last name sounds a bit like "Thor's Son", move on.

If the board includes a woman who's first name sounds like "Sindy", and who's last name might include either a Japanese surname and/or sound like Murtaugh's partner, move on.

Windermere Sound is a nice neighborhood with the exception of a few people, but those people happen to be on the never-voted-upon HOA Board.  Life is too short, and these people and those houses are not worth it.  Some of their friends are quite morally compromised, too.  They're obviously not complete fuck-ups, because they have great kids with better morals than their parents, but at this point being involved with the Windermere Sound HOA in Windermere, FL is a condemnation.

I hope that this changes, and the board should become filled with responsible adults.  I'd love to be able to take this post down with a massive "EDIT" at the beginning.  But that will require that the existing HOA to follow it's own rules, provide proper notice, and run a legitimate Board vote.  Unfortunately, it is not in their own best interests to do so.

Central Florida is nice.  I like it here.  I used to love it, and would tell everyone I met how great my neighborhood was.   This was until the people who became the HOA turned toxic.

I'm happy with my new house.  The neighbors are quiet, respectful adults.  Which is to say "they act like Adults".  Their children are well-behaved.  We don't have any fear about letting our kids outside to play, for fear of an unbalanced person harming them.  I haven't called the Sheriff's department in over a month.

Things are good in Windermere, FL.  Just mind where in Windermere you are.


On Perfume

Perfume.  Originally created to cover the fact that you may have never bathed, and that you may have one or more infections that are rotting your flesh away.

Now, it serves mainly to warn the herd that someone named "Chad" has wandered into your proximity, and may try to corner you into listening about Crossfit.

Men and women, if you MUST, here's how to apply it:

1) If there is a pump that sprays the perfume out, point the nozzle away from you, pump once, then walk into the cloud.  Now put the perfume away.  Do not pump more than once.  Do not repeat.  You have enough.

2) If there is no pump, with the cap on the bottle, shake the bottle.  Remove the cap, and prepare to stick one finger into the cap.  NOTE: Not the bottle!  Now, barely touch the part of the inside of the cap that is wet. Put the cap back on the bottle, and put the perfume away.  Lightly touch the perfumed part of your finger to your collarbone, or behind the ear.  Do not do this more than once.  Do not repeat.  You have enough.

Here are a couple Don'ts:

* Do not wear perfume to the office.  You're not there to pick up anyone unless you're a walking HR Violation.  It's only distracting, and not in the good way.

* Do not wear perfume out to dinner.  You're fucking with everyone else's sense of smell and taste.


This part is for the men.

Guys, look, I get it.  I used to bathe myself in perfume because I thought women were into guys that smelled like the inside of bottles that were shown in the foreground of cowboys.  I didn't want to have "too little" perfume on, and miss out on them being unable to keep their hands off of me.  I get it.

I even had one girlfriend who Loooooved a particular perfume, so bought me a bottle of "Curve".  Yes, she did like that perfume.

Here's the thing: If you want to attract the kinds of women that are attracted to a perfume, you're going to be easily replaced.  Shallow can be fun for awhile.  But if some bottled chemicals are what separate you from the next guy, I feel sad for you, bro.

So, that girlfriend?  She tried to play a bunch of headgames to get me to... fuck, I don't know what she was doing.  Maybe get me to try to prove to her that I was worthy, or mental judo to convince myself that putting in that much effort meant that she must be worth it.  Needless to say, it didn't last, and the way she ended things won her no friends.  She bought the new boyfriend some Curve, too.

Perfumes might be a cheat against pheromones, but that's all they'll be.  If you stink, you'll be better off getting clean.

If you want a woman to miss your smell when you're not there, you want that smell to be you, not something from a cosmetic.  If "your smell" that she misses is a perfume, you're just a vibrator and a heated blanket away from being completely replaceable.

In the days before I went to Iraq for most of 2005, I set aside a t-shirt, and wore it at night while I slept.  As I was doing my final packing up, I put it into a gallon ziplock bag, and set it aside in a drawer.  After I got in-country and could make a call, I told my wife what I'd done and where it was.  This was so that when she missed me the most, she could open that bag, and have a little bit of my smell.  I don't know how long she kept it, but it was appreciated, especially as time passed and my smell faded from our house.

As a side note, if you take exception to it being called "perfume" and insist on calling it "cologne" or "body spray", I challenge you to tell me the fucking difference, especially if yours wasn't created and packaged in a particular region of France.


Those ads with hordes of women swarming a guy because he's spraying himself are appealing.  What if you look at it this way:  What if they're not drawn to him?  What if they're rushing at him to beat him to death?  He has marked himself, and they figure that one murder shared among them is worth not having to hear any more goddamn Crossfit stories.


WWDC, Again, 2017 edition

Hey, it's time for another WWDC!  Granted, I haven't been doing iOS development in awhile, and find that I'm not eyeing the latest hardware as much as I used to, but it's still at least a little fun.

For a lot of people, there is a lot of fun and money to be had from the Apple Speculation Game.

For me, I don't care nearly so much.  Historically, I have bought iPhones every 3 years, and iPads nearly as often.  My most recent iPhone is a 6S, so, I probably won't buy a new phone in this coming year.

But here's what I hope for:
-An iPhone 6S,
-Retaining the headphone jack,
-With more storage available,
-Faster would be fine, but isn't required,
-And rather than be thinner,
-Make the front and back flush with the thickest part (the camera),
-Taking up any extra space with battery.

There.  That's it for iPhone.

I love my 6S.  It's height and width are fine.  I like having a Lightning connector as well as a headphone jack.  I use my headphone jack REGULARLY.  I have several different pairs of headphones.  I often swap what pair of headphones is on my head into a different device while sitting at work; I use different headphones for different things.  Likewise, I may swap what headphones are in my device.

Bluetooth does not give me that flexibility.  The cords don't bother me that much.  I will probably buy a nice pair of Bluetooth headphones in the next year or so, but I don't want it to be my only option.

As far as the body being flush on front and back, I hearken back to my iPhone 5 (as well as the 4/4S and 5S phones).  My 6S is the first phone that I felt that I needed a case on it.  I had my 3GS and 5 on my person day-in and day-out for each of their 3-year lives.  While the backs were a little worn, that didn't bother me.  I loathed the idea that I would have to make the device thicker just to protect something that I had no intention of selling, so I didn't need to protect it.  They each suffered a couple falls, but nothing damaging.

My 6S, on the other hand, drove me nuts, because the camera sticks out.  The phone does not lie flat on a table.  So, in order to keep from damaging the camera, or causing stress to the phone when laying it on a table repeatedly, I bought a case.  I got a leather case which I'm quite pleased with, but I hate that I needed it.

I would much rather have a thicker phone with better battery life.

Apple's product lineup from this last year disappointed me.  I didn't care about the iPhone 7, but I wasn't going to get a new iPhone unless my current one broke.  But I wanted to buy a new Mac Laptop, or a cheap laptop, and an iMac.  Typically I would buy the mid-level 15" MBP, but this year I'd intended to buy a pretty much maxed-out 13".  But then Apple "Innovated".  "Bravely."

I don't know anyone who cares about the touch-bar.  I know a lot of people who care about a goddamn Escape Key.  I care about the Escape Key.

I know people who want an Apple Desktop.  I was ready to buy an Apple Desktop.  Guess who didn't buy an Apple Desktop.

In fact, I was so disgusted by Apple's lineup, I went all the way around, and found what is almost my ideal setup:  A Razer Stealth Blade with the Razer Core.  This is an Ultrabook, paired with a Thunderbolt 3 Dock that allows me to run a desktop GPU.  I love this setup.

My two complaints are 1) the trackpad isn't as nice as Apple's, and 2) it's running Windows.  Now, this isn't a knock on Windows, per se; I had administered Windows for a long time.  I can make it work.  But I'd rather be running MacOS, by a long shot.  Aside from gaming, my main application categories are a web browser, terminal, and text editor.  Editors and browsers are fine on Mac, but I want ZSH with oh-my-zsh, my .zshrc, and a Unix toolchain.  Yes, I can install a *nix distro on it, but I'd rather have the MacOS without having to jump through a shitload of hoops.

I'm sorry, but Synaptics is not nearly as good as Apple's touchpad.  I wish it weren't the case.

The one upside is that the number of usable games in my Steam library doubled immediately, and I've been able to play a fair number of games that used to be completely inaccessible to me before.

Too bad Apple couldn't provide something that I could use.  I needed a laptop, but all Apple provided were severely compromised options.

Maybe this year will have better options.


Dear Vendors

Dear Vendor,

Since I didn’t see an unsubscribe link, I replied with the subject changed to “Unsubscribe”.

That didn’t mean reply some more.

When I replied to that with the subject and body changed to “Unsubscribe”, that was a less-subtle hint.

When you reply to that (maybe including a quote or some byline of mine) not along the lines of “sorry to trouble you”, I read that as “please block and report me as spam."

I know that you're a person with a job to do, but when I express a lack of interest, please take the hint.  Let's not waste both of our time.


That Product Team Really Brought The Room Together

As with last year, I participated in SysAdvent again, a tradition of Systems Administrators to submit to write a blog article of their choosing.  Similar to a Conference, a Call for Proposals is published, and if interested, you propose a Topic (a title and brief description are all that are required, if I recall correctly.  My proposal was accepted, an editor was assigned, and due dates were set.

I'd had a lot of notes of things that I wanted to say, but I ended up struggling with constructing a coherent narrative, but lots of smallish topics that would be highly overlapping in a Venn diagram, but didn't present linearly in my mind.  Again, being something of a followup of last year's article/talk, there's a lot of related material, but also a lot omitted for time and space reasons.  (I needed to end it _somewhere_...)

Again, I offer my thanks to my editor Cody and the rest of the SysAdvent team for maintaining this tradition, and I sincerely appreciate the work that goes into keeping it going.  While I'd had this bunch of ideas floating around in my head (largely as a conference presentation), it was their work that made me sit down and write it out as prose, rather than a slide deck.

Now, with permission from the author, I present:  

Day 23 - That Product Team Really Brought The Room Together

Written by: H. “Waldo” Grunenwald (@gwaldo)
Edited by: Cody Wilbourn (cody@codywilbourn.com)

There are plenty of articles talking about DevOps and Teamwork and Aligning Authority with Responsibility, but what does that look like in practice?
Having been on many different kinds of teams, and having run a Product Team, I will talk about why I think that Product Teams are the best way to create and run products sustainably.


Yes, (yes I did). And I believe every word of it. I consider Product Teams to be a definitive implementation of “Scaling DevOps” which so many people seem to struggle with when the number of people involved scales beyond a conference room.
To my mind, Product Teams are the best way to ensure that responsibility is aligned with authority, ensuring that the applications that you need are operated sustainably, and minimizes the likelihood that a given application becomes “Legacy”.

What do you mean “Legacy”?

There is a term that we use in this industry, but I don’t think that I’ve ever seen it be well-defined. In my mind, a Legacy Product is:
  1. Uncared For: Not under active development. Any releases are rare, using old patterns, and are often the result of a security update breaking functionality, causing a fire-drill of fixing dependencies.
  2. In an Orphanage: The people who are responsible for it don’t feel that they own it, but are stuck with it.
If there is a team that actively manages a legacy product, they might not be really equipped to make significant changes. Most of the time they are tasked only with keeping this product barely running, and may have a portfolio of other products in similar state. This “Legacy Team” might have some connotation associated with it of being “second-string” engineers, and it might be a dumping ground for many apps that aren’t currently in active development.

What are we coming from?

The assumed situation is there is a product or service that is defined by “business needs”.
A decision is come to that these goals are worthwhile, and a Project is defined.
This may be a new product or service, or it may be features to an existing product or service. At some point this Project goes into “Production”, where it is hopefully consumed by users, and hopefully it provides value.

Here’s where things get tricky.
In most companies, the team that writes the product is not the same team that runs the product. This is because many companies organize themselves into departments. Those departments often have technical distinctions like “Development” or “Engineering”, and “Quality Assurance”, and an “Operations” and/or “Systems” groups. In these companies, people are aligned along job function, but each group is responsible for a phase of a product’s lifecycle.
And this is exactly where the heart of the problem is:
The first people who respond to a failure of the application aren’t the application’s developers, creating a business inefficiency:
Your feedback loop is broken.

As a special bonus, some companies organize their development into a so-called “Studio Model”, where a “studio” of developers work on one project. When they are done with that project, it gets handed off to a separate team for operation, and another team will handle “maintenance” development work. That original Studio team may never touch that original codebase again! If you have ever had to maintain or operate someone else’s software, you might well imagine the incentives that this drives, like assumptions that everything is available, and latency is always low!
See, the Studio Model is patterned after Movie and Video Game Studios. This can work well if you are releasing a product that doesn’t have an operational component. Studios make a lot of sense if you’re releasing a film. Some applications like single-player Games, and Mobile Apps that don’t rely on Services are great examples of this.
If your product does have an operational component, this is great for the people on the original Studio team, for whom work is an evergreen pasture. Unfortunately it makes things more painful for everyone who has to deal with the aftermath, including the customers. In reality it’s a really efficient way of turning out Legacy code.
Let’s face it, your CEO doesn’t care that you wrote code real good. They care that the features and products work well, and are available so that they bring in money. They want an investment that pays off.
Having Projects isn’t a problem. But funding teams based on Projects is problematic. You should organize around Products.


Simply put, a Product Team is a team that is organized around a business problem. The Product Team is comprised of people such that it is largely Self-Contained, and collectively the team Owns it’s own Products. It is “long-lived”, as the intention behind it is that the team is left intact as long as the product is in service.
Individuals on the team will have “Specialties”, but “that’s not my job” doesn’t exist. The QA Engineer specializes in determining ways of assuring that software does what’s expected to. They are not responsible for the writing of useful test cases, but they are not limited to the writing of tests. Notably, they’re not solely responsible for the writing of tests. Likewise for Operations Engineers, who have specialties in operating software, infrastructure automation, and monitoring, but they aren’t limited to or solely responsible for those components. Likewise for Software Engineers…
But the Product Team doesn’t only include so-called “members of technical staff”. The Product Team may also need other expertise! Design might be an easy assumption, but perhaps you should have a team member from Marketing, or Payments Receivable, or anyone who has domain expertise in the product!
It’s not a matter of that lofty goal of “Everyone can do everything.” Even on Silo teams, this never works. This is “Everyone knows enough to figure anything out“, and ”Everyone feels enough ownership to be able to make changes."
The people on this team are on THIS team. Having or being an engineer on multiple teams is painful and will cause problems.

You mentioned “Aligning Authority with Responsibility” before…

By having the team be closely-knit, and long-lived, certain understandings need to be had. What I mean is that if you want to have a successful product, and a sustainable lifecycle, there are some understandings that need to take place with regards to the staffing:
  • Engineers have a one-to-one relationship to a Product Team.
  • Products have a one-to-one relationship with a Product Team.
  • A Product Team may have a one-to-many relationship with it’s Products.
  • A Product Team will have a one-to-one relationship with a Pager Rotation.
  • An Engineer will have a one-to-one membership with it’s Pager Rotation.
Simply put, having people split among many different teams sounds great in theory, but it never works out well for the individuals. The teams never seem to get the attention required from the Individual Contributors, and an Individual Contributor is in a position of effectively doubling their number of bosses having to appease them all.


Some developers might balk at being made to participate in the operation of the product that they’re building. This is a natural reaction.
They’ve never had to do that before. Yes, exactly.
That doesn’t mean that they shouldn’t have to. That is the “we’ve always done it this way” argument.

This topic has already been well-covered in another article in this year’s SysAdvent, in Alice Goldfuss’ “No More On-Call Martyrs”, itself well-followed up by @DBSmasher’s “On Being On-Call”.
In this regard, I say is that if one’s sleep is on the line - if you are on the hook for the pager - you will take much more care in your assumptions when building a product, than if that is someone else’s problem.
The last thing that amazes me is that this is a pattern that is well-documented in many of the so-called “Unicorn Companies”, who’s practices many companies seek to emulate, but somehow “Developers-on-Call” always is argued to be “A Bridge Too Far”.
I would argue that this is one of their keystones.


Before I talk about anything else, I have to make one thing perfectly clear. If you have a role in Functional Leadership (Engineering Manager, Operations Director, etc), your role will probably change.
In Product Teams, the Product Owner decides work to be done and priorities.
Within the team you have the skills that you need to create and run it, delegating functions that you don’t possess to other Product Teams. (DBA’s being somewhat rare, and “DB-as-a-Service” is somewhat common.)
Many Engineering and Operations managers were promoted because they were good at Engineering or Ops. Unfortunately it’s then that it sets in that, in Lindsay Holmwood’s words, “It’s not a promotion, it’s a career change”, and also addressed in this year’s SysAdvent article “Trained Engineers - Overnight Managers (or ‘The Art of Not Destroying Your Company’)” by Nir Cohen.
How many of you miss Engineering, but spend all of your time doing… stuff?
Under an org that leverages Product Teams, Functional Leaders have a fundamentally different role than they did before.

Leadership Roles

Under Product Team paradigm, Product Managers are responsible for the work, while Functional Managers are responsible for passing of knowledge, and overseeing the career growth of Individual Contributors.
Product ManagersFunctional Managers
Owns ProductIC’s Professional Development
Product DirectionCoordinate Knowledge
Assign Work & PriorityKeeper of Culture
Hire & Fire from TeamInvolved in Community
Decide Team StandardsBullshit Detector / Voice of Reason

Product Managers

The Product Manager “Owns the Product”. They are ultimately responsible for the product successfully meeting business needs. Everything else is in support of that. I must stress that it isn’t necessary that a Product Manager be technical, though it does seem to help.
The product owner is the person who understands the business goals that knowledge and those stakes, they assign work and priorities such that it’s aligned with those business goals.
Knowing the specific problems that they’re solving and the makeup of their team, they are responsible for hiring and firing from the team.
Because the Product Team is responsible for their own success, and availability (by which I mean, of course, the Pager), they get to make decisions locally. They get to decide themselves what technologies they want to use and suffer.
Finally, the Product Manager evangalizes their product for other teams to leverage, and helps to on-board them as customers.

Functional Managers

At this point, I expect that the Functional managers are wondering “well what do I do?” Functional Managers aren’t dictating what work is done anymore, but there is still a lot of value that they bring. Their job becomes The People.
I don’t know a single functional manager who has been able to attend to their people’s professional development like they feel that they should.
Since technology decisions are made within the Product Team, the Functional Management has a key role in coordinating knowledge between the members of their Community, keeping track of who’s-using-what, and the relevant successes and pitfalls. When one team is considering a new tool that another is using, or a team is struggling with a tech, the functional manager is well-equipped for connecting people.
Functional Managers are the Keepers of Culture, and are encouraged to be involved in Community. That community-building is both within the company and in their physical region.
Functional managers are crucial for Hiring into the company, and helping Product Managers with hiring skills that they aren’t strong with. For instance, I would run a developer candidate by a development manager for a sanity-check, but for a DBA, I’d be very reliant on a DBA Manager’s expertise and opinion!
Relatedly, the Functional Manager serves as a combination Bullshit Detector and Voice-of-Reason when there are misunderstandings between the Product Owners and their Engineers.

The Reason for Broad Standards

Broad standards are often argued for one of two main reasons: either for “hiring purposes”, where engineers may be swapped relatively interchangably, or because there is a single Ops team responsible for many products, who doesn’t have ability to cope with multiple ways of doing things. (Since any one Engineer might be called upon to solve many apps in the dark of the night.)
Unfortunately, app development can often be hampered by those Standards that don’t fit their case and needs.
Hahahaha I’m kidding! What really happens is that Dev teams clam up about what they’re doing. They subvert the “standards” and don’t tell anyone, either pleading ignorance or claiming that they can’t go back and rewrite because of a deadline. Best case is that they run a request for an “exemption” up the flagpole, where Ops gets Over-riden. And Operations is still left with a “standard” and pile of “one-offs”.

Duplicate Effort

Another claimed reason for broad “Standards” is to “reduce the amount of duplicated effort”. While this is a great goal, again, it tends to cause more friction than is necessary.
The problem is the fallacy that comes from assuming that the way that a problem was solved for one team will be helpful to another. That solution may be helpful, but to assume that it will, and making it mandatory is going to cause unnecessary effort.
At one company, my team ran ELK as a product for other teams to consume. A new team was spun up, and asked about our offerings, but asked my opinion of them using a different service (an externally-hosted ELK-as-a-Service). I was thrilled, in fact! I want to see if we were solving the problem in the best way, or even a good way, and to be able to come back later for some lessons-learned!

Scaling Teams

At some point, your product is going to get bigger than everyone can keep in their head. It may be time to split up responsibilities into a new team. But where to draw boundaries? Interrogate them!
A trick that I learned a long time ago for testing your design in Object-Oriented Programming is to ask the object a question: “What are you?” or “What do you do?” If the answer includes an “And”, you have two things. This works well for evaluating both Class and Method design. (I think that this tidbit was from Sandi Metz’s “Practical Object-Oriented Design in Ruby” (aka “POODR”), which I was exposed to by Mark Menard of Enable Labs.)

What Doesn’t Work

Because this can be a change to how teams work, it’s important to be clear about the rules. If there is a misunderstanding about where work comes from, or who the individual contributors work for, or who decides the people who belong to what team, this begins to fall apart.
Having people work for multiple sets of managers is untenable.
Having people quit is an unavoidable problem in any company. Having a functional manager decide by themselves that they’re going to reassign one of your people away from you is worse, because they’re not playing by the rules.

WARNING: Matrix Organizations Considered Harmful

If someone proposes a Matrix Org, you need to be extremely careful. It’s important that you keep a separation of Church and State. Matrix Organizations instantly create a conflict between the different axes of managers, with the tension being centered on the individual contributor who just wants to do good work. A Matrix Org actively adds politics.
All Work comes from Product Management. Functional Management is for Individual Careers and Sharing Knowledge.
This shouldn’t be hard to remember, as the Functional Leaders shouldn’t have work to assign. But it will be hard, because they’ll probably have a lot of muscle-memory around prioritizing and assigning work.
Now, I’m sure a lot of you are skeptical about how a product team actually works. You might just not believe me.
If you properly staff a team, give them direction, authority, and responsibility, they will amaze you.


As with anything, the hardest thing to do is begin.

Identifying Products

An easy candidate is a new intiative for development that may be coming down the pipeline, but if you aren’t aware of any new products, you probably have many “orphaned” products already running within your environment.
As I discussed last year, there are plenty of ways of finding products that are critical, but not actually maintained by anyone. Common places to look are tools arounddevelopment, like CI, SCM, and Wikis. Also commonly neglected are what I like to call “Insight Tools” like Logging, Metrics, and Monitoring/Alerting. These all tend to be installed and treated as appliances, not receiving any maintenance or attention unless something breaks. Sadly, it means that there’s a lot of value left on the table with these products!

Speaking with Leadership

If you say “I want to start doing Product Team”, they’re going to think of something along the lines of BizDev. A subtle but important difference is to say that you want to organize a cross-functional team, that is dedicated to the creation and long-term operation of the Product.
I don’t know why, but it seems that executive go gooey when they hear the phrase “cross-functional team”. So, go buzz-word away. While you’re at it, try to initiate some Thought Leadership and coin a term with them like “Product-Oriented Development”! (No, of course it doesn’t mean anything…)
What you’re looking for is a commitment to fund the product long-term. The idea is that your team will solve problems centered around a set of problems. The team is of “Your People”, that becomes a “we”. Oddly enough, when you have a team focused and aligned together, you have really built a capital-T “Team”.


The Product Team should be intact and in-development as long as the product is found to be necessary. When the product is retired, they product team may be disbanded, but nobody should be left with the check. Over time, the features should stabilize, and the bugs will disappear, and the operation of the application should stabilize to a low level of effort, even including external updates.
That doesn’t mean that your engineers need to be farmed out to other teams; you should take on new work, and begin development of new products that aid in your space!


I believe that organizing work in Product Teams is one of the best ways to run a responsible engineering organization. By orienting your work around the Product, you are aligning your people to business needs, and the individuals will have a better understanding of the value of their work. By keeping the team size small, they know how the parts work and fit. By everyone operating the product, they feel a sense of ownership, and by being responsible for the product’s availability, they’re much more likely to build resilient and fault-tolerant applications!
It is for these reasons and more, that I consider Product Teams to be the definitive DevOps implementation.


I’d like to thank my friends for listening to me rant, and my editor Cody Wilbourn for their help bringing this article together. I’d also like to thank the SysAdvent team for putting in the effort that keeps this fun tradition going.


If you wish to discuss with me further, please feel free to reach out to me. I am gwaldo on Twitter and Gmail/Hangouts and Steam, and seldom refuse hugs (or offers of beverage and company) at conferences. Death Threats and unpleasantness beyond the realm of constructive Criticism may be sent to:

c/o FBI Headquarters  
935 Pennsylvania Avenue, NW  
Washington, D.C.  


On The DevOps Drinking Game

Just for laughs, as part of my "Fear and Loathing in Systems Administration" conference talk, I saw a real gap in our community's resources.  My research turned up nothing, so I took it upon myself to "be the change that I want to see in the world.

Thus was born a new GitHub project: The DevOps Drinking Game.

Enjoy, and Be Safe!