Leadership through kindness

Leave a comment
Growth

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.

The relationship with Product

comments 2
Growth

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 team 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 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.

Dealing with different personalities

Leave a comment
Growth

Not the best mix

You get all sorts of people working in technology. Let’s start with a story.

There are two meeting rooms, side by side. The camera pans over to the first of them, on the left. The wall of the meeting room is glass, and through the pane there are three suited individuals in their mid-forties, having what looks like a very heated argument.

We are now inside the room.

“I just refuse to believe that. I know I’m right. We should go with the offer, and that’s that.”

“Nonsense. I’ve been in this industry longer and I’ve seen this go wrong. We shouldn’t proceed. You’re mad for thinking we should.”

The third man chimes in, whilst looking quite red in the face. “We should do the deal.”

“Why? You’re clearly not thinking straight.”

“We just should. Don’t question me on this!”

We are outside the room again, looking in through the window. A fist bangs the table top. Hands go in the air in anger.

We’re now outside the second meeting room, looking in through the glass. Two people are sitting in there, dressed much more casually. One person is standing at a whiteboard, drawing a series of boxes connected with arrows.

“So, we know what we need to build, but first we need to work out what framework we’re going to use. Any thoughts, guys?”

“Dunno. Could try some out I guess?”

“Yeah.”

“Probably.”

“Not sure why we’re even bothering with this project.”

The person at the whiteboard is now staring out the window, frustrated. The conversation around the table continues.

“I know right? What’s the point? Surely there’s better uses of our time.”

“Yeah. Remember that project we did last year together? What a waste of CPU cycles. I doubt anyone even uses it.”

“Hah, exactly. These people know nothing about building software, do they?”

We are now back outside both rooms. Two meetings are going nowhere. Fade to black.

Working with different people

Technology companies, like most companies, have a wide array of different people and personalities working there. International offices are staffed with people from all genders and cultures: salespeople, engineers, data scientists, executives, researchers – you name it – all of them come together for this wonderful thing called work. Sometimes teams and meetings can be an eclectic mix of people who get along swimmingly and collaborate well. On other occasions they can be frustrating, one-sided and fruitless.

You’ll need to collaborate, debate and make decisions with all sorts of people throughout your career. Yet, despite our differences, the value you gain from interacting with your colleagues need not be purely up to chance. You can consciously adapt your style to improve your individual conversations and even intentionally ameliorate differences in a whole group.

I’d say that there are two levels that you can operate at in order to work well with your colleagues:

  1. Understanding the personality types of others. This allows you to have better quality interactions where you can engage on the right wavelength with people. You can appeal to a fast-paced directive mind with one approach, but you can equally pitch something in a differing style to a deeply analytical person so that it lands right with them.
  2. Playing a personality role in order to get the best out of a situation. Knowing the balance of a team, group, or selection of people in a meeting, you can put aside your natural personality (which may be, for example, analytical) and play a different role to improve discussion and decision (e.g. a brash and directive viewpoint). Your natural way of being describes you, yet it doesn’t define how you should always be.

Understanding personality types

Techniques

There are a variety of methods for categorizing personalities. You may be familiar with the Myers-Briggs test, which after answering a number of questions, assigns you a strange-sounding acronym such as ISFP, ISFJ and INTJ; the latter being mine, for the curious reader.

Additionally, you may have been subject to some training at your company that used the Insights Discovery toolkit, which is based on the psychological theory of Carl Jung. Again, after answering some questions, a written report is generated that assigns you a color on personality wheel that represents the predominant characteristics that you exhibit. Typically this exercise is followed by training on how to work with people’s personality traits.

Here’s what the Insights Discovery wheel looks like. Where do you think you naturally reside?

We did the Insights Discovery training at work and although I approached it with skepticism, the outcome was very positive. I was able to explore traits that make me who I am, but more importantly, to become much more sensitive to others that have divergent personalities. If you’re offered any kind of related training then approach it with an open mind: it stimulated some really interesting discussion between us. Just don’t assume red means angry. That’s not true.

The basics

But, I digress. Less chat about psychological models. Let’s keep it simple. Some people are loud, some are quiet, some are rambunctious, others are shy, some are deeply cerebral with their decisions, and some trust their gut instinct instantly.

Regardless of how you categorize your own personality and those that you work with, whether through a model like the above or just your own gut feeling, one thing is fairly clear: when working closely with others, you need to be tuned into everyone’s differences in order to have high quality interactions. Not everyone you work with will be the same as you, and it’s your responsibility to respect that and make others feel considered.

Sometimes you’ll clash with people. You have to understand that the way that you view the world and reason about it could be the opposite of how they do, but, importantly, both of your viewpoints and logical processes are just as valid as each other. The first step in being a great collaborator is using your emotional intelligence to be aware of these differences, and then focus on communicating in a way that resonates well with others. Ask questions. Consider. Probe if you sense that you’re causing discomfort. Speak out if you’re uncomfortable yourself.

Here are some examples of how people may be different to you.

  • Quiet doesn’t mean indecisive: The quiet ones in meetings may just be deeply analytical about decisions. They prefer to go do their research and come to a reasoned conclusion later. It doesn’t mean they are indecisive. Respect that and let them do so. They’ll probably come back with a more balanced and well-researched opinion than yours! How about we go and do some research and get back together tomorrow to discuss what we’ve found?
  • Loud doesn’t mean right: A very confident and loud personality may come across as the most persuasive, but remember that there are other opinions in the room. Allow space for others to speak by asking questions directly to them for the benefit of the room. A good point. I can tell that Bob’s been thinking a lot while you were speaking. What’s your current thoughts, Bob?
  • Zooming out and zooming in: Depending on their role, some people will be detail-oriented while others prefer to take (excuse the cliché) the helicopter view. Both levels of abstraction are necessary, but allow each personality to express their feelings. Tie the opinions together into a wider narrative that considers the views of all. I understand that we need to ship this new product yesterday, but there are a lot of considerations that the group has raised. How can we drill into all of the detail and then come back to make a decision at the end of the week?
  • Consensus: Some personalities are deeply uncomfortable at not getting consensus on decisions, whereas others couldn’t care less. Ask questions about how the group can arrive on the same page, and try to get those creating discord to understand that they need to persuade others, too. I totally agree with your position, but we all need to get there together. How can we do this without causing a rift with the other teams? What could potentially go wrong?

I’m sure there are many more examples, but group dynamics are tough. If you can develop a sensitivity to the personalities of others and understand what motivates them, you can begin to develop a feel for how to pitch controversial ideas or make difficult decisions while making them feel considered and respected.

Playing a role in meetings

As our introductory story showed, particular mixtures of people don’t work so well, and as a result some meetings can lack the balance required to move the discussion in the direction of a decision or action. So we’ll move on to a skill that is more advanced.

Here’s the question: regardless of your own personality type, are you able to play differing personality roles for the benefit of a discussion or debate? This requires a great deal of self-awareness about your default mode of operation (i.e. are you a snap decision maker, an analytical thinker, predominantly a listener or an orator?) and the ability to notice when a discussion lacks balance and to slot a counterweight into the missing gaps. It also requires a great deal of confidence to represent or debate viewpoints that you are naturally less comfortable with.

It can be useful to think what the ideal outcome of a particular meeting is. Are you trying to make a decision on something? Is it a chance to critique an idea? Are you trying to come up with new ideas? The purpose of the meeting acts as the North Star that you are all aiming towards. With that in mind, what is the balance of people in the room like and how likely are they to work together to get there effectively?

There are a number of techniques you can use to do this:

  • Adopt an opposite stance for balance: If you spot that the conversation is getting stuck because people are being too analytical and not getting to a decision, or that the room is at risk of argument or a decision being made that is too rash, can you adopt an opposite position in order to pull the room towards the desired outcome? You can anchor a frantic room or invigorate a lethargic one. Can we run through what a different approach would look like to this? What if we did this in the backend instead? What would happen if we used our own infrastructure for this, rather than going straight into the cloud?
  • Adopt a controversial stance to interrupt thinking patterns: If you feel that the debate is one-sided or at risk of not exploring all avenues before reaching a decision, can you be controversial for the sake of inspiring new discussion? What if we didn’t do this at all? Is this actually a bit of a silly idea? Is this really worth our time and money?
  • Pretend you know less than you do to probe deeper: This technique is useful to get people to explain their thinking further for the purpose of critique and, often more importantly, if you spot that others in the room are not following but may be too embarrassed to ask, you can confidently feign lack of knowledge to bring others up to speed. I don’t quite follow that last step; can you elaborate? Why doesn’t that framework support that feature? Why wouldn’t our current system cope under that load? What do you mean by index
  • Pretend you know more than you do in order to be proved wrong: If you feel that a given solution is worryingly complex, can you falsely posit that it’s actually much easier in order to force more explanation? Surely it’s just doing this, then that, right? Isn’t there open source software that just does this? Why isn’t this as easy as just adding this field to the database?

I’m sure that there are other techniques that can be equally useful. To use another cliché (that’s two now, sorry), careful playing of different roles can turn you from a musician in the orchestra to the conductor, steering collaboration in the direction of the greater good. It’s also fun.

In summary

We’re all different, and sometimes that makes for wonderful collaboration, but it also can result in conflict. As well as developing the emotional sensitivity to be able to work well with others by appealing to their own needs, you can work towards playing a role other than your natural one in order make collaboration faster, better and more interesting.