Overview
When you become a manager, there are a number of books and resources available on “managing” in general, and on project management, but if you look specifically for resources on managing software developers, there are only a handful. This led Ron Lichty and Mickey Mantle to write their book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams. As our first TechKnowCon Roundtable of the year, we invited Ron to share his knowledge and best practices on what it takes to become the best software manager you can be.
About Ron
Ron started his career as a programmer, and during his 7+ years of experience as a programmer, he was awarded a few patents and had articles that were magazine cover features. Curious about managing, Ron followed the path of becoming a manager, and his experience as a manager included at larger companies like Apple, Fujitsu, and Charles Schwab, to smaller organizations like Forensic Logic and Socialtext. Ron then decided to utilize his years of experience in managing to coaching and training to help business and product and engineering leaders and managers make their software development more effective. His weekly breakfast and conversation with Mickey led them to write their book in a hope to share their knowledge to better prepare software developers to become better managers.
Managing (programmers) is hard!
As you can imagine, managing people in general is challenging, but when it comes to managing programmers specifically, things get more complicated. In his earlier research and studies in writing the book, Ron reached out to software managers and asked how much training they had received, and sadly, less than 5% had a day of management training prior to becoming a manager. On top of that, almost none of the training was specific to managing software people and teams
How is it that we expect programmers to have studied the art of programming for so long and yet how little we expect managers to have studied the art of managing.
– Ron Lichty
Continuing on the research, Ron saw a pattern that most engineering managers, including Ron himself, have had experiences with two types of managers.
- A micromanager who tells everybody what to do, and practices command and control management style
- A manager who throws you in the deep end and watches to see whether you sink or swim
Ron had initially decided not to be a micromanager, but that he would practice the latter and watch his team figure out how to swim. What he learned after he attended a few situational leadership courses was that there is also delegation and support to show his teams. As a successful leader, one must be able to delegate with purpose, and support the team however they needed when needed.
I came back (from situational leadership courses) and said to Tom (my recent college graduate hire), I’m sorry, I’m going to do more delegation and support from now on, and given the size of relief that I heard from him, I realized that was the right thing to do as his manager.
– Ron Lichty
In addition to being able to delegate and support the team as a whole, what really made a big difference for Ron to be a successful manager was to practice reflective listening. Not only did his team appreciate that, his wife appreciated Ron becoming a much better listener in all aspects of his life! That’s always a plus! Listening leads to happy employees (and a wife and a family!) which then leads to productivity and efficiency overall.
Success as a software developer vs what it takes to be a software manager
One of the most commonly asked questions Ron receives is “what is a good manager,” and “what is a good people manager, and not just a project manager?” Often enough, when Ron asks software managers that question, they come back with something about “technical prowess.” On the other hand, when you ask them what characteristics their favorite manager had in the past, technical prowess almost never comes up.
Characteristics that come up when asked about their favorite manager include not being biased, someone who walks the talk, someone who empathizes, one who coaches, who is trustworthy, and who is both a good listener and a communicator.
Yes, technical prowess is valuable when it comes to a team of developers and their ability to get things done, but the “very thing that’s made you successful in your last role would get in your way in the next role” as Ron says. The key is understanding that skills that make you a successful and effective software engineer are different than the skills and characteristics of an effective manager.
Ron believes the skills as a software developer will get in the way of someone becoming a successful software manager because as a manager, you are supposed to be welcoming interruptions and to focus on enabling others. The job becomes about what you can do for others to be their best, and not how you can become the most efficient and effective programmer.
In Ron’s experiences, he sees many companies that task managers to code, not just manage, for many reasons like budgetary, but every manager he’s seen that is required or tries to do both coding and management of a team, does at least one of the tasks poorly, and for the most part, both tasks poorly.
So what does it take to manage developers?
When managing people, it is first important to understand the types of people in the organization. Just like managing every other person in the world, every programmer is different and they are all unique, but you can look at different categories within developers.
First category is Programming Disciplines. Systems programmers vs UI / UX programmers have different mindsets, as do database programmers; they have different ways of thinking about problems and solutions. People with different mindsets and mentality will need to be managed differently. There are also the generational differences to take into account. Are they morning people or night owls? What is their communication style? Not only would you end up managing full time employees in different time zones and different personalities, most likely your team consists of employees and project based contractors, and Cowboy type programmers and Farmer type programmers. There are times when we need the “Cowboy” type programmer who charges in at the very last minute of a project to save the day, but you cannot forget the “Farmer” type of programmers who ultimately creates the software development programs over time for your team, one step at a time at a steady pace. As a manager, there is no one right way to manage everyone, but one needs to be flexible and understand the differences in people’s characteristics.
Create the right balance between rewarding teams and rewarding heroes, and you’ll have many team members willing to save the day, but few times when you need them to do so.
– Ron Lichty
Common challenges faced by software leaders
Each team and company will face different challenges when it comes to product development and leadership, but Ron has identified a few challenges that are common and important to overcome.
Recruiting
Engineering teams are always hiring, and they are probably the fastest growing team in their organization, so having the mentality of “always be recruiting” is crucial for an engineering team. In Ron’s words, “(recruiting) is where your teams come from, and there has to be a balance of technical skill set and team play.”
Software development is a team sport, and if it’s a team sport, you have to find programmers who play well inside of your teams and you have to figure out how to interview for that and recruit for that.
– Ron Lichty
When it comes to recruiting to expand your team, it is important to figure out how to evaluate the quality of someone’s ability to code, the code itself, and the results of one’s code. Your team has to work together to identify what works specifically for your team, and how to measure that in a potential candidate.
It’s important to share how you and your team evaluate candidates with your recruiter so they are on the same page. Recruiters are supposed to help you grow your team in the right direction, so they need to understand the specific characteristics and profiles your team is looking for, rather than hoping they understand what you do.
There is a ton of reading between the lines that we as managers do and look at (in recruiting) and recruiters do also, but they need to understand the part that we as managers do…so they can do a better job of (narrowing) down the vast number of resumes.
– Ron Lichty
Onboarding
Although onboarding is often seen as an HR related task, software leaders are uniquely challenged by onboarding. Onboarding is not just about the paperwork, benefits, and a whole bunch of first week tasks for a new hire to do, but it’s the process of onboarding that person to your specific team.
For a manager, onboarding means integrating people into their teams effectively and meaningfully. This includes both creating activities for new hires to do so they become part of the team, but also creating a welcoming culture in your team so that everyone welcomes the questions and the interruptions new hires will cause. It should be natural and encouraged for new hires to have questions and to bring them up to your team’s attention, so your team needs to foster the culture of welcoming interruptions and questions as part of onboarding. Read how Uber scales their remote engineering onboarding.
From Ron and Mickey’s research, it was evident that effective onboarding correlates with high performance teams, yet few teams view their onboarding practices as good and effective.
We found only 4% of teams claimed their onboarding as a best practice. This is probably the lowest hanging fruit for engineering managers to take up… bettering their onboarding practices, and making their onboarding practices to be best practices.
– Ron Lichty
As a manager, it is also important to recognize that you cannot delegate a task of a manager to a team member, because when you do that, you are pulling someone away from the very thing your team hired them to do, which is to code. You, as their manager, should be managing, and not delegating managing tasks to programmers. Recognizing the difference between delegating for efficiency and supporting the team vs delegating and offloading is an important factor a manager needs to understand.
In addition to the challenges of onboarding and recruiting, software managers need to handle the following:
- Understand software project management principles
- How to structure an organization of people that’s larger than one team into multiple teams in a most effective way
- How to motivate developers and especially how motivate them by connecting every programmer’s work to the company’s mission
Knowledge sharing
Ron also believes that it is important for a successful manager to learn from and share with other engineering managers. The very reason why Ron and Mickey used to have weekly breakfasts to share what they’ve learned in managing teams, and led them to publish a book, and the very reason why Marko started PlusPlus, is what helps improve future managers and the engineering leadership community.
Managers get benefit from asking other managers about the most important lessons they’ve made, the mistakes they’ve made, how they solved them, the surprises, both good and bad, the sources of strength and support… and mentoring from bosses and peers.
– Ron Lichty
Going back to the notion that software development is a team sport, communicating and collaboration is crucial in having a successful team. Managers must listen, but also create an environment of communication, and encourage teams to communicate to each other and to their managers and with their collaboration partners. As a manager, you have to create and foster a culture of communication at every level in the team, especially in a remote environment like we live in today. In Ron’s words, software leaders cannot over-communicate, and it’s crucially important to remember to listen as part of your communication!
To wrap up the conversation, Ron left us with a few key quotes from his book that each software leader should remember.
- If you’re a people manager, your people are far more important than anything else you’re working on. – Tim Swihart, Engineering Director
- Projects should be run like marathons. You have to set a healthy pace that can win the race and expect to sprint for the finish line. – Ed Catmull, CTO, Pixar Animation Studios
- In applications with high technical debt, estimating is nearly impossible. – Jim Highsmith, Agile Coach & Leader
- The quality of code you demand during the first week of a project is the quality of code you’ll get every week thereafter. – Joseph Kleinschmidt, CTO, Leverage Software
In conclusion, leveraging best practices in becoming a software leader involves not only leading your team to accomplish their tasks efficiently and helping them produce effective results, but one cannot ignore:
- To recognize the difference between a successful software engineer and a successful software leader
- To listen
- To communicate effectively
- To understand everyone’s differences
- To welcome and encourage interruptions and questions from your teams
- To motivate everyone by helping them see the difference they’re making – for customers, for the company, and for the world
