The Engineering Manager

Positioning, positioning, positioning

The best software doesn’t sell itself. Even if you did have the best software, it needs to be positioned, priced and pitched correctly to stand a chance amongst your competitors, and that’s where product marketing comes in. As a manager of an engineering team it’s likely that you’ll be regularly working with a product marketer to make sure that the cool stuff that you’re building is making the biggest splash possible.

Great product marketing can make the code you’re writing into something that people need to have. This is most easily demonstrated by example. To begin with, consider this: a customer messaging platform. Sounds boring. But by using Intercom, and especially when perusing through their wonderfully designed guides, you’ll wonder why you didn’t start using it sooner. Now consider this: yet another instant messaging program. Yawn. But after having a read through the beautifully written and illustrated Telegram blog I was downloading their app and I’ve been using it ever since. It makes a lot of difference. A world-class engineer, designer, product manager and product marketer can really change the world.

In the wider world beyond software, clever positioning of a product can dramatically widen its reach. For example, Cirque du Soleil are not just positioning themselves as a circus act. They are a brand that compete against theatre, movies and musicals worldwide.

So what is product marketing?

Product marketing is a really interesting role. It’s a kind of hybrid of product, sales and marketing. Small SaaS companies may have just one product marketer for their application. Large companies may have one product marketer per tool in their suite, or they may have many product marketers producing content to appeal to particular user personas.

As an engineering manager, product marketers are extremely useful to make sure that your team are iterating quickly on the most impactful features, that they are getting feedback from users quickly and therefore experiencing the true impact of their work. We’ll have a look at how we can help them help us shortly, but first let’s explore their role.

So, what do product marketers concern themselves with?

• Creating a compelling narrative and positioning for the product that you are building. Why does this product exist and how is it making its own ding in the marketplace? Why is it so much better than competing products? Why is it so much better value for money? They have the answers to these questions.
• Deciding the right moments in time to make big marketing pushes for big impact. Your product may have new features and functionality added weekly, but when is the right point of the year to turn the wheels of the hype machine and do a big, splashy launch? When should they spend marketing budget on creating an advertising campaign? How does that line up with what the rest of the company is doing and with competitors’ launches?
• Engaging with customers and tracking usage of features. Your product marketer will obsess over how new functionality is being picked up when it hits production and will keep a close eye on feedback, whether implicit or explicit. They’ll reach out to your biggest customers directly for feedback. They’ll worry when few people engage with your latest product feature and want to help you fix that problem.
• Steering sales enablement. Your product marketer will be the biggest champion for your software and will spend plenty of time narrating the story and purpose to the sales team. They’ll do demos for them, run sales enablement sessions, get them excited about what’s coming down the pipe, and give them hints and tips on how to sell against competing products and how to get the most out of your new features.
• Advising on pricing. It’s extremely hard to get pricing right in an ever more price sensitive economy. Your product marketer will eagerly study what your competitors are charging and what their billing models look like so that you can have the best chance of fighting them.
• Feeding back from the marketplace. Your product marketers should be sitting in on sales pitches, demos and executive business reviews with your key clients, listening to their needs and then feeding it back. As well as bringing products to market, they should bring the market to the product.

Helping them help you succeed

As you can see, product marketers do a lot! They’re invaluable resources for your team, connecting you with customers and further convincing your own engineers of the over-arching purpose of what they are building.

But this seems a world away from engineering management, which is your job. Is there anything that you can do to help them do their job better and therefore make your team’s work even more successful? Well, fortunately, there is a lot that you can do.

Let’s explore how you can help.

• Find the product marketer(s) who are working on your area of the application. Your team and department may already have strong links with those that are doing product marketing, but it’s equally possible that they sit in another department, or on another floor, or even in another office in another country. How often do you meet with them? There may be a lot of disconnect between the engineers writing the code and those weaving the narrative. Find them, introduce yourself. Take them for a coffee if they’re nearby. Ask them how they do their job. Ask how you can help. Enquire as to whether they have any frustrations. Even better, see if they can come sit with your team on a regular basis to form a closer bond.
• Include them. Open up your world to them. Invite them to your sprint demos. Get them in your Slack channels. You want to have a fluid, open conversation going at all times. See them as an integral part of your team. This gives them the chance to offer feedback (from themselves and also customers) at the earliest possible stages, creating the opportunity for them to motivate and steer the team.
• Describe the reasons you think that you product or feature is awesome. Your team will work on more than just customer facing features. They may improve uptime, speed or the number of concurrent users that your application can handle. These aren’t always clear to your product marketers, but they are great ammunition for them to further improve their message.
• Let them practice their narrative with your team. Not only does this give the chance for them to have a safe space to craft the ongoing story of your features and receive feedback, it also gives them the chance to expose the impact of the work that your team is doing. This is extremely motivational and breeds a feeling of purpose and desire for your team to do their best work: it really means something!
• Build in feature toggling. For the greatest possible market impact, your product marketer may advise batching together the unveiling of a set of new features and launching them as part of a campaign. You won’t want to hold back code changes indefinitely, as continued code changes can end up blocked behind stale code that hasn’t yet been released. Instead, build in the ability to feature toggle and keep shipping to production in secret. We’ve had great success with Launch Darkly, which allows code to be wrapped in feature flags that can be turned on and off dynamically. It can also do targeted or percentage-based rollouts; ideal for enabling features for trusted clients for early feedback, or letting your company’s employees use the most bleeding-edge features.
• Track usage. Always call upon your product marketer when designing new features so that you know what the important metrics are that should be tracked. Is it clicks or opens or conversions? Is it session length or actions performed? These tools give your product marketer greater power in investigating how well features are being received.
• Build in survey functionality. This could be as simple as a net-promoter score prompt that appears occasionally in the application, or could be a detailed survey that is delivered to users quarterly.
• Let them talk directly to customers. Again, Intercom has been an excellent tool for this. As well as telling their narrative via marketing material, we’ve been using Intercom to let our product marketers deliver product updates, targeted messaging and receive questions and feedback directly from customers through the application. Doing so requires no intervention from the engineers.

In summary

If you’re running an engineering team, then having a good relationship with your product marketers can help you make your work land with impact at the right place and the right time. There are a plethora of ways that you can help make life better for your product marketers, and it’s in your team’s best interests that you do.

Make sure that you’re getting the most from them: early feedback on product development, intelligence on your competitors, clarification of the value (to users, but also monetary) of what you are building, your messaging to the market, and help defining targets behind usage and interest. Go and use them!

Thank you to Phill Agnew for the comments and feedback on my draft of this post.

Building people and technology

When your company is at an early stage, hard graft, rather than complexity, is the focus. Communication doesn’t require careful thought or organization because you’re either sitting next to each other or there are few enough of you to make decisions over video calls, emails or IMs. If there’s friction or disagreement amongst key people, then often the fight to keep afloat takes precedence anyway, dampening the urge to keep negotiating. Instead, you just do.

For the lucky few, dreams of success at those early stages can become a reality. That reality can be one playing out in fast-forward. Your company could attract funding and grow aggressively, expanding into many geographical locations and in turn create multiple products that each generate their own revenue streams. That’s all brilliant. But success and scale also cause drag: communication gets harder, collaboration becomes trickier and decisions require much more lobbying and consensus. Trying to continually adapt how the department works as it grows and matures is a continual iterative process that you’ll get wrong more than you get right.

From a technical viewpoint, as a product and company grows, so does the complexity of adding new features. In the early days where only a handful of developers were required to build the whole thing, decisions and progress were fast. But now building innovative new features often requires a multi-team effort: provisioning of new hardware or infrastructure, plenty of data science to prove concepts, new APIs and services built with future reuse in mind, and sweeping changes to the UI.

It becomes harder for each team to cleanly and completely own an area of the application. Dependencies begin to occur between different areas of the department and communication becomes more complex. You could argue that the hardest part of having a successful technology company is solving the technical challenges, but when it comes to doing this at scale it’s more often than not a people problem. How can everyone remain productive as the department steadily grows? Are there set processes and techniques that we can use to make this all predictable and frictionless?

Process isn’t always the answer

Being engineers at heart, we often try to solve all of our problems in the same way that we try to solve the problems that we have with technology. Surely, if we can streamline algorithms and build processes we should be able to apply the same logic to problems in the domain of communication and productivity, right?

Well, sometimes.

If we’re not careful then we can end up layering more and more complexity on top of what are essentially people problems and then inadvertently create even more people problems as a result. It’s a vicious circle.

It is sometimes necessary to take difficulties in the department and assess them as people problems rather than process problems to see if there are far simpler ways that they can be fixed. Let’s have a look at an example that we worked through in many iterations at Brandwatch. We still don’t have a right answer, but I feel that it highlights how we incorrectly identified a people problem as something that could be solved with even more process when the solution was in fact far simpler.

Pull requests

For many years I’ve been involved in reviewing code. This example covers how we worked through some issues with scaling backend code review as the department grew.

If you’re not familiar with them, pull requests are a method for submitting modifications to a codebase via Github so that others can review them before they are merged in. We’ve been using them for many years, and they’re great. However, when we first adopted them it took a number of adaptations to the way we used them before frustrations went away.

Let’s start with some history.

A very long time ago, in a pre-Github era, there weren’t many developers in the company. Typically people would ask for a quick in-person code review before pushing their work into the testing environment. Although an imperfect process, it encouraged people to seek review themselves before their code went any further. However, as we grew, and as the pull request functionality in Github became a lot better, we migrated to that system because it made it much easier to organize detailed reviews, especially when the number of developers in disparate geographic locations began to increase.

However, the pull request process highlighted a multitude of ambiguities in how we got things done:

• How many people were required to review a given change before it could be merged in?
• How senior did the reviewer need to be so that the review could be trusted?
• Who was allowed to click the “merge” button once the reviews were complete?
• How were conflicts resolved if the reviewers didn’t agree or if the submitter disagreed with the reviewers?

Mergers

In order to answer these questions, we added another layer of process: a group of senior and trusted developers called mergers, who had the authority to decide the fate of a pull request and ultimately were the ones that were allowed to click the “merge” button. Our new mergers enjoyed the initial responsibility and spent much more time carefully reviewing code. Two reviews were required: one from the merger and another from any other developer.

However, with time this additional layer of process created more people problems:

• Our mergers became a single point of failure and if any of them got busy or sick then the throughput of teams suffered.
• This also increased the amount of pressure that our most senior developers had on their job: they were now slowing up the rest of the department if they were busy with their own work!
• Those that were not mergers felt like they had diminished responsibility. Not only did this make them feel like they were not trusted enough, it also dramatically reduced the amount of time that they spent reviewing code because they felt that a merger would need to do it anyway, so why bother?

SLAs

Of course, to solve this problem, more process was added! We implemented an SLA for pull request review which mergers needed to stick to.

This made things worse:

• More pressure was being put on the mergers to review quicker.
• The SLA was being observed regardless of the size, complexity or impact of the pull request. Some bug fixes take 30 seconds to review, and some architectural pieces can take multiple days.
• Our delivery managers would chase pull requests that weren’t meeting SLAs, causing even more stress for our mergers. They started to really hate the responsibility.

Easing the grip

After a while, it was clear that our issues with code review were people problems. I reached a point where I felt I was spending too much time in the week addressing problems that the code review system had caused: stalemates due to disagreement, pressure from the business about things being “too slow”, angry staff who felt powerless to get their changes through, endless cyclic arguments from code style to personality clashes.

It was time for change. Fundamentally, regardless of process, we wanted to aim for the following:

1. Everyone should feel empowered to make changes to the codebase.
2. It should be in the best interest of the submitter to get their changes reviewed and merged. They have ultimate responsibility for the progress of their review.
3. We trust that each engineer would submit their best work for review and would not want to do anything destructive or malicious.
4. We trust everyone to give suitable constructive criticism, no matter their seniority, and to do their best to prevent bugs or odd patterns making their way into the code.
5. Regardless of what happens, it’s just code after all. If something causes a bug when it gets merged into the codebase, we can just fix it or back it out. No big deal.
6. Two positive reviews and it merges. No specific mergers required. The submitter should feel empowered to nominate reviewers if there are specialist concerns.

We’ve operated with this model since. It still has its flaws, but for the size we are now it makes do, and requires very little policing or intervention. It allows most review to happen within teams, too.

Redefining what we wanted to fix as a people problem showed that none of these ambitions required monitored implementations of particular processes. Instead, we just needed to encourage people to feel empowered to get on with their jobs to the best of their ability. And best of all, it had entirely positive effects. More people became empowered to get involved in reviewing because they could affect the outcome. Teams felt like they could take more control of their destiny by reviewing the code of their teammates rather than relying on nominated engineers in other teams and locations. And, when very complex or controversial pull requests were opened, people actively sought reviews from the right people themselves because it was in their best interest to do so.

In summary

Before you add another process or piece of technology to solve an issue, stop and think: is this a people problem?

Although it can be tempting to use one’s engineering brain to solve issues as if they were an algorithm, often that isn’t what needs fixing. In our example, an increase in trust and autonomy of individuals made people work more efficiently, rather than trying to layer on more process. We are just humans after all.