Discussion points from 'What is your leadership style? What works, and what doesn't?'

I'm pleased to share some take-away thoughts from July's Threads discussion.

We got together for an open discussion around leadership style, how this is borne out, and what one can do to lead and engage others..

On Wednesday 2nd August, we're at Bristol & Bath Science Park to explore the topic How do you identify, protect and exploit value within your business?'. You can rsvp via the group MeetUp page.

Here is a little of what came out of the conversation;

Be authentic. It's important that you match your management style to your own personality type.

Be ready to use different management styles, choosing the one that is most appropriate for the situation. Have a bunch of different styles ready in your kitbag and be ready to sometimes 'step up' and be tough.

Seek feedback about your management style from others, including your team. They will appreciate you asking and respect you for it. Some may ask for stronger leadership when it’s needed giving you permission to be tough when the need arises.

Don’t shy away from understanding your people at a very personal level. Think of them as components in the overall engineering machine. It's necessary to understand the workings of the components, the inner workings of your people, in order for you to manage the machine effectively.

When seeking to understand something personal about a team member, first identify what you want to know. It's then a game of conversation to get to that information. Use low pressure situations to practice this skill.

Planning work doesn't have to mean delving into the detail. Some people can be trusted to just get on with large pieces of work while keeping you in the loop, other need to be spoon fed. Know which is which and manage them accordingly.

Structure your teams in ways that mirror your project delivery. Focus on projects rather than functions.

If your management style is collegiate, make sure you set expectations with your team and check in regularly. They need to feel that while you may be managing them loosely, you are still managing them.

In almost any business, the staff at the ground level usually know where the problems lie, often with a clearer understanding than the management team. Take a regular grassroots perspective too.

When faced with conflicting engineering opinions of seemingly equal validity in subject areas you don't understand, take an evidence-based approach. Ask for simple explanations of the options and allow logic to dictate which is best.

Beware of conflicting opinions which are actually stylistic, particularly from software engineer. Point out that these things are a matter of taste rather than of right and wrong.

If you suspect a poor engineering decision has been made, it can be helpful to play the innocent; get the engineer to talk you through their rationale, approach and evidence. Often, with your support, they will recognise their own mistake or learning gap.

Engineers respond poorly to an authoritarian approach.

Continual growth hacking can become a pathological cycle, servicing a conveyor belt of seemingly must-have features to boost product adoption or win new customers. Take a regular, high level, and objective view to avoid the product becoming over-burdened and ineffectual.

Some of your engineers may already be displaying management potential, showing broader interest in how their own work fits together with that of others, and how their engineering is used by customers and to generate a commercial return. Look out for these people and grow them into future managers.

Engineers who become frustrated at the way they are managed are sometimes the ones who become passionate about showing how it should be done.

Engineers who show the potential for management may not yet recognise it in themselves, so offer them ways to discover their own aspirations and potential.

Building a team that isn't hung up on job titles builds in resourcing flexibility. It means you can let people try out  new roles but step back if they don’t take to them.

Some software engineers won't enjoy having their code checked and reviewed publicly. Others won't enjoy reviewing code. Create a culture where there has to be at least one positive comment made at review. This reinforces the good practice you are all aiming towards.

Policy and process is strongest where it is evidenced-based. Be careful not to get carried away with process or formality just for the sake of it.

Think carefully about whether and why something is needed before asking for it from your team. Doing so guards against the unnecessary and gives you the evidence and rational to sell what’s needed to the team.