This fall ESPN published an article about Steelers QB Ben Roethlisberger’s high school stint as a Wide Receiver and how it benefited him as he moved forward in his career.
Before he set records as a quarterback his senior year, before he became the Pittsburgh Steelers' top draft pick out of Miami (Ohio), and before he won two Super Bowl rings as one of the NFL’s best signal-callers, Roethlisberger spent his junior year of high school playing wide receiver.
It gave Roethlisberger a deeper understanding of the game he took with him the rest of his career – something he found again last season as he stood on the sideline following a season-ending elbow injury in Week 2.
“[Findlay] coach [Cliff Hite] was always like, ‘It benefited you as a senior playing quarterback from playing wide receiver your junior year,'” Roethlisberger said. “I never understood it at the time, but I think it does to a certain extent because you can see the other side of it.
The article highlights 2 advantages of the previous receiver experience for Roethlisberger.
Roethlisberger’s stint as a receiver enables him to be clear with his instructions. Nothing gets lost in translation when the quarterback can give his directives in a way the receiver clearly understands.
“He can talk our language,” said Ryan Switzer, who played with Roethlisberger in Pittsburgh for two seasons. “He can talk leverage, he can talk technique, he can talk lean and press, he can talk all these things, which makes the communication a lot more fluid between us and him. … He’s able to communicate really well, which helps translate to being on the same page more often on the field.”
The carryover from one position to another goes beyond communication. Iriti sees it in the way Roethlisberger eludes the pass rush and finds a receiver on a broken play.
“It’s like he knows where he’s at, and he knows where you’re trying to go, so he can wait until that last second, just make that little move,” Iriti said. “It’s not fast, it’s not quick, but it’s like it’s premeditated that he knows where you’re going. So it makes him seem more agile and quick than he actually is. He’s not a blazing-fast guy, but instinctively he’s really smart.”
Playing a position that he later had to collaborate with allowed Roethlisberger to communicate with his teammates better and make better adjustments when things went wrong and he needed to understand or anticipate his teammates reactions.
Reading Roethlisberger’s stories reminded me of some of my own practices as a high school basketball player. Our coaches would force us to switch positions around when practicing plays. The theory was that you didn’t really know a play until you could execute on every position’s part of it. As a tall but gawky and uncoordinated high schooler, I was never likely to move away from my forward position to become a full time point guard, but the exercise was useful both for the reasons called out above, as well as the flexibility it gave us to play different lineups for shorter stretches during a game. If we had problems with injuries or foul trouble, we could get away with playing people at a different position for some stretch of time, or play different groupings of players that let us take advantage of matchups.
So what does any of this have to do with the purported topic of this blog, productive software teams? It turns out that modern software teams have a lot in common with sports teams. They’re a collection of individuals with different skillsets who take on different roles to work together towards a set of goals over time. Our work has less black and white scorekeeping, and the lines between “games” are a lot blurrier, but there is a lot we can learn from the world of sports.
The lessons from my high school basketball days have stuck with me as I’ve progressed through my software career. I find that I collaborate better with my teammates when I have some sense of what it is like to do their job. A benefit of spending the last 7 years in startups was the opportunity to wear a lot of different hats on a short term basis. I’ve always done an mix of front end and backend development. I once was assigned the role of being primary test engineer for a major release while our normal QA lead was taking a few weeks off out of the country. As my career advanced I got to get more involved with the product management side of things, collaborating closely with PMs to help shape how products got built. I even spent a memorable and painful couple months as my team’s primary designer after a round of layoffs. As both an individual contributor and an engineering manager, these experiences have helped me work well with a variety of different people, identify times when teammates in different roles were talking past each other, and plug gaps when the need arose. It also gives me empathy for people who are facing the tough parts of their job, and a level of humility when approaching discussions that comes from knowing there are always many perspectives on a particular problem or process.
Unlike sports, we don’t usually consciously “practice” in software development. That may be a mistake, but given it is the world we live in, how do we actually develop this type of experience? I’ve found 3 primary things helpful: doing the work, talking with people experienced in the role, and reading about the role. This isn’t that different than the learning process if you actually wanted to pursue a particular role, the time commitment is just lower.
If you have the ability to just do a piece of a project in a different role or fill in for someone for a short time, that can be the easiest way to quickly develop some intuition about a role. For some role combos that’s pretty easy. A software engineer can always take a shot at doing more of a test engineer role. Look at another developer’s code and think about how you would test it. You probably won’t be doing what a full time test engineer would do, but just getting into the mindset can be helpful. It can feel harder to cover other roles - how would you “try out” being an engineering manager as a junior engineer? But you might be able to ask the person in that role if there’s some part of their job you can help them with. Then you get to try out a piece of the role and potentially get some guidance to go with it.
One problem with “just doing it” is that when we first try a new skill or role, we don’t know what we don’t know. It’s easy to perform a parody of the role if we don’t get any meaningful feedback on our performance. So it is helpful to talk with somebody who is experienced in the role, ideally an expert. They can give you feedback on your attempts or just tell you about what they do and how they see the world. The ability to listen well and ask good questions can take you far here.
Finally, there are a lot of written resources out there for learning about different roles. To help work with people in a certain role it can help to read some of the “classic” essays or books about a role. A learning-focused person in the role will be able to make recommendations, but if you don’t have a good resource there you can get a similar effect with careful googling for “best books for product managers” or similar. Some books I’ve found helpful for understanding different roles include Inspired for product managers, The Manager’s Path for engineering managers, and The Design of Everyday Things for product designers.
For pretty much every piece of career advice out there, there are pathological variations that should be avoided. Almost everything can be taken too far or stripped of context to the point where it becomes harmful. I’ve seen at least one common way that the pursuit of understanding our teammates roles can go wrong. That is simple ego; it can be tempting to believe that because we’ve walked a mile in somebody’s shoes we’re the experts and our voices should now hold heavy weight when making decisions in our teammates area of expertise. We should always be listening to our teammates and taking in different opinions. However, it is still valuable to have “owners” for a role, and spending a week or a month or even a year working in a role is not the same as making it your career. There are going to be times where a more experienced team will need to support somebody in their role, especially if they’re new. But that’s not the same as you “being able to do it better” or “having veto power”. This can get quite bad; I’ve known engineers who genuinely believed that they could step in and do any role in their company better than the people who had made it their careers. This is the opposite of the empathy we’re trying to create.
I’m wary about aggrandizing this advice. Trying other roles is a simple technique for working better with your teammates and it isn’t going to change the world. But I’m writing this on the first day of 2021. 2020 was a year that was marked by a lot of suffering and struggle across our world, and also one that seemed to me to lead many people away from empathy and connection and toward conflict. Consider this as a simple way to build empathy and connection with your teammates this year.