I wanted to follow on from the previous Thank God it’s Friday at TLR where I presented about my experience in a leadership position managing a team of 17 people, so, I’ll start at the beginning!

Born in 1984, I started programming software when I was 13 years old, I was that typical computer geek. I went to university and after became a technical lead and then eventually an architect/product owner. I ended up in a leadership role without consciously deciding to leave a technical role in the first place, it just kind of happened.  I joined KIT Digital in 2012 as a lead engineer. However, after KIT Digital went bankrupt and rebranded as Piksel, I had earned myself enough of a reputation to be asked to take ownership of Fuse Publisher (a cloud product) as a technical architect. And this is where my journey begins in the leadership role I held for 5 years.

(Ever wondered how digital media gets from the camera to the postproduction studio into the cloud? Check out my slides at the end of this blog post to learn a bit more about what’s involved in the process.)

The things I learned

Responsibility. You are being paid to be responsible for when things go wrong and fixing it. When things go right your responsibility is to deflect that to the team. Leadership decisions (if to promote somebody for example) were a lot more difficult than technical decisions. I had to try and reduce the number of decisions I had to make to avoid decision fatigue, so I reduced the number of technical decisions I had to make and focus on the leadership decisions. 

Freedom. Really be clear about the support you need before you enter into a serious leadership role. Because you’re going to need freedom in order to be able to bear the responsibility.

Interpersonal management. At the beginning of the project, I wanted to be involved in everything that was happening. I wanted to have the final say on all decision making and I wanted to implement the first iterations of a feature. However, this was motivated by insecurity – what if the company management asked a question that I didn’t know the answer to? How would that make me look? How would that affect my reputation I had worked so hard to build? It was difficult to trust others to do a good job. This was a major problem…

I knew I needed to find another solution. One that gave control and responsibility to the team. One that relieved me from all this decision fatigue, so I developed the following 5 step leadership plan;

5-Step Leadership plan:

Step 1. Delegate: Delegate leadership. They will be responsible for the development, architecture and quality of a subcomponent of a system. They will design the implementation of a feature and they will perform code reviews. 

Step 2. Quid Pro Quo: When you’re asking someone to do something, it has to be a 2-way relationship, like a contract. I am giving you responsibility, but I expect good quality work and continuous improvement. 

Step 3. Identify Outcomes: Difficult. I’m going to keep control of my accountability by identifying outcomes. I would find ways to measure success (problems found during demos, missed requirements, rejected features and so on). It is their responsibility to ensure that they understand the requirements from me before delivering them. 

Step 4. Measure: I will measure these at a regular cadence to ensure we’re on the right track. The measurements will form part of your performance evaluation.

Step 5. Reflect and Discuss: We will regularly (every 2 to 4 weeks) discuss how things are going, and I will give feedback and guidance. 

This image has an empty alt attribute; its file name is Paul-blog.2-1024x768.jpg

There was also another problem. If I’m subdividing the platform into leadership areas with owners, how do I ensure that people don’t become overly specialised in a single area. This is what’s known as the bus problem; how many developers have to be hit by a bus in order for the project to fail? As no one else knows anything about each others areas to then take the project forward. So I created a chart (see slides) to identify metrics from a persons area of specialism. Once this was identified, share the knowledge with those who are weaker in these certain areas. Shared knowledge is key!

Team Success

Teams can sometimes be difficult to manage and especially within the technical field there is a certain team structure that I will try to explain. It is like a motorbike analogy, to build a motorbike you do this in stages, bit by bit, until you finally have a working motorbike (the final product). In the technical world, a sprint is a period of time, typically 2 weeks, with a set of cards (different parts of the motorbike) to be delivered within that time frame. I need certain features to be delivered, and the team commits to delivering these sprints within a certain amount of time. At the end, we’ll have a demo and review what was actually delivered. Assigning a score to every piece of work (the motorbike parts) to see if they underdelivered or over-delivered. The main thing I learned about team-work is that you can apply the same steps taken with the 5 step leadership plan (above)! Basically, team behaviours are learned through trial, error, and retrospection.

For me, leadership is about a balance between delegating responsibility whilst maintaining accountability, giving space to grow and develop whilst at the same time providing boundaries, and having regular contact and evaluating performance continuously.

Conflict resolution formed a big part along my leadership journey as I encountered many conflicts along the way. People will sometimes seek conflict to gain control and be disobedient to find your limits. Sometimes, people will try to control you or otherwise influence you for their own benefit. I learned they just want engagement (children and pets do this for attention) and there is are some key pointers to resolve these conflicts in what’s know as ‘non-violent communication’.

Non-Violent communication:

  • You cannot act passively in situations of conflict
  • These problems do not go away and usually escalate very quickly
  • Anger and irritation are wastes of energy, and only give them what they want
  • Strong leaders observe, express their feelings, give their needs, then make requests

5 Years Later, I grew the product team from 5 members of staff to 17 staff members and kept a 92% staff retention until I left the company, which I’m very proud of. In the end, we did 3 iterations of the product released to market and sold it into some of the largest names in broadcast and media (Discovery Channel / AC Milan / Liberty Global). I made a huge number of mistakes, got burned out, and learned a lot along the way. Currently, I am based in Malaga and I am part of the TLR Alameda office family, which is the perfect place to base myself as I work remotely.

I hope some of you guys can take away some of my lessons learned and maybe apply it to your roles working within a company or as a freelancer, to ultimately create a successful team and end product!  

Link to my presentation slides found here: https://docs.google.com/presentation/d/1ozdnkXRtnOgnn3yR8AdDpJxLZIr9YwiLRaAXvWBSXKg/edit#slide=id.p

Paul Wilson at The Living Room Coworking

About Paul:

Paul has 13 years of software engineering industry experience across all areas of delivery, from Product Ownership and Architecture to Development and Operations. He has worked with CTO and Director level stakeholders to define, architect and deliver software projects across two major industries (media and telecommunications) and seen traction in some of the largest brands in the world (including BSkyB, Vodafone, Liberty Global, Discovery Communications, AC Milan). Find more information here about Paul and his software consultancy.