Many of the major revelations for me as I moved into senior management involved the relationships that I needed to develop with the other people on the executive and leadership teams. I had the opportunity to work with people I respected across many functions, and because we had a large and diverse leadership team I got to know many different types of senior leaders. I got along better with some than with others, and I evolved my perspective by learning from both types of interactions.
Senior leaders, more than any other group in a company, must actively practice first-team focus (introduced in Chapter 6). They are dedicated first and foremost to the business and its success, and secondly to the success of their departments as a way of contributing to the overall business success. Leadership books such as Patrick Lencioni’s The Five Dysfunctions of a Team2 write about this relationship, and while many of us start to practice this type of leadership with other engineering managers as our “first team,” senior leadership is often the first time your peers all operate in a very different way than you’re used to, and having few to no peers on your first team who are fellow engineers can feel very isolating.
So what does it feel like to work well with cross-functional peers? To start with, you let them own their areas, and they let you own yours. Many of us learn how to do this earlier in our careers, when we have to work with senior designers, product managers, or other business team members, but if you haven’t learned how to let a peer own her specialty, now is the time. Giving her respectful deference when it comes to her turf is fundamental. If you disagree with her management style or application of her skill set in places where it isn’t directly affecting your team, you treat that disagreement like you would treat a good friend who happens to date people you don’t love. Unless she asks for your advice, try to stay out of it as much as possible, and certainly approach any disagreement you choose to discuss with kindness. Be willing to let those differences lie.
Of course, you’ll disagree with your peers. The place for this disagreement is either one-on-one or in your leadership team meetings. These meetings are where you hash out differences of opinion on strategy, challenges the company is facing, and details of direction setting. If the numbers don’t make sense, ask the CFO in the context of these meetings. Also expect to defend your own technical decisions and roadmap in this setting.
This brings us to the second element of trust, beyond trusting someone’s abilities. In The Five Dysfunctions of a Team, Lencioni notes that absence of trust is a fundamental dysfunction. In this case, what’s missing is the trust that your peers are actively trying to do their best for the organization, that they are not trying to manipulate situations, undermine you, or otherwise get their own way. So, beyond establishing basic respect for your peers’ ownership of their turf and respect for their abilities as functional experts, you also have to put aside the idea that they’re acting in irrational or self-interested ways when they disagree with you or do things you don’t like.
Establishing this fundamental trust is really difficult. You will probably have some degree of a cultural clash with some, if not all, of your peers. The values that make a great CTO are probably slightly different from those that make a great CFO, CMO, VP of Operations, and so on. A very common clash occurs between people who are extremely analytically driven and those who are more creatively or intuitively focused. Another is between the people who prefer to embrace agility and change (and, yes, sometimes disorder) and those who push for more long-term planning, deadlines, and budgets. You have to figure out how to understand and trust everyone’s styles across the spectrum.
Engineers frequently struggle with the transition to respecting and communicating well with diverse peers. I believe the struggle with respect is a side effect of the current tech culture, which tells us that engineers are the smartest people in the room. It can’t be said strongly enough: your peers who are not analytically driven are not stupid. On the flip side, we undermine ourselves when we fail to talk so that nontechnical peers can understand what we’re saying. Throwing out jargon to people who aren’t familiar with it — and who don’t even need to be familiar with it — makes us look stupid to them. We therefore need to figure out how to communicate the complexity of our work in a way that an intelligent but nontechnical peer can understand.
The final element of this first-team trust and respect is the cone of silence. Disagreements that happen in the context of the leadership team don’t exist to the wider team. Once a decision is made, we commit to that decision and put on a united front in front of our engineering teams and anyone else in the company. It’s easier said than done — I’ve struggled frequently with hiding my own disagreements with my peers. Letting go when you don’t get your way, especially when you don’t feel that your objections have been heard, is hard, and it will have to happen from time to time. At this level especially, you must decide whether you want to fall in line or quit. The middle ground, openly disagreeing with your peers, does nothing but make the situation worse for everyone.