Came for the banter, stayed for the wisdom: Lessons from 10 years at the same company

Chris and I met when we both started working at Campaign Monitor in 2015, him having started several months before me. We started working in the same team, spent a few years in separate teams, and then worked together again but with a couple of different team structures. This post is an adaptation of a presentation we did at our company offsite called Devcamp. The inspiration from this talk came from many of the people we have worked with, some of whom are actually no longer with the company. Rather than singling out individuals or specific events, we built the presentation around themes that we teased out from all of the learnings (and laughter) we collected over time. Most of the presentation slides were gifs, and I have included only a handful of them.

✨ Introduction

Thank you to Rashmita, David, Sha, Karthik, Fab, Shen, and the Henries™ for also organising Devcamp with us this year. 👏🏻💕

I’m hoping you all packed light for this. (This was the first time we’d travelled via air for a Devcamp event, and the luggage restriction on some budget airlines had some people a bit worried. I mean, I fit a tripod into my backpack.)

We are Chris and Georgie.

Back in 2015 we totally went to space thanks to the email builder.

Between us we’ve pretty much worked on every customer facing part of the product, including journeys, campaign reporting, and a whole host of other things. (We’d just be damn near flexing if we read them all out loud.) Most recently we launched landing pages in Team Hopper. And if you count anything with CMDS (Campaign Monitor Design System), code we’ve written is in every user interface that’s been built since 2017.

Outside of developing product UI, we have done public speaking locally and internationally, organised Change Days, Bread Talks, and multiple Devcamps.

I (Georgie) am also responsible for a lot of the poop emoji in Slack—you’re welcome. 💩

And between us we have eaten all the Skittles.

Chris has had more managers than there are planets in the solar system, even if you count Pluto. 🪐

So, in summary, we’re pretty insufferable. 😝

Over the past ten years we’ve learned some things from working with great people, and wanted to share what we think are the most valuable.

🔍 Observe and learn how things play out

The first is to observe and learn how things play out when they don’t meet your expectations. I’m pretty sure introducing something to a company and then leaving shortly after is the ultimate power move. You get to look like a hero then everyone else has to deal with the consequences.

I’m sure you can all think of at least one technology or integration we had to introduce and then continue to support, after the person who introduced it left the company.

Changes are rarely instantaneous and often take time to play out. When they do, learn from them. When the average tenure of a tech company is 2–3 years, people making changes they don’t have to personally deal with is a reality.

A recent example was a project called Bloom. It was a decision to dedicate all our efforts to build an entirely new Campaign Monitor in—let’s just say—a very optimistic timeframe. Given that we’re no longer working on that same project today, you can see how that actually played out.

You are going to experience these kinds of projects in your career. They feel like slow moving train wrecks that you can’t stop. So you make your voice heard, you move on, and you find ways to make the work interesting.

And if you think it’s a total dumpster fire, you make sure it’s easy to remove afterwards. 🧹

🎤 Don’t expect people to understand you just because you’re talking

Consider that people are wired differently with different communication styles. Us talking up here isn’t one-directional. Good communication means that we all understand each other. It helps set and meet expectations all around.

Here’s a hot tip: Don’t put a wall of text on a powerpoint slide.

And there’s no need to say more words just because you’ve got the microphone. Get to the point. If you have a lot of information to talk through, make it interesting for those of us who need more dopamine to pay attention—use visuals, read the room, encourage engagement from the audience. Raise your hand if you own a dog? 🐶

Quiet people often have something valuable to say but are waiting for the right moment. Make sure that it’s always a safe space for these people to communicate.

Tailor your communication. Your product manager needs to know how things affect the customer, not the details of code cleanup or refactor.

Communication is not just limited to talking. When someone is confused and looking for an answer, documentation is an example of communication that continues to become valuable after the passage of time.

It is also not limited to code. If you’ve been around long enough you see the resurgence of certain projects. Talk of a mobile app has come about again. Subject line tuner, two more times. What’s being done differently? What research was completed? What did we discover? Found an old Invision prototype? We don’t have access to Invision anymore! (Awkward.) Documenting history ensures that we do not do the same projects over and over.

Those who do not remember the past are condemned to repeat it
—George Santayana

Communication doesn’t just land in your lap. It is a skill you have to work on and practise using every day. I hate to break it to you, but AI can’t teach you to communicate. It might capture pure facts and spit them out, but will fail on delivery. You also still have to do the mental work to follow up with conversation. AI also won’t be there for you when it comes to a conversation in real time or in person. Plus, if you have good communication skills to begin with, you can smell an AI-written message from a mile away.

📈 Don’t change for change’s sake

If I visited my doctor and they told me I need to get my appendix removed without a single word coming out of my mouth, I’d be pretty alarmed. People often have an action bias. Maybe it’s that some former team or company did it a different way, and they expect the same result every time.

Unfortunately people don’t spend enough time understanding the code, processes or the teams involved. These changes have unintended consequences.

The trouble is, we see an oversimplified version of what we want to change if we don’t spend the time to understand. A recent example is the discussion of AI replacing people’s jobs in our industry. The industry has been losing its collective mind since November last year. 🤯 From a one-thousand-foot view, dollars are input, and code or design are the output.

But the people—your team mates—bring all the tangential context, subject matter expertise and debate on how to achieve our goals to build products customers actually love, rather than cookie cutter slop built without knowledge of the customers we have, or want to have. Coding is only part of what the engineers here do, mockups is only part of what the designers do, so what is the process of getting to the best result?

Garbage in, garbage out
—George Fueschel (apparently we only quote people named George)

George Fueschel created the principle “garbage in, garbage out”. The quality of the output is determined by the quality of the input. This is particularly apt when dealing with the idea of AI replacing key team members. If you want to bring change, make sure you actually understand what systems you are changing, and how your change is actually better than what was there before. Otherwise you’re just guessing. What you are introducing could actually make things worse.

You are fixing it until it’s broken.

We encourage anyone to learn to observe and understand before acting. If you can’t demonstrate why your change definitely makes things better for everyone, then don’t make the change.

🔌 Things fall through gaps; plug the gaps

A fire in your neighbour’s apartment might not be your immediate problem, but it’s going to be your problem soon enough.

Ever come across some form of the “not my problem” attitude?

There are seams in every organisation, stuff that sits in the grey area between teams and disciplines. The customer doesn’t care about your organisational structure, they care that their experience with the product is shit.

No single person knows everything, we do best when we combine our talents and knowledge. Examples of collaborative initiatives and opportunities to share our knowledge at Campaign Monitor include:

• Product Dev Knowledge Sharing, every 3 weeks: an opportunity for engineers to share technical problems they have solved, improvements, or other recent work. It encourages sharing knowledge beyond teams and demonstrates what other teams can benefit from, learn from, or use. It came about during a large UI/UX refresh involving a large percentage of the entire product and engineering departments.
• Design Review Crew, every week (if people have work to share): an initiative to foster collaboration between product and design. It originally started when we had limited design resources, and a stable design system with a handful of components, and the goal was to reduce the strain on the design team and have a dedicated casual forum for discussing upcoming work. People bring mockups or ideas to the group for a feature that is about to start development, or in early development. The group consists of designers, engineers, product managers, and domain knowledge experts.
• Tech showcase, every month: a presentation style meeting where teams can showcase recent features they have released, or that are in development, to bring awareness to the wider engineering group.

These initiatives promote visibility and feedback, and all of them have been around for years, even pre-dating the pandemic lockdowns in 2020.

🎓 Leadership is not a title

I want you to think about someone who is a leader but doesn’t necessarily hold a leadership title. They care, guide, and teach the people around them, helping them take advantage of opportunities. I bet you thought of not just one person, but a few.

The best leaders don’t seek to promote themselves but the people around them. They make sure the right people get the credit for the work that’s actually done.

Leadership is a support role, not a power trip. Terrible leaders push you around. Good leaders support you to do what you need to get done. And you actually miss them when they’re not around. If you’re looking for a template for leadership, look for the people with these qualities as your inspiration.

🌻 A weed is just a plant in the wrong environment

A great performer can do terribly in the wrong role or team. Team dynamics matter. If the team dynamic is poor, people will not perform well.

If you don’t feel valued, you’re probably not going to do your best, why bother trying?

Even a hardy plant like a cactus wouldn’t do well in a rainforest.

I assure you, no AI was used in the making of this slide.

To share a personal story: Before the UI Services team formed in 2017, I found myself stuck, working with someone who diminished opportunities for me to contribute the best of my technical skills. I debated leaving the company and even considered a complete career change because they made me feel like I wasn’t competent enough. It even had other people at the company doubting my capabilities. The impact this had on my self-esteem was damaging.

The difference between that team and UI Services—a team dedicated to working on a design system and tools to help other teams build UI—was like night and day. In UI Services, I had space to use my skills and contribute my ideas. I was listened to and respected, and supported while doing a complete gamut of things from facilitating meetings and writing documentation, to speaking at conferences.

If you see someone struggling, don’t just assume they’re the problem. Maybe it’s their environment. Maybe they’re stuck, maybe they need to be in a different team, or need something more challenging or stimulating.

Sunflowers are actually considered a weed but flourish in the right environment.

🧠 Claiming expertise can be limiting

I love this comparison so much. A futurist with a fancy title, “Digital Prophet”, versus the person who invented the web—Tim Berners-Lee—whose title is “Web Developer”.

If you claim expertise, you’re attaching your reputation to your skills. Now you always have to look like you know what you’re talking about.

We grow by experimenting, by being wrong and learning better ways. By trying to defend yourself as an expert you limit yourself, and you don’t give others the opportunity to learn with you.

We all do better when we leave our ego at the door.

💌 In closing

These were the gems we collected over the years. 💎 We couldn’t have lasted ten years without the people and the memories they created, so, some honourable mentions:

• #kitchen-crankypants, a Slack channel inspired by T4’s grumpy comments about people leaving the coffee machine in a terrible state (back when we had a permanent office and a kitchen 🪦)
• Our designer Fabre making flawless gifs of the team attempting the party parrot emoji and doing other funny movements
• Trips’s catchphrases and his attitude towards problem solving, always trusting you that you had the right answer, and his ability to break laptops
• Courto being the first person to open up about mental health in a Bread Talk, creating a shift in how we approached looking out for one another
• #the-loud-corner Slack channel, which Greeny dubbed “The reddit of Campaign Monitor”
• Classic Zoom fails, showing people working in tech can also be completely inept in technology
• Georgie saying that there’s no such thing as work life balance
• Chris shaking a pudding at Devcamp 2016

…and many more memories to be made this year at Devcamp.