Cloud Four Blog

Technical notes, War stories and anecdotes

Project Management is BS: an inspirational meditation for modern PMs

This past week, I had the luxury of attending the Digital Project Management conference in Austin. If you are a project manager and you haven’t heard about this group of awesome digital PMs, you are missing out. The first time I attended one of their events, I thought, finally! These are my people! People who actually do what I do at Cloud Four. My tribe.

What do I do, every day? What do digital project managers actually do? It’s mundane stuff, folks. In any given day, I write a ton of emails and Basecamp threads, review lists — many, many lists, in many different forms. I pester people in every way imaginable. (Letters. I’ve written actual letters at times.) I listen, a lot. I run conference calls, I Skype, I Hangout, I Slack, I SIP into meetings. Today, I slacked, then hangout, then called the same person in a 10 minute period. This is not glorious work.

It occurs to me frequently that this is work that really anyone could do. In fact, the tools we use are often designed so that anyone on my team is empowered to use them. 

Want to schedule a meeting? Great! Lucid Meetings makes this really simple. It even walks you through agenda creation and attendee selection! (You know you need an agenda for every meeting, right? Make them good ones, too.) Want to ask the client a question? Perfect! Hit them up in Slack, or Basecamp. You don’t need me.

Sometimes it feels like the work we do is complete BS.

This is not the most encouraging thought to be having about your chosen career.

But here’s the thing: the reason we have project managers at all is because most people are not thinking about these things. Your project team is so heads down on the work they are doing that they don’t think about the overall project progress, or the political implications of asking a certain question, or just the right way to deal with that nagging change request. They don’t worry about the overall budget impact of that bug that was just found in QA, or how the hell you are going to schedule one extra sprint when you’ve got two other projects starting that same week.

They just don’t. But YOU do. And YOU are really freaking good at it. 

[cue the inspirational music]

YOU wake up in the middle of the night, wondering why that one stakeholder didn’t seem engaged in your kick-off meeting that day.

YOU can’t shake that feeling that something isn’t right about that call you just had with your developer. She didn’t really say anything, but you know something is off and how to suss it out. 

YOU know exactly how to load your project teams to maximize efficiency without overloading them. 

YOU can evaluate a budget overage, report it to the customer, and offer alternatives that are actionable and clear.

YOU inspire and motivate your team to keep on keeping on. 

YOU see patterns of inefficiencies in your organization and have ideas on how to address them. 

And this is not just about making sure that someone (anyone) is tasked with these types of things. It’s making sure the right person is leading it.

This stuff is our DNA. And it’s not mundane or ordinary. It’s essential, technical, precise, and difficult work. It’s hard and soft skills. It’s invisible, yes, but like my ever-so-talented colleague Tyler Sticka described it, we’re like the project’s nervous system. The developers, designers, and other project team members are like arms and the legs, moving the body around, but they’d be paralyzed without a good PM to make sure signals are going where they need to be.

Like Nancy Lyons said in the closing DPM keynote, “We are change-makers, we are thinkers, we are do-ers.” 

That’s some really cool, important BS, if you ask me.


GitHub introduced a new text editor called Atom last week, and reactions (at least in my Twitter feed) seem divided between fervent desire and snide disregard. For every few people shamelessly begging for invites, you’ll find one or two bemoaning how fickle we all are, how crowded this software category has become, or how our obsession with the “latest and greatest” distracts us from what really matters (what we make).

Some of these emotions are likely the result of the unspoken assumption that everyone in our industry must always know everything (Lyza called this the knowledge burden). But I also believe, regardless of industry, that a natural friction exists between makers and their tools.

We’ve yet to invent a device capable of directly converting our thoughts into physical manifestations. Until we do, tools can only approximate our intent. This means that the distance between idea and execution is often defined by the capability of our tools and our mastery thereof. They tell us what we can and can’t do.

It’s a complicated relationship.

 Some remain faithful to a specific toolset for as long as possible, cultivating an intense and focused knowledge of every feature, quirk and workaround. Peanuts creator Charles Schulz was so fond of Esterbrook & Co.’s Radio Pen No. 914 that he bought all of their remaining stock when they stopped producing it. The pens lasted him through the remainder of the strip’s nearly fifty-year run.

Others transition quickly, abandoning their previous workflow as soon as they feel it may be working against them. English post-punk band The Fall have remained vital and prolific for nearly four decades, in part because of frontman Mark E. Smith’s infamous propensity for changing the band’s lineup with little or no warning.

We’ve yet to discover that magic “one size fits all” process. Until we do, we should encourage the accelerating expansion of available tools while remaining skeptical of any that claim to be everything to everyone. Choice encourages diversity in the types of thought processes our medium supports.

In other words, tools are important. Not for their own sake, but for those they empower to create. Welcome!

Video: Essence of Content on the Web (Mobilism 2012)

Oh, I am excited! Video from my presentation at Mobilism in Amsterdam has been posted. I’m already excited about Mobilism for next year!

In this presentation, “Cutting through the Crap: The Essence of Content on the Web”, I talk about some of my mental explorations of the meaning of core content on the web. The summary:

You’ve likely heard about content a lot lately—content is king, content should flow like water, “Content First!”. But what IS content in its basest form? Is it HTML? XML? JSON? Is it human-readable plaintext? And once we have our content, how do we transform it to look wonderful on mobile devices, televisions, regular old computers, refrigerators? Where does content end and platform-specific representation begin? The mobile revolution has shown us that our content management and web publishing technologies are entangled and flawed. The web will continue to be consumed by more and more clients, many of which haven’t even occurred to us yet. But by thinking deeply and re-examining the essence of our content, we can help to architect a flexible future for the web.

Lyza's "Cutting through the Crap" presentation at Mobilism 2012
Photo courtesy of the very kind Jen Hanen

The video is available on Vimeo.

Laying Down our Burdens: Steps towards simplifying the mobile Web

Developing on the mobile (or pan-device) web is hard. Maybe too hard. Yeah, kind of too hard sometimes. My days are spent chasing down the vital new frameworks (maybe not so vital, really, in retrospect), the newest incremental browser releases, updated devices, newly-unearthed bugs, JavaScript polyfills, debunked CSS techniques, amended specs and sexiest APIs, all while trying to avoid arguments about the True Spiritual Purity of particular approaches.

This leaves me with about four minutes a day to actually do my job, so I don’t get out/sleep/call my poor suffering mother/laugh much.

I don’t really like this. It’s quite noisy. It makes me restive. I want to help people learn how to be successful on the mobile web and the future web as a whole, but the slag heaps of particulars and trivialities are starting to corrode the environment.

Let’s try to make it quieter. Let’s build on the commonality core to the web where we can. To do this, I think we need to let go of a few things, to lay down our burdens.

There are as many kinds of web projects as stars in the Milky Way, yadda yadda, disclaimer, worried-I’m-going-to-get-flamed backpedaling, etc., but I do find that two patterns of control and responsibility seem to crop up in multiple contexts. We grasp desperately for control in our chaotic environment, often looking to control things we in fact do not have control over. And, meek martyrs that we can be, sometimes we take the onus for things that we really should be able to walk away from.

Unclench and set the web free

Part of being successful on the pan-device web is relinquishing control of things we never had control of in the first place. Some of this you have probably heard. Web design processes are being re-imagined with an emphasis on adaptation and a rejection of pixel-perfect mockups. Content is increasingly given a position of centrality, and design flows around it.

As I like to say when I’m feeling punchy, we’ve invented the myth of the PREVIEW button. When customers ask whether there really is an existing tool to see the content and data they’ve put into the web as presented on every possible combination of device, browser and platform out there, I get nervous and worried (also: no). Because such questions smack of expectations-expectations of a pixel-perfect control that was always an illusion and never more than it is now.

As we move into the future, I believe we will see increasing decoupling between content and data input versus representational output as we transform back and forth between various web formats for the different types of clients consuming the web. Our current distractions of micro-control ("The border-radius on this button on the Samsung Galaxy S is about half a pixel too thin") aren’t even remotely scalable, and I think we already know this.

So, take deep breaths, build a solid, utterly simple, mobile- or content- or awesome-first foundation, and let your content flow into it like water as much as possible.

I’ve talked somewhat ad nauseum about my belief in the release of certain kinds of control, flexible content (another kind of control release) and the like. Recently, I’ve stumbled onto the concept a second kind of responsibility and control we, as devs, take on.

You are not and cannot be responsible for everything

So, the border-radius on a theoretical Samsung flavor of Android is all wrong (let me preempt the pedants: I’M MAKING THIS UP. IT IS AN IMAGINARY SCENARIO.). Whose problem is this? That’s a sort of rhetorical question, because in our world, it’s almost always our problem. A wonkish, nasal and self-righteous lecture to the client about a bug in a particular fork of Webkit, while potentially totally correct, is not going to change the fact that the CEO barely knows what a computer is but has that exact Samsung and a strong predilection for particular, round-y, green-tinted buttons.


This is an untenable situation.

I watch many mobile web projects bloat and spill over their budgets in the communities around me. I see the core of development go perfectly well until the dev team dies from a thousand tiny stupidities in mobile browser specifics.

Baby steps to a different perspective

Here’s a story that is not hypothetical. Recently I was piecing together an example prototype web app to use for teaching some concepts around progressive enhancement (specifically for my workshop at dConstruct in Brighton). Part of my enhancement process involved converting some footnoted terms and phrases into tappable elements that spawn a lightboxed modal widget with the footnote content (that is, preventing the user from having to scroll to the footnote at the end of the document—yay, convenience).

As part of this enhancement, my code assigns an additional CSS class via JavaScript. This class adds additional line-height to give more space around those now-tappable elements, you know, the classic "make your tap targets usable" situation. Worked fine.

Except that in Opera Mini, line-height is ignored entirely.

Enhanced Page on Mobile Safari
Enhanced page on mobile Safari on iOS (note relatively space-y line-height)

Enhanced Page on Opera Mini on iOS
Enhanced page on Opera Mini on iOS (no line-height space here)

iPhone iOS Safari: Line Height
line-height test page on mobile Safari on iOS

Opera Mini Line-height
line-height test page on Opera Mini, same iOS device

Here’s what Opera has to say:

"Mini does not support the line-height CSS property at present, since testing showed that it generally meant less text fitted on any individual page, requiring more scrolling from the user." — Opera Mini Authoring Guidelines

Hokay. You know how I’m going to deal with this?

I’m not.

For one thing, I can’t (see point one above about things we can’t control). But even if I could think of a plausible workaround, enh.

I sort of visualize the Opera folks as sitting around in a summit akin to the Council of Nicea, picking and choosing which parts of CSS they felt were worthy of inclusion in their canon. But dumb and fanciful metaphors aside, I would argue browsers should insomuch as possible implement the standards as they stand, not selectively exclude things because they can’t reconcile with them on a moral or idealistic level. Hey, I get that Opera is trying to protect users from data and scrolling glut, but when behavior doesn’t remain predictable, it puts developers in an impossible position, and in the end is detrimental for the user.

That’s all great, you say, and it’s very easy to make sweeping generalizations and plans and take stands when you’re not faced with a twitching and possibly insane client at 8:40PM demanding another CSS animation to showcase a Facebook Like button. And you’re right. Idealistic mountaintops have good views but are cold and lonely places. The real stuff happens at grungy-but-whimsical sea level, among the dead fish and vibrant local patois. But what we can do is start to grapple with the nature of the way we talk about these things.

We can slowly migrate our perspective from immediate self-blame and ownership of issues like these. We can start communicating about these things a bit differently. We can make little decisions that incrementally shift the timbre of this situation. We don’t have to bear certain burdens silently, forever.

By way of examples of little steps: I’m polyfilling for less-full-featured browsers less these days, where I can get away with it. Instead, my code increasingly looks something like this:

if (typeof history.pushState != 'undefined') { 
  // Yay! Async elements and that one-page-app snazziness
} else {
     // It still works. Don't panic. Normal URLs and requests FTW.

This is me somewhat quietly casting a vote for standards. Sending the message that, hey, I want to give you this feature, but to level up to this with me, you have to play by the rules the community forged. If you don’t, I’m going to give you a baseline way to get things done (see, I’m not too cruel).

Sure, not always feasible. Sure, an oversimplification. Sure, not always advisable. But even small steps toward reducing the noise—and thus lowering the number of introduced risks and crap you have to deal with—in a project can help make the burden of responsibility more tolerable. Maybe this is as simple as not opting for a bells-and-whistle framework or JavaScript plugin for flyout navigation, but instead crafting something more minimal yourself.

We have a long way to go to streamline cross-device web development techniques. But maybe these humble little inroads can help lead to a simpler, more beautiful web.

This post is an expansion on some of the ideas in my recent talk on The Most Common Denominator at Breaking Development in Dallas. The link is to the slide deck, but there should be a video available within a few weeks. Stay tuned.

Keen on this kind of stuff? Get ye to the next, assuredly amazing Breaking Development conference, April 10-13, 2013 in Orlando, Florida. The lineup is incredible. Paul Irish, Stephanie Rieger, Sarah Wachter-Boettcher, our own Jason Grigsby…the list goes on and on and on (Dion Almaer and Ben Galbraith, Mat Marquis, Cameron Moll, Aaron Gustafson…).