In Search of the Ideal Employer

I’ve had a great run working on the Mingle team for the past few years, but, as they say, all good things must come to an end. I’m looking at other opportunities both within the company and elsewhere. And because of this, I’ve had a bunch of discussions lately about the kind of place I’m looking for. As I troll the job listings, I’ve developed a rough scale of what domain the companies are in and therefore how much my personal values align with their missions.

Which brings me to:

Bill’s Organizational Scale of Social Impact (B.O.S.S.I.)

The core activities and products of the company…

  • (+3) explicitly improve the world for the less powerful elements of global society (Samasource, Codestarters)
  • (+2) explicitly improve the world for everyday first world people, perhaps by enabling the sharing or green economy (CityCarShare)
  • (+1) improve the world, perhaps as a byproduct of their primary goal (GoodreadsVeganCuts, HipCamp)
  • (0) don’t improve the world, but would broadly be seen as worthwhile. Perhaps the product is a tool that can be used for doing good, but not necessarily so. (Mingle, many companies in the U.S.)
  • (-1) don’t harm anyone directly, but probably the money and brain power expended, both by the employees and customers, would be best spent on something else. (far too many startups in S.F.)
  • (-2) encourage behaviors that may be anti-social, misogynist, excessively consumerist, exploitative, and so forth (the entertainment/pornography industries, casinos)
  • (-3) explicitly harm society and/or individuals directly and should really not exist. (the for-profit health system in the U.S., energy companies, defense contractors, &c)

In this simplistic scale, I have intentionally not addressed large companies, e.g. Sheinhardt Wig Company, that likely have elements of each in their various divisions.

What about you? Where does your company fit? What matters to you about what your company does?

The Fallacy of Agile Transformation

Last summer, I attended Agile 2013 in Nashville. Many of the talks were focused around the idea of “agile transformation,” where an organization following a traditional waterfall software development process switches to an agile methodology, almost always Scrum.

But how does this occur? Does it start small, from the bottom up, and evolve gradually over time? Not usually, or at least organizations following this approach aren’t talking loudly about it.

Instead what seems to happen frequently is that a leader in the organization, presumably fed up with late deliveries, cost overruns, or other issues where the blame could be pinned on the software development methodology, decides that it’s time to get with the times and “Go Agile!” They then seek out a new tool and its associated training to roll it out to their teams as if it were a new time card entry system.

At its worst, it all goes nowhere, vast amounts of time and money are wasted, and the “forward-thinking” leader is eventually thrown out along with their tools. People doing actual work learn the lesson that change is bad.

When it’s called a success, what happens is that teams adopt some of the popular practices, like standups, and they use new terminology. However, since they were told of the new way to work, rather than working it out on their own, they seldom internalize the underlying values. When they run into trouble, they assume they must be doing the sanctioned process wrong and seek out process-oriented solutions from external sources of information.

So if the results of these transformations are not usually ideal, why do organizations follow this approach? It seems to me that the people who conceive of and orchestrate the transformation treat the entire undertaking like a waterfall project, because that’s the world they know. They create a plan, mandate a particular process and/or tool, and set a date for completion. The alternative, empowering their teams to change the way the work and improve over time would take an uncertain amount of time with uncertain results.

As an example, there was an idea board posted that asked attendees to complete the sentence: “Agile will fail at my organization because…”

An organization who has realized that predictive approaches have limitations and decided to experiment in more adaptive ways of building software would not frame the question this way. A team that is learning how to be better every day as it incrementally delivers value is already succeeding, whether they are on day one or five years into their journey.

Unsubscribe me!

Tonight I checked my email inbox and found about 100 useless emails I didn’t even plan on reading. So instead of just deleting them as I usually do, I went on a marathon unsubscribing spree. This isn’t the first time I’ve done this and I’m sure it won’t be the last. Seeing many different interfaces for unsubscribing in quick succession made it apparent what makes for a good design.

Why is this important? While businesses might not directly care about someone unsubscribing since the unsubscriber is less likely to buy from the business again, it seems to me that making the unsubscription process painless makes a good last impression.  This in turn makes the unsubscriber more likely to become a customer again one day or even recommend the business to a friend.  To take myself as an example, just because I’m unsubscribing from the promotional emails from an online t-shirt store doesn’t mean I’ll never order from them again.

Unsubscribe Do’s:

  • Do make it a single click from the bottom of the email (no questions asked, no login needed, no retyping my email )
  • If you have different frequency options or types of mailings, make a giant button that gets me off all of them so I don’t have to read all the options

Unsubscribe Don’ts:

  • Don’t make me tell you why I’m unsubscribing (but an optional form after I unsubscribe is acceptable if you really care)
  • Don’t make me reply to the email to unsubscribe
  • Don’t make me send an email to a weird randomly named email address to unsubscribe (yes I mean you Conde Nast!)
  • Don’t make me notice that while your website is pretty, your email system is run off of a cgi-bin folder on a forgotten mainframe.  It should be polished and branded the same way you would any of your public content.  After all, it’s your last chance to convey the impression of professionalism and trustworthiness to me.
  • For god’s sake, don’t send me an email to confirm my unsubscription!


Experience at SOCAP12

SOCAP12, which stands for Social Capital Markets, was held this week at Ft. Mason, the rehabilitated military base overlooking picturesque San Francisco Bay.  It brings together organizations and individuals interested in social entrepreneurship, the idea that you can build a sustainable and profitable business model with a socially beneficial mission at its heart.  The company I work for, ThoughtWorks, believes strongly in this idea and its reflected in our Three Pillar Model (originally from Ben & Jerry’s).

While the conference mostly focused on social entrepreneurship in general, I mostly attended the tech-focused sessions.

 Continue reading

Highlights from SF Disrupt 2012

This past week I attended SF Disrupt 2012, a conference put on by startup news site TechCrunch.  Thirty or so startups presented their ideas, many for the first time publicly, to the audience.  These were trimmed down to finalists and then a final winner.  I only attended the first two days so I missed the excitement of the final voting.  However, I wanted to capture interesting ideas I saw while at the conference in this post.  This attempts to be more journalistic.  If you want more of a rant my feelings toward its startup culture, see my other post.

 Continue reading

The Status Quo Culture at SF Disrupt 2012

Despite its focus on disrupting the status quo, in many ways Disrupt was a reflection of the current culture rather than a message from the avant-garde. For example, the winning startup is solving the First World Problem of being too busy to take your car to a mechanic. However, if you watched carefully there were glimmers of hope from a parallel culture, one building solutions that will truly improve the world.

 Continue reading

Continuous integration equally applies to your dependencies

Preface: I don’t think I need to explain why continuous integration is A Good Thing.  If you don’t understand that, look elsewhere for nice explanations.

Continuous integration is a very beneficial process.  You integrate with every commit against the other devs working on the same codebase.  However, what about your application’s dependencies?  What about integrating with the Rails developers? Or the jQuery developers?  Don’t the same benefits apply?  I’ve been on quite a few teams and it seems like we treat external libraries very differently from our own (or our own organization’s) code.  We fit the mold of what the Build Doctor calls “reluctant integrators.”  And I think this is actually a really dangerous process to follow, for many of the same reasons that practicing discontinuous integration is a bad idea with your own codebase.  It might seem nice and comforting at first, but over the years you’ll end up under water with regard to technical debt.

As an aside, it’s worth mentioning at this point that if you’re lucky enough that your codebase lasts long enough to feel the downstream damage from discontinuous integration with external dependencies, then congratulations.  Maybe it’s the short lifespan (planned, anyhow) of most systems that has meant this problem is not talked about as often.

For all of your libraries, you should have a periodic schedule to check for new versions and update to them.  The alternative is to postpone and magnify the pain of doing so, in the exact same way it would be for not pulling in your teammate’s commits.  But should you practice continuous integration with them, meaning upgrade to every public release?

I spent some time thinking about it and it seems like you should.  Commonly, people mention lack of stability as a reason not to.  I would then ask why you are using a library that you cannot count on the quality of.  Many projects have stable, long-term support or other more conservative packages to meet this need.  You can always use those if the developers are a little too experimental for your taste.

When a new version comes out, pull it in.  After all, if your build goes red you can always revert.