Let’s ditch Software Managers!
It is said that many stereotypes contain an element of truth. In the case of coders or software developers the stereotypes have evolved over time. However, the stereotype of the antisocial, introverted or socially awkward has stuck with software developers. Just like all stereotypes, they are not accurate and have consequences.
After being in the software industry for many years, and in multiple countries, it is obvious, just like any other industry, software developers are a very diverse crowd of people. There are a wide variety of personalities, attitudes, motivations, and other human qualities among software developers. Despite this diversity, stereotypes of software developers still trespass into hiring and employment. One these trespasses is the lack of social interactions during the interview process.
When hiring software developers there is usually some form of a test before there is even an interview. Often candidates get mailed calendars where the candidate is required to self schedule the interview. These practices are convenient, however they lack any real human interaction. When a software developer candidate does finally get an interview the interviewer rarely tries to get to know who the candidates are as a person.
Software development is complex and skills are important but a candidate’s current software skills are not all they bring to your organization. New members could bring in new ways of thinking, new attitudes, new experiences from other industries, along with new energy. Finally if a software developer does get hired they are put into organizations with very different concepts of what a software developer is and how they are led.
Tech Companies often lack leadership or have extracted leadership into strange concepts that ultimately fail
Often there is no real leadership in software teams or it has been extracted into strange concepts. One concept, gaining popularity, is to attach a human resources person to do the “human” side of the interaction with team members, while the technical manager handles just that, the technical side of software projects. A similar form of this dual management system is to groom developers into two career paths.
Divided developers. One career path for “managing” and one career path that is “technical”. The “managing” career path is usually for those software developers who may not be as strong at software development as others. The “technical” paths are for developers who, someone at the company feels, may have no interest in leading other “humans”. Extracting the leadership responsibilities from the technical responsibilities never leads to a successful cohesive team.
In order for a team to be cohesive and successful the members need clear guidelines and feedback. Two people rarely can see the big picture when both are looking in completely different directions. A leader does not have to be more technically competent than the members they lead, but should be technical enough to know when someone is struggling and how to support them. Therein lies the problem: how to support team members you do not understand?
Supporting your team members requires some leadership knowledge and human understanding. If the leadership is extracted into another person, then understanding the big picture of a team member is overly complex. Some companies realize this and instead of dual career paths they try to hire a leader to support the current leadership.
Hiring a leader into a position under a leadership team who does not know how to lead is a path to the darkside. I have been in this position and wish it upon no one. The middle manager is constantly having to hold people accountable, and have the hard conversations, while the upper managers handle the raises, praises, and smiles. The position will suffer frequent burn out and turn over.
Being the only “adult” in the room is lonely. Constantly getting thrown under the bus so the upper management layer can maintain their image and friendships with employees is not fun. The middle manager will also be the target of hurt feelings from the hard conversations the middle managers were forced to have with team members. Negative feedback is not fun and delegating that responsibility onto one person is an awful way to handle it. Hiring someone to be a leadership crutch is most common when a company realizes the CTO is struggling to lead.
CTO’s who lack leadership skills are very common in the software industry. Given the tech startup model of fast growth it is easy to understand why many CTO’s came up from a developer position almost overnight. Plus over half of software developers have less than 5 years experience and most software developers are under 30. Within this fast paced growth focused industry there is almost no time for leadership training or focus.
We should accept that software projects are managed and software developers are led.
A lack of leadership knowledge is part of why many companies reach for tools in an attempt to automate the means to measure and manage software developers. Tools do not solve the problem of leadership because software developers are humans and not machines or cogs in an organization. Therefore we should accept that software projects are managed and software developers are led.
A software developer’s “manager” is really a leader. If you are a CTO you are a leader. As a leader you should focus as much, if not more, on leadership skills as you do on technical skills. People are going to make your company successful, not the software. Recognizing your weaknesses in leadership skills and accepting the challenge of self improvement are the first steps towards becoming a good leader.
Software team leadership is not any different than any other human leadership. One of the best ways to learn leadership is to be led by a great leader. If that is not possible there are coaches, mentors, meetup groups, books, and plenty of other resources available. However, one of the most important things you can do, right now, is to engage with your team.
It is a fact that humans perform better with frequent engagement. Engagement is vital to job satisfaction and employee mental health. Engagement is not micromanaging, and can be as simple as having one meaningful conversation a day with each person in your team. The goal of your conversation is to know how they are doing, not what they are doing.
Knowing how your team members are doing by itself can make a huge difference in your team. With this knowledge you may find ways to help them grow and improve their performance. At the very least a simple meaningful conversation can give your team a feeling they are important and you care.
Yet it is shocking how often a simple meaningful conversation does not happen with a software developer. From the interview process all they way through their membership in a team. I personally have been witness too many companies where the CTO almost never spoke to anyone on their teams, let alone candidates. It is a horrible trend that leads to miserable work environments.
If you are in a leadersip position be a leader and take the first steps to engage. Reach out and start having at least one meaningful conversation per day with each member of your team. Over time you will see your team happiness level rise along with productivity.
