Today I'm sitting across from my teen daughter, Pietra, in our attic, locked down because of COVID‐19. She gets through her daily studies on Google Classroom and then shifts to virtual classes on art and dance. She's incredibly creative and builds wonderful multi‐story mansions, dynamic amusement parks, and enchanting underwater castles in Minecraft, her favorite game where she can easily express her imaginative ideas. I'm happy for this intellectual distraction, and it's certainly better than some of the digital sugar streamed at her on TikTok and YouTube. I try to get her interested in coding, but she hasn't shown interest yet. Growing up a digital native, and with her imagination and originality, I wonder what opportunities she'll pursue and whether this evolving world of digital experiences will someday lead her to take on a job that hasn't even been invented yet.

I'm reminded of a situation two years ago when my cousin asked me to come to Queens, New York, for her school's career day. I was there to talk about technology job opportunities, and these high schoolers were not shy with their questions. “You're a chief, right, a CIO—how much money do you make?” came from one student, while the next asked, “Should I even bother learning Java, and should I develop my apps in React or Angular?” But my favorite question came from a girl who was intrigued by my writing and speaking. She showed me her scrapbook, and it was clear she was talented at drawing figures and elaborate fantasy scenes. She asked me, “I know becoming an artist isn't easy, so how can I prepare myself for roles in technology?”

There are incredible technology roles and opportunities for her and my daughter. Today, employers might be looking for full‐stack developers, cloud engineers, and data scientists, but many other important technology opportunities are in demand. Companies need more creative people to collaborate, innovate, and develop simple and delightful customer experiences. There are opportunities to build the next generation of video games, create industrial AR/VR experiences, and architect sustainable smart buildings.

Yes, I want creative people on my teams from diverse backgrounds and with different skills and interests. And there are many reasons why crafting high emotional intelligence (EQ), diverse teams is important for the Digital Trailblazer who wants to innovate and deliver business outcomes.

Only 25 percent of the computing workforce are women, with only 3 percent African American women and 2 percent Hispanic women, according to the National Center for Women & Information Technology.¹ Only 18 percent of women make it up the ladder to become CIO.

And here's one reason why diversity is essential for innovating and creating high‐performance teams:

Learning Team Building and Culture Without a Playbook

There's more research, writing, courses, and best practices today on the importance of developing collaborative, diverse teams and transformative cultures. But when I assumed my first CTO role back in the 1990s, I didn't know much about these important subjects. I was more concerned about filling gaps in my technical knowledge, hiring super‐skilled developers, and defining our best practices. It didn't take long for me to realize that part of the role required me to influence the team's attitude, norms, and behaviors. I had a startup founder's title, too, so I was also setting an example for our company culture. No one told me this, and at that time, there weren't dozens of books from Silicon Valley spelling out the importance of organizational culture or how to implement it well in growing startups.

I made it my business to get to know the team as a group and as individuals. Many times, that meant going out to bars and having beers, and working near Chinatown gave us other unique options to explore and be adventurous. Steamed pork leek dumplings. Salt and pepper baked squid. Vietnamese pork chops. They were all favorites of our CTO, Ilan, and he paved the way for our adventures in Chinatown.

I used to tell people that our office was on the great divide of culinary greatness. From our offices on Franklin Street and Broadway, we can walk east into Chinatown for an amazing lunch for less than ten dollars a person. Or we can head west into Tribeca's growing culinary scene. I loved a late breakfast at Bubby's and lunch at Walkers. There was a Thai place on Varick near Canal Street that I thirst for whenever I think about curries unscathed by attempts to appease the bland American palate. Our night trips were up to the East Village where we hoarded sushi at Iso, drank to the hardcore beats at a basement sake lounge called Decibel, and then went across the street to Veselka to carb up in an attempt to avoid next‐day hangovers. You can still visit Decibel and Veselka, and I highly recommend them.

When we started as a group, there were just four of us coding hard and sometimes partying harder. With every round of funding, the group grew a little bigger, and we tried to keep a work‐hard, eat‐well startup culture going. We didn't have room for a foosball table in the office, but we did have a Sony PlayStation and spent countless hours playing hockey on it. As the company got bigger, we eventually had enough space to add a ping pong table.

Food, drink, and games. Is that what startup culture is all about? It was certainly fun, but our culture needed to be defined differently as the team grew.

When I assumed the CTO role, there was already a counterculture forming at the company that heralded MBAs from fancy schools wearing expensive shirts. Our team wasn't focused on selling new business or developing the marketing plans that made us look bigger on paper than we were generating revenues. Our colleagues thanked us only occasionally. IT is often a thankless job, and to keep up morale, I needed to find ways to recognize teams and people for their hard work and accomplishments. And going one step further, I realized it was important for people to feel comfortable, safe, and enthusiastic about coming to work and being in the office every day.

Since the company was growing, finding and hiring people who wanted to be on the team was essential. My hiring practices then were instinctive. It was no secret that IT was male dominated because many of us experienced the imbalance in computer science or engineering programs. But my mother was a programmer and would come home telling me and my brother stories of the challenges she faced at work. She is an immigrant and became a U.S. citizen, and even though she went through English schooling, she isn't conversant as a native speaker. I believe my instinct to hire more women came from my mom, and I always had higher female‐to‐male ratios on my IT teams throughout my career.

We also had to compete for talent. Back then, we weren't competing with other startups or behemoth tech companies offering outlandish salaries and benefits. In New York City, we were up against Wall Street companies that outbid us and also provided long‐term career paths. Our saving grace included more work–life flexibility and the potential to make fortunes. Our startup didn't have grandiose aspirations to change the world, and most of us were just happy not to be working at a big bank or any other large corporation with thousands of people churning out code and surviving the office politics. We sold potential recruits on interesting tech challenges and the opportunity to be a part of a new adventure working for an internet startup.

But we still had to be creative, and I remember getting questioned by human resources (HR) back then when I wanted to offer a quality assurance testing job to an English major who didn't have a computer science degree. My instinct was that we needed someone in the group with strong writing and communication skills, and here she was, an English major with no technical background but an eagerness to learn. HR told me hiring her was a risk, but I thought it was a no‐brainer. I was right.

Having a recruiting and hiring strategy is only the beginning of building an effective culture. Building happy, collaborative teams that are open to diverse points of view starts with making the right hiring decisions and continues with nurturing your existing talent.

I was fortunate to address a meaningful challenge in the very early days of agile with several developers on my team, including Bart, Daniel, Alexandra, and Karina. At the time, Bart is still working toward his bachelor's in computer science, but Daniel is mentoring him on server‐side software development. Alexandra is a seasoned programmer with a methodical problem‐solving approach, while Karina is very new to the group and software development.

They work as two groups of two developers for a while, but as the application gets more complex, they have more interdependencies. Their work is a top priority, so when Alexandra and Karina express their difficulties working with Bart and Daniel, I'm eager to hear what could be slowing them down.

Daniel introduced pair programming several weeks earlier and paired with Bart on some challenging algorithm upgrades. The code was new to Bart, and the two worked well together. I knew algorithm development was a new challenge to Bart, so while I didn't know the ins and outs of pair programming—which entails two developers working together at the same workstation—I gave Daniel the nod to give it a shot.

And it worked. Soon, Bart was ready to go off on his own, and Daniel was eager to take pair programming another step forward. He planned to pair with Alexandra and ask Bart to pair with Karina. Daniel had the best of intentions, hoping to take a practice that worked once and apply it a second time while also addressing some of the coding bottlenecks that were slowing us down.

And that's the issue Alexandra and Karina escalate because they are not interested in working with Daniel or Bart in pairs. They don't like the idea of sitting shoulder to shoulder with them, and they are concerned about whether their contributions will be recognized if they pair with another more senior developer.

I listen but don't have an answer. Until then, I cared more about getting the work done, the level of innovation, the code quality, the system's performance, and whether the business was seeing an impact from our efforts.

I had the instinctive reaction that something was wrong, and it wasn't anyone's fault. Daniel had all the right intentions, and Bart was trying to take what he learned and put it into practice. But I sensed something that day. An attempt to get one way of doing things that worked for Bart and Daniel needed more thinking before extending to others in the group. Alexandra and Karina were never part of the discussion, and we were a small enough group back then where they certainly could have been invited to share their thoughts or concerns. Unfortunately, Daniel thrust pair programming on them, and while it was solving the technical problems, it wasn't helping our team dynamic. If Alexandra and Karina had an active part in the discussion, perhaps they would have been more open to pair programming or could have shaped it into something that worked better for them.

That's what creating a way of working is all about. It's the discussion that takes one idea, one agile practice, or one DevOps norm and sees how to apply it again in a larger context. You can't go into team building, defining standard practices, or growing adoption with a what‐worked‐for‐us‐will‐also‐work‐for‐you mindset. Equally, buying and instrumenting highly prescriptive agile frameworks often robs people of the opportunity to learn, understand why, weigh in, and shape the team's collaborative practices. Digital Trailblazers who want collaborative, diverse, high performance, and high teams with high EQ must invite people to the conversation around standard practices. It's one reason you'll hear diversity and inclusion together because leaders must start with diverse teams and then create an environment of open discussion and dialog.

For now, I make a tactical decision. We would use pair programming to train new people. We wouldn't use it as a way of working. We found ways of implementing the pairing without people sitting so close together. It was a practical compromise and one aligned with productivity.

It's during my days of working in startups that I develop my muscles and practices to hire great people first and address skill gaps through learning and pairing. I recognize that having diverse teams isn't sufficient, and I need an inclusive approach to develop standard ways of working that—as I said earlier—help people feel comfortable, safe, and enthusiastic about coming to work and being in the office every day.

These approaches will help you create collaborative teams and agreed‐upon ways of working, but there's much more to creating a transformative culture. First, as you gain responsibilities, you'll have fewer day‐to‐day interactions with teams and people. You'll need ways to measure engagement and sense the organization's morale. You'll need to know how to influence groups, teams, and people, consider individual emotions, and factor in complexities you can't control.

I wouldn't fully understand culture building for another decade when I became CIO for teams in multiple global locations.

There are many ways to think about culture. How you encourage innovation, experimentation, learning, and smart risk taking is critical in transforming organizations. Agile teams committing to their sprint's work is a step away from micromanagement and toward building trust. We expect agile teams to provide honest estimates, and we require product managers to host open discussions to share customer needs and opportunities. DevOps teams adopt blameless postmortems to openly discuss issues and problem root causes without fear of retribution. And we ask everyone to bring data to every discussion, openly discuss insights, and facilitate collegial debates on actions.

But two disciplines stand out from my progression from team leader to global CIO. I needed to learn what it means to be an empathetic leader and then understand how to build a winning leadership team.

Fostering Empathy on Agile Teams

How should I think about team happiness?

Why and how is team happiness important? How should I determine whether and to what extent the team is happy? And what if they're not happy? What should I do about it to make them more comfortable? And what if it's just a few members of the team who are unhappy, but the rest are jolly as can be? Is this a significant issue, or is it just human nature that some team members, at any given time, are probably not going to be happy?

And what should I do if someone on the team starts voicing their unhappiness? They're grumbling to their colleagues or gossiping with friends from other departments, or maybe they're going to human resources with their grievances. How do their colleagues or human resources respond to this information? How will they help an unhappy employee? Will they inform me about the issues? Will they provide suggestions on changes, or will they come in with alarms blazing, assuming that one person's grievances imply that the entire department is in disarray?

These thoughts haunt me when I come into the office every day and especially today. The commute makes my mind wander. Normally I spend the 45‐minute ride on the commuter rail reading, listening, or sleeping. But today, my mind won't stop racing. Off the rail, and I could subway to the office, but I elect to walk. It's early and the best time to walk in New York City with few people out to dodge around.

My mind continues its rambling as I think about how to improve my department's culture.

It's not just happiness. There's sadness, loneliness, or a withdrawal that someone might be experiencing. Maybe there's trouble at home? How do I sense this so that I can handle difficult situations with this person appropriately?

Then there's anger.

I'm a driver. I ask a lot from the teams that work with me, and I must assess how hard to push. What's realistic for the person, the team, the department? What are the signs that I'm driving too hard, too much, too fast? Does it overwhelm people, or does it anger them? Are they frustrated at having too much work on their plate, or are they irritated that I ask them to work hard? Are they resisting the changes, and that's causing their anger? Do they want to challenge the direction we are heading and are furious because they would do different things in different ways if they were in charge?

These thoughts haunt me because I'm not an expert at human emotions. I'm closer to a novice. Years of engineering school and problem‐solving have ingrained my pathways to drive from listening to problem identification, experimentation, and executing solutions. I work with people, teams, and colleagues to get a job done.

Right? Or so I thought. I was dead wrong.

This mindset of working with people from problem through solution only works to a point.

It works when you're in the weeds and working with teammates on a day‐to‐day basis. You can then sense their emotions of the day. They came into the office angry at their spouse, not mad at the work you're doing with them. They're happy today because they have challenging work. They're sad because they read about the death of a musician who influences them. You get that level of detail when you're working with the team regularly. You adjust your expectations. You help and accept help. You drive hard but are present to hear everyone's honest feedback.

Agile methodologies help with this significantly. Our teams commit as a team, so if they are stressed out for any reason, they'll commit less. They talk about impediments during the standup and help each other through what's blocking them. Maybe today, someone is just distracted, and a teammate can step in to help. They celebrate the small stuff at sprint reviews and learn from each other at retrospectives.

I know that agile practices are one ingredient to the team and employee happiness for these reasons. If a team or an employee is unhappy for long periods, I visit the team and see how their agile process functions. Agile becomes my first long‐distance lens into understanding empathy. I use the team's performance and metrics to get a window into their world, and that tells me which teams or people may need some attention.

I also measure engagement qualitatively. Who is asking questions or providing feedback? Are people following up and putting their training and learning to practice? Who is getting their work done and going the extra mile to adhere to standards? Who isn't responding to communications in a reasonable time, filling out HR's employee surveys, or following procedures to update the status of stories and tickets?

Again, these are indicators, and I learn to follow them up with conversations with the employee and sometimes with their managers.

But now, I'm leading a department with multiple teams in multiple locations. I'll get to see some people at the water cooler daily, and others I might only get to see once a year. And even when I see many of them, it is in town halls and large group meetings. Sure, I'll have their attention because I am the CIO. But it still takes many well‐chosen words to raise everyone's listening skills and knowledge absorption rates. For the most part, I'll only have their gazes back to tell me whether they understand, agree, are excited, and are ready to drive.

But I know from experience that whatever feedback I get isn't complete or sufficient. Teammates return to their cubes. Their mind and actions go back to their day jobs. They largely continue doing what they were doing before and how they were doing it.

My message needs echoes. My leaders need to reinforce a steady pulse of required changes and adjustments when teammates can apply them to their work. The values, vision, and priorities need to reach the agile team and their teammates when I'm not there.

Developing a Digital Trailblazing Leadership Team

My anxiety increases as I arrive at the office. Today is a big day for me. It's my fiftieth day at this business, and I am halfway into my 100‐day plan, a ceremonious time when C‐levels are expected to articulate their plans and roadmaps. The tactical parts of this plan aren't the issue, and I'm confident the technical aspects of the roadmap will get done. Getting a leadership team together and turning around the culture is the challenge.

When you get a leadership role, you'll be asked this wonderful question from your mentors. They'll ask about your team. Your direct reports. Your lieutenants. They'll say something like, “Make sure you focus on your leadership team and get the right people working for you.” Or something like that.

And the first time you hear it, you might scratch your head on the meaning of the statement and question. Who are the right people? What does it mean to focus in this context? Then you'll get to the heart of the matter. How should you go about forming a leadership team?

It's not easy, even for those of us who have done it several times before. Every organization is different. Every situation where you are fifty days into the job is different. It starts with hundreds of questions about who is already on this team and then determining whether and to what extent you can make changes.

I do this on day 50, but also day 150 and again and again. I still look at leading organizations and grooming leaders aligned to an agile cadence, though the sprints are not fixed in duration. As a leader, there are times when I can only listen and can make a few tweaks, while other times, I can grab the bull by its horns and drive significant changes.

Today is one of those days, and today is the start of the next fifty days I use to develop my leadership team. In my first fifty days, one leader elected to leave, and the other one, well, let's just say the person wasn't going to work out. I fought to get one additional open position, so now I'm in a race to find the right people.

Back to that question on what is right. I'm not just looking for leaders to take on responsibilities. These leaders will be closer to the agile teams. They must echo the company's strategy and my vision and have their own voice with their teams and with me. I seek leaders who are great listeners and are ready to make data‐driven decisions. They must be collaborators and handle the pressures of driving change. I want drivers, but not bulldozers, because they must seek feedback and seek contributions from everyone. Of course, they need some of the skills I am seeking, but I must pick which skills are critical and which they can learn during the journey.

I hire Donovan to manage operations and Pranav to lead application and agile software development. They need to be driving 30 degrees left and right of the north, but with enough gray area that overlaps their leadership styles, technology acumen, and understanding of responsibilities. It's the overlap that makes them empathetic, collaborative, and often conflicting.

When an application release is 90 percent complete but showing performance issues, who takes charge and drives the right decision? When we have only one open position, will they fight for the role without mercy, or will they listen and acknowledge what is right for the department and the business? When a developer breaks from standards to reach an innovative solution, how will they collaborate on the right balance of activities to support her?

Donovan and Pranav are drivers, and they push their speedboats at 70 miles per hour. The wake they leave behind, which should be the gray area I seek, is wavy and choppy. They argue more often than collaborate, and too many issues bubble up to me. Their boats are moving so fast that the wind prevents them from listening attentively to their teams. There's conflict because the teammates understand the requirements and the agile process but haven't fully embraced why either of them is pushing for specific standards.

And there is even more conflict with our colleagues working in product management. They see the teams' velocity but don't receive communications about the direction, the estimates, and the forecasts. They don't understand why Pranav prioritizes technical debt over features this sprint or why Donovan has to blackout the release calendar for two weeks to support an infrastructure upgrade.

I hire Gracie to take ownership of the project management office, agile practices, and department finances. More important, I select her to create the required balance between speed, agility, innovation, safety, reliability, compliance, growth, operational excellence, empathy, and tough love when required.

I ask her to be the active listener and provide feedback to Donovan, Pranav, and me. I want her to make sure the team understands why agile methodologies, when to use NoSQL and not SQL, why bringing an A‐game to the change advisory board (CAB) is important, and why we will use several no‐ and low‐code platforms to drive fast and agile solutions. If the team doesn't understand the business direction, then I want her to bring in the right people to explain it to them. I want her to encourage the teams to ask questions and challenge the status quo.

She should lead inclusive discussions on process transformation and improvements and sell me on them. I need her clarity on when to step in and when to get out of the way. Where does the team need air cover? Whom do I need to help get past the proverbial response, “That's the way we always do things”?

I want her to be a team player with our colleagues but also be tough with them. When they ask for too much or don't have their acts together around the requirements, she must say no to them. They celebrate when the teams hit their goals but throw her under the bus when colleagues don't get everything they want. And I am there to support her and the rest of the team because transformation requires prioritization and compromises.

They were two speedboats running 70 miles per hour and an empathetic leader holding them to a formation. We went on to develop five new products together and reshape the business.

As you'll see, feel, witness, and experience, leading transformation is a fast and bumpy journey. A diverse team is required. Thank you, Gracie, Pranav, and Donovan.

For this chapter, I selected a diverse group of leaders to contribute to the lessons learned:

1. Cultivate diverse teams to boost innovation and performance. It bears repeating that companies with above‐average diversity had 19 percent higher revenue from innovation than those with below‐average diversity.

   When you're looking to fill a position, take stock of your team's EQ, backgrounds, and experiences. Look beyond filling skill gaps and be creative where you target recruiting efforts. Helen Wetherley Knight, co‐founder of TechforSocialGood.ca, offers a recommendation: “Seek to hire new leaders from diverse backgrounds. New graduates can breathe fresh life into an established team of experienced leaders, just as a young startup can benefit from the experience of an older leader from a more traditional industry.”

2. Recruit people from different backgrounds, experiences, and places. I hired people who majored in linguistics, economics, art, communications, and others without a STEM background. A few came from well‐known universities, but most didn't, and some didn't have a degree. Paige Francis is CIO of Alliance Support Company, author of Demystifying IT: A Pocket Guide for the Non‐Technical, and an experienced CIO in higher education. She explains how important it is to challenge the status quo on hiring practices and says, “Professionally, I hire, promote with #DEI‐intention.³ Higher education and advanced degrees are statistically less accessible to underrepresented groups and a basic requirement for a career in higher education. Archaic and counterproductive, given those careers offer degree pursuit as a benefit. I would also say #DEI is the floor, not the ceiling. There is no limit to the heights we can reach with diverse perspectives.”

   Jason James, CIO of Net Health, adds that the pandemic should encourage leaders to diversify from where they hire. “Now that a global pandemic has forced organizations to embrace a remote workforce, there's a greater emphasis on hiring for skills rather than for a specific geography. This creates more opportunities to embrace leaders from different backgrounds. Different time zones not only provide expanded coverage when supporting clients but come with their own diversity in regional cultures. For example, would Midwestern pragmatism balance West Coast ambition in development teams?”

   And Helen adds this important, pragmatic advice: “Resumes never tell the whole story; you need to get out and meet people in different environments. Try volunteering as a judge at university events or joining a new networking group. Every person you meet has the potential to increase the collective intelligence of your team.”

3. Encourage everyone to contribute to your organization's way of working. Leaders, and especially Digital Trailblazers, are under significant pressure to drive the organization faster. Maybe you've rolled out agile methodologies at previous jobs or are an expert at instrumenting DevOps. But to succeed in a new organization, culture, and group of people, you must invite them to the discussion, ask for their input, debate options, and decide what's optimal for your organization and situation. It requires open‐mindedness. You must seek opinions from a diverse team—not only will it challenge your thinking and ensure you're being an inclusive leader, but it also has the side effect of helping you identify where you can drive faster and when you need to slow down. Kim Wales, CEO of peer‐to‐peer lending and equity crowdfunding index firm CrowdBureau Corporation and one of my early mentors, suggests, “Allowing leaders to find the ‘I’ in the ‘we’ empowers and nurtures thoughtful leadership that fosters ownership, decision‐making, and collaboration that drives success.”
4. Engage your leaders to listen and extend your EQ's range. In Chapter 1, I challenged you to grow beyond the skills that made you successful as an individual contributor. In this chapter, I suggest that your approaches to team building, listening, partnering, and rallying need to grow when your role extends from leading a single team to leading multiple teams across virtual or global organizations. Your eyes and ears don't extend far enough to experience the pulse of the organization, let alone to understand what's on people's minds and how they are feeling. You must mentor your leaders on where and how you want them to extend your empathetic reach into the organization, with whom to develop relations, what signals to listen for, and how best to help people or struggling teams.

   Hybrid working and managing distributed teams add new dimensions to these challenges. You can't pick up people's feelings as easily on Zoom, and there isn't a watercooler to hang out at to listen and set a vibe.

   Martin Davis, CIO and managing partner, DUNELM Associates, offers this suggestion: “Make yourself available to your teams, set aside time to have one‐on‐one meetings, but also encourage them to interact when they have questions or want advice. Be open and share what is going on (where possible). Knowledge is not power in today's world, and we win as a team.”

5. Assign leadership responsibilities and then foster collegial conflicts. I explicitly define the responsibilities of my leaders so that they know what's expected of them and want them to drive their agendas slightly above their teams' speed limits, say 70 miles per hour. But I also intentionally create some overlap and gray areas to create tension that brings out debate. I want some conflict on my teams because better, thought‐through answers come from the debate and discussion. Competition works with hackathons, experiments, and proofs of concept to test different solutions. But I don't go as far as creating a competitive atmosphere, which in my opinion is a counterculture that has many stressful and avoidable ramifications.

   Having a competitive or stressful environment also reverberates to other teams and people you collaborate with regularly. It can create confusion when your colleagues experience the conflicts and don't know how you've assigned responsibilities. And trust me, the last thing you want is to have a competitive culture to ripple up and across the organization, especially if it's in the C‐suite. As we'll see in the next chapter, collaborating with leaders has enough challenges without a competitive atmosphere.

▪  ▪  ▪

If you would like more specifics on these lessons learned and best practices, please visit https://www.starcio.com/digital-trailblazer/chapter-8.