Life’s Decisions as Computational Problems

I recently finished my most recent non-fiction read, the excellent Algorithms to Live By – The Computer Science of Human Decisions, by Brian Christian and Tom Griffiths.

The overall idea of the book is clever: take a series of human decisions, map them to computational problems, investigate the historic and current computer science on those problems, and then discuss the findings. Extrapolate the findings onto other related problems, and hopefully learn something.

For example, the book opens by discussing apartment hunting, and maps the process of finding an apartment in San Francisco to a series of problems known as “Optimal Stopping.” After discussing (in tones which should be comfortable to most of my readers) the computational science of this family of problems, the authors discuss other optimal stopping problems like serial monogamy and finding a parking spot.

What can the start of the art as relates to optimal stopping teach us about those problems? How should we think about those problems with this in mind?

Don’t get me wrong — this is not a book about how to approach your decisions like a robot, or even Mr. Spock. The goal isn’t to take humanity out of the equation, it’s to provide some information to factor into the process, some formality into how to think about some of the problems so we understand what we’re actually doing when we pick a parking spot, for example.

The same sort of treatment is given to other families of problems, including scheduling, sorting, and caching. Problem-solving strategies like relaxation (in the computational sense), randomness, and game theory are also given attention, again, looking at real-world examples.

When I set out to read this book, I knew all of the above, and it was already enough to get me interested. What I didn’t expect was the emotional depth of some of the discussions. How does a discussion of the explore-exploit tradeoff as relates to picking a new restaurant versus visiting an old favorite relate to our own mortality and sense of it? How does the way we frame questions and present decisions represent cognitive selfishness or generosity? When is “good enough,” in fact, good enough?

Math and science junkies should be warned that this isn’t a book that breaks down the equations and proofs. The authors will tell you that computer science has proven specific things, but doesn’t explain the proofs. This makes the book much more readable, and honestly if you’re the audience who could understand the proofs it’s probably worth your while to review the bibliography and dive into the sources yourself.

As far as brain candy goes, I highly recommend this one. It’ll get you thinking in a few new directions. It might even rekindle your love of computer science.

Yeah, but do I really need to patch this one?

A big part of my “day job” over the past few years has been to act as the security advocate for a number of Dell EMC products. This includes a variety of activities, both proactive and reactive. One common activity is handling the life cycle of a security vulnerability through discovery, triage, remediation, and disclosure. Most (but not all) of the vulnerabilities I deal with are a result of embedded components which are updated periodically for security reasons.

There’s a common response I get when vulnerabilities, and their remediation, are disclosed. “Do I really need to worry about this one?”

When I put my corporate hat on, the answer of course is, “Yes. We advise you to <blah blah blah> immediately.”

But you know and I know that security vulnerabilities come in a wide variety of flavors.

So what’s the real answer?

Continue reading →

My thoughts on Disrupted

During my commute (and while doing yardwork), I listen to books using Audible. Unlike everyone else who mentions Audible, I don’t have any advertising affiliation there, so I can’t give you a link to sign up. Sorry, but I’m guessing you can figure it out :).

Recently I wrapped up Dan Lyons’s bestseller Disrupted: My Misadventure in the Start-Up Bubble. Dan Lyons, who found himself out of work after a lengthy media career, took a job at a Boston-area start-up (HubSpot) where the average age was half of his, and wrote a book about the experience. It’s a great read, even more so if you’re in the industry in any way (and doubly if you’re over 40).

As Lyons has worked as a writer on HBO’s “Silicon Valley,” I came in expecting some wacky hi-jinks and light-hearted but pointed criticism at the ridiculousness of start-up culture. And while that is present, the overall package is much darker, and it’s worth experiencing it for yourself. To make sure I had a bit more context, as soon as I finished the book I read some of other press about HubSpot, including their official response to the book (posted by one of their founders, in a LinkedIn post).

As someone who cares about how people are managed, a few things stood out, and I felt they were worth writing about here. As a disclaimer, I’m talking about how Lyons portrays HubSpot. I have no direct experience with the company, and I am not assuming that what he’s relating is actually happening.

People Management

Lyons severely criticizes the management culture at HubSpot throughout the book. From individual line management (where young men with no management skills or experience do a poor job of managing others) to executive management (where a frat-boy sales culture seems to be encouraged by executives who value “cultural fit” without thinking too hard about how that impacts diversity and inclusion), everyone has some share of blame. The relationship between Lyons and his direct management is always portrayed as clunky, and sometimes downright toxic. In passage after passage, I found myself wondering why his management couldn’t handle any given situation better. So much of the difficulty could have been avoided if management had been receptive, open, transparent, and supportive.

Of course, we all know the people-skills side of management is not given enough weight in general, and this is especially true in a fast-growing cut-throat environment.

I’ve said over and over in my career that the first lesson I had to learn as a young manager was that not everyone likes to be managed like I do. Perhaps, in a very homogeneus workforce, this isn’t as easy to learn early on. This may especially be true if that homogenus workforce is inexperienced and not very demanding of their management, which it sounds like was the case at HubSpot. Maybe in that situation, you can put people into management roles without much coaching, and not have it backfire spectactularly … until you have someone join the team who is outside the norm. And when that happens, saying it’s a cultural mismatch is a bit of a cop-out, isn’t it?

Human Resources

This brings me to the second thing that jumped out at me. I’ve always felt that there’s an inherent conflict of interest when you have to deal with HR about anything sensitive about the company itself, because disrupting the corporate norms isn’t necessarily in HR’s interest, though it may be in your interest. For example, how many harassment claims seem to get shoved under the carpet at companies because it’s easier to shuffle people around than replace one executive?

This conflict seems to be even greater when the company is a start-up and so much of each person’s compensation is tied to stock which has no value yet, but whose value will eventually derive completely from shareholder confidence in the company. As an HR person (perhaps the only HR person) in that company, what’s your incentive (besides your own ethical code) to dig too deeply into something that may hurt the company?

So, in the book, when Lyons asks HR “Do we have any statistics about diversity in our workforce,” and they answer, “Why?”, it’s partially because there isn’t a clear separation of role here for HR. HR is proactively acting as a mix of HR, PR, and Legal. This is exceptionally true in a start-up environment but it’s not unique to that. I don’t know the best way to address this, except that in countries where strong legal protections exist for workers’ rights, it’s very much in the company’s best interest to adhere to those laws, and that falls directly into HR’s area of expertise (i.e. protecting the company from itself). It’s unclear to me, though, whether American voters have any strong desire to press forward in that realm.

Diversity and Inclusion

Speaking of diversity brings me to a tougher question in the book, and perhaps its central thesis. Lyons spends significant time discussing ageism at HubSpot and in tech in general. His points are all valid, and everybody should read them and absorb their implications.

I couldn’t help, though, being a little uncomfortable with some of Lyons’s own blindness towards inclusive behaviors. While talking about how uncomfortable older workers with families might be in the youth-oriented start-up culture, he hits the nail on the head. But then he brags about how confrontational and brash the newsrooms of his early career were, and lauds the raunchy jokes he’s free to make as a writer in Hollywood. It leads me to wonder if he’s really concerned about inclusion on principle, or just making sure he’s included. Because I’ve worked with many people who would be as uncomfortable in his dick-joke writing room or his confrontational newsroom as he was in the “everything is awesome” frat-house kindergarten.

Corporate Kool-Aid

The final thing I’ll mention which rubbed me the wrong way in the book was how Lyons portrays what I tend to think of as fairly mainstream corporate “stuff.” Whether it’s intentionally softened jargon or being terminated upon giving your notice, Lyons acts surprised at standard operating procedure for a 21st century company. I can understand being surprised at these things if you had been living in a newsroom bubble for the past 30 years, but Dan Lyons covered the tech industry for a living for a good chunk of his career. He went to conferences, interviewed corporate PR drones, and generally absorbed the mainstream corporate world for years. I find it unlikely he was as surprised by everything he encountered as he acts when he writes about it. I wonder if he’s intentionally playing this up a bit for an audience who is coming from further outside. I don’t blame him if he is, but it does impact the readability a little.

Overall, I found the book darkly fascinating. It was addicting, even though some days when I shut off the audio player I was stressed out and feeling depressed about our industry’s future. It’s definitely good reading, but it’s worth reading it with an eye towards your own workplace environment and how you can avoid falling into the pitfalls that obviously befell both HubSpot and Dan Lyons himself.

Technical momentum and shifting tides

I wrote some time back about how we all write throw-away code, how applications have life spans and you don’t want to work on the same code for two decades. Recently I was discussing this topic from a slightly different angle, in terms of how a product team’s technical culture has momentum and how important it is to be able to shift that momentum over time. I speak here of the collection of tribal wisdom and best practices that influence the technical decisions of a team over time, the technical values that the primary decision makers rely on when steering the ship.

Continue reading →

Picking up the workplace litter

We all want to work in better workplaces. Even people who have checked out, who have no connection to their work beyond their paycheck, could come up with ways their work environment could improve, or could get worse.

We all want it, but not all of us believe it can happen, and many of us don’t feel it’s our responsibility. And so it reminds me of how people approach the environment. As we head into spring here in New England, my mind shifts to the outdoors, and I can’t help but map the behaviors I see outdoors to the behaviors in the workplace.

Continue reading →

Cloudpets and culture

As a parent of an elementary-school child, I end up seeing a lot of children’s television. One of the most popular shows in our home is Teen Titans Go!, a brilliantly absurd comedic show about teen superheroes in the DC universe.

Since I see a lot of kids’ TV, I see a lot of kids’ commercials. One commercial I saw frequently last year was for Cloudpets, little teddy bears you could use to send voice messages to your kids from afar. The commercials showed a father who had to travel for business, a distant grandmother, and more all recording messages on their phones that their kids would listen to via their bears.

The bears themselves were not connected to the net. All messages would first be downloaded to a parent’s phone, and once approved, would be sent to the toy via bluetooth.

I immediately felt that this technology was an incredible waste of money (if you have connectivity, why not just call or send voice messages), but so are many toys, so I shrugged it off. I didn’t think of cloudpets again until last week, when Troy Hunt posted about yet another high profile breach (or rather, leak). I won’t spend a lot of characters outlining the leak; Troy does a great job of summing it up and he deserves the clicks.

Continue reading →

Shaping identity through naming

A few years back, during a project kickoff, we organized our engineers into teams, each intended to solve specific problems and deliver subsets of the overall project functionality.  Experimenting with some Agile concepts, we invited the teams to name themselves.

The team I was leading took this opportunity seriously; we campaigned for names we liked, we had suggestions both serious and humorous, and in the end we voted.  Our team name became Daemon.  We adopted the FreeBSD mascot for our informal internal communications, and often accompanied our team name with the following quote someone found online describing Unix daemons:

Thus, a daemon is something that works magically without anyone being much aware of it.

Over the next year, our team shifted to align with that definition.  We took pride in low bug counts, in delivering services that “just worked” and required very little configuration or setup.  Our focus shifted away from administrative use cases and focused more on infrastructure.  We sought out work that aligned with our mission.

In other words, naming ourselves helped define and shape our behavior.

We obviously took the name because we were proud of our ability to quietly deliver high quality work.  But that in turn shaped us to focus more on the traits we took from our name.

As another example, I’ve noticed this same pattern when defining strengths in performance reviews. Once someone names a strength, they are more apt to think of that as a character trait and seek out opportunities to prove it again.  Likewise, once the team leadership begins to discuss a person in certain terms, those terms may follow that person around their career (for better or worse).

So naming (or even labeling) can be powerful, and we should respect that.  Use it to your own advantage (the ever-present “personal brand”), help your teams use it to define their mission — but use it cautiously when defining others.

The strength of silence

I don’t remember the first time I was told about the power of silence in conversation, but I’m pretty sure it was one of my first management classes. I’ve run into the concept both formally and informally many times since then, and the usual context is somewhat adversarial.

For example, when performing a job interview, if you aren’t that impressed with an answer, wait a few beats. Does the candidate fill the silence? Do they elaborate? And does their answer dig a deeper hole or do they begin to climb out?  You can learn a lot with this technique: someone who immediately realizes the impact of their words and tries to work the conversation back in the right direction is showing a great deal of emotional intelligence.  Someone who manages the same feat but only after being prompted and guided is in a different place (this may not be a bad thing; it depends on what you’re looking for).

Continue reading →

Let others help you

I recently sat through a meeting and got a little riled up.  I may come across as pretty low key, but I take some things seriously, and every once in a while my idealistic self threatens to take over.

I was in the middle of writing up a charged email on the subject — in fact, I had edited it four times to make it seem as calm as possible while still getting my point across — when a colleague came by for a chat.  I mentioned in passing that I was thinking of sending this email, and he just shook his head.  “Not a good time,” he said.  I was frustrated, but nodded, and saved the draft and picked up something else to work on.

Continue reading →

The self-appraisal as a business communication

Once more, I find myself writing about the self-appraisal, that much maligned part of the annual performance review so common in our corporate circles.  Can you believe it’s been eight years since I first wrote about the self-appraisal process?  My own approach to this topic has evolved considerably over time, and so has the corporate environment in which I write them.

Here at Dell EMC, the biggest difference between self-appraisals in 2009 and 2017 is that we no longer make use of open-ended documents. Instead of having unlimited space to wage a marketing campaign for ourselves, we’re forced to focus our thoughts on each question into just a few sentences. We often joke that we’re tweeting our strengths and weaknesses, and the comparison is apt.  With a strict character limit, every word counts, which makes strong communication skills vital in producing an effective self-appraisal.

I don’t have any “tricks” here, but I make a point to think of my self-appraisal as a piece of business communication. As with any such communication, there are some tried and true keys to effectiveness. Continue reading →