The Engineering Manager

Imagine

What do you think about when you imagine a good leader? What sort of person are you thinking about? What age are they? Which gender? Now, let’s think about what you’re imagining them doing. Are they giving a talk? Are they motivating a group of people? Are they congratulating them after a major success? Maybe you have a less positive connotation. You could be imagining someone shouting, or being angry or pushy.

It could be that the person that you are imagining is someone you know, or maybe it is someone that you look up to. Maybe it’s yourself! Either way, I can’t predict what you’re thinking about. However, I have a conjecture: I reckon that it’s unlikely that you imagined someone predominantly showing kindness.

Is that true?

Stereotypes

In the opening gambit, I wrote down some of the variations that came into my own mind. What were they?

One common visualization is that of the inspirer: The politician, public figure or the CEO of a notable company. If you were working for this person, it is likely that you wouldn’t be working for them directly; you’d be working for them because you’re in their organization. Since you aren’t interacting with them on a personal level, you may be influenced by their public persona or what their company is achieving. You may look up to them speaking at large events or conducting themselves with civility in the public eye.

Another is the motivator. When visualizing this person, it’s more common to imagine yourself working with them on a closer, individual level. For example, they could be your direct line manager. You may have thought of them in a room with you individually or collectively with your team, offering some praise or words of advice. This person makes you feel secure. You trust them.

The third type of person that came to mind represents the negative stereotype of some leaders. Perhaps we could call this trait the drill sergeant. Angry, shouting, ruling with an iron fist; yet trusted, because if this person isn’t going to take any crap from you, then they’re probably not going to take any crap from anyone else either. You’re safe, albeit through fear. They probably deploy the stick on a regular basis.

I mentioned that it was unlikely that you imagined someone being gentle and kind. It might not be the first thing that comes to mind, but it is critically important in being a good leader. Let’s have a look at why, and follow with some examples that I’ve experienced of how to use kindness for the greater good.

Being kind

First up: let’s abolish the stereotype that being kind means that you’re being soft. That couldn’t be further from the truth. Being kind doesn’t mean letting standards slip, or accepting poor performance, or protecting your staff from interacting with difficult personalities or projects.

An effective leader who is also kind is a show of strength through emotional intelligence. Being emotionally in tune with those that you work with means that your staff will feel listened to, wanted and cared for. In turn this increases trust, which allows for open and honest relationships; a key to retaining staff through bad times and good.

As software continues to eat the world, the job market for your most talented staff is a fully-stocked candy shop that sends them enticing emails on a daily basis. Given that there are so many different companies to work for, located all over the world (noting the increase in remote working), you’re going to find it difficult to offer a constant rotation of extremely exciting projects that will be more attractive than what a headhunter is luring your staff with. However, as we’ve tried to show on this blog, you can compete through camaraderie and kindness to your staff. It’s also the right thing to do.

How can you be kind?

I’d hope that we all know how to be kind in general, and that is certainly encouraged, to say the least. But what are some techniques that demonstrate your kindness and in turn build better relationships with your staff?

• Asking questions and listening: In an earlier article we have touched upon the notion that your meetings with your staff should be their meetings rather than yours. This means listening more than you speak, and asking questions rather than being directive. Simply allowing this space to be theirs is an act of kindness, that you value their time and opinion. Better still, this allows a the topics of conversation to ebb and flow, offering opportunities for you to get to know them better on a personal level.
• Being open and honest: Yet another reference to Radical Candor. Don’t worry, I’m not getting commission. But being open and honest in your conversations with your staff is a way of showing kindness: it shows them that you care to be transparent, and to offer your unsolicited praise, feedback and critique. This in turn demonstrates by example that you encourage them to do the same with you. If you build this level of rapport, then it is more likely that your staff will open up to you about deeper issues with time.
• Appreciating hard work: Simple gestures of kindness go a long way. Making sure that you say thank you, privately and publicly, has a much greater impact than you may think. Additionally, if you have a team who have worked hard to meet a deadline, are there ways that you can relax their output over the following week to help them recoup? For example, you could offer them the ability to work on improvements of their own choice, or give a safe period to pay down technical debt. Using small parts of your budget to signpost success is also an act of kindness: taking a team out to lunch, or for an activity together.
• Offering flexibility: Being sympathetic to constraints outside of work is kind. Flexible working from home days, or flexible start and end times for those with dependents can help immensely, especially when it can take the pressure away from your staff’s partner or family. When people are sick, make sure they go home and rest rather than fighting through. If someone needs to go to the doctor or the hospital, just let them go rather than needing use up their holiday time.
• Giving time back: Sometimes life can throw curveballs, such as a sick child, a sick partner, a grievance in the family, and so on. If it turns out that your staff has taken holiday in order to be present for issues like these, you could consider giving some of their holiday days back to them as an act of compassion.
• Doing your research: If a member of staff opens up about a personal issue, such as a mental health problem, or has concerns about something either inside or outside of work, then an act of kindness is to go and do your research on it. Look it up. What does it mean? Can you help, or is this something that requires help from others in the company, or even medical or professional help? Caring personally allows you to encourage your staff to look into getting help either from you or others. It also shows that you have an interest, and it encourages them to strengthen their connection with you through conversation.

In summary

Leadership isn’t all about bravado, or wielding the stick, or being inspirational and larger than life. Instead, it can be just as effective to be kind and compassionate. Doing so builds a bond that makes your staff want to continue to work with you, and encourages a positive culture in the workplace.

A month after launch

A much-awaited upgrade to your application went live 4 weeks ago. It was probably the most organized launch that your company has done so far. It hit production well on time for a start! Customers logged in on Monday morning to an in-app announcement about the new functionality. The team felt great for making it over the line. The marketing collateral followed on the brochure site and your social channels at 2PM UK time to ensure that American customers saw it first thing in the morning. Usage tracking was carefully thought out to follow the user journeys. KPI dashboards were defined well in advance. For once, the engineers and product manager felt like they shipped something calmly and confidently.

But, here you are, 4 weeks later. Frustration. Extremely poor uptake from users. Did people even notice that it was there? How could they not? You told them via email, in-app message, Twitter, Facebook, LinkedIn; you name it. No conversions to the premium package at all. What on earth happened?

The engineers are feeling deflated after such a disappointing launch. Product are getting their fair share of blame for the lack of usage, especially taking into account how long it took to build, and the features that the team couldn’t build while it was underway. The situation comes to a head in the team’s weekly meeting whilst analysing the usage data. A snide remark from one of your engineers starts it off.

“Well, the usage would probably be better if the feature was more interesting, right?”

Your product owner, rightly, goes on the defensive, but withholds her anger.

“We were all behind this being a success a few weeks ago. What makes you say it wasn’t interesting?”

“It’s just not a particularly smart feature. We could have done so much more with the algorithms that recommend content. It’s pretty simple to do as well.”

“Right. So why didn’t you suggest any of that when we were designing it?”

“That’s not really my remit; I don’t really know what the customer wants,” exclaims the engineer.

“But you just said it could have been much better! You knew how, too!”

“But that’s not my call, is it? You’re the ideas person, right?”

Working with product owners

The fictitious situation above is a riff on a real situation that I have experienced countless times. As soon as the relationship between Engineering and Product becomes anything other than symbiotic, you’re asking for trouble. In an ideal world, a strong engineering lead (or team) combine with a strong product owner and, like Voltron, become a force to be reckoned with. The engineering team bring innovative technological ideas and a knowledge of what is and isn’t possible, and the product owner brings clarity on customer needs, the job to be done, and the predominant feature ideas that can satisfy these needs.

You’ll repeatedly read that a “healthy tension” should exist between Engineering and Product. This is true. However, this can also be interpreted wrongly. It doesn’t mean that there should be purposeful conflict and loyalty to sides; instead the tension should exist between innovative ideas and their possibility within real-world technical constraints. Additionally there is an ongoing tension as to when to pay down technical debt rather than consistently rolling out new functionality.

But I mentioned the term symbiotic for a reason: a feature team without a good product owner is stunted in their ability to do their most impactful work for users, and a product owner without a good engineering team is unable to deliver their vision.

What happens when the relationship isn’t symbiotic?

1. Silos: Where both Product and Engineering metaphorically exist on two sides of a wall. Product throw ideas over the fence at Engineering, who blindly implement those ideas as best as they can.
2. Engineering don’t “do” ideas: If your engineering team refuse to take ownership over what they are building as well as how, then you can find yourself with a blame game when things go wrong. Also, a wealth of interesting ideas from Engineering go unsurfaced.
3. Product don’t “do” implementation: When Product don’t take an interest in how things are built, with a longer term view to understand better how engineering constraints work, then a product owner can miss the trick of learning how to better engage with engineering teams, and also question and critique their approaches.

Let’s dig into all of these in more detail.

Silos

To begin with let’s talk about collaboration. Even though in theory you have your product owner owning the strategy, ideas and ultimately the backlog for the team, and likewise, you have Engineering owning the implementation, if both parties are not collaborating deeply then the software will be much worse off.

Let’s consider a hypothetical situation where a product owner doesn’t talk to the engineering team at all. Instead, she just makes sure that their backlog is well-defined and always up to date. Now, assuming you have a perfect product owner and a perfect engineering team, then this isn’t necessarily a catastrophic problem for the business: new stuff will still get shipped. However, the sad part of this situation is that it could be so much better.

In reality, no engineering team is perfect and no product owner is perfect. There will always be frustrations; things may take much longer to build than originally thought (or may be impossible), and some product requirements may come through half-baked. It happens. Both parties collaborating and having opportunity to discuss ideas and technical approaches, purely from a critical thinking perspective, can only make the whole project better.

Not operating in silos also contributes to everyone feeling enfranchised. If the engineers feel that they have no input in the product direction, then not only is it harder to get inspired about building new functionality, but if stories are poorly defined, or technically impossible, or if the functionality lands badly with customers, then the fingers will point and blame will be thrown.

It should be a two-way street. If we instead consider Product’s ownership of ideas and Engineering’s ownership of implementation and rephrase this as accountability instead, then we can imagine ways that both parties can jointly have more input in each other’s worlds.

Engineering don’t “do” ideas

This one can really bugs me.

There are two facets to this argument that I disagree with. The first is covered above on the effects of siloing Product and Engineering. If the engineers are not willing to engage with their product owner when they are coming up with ideas, then they’re missing out on improving them by offering their own thought and critique to the process. Product can have the accountability for those ideas, but input from smart people in any role can only improve them.

Engineering should do ideas. Here are some of the ways that your engineers can improve a product roadmap:

• Identify useful functionality with little engineering effort. It may be the case that spending a short time upgrading to the latest version of a relational database or search index could bring a whole host of cool features for free, i.e. new ways to aggregate data, the ability to do free-text search, or the ability to perform joins that were not possible previously. It may be the case that newly built functionality (e.g. a new type of visualization) can now be extended quickly and easily to roll out variations of this feature in a comparatively short space of time. Stand on the shoulders of giants.
• Suggest new technology that could improve a product. Following the open source community can highlight when an interesting new piece of technology is available to use. The engineers can suggest that bringing that piece of technology into the stack can unlock all sorts of new features that may have previously not been thought possible, or even considered at all.
• Come up with entirely new ideas! Technology aside, engineers are smart folk who use software extensively as well as building it. What have they seen in other applications that could be an avenue worth exploring in their own?

So, in short, yes: Engineering should do ideas, and collaborate with Product to work them into the roadmap. Your engineers will learn about Product’s role in making priority trade-offs which is a key entrepreneurial skill that is a benefit to anyone if learned.

Product doesn’t “do” implementation

Well, it’s true that your product owner won’t be committing code, but it shouldn’t prevent a healthy curiosity about the development process. Great product owners have a natural feeling for how complex a given feature is to build and are able to work with an engineering team to balance quick wins and long-term plays to ensure that software is shipped with a predictable cadence.

Here are some of the ways that product owners can contribute to implementation:

• Push for small increments to demo: This may be the most obvious point, since it’s a repeating topic in agile literature. However, engineers may not naturally think about how demonstrable their work is (i.e. deploying feature branches, knocking together a quick UI, preparing a data dump for display), so a product owner can act as a lever for the understandability of what his been achieved by the team. This helps the whole team communicate better to the business. How can we show that this piece of work has been successful? How can we track the usage of that change? How can you show me that the storage upgrade has been successful and worth our time?
• Offer critique in design sessions: Designing software is all about logic, and to an extent, it can usually always be abstractly represented by diagrams on whiteboards. Instead of backing away from these sessions, product owners can sit in and ask questions for the benefit of improving the group’s critical thinking. Why do we need to build that part? What sort of speed will that return at? Is this how we tackle the problem elsewhere in the system, or is this totally new functionality? Could this API be used elsewhere in our software by another team?
• Expanding their knowledge of how things are built: By spending time discussing ideas with engineers and seeing abstractly how parts of the system are constructed, a product owner increases their feel for how challenging future work is. In addition to better understanding the complexity of their own roadmap, they can look at competitors and have an intuition of how they are solving particular problems (i.e. what data are they storing and how? How often does it refresh? Is it cached or computed on the fly?). This improves the working relationship with engineers. There is a common understanding about size and difficulty, and a deeper understanding of technical debt and implementation trade-offs.

In summary

Don’t work in silos. Collaborate. Engineers: you’ve probably got more product ideas to offer than you think. Product owners: you don’t need to be scared of implementation. Be curious, explore and offer critique.

Engineers shouldn’t feel that they exist to blindly serve product owners, and product owners shouldn’t feel that they can never get involved in the process of creating software. There are ample opportunities for both roles to understand each other much more deeply and improve their own skills. After all, both roles exist in order to deliver value for a business, and that’s the North Star that they all should be pointing towards.