Technical Leadership in Software Companies

Recently I was invited as a speaker in one of Ireland’s largest technology event, Tech Connect, held in Dublin on the 25th of May 2016.

It is a gathering of 3000+ key decision makers from the Irish and international tech sector and provides an unique forum for technology companies, start-ups and investors.

I spoke on the topic of “Technical Leadership in Software Companies”. The talk was well received from the audience and gave them something to think and act upon.

I spoke about how Software developers have to be managed differently than people in other industries because their work is intellectual in nature. I took the audience through ways in which technical leadership can inspire software developers to achieve the extraordinary.

Here is a summary of some of the key points from the talk, in easy to read bullet point format.

My talk was based on first-hand experience: First as an employee working under others and then in technical leadership roles helping and motivating teams of developers…and of course still coding when possible.

Understanding the Psyche of a developer…

• Before we try to inspire developers, it is important to understand the psyche of a developer - the men and women behind the face. What do they really want?
• What do software developers like above all? Solving problems. Right since their childhood, they got into programming because they liked to solve problems.
• They had the freedom to choose the problems they liked to solve, how they solved it and when they solved it.
• The feeling of creating something out of nothing. All developers want is to have that feeling everyday. Feel God like for a short time.
• It was never for the money. The passion was driven by creativity, learning, standards of excellence we set for ourselves.
• What mattered at the end of the day was the Pride. The pride of honing the craft.

Conventional management…

• Conventional management styles don’t care about the psyche of a developer. They don’t care possibly because of two reasons - 1) They really don’t care or 2) They don’t know how to care.
• There is one thing they certainly do care about - Bottom line. Decisions are based on whether they impact the bottom line in a positive way or not.
• Driven by clear targets, for e.g. sales target of 5 million per year, reduce expenditure by 25% etc. This is contrary to how software developer thinks where exploration of ideas is the key.
• Most people in these management positions are of certain traits - Charismatic, outspoken, extrovert etc. Extremely positive traits, but in most cases, these traits are exactly the opposite of a typical software developer.
• What? That’s a frequently used word in various contexts.
  • What can I do to get more out of the team?
  • What can I do to reduce wastage of resources?
  • What can I do to increase profits?
• It is no longer about things that matter to a developer.
  • It is no longer about Code quality
  • It is no longer about Maintainability
  • It is no longer about excellence towards the craft
• It is all about…
  • Customer is greater than all
• And it is no longer about the programmers or their craft…..
  • A developer’s pride gets taken away
  • They feel disconnected with the aims of conventional management

Decision-Consequence gap

• Do you really think managers don’t like quality? Do you really think customers don’t like quality? No, they don’t want low quality products. Then why is it acceptable in our industry to consistently deliver low quality products? Why are quick fixes, workaround encouraged by managers? The reason it is happening is because of something called : Decision-Consequence gap.
• Decision-Consequence gap - It’s when the decision makers do not have to face the direct consequences of their decisions. So, when a manager instructs an employee to go with a workaround that results in bad code, he/she doesn’t have to face direct consequence because he doesn’t work on the code. Companies should always try to reduce this gap so that correct decisions are made. Its the same reason why giving advice to others is easy than to oneself.

The Golden Circle…

• How do we fix things in the corporate world so that both developer’s needs and the customer/manager’s needs are met? How can we mange to keep everyone happy?
• The answer lies in Simon Senek’s Golden Circle.

• The basic principle to be understood is that people are never motivated to work for others, but they will be highly motivated to work for themselves, for their own interests.
• The WHATs don’t motivate people because you are working from the outside-in. That’s conventional management approach to leading teams.
• Developers will not get motivated by financial goals of the company because it serves someone else’s dream.
• For people to be motivated, they need inspiration from within - and that comes from WHYs and HOWs.
• The biggest success story of this model in the software world is in the FOSS - Free and Open Source Software.
  • How do open-source projects become successful where there are no managers, Scrum masters etc?
  • Why do developers work on open-source projects for free?
• The answer lies in the fact that open-source projects take care of the developer’s WHYs and the HOWs.
• The WHYs and HOWs are based on and feed the developer’s psyche. They work from the inside-out. They make sure that developers have a feeling of success everyday.

Improve your development process…

• Feed as much as the WHYs and the HOWs that are meaningful for the developer.
• Convert your business goals (the WHATs) to HOWs and WHYs.
• Foster a culture where
  • Excellence is valued
  • Creativity is encouraged
  • Shortcuts and workaround are not entertained
  • Quality is the primary goal, not deadlines
  • In short, always lead from the inside-out
• Some of you based on conventional management styles may feel you might miss the deadlines or have no control over the development, but you couldn’t be more wrong.
  • Imagine a highway, nice wide road with fast lanes. Would you ever ask someone to take a shortcut full of obstacles? I guess not.
  • The highway may be the longer route, but it gets to your destination faster.
• The highway analogy can be applied to software development as well. In the short-term the highway might not look like a good option, but things that are developed properly and with consideration for quality always make up for time in the long run.

Technical Leadership..Have high quality people lead your teams…

• Role models for developers are people similar to them. A role model for developer is more likely to be technical person rather than a business person.
• That is one important reason to have technical role models lead development teams and not managers with no inclination for technical stuff.
• Have a leader who leads by example, not by authority. You need to have technical leadership, not managers.
• Let it be the case where people work with a leader not because they have to, but because they want to.
• Remember that you will always attract others like you already are, not people like you want.

No competition within teams…

• Don’t foster a culture of competition within your team, it only inhibits forming of a gelled team.
• When people have to compete with each other, they will work for personal agenda, not for the common goal of your team or company.
• Get rid of things such as appraisals, awards based on individual performance.

Treat developers as responsible adults…

• This is inspired by changes made by Netflix to their policies. It is time we treat developers as responsible adults. In most companies, your most valuable and knowledge resources are working at the bottom of the hierarchy with everyone making them dance to their tunes.
• Netflix doesn’t care about where employees work, how they work, what time they work as long as high performance is maintained. They even have unlimited holidays that can be taken without notice and approval! Hubspot recently adopted a similar style of operation. Hopefully we will see this widespread in a couple of years time.

Real deadlines…

• Have reasonable deadlines. Have real deadlines.
• Don’t override the estimates given by your developers. They are the best placed to give correct estimates. If you do, you bring down the morale because now you are forcing them to work in ways that they don’t want to. Remember the highway analogy from above.

Hopefully that gave you something to think about! I hope good things come out of it.

Remember that developers work because of passion, they love to solve problems and like the creativity and the thought process that comes with it.

Always feed the basic psyche of a developer to achieve business goals. Give them a reason to pursue their passion and see the magic happen! Cultivate technical leadership and care about the craft of programming.