Let’s make a space for developers

Leave a comment
Growth
“You’re going to love this.” Photo by rawpixel on Unsplash.

Lisa and Ben are standing in the middle of a cavernous empty office. It smells damp.

“Well, I guess this could be nice,” says Ben, looking at the peeling corners of the carpet tiles beneath his feet and the adjacent coffee stain that possibly predates Y2K.

Lisa looks at the wires hanging from the ceiling. “Before or after we set fire to it?”

“C’mon, Lisa. Imagine the possibilities.”

Ben makes a wide gesture with his arms and motions towards the space in front of him.

“We could have our team sitting right by that window over there. It’s a great view.”

“Of Tesco.”

“We could even have our own coffee machine, and maybe a screen on the wall, and…”

Thump.

Mia shoves the front door open too hard and the handle collides loudly with the adjoining wall. She announces her presence, although she’s already done that quite successfully.

“Yoo-hoo! Develoooooopers!”

The developers in question exchange glances.

“We’re data scientists,” exclaims Lisa.

Ben looks dubious. “Oh no, she has company.”

Mia is followed by three identically dressed men with  matching brown brogues, black trench coats, and black oversized spectacles.

Lisa looks twice in surprise as they file in, one after the other.

She whispers quietly to Ben. “Is this a glitch in the Matrix?”

The group approach, with hands outstretched, ready to greet. Mia introduces them.

“Lisa, Ben; meet the agency is who is going to turn this old office into a masterpiece for us: Ashley, Ashley and Ashley.”

The first man speaks. “Thank you Mia. We really enjoyed meeting your sales team earlier.”

They all shake hands in turn.

“Hey, I’m Reuben Ashley.”

Next.

“Nice to meet you. I’m Reese Ashley.”

Next.

“Hello. I’m Ramon.”

“Ramon Ashley?” enquires Ben.

“No, Ramon Martínez Simón.”

“OK.”

“Well it’s nice to meet you too,” says Lisa, relinquishing their firm handshake grip.


The group walk across the tatty floor towards the few remaining pieces of furniture from the previous occupiers. They sit down.

“Ashley, Ashley and Ashley have been working on some ideas for how we’re going to turn this space into something fantastic,” declares Mia.

Reuben nods.

“Yes, yes, we have. We’ve brought some initial designs along with us today. Mia informed us that you are two of the longest serving developers here, so you’d have a good idea about what you’d want in your ideal workspace.”

“We’re data scientists,” replies Ben.

“Data what?”

“It doesn’t matter,” says Lisa. “We really appreciate you getting our opinion on it! What sort of ideas did you already have in mind?”

She looks around at the empty room.

“This place is huge, so it could be really amazing.”

Reuben reaches down into his leather folio and extracts a thick stack of colorful card.

“I think you’re going to like what we’ve been ideating on here.”

He turns the first drawing towards them.

Ben and Lisa scoot their chairs closer. Ben’s wobbly chair leg gets stuck on a tacky pink substance left on the carpet and he wiggles it free, leaving a rope of slime behind.

He looks at the mess. “Gross.”

“OK, let’s go through these,” says Reuben.

The initial drawing is a cacophony of color. Red sofas, green beanbags, yellow carpet; all drawing attention to the beautiful, long, translucent acrylic reception desk.

Reese makes an open-handed gesture in front of the stack of cards. “We wanted the entrance of the office to look inviting and fun. Clients will want to visit you here. Interviewees will want to work here the moment they come through the door.”

Lisa and Ben nod in agreement.

“Looks great,” says Lisa.

“Good,” says Reuben. He moves the next drawing to the front of the stack so they can see.

It details a breakout area complete with table tennis and air hockey tables, complimented with reclaimed wood furniture, metal café chairs in a kaleidoscope of colors, and oversized spherical white pendant lighting.

Reese continues. “Notice how we’ve created this central hub, accessible from all work areas, where most employees will visit throughout the day. We think that this will help colleagues connect and strike up interesting conversations.”

They nod again.

“Yeah, I like that. The breakout in our old office is such an awkward area to sit in. People tend to eat lunch at their desks,” says Lisa.

Ramon chuckles. “Of course, you developers aren’t really ones for talking to people are you?”

He continues to laugh. Ben raises his eyebrow.

“We’re data scientists,” states Lisa.

“Let’s not get too distracted, Ramon,” says Reuben, pushing his glasses back up to the bridge of his nose with his middle finger. Let’s take a look at some of the work areas.”

He moves the next thick piece of card to the front of the deck. It shows the main floor of the office, sprinkled with clusters of white desks, each paired with black Aeron chairs. The desk islands are flanked by colorful fabric dividers, intended to give teams their own private spaces.

“I like this,” says Ben, pointing at the dividers. “I know we can’t all have our own small offices, but this is a pretty good compromise. What’s that on the floor?”

“It’s astroturf.”

“Why astroturf?”

“Because it’s a team sport.”

“What’s a team sport?”

“Coding.”

“OK.”

Ben leans in closer to the drawing, squinting.

“Hang on, what are those little boxes at the back of the room?”

“Ah, well spotted. We’ve thought about some features to make this place really cool,” says Ramon.

On cue, Reuben moves the next drawing to the front of the stack. Lisa is lost for words.

“…are those… dog kennels?”

Mia smiles. “Love the kennels. Love them!”

“Why would there be human-sized dog kennels?” asks Ben.

“We wanted an innovative and playful solution to the lack of meeting room space,” explains Reuben.

“I’m just not sure if it sets the right…”

“Get the geeks in the doghouse! A-woooooo!”

Ramon just couldn’t control himself. He’s not alone.

“A-wooooo!” replies Mia with her head tilted back. “I love dogs. Love them! This is so fun!”

“Erm,” says Lisa with a hand on her chin. “Isn’t that a little offensive? We’re not dogs, after all. We’re professionals.”

Lisa and Ben meet eyes. Their eyebrows couldn’t get any higher.

“It’s playful, Lisa. Imagine how fun meetings would be in the kennels! There’s even little dog bowl coasters for your coffee,” states Reese.

“Hmm.”


“A-woooo!” Photo by brittgow on Flickr.

A number of inoffensive drawings that did not contain dog kennels have passed by. The next card comes to the front of the stack. Ramon looks up expectantly with a smile on his face.

“Well?”

“It’s a bed. Why is it a bed?” asks Ben.

“There have to be cool places to hang out.”

“But on a bed?”

“Yeah. Imagine: it’s laptop and chill. Did you ever see Paula Yates on the Big Breakfast? Amazing interviews from the bedroom. Such creativity. It sets such a different tone.”

“I’m not sure if I want to lie in a bed with my colleagues,” says Lisa.

Ramon laughs. “I want all of these socially awkward developers to come out of their shell! This will be brilliant! Imagine them asking to go to bed with one another, it’ll be hilarious! It’ll break down social barriers. Create new friendships.

And maybe more if you know what I mean!” shouts Mia. “I love it! A-wooooo!”

Ben and Lisa exchange glances. Lisa interrupts the laughing.

“Have HR seen these designs?”

Thump.

The front door opens, and it’s the CEO, Tim. Reuben stands up and waves.

“I’m so glad you’re here,” says Reese. “We’re just getting to the design of your new office.”

Tim sits down next to Lisa and Ben. He smiles. “Looks good so far, doesn’t it?”

“…yeah,” says Ben, through gritted teeth.

“OK, to your office, Tim,” says Reuben, once again adjusting his slipping glasses with his middle finger. “Tell me what you told all of your customers at your annual keynote last month.”

Tim beams and sits up straight.

“We’re going to turn the world of software upside down,” bellows Tim through his immaculately projected stage voice.

“Please don’t tell me you’ve put his desk on the ceiling,” says Lisa.

Reuben rotates the cards.

“We’ve put your desk on the ceiling,” says Ramon.

Ben’s shoe is stuck to the floor.

Collaborating with marketing on launches

Leave a comment
Growth
The unveiling of the first generation iPhone in 2007. Photo by Kim Støvring on Flickr.


No big bangs

When launching a new product or feature, the last thing that you want to do is something risky. The most risky kind of launch is a big bang, where the application or feature:

  • Is shipped to production only as the marketing launch goes out.
  • Is enabled for all users at once.
  • Hasn’t been profiled against real load in production.

In order to avoid those kinds of launches, last week we wrote about techniques that engineers can use in order to make product launches safer. To recap, those techniques were to ensure that the team are:

  • Planning for usage that is many times beyond what the current system can handle.
  • Making use of feature flags in order to constantly ship the feature into production where they can see how it behaves.
  • Doing extensive load testing early enough to be sure of the architectural decisions.
  • Taking advantage of beta programs with trusted customers to get real, non-internal feedback on the production code as early as possible.
  • Using shadow loading to see the real production footprint, without those users knowing they’re using it.

However, using these techniques requires understanding and cooperation from the marketers that are going to be putting out all of the launch material: the new website, the video, the pre-recorded demos, the blog posts, you name it; there’s a lot of content and planning that goes into a high ticket item launching.

For example, they’ll need to know that you’re going to do a phased rollout beforehand in order to bake that into their messaging. They may also need to be flexible with the exact date of the announcement if progress is tight to the deadline, or if the shadow loading highlights that further optimizations need to be made. If the launch is going to target different geographic cohorts in sequence, then the engineers will need to ensure that the switching on or off of feature flags is coordinated in time with the messaging.

How can engineers and marketers work together better?

Questions for your marketing team

The worst launches happen when the only point of communication is the date at which the software is going to ship. Ideally, your product marketer(s) should be present for the duration of your project, at minimum attending the regular sprint reviews to keep on top of progress, and, even better, with them using those reviews as a chance to show how the launch material is coming together.

At the beginning of a project, there are some useful questions that the engineering team can ask so that they can better understand the particular strategic angle of a launch, and make sure that both engineering and marketing collaborate well from that point onward.

  • Who is the marketing launch primarily for? Is it for positioning a product or feature in the marketplace before your competitor does, or is it a riposte against existing competing functionality? Is the marketing message primarily aimed at those that don’t use the software in order to generate leads, or is it to re-engage and excite existing users?
  • How critical is it that the functionality is live at the time of the announcement?
  • What is the contingency plan if the engineering team are unable to make the deadline for some reason?
  • Does the new functionality need to be hidden from existing users until the launch happens?

Let’s go through these in turn.

Who is the marketing launch really for?

There are a whole bunch of reasons for doing a marketing launch.

The obvious reason is that we want to tell the world that our glorious new functionality has arrived. But why? What’s the deeper meaning? After all, existing users will notice that the new functionality has shipped because they’re already using the software: a simple in-app message would suffice for alerting them to its presence.

So, aside from adding new functionality for existing users, is the company trying to strategically position itself with the launch of a new feature (i.e. “we are the leaders in deep learning!”) or is it primarily trying to attract more leads for the sales pipeline? Is it both?

Often there are a number of subtle strategic motivations for the marketing message. Making them transparent to the engineers can inform their priorities, and can help form the contingency plan if the delivery is going to overrun.

For example, is the scope of the project completely fixed, or can features be chopped because the timing of the launch is the most important thing? Can we identify which features we could ship without up front? Conversely, is the date flexible because we want to ensure the highest quality product goes out to our current users?

Always talk about Plan B.

If all goes horribly wrong, what’s the minimum we could ship with? Could we move the date and still deliver the same impact with the marketing message?

Decoupling the announcement from shipping

As mentioned earlier, the engineers will be wanting to ensure that the production system is going to cope with the launch, by using techniques like feature toggling, beta programs and shadow loading. But no matter how brilliant or organized your engineers are, from experience, it’ll always be tight getting everything done to the deadline.

Sometimes everything goes spectacularly wrong. This will mean the project is going to be delayed. This might not be anyone’s fault: there could be a security breach, unexpected illness, or a database corruption elsewhere that needs more hands on deck.

So here’s the question: does the software actually have to be live at the time of the announcement in order for the marketing launch to be judged as a success?

If you think back to memorable announcements on stage by big players such as Apple, Google or Microsoft, how often was the product available right at the moment of the announcement? One purpose of these announcement events is to generate momentum and interest so that the new product sells well. If the launch is being judged by sales pipeline KPIs, shipping a bit later probably won’t matter, as your new leads aren’t using the software yet; they’re waiting for a demo.

The first public announcement of the 1st generation iPhone, complete with the in-depth demo by Steve Jobs, was at Macworld in January 2007. The first iPhone units didn’t ship in the United States until the end of June.

Was the initial iPhone announcement seen as a failure? Definitely not. Instead, they chose to do the right kind of messaging at the right time. The first in-depth unveil does not have to be the date that it is available. It’s when you know roughly when it’s going to be done.

Filling the marketing funnel can be done with a compelling story and pictures and videos. It doesn’t need shipped code.

Pleasing existing users versus attracting new ones

Even if your company is laser-focused on growth, you need to put your existing users first.

If they’re using your software daily as part of their job, holding back a legitimately useful feature for a future ideal date in the marketing calendar is doing them a disservice. Rushing a release for the purpose of a marketing splash has the same effect. They’ll know it’s half-baked, and they will think that new lead are more important than their existing custom. Worse, they’ll think you’re being dishonest by observing the quality void between the glorious marketing story and the buggy live software.

Ideally, existing users should be given new valuable features as soon as they’re good enough, especially if they’re paying money. It says “hey, you’re important to us and we’d like you to try this out.”

Those that don’t already use your software may not be attracted enough to buy until a new feature is iterated on. But remember: the video demo of the feature can be more polished, slick and perfect than it actually is. That video can go out beforehand, then the engineering can catch up.

Measurement

How does the company really measure a successful marketing launch? Is it namely on new leads that are generated and delivered into the sales funnel? Or is it the uptake in the usage of the functionality from existing users? Is it both? Are those two measured with equal weight, or is it skewed towards one or the other? Are they measured by totally different departments that don’t even talk about those metrics to each other?

Being clear with how the marketing campaign is being measured can open the door for engineers to help.

If it’s primarily to attract new users, then engineering can help prepare demos, videos and previews well ahead of the time that all of the functionality goes live. This can allow marketing to progress their campaign without being completely coupled to the stability of the feature or the shipping date.

If instead the feature is predominantly for pleasing existing users, then one could argue that time is better spent on in-app tours and big flashing arrows saying “check this out!” rather than a carefully crafted campaign on Twitter and PR Week. Are your existing users reading those sites, or are they just using your application?

Regardless of either scenario, knowing how it should be measured ahead of time allows the engineering team to improve the capture of usage metrics, such as specific types of interaction with the application or feature. This can include distinguishing whether users are new or returning, and which route they’ve taken to land there.

No alarms and no surprises please

What engineering should be aiming for in their relationship with marketing is transparency, and that works both ways. It means no surprises before the launch. It means the engineers feel confident that the marketing message is an accurate reflection of what they are building. It builds camaraderie and trust between departments, and allows launches to be exciting, not painful.

Here are some things to think about as an engineer:

  • Don’t feel pressured to give an exact date if it is currently impossible to do so. Instead, the engineering team could give an estimated month, or even a quarter. That doesn’t prevent marketing from planning their work; they can get on with it just the same. As time progresses and the estimate of a quarter becomes a clearer estimate of a month, then specific dates can be discussed. The worst thing to do is to give a exact date in the distant future that you can’t stick to. That’s where you’re putting both yourselves and the marketers under pressure.
  • Think about how you can serve the marketing team. Can you keep a stable build of the software running somewhere so that they can record their videos, run webinars and do demos to customers without your latest incremental pushes to production messing it up?
  • Get them into your sprint reviews. Regular attendance to see the progress of your work builds empathy and makes marketers more understanding of how the software is being built. As well as their feedback being extremely valuable, they can identify points where they can unblock one of the activities on their side: i.e. the product may be done enough to start webinars, even if many of the edge case bugs are still being ironed out.

If there is a distance between the engineering team and marketing, then something will inevitably go wrong.

Don’t let that happen.

In summary

Releasing software doesn’t have to be a sprint to a big bang on a specific date far in the future. By considering exactly how and why a feature is being launched, there are many techniques that can be used to ensure that the whole thing goes smoothly.

Consider the purpose of the launch. Is it for strategic positioning, to generate new leads, or to please existing users? Is it in fact all of these things, and how is it being measured? Also consider ways that contingency can be built around the launch by decoupling the day of the messaging with the day that all users gain access.

Work on building a transparent and open relationship with your product marketers. Get them in on day zero, show your progress, and plan the rollout of the feature together. Spend serious time thinking about what to do if it all goes wrong. You will both learn a lot from each other.

Shipping is tough, but it can be made easier. Think about it. Why not do it over a coffee with your product marketer?