Most software engineering practices instantiate a philosophy or mindset. Leaders in the industry brought about the foundation of these practices in use today, from their experiences.
Having listened and read thought patterns and experiences that helped these engineers become today’s leaders, this article will highlight their opinions on engineering management concepts.
We will cover:
- Eric Schmidt on structuring teams
- Andy Hunt on team reviews and estimates
- Camille Fournier on learning/growing as an engineering manager
Eric Schmidt on structuring teams
In this interview, former CEO of Google Eric Schmidt voiced his opinion on structuring teams. We will summarize a few thoughts he shared from his experiences.
Recruiting for a team
Engineering managers maintain the motivation of individual contributors in the team. We discussed in this article how purpose and understanding of the bigger picture are vital in building and maintaining effective teams.
Eric Schmidt shared that when deciding who should join a team, the engineering manager should ensure that the engineer understands the project’s purpose.
Hire generalists
Eric says he supports the idea of recruiting generalists, quoting that “The industry overvalues experience, and undervalues strategic and intellectual flexibility.”. In software engineering, where things are changing fast, flexibility is valuable, especially in long-term projects.
Let everyone give inputs
In Japanese manufacturing culture, the Kanban system allows employees to stop the line if they see or notice the poor quality. Eric drew from that to explain how it was helpful for the teams at Google to improve and deliver quality software. If every engineer in a team is allowed to give input on the project, quality will increase.
Andy Hunt on team reviews and estimates
Andy Hunt is the co-author of Pragmatic Programmer and one of the co-authors at Agile Manifesto. During an AMA he did for the Zumvie Slack Community, he revealed a few interesting approaches of his.
Survey user, team and leadership health and happiness for metrics
Andy points out that all metrics can and will be gamed. A company might score very high on any hard, quantifiable metric, but the team might be miserable.
In Andy’s opinion, what really matters is the happiness and health of the end-users, the team themselves, and the company leaders. Surveying for these metrics will get to the heart of the matter of “how well are we doing”.
In Andy’s words: “Health includes sustainability and growth. Happiness includes the sense that these parties are accomplishing their goals to their level of satisfaction (and getting the business value the sponsors expect).”
Drop estimates and just ship code
Andy believes that estimates are basically a proxy for working and if you can deliver code daily, you don’t need estimates. In fact, multiple studies have shown that story points are not a productive use of time, as teams tend to argue on the estimated time, instead of coding right away.
Andy suggests companies focus on managing a good CI/CD environment that enables developers to push code out to the main branch multiple times per day. This will enable the team to test and demo product changes out quickly and just ship the code.
And while Andy realizes that team will get things wrong, it doesn’t matter, as the speed is there and rapid iterations based on users inputs can be done to eventually get it right.
Camille Fournier on learning/growing as an engineering manager
Camille Fournier is the author of “The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change” and in this interview, she shares the following thoughts:
One size does not fit all
We know that being an engineering manager is being a people manager. The most significant challenges aren’t technical but personal. People aren’t computers, and there is no one-trick way to deal with every kind of person.
Camille is a big believer that there is no one formula for managing people because situations change all the time.
She has admitted that she covered topics in her book that she would not practice herself at the time, but does now, due to a change in the situation.
We have also written on our own blog about the subjective nature of tech practices.
Engineering managers can always grow
We all know that the developers we manage can grow, we might even be able to pinpoint the exact areas of growth for them!
But Camille believes that engineering managers also have a lot of room for growth, and to do so, she recommends engineering managers do the following:
- Retrospectively figure out where they need to develop to be the kind of manager they want to be, either from a career perspective or interactions with people.
- Not shy away from the things that are hard for them – getting out of their comfort zone.
- Be open-minded because nobody knows everything about software engineering and management.
- Perhaps most importantly: listen to their engineers.
What do you think?
What’s your opinion on these thoughts on engineering processes? Do you agree or disagree? What are your experiences?
