Smita Patnaik

Good morning, everybody.

Good morning. Last year I was here at Enterprise Technology Leadership Summit at the same venue, and it was a great experience. I got to meet a lot of smart folks like you all, learned a lot, and learned from the experience that other companies are having.

But there are two things that stood out. One was that we are different, but same in a lot of ways in the kind of challenges we are facing and the goals that we want to achieve. And secondly, among the many, many presentations that I experienced last year, and in the last two days here this year as well, there was not one presentation from the energy industry.

So here we are telling you a story about how we are building a learning culture in MISO software engineering. I'm Smita Patnaik, manager of software engineering.

Curtis Reister

Hello, I'm Curtis Reister, senior director of our software engineering department. I'm going to talk a little bit about MISO and then hand it back to Smita to talk about the learning culture.

I'll ask with a couple questions. Does anybody like their power on? Do you enjoy electricity? Anybody wish it would all go away and go back to horses or something? And you like a low-cost energy bill, right? Nobody likes a big high energy bill showing up at their house either. That's what we're fortunate to have in this modern society: reliable energy that's frankly affordable, relatively affordable. And that's really MISO's mission. It's that bold. Our mission is to keep the lights on and keep it affordable.

One way to think of MISO is like an air traffic control system. Most of you are probably way more familiar with that. A lot of you probably flew here. You're probably aware that there's a control tower, a group of people sitting with a bunch of screens, collecting radar data about your planes, making sure they take off on time, they transit, don't run into each other, and land where they need to go. It's trying to create a safe, effective, efficient system for air traffic.

At MISO, we're doing the same thing with energy. Just like the air traffic controllers, they don't own the planes. They don't own the airports, they don't own the airlines, but they manage what those companies do so they can all work together and everything works together correctly. That's what MISO is for energy. Your local utilities join ISOs; that gives them scale and allows them to operate safely in a more regional scope.

In the same way, we don't own the electrical lines or the generators, but we essentially operate them for the utilities so that all the energy can flow reliably 24/7.

We also have, on the affordability side, an energy market. We make sure everything is competitive, that the power generators are running the most efficient and least-cost generators to provide that energy to you so that the prices stay low. We have a competitive market that sets the prices.

To dig a little bit into the scope of MISO, we're one of nine ISOs. You see this map of the United States. We're the dark blue one right in the middle, and that's what the M is in MISO: Midcontinent. There are other ISOs. The one closest to you is California ISO. We provide that scale I was talking about so all those little utilities can get scale that reduces their risk, reduces the cost, and maximizes the economics. We zoomed into Indiana, and that's where we're based, out of Carmel, Indiana. Right there is a building, and it has a control room just like air traffic, with operators monitoring the grid 24/7.

To put it in terms of dollars, we actually create $14 of value for our members for every dollar we spend. We're a relatively small company operating and creating a huge amount of value across our members.

Looking at the scope a little bit: 45 million people operate within our footprint. That's about 13% of the population. That's also factories, hospitals, commercial buildings, and homes, all in that footprint, depending on the energy we deliver.

At the bottom there's $40 billion. We kind of control the way money flows. You have a bill you pay at home. Eventually that utility has to buy the energy, and that has to be given to the generators who are generating the energy. We manage that flow of money as well. That's what the bottom represents: that flow. Generators produce the energy, the big electrical transmission towers you see when you're driving down the highway move that energy to where it needs to go, the utilities pick it up and deliver it to homes and factories, those bills are collected, and that money flows through MISO and gets delivered to the people providing the energy. Most of our value comes from that flow.

All of that's 24/7. There are about 300,000 data points collected across our footprint in real time, because energy has to be balanced in real time. You have to produce the exact amount of energy you're consuming at any time. There's a lot of real-time data and systems involved because people can't do this. It's too complicated and too big. It's all computer systems that we use to run this.

There are three primary value streams. Grid reliability is the keep-the-lights-on part of MISO. That's very near time. We literally control the grid every four seconds. The energy market sets prices and settles them between the generators and the load-serving entities. Then we also have a much more future-looking part where we think about what sort of transmission we need and how generators connect to our system.

There are disruptors in our future, just like all industries. A big one is weather-dependent generation: wind farms and solar farms being built at an accelerating rate. Those types of generation we can't control. The wind only produces when the wind blows. Solar only produces when the sun is shining. That creates a whole dimension we have to manage now.

Electrification and load growth are another disruption. AI data centers are talked about a lot in this conference. One of those data centers can be the equivalent of an entire city. Then there are increased severe weather events. Think about the winter storm down in Texas. About 70% of Texas was without power during that storm, and about 50% of folks didn't have water, couldn't get groceries. These severe weather events really affect the grid, and we have to manage that risk as well.

We do all this with a relatively small team of 50 software engineers. Smita is going to talk about how we develop that talent and meet these disruptions with a relatively small team.

Smita Patnaik

Does that disruption resonate with folks here in other industries? I see some smiles and nods. Okay. How do we tackle these disruptions? Yes, that's a rhetorical question.

Learning and innovation. In this high-stakes and high-complexity environment, learning and innovation is not just valuable, it's foundational. There are only a very few ISOs managing the entire grid of the USA. Along with these ISOs, there are some other co-ops too, to help with grid operations, but there are very few. This is a not-for-profit space to keep the energy cost low, and there are very few vendors in the space with true deep domain knowledge to help really create these solutions. So software engineering in MISO plays a really core role in creating and maintaining these solutions.

Innovation in this context means more than building features. We have to deliver scalability, reliability, and resilience in a system that has to function 24/7 flawlessly. That means from real-time platforms to predictive analytics to AI-driven grid operations, we have to keep up with technological change quickly. We have to be agile, curious, and ready to experiment and learn. It's not just about keeping up with tools and architectures. It's also about coming up with real solutions that will help us be ready for the grid of the future.

It means we have to embrace principles of DevOps, cloud-native design, AI, ML, and more to solve problems that did not exist ten years ago. It means creating safe spaces for our engineers to learn, innovate, and iterate quickly.

Here are four key ways we have shaped and grown our culture: continuous improvement, delegated ownership, product mindset, and leadership support.

Continuous improvement. We do a lot of similar things that happen in other companies as well. We encourage training time for our folks. We give them time to go through courses, certifications, and conferences. We set aside budgets so people can go to all these places and learn. We have lunch-and-learn series to further support that learning process.

I'll highlight some stories from our experience: how we have adapted and supported this culture. I'll first start with the software engineering round table, a fancy name for lunch and learns. It has evolved significantly over the last seven years or so. It started as lunch and learns driven by a motivated individual contributor. It was passionately led and well intentioned, but it struggled with sustainability and engagement.

To encourage broader participation, we went through a second version where we introduced a Lean Coffee style format, which means participants could offer topics and participants could vote which topic gets spoken about. It was successful. There were more voices, and we brought together more voices in the room. Eventually, it was better than before, but it was still limited to a group of individuals, and it eventually lost momentum.

In its third iteration, we introduced rotating team ownership and a shared team backlog. Adding a MISO-themed Kahoot quiz made it fun and interactive, and that format ran successfully for two years. Still, I remained the de facto owner of that meeting, so I needed to get out of that.

In its current format today, it is owned by a group of engineers from across the teams, from across the department. It has become a cultural cornerstone driven by shared ownership, peer-driven learning, and continuous iteration. For technology leaders, it's a reminder that sustained engagement comes from empowering the community, not just organizing events.

Next, let me talk through the outcome. How do we say we are successful? We did a recent DevEx survey, and 75% of our staff value the software engineering round table for sharing and learning. Year over year, we have seen conference attendance go up by 20%, which is a sign of strong growing engagement.

The next story I'd like to share is about the software engineering summit. It's an internal conference organized for MISO software engineers internally. After years of predominantly working in a remote setting, it became clear that we needed to foster deeper, more organic connections across our teams.

In 2024, we hosted our first MISO software engineering summit. We brought together engineers from across the country. We organized sessions on ideation, prompt engineering, and of course AI has to be there, so generative AI using GitHub Copilot. We paired that with informal social gatherings that sparked spontaneous conversations and cross-team bonding. A post-event survey confirmed its impact. Engineers valued the chance to connect, exchange ideas, and recharge their sense of purpose. For tech leaders, this reinforced a key learning: intentional in-person experience amplifies innovation, cross-team bonding, and accelerates alignment across distributed teams.

That was great. We wanted more of that energy, more collaboration, more creativity, and we leaned into that vision at our just-concluded software engineering summit. I'll get to that in a little bit. Before that, let me talk about another exciting thing: our journey with hackathons.

We launched quarterly hackathons in 2023 to spark experimentation in a traditionally risk-averse regulated industry. That's important context to have. Early participation was limited to one or two teams. Years of compliance had made our engineers hesitant to explore creativity even when given that space. With consistent coaching, engagement grew. We did see improvement, but we still were not seeing the energy for innovation we wanted. We wanted to do more, so we tried something different.

We organized an in-person hackathon in our 2025 software engineering summit. We flipped the script a little bit. We randomized the teams, introduced playful constraints, and gave them a challenge to build the worst possible user interface. Yes, it's an AI world, so we said they had to use GitHub Actions and GitHub Copilot. There was that AI aspect. Midway through, after starting the hackathon at 8:00 AM, at about one o'clock we threw in a twist: they had to localize the application through made-up languages.

The result was one of the most energizing sessions we have ever had. The slide depicts some of the fun applications our folks created. One was Spot Willing, a parking spot bidding tool. The twist was that whenever somebody bid, an alert showed up, and that alert kept increasing. Everybody had to fight between trying to bid for a parking spot and trying to close those alerts. It had to be the worst possible user experience. If somebody enjoys that experience, let me know; we'll have our staff build you one.

Somebody else created a MISO acronym decoder. We have thousands of acronyms in MISO. The twist was they did not have access to their keyboards. People had to go in and hunt down letters, like in Duck Hunt, and then eventually they also had to hunt down the submit button. Our engineers got really creative.

The humor was the hook. The real wins were creativity and collaboration. It was fantastic. There was energy in the room. Our CIO just stepped into the room for five minutes and gave us feedback like, "You're doing great," and then stepped out because it was just that evident. Our architecture team wanted to emulate that same format for an architectural hackathon, just because of how successful the format was.

Those were the ways in which we support the learning culture and innovation culture very tactically. Everything is dependent on doing a course, going to the round table, sharing learnings, and so on. There are three other ways in which we support this learning culture that are not directly related to the act of learning.

One is delegated ownership. At MISO, software engineering teams have embraced agile principles for a long time. Now we are pretty mature on that front. Our engineers identify problems, take initiative, and come up with their solutions. There's no looking up for top-down direction for that, which is great. It empowers our teams to explore, experiment, and grow through real-world problem solving.

We also recognize that innovation, and letting our teams drive solutions like this, inherently comes with the risk of failing. That's okay. Rather than focusing on blame when things go wrong, we have built a culture where we focus on what went wrong. Our problem management team works with our folks to identify what went wrong. They follow structured root cause analysis principles to help identify and prevent recurring high-impact incidents. We have support teams empowered to figure out effective workarounds, while the development team is empowered to engineer long-term solutions.

This clear separation of responsibilities, combined with a no-blame mindset, encourages open dialogue, reflection, and shared learning. Over time, this has helped normalize failure as a learning opportunity.

Next: product mindset. Software engineering at MISO has long been an execution-focused arm. But in recent years, two product lines have functioned very differently than others. In these cases, software engineering and business formed a persistent partnership. Feature development was not transactional; it was very feedback driven. That resulted in outcomes that were very appreciated in the control room. Our control room is where the whole action is. If you're helping the control room, you're helping run the grid successfully eventually.

One stakeholder's feedback really captures how successful that format was. Seeing this feedback go directly to the director of the department says tons about how the business benefited from that sort of model. We wanted to roll out this model across all our teams, and that's what we are doing through the project-to-product transformation that we are going through right now. We are still in the thick of it, and I'm sure we'll have stories we learned from. That would be a presentation for another time in a few years.

Last but not least, the role of leadership in supporting this kind of culture at MISO. Technology has a seat at the executive table. Our chief digital information officer supports strategic modernization and technology adoption with strong executive backing. We are advancing initiatives like AI across all levels of the organization. Again, having the context that we are in a risk-averse, regulated industry is important. I do not believe that we have ever adopted a new technology this fast ever before.

We have made significant strides on that front. We have a group of AI champions, a group of passionate engineers who stay on top of AI trends, run POCs, evaluate tools, and evangelize the value of AI. This grassroots movement is a direct reflection of leadership's commitment to fostering a truly innovative culture.

Our leaders also embody a continuous improvement mindset. We hold regular developer experience surveys to identify friction points and drive targeted improvements in tools and processes. This reinforces a culture that is transparent, psychologically safe, and always evolving.

This is the result from our recently concluded developer experience survey, where our staff is extremely happy with the kind of innovating culture we have in our department. Our staff also strongly believes in the management team's ability to guide the department. That's a strong testimony.

We are in the home stretch here. If you've been with me for the last 20 minutes, thank you for listening to me. But this is the last day of the conference, and if you've zoned out, I don't blame you. This is the one slide you need to look at. If you need to reach out, have a conversation, or ask questions, please reach out. We are in the hallway, at lunch, or connect with us online.

This is the story of our journey until now, and we are still seeking ways to improve. Here are some ways. How do we measure engineering outcomes consistently? The presentation from Booking.com and the workshop with Laura Tacho yesterday were really interesting. We are trying to sift through all of those agile metrics, flow metrics, and DevOps metrics, trying to figure out what metrics we should hone in on to measure outcomes consistently. If you've got ideas, if you've done this successfully, we want to hear from you.

How do we strengthen feedback mechanisms beyond DevEx surveys, beyond customer satisfaction surveys? How do we amplify those feedback mechanisms?

MISO is in a critical industry where being safe and reliable is important. That is non-negotiable. On the other aspect, we do need to be prepared for the future and we do need to support experimentation. We are still constantly trying to find ways to keep both operations running in parallel. We are still looking for how to boost support for experimentation.

And yes, it's like drinking from the fire hose, the way technology is changing and the pace at which we have to learn. We have to make sure that the learning is also getting transferred appropriately. We are looking at ways to sustainably make sure that we are planning for succession and transferring that knowledge efficiently.

If you've got ideas, please connect with us. That's how you can connect with us on LinkedIn. Thank you.