My first (and only) axiom of culture

April 13, 2016

Like all my other posts, this post is entirely my own opinion and not may not reflect the opinions of my employers, past and present.

A week ago, I finished reading Dan Lyons’ real-life tragic comedy “Disrupted: My Misadventure in the Startup Bubble“. It has left me uneasy. Among other tech startup evils, Lyons turns the spotlight on HubSpot’s culture – with its own cult-like lingo, ridiculous rituals, and messianic rhetoric that turns HubSpot’s commodity products into the salvation of mankind.

Under the lashes of Lyons’ trademark wit, it is uneasy to be sympathetic to the torrent of B.S. in which HubSpot seems to drench its hapless employees. But I have seen many of the phenomena Lyons describes at other organizations: good companies run by decent, well-meaning people. On the other hand, I have seen leaders, even those without any formal managerial training create cultures that everyone was happy to be a part of without resorting to gimmicks, rhetoric, or any other device that Lyons skewers in his tome.

I have concluded that those who “win at culture” do so because they understand, perhaps at an intuitive level, this one core principle:

Culture cannot be “created”, “established”, or “designed”. It can, however, be seeded and allowed to grow.

To illustrate the point, let’s look at how companies typically try to “establish” culture.

Wisdom + Plaques = Bullshit

When I worked in what became a subsidiary of a subsidiary of eBay, we had plaques with the eBay’s “shared commitments” and “shared behaviors” on the wall of every conference room. These included great nuggets of wisdom, such as “Be the customer”, “Debate, decide, and deliver”, “Enable talented people to thrive”, etc. As far as I could tell, once introduced, these had absolutely no impact on how we approached products, people, or processes. In fact, after a few days – we stopped noticing the messages entirely, only pointing them out in new employee orientations or when they served as convenient punchlines (I, for one, can’t resist a convenient punchline).

But the plaques had another unwritten message: “we are your corporate overlords. We tell you what to think.” A shared commitment, behavior, or value does not need to be hung in on every wall. The fact that something is hung on a wall, phrased as a slogan or a snappy acronym, or written in a slide deck means that it is not shared. Rather, it is something that the leadership wants to impose and and beat into employees with repetition. And the only cultural values such misguided efforts can instill are distrust and cynicism.


Seeding Culture

Truly shared values, beliefs, and behaviors occur without being preached, promoted, or mandated. Leaders of an organization can, however, “seed” beliefs and behaviors by creating an environment where such beliefs and behaviors can thrive and grow organically. Some ideas that, in my experience, work:

  • Lead by example. If one of the values you want to seed in your organization is directness/honesty/transparency, then you need to demonstrate these values in practice. That means staying away from slogans, euphemisms, and white-washing. If faced with uncertainty, communicate the uncertainty.
  • Provide the tools. It’s easy to pay lip service to any value or goal, but if you actually want your organization to believe it and adopt it, you have to enable it to do so. For instance, with the directness/honesty/transparency goal above, you might provide an anonymous feedback mechanism for any employee to voice concerns without fear of retaliation.
  • Ask. Yep. Instead of making slogans, gimmicks, instructional activities, and other forms of bullshit, just ask your people for what you want. Do you want them to be honest and direct with you? Say, “please, tell us honestly if something concerns you. Here’s that anonymous suggestion box.” Another common startup example: Let’s say you want your organization to exude an aura of fun, a kind of casual friendliness and low-key atmosphere that a job candidate on a tour couldn’t resist. Why not just ask your employees? “Hey, guys, so what can we do to project that this is a fun place to work?” Note: this is decidedly not the same thing as taking unilateral steps from a leader’s perch to “make the place seem fun”. You’re not deceiving your employees with a facade, you’re asking them to help create the facade. They’re in on the scheme, and since they likely share your goal of wanting to attract the best candidates – and to create a fun environment – they’ll be only too happy to help.


Independence Day Time Warp

April 3, 2016

Let’s see how familiar you are with Java 8’s new Date/Time classes.

ZonedDateTime americasBirthday =
  ZonedDateTime.of(1776, 7, 4, 9, 1, 2, 3, ZoneId.of(“America/New_York”));

(I actually have no idea exactly at what time the Declaration of Independence was read that day, but that’s thoroughly beside the point).

So question: what does this print?


If you said “1776-07-04T13:57:04.000000003Z[UTC]“, you were right!

The withZoneSameInstant method applies the source date’s time zone’s offset and the target timezone’s offsets to produce an equivalent date in the target time zone. But a time zone’s offset is itself a function of the date. For example, today in summer, the offset of Eastern Standard time (identified as “America/New_York”) is -4. In Winter, it’s -5. And in 1776, the offset from UTC was…



Ok – so you’d expect it to be -5, since Daylight Savings Time had not yet been institutionalized. But how do you lose 3 minutes and 58 seconds? Java 8’s timezone definitions include sets of rules that compensate for “discontinuities” in local time. These discontinuities are quite common – each time you switch to daylight savings time you experience one.

And Java 8 will be happy to generate a complete list of these discontinuities for you:


And if you get the toString() of the first element in that list, you get your answer:

Transition[Overlap at 1883-11-18T12:03:58-04:56:02 to -05:00]

Java 8 records the offset jumping from -4:56:02 to -5:00:00 on November 18, 1883. Why that date? I’m assuming it’s because time zones were established on that date. I guess whatever the “clock of record” was in the newly-defined eastern time zone, it had to be set back almost four minutes to sync up with the rest of the U.S.

The next discontinuity comes three decades later:

Transition[Gap at 1918-03-31T02:00-05:00 to -04:00]

The very first changeover to Daylight Savings Time.



This may or may not have bitten me…

March 30, 2016

What does this print?

Screen Shot 2016-03-30 at 3.16.40 AM

Is Conway’s Law real?

March 19, 2016

Conway’s law:

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. –Melvin Conway

Are they? Sure, there is ample evidence to suggest that the architectural structure of software closely parallels the organizational structure of its creators, but this “mirroring” is a correlation, not a causation.

Consider ye olde three-tier web application architecture: there’s ye olde persistence tier, ye olde business logic (typically server) tier, and ye olde presentation tier (much of which dwells on the client side these days). Has the ubiquity of this architecture sprung forth from the inherent propensity of engineers to divide into UI, database, and server specialties… just because? Are the UI people just too hipstery to be tolerated by the backend folk? Do DBAs smell funny?

Or it is because the skills to be mastered by owners of these tiers are so numerous and discrete, that specializations in these tiers becomes practical and natural? On the database side, there is the complexity of organizing data, indexing data, replicating data, retrieving data all in a platform-specific way. On the UI side, there’s the ever-growing number of user form factors and a cannonade of web frameworks. If there weren’t enough hours in the day for one person to master all three tiers, wouldn’t specialization by tier be inevitable? And if the difference of skillsets required for specific tiers was greater than the difference of skillsets required for specific projects, wouldn’t teams naturally specialize by tier and not by project? I submit that the inherent complexity of software components and tiers forces contributors to specialize in dealing with those components and tiers. And it is this inevitable specialization that causes teams to organize in a manner that mirrors the organization of their respective components and tiers.

Specialization is nothing new. David Ricardo developed the theory of specialization by comparative advantage in 1817. It states, at its simplest, that if John is better at growing apples than he is at growing oranges, and Jane is better at growing oranges than she is at growing apples, then John should grow apples, Jane should grow oranges, and they should leverage each other’s output through trade. When they do, they operate at their peak combined economic efficiency.

All this begs an ominous thought: Conway’s Law has been used to rationalize organizing teams around developing microservices. But given the possibility that it is a false causation, should organizing teams around Conway’s Law be considered harmful? Dum dum dummmmm! (To be continued…)



REST is NOT bound to HTTP

August 29, 2012

I’m not sure why the connection of REST to HTTP is so commonly misunderstood, but after hearing an architect say REST is implemented with HTTP, I’ve had just about enough.

HTTP is a transfer protocol that implements the four verbs in REST (under different names). HTTP is thus a convenient foundation for RESTful services. It is not the only possible foundation. Wanna implement REST over JMS? Over CORBA? Over carrier pigeon? Go nuts!

Microsoft to PC users: you’re dumb!

March 13, 2012

A quick refresher, if you’ve been living under a rock for the past few months. Microsoft recently dropped a consumer preview of their next operating system, Windows 8. In Windows 8, desktop applications that you’re used to will be second-class citizens. They will not be allowed in the app store. Their small non-interactive icons will pale next to larger self-updating badges. The start menu that kept them tidy and organized for almost two decades will be gone. Apps that conform to Microsoft’s new touch-favoring user experience framework, Metro, will rule the day. A change this fundamental has to reflect new and significant assumptions about who the users are and what the users want. Based on what I’ve seen and read of Metro, here is what I think those assumptions are:

  • PC users really want a tablet. Oh, sure, you bought that big box with a monitor, a mouse, and a keyboard. But that’s not what you really want. You want a tablet. You want to touch that screen with your fingers, not use a precision pointing device. You bought that 32″ 2560×1440 monitor to have one app take up all of it. And typing? Who does that anymore? If God wanted you to type, he’d have given you twenty-six fingers, not ten!
  • PC users can’t walk and chew gum. You want to switch the tune in your media player while playing solitare? Ooof… that Solitare will be so distracting! Better tuck it away, just to be safe. Oh, alright, fine, you can keep your media player docked in a sidebar. But if you wanna respond to that instant message, someone’s gotta go!
  • PC users are content consumers, not content creators. All but the most simplistic content creation apps offer many tools that can be applied to the edited content non-linearly. These are often presented to the user via toolbar-like interfaces, dropdowns, and popup-menus. And since much tooling and information must be presented in a limited amount of space, it is impossible to provide the same breadth of tooling in a “touch-first experience” that Metro requires. Not to mention squeezing such an app into a sidebar – another Metro demand. So… whereas the competition comes with content creation apps for music, photos, and video out of the box, in Windows 8, these apps would not even be allowed in the app store.

Microsoft is neither the first nor the last platform vendor to limit the breadth of application possibilities in favor of a single, simple user experience. However, when users themselves are limited to being page-swiping badge-poking single-minded content-consuming couch potatoes, some resentment may occur. When a company treats its customers as simpletons, these customers may well turn around and walk away, mumbling “same to you”.

How not to recruit engineers

August 21, 2011

Today, this gem of an advertisement graced the sidebar of my Facebook page:

"Rejected by Google? Urbancode is your perfect rebound opportunities"

Really? I wonder what kind of engineer this company wants. The kind with the same skills, aptitudes, and background that Google wants? If so, they’ll get only the ones Google turns down. And if this company is looking for different assets than Google, then its ideal candidate(s) may not have been interested in working for Google in the first place. Either way, this ad will not bring in the candidates this company wants.


Get every new post delivered to your Inbox.