Infocon: green

 ∗ SANS Internet Storm Center, InfoCON: green

Site and Currently Down

Site and Currently Down, (Sun, Dec 21st)

 ∗ SANS Internet Storm Center, InfoCON: green

We have received a report theNational Finance Center site

Our approach to manufacturing is as quaint as punchcards

 ∗ One Big Fluke

Recently, I had the privilege to hang out with some septuagenarian programmers. I was showing off the bicycle shifter I've been working on. I complained to the veterans that I was shocked by the amount of time required to bring a physical design to implementation. It took two weeks to come up with a CAD model; a month and 30 failed attempts to make a usable 3D print; 4 months to manufacture a part out of aluminum.

"That's what programming was like back in the day" was their reply. Really? "You'd turn in your punch cards and hope to get the output a week later — sooner if you were lucky". Can you imagine writing a program like that? I had never considered the analogy to physical design.

It's unimaginable how anyone prototyped physical objects before 3D printing. Debugging a program with one execution attempt per week is similarly inconceivable. We're spoiled these days. We grew up reliant on read-eval-print loops (REPLs), interactive debuggers, quick compilers, and instant gratification. Though we've progressed beyond punchcards, many people think our tools still aren't fast enough. Our generation is obsessed with speed and convenience (perhaps for good reason).

The question is: What will bring physical manufacturing up to parity with software? Earlier this year I would have said it's 3D printing. But 3D printing is slow. Even though laser sintering can produce precision parts like rocket engines, it doesn't scale. SpaceX isn't printing 1,000,000 engines, they're printing 100.

To build cars, cell phones, and soda cans you need to produce high volumes quickly. Waiting for a 3D printer to finish a job isn't cost effective for most terrestrial products. Instead, you need to design for manufacturing with mills in factories where the machine time is measured in seconds, not hours. But today designing for factories is too way too difficult. Our approach to manufacturing is as quaint as running assembly code on punchcards once a week.

Though there are high-level tools to turn CAD models into milling toolpaths, that's only a small portion of the problem. What we need is a way to click a button and launch a manufacturing process: a generalized, automated workflow from CAD to produced parts. Maybe affordable milling tools will help us get there. Maybe cheap, inflatable robots will enable scale.

As much as I loved the Diamond Age, I don't think 3D printers will make it possible. But I think it's a goal worth pursuing. It would be wonderful to tell our grandchildren the same line: "That's what manufacturing was like back in the day". Who knows what they'll be creating then.

Lyza Danger Gardner on Building the Web Everywhere: The Implicit Contract

 ∗ A List Apart: The Full Feed

I work with lots of different teams and different developers. I usually know innately, as does the team around me, whether the teams we’re working with are good or not. We rarely disagree on the evaluation.

But what does good mean?

I find that the most valuable web developers interact with each other along a kind of implicit contract, the tenets of which are based upon web standards and proven ways of doing things that we’ve cobbled together collectively over the years. Most of the time, good isn’t generated by an individual in isolation—it’s the plurality of tandem efforts that hum along to a shared, web-driven rhythm.

When things are ticking along smoothly among devs, I find we have a common underlying way of talking and thinking about the web. We fit together in human and technical ways, upholding a shared understanding about how best to make pieces of the web fit together.

In contrast to the tired stereotype of genius coming in the form of a lone, intense hacker, much of the effective work done on the web is done within the bounds of a certain kind of communal conformance. In a good way.

Working together

A heap of obvious things goes into making an individual web developer seem good: An innate understanding of time and effort. An indestructible drive to self-educate.  A lick-smart, logical mind quick to spot and take advantage of patterns. I think we look for these talents naturally.

And yet when devs work together, those skills fade back just a bit. In a (grossly oversimplified) way, as part of a larger team each developer is a miniature black box. What comes fiercely front-and-center are the interfacing edges of the people and teams. The way they talk to each other and the timbre of what they build, what they disclose and what they don’t think they need to mention.

When something unexpected pops up between healthy teams—which happens, because this is a complicated world—a communication like, “Hey, when I poke this service in this way, it throws a 500 at me” as often as not is enough information for the recipient to go off and fix it, because we have have similar scars to reference and a shared vocabulary built on common ground.

A common vernacular and communication style is an echo of a common thinking style. Underneath the chatter are cognitive technical models of the metaphors at hand, based on each team member’s perception of how the web fits together—REST, modular patterns, progressive enhancement, etc.—and how those components apply to the current project. Happy days when those internal archetypes align.

When you run into misaligned teams it is obvious. There’s a herky-jerky grating to communication. Seemingly dashed-off emails that don’t quite dig into the problem at hand. Teams where you can tell each member’s mental context differs. Code that feels weird and wrong.

A common ground engenders brilliant ideas

Unless it is the actual goal of the project, I don’t care too much if you can come up with a Nobel-worthy new implementation of a basic CRUD feature. In most cases, I’ll happily accept something predictable and expected.

This is not an argument for ignorance or apathy. Ideally, everyone should be pretty good at what they do—those individual technical skills do of course matter. I mean, part of the contract here does involve boots-on-ground time—to understand the lay of the land, to break HTTP into bits and pieces, leak some memory, screw up DNS a few times. We break and heal frequently as we gain deeper web mastery.

But having a web set of conceptual building blocks—standards, patterns, conventions—upon which we can frame and build gives us the freedom to focus on where we really need to be creative: the particular task, product, or site at hand. Common components, shared notions.

After all, the best chefs in the world don’t reinvent carrots. Instead, they identify what other remixed food components might plug into a carrot to make it divine.

Likewise, good developers are mixing up agreed-upon technical ingredients into the soup of the day. And just as a talented cook knows how to explain to the waitstaff the nuances that thyme brings to the potato, good devs know how to talk to those around them, team members both in the kitchen and beyond, about why today’s menu includes OAuth or moment.js.

It’s not just touchy-feely

It used to be that I would think, “Hey, these people seem like they’re on the same wavelength as my team; that’s cool,” but now I realize it’s likely that what seems merely like good vibrations saves prodigious time and money on projects.

In damaged teams, mental reference dissonance carries through to the outcome, manifesting itself in jarring technical mismatches, poorly-thought-through integration seams and, frankly, bugs. It’s as if people are thinking about the web in different internal language systems.

So? Things take longer, often a lot longer. Teams become frustrated with each other. Meetings and discussions are drawn-out and less fruitful. The results suffer. Things break.

It matters.

I’m not suggesting we all link arms and plow out code from a single hive mind. In fact, I’d argue that the constraints imposed by a common perspective help to drive a certain kind of unique brilliance.

A Holiday Wish

 ∗ Jeffrey Zeldman Presents The Daily Report: Web Design News & Insights Since 1995

We are all designers. You may call yourself a front-end developer, but if you spend hours shaving half-seconds off an interaction, that’s user experience and you, my friend, are a designer. If the client asks, “Can you migrate all my old content to the new CMS?” and you answer, “Of course we can, but should we?”, you are a designer. Even our users are designers. Think about it.

ON THE TITLES that divide, and the spirit that unites us: My Holiday Wish for all people who make websites—in today’s 24ways.

Tweaking the Moral UI

 ∗ A List Apart: The Full Feed

A couple of years ago, I was asked to help put together a code of conduct for the IA Summit. I laughed.

We need a code of conduct here? The IA Summit is the nicest, most community-friendly conference ever! Those problems happen at other conferences! And they want me to help? There are sailors jealous of my cussing vocabulary—surely I was not PC enough to be part of such an effort. But the chairs insisted. So, being a good user-centered designer, I started asking around about the idea of a code of conduct.

I found out design conferences are not the safe meetings of minds I thought they were.

One woman told me that she had been molested by another attendee at a favorite conference, and was too scared to report it. “No one will ever see me as anything but a victim,” she said. “I’ve worked too hard for that.”

At another conference, a woman was woken up in the middle of the night by a speaker demanding that she come over. When she told the organizer in the morning, he said, “We were all pretty drunk last night. He’s a good guy. He just gets a bit feisty when he’s drinking.”

Then there was my own little story. Years ago at the IA Summit, I went to talk to a speaker about something he’d said. I’m a tall, tough lady. But he managed to pin me against a balcony railing and try to kiss me. I started wondering, what if there had been a code of conduct then? What if I had had someone to talk to about it? What if I hadn’t said, “Oh, he’s just drunk”?

Maybe I wouldn’t have spent the past seven years ducking him at every event I go to. And maybe he wouldn’t have spent those same years harassing other women—women who now were missing out on amazing learning and networking opportunities because they thought they’d be harassed.

The idea of a code of conduct didn’t seem so silly anymore.

A wicked problem

Unfortunately, it still seems silly to others. Recently I was talking to another conference organizer about setting up codes of conduct, and he said, “That doesn’t happen at our conferences. People know me, and they know they can talk to me. A code of conduct will make people nervous that we have a problem. And we don’t.”

I wonder how he knew that, since most victims don’t come forward. They don’t want to be seen as a “buzzkill,” or be told that what they wore or what they drank meant that they asked for it. This is not unusual; every day we see examples of women whose reputations are trashed for reporting rape and harassment. On Twitter, women who talk about sexism in games or even think a woman should go on a stamp are given death threats. Reporting carries consequences. Reporting is scary.

In order to feel safe enough to come forward, attendees and speakers need to know that the conference organizers are paying attention. We need a guarantee that they’ll listen, be discreet, and do something about it.

In her recent piece, “Why You Want a Code of Conduct & How We Made One,” Erin Kissane frames precisely why codes of conduct are absolutely necessary:

To define a code of conduct is to formally state that your community—your event or organization or project—does not permit intimidation or harassment or any of the other terrible things that we can’t seem to prevent in the rest of the world. It’s to express and nurture healthy community norms. In a small, limited way, it’s to offer sanctuary to the vulnerable: to stake out a space you can touch, put it under your protection, and make it a welcoming home for all who act with respect.

A code of conduct is a message—not a message that there is a problem, but a message that there is a solution. As much as a label on a button or a triangle with an exclamation point in it, a code of conduct tells you how a conference works.

Tweaking the UI

We are designers.

That means we make choices about the interface that sits between the people and the thing they want. We mock interfaces that aren’t clear. We write books with titles like Don’t Make Me Think. Yet when we hold conferences, we seem to assume that everyone has the same idea of how they work.

Why do we expect that people will “just know” how to use this complex build of architecture and wetware? There is a lecture; that means professional behavior! There is a bar; that means drinking and flirting! There is a reception; that means…alcohol plus speakers…network-flirting? A conference can be a complex space to understand because it mixes two things that usually have clear boundaries: social and work. If one person is working and another is looking to get social, conflict will happen.

These fluid boundaries can be particularly hard on speakers. Attendees often approach speakers with questions inspired by their talk, which could start a conversation that leads to work…or a date. It’s hard to tell; cautious flirting and cautious networking often look the same. People can feel uncomfortable saying no to someone who might hire them—or keep them from being hired.

Sometimes after giving a talk, I’ve mistaken admiration for flirtation, and the other way around. A wise speaker stays neutral, but it can be hard to be wise after a few glasses of wine. A code of conduct is useful because it spells out parameters for interaction. Some codes have even gone so far as to say if you are a speaker, you cannot engage in romantic activities like flirting. Clarity around what is expected of you leads to fewer accidental missteps.

Set expectations

A good code, like a good interface, sets clear expectations and has a swift feedback loop. It must:

  • Define clearly what is and isn’t acceptable behavior at your con. “Don’t be a dick” or “Be excellent to each other” is too open to interpretation. The Railsconf policy offers clear definitions: “Harassment includes, but is not limited to: offensive verbal comments related to gender, sexual orientation, disability, physical appearance, body size, race, or religion; sexual images in public spaces; deliberate intimidation; stalking; following; harassing photography or recording; sustained disruption of talks or other events; inappropriate physical contact; and any unwelcome sexual attention.”
  • Set expectations for what will happen if the code is violated, as the O’Reilly code of conduct does: “Conference participants violating this Code of Conduct may be expelled from the conference without a refund, and/or banned from future O’Reilly events, at the discretion of O’Reilly Media.”
  • Tell people how and to whom to report the incident. The Lean Startup Conference’s code includes: “Please contact a staff member, volunteer, or our executive producer [name], [email] or [phone number].” Providing a phone number is a massive signal that you are willing to listen.
  • Set expectations about how it will be handled. The World IA Day code is very clear:

    First we will listen.

    Then, we will help you to determine the options that we have based on the situation. We will also document the details to assure trends of behavior are uncovered across locations.

    Lastly, we will follow the situation to a resolution where you feel safe and you can remain anonymous if you wish to be.

A code of conduct is a little like a FAQ or a TOS. It’s clunky, and I hope someone comes up with something better. But it’s instructions on what to expect and how to behave and, most importantly, what to do when something breaks. Because, as we keep seeing, something will eventually break. It’s better if it’s not people.

A lot of conferences are adopting codes of conduct now. The Lean Startup Conference one mentioned above is heartfelt and crafted based on their values. The art and technology festival XOXO has an excellent one, based on the template from Geek Feminism. Yes, there’s a template. It’s not even hard to write one anymore. It doesn’t even take a long time.

Meet (or exceed) expectations

Any good experience designer knows that setting expectations is worthless if they aren’t immediately met. Beyond writing a code of conduct, conference organizers must also train their team to handle this emotionally charged situation, including making sure the person reporting feels safe. And there needs to be a clear, established process that enables you to act swiftly and decisively to remove violators.

So how should a conference handle it when the code is violated? There are a couple of telling case studies online: one from Elise Matthesen at the feminist science fiction conference WisCon, and another from Kelly Kend at XOXO.

In both cases, these women were immediately supported by the people they spoke with—a critical first step. In Kelly’s case, she brought her situation directly to the organizers, who listened to her and made it clear they weren’t going to blame her for the incident. Once the organizers had made her feel safe, they removed the harasser. It was improvised action, but effective.

In Elise’s case, it’s clear that WisCon was well-prepared to handle the incident. The first part of the story is exemplary:

  • The conference staff member (called a “safety staffer”) asked if Elise wanted someone there while she reported.
  • The safety staffer asked if she wanted to report it formally, or just talk it through first.
  • The safety staffer asked if she wanted to use her name, or remain anonymous.
  • And the safety staffer and the conference organizers kept checking in with her to make sure she was doing okay.

Unfortunately, WisCon fell down when it came to acting on the report. Eventually the harasser was banned, but only after a slow and onerous process. And the ban isn’t permanent, which has infuriated the community.

It is hard work to get the poison out of the apple. Elise writes, “Serial harassers can get any number of little talking-to’s and still have a clear record,” which has been my experience as well. Since I started writing about conference harassment, a number of women have spoken to me about incidents at various design conferences. Two names keep coming up as the abusers, yet they continue to get invitations to speak. Until more people step forward to share their stories, this won’t change. And people cannot step forward until they are sure they won’t be victimized by the reporting process.

If you are a conference organizer, it is your job to make sure your attendees know you will listen to them, take them seriously, and act decisively to keep them safe.

If you are an attendee who sees harassment, stand up for those who may be afraid to step forward, and act as a witness to bad behavior.

And if you are harassed, please consider coming forward. But I can’t blame you if you choose not to. Keep yourself safe first.

A promise

John Scalzi, author of several best selling sci-fi novels, made a pledge to his community that he would neither speak at nor attend any conference without an enforced code of conduct.

I will make the same pledge now. I will honor any commitments I’ve made previously; all new ones are subject to the pledge.

I will neither speak at nor attend conferences that do not have and enforce a code of conduct. This may prove hard, as many conferences I’d love to speak at do not have a code yet. But change takes sacrifice. Integrity takes sacrifice.

If you believe, as I do, that it is critical to make a safe place where everyone can learn and grow and network, then leave a comment with just one word: “cosigned.”

Conference Proposals that Don’t Suck

 ∗ A List Apart: The Full Feed

When it comes to turning your big idea into a proposal that you want to submit to a conference, there are no real rules or patterns to follow beyond “just do your best” and perhaps “keep it to 500 words,” which makes the whole process pretty daunting.

I’ve worked with a number of people submitting proposals to events over the past few years. I’ve been racking my brain trying to identify a strong pattern that helps people pull together proposals that provide what conference chairs and program planners are looking for, while at the same time making the process a bit more clear to people who really want to find their way to the stage.

I’ve found that it’s best to treat the proposal-writing process as just that—a process, not just something you do in a half-hour during a slow afternoon. One of the worst things you can do is to write your proposal in the submission form. I’ve done it. You probably know someone else who has done it. Most of our proposals probably sucked because of it. Hemingway advises us that “the first draft of anything is shit,” and this is as true for conference proposals as it is for just about anything.

When you write a proposal in the submission form, you don’t give yourself the time that a proposal needs to mature. I’ve found six solid steps that can help you turn that idea into a lucid and concise conference proposal that paints a clear picture of what your presentation will be about.

As I walk through these steps, I’m going to share my most recently created conference proposal. I’ve recently submitted this to some conferences, and I don’t yet know if it will be accepted or if I’ll have any opportunities to give this presentation—but following these steps made writing the proposal itself much easier.

Let’s get to it.

Step 1: Write down the general, high-level ideas that you want to talk about

This is a very informal step, and it should be written just for you. I use this step to take any notes I’ve stored away on post-its or in Evernote, and turn them into something resembling a couple of paragraphs. It’s an exercise in getting everything out of your head.

You don’t need to worry about being factually accurate in what you’re writing. This is the opportunity to go with what you know or remember, or assume you know or remember, and get it all into some other medium. You can fix anything that is inaccurate later; no one is going to read this but you.

For example, I’m writing a proposal for a presentation about creating “skunk works” projects (essentially, where small teams work on secret/necessary endeavors) to get things done when you’re busily leading a team and don’t really have time to get all the things accomplished that should be in place.

Here’s what I started with:

Something About Skunk Works Projects

The overall premise is that teams are really busy and if you’ve recently grown one (in-house or otherwise), you know that all the bodies go to the work, and little goes to the stuff that helps make a team purr along nice and smoothly, such as efficient on-boarding processes, sharing of thinking, processes, definitions, etc. Skunk Works projects can help you continue to increase the value to your team (and others) and also provide the team with an outlet for growth.

Is there a formula? There sure is, and I can trace a lot back to Boeing, and other places like Atari & Chuck E. Cheese, and my own current “stuff.” It dovetails nicely into the guerrilla stuff that I’ve done in the past, and the leadership I’ve been doing recently.

That’s the idea—how to get stuff done for your team when you’ve got so much stuff to do that you don’t have time.

This is an extremely rough draft, and should be for your eyes only—despite the fact that I’m sharing mine with you here, in its poorly written and somewhat inaccurate state.

At this point, you’ve earned a break. You’ll want to be fresh for the next step, where we start to build a supporting backbone for your free-flowing words.

Step 2: Break your content into topic points

Review what you’ve written and begin to break that content into topics. I create bullet points for “Pain,” “Solution,” and two rounds of “Support.” I also add a bullet point I call “Personable,” so that I have a place to add how the idea is relatable to my own experience (though this sometimes ends up being covered by one of the Support points).

This isn’t final content; go ahead and lift sentences from your previous paragraphs if you feel like they’re relevant. Grammar still takes a backseat here, but do make sure that you’re addressing the topic point with some clarity. Also, spend a little time doing some fact-checking; tighten your points up a bit with real and concrete information.

As I was working through this step, I did a little more homework. I cracked open a few books and hunted down articles in order to refresh myself and feel like I was on more solid ground as I pulled the points together.


When you think about your presentation’s topic, what is the common point of pain that you believe you share with other people? What prompted you to feel that this is a strong idea for a presentation and worthy of sharing? Pain is something we all share, and when you can help someone else feel like their pain might be alleviated, they start to nod their heads, mentally say “yes!” to themselves, and begin to relate to you and your message.

Pain point: Work has to get done; organizational good “stuff” often comes last, which means it never gets done because the bills have to get paid and people get booked on project work first.


After you’ve identified that common point of pain, what’s the general, high-level solution? If you are the person who found the solution, you should say so; if not, you should identify who did, and explain what you learned from it. Give enough information to assure people there is a solution. Don’t get hung up on feeling like you’ll give away the ending; people will show up to your presentation to hear more about the journey you’ve taken from that common point of pain, not just to hear you recite the solution itself.

Solution: Don’t worry, others have used skunk works to have some great successes. Companies such as Google, Microsoft, Ford, and Atari have done amazing work with skunk works. So have I, and I’ll show you how I’ve done it so you can put it into practice for yourself based upon my loose framework.

Supporting points

Once you’ve worked through the pain and solution, it’s time to provide a little more information to the reviewers and readers of your proposal. Merely telling people that there is pain and a solution is great to lead with; however, it’s not enough. You’ll still need to convince people that this idea applies to a broad range of other contexts, and that this is a presentation that they need to see so that they can benefit from your wisdom. What are a couple of key points that you can use to support the validity of your proposal and the claims that you may have made?

Support 1: Origin in the 40s with Lockheed. They used it to create a jet fighter to help fend off the German jet fighter threat in 1943. Kelly Johnson and his team designed and built the XP-80 in only 143 days, seven less than was required.

Support 2: Kelly had 14 Rules & Practices for skunk works projects—we don’t need them all; however, we can learn a lot from them.

Something personal and/or humorous (optional)

If you’re able to pull something personal into your proposal, you can help reviewers and audiences members further relate to you and what you’ve been through. It can shift a proposal from appearing to be “book report-ish” to one that speaks from your experience and perspective. I like to leave this as optional content because you may already be adding something similar in the Pain, Solution, or Supporting points sections.

It’s important not to overlook the value—and the risk—of humor. Humor is tough to do in a conference proposal. You may have a line that you find hilarious; however, great comedy relies heavily on nuances of delivery that are difficult to transmit in a written proposal (and sometimes even harder for the readers to pick up on). Take caution, and when in doubt, skip anything that could be misperceived when creating your proposal.

Personal: I’ve pulled together skunk works teams and busted out some skunk works projects myself!

Humor: The results smell pretty damn good. (Wah wah wah.)

Together, these provide the foundation for the next step, which is where we start to get more serious.

Step 3: Turn your topics into a draft proposal

This is where we take the organization and grouping of your thoughts and turn them into a few short paragraphs. It’s time to turn on the spell checker and call the grammar police; this is a serious activity and the midway point to having a proposal that’s ready for submission.

You’ll be writing the best, most coherent sentences that you know how to craft based on your topic points. You should use your topic points as the outline for your proposal, hitting the ideas in the same order. As a refresher, here are my topic points, in the order they were created.

Pain: Work has to get done; organizational good “stuff” often comes last, which means it never gets done because the bills have to get paid and people get booked on project work first.

Solution: Don’t worry, others have used skunk works to have some great successes. Companies such as Google, Microsoft, Ford, and Atari have done amazing work with skunk works. So have I, and I’ll show you how I’ve done it so you can put it into practice for yourself based upon my loose framework.

Support 1: Origin in the 40s with Lockheed. They used it to create a jet fighter to help fend off the German jet fighter threat in 1943. Kelly Johnson and his team designed and built the XP-80 in only 143 days, seven less than was required.

Support 2: Kelly had 14 Rules & Practices for skunk works projects—we don’t need them all; however, we can learn a lot from them.

Personal: I’ve pulled together Skunk Works teams and busted out some Skunk Works projects myself!

Humor: The results smell pretty damn good. (Wah wah wah.)

Once you’ve reviewed your topic points, put your writing skills to work. I did more gut-checking and fact-checking to make sure I wasn’t completely full of crap and to generally tighten up my thinking.

The Science of Skunk Works — Making Sure the Cobbler’s Kids Get Shoes

We’ve all worked at places where there’s never enough time to make sure that things are operationally done the “right way”—bills need to get paid, client or product work needs to get done and takes priority, and hey, everyone deserves to have a little bit of a life, right? There is a bit of a light at the end of this tunnel! Several companies, including Atari, Chuck E. Cheese, Ford, Microsoft, and Google, have pulled of some pretty great things by taking advantage of skunk works teams and projects. I’ve been fortunate enough to see a little bit of success with those teams and projects, as well, and will share how you can apply them to your own practice.

Way back in the 1940s, Kelly Johnson and his team of mighty skunks used their skunk works process to design—and build—the XP-80 prototype jet fighter to compete with the Germans. In 143 days—seven days less than was needed. Kelly created 14 Rules & Practices for skunk works projects in order to help articulate the most effective way for his team to successful in the projects that they worked on. We can learn from Kelly’s rules, adapt them to our current times and perhaps more digitally dependent needs, and find some ways to put some shoes on the cobbler’s kids. And the results might just smell pretty good, if you’re patient enough.

Notice that I didn’t just take the topic points and copy and paste them into paragraphs. Instead, I put on my editing hat and tried to establish the flow of what I was writing, keeping the paragraphs limited to 2–3 sentences for the sake of concision.

Step 4: Phone a friend

You know that friend you can always count on to tell you when you’ve got a booger on your noise or spinach in your teeth, or who will tell you when you were just a completely out-of-line jerk and you need to get your head on straight?

That’s the friend you want to send your proposal to. If you’re fortunate enough to have more than one of these friends, send it to all of them. Explain to them—clearly—what they’re about to read and what the purpose is. Give them enough background so that they can provide you with actionable feedback. Tell them about the conference, the expected audience, your topic, why you’ll be good presenting on this topic, and what your proposal is about. Finally, give them a deadline of a day or two so they can review it with the focus that it deserves.

I sent my proposal off to my friend Gabby Hon, because she’s that friend who will tell me all those things I listed above and because she’s a words-and-grammar nerd who kicks my work as hard as it needs.

She sent me feedback, and, for once, my confidence was a bit higher than it should have been. I really like my topic and really felt strongly that I’d pulled together a solid proposal. Gabby’s feedback was essentially:

  • You’re using “a bit” and “a little bit” too much. I’ve counted 3 so far within a paragraph
  • Okay, so, there’s too much “this is what skunk works is”—which I can find on Wikipedia—and not enough “why this matters to design/tech/UX”
  • You say you can adapt the rules, but can you give a little hint?
  • I mean obviously it was all about design and working around restrictions and limitations—thus skunk works
  • If design is best when faced with limitations, then skunk works programs are our best historical example of how to do great work under something something

Not only did Gabby provide some great things for me to think about and improve on, she was also gracious enough to let me know that I didn’t entirely stink up the page when I’d written my proposal:

  • It’s very good
  • Just the second paragraph needs some polishing

Step 5: Revise your proposal

Once you’ve had time to process the feedback, sit back down with your proposal and make adjustments. Don’t be shy about killing your darlings; the feedback you’ve received is meant to help you focus on the important parts and make them better. If something doesn’t fit, move it to a parking lot or remove it entirely.

Here is my final revision that I’ll be submitting to conferences:

DesignOps Skunk Works: Shoes for the Cobbler’s Children

We’ve all worked at places where there’s never enough time to make sure that things are operationally done the “right way”—bills need to get paid, client or product/project work needs to get done and takes priority, and hey, everyone deserves to have a life, too. There is light at the end of this tunnel! Several companies, including Atari, Ford, Microsoft, and Google, have pulled off some great things by taking advantage of skunk works teams and projects. I’ve been fortunate enough to see some successes with those teams and projects, as well, and will share them so you can see how to apply the approach(es) to your own practice.

Way back in the 1940s, Kelly Johnson and his team of mighty skunks used their skunk works process to design—and build—a prototype jet fighter in 143 days. Kelly established 14 Rules & Practices for skunk works projects in order to help articulate the most effective way for his team to be successful in the projects that they worked on. Not only can we learn from Kelly’s rules and adapt them to our current methods of working, we can also create our own skunk works teams and projects to ensure that the cobbler’s kids—the operational areas of our design practices—get some shoes put on their feet. And the results might just smell pretty good, if you’re patient enough.

There’s a bit of a method to my madness, believe it or not. Here’s a micro-version of the change log of my proposal:

  • I made a key change in the title; I’m pretty uncomfortable with using the word “science” (originally “The Science of Skunk Works”). I’m pretty sure “science” is making a promise that I’m not certain I can keep in the presentation, and I’d prefer not to be called to the mat for that.
  • I tested my title with a few friends and this title fared the best. I was leaning toward “Shoes for the Cobbler’s Kids” personally, and the feedback encouraged me to not be so precious.
  • I also tightened up the copy based on Gabby’s feedback, placing extra focus on the second paragraph.

Step 6: Submit the proposal to a conference

You likely had a conference in mind when you started trying to pull together your proposal. Each year, I start contemplating my primary presentation for the next year as soon as I can. Generally, starting around March through April or May is when I really start to try and think about what I’ve learned and what is worth sharing with others, and then I start collecting information—notes, articles, books, and so on—so that I can support my thinking as best as I can.

When I go through this process, then I know that I’m ready with a pretty solid proposal. I copy and paste the final, vetted version into the form and hit submit, confident that I’m not just winging it.

And sure enough, that’s when I find that last typo.

Poverty is a System Design Failure

 ∗ Jeffrey Zeldman Presents The Daily Report: Web Design News & Insights Since 1995

Platts Global Energy Awards. My friend Peyo at right.

“POVERTY is a system-design failure.” So says my friend Pär (“Peyo”) Almqvist in a World Economic Forum article he wrote last year when his company, OMC Power—which brings sustainable, renewable, off-the-grid energy to the poorest people in rural India—was selected as a World Economic Forum Technology Pioneer.

Peyo’s article explains better than I could how renewable-energy companies, locked out of first-world competition by entrenched fossil fuel interests, are bringing the future to poor rural and urban areas—and ushering in a new era of decentralized power. (Much like the web is doing for content, commerce, and applications.)

The Economist has also covered OMC’s work.

Last night in New York, OMC Power won a fresh honor when they were named a rising star at the 2014 Platts Global Energy Awards (“the Academy Awards of the energy industry”).

I first met Peyo in 1999 in Stockholm, when we both spoke at a design conference organized by the K10k guys, Toke and Mike. Peyo was just 19 at the time. By age 25, he had become a digital media director and music producer (his music is still popular in the Swedish iTunes EDM and hip hop charts), not to mention a contributing author to A List Apart.

I am so happy for my friend, and even happier to see him putting his brilliance to use addressing one of the greatest economic, ecological, and social challenges of our time. Not everyone who is smart and talented is making smartphone camera apps (not that there’s anything wrong with it).

Congratulations, Peyo!

Reliably hosted by