A friend (non technical) recently asked me how I lead my dev team, he had led product and marketing before, so I have attempted to focus on the differences, that said good team leadership has commonality with all disciplines.
I currently have three software engineers, one IT/Dev OPs and one product designer (3 female and 3 male). In the past I have led 23 teams. I will use this blog for my team to hold me to account 🙂
No Surprises
Being accountable for “no surprises” is the core. Where ever possible you should be accountable for all of the people that you work with, people should not be surprised by what you say, because you have already asked their opinion, maybe even evolved your thinking and they can see the process by which you went through to reach a decision.
It means more communication and more interaction with your people. It means you can be vulnerable. It means stepping outside of your “assigned” responsibility and forming relationships with all parts of your organization, and other organizations. Its about being connected, its about being a leader and a follower. It shows that people understand you and your core principles. That you can be consistent and when you adapt they can see that to.
There are not things left unsaid, you are not passive aggressive or have control issues.
Being a Leader of context
The role you take on should change depending on the context. Sometimes you are the coach, sometimes the mentor, sometimes the friend, sometimes a psychologist, sometimes the engineer, sometimes the product owner, sometimes the user advocate, sometimes the engineer advocate, sometimes the leadership context, sometimes the inspirer, sometimes the critic.. There are different leadership styles and yours should adapt. In 2003, prior to my MBA this book really helped me step up my game The New Leaders: Transforming The Art Of Leadership Into The Science Of Results
You are the right person at the right time
Different places/ways to work
People are generally smarter/productive longer, when they can have different types of environments to work in and have multiple ways to express themselves. Have multiple places that engineer can work in. When I recruited my current team, I got the organization on board with the following:
- Give the engineer a laptop
- Have somewhere comfortable to work e.g. sofa, kitchen
- Have somewhere serious/quiet with extra screen
- Have somewhere they can stand up and code
- Have somewhere outside if possible, natural light/fresh air is a great refresher
- Make it possible to work remotely
- That there are white boards for people to express, figure out a problem.
This is a good book if you want to really consider your culture and the way you work. The Best Place to Work: The Art and Science of Creating an Extraordinary Workplace. Without doubt you should ask each team member what helps them concentrate, what distracts them, what they need to stay in the zone. The obvious big one for many is a good set of headphones. Do not underestimate the quality of a good display also, anything at the quality of a Retina can reduce eye tiredness.
Different physical environments can refresh you, help you think bigger or focus. Be flexible.
Leave chunks of time to code
Engineers are generally more efficient if given chunks of time to code. Thus have your meetings meetings near mornings or lunchtime. To give several hours of interrupted research/code time.
- Get engineers to block out their time on their calendars, so product/founders can book time when needed
- Use an IM system to ask questions such as Slack or Skype during those chunks of time and do not expect a quick response
Developers need chunks of time to be left alone to get on and focus
Being a good human being
This means understanding each others needs and wants. Expectations both from the lead and engineer should not be hidden, things should not be left unsaid. Sometimes we need processing time, to check in destructive emotion, but you should still tell that person how they made you feel. You should also be kind but not nice.
Both people should be able to be vulnerable with each other and trust each other. You both need to avoid surprises. This is done through good communication, which is not common and takes effort. This needs time together.
- Feedback in the moment, always ask permission before giving feedback and make it about the behaviour you saw. Do not assume intent, in fact assume positive intent. Give positive and negative feedback. Understand how each member likes to receive feedback. This is my slide deck from teaching my teams about feedback.
- Weekly One to One checkins 10-30 mins, any fire issues? any smoking issues?
- Monthly sit down at least one hour. I have a list of questions to always go through, which we agree when we start together.
- Allow others to lead, giving opportunities to members of your team to lead on a project/task whatever you do not need to be the boss of everything.
Question set for monthlyFirst conversation should be to agree the questions, here is a starting set. They should based around the culture we wish to create and how we want to treat our people
- How are you feeling? Any hot issues we should talk about?
- How are you contributing to the company and your team?
- Are you a Team player? How are you involving others in your process?
- How are you growing/learning? Are we are helping your reach potential? Do you have mastery?
- What are your Technical Capabilities here? Where do you feel competent?
- How are you helping the company grow and evolve?
- Are you Hungry? How productive are you? Are you taking inspired action?
- Do you have a friend here?
- Do you have a mentor or coach in the company? Are you coaching others?
- Do you want stay with the team and the company?
- What can can we do better as an employer/me as your leader/CEO?
- Do you feel you have Autonomy? Are there things stopping you doing your job?
- Do you feel you have Purpose? Do you understand what we are building and why?
- Are you contributing to the wider community? What can we do to help?
One to one, face to face is the highest bandwidth of communication
Your processes and system should evolve.
The way you do things should be Agile (as originally intended i.e. flexible and evolve NOT rules). Agree a workflow together from product to engineer. It should change and evolve to be right for the context.
- When starting with a team, I will audit all current systems and ask for each members views privately on each tool/system/process, to ensure the less confident or shy people get their say
- I will then have a team meeting to review what we need and what we like
- Any team wide system change should involve all parties
- Deadlines should have engineer involvement and not be dictated downwards
For example in my latest team we discussed the tools we wanted and we decided to use
- Slack for IM
- BaseCamp for idealization and research
- Github for product/features/user stories and code/issue management – The way we used tags evolved several times.
Freedom to solve the actual problem
Sometimes Product/founders/Engineering leads may try to solve the problem in their way i.e. micromanage. Giving the engineer the “code monkey” role of just coding to a very prescribed way i.e. an exacting feature. Giving no space, to actually problem solve can be very limiting and create an environment where creativity and innovation are stifled i.e. the evil called micromanagement. Most humans do not like their freedom taken from them. So find the the right balance between the organizations’ needs and the employees. That said some people like more structure, context matters.
- Give space for engineers to solve the problem in their way. If you are already using Agile then you may evolve the story a couple times as users respond to the work.
- Within the user stories/feature requirements do not limit. Ensure you actual describe the problem you want solve, suggestion ideas/solutions but where possible do not dictate
- Involve the team in talking about the features and discussing possible approaches, but the actual engineer who takes the feature gets to decide
- Engineers should have some understanding of the customers. Ensure your engineers meet customers, and spend time with your Customer success/relations people.
- Keep the engineer accountable for the response by users. Thus have good monitoring software and have a culture when engineer go back to check the real world implications of their work.
Micro Management is the evil of leadership, it kills creativity, innovation, trust, and growth. It can appear both in a manager and in the processes you impose on your people
A culture of science
Scientists experiment many times and fail many times and one day they get it right. Encourage a culture of learning from mistakes not teasing/persecution which means encouraging experimentation and forgiveness.
- Discussion should be based on logic in reference to code
- Create an environment where people can I say “I do not know.. but here is an idea/feeling/instinct”
- Call people out if they tease others about their failures or use it to argue they case in a discussion
- Careful to not let irrelevant aspects enter into the discussion such as gender, race, age or sexuality. I say careful because humour can involve these but they should not sway discussions and the receiving of the humour should not be hurt.
Experimentation and failure should be Ok, team members should not “haze” each other. Leadership need to be able to move on
To build a team well, needs reflection and the teams involvement
The team needs time to connect as a team and evolve together as a team. We have a book club where we talk about the teams performance in terms not related to code. How good are we at communicating:
- Giving/receiving feedback
- How do we react to others ideas?
- Who do we go to help us through problems?
- Who pair code with more often
- How much do we know about each others strengths and weaknesses?
- How vulnerable can we be with each other?
We used The Five Dysfunctions of a Team to kick start this conversation. Every couple months we take time to talk about how a team we are in terms of communication. You need to invest in the actually team to have a team..
You need time for the team to talk about the team, spot weaknesses and evolve
Ask your people how you are doing
“How am I doing?” should not be a hard question for you. Ask it informally in your one to one monthlies and formally at least every 3 months. The no surprise rule should be for all. It should be 360 your leaders, peers and your people. Find out if people get what they want and what they need from you, in terms of communication, conflict/challenge, advice and performance.
You learn faster by other people telling you what you are doing right and wrong
Collaborating with your leader
Hopefully you chose your boss carefully when you were recruited into the organization.. but things evolve, so maybe that perfect person you went to work for, moved on. I have found the best leaders are those who keeping growing i.e. they read about how to be a better leader, they can be vulnerable with you and you can talk openly. When you make mistake your instinct is to tell your boss, when one of your team performs really well you never feel the need to take credit and generally you have no fear of your boss talking to your team. If you do find the above hard, understand why.
- Never underestimate the amount of time you will need for your leader
- Know each others strengths, weaknesses and blind spots
- Find those things you really enjoy about each other
- Find those things that you find difficult and talk about them
- Build strong relationships throughout the organization, ensure all find you approachable
Success in any organization is about working together and helping each other evolve
Adding to the team
Whilst you as the lead will drive this process, you should involve the team in the process. You should ensure everyone is trained and good at the interview process. This may mean mock interviews, where your team interview you. Its worth noting that you do not want more clones, you need different types of people, skillsets, who sometimes will clash, but have the communication skills and reasoning capacity to grow from each other.
- Be clear what the team is missing and what you need
- Agree on what you are looking for both terms of technical and personality
- Ensure the all those that are interviewing try out their questions, again no surprises
- Have space for something social
- The best interviews are like a great chat amongst friends about something technical
- Personally I hire on communications skills, problem solving skills, learning capability and then current technical skills
- I often look for potential as much as current craft capabilities
- I do not hire more of me, I want diversity
- If employing someone with less experience, be clear what the areas are and put in place a training program to fill those gaps.
I look for growth potential, hunger, curiosity, pro-active, problem solving capability, how they will add value to the team and how they will help the team evolve. Then I start start to consider technical experience.
Software engineers are great problem solvers
Sometimes we box people into a role. Humans are so much more than their job title and job description. Most people are capable of applying their skills in other domains. You have a problem, why not ask a software engineer?
I will keep adding to this blog as I learn.
Eric Brooke's Blog 
Very nice blog yyou have here
LikeLike