The QCon New York 2023 track, "Staff+ Engineering: New Skills, New Challenges", consisted of four talks that went into decisions with buy-in, growing people, the art of Staff+, and deciding between individual contributions and leading people.
John Riviello gave a talk about the decision buy-in algorithm.
The core challenges associated with big decisions are how to decide and who will decide, Riviello said. Options are to ask the most senior engineer, do an equal democratic vote, or use the wisdom of the crowds. Research has shown that the merging of multiple independent judgments tends to lead to better decisions than individual experts, he said.
If there’s an opinion presented upfront, like an expert answer, people tend to anchor their decision toward that, Riviello said. When there’s a disagreement, people interpret it as assuming that their own estimate is right and the other must be wrong.
Riviello presented the Analytic Hierarchy Process (AHP), which consists of a goal, criteria, and alternatives. You make pairwise comparisons and scoring for each criterion between the alternatives based on how important the criteria are. AHP uses a fundamental scale for the intensity of importance.
When making a decision on what JavaScript framework to use, they used weighted criteria like community, performance, Redux compatibility, and developer productivity. They were able to evaluate three alternatives and come to a decision on what framework to use.
They did the priority scoring by having people share their pairwise comparison scores in person at the same time, not anonymously, as AHP suggested. The discussions that followed when different scores were suggested turned out to be very valuable, Riviello mentioned.
AHP clearly helped to make decisions and get buy-in, Riviello said. Using AHP helped to capture the motivation behind why a decision was made. Also, people got to learn about each other in the process. AHP does not make hard decisions less painful, Riviello mentioned.
It is important to follow the concept of "nemawashi" to build consensus openly and not force consensus, Riviello said. Don’t hide the data when sharing the final decision, he advised.
Audrey Troutt gave a talk about Growing Others to Grow Yourself.
Troutt started out as a software developer and grew to take on tech lead, manager, director, and VP roles all the way up to recently becoming a CTO. Through her own growth and many years of coaching software engineers and leaders, she has developed a generic framework for thinking about growth that translates across companies. She shared that framework, along with other coaching advice about the challenges and surprising inflection points awaiting engineers at each growth point.
Troutt mentioned that it is really hard to grow into a new role when you are still holding on to what you were really good at and really loved doing in your previous role. Holding on too close to that will only hold you back from growing into a new role, she said.
By holding on to your previous responsibilities and skills, you are also depriving the people around you of an opportunity to grow and learn to master those skills and take on those responsibilities, too, Troutt said. You can also become a bottleneck for your team this way. Troutt mentioned that at many stages of her career, she helped her team build the skills and expertise needed to do the thing that she was previously single-handedly owning, and that led to growth for her and her team.
As a tech leader, you can become a force multiplier by creating clarity and direction for your teammates and coaching and supporting them to be successful, Troutt said. Teams that approach growth this way are often the most healthy, effective, and resilient, which is great for you, great for your business, and great for our industry as a whole, Troutt concluded.
David Grizzanti gave a talk titled The Creative Act: How Staff+ Is More Art Than Science.
He started his talk by mentioning that he has never been in a role managing people. At all career decision points, he was able to stay in a technical Individual Contributor (IC) role.
Grizzanti presented an example of a parallel track for management and engineers as they grow through their careers. He also discussed the four staff+ archetypes from Will Larson’s Staff Engineer book: Tech Lead, Architect, Solver, and Right Hand. The audience mostly fell into the Tech Lead, Architect, and Solver types, but a few folks in the audience signalled they identify with multiple types. He mentioned that in all roles, everyone is a creator, even if you’re writing software. People might not feel like an artist, but they are doing creative work.
When moving into a Staff+ role, Grizzanti discussed the struggles that Staff+ engineers often have and how these are similar to challenges faced by the more traditional artist. He suggested cultivating a beginner’s mindset to keep possibilities open. Ways to do this are asking questions, detaching from expert mode, or working with a beginner.
Grizzanti suggested frequently going for a walk, preferably without distractions like your phone. If he took his phone along, he would only use it to take notes about things that came up during the walk.
One of the big Staff+ challenges is to lead without authority and get people to work with you. Co-elevation is key, Grizzanti said. Being friendly and approachable helps to build relationships. He suggested being an active listener and asking questions.
Grizzanti suggested doing peer mentoring by teaming up with colleagues who are in a similar position but with a different background or experience. It can complement your skillset and give you someone you can rubber duck with.
Michael Winslow presented Making the Decision to Be an Individual Contributor or a People Leader.
Winslow started as an individual contributor in 1998 with Basic and .Net, and ten years later, he also started leading people. For him, that was "learning, and making mistakes, in management".
When agile was introduced at the company without Scrum masters assigned, Winslow thought about how to organize the individual contributors in sprints to produce the software are a team.
When replacing his boss when he was on leave, Winslow got feedback that he was good at leading people. So he asked if he could get more management responsibility, although he felt he wasn’t ready yet to be a manager. Being personable doesn’t make you management material, Winslow said.
When Winslow became an organizational leader, his agenda filled up with meetings which left ample time for coding. As a leader, you can keep coding but leave the production code up to your teams. You can still create your own tools, status reports, bots, etc, Winslow said.
It’s ok to stay technical, but differently, once you start leading people, Winslow concluded. Every company is a tech company; try to find your passion in tech, he suggested.