Management bugs: 18 months later

Leave a comment
Growth
Photo by michael podger on Unsplash.

Nearly a year ago, I wrote an article on an initiative called “management bugs” that I had introduced into our Engineering department at Brandwatch. If you’re not familiar with the concept, then I go into a fair amount of detail in the previous article.

However, in summary:

  • The management of the engineering department have their own JIRA backlog that staff can raise “bugs” into if something isn’t working quite right.
  • Anyone can raise bugs, regardless of role or tenure, and anyone can view or comment on them.
  • There is a designated person (me) who receives, triages and dishes out bugs to the relevant people in order to solve the issues.
  • Typically the bugs become part of the agenda at our management meetings, and are taken away as actions.
  • Once resolved, a summary is written of the outcome and emailed around to the department mailing list.

This week, I was invited to give a talk about the management bugs initiative at The Lead Developer Meetup which was hosted at Intercom’s office in London. In my talk, I introduced the concept and walked through some of the things that had changed in our department as a result.

In preparation for the talk, I revisited the management bugs scheme by reviewing all of the bugs that had been raised and closed. We’ve been running the scheme since summer 2018.

Here’s what I learned:

  • In 18 months, we’ve completed 48 management bugs, with 5 currently in progress. So that’s a new bug every week and a bit. Although, it has to be said that the average number of bugs is skewed by a deluge coming in at the beginning of the initiative, and it has lessened with time, hopefully because we’re getting things fixed!
  • An overwhelming majority of bugs were opened by non-managers. This is great, as it shows that our staff feel empowered to raise their concerns openly with their names attached.
  • The typical length of time that a bug was open for ranged from 5 minutes to 1 year! Some issues were extremely simple to solve, and some were not even necessarily solvable.

I sifted through the bugs to get some examples of issues of different sizes.

Here are some examples of small, quickly solved issues:

  • What do the VPs do? As a VP, this one hit slightly close to home! However, it was a good example of us failing to regularly share the location of our career tracks document, which details the roles and responsibilities for the individual contributor and management tracks.
  • New starters aren’t getting introduced! And indeed, they weren’t. We now make sure that every new member of staff has an introduction sent to the department from their manager detailing their name, what they’re working on, a picture of what they look like, and any self-declared interests and facts to help break the ice.
  • Is there a budget for books and courses? Well, yes, there was, but we had never really documented it. So we did.
  • New staff outside the UK aren’t getting dialed into induction meetings. Oops! That doesn’t happen any more, and all calendar invites now have proper video call links.
  • New roles aren’t being advertised internally. Often opportunities would arise in teams and the outside world would know more than our internal staff who might be interested in working on something new. We make sure that we publicize roles internally now also.

How about some of the medium sized issues?

  • Why aren’t we getting faster as we’re getting bigger? That classic debate. It had a whole bunch of fascinating input from people in a variety of roles in the department. I wrote up a fairly in-depth summary about productivity per head decreasing as you grow, including mention of the Mythical Man Month, speed of decision-making, and the Innovator’s Dilemma, and how we could keep this in mind as we go forward.
  • Why do we not advertise roles as part-time? Well, after a bunch of discussions, we now do, and we have part-time staff that we have hired into our department. So that was a success.
  • When are we going to rewrite the frontend? We’re not, but this did help instigate further discussion about architectural and technical debt work that we needed to tackle, and we now have a permanent stream of work to address it.

Lastly, what about some of the issues that took a very long time to resolve?

  • What is our technical vision for the department? Tricky to define, as it cross-cuts so many different skill sets and areas, such as what our cloud strategy is (we run both cloud and hardware for different parts of the system), how we migrate towards Kubernetes everywhere, whether or not we should standardize the storage and deployment technologies in all teams, and so on. We made a fair bit of progress, but then we went through a merger, so this is all up for further debate again…
  • Why don’t we sign up for StackOverflow for teams? We made the decision very quickly that we’d like to, and we ran a trial that was very well received. It just took a long time to secure the budget. Sometimes it isn’t always the consensus that takes the time.

All in all, I’ve been really happy with our management bugs initiative. I hope that it has made everyone empowered to make change, regardless of their seniority or tenure in the department. It’s also allowed myself and others to get involved in discussions with individuals that we otherwise would rarely talk to.

The challenge that I set the audience of the meetup was that they should go away and do something similar in their own Engineering department. Will you?

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?