Uno Platform 5.3 Released, Including JetBrains Rider Official Support

MMS Founder
MMS Arthur Casals

Article originally posted on InfoQ. Visit InfoQ

A few weeks ago, Uno released version 5.3 of their multi-platform UI framework for .NET developers. The highlight of the new release is the official support for JetBrains Rider. Other relevant features include an improved Hot Reload experience, two new UI controls, new font options, and support for SkiaSharp 3 Previews.

The Uno Platform acts as a bridge for WinUI and UWP apps to run natively on iOS, macOS, Android, Linux, and WebAssembly. It is built over different technologies (Xamarin Native Stack, Mono-WASM, and Skia, depending on the target platform), allowing the creation of single-source C# and XAML applications with responsive design and pixel-perfect control and using a single codebase.

With the new release, the Uno Platform introduces official support for JetBrains Rider through a new extension on the JetBrains marketplace. According to the company, this addresses a request from the community, bringing productivity advantages to developers using Rider:

Rider support has been a top request in our recent developer surveys […]. Starting this release, the development experience Rider developers have is on par with that of Visual Studio and VS Code developers. What this means in practice is that you can enjoy the full set of developer productivity enhancers such as C# and XAML Hot Reload for Uno Platform apps and debugging.

A full list of supported scenarios for developers using the new extension can be found here.

Another relevant feature of this release is the improved Hot Reload experience. “Hot Reload” refers to the ability to instantly see the effects of any code changes in a project. With the new release, a new visual indicator displays new information every time Hot Reload is triggered, helping the developer to monitor any changes in the code. The new feature is available on all IDEs for all targets that Uno Platform supports, except for WinAppSDK (since it has its own Hot Reload indicators).

The new release also introduces the support for a new default font for all platforms, using Open Sans. This is a relevant change since the default font on WinUI is Segoe UI, which is not supported on macOS, Linux, or browsers running in either these systems. Also, as a result of this feature, Uno now supports the use of Variable Fonts through the use of a font manifest. Using a font manifest allows specifying where a single variable font file can be used (the Web) and where multiple files may be used (Skia Desktop).

Other features in this release include two new UI controls: ItemsView (available for desktop applications) and SelectorBar (available for Skia Desktop targets). It also includes support for SkiaSharp 3 Previews.

Uno Platform is open source (Apache 2.0) and available on GitHub. The list of supported platforms includes Windows, iOS, macOS, Android, and Linux. It can be used with Visual Studio Code, Visual Studio 2022 for Windows (17.8 or later), and JetBrains Rider (2024.2 or later). The new release supports .NET 8 and later (up to .NET 9 Preview 6). At this point, Uno itself is built using .NET 9, which is part of the team’s effort to be ready to support .NET 9 on day 0 of its official release.

About the Author

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Presentation: Being a Bad Influence – The Dangerous Dichotomies of People Management

MMS Founder
MMS Hannah Foxwell

Article originally posted on InfoQ. Visit InfoQ

Transcript

Foxwell: I am going to talk about being a bad influence. Most days, I think I’m a pretty good manager, but I know that I’ve made mistakes. I know that I can be a bad influence. I’m going to share some of those mistakes with you. This is a very personal talk. I’m going to share some of the things I’ve learned from the mistakes I’ve made, in the hope that my lessons learned will help you do better as a people manager.

Learning how to manage people is by far the most difficult, and also the most rewarding part of the work that I do. Sometimes the hardest things are the ones that are most worth doing. We don’t have enough time to talk about absolutely everything you need to know to be a good people manager. I filtered it down, and I’ve decided to talk about the really difficult stuff. The really hard stuff that we don’t talk about very often. The really hard stuff that makes the biggest difference.

I’m going to give you a quick overview just to set your expectations about the type of things that I won’t be talking about. I’m not going to be talking about hiring or interviewing, and how you do that. There’s lots of other talks on those topics. I’m not going to be talking about how you do a good one-to-one with your direct reports, or even how to run a team meeting. I’m also not even going to touch on how we get shit done. How do we do delivery management as managers? I’m not going to talk about org design either. The things that I’m going to cover, again, are the areas where my first attempts to do these things have been wrong.

I’ve learned some lessons. I’m going to talk about my understanding of the job of a manager. I’m going to talk about how to build inclusive teams. I’m going to talk about equality, equity, and equal opportunities for everyone in your teams, and how you make that happen in a practical way. I’m going to talk about money. We don’t talk about money often enough, I don’t think. I’m going to talk about the reality of performance, pay, and promotions. I’m also going to talk about what it’s like to be a manager on a really bad day. I’ve been through two rounds of layoffs in the past 18 months. We are having to manage through a lot of really bad days at the moment. I’m going to share my experience and some of my advice of how to do that well.

The Job of a Manager

I’m going to start with a relatively easy topic, what is the job of a manager? I’m going to start by talking about your three teams, as a manager. When you’re an individual contributor, your role is usually relatively well defined. You understand the expectations of you. Your manager deals with a lot, if not all of the stuff that’s happening outside of your team. What you see from your manager is very finite. You see the activities your manager is doing in order to manage your team successfully. You might not necessarily see the other work your manager is doing.

When I started managing people, this is what I did. I said, I am managing this team and this is my priority, and this is all that I care about. Actually, to be a successful manager you have to do an awful lot more than that. Your second team is your leadership team. If you are one of those people here who’s a manager of managers, you want to build a really cohesive leadership team because together you are better, together you are stronger, together you are more effective. I’ve seen it happen so often that actually the channels of communication through the organization follow the org design.

Communication flows top to bottom, and there’s not enough of this collaboration at a team level. A really cohesive leadership team that works well together will make a huge difference for the teams that report into them. Think to yourself, actually, am I a part of a leadership team, or do I just share a manager with these other people? If you just feel like you share a manager with these other people, why not try and build those bridges? Why not ask them to partner with you? Why not try and uncover some of the shared problems that you’re all experiencing, and try and build that sense of team and that shared ownership in your leadership team?

Of course, there are other people involved in getting work done. This is the only bit of the talk where I will talk about how we get shit done. Because, quite often, if you’re engineering or if you’re in engineering leadership, you will have peers in product, in product leadership. You’ll have peers in design. You might have peers in infrastructure. We rarely get things done in isolation, we have to act as a team. Actually, for the most part, I don’t see these groups of people behaving as a cohesive team towards a common goal. That’s a problem. That creates a problem for their teams who have misaligned expectations. That creates friction. That creates conflict.

It creates a bad atmosphere in terms of the blame game, “My team did everything they were supposed to do. It was your team that missed the deadline.” It’s just not helpful for anyone. I’ve heard this talked about in terms of stakeholder management, or how you build your network, and who are your allies. It’s much more simple than that. These are your team. This is a team of people who need to work together to get something done. If that group of people isn’t behaving as a team, you’re going to have problems in delivery. These are the three teams that I try to build when I take on a new management role. I know, it’s easy almost to find out and figure out who your team is, who report to you, and how to lead them effectively. It’s sometimes worth investing in building a more cohesive leadership team. It is very often neglected to build that team spirit with your peers in other areas of the business.

I really highly recommend, “The Five Dysfunctions of a Team.” This is the book that actually gave me that light bulb moment of realizing that I was thinking about my team all wrong. “The Five Dysfunctions of a Team,” says that the absence of trust is the number one dysfunction. It also says that that group of peers, that leadership team is your first team. That’s your priority, actually.

That’s where you should be spending a lot of your time. Behaving as though your team of direct reports is your one and only team is actually a dysfunction. This was the book that gave me that light bulb moment that made me see that my job as a manager wasn’t just my team, get things done, and not taking responsibility of everything that was happening around us.

To summarize, hopefully, this is a really practical thing you can take away from here. Reflect on those three teams, in your context. Who are on those teams? Are you acting as a team, the people you manage, your leadership team, and your group of peers? Common mistakes I’ve seen people make are neglecting those second and third teams that can lead to office politics and the blame game, “It’s not my fault. It’s your fault.”

Actually, we should be working together, we’ve got a common goal. Another thing that can happen is you can take it too far. If you have a very tight leadership team, it can sometimes feel like a bit of an exclusive club. Have a think about who you might be unintentionally excluding. I’ve seen a lot of organizations where people like customer support aren’t in the room. They aren’t in the room to help inform decision making. I’ve seen other organizations where design is neglected and product act as the interface into design. How can you bring people together towards that shared goal that you have?

Inclusive Teams

I’m going to move on to my next topic now, and my next light bulb moment as a people manager. I’m going to take a little detour and tell you a story about a work night out in Austin, Texas. We were in Austin, Texas, and there’s this really infamous party street called Sixth Street. They are really generous with the bourbon. I’m having a great time. I’m wearing my new cowboy boots. I’m catching up with lots of people. I’m drinking all of the bourbon, all of it, so much bourbon. Those cowboy boots, they were really slippery. Those cocktails were really slippery, and I fell over. I fell over on a work night out. I fell over on a work night out because I drank way too much.

This is a picture of me from the emergency room where I had to get a CT scan and five stitches on my lip. There is an important message behind this story. Getting drunk isn’t a team building activity. Alcohol is fine in moderation at social events, but it’s not the social event. This was a mistake I made time and again when I first started managing teams in my 20s, because I wanted to have team building activities that I thought were an awesome and great time. I wanted everybody to come into central London and go on a big night out with me. That’s what I wanted. I can see now how problematic that was. How I was accidentally excluding people whose idea of a good time was absolutely the opposite of going on a rampage with Hannah Foxwell.

That’s the lesson I learned about building inclusive teams and inclusive team building activities. It’s got to be fun for everyone. Now I’ve changed my approach. It should be fun for people who don’t drink. It should be in working hours wherever possible. I actually took a team out for a meal. This was a customer I was working with at the time when I was consulting. I took a team out for a meal and I let the sales guy book the restaurant. We took a vegan engineer to the best steak restaurant in town. These are really easy things to get right, and so often, we get it so wrong. How did that person feel a team building dinner that was supposed to be a celebration of what we’d done together, and there was nothing on the menu that they could eat?

I learned these lessons, not as a manager. My managers have never taught me about this. I learned these lessons by being a conference organizer. I’m one of the organizers at DevOpsDays London. We put a lot of effort into creating an inclusive and accessible event, or a nonprofit event, and so we think it’s really important that we run an event that’s for the benefit of the community. We try to remove all of the barriers that we possibly can for everybody to participate in that community should they want to. We’ve been doing this since 2017.

I’m really thrilled to see so many conferences now are following our example, and they’re adopting some of these more inclusive and accessible practices. This is taken directly from the welcome talk that I gave at DevOpsDays London. These are some of the ways that we try to create an inclusive and accessible space for the community. You can imagine using the same mindset at work, how am I going to create an inclusive and accessible environment for my team to do their best work?

Some of the mistakes I’ve made as a manager reveal some of my blind spots, and some of these things that you just learn through experience and you get better, and I hope that I have. To create an inclusive team, I always try to make sure that everybody has a voice. I make sure that team building activities are things that everyone can enjoy. More importantly than that, I try to create enough unstructured social time that team building just happens organically within the team.

Sometimes team meetings can be overly formal. Where is that unstructured time? Where are the team talking to each other about things that matter outside of work? Common mistakes I see people make as I did when I was starting to manage people is imposing your own preferences, likes and dislikes on your team. Having team building events outside of working hours, which really excludes people who maybe have young children or have caring responsibilities at home with their family, or even traveling greater distances. You’re accidentally excluding people by taking events outside of working hours. Also, it’s easy to bias towards the needs of the majority. Maybe you only have one vegan on your team. It’s like, they’ll be fine. Maybe you only have a small number of women on your team. Maybe you only have one person who doesn’t drink. I still believe that the best team building events are ones where everyone can enjoy them equally.

Equity and Equal Opportunities

I’ve talked about inclusion. I’m about to talk about equity. This isn’t a talk about DEI, diversity, equity, and inclusion. This is a talk about managing people. I’ve talked about inclusion because as a manager, I think it’s my job to make sure that nobody in my team feels excluded. I’m going to talk about equity, because as a manager, I think it’s my job to make sure everyone in my team has an equal opportunity to succeed in their career. For me, equity is at the core of people management. Equality is treating everyone the same but equity is taking differences into account so everyone has a chance to succeed.

This is an everyday practice. This isn’t some special initiative. This is about acknowledging where your direct reports are at in their life and in their careers, and adjusting your management style and your techniques and your practices to what that person needs at this moment in time. This is how you make sure everyone has a chance to succeed. Again, when I started managing people, I had blind spots. This is another story about Hannah sat in a bar, unfortunately. I was at an off-site. I was the last person in the hotel bar at 9 p.m., and I couldn’t understand it.

I was like, where is everybody? Where are the expenses? Can we have a couple of cocktails, maybe? Actually, everybody I was with had young children at home. The idea of going to bed at 9 p.m. for them was absolutely luxurious, and that’s what they did. They left me on my own in a hotel bar. That was a blind spot that I had earlier in my career about what the reality for parents was at work.

This is a visualization of a baby’s sleeping patterns for the first year of their life. It’s absolutely brutal. This is what the reality of home life might look like for the new parents, who you manage. As a manager, if your team get woken up in the middle of the night by PagerDuty, I bet you have processes and practices and policies around recovery time. I bet you have awareness of who in your team have been disturbed during the night, and you would be inquiring with them to see if they’re ok. There’s a lot of other reasons that people might be waking up during the night, and you are blind to them, for the most part, as a manager.

One of my colleagues once said to me, having kids is basically like giving up sleep for 5 years. I was like, don’t be silly. Then my sister had some kids, and I met some babies. They’re really difficult. Babies are hard. Indirectly, my niece and my nephew have taught me some really important lessons about managing new parents. Unfortunately, I can’t talk about managing new mothers, because I haven’t had that opportunity in my career, but I have managed a lot of new fathers. What I always try to make sure I do is to make sure that they are able to participate in their home life. Personally, I do not like this idea that mom is always doing the night shift because dad has to log in and work 8 hours tomorrow morning. That’s something that bothers me. I want to make sure that the people in my team can show up for their family whenever their family need them.

Although I can’t influence the paternity leave policies, or at least I can try to, what I can do is I can be flexible. I can have awareness. I can be kind. I can make sure that project assignments and expectations of new parents and working hours are as flexible as possible knowing that not every day will be the same. I can have conversations at the start of potentially a high-pressure project about whether this person feels like it might impact their home life or whether or not they would like to take on a different role on the project than maybe what they normally would.

Working at home has obviously made a huge difference to so many of us. The blurring of the boundaries between our home lives and our family lives and our work lives is brilliant. In the teams that I manage, I celebrate every time a baby or a child shows up at one of our team meetings. I absolutely love it, because they should be there. They are welcome. As long as it’s the right balance for you in your home life, taking a call with your baby on your lap is absolutely fine. I welcome that.

Here’s the other graph. This one is a proper horror story for anyone who’s experienced it. Anyone know what it is? I’ll give you a clue with my next story. I’m going to call this, Hannah’s years of denial, because this is what I used to say, “I’m not a woman in tech. I don’t want to be treated differently. I’m just a person in tech.” My eyes were closed for a long time to the ways in which my gender would influence and shape my career prospects in tech, as a member of a minority. That’s what this is. It’s a menstrual cycle, of course. Unfortunately, it’s an incredibly taboo subject. This is the reality. This is the monthly roller coaster that some of us are on.

I think it’s really important. I know that I have very open conversations about women’s health issues, fertility, family planning with the women that I manage, but I don’t think it’s as common with the men. I definitely don’t see it happening when I have male managers. I think just acknowledging that there are days where there will be physical symptoms from this hormonal roller coaster that a lot of us are going on is really important. If you haven’t educated yourself on what that looks like, maybe read a few blog posts and find out. I am not saying that you go into your one-to-one and you say, “Hannah, you seem a little bit overwhelmed today. Is it that time of the month?” Don’t do that. Having an awareness that there will be really bad days is useful information to have. You can be flexible, and you can be kind. You can think about how you build an environment where those things matter less.

A recent study found that one of the key reasons that women don’t advance as far in their careers as men is a lack of sponsorship. This is one of those unconscious biases that once someone pointed out to you, you start to see it everywhere. Women are over-mentored and under-sponsored. This leads me really nicely in to talk about how you adjust your management style to the needs of the person that you’re managing. Mentoring, coaching, and sponsorship, they are not the same. I’ll talk about the differences between them.

When you go back into the office, have a think about what your direct reports need from you. Do they need a mentor? Someone who supports you in learning new skills by sharing their knowledge and advice. Or, do they need a coach? Do they need someone who’s going to teach them new skills by helping them think through solutions by themselves, asking good questions, allowing the person to find the answer on their own in their own time? Or, do you need a sponsor? Do you need someone who supports you in learning new skills by creating opportunities for you to do new things? Someone who’s going to trust that you can do something that you’ve never done before. This is so important to people’s careers. That moment that someone decides to trust you to accelerate your career, to let you do something that you’ve not done before so that you can learn how to do it well.

I recently had the privilege of sponsoring a young woman into her first management position. I was told by her current manager that she wasn’t ready, that she hadn’t had enough years of experience under her belt. I said, I started managing people at this age, and I did all right. I was like, “I’m plus, like I’m here. I’m going to make sure that she’s successful.” I did that. I created an opportunity for her to do something that her current manager wasn’t allowing her to do, because he thought she needed more years of experience as an individual contributor to do it well.

You can probably guess where this story ends. She absolutely smashed it. I’m so happy that I was able to do that for her. I’m so grateful for all of the people throughout my career who have done that for me, who have been sponsors for me. When you’re thinking about your direct reports, and what help they need, think about whether they need you to be their mentor, their coach, or their sponsor, and adjust your approach accordingly. Because, as I said at the beginning of this section, the right answer isn’t to treat everybody exactly the same. Equality is not the same as equity. We want to create an environment where everyone has an equal opportunity to succeed. Everyone’s definition of success will be different. The help you need to provide to get them there will be different.

Striving for equity means that you need to understand the different needs of each person, understand their personal goals and aspirations. Then adjust and understand what support they need right now at this moment in time in their career to get them there. It’s also really important to challenge your own biases, because as we’ve seen, some of these unconscious biases towards women can mean that we are over-mentored and under-sponsored in a work context.

Common mistakes when striving for equality and treating everybody exactly the same, means that you might have an unintended impact on their home life. Someone might not be able to give you 150% right now, like the other members of the team. It can result in a lack of stretch goals and growth opportunities for your high performers. It can lead to attrition. In a worst-case scenario, if you’re not really consciously matching the work with the person and their current situation, it can lead to stress and burnout. You don’t necessarily want to throw somebody overboard and see if they swim. You need to provide the right support when you’re giving people new challenges and stretch opportunities. Be really mindful about the right opportunity for that person at that moment in time in the context of their career, and in their life.

Performance, Pay, and Promotions

Next, I’m going to talk about the vulgar topic of money, because again, it’s an area where equality isn’t always the right answer. I’m going to be trying to be as generic as possible about this. I’ve worked in moderate to large companies for a while, and so I’m trying to generalize based on my experience of how pay and promotions happen. If you’re in a very small company, it’s likely to look very different. When I started managing people, no one sat me down and explained it. No one sat me down and explained how pay and promotions actually worked in the real world. It was all done behind closed doors.

I learned through experience how to run this process and how to run this process well. What will usually happen is, once or twice a year, there will be budget set aside to allocate to pay rises and promotions. The budgets will be agreed right at the top of the company, and then it will be chopped up, and they will cascade down through the org chart. Your VP will have a big pot of money. They’ll take a little bit to the side for their management team. Then they will allocate budgets to each of their leaders. Those leaders will do the same with their leaders. Then they will do it for their managers.

Those budgets will cascade top-down. Then, managers of individual contributors will make recommendations about what they think their team deserve. The problem with this process is that talent isn’t always evenly distributed across the teams. When budget is equally distributed across the teams, you need to do a secondary step to this process, you need to do the rebalancing and the calibration. This can’t happen unless you’re working really closely with your peers. That’s why I talked about team 2 at the beginning of this talk because you all need to be aligned. You need to be aligned about what a senior engineer looks like in your organization. Because if a manager is imposing their own personal opinions on what a senior engineer looks like, if one manager is setting the bar up here, and the people who report to them aren’t getting promoted as quickly as the people over here, you’ve got inequality, and that’s not ok.

As an individual contributor, you won’t see any of this process, but as a manager you may not see any of this process either, because you might not actually be talking about it. What I would encourage you to do is talk about it. You need to be working with your leadership team and your peers to make sure that the budgets are allocated to the right people based on the impact that they have on the organization, but also about the potential they’re showing for growth.

This is something that I see go wrong time and again, because managers believe that once they have their budget, they don’t want to release a single penny of it, even if it’s the right thing to do. Even if there are three people who are deserving or that need promoting in team 1, no one will release their budget to make sure that they do the right thing for the people who are ready for promotion. They will use up their budget on the team that they have reporting to them. I don’t think that’s fair. I don’t think that’s right. I think a collaborative process is much more effective to get the result you want.

Another thing that you’re going to want to do is check for systemic inequality and biases. We all know that minorities will be generally paid less. Because of the various barriers to entry in our industry, they might have less years of experience, they might have been held back from promotions due to biases. You may need to correct for some of the wrongs that were done to these people earlier in their career. This has happened. If you take on a new team, and you stack rank them by salary, and you find that all the women are at the bottom, you’ve got a problem. It’s this process that allows you to correct for that.

Again, because I would always encourage a collaborative process as part of your leadership team to make sure that you’re being fair and consistent across everybody who has the same role and job, use that opportunity to check that other people are doing these checks and balances as well. Another aspect of this is obviously the individual themselves. When I was a new manager, nobody explained to me how pay and promotion works, and how to do it well. No one taught me that. I think there’s an amount of knowledge that you need as an individual contributor as well.

At the very least, you need to know what the timeline is. It’s no good going to your manager in August and saying, I’d like a promotion in the next round, if in July, all of the promotion recommendations have already been submitted and the budgets have been allocated. Timing is everything. You have to have the right conversations with your team at the right time. If you don’t know the rules of the game, you’re not going to be able to play the game. Being open and transparent about how decisions get made, who the decisionmakers are, what people are looking for and assessing for in these promotion conversations, and how to set yourself up for success, is incredibly valuable. Be transparent about it. There’s absolutely no reason not to be. This is a reality, and it doesn’t have to happen behind closed doors.

As I said, there’s nothing worse than getting to the end of a process for pay rises and promotions and having a very upset employee on your hands because they didn’t get what they expected. If you end up in that situation, chances are, you haven’t asked them what they expected, or they didn’t know that the time to have those conversations was probably weeks ago and not today, in this room. The decision’s already been made.

Again, as I said about that transparency, if you have someone who is expecting a promotion, be really transparent with them about their chances of success in getting that promotion as well. To manage their expectations, you first need to know their expectations. You do this not in an annual process. If you’re only doing this once a year, you’re getting it wrong. You’re going to be providing them with continuous feedback. You’re going to be encouraging them to continuously improve. You’re going to be really aligned on expectations.

I will put you forward for promotion in 6 months’ time, but I don’t think you’ve got a high chance of success now, so I won’t be putting you forward this time. You can have that conversation. It’s not an easy conversation, but you can have that conversation. It avoids some of that upset that happens when someone’s expectations are up here and you have to deliver bad news, or you have to deliver bad news that you didn’t expect was bad news. One of the things that I tell all of my teams, is that everyone’s career path is different, and so you shouldn’t try and compare yourself to others.

Figure out who you are, and then do it on purpose. When we’re talking about continuous feedback, make sure you really understand the strengths and weaknesses of the person you’re managing, and build a plan to get to that promotion with them, that plays to their strengths. Don’t throw them into a situation where you’re going to reveal all of their weaknesses. Absolutely customize it and play to their strengths. Figure out who they are, and help them to do more of that.

One of the things that I’ve found through managing people, is, quite often, the things that make us stand out, are the things that make us stand out. Sometimes your greatest strength, the things that makes you amazing, can also manifest as your greatest weakness. To give an example about myself. Some of the feedback I was given early in my career was, “I’m a bit silly. I can be a bit too fun. I don’t take things too seriously.” In the same breath, someone would say, “You bring great energy for the team. I love how fun it is to work in your team.” I think sometimes you have to take feedback in that context.

You have to think, these are the things that stand out about me, how can I get myself into a situation where this is considered a strength, and it’s not a weakness? In those situations where I need to adjust and I need to adapt, how do I make sure that I’m mindful of the ways that I stand out and the ways that I am different? How can I make sure that it’s not perceived as a weakness? Because treating everyone the same is impossible, because we are all gloriously different human beings. We’re not striving for equality in a pay, performance, and review process. We are striving for equity. We are striving to build an environment and a team where everyone has an equal chance of success, and that will look different for every single person.

To summarize some of my lessons learned about running multiple pay promotion and performance management processes. I reward based on impact. I reward people who make those around them better, who share their knowledge, and who are team players. I also reward for potential, people who I want to see grow in the team, people I want to keep around. I am transparent with the timetable, and I share it with everyone including individual contributors.

Performance management doesn’t happen as part of a formal process once or twice a year. It’s continuously managed, and you continuously manage expectations throughout that process as well. Also, if you can, seek to match the person and the job. Figure out who you are, and do it on purpose, with the help of your manager who can create opportunities that are right for you. They may not be right for everyone. Common mistakes I’ve seen in these processes is where decision making happens behind closed doors or by a single person, maybe a senior manager, and not even the managers who report to them.

When that happens, there’s very little chance for collaboration or consistency or rebalancing in the process. When it happens behind closed doors, there’s little opportunity to challenge for systemic bias and inequality that is not related to the person’s performance. One of the other mistakes that you can make is actually just trying to reward employees equally in the pursuit of fairness. One of my old managers called that peanut butter spreading. “We just chop up the budget and share it equally because that’s the right thing to do.” It’s very rarely the right thing to do. Also, during performance review processes, it’s really easy to focus on people’s weaknesses. Try to remember that the weaknesses might actually just be different manifestations of this person’s strength. Figure out what those strengths are and find a way to use them.

The Bad Days

I’ve been through two rounds of layoffs recently as a manager. Those are bad days. Those are really horrible bad days. I’ve been through acquisitions. Those can also be really difficult emotional days if the acquisition is not something your team wants, or if they’re worried about how the acquisition might impact you. Even things like reorgs can create anxiety within your team, and uncertainty. I’m going to talk very briefly about what your role as a manager might look like, on those very bad days. I’ve had Barbra Streisand. I’ve had Dolly Parton. Now I’ve got Rihanna. All thought leaders.

I think the most important piece of advice I can give you about the bad days is, just be present. Be present for your team. Make it ok not to be ok. What I’ve done in the past, even though I’ve been upset, and I’ve been angry, and I’ve been worried during these times, is I’ve just tried to create a space where we can be together and feel all those feelings and talk about it. I absolutely make sure the team know that today is just not a day to keep calm and carry on. It’s ok. If you need to take a break from your desk, if you need to log off for a while to process this news, or if you want to be together, here’s a Zoom that I’m going to open up and we can just use it as a drop-in for today. We can just drop in and be together and share these feelings and these thoughts and these worries, and do it together.

Unfortunately, we have to be that shit umbrella, quite often. It’s really difficult because during these bad days, there’s often ambiguity, there’s often uncertainty. You can’t share answers with your team, because the answers simply don’t exist yet. Decisions haven’t been made. It’s really difficult to be in that room, as the leader and the representative of the company with absolutely no information. It’s really hard. All you can do is to be authentic, and to be honest about what is going on, what you know.

You can try to discourage gossiping. You can try and discourage people from catastrophizing the event. In reality, you’re going through this with them. My only piece of advice there that I have found works for me is just to literally be there, go through it with them. Another thing that is slightly more structured, and I’ve used this during acquisitions and reorgs and times of big change, is just create space to voice all your irrational fears. Throw an anxiety party. Just be like, we’re just going to spend half an hour right now just venting.

We’re just going to do that. This is the time where we’re going to vent. We all know. We’re all smart people, we’re going to rationalize some of these fears away. For just a moment, we’re going to voice that fear, and we’re going to point at it, and we’re going to look at it. I find that a really powerful activity to do as a group during times of large change and uncertainty.

On those bad days, what advice can I give you? Just make it ok not to be ok. Create space to share your thoughts and feelings, however raw they may be. Be patient. No one is going to bounce back in a matter of hours or days. Everyone’s going to take their time to process whatever news you’re processing. It’s also incredibly powerful to reflect on that worst-case scenario, and figure out what you would do. What would I do if I lost my job tomorrow? Once you’ve written down what your plan would be, you can stop worrying about it. You’re like, if I get laid off tomorrow, this is my plan, this is what I’m going to do. It takes the power away from it. Also, as a manager, it’s really important that you have a safe space to vent. Your words have a lot more impact on your team.

Be really mindful about how you share your stress and anxiety, and who you share it with. This is one of the areas which is terribly conflicting because I’ve just said, make it ok not to be ok, but not for you. You’re the manager. Just be really mindful about that. Be mindful about maybe bleeding your own stress and anxiety into your team because they’ll take their cues from you and how you’re feeling, and you could make a bad situation worse.

Power

I want to talk about power, the power that we have and how we can be intentional about how we use that power as managers. A great manager can genuinely change your life. I’ve talked about equity and inclusion, because it’s something I care deeply about. I wasn’t always active in pursuit of those goals. I was passive. I would say things like, “I’m not racist,” but I wasn’t actively doing anything to combat racism. I would say, “I’m definitely not sexist,” but I wasn’t doing anything to help the women in my organization. I’m going to share a quote with you that changed how I think about going from passive to active in my pursuit of diversity, equity, and inclusion. This is a quote by Banksy that was shared shortly after the murder of George Floyd. “At first I thought I should just shut up and listen to black people about this issue.

Why would I do that? It’s not their problem. It’s mine. People of color are being failed by the system. The white system. Like a broken pipe flooding the apartment of the people living downstairs. This faulty system is making their lives a misery, but it’s not their job to fix it. They can’t, no one will let them in the apartment upstairs. This is a white problem. If white people don’t fix it, someone will have to come upstairs and kick the door in.” The leaky pipe flooding the apartment downstairs is such a simple and powerful metaphor for me. It was genuinely one of those light bulb moments.

Life is simply harder in the apartment downstairs. Life is easier in the apartment upstairs. I know that I have privilege as a white person, as a British person, as a person from a loving, stable family. I also know that I’m a minority. I’m a woman trying to succeed in a man’s world. Racism is a white problem to fix. Sexism is a man’s problem to fix. Homophobia is a straight problem to fix. Are you sat in the apartment upstairs, and are you ignoring that leaky pipe, or are you trying to fix it?

With whatever privilege and power that I have, I choose to do something. I choose to try and make things easier for people who through no fault of their own, have less power than I do. There are really simple ways that you can be active about this in your work life. I’m not talking about doing big things. You don’t have to stand up on a stage and talk about it. As a woman, I will get interrupted really frequently. This is a thing that a lot of women will experience in the workplace, we get interrupted. When a woman in your team is interrupted, what will you do? Will you say something? Will you direct the conversation back to her so she has an equal voice?

Also, as women, we take on a disproportionate amount of menial work. It’s often assumed that the woman in the room will schedule the meeting, or take the meeting notes, or organize the team social, and do a lot of the facilitation and peacekeeping that make this a great team to be on. As a manager, will you make sure that that menial work is distributed equally between the men and the women in your team? Perhaps there are no gay people in your organization, and someone’s made a homophobic joke. Is it still a problem if there’s no one in the room to get offended? Will you say something, or will you let it go? Although these sound like small things, I want to remind you that in those moments, it’s so tempting and it’s so easy to do absolutely nothing, to be passive.

This is the difference between being active in pursuit of the things that you care about, and being passive. That leaky pipe will never get fixed if the people in the apartment upstairs continue to do nothing. Here’s the thought I want to leave with you, “Perhaps the measure of a manager is what they do with power.” What will you try to change?

See more presentations with transcripts

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Presentation: Being a Bad Influence – The Dangerous Dichotomies of People Management

MMS Founder
MMS Hannah Foxwell

Article originally posted on InfoQ. Visit InfoQ

Transcript

Foxwell: I am going to talk about being a bad influence. Most days, I think I’m a pretty good manager, but I know that I’ve made mistakes. I know that I can be a bad influence. I’m going to share some of those mistakes with you. This is a very personal talk. I’m going to share some of the things I’ve learned from the mistakes I’ve made, in the hope that my lessons learned will help you do better as a people manager.

Learning how to manage people is by far the most difficult, and also the most rewarding part of the work that I do. Sometimes the hardest things are the ones that are most worth doing. We don’t have enough time to talk about absolutely everything you need to know to be a good people manager. I filtered it down, and I’ve decided to talk about the really difficult stuff. The really hard stuff that we don’t talk about very often. The really hard stuff that makes the biggest difference.

I’m going to give you a quick overview just to set your expectations about the type of things that I won’t be talking about. I’m not going to be talking about hiring or interviewing, and how you do that. There’s lots of other talks on those topics. I’m not going to be talking about how you do a good one-to-one with your direct reports, or even how to run a team meeting. I’m also not even going to touch on how we get shit done. How do we do delivery management as managers? I’m not going to talk about org design either. The things that I’m going to cover, again, are the areas where my first attempts to do these things have been wrong.

I’ve learned some lessons. I’m going to talk about my understanding of the job of a manager. I’m going to talk about how to build inclusive teams. I’m going to talk about equality, equity, and equal opportunities for everyone in your teams, and how you make that happen in a practical way. I’m going to talk about money. We don’t talk about money often enough, I don’t think. I’m going to talk about the reality of performance, pay, and promotions. I’m also going to talk about what it’s like to be a manager on a really bad day. I’ve been through two rounds of layoffs in the past 18 months. We are having to manage through a lot of really bad days at the moment. I’m going to share my experience and some of my advice of how to do that well.

The Job of a Manager

I’m going to start with a relatively easy topic, what is the job of a manager? I’m going to start by talking about your three teams, as a manager. When you’re an individual contributor, your role is usually relatively well defined. You understand the expectations of you. Your manager deals with a lot, if not all of the stuff that’s happening outside of your team. What you see from your manager is very finite. You see the activities your manager is doing in order to manage your team successfully. You might not necessarily see the other work your manager is doing.

When I started managing people, this is what I did. I said, I am managing this team and this is my priority, and this is all that I care about. Actually, to be a successful manager you have to do an awful lot more than that. Your second team is your leadership team. If you are one of those people here who’s a manager of managers, you want to build a really cohesive leadership team because together you are better, together you are stronger, together you are more effective. I’ve seen it happen so often that actually the channels of communication through the organization follow the org design.

Communication flows top to bottom, and there’s not enough of this collaboration at a team level. A really cohesive leadership team that works well together will make a huge difference for the teams that report into them. Think to yourself, actually, am I a part of a leadership team, or do I just share a manager with these other people? If you just feel like you share a manager with these other people, why not try and build those bridges? Why not ask them to partner with you? Why not try and uncover some of the shared problems that you’re all experiencing, and try and build that sense of team and that shared ownership in your leadership team?

Of course, there are other people involved in getting work done. This is the only bit of the talk where I will talk about how we get shit done. Because, quite often, if you’re engineering or if you’re in engineering leadership, you will have peers in product, in product leadership. You’ll have peers in design. You might have peers in infrastructure. We rarely get things done in isolation, we have to act as a team. Actually, for the most part, I don’t see these groups of people behaving as a cohesive team towards a common goal. That’s a problem. That creates a problem for their teams who have misaligned expectations. That creates friction. That creates conflict.

It creates a bad atmosphere in terms of the blame game, “My team did everything they were supposed to do. It was your team that missed the deadline.” It’s just not helpful for anyone. I’ve heard this talked about in terms of stakeholder management, or how you build your network, and who are your allies. It’s much more simple than that. These are your team. This is a team of people who need to work together to get something done. If that group of people isn’t behaving as a team, you’re going to have problems in delivery. These are the three teams that I try to build when I take on a new management role. I know, it’s easy almost to find out and figure out who your team is, who report to you, and how to lead them effectively. It’s sometimes worth investing in building a more cohesive leadership team. It is very often neglected to build that team spirit with your peers in other areas of the business.

I really highly recommend, “The Five Dysfunctions of a Team.” This is the book that actually gave me that light bulb moment of realizing that I was thinking about my team all wrong. “The Five Dysfunctions of a Team,” says that the absence of trust is the number one dysfunction. It also says that that group of peers, that leadership team is your first team. That’s your priority, actually.

That’s where you should be spending a lot of your time. Behaving as though your team of direct reports is your one and only team is actually a dysfunction. This was the book that gave me that light bulb moment that made me see that my job as a manager wasn’t just my team, get things done, and not taking responsibility of everything that was happening around us.

To summarize, hopefully, this is a really practical thing you can take away from here. Reflect on those three teams, in your context. Who are on those teams? Are you acting as a team, the people you manage, your leadership team, and your group of peers? Common mistakes I’ve seen people make are neglecting those second and third teams that can lead to office politics and the blame game, “It’s not my fault. It’s your fault.”

Actually, we should be working together, we’ve got a common goal. Another thing that can happen is you can take it too far. If you have a very tight leadership team, it can sometimes feel like a bit of an exclusive club. Have a think about who you might be unintentionally excluding. I’ve seen a lot of organizations where people like customer support aren’t in the room. They aren’t in the room to help inform decision making. I’ve seen other organizations where design is neglected and product act as the interface into design. How can you bring people together towards that shared goal that you have?

Inclusive Teams

I’m going to move on to my next topic now, and my next light bulb moment as a people manager. I’m going to take a little detour and tell you a story about a work night out in Austin, Texas. We were in Austin, Texas, and there’s this really infamous party street called Sixth Street. They are really generous with the bourbon. I’m having a great time. I’m wearing my new cowboy boots. I’m catching up with lots of people. I’m drinking all of the bourbon, all of it, so much bourbon. Those cowboy boots, they were really slippery. Those cocktails were really slippery, and I fell over. I fell over on a work night out. I fell over on a work night out because I drank way too much.

This is a picture of me from the emergency room where I had to get a CT scan and five stitches on my lip. There is an important message behind this story. Getting drunk isn’t a team building activity. Alcohol is fine in moderation at social events, but it’s not the social event. This was a mistake I made time and again when I first started managing teams in my 20s, because I wanted to have team building activities that I thought were an awesome and great time. I wanted everybody to come into central London and go on a big night out with me. That’s what I wanted. I can see now how problematic that was. How I was accidentally excluding people whose idea of a good time was absolutely the opposite of going on a rampage with Hannah Foxwell.

That’s the lesson I learned about building inclusive teams and inclusive team building activities. It’s got to be fun for everyone. Now I’ve changed my approach. It should be fun for people who don’t drink. It should be in working hours wherever possible. I actually took a team out for a meal. This was a customer I was working with at the time when I was consulting. I took a team out for a meal and I let the sales guy book the restaurant. We took a vegan engineer to the best steak restaurant in town. These are really easy things to get right, and so often, we get it so wrong. How did that person feel a team building dinner that was supposed to be a celebration of what we’d done together, and there was nothing on the menu that they could eat?

I learned these lessons, not as a manager. My managers have never taught me about this. I learned these lessons by being a conference organizer. I’m one of the organizers at DevOpsDays London. We put a lot of effort into creating an inclusive and accessible event, or a nonprofit event, and so we think it’s really important that we run an event that’s for the benefit of the community. We try to remove all of the barriers that we possibly can for everybody to participate in that community should they want to. We’ve been doing this since 2017.

I’m really thrilled to see so many conferences now are following our example, and they’re adopting some of these more inclusive and accessible practices. This is taken directly from the welcome talk that I gave at DevOpsDays London. These are some of the ways that we try to create an inclusive and accessible space for the community. You can imagine using the same mindset at work, how am I going to create an inclusive and accessible environment for my team to do their best work?

Some of the mistakes I’ve made as a manager reveal some of my blind spots, and some of these things that you just learn through experience and you get better, and I hope that I have. To create an inclusive team, I always try to make sure that everybody has a voice. I make sure that team building activities are things that everyone can enjoy. More importantly than that, I try to create enough unstructured social time that team building just happens organically within the team.

Sometimes team meetings can be overly formal. Where is that unstructured time? Where are the team talking to each other about things that matter outside of work? Common mistakes I see people make as I did when I was starting to manage people is imposing your own preferences, likes and dislikes on your team. Having team building events outside of working hours, which really excludes people who maybe have young children or have caring responsibilities at home with their family, or even traveling greater distances. You’re accidentally excluding people by taking events outside of working hours. Also, it’s easy to bias towards the needs of the majority. Maybe you only have one vegan on your team. It’s like, they’ll be fine. Maybe you only have a small number of women on your team. Maybe you only have one person who doesn’t drink. I still believe that the best team building events are ones where everyone can enjoy them equally.

Equity and Equal Opportunities

I’ve talked about inclusion. I’m about to talk about equity. This isn’t a talk about DEI, diversity, equity, and inclusion. This is a talk about managing people. I’ve talked about inclusion because as a manager, I think it’s my job to make sure that nobody in my team feels excluded. I’m going to talk about equity, because as a manager, I think it’s my job to make sure everyone in my team has an equal opportunity to succeed in their career. For me, equity is at the core of people management. Equality is treating everyone the same but equity is taking differences into account so everyone has a chance to succeed.

This is an everyday practice. This isn’t some special initiative. This is about acknowledging where your direct reports are at in their life and in their careers, and adjusting your management style and your techniques and your practices to what that person needs at this moment in time. This is how you make sure everyone has a chance to succeed. Again, when I started managing people, I had blind spots. This is another story about Hannah sat in a bar, unfortunately. I was at an off-site. I was the last person in the hotel bar at 9 p.m., and I couldn’t understand it.

I was like, where is everybody? Where are the expenses? Can we have a couple of cocktails, maybe? Actually, everybody I was with had young children at home. The idea of going to bed at 9 p.m. for them was absolutely luxurious, and that’s what they did. They left me on my own in a hotel bar. That was a blind spot that I had earlier in my career about what the reality for parents was at work.

This is a visualization of a baby’s sleeping patterns for the first year of their life. It’s absolutely brutal. This is what the reality of home life might look like for the new parents, who you manage. As a manager, if your team get woken up in the middle of the night by PagerDuty, I bet you have processes and practices and policies around recovery time. I bet you have awareness of who in your team have been disturbed during the night, and you would be inquiring with them to see if they’re ok. There’s a lot of other reasons that people might be waking up during the night, and you are blind to them, for the most part, as a manager.

One of my colleagues once said to me, having kids is basically like giving up sleep for 5 years. I was like, don’t be silly. Then my sister had some kids, and I met some babies. They’re really difficult. Babies are hard. Indirectly, my niece and my nephew have taught me some really important lessons about managing new parents. Unfortunately, I can’t talk about managing new mothers, because I haven’t had that opportunity in my career, but I have managed a lot of new fathers. What I always try to make sure I do is to make sure that they are able to participate in their home life. Personally, I do not like this idea that mom is always doing the night shift because dad has to log in and work 8 hours tomorrow morning. That’s something that bothers me. I want to make sure that the people in my team can show up for their family whenever their family need them.

Although I can’t influence the paternity leave policies, or at least I can try to, what I can do is I can be flexible. I can have awareness. I can be kind. I can make sure that project assignments and expectations of new parents and working hours are as flexible as possible knowing that not every day will be the same. I can have conversations at the start of potentially a high-pressure project about whether this person feels like it might impact their home life or whether or not they would like to take on a different role on the project than maybe what they normally would.

Working at home has obviously made a huge difference to so many of us. The blurring of the boundaries between our home lives and our family lives and our work lives is brilliant. In the teams that I manage, I celebrate every time a baby or a child shows up at one of our team meetings. I absolutely love it, because they should be there. They are welcome. As long as it’s the right balance for you in your home life, taking a call with your baby on your lap is absolutely fine. I welcome that.

Here’s the other graph. This one is a proper horror story for anyone who’s experienced it. Anyone know what it is? I’ll give you a clue with my next story. I’m going to call this, Hannah’s years of denial, because this is what I used to say, “I’m not a woman in tech. I don’t want to be treated differently. I’m just a person in tech.” My eyes were closed for a long time to the ways in which my gender would influence and shape my career prospects in tech, as a member of a minority. That’s what this is. It’s a menstrual cycle, of course. Unfortunately, it’s an incredibly taboo subject. This is the reality. This is the monthly roller coaster that some of us are on.

I think it’s really important. I know that I have very open conversations about women’s health issues, fertility, family planning with the women that I manage, but I don’t think it’s as common with the men. I definitely don’t see it happening when I have male managers. I think just acknowledging that there are days where there will be physical symptoms from this hormonal roller coaster that a lot of us are going on is really important. If you haven’t educated yourself on what that looks like, maybe read a few blog posts and find out. I am not saying that you go into your one-to-one and you say, “Hannah, you seem a little bit overwhelmed today. Is it that time of the month?” Don’t do that. Having an awareness that there will be really bad days is useful information to have. You can be flexible, and you can be kind. You can think about how you build an environment where those things matter less.

A recent study found that one of the key reasons that women don’t advance as far in their careers as men is a lack of sponsorship. This is one of those unconscious biases that once someone pointed out to you, you start to see it everywhere. Women are over-mentored and under-sponsored. This leads me really nicely in to talk about how you adjust your management style to the needs of the person that you’re managing. Mentoring, coaching, and sponsorship, they are not the same. I’ll talk about the differences between them.

When you go back into the office, have a think about what your direct reports need from you. Do they need a mentor? Someone who supports you in learning new skills by sharing their knowledge and advice. Or, do they need a coach? Do they need someone who’s going to teach them new skills by helping them think through solutions by themselves, asking good questions, allowing the person to find the answer on their own in their own time? Or, do you need a sponsor? Do you need someone who supports you in learning new skills by creating opportunities for you to do new things? Someone who’s going to trust that you can do something that you’ve never done before. This is so important to people’s careers. That moment that someone decides to trust you to accelerate your career, to let you do something that you’ve not done before so that you can learn how to do it well.

I recently had the privilege of sponsoring a young woman into her first management position. I was told by her current manager that she wasn’t ready, that she hadn’t had enough years of experience under her belt. I said, I started managing people at this age, and I did all right. I was like, “I’m plus, like I’m here. I’m going to make sure that she’s successful.” I did that. I created an opportunity for her to do something that her current manager wasn’t allowing her to do, because he thought she needed more years of experience as an individual contributor to do it well.

You can probably guess where this story ends. She absolutely smashed it. I’m so happy that I was able to do that for her. I’m so grateful for all of the people throughout my career who have done that for me, who have been sponsors for me. When you’re thinking about your direct reports, and what help they need, think about whether they need you to be their mentor, their coach, or their sponsor, and adjust your approach accordingly. Because, as I said at the beginning of this section, the right answer isn’t to treat everybody exactly the same. Equality is not the same as equity. We want to create an environment where everyone has an equal opportunity to succeed. Everyone’s definition of success will be different. The help you need to provide to get them there will be different.

Striving for equity means that you need to understand the different needs of each person, understand their personal goals and aspirations. Then adjust and understand what support they need right now at this moment in time in their career to get them there. It’s also really important to challenge your own biases, because as we’ve seen, some of these unconscious biases towards women can mean that we are over-mentored and under-sponsored in a work context.

Common mistakes when striving for equality and treating everybody exactly the same, means that you might have an unintended impact on their home life. Someone might not be able to give you 150% right now, like the other members of the team. It can result in a lack of stretch goals and growth opportunities for your high performers. It can lead to attrition. In a worst-case scenario, if you’re not really consciously matching the work with the person and their current situation, it can lead to stress and burnout. You don’t necessarily want to throw somebody overboard and see if they swim. You need to provide the right support when you’re giving people new challenges and stretch opportunities. Be really mindful about the right opportunity for that person at that moment in time in the context of their career, and in their life.

Performance, Pay, and Promotions

Next, I’m going to talk about the vulgar topic of money, because again, it’s an area where equality isn’t always the right answer. I’m going to be trying to be as generic as possible about this. I’ve worked in moderate to large companies for a while, and so I’m trying to generalize based on my experience of how pay and promotions happen. If you’re in a very small company, it’s likely to look very different. When I started managing people, no one sat me down and explained it. No one sat me down and explained how pay and promotions actually worked in the real world. It was all done behind closed doors.

I learned through experience how to run this process and how to run this process well. What will usually happen is, once or twice a year, there will be budget set aside to allocate to pay rises and promotions. The budgets will be agreed right at the top of the company, and then it will be chopped up, and they will cascade down through the org chart. Your VP will have a big pot of money. They’ll take a little bit to the side for their management team. Then they will allocate budgets to each of their leaders. Those leaders will do the same with their leaders. Then they will do it for their managers.

Those budgets will cascade top-down. Then, managers of individual contributors will make recommendations about what they think their team deserve. The problem with this process is that talent isn’t always evenly distributed across the teams. When budget is equally distributed across the teams, you need to do a secondary step to this process, you need to do the rebalancing and the calibration. This can’t happen unless you’re working really closely with your peers. That’s why I talked about team 2 at the beginning of this talk because you all need to be aligned. You need to be aligned about what a senior engineer looks like in your organization. Because if a manager is imposing their own personal opinions on what a senior engineer looks like, if one manager is setting the bar up here, and the people who report to them aren’t getting promoted as quickly as the people over here, you’ve got inequality, and that’s not ok.

As an individual contributor, you won’t see any of this process, but as a manager you may not see any of this process either, because you might not actually be talking about it. What I would encourage you to do is talk about it. You need to be working with your leadership team and your peers to make sure that the budgets are allocated to the right people based on the impact that they have on the organization, but also about the potential they’re showing for growth.

This is something that I see go wrong time and again, because managers believe that once they have their budget, they don’t want to release a single penny of it, even if it’s the right thing to do. Even if there are three people who are deserving or that need promoting in team 1, no one will release their budget to make sure that they do the right thing for the people who are ready for promotion. They will use up their budget on the team that they have reporting to them. I don’t think that’s fair. I don’t think that’s right. I think a collaborative process is much more effective to get the result you want.

Another thing that you’re going to want to do is check for systemic inequality and biases. We all know that minorities will be generally paid less. Because of the various barriers to entry in our industry, they might have less years of experience, they might have been held back from promotions due to biases. You may need to correct for some of the wrongs that were done to these people earlier in their career. This has happened. If you take on a new team, and you stack rank them by salary, and you find that all the women are at the bottom, you’ve got a problem. It’s this process that allows you to correct for that.

Again, because I would always encourage a collaborative process as part of your leadership team to make sure that you’re being fair and consistent across everybody who has the same role and job, use that opportunity to check that other people are doing these checks and balances as well. Another aspect of this is obviously the individual themselves. When I was a new manager, nobody explained to me how pay and promotion works, and how to do it well. No one taught me that. I think there’s an amount of knowledge that you need as an individual contributor as well.

At the very least, you need to know what the timeline is. It’s no good going to your manager in August and saying, I’d like a promotion in the next round, if in July, all of the promotion recommendations have already been submitted and the budgets have been allocated. Timing is everything. You have to have the right conversations with your team at the right time. If you don’t know the rules of the game, you’re not going to be able to play the game. Being open and transparent about how decisions get made, who the decisionmakers are, what people are looking for and assessing for in these promotion conversations, and how to set yourself up for success, is incredibly valuable. Be transparent about it. There’s absolutely no reason not to be. This is a reality, and it doesn’t have to happen behind closed doors.

As I said, there’s nothing worse than getting to the end of a process for pay rises and promotions and having a very upset employee on your hands because they didn’t get what they expected. If you end up in that situation, chances are, you haven’t asked them what they expected, or they didn’t know that the time to have those conversations was probably weeks ago and not today, in this room. The decision’s already been made.

Again, as I said about that transparency, if you have someone who is expecting a promotion, be really transparent with them about their chances of success in getting that promotion as well. To manage their expectations, you first need to know their expectations. You do this not in an annual process. If you’re only doing this once a year, you’re getting it wrong. You’re going to be providing them with continuous feedback. You’re going to be encouraging them to continuously improve. You’re going to be really aligned on expectations.

I will put you forward for promotion in 6 months’ time, but I don’t think you’ve got a high chance of success now, so I won’t be putting you forward this time. You can have that conversation. It’s not an easy conversation, but you can have that conversation. It avoids some of that upset that happens when someone’s expectations are up here and you have to deliver bad news, or you have to deliver bad news that you didn’t expect was bad news. One of the things that I tell all of my teams, is that everyone’s career path is different, and so you shouldn’t try and compare yourself to others.

Figure out who you are, and then do it on purpose. When we’re talking about continuous feedback, make sure you really understand the strengths and weaknesses of the person you’re managing, and build a plan to get to that promotion with them, that plays to their strengths. Don’t throw them into a situation where you’re going to reveal all of their weaknesses. Absolutely customize it and play to their strengths. Figure out who they are, and help them to do more of that.

One of the things that I’ve found through managing people, is, quite often, the things that make us stand out, are the things that make us stand out. Sometimes your greatest strength, the things that makes you amazing, can also manifest as your greatest weakness. To give an example about myself. Some of the feedback I was given early in my career was, “I’m a bit silly. I can be a bit too fun. I don’t take things too seriously.” In the same breath, someone would say, “You bring great energy for the team. I love how fun it is to work in your team.” I think sometimes you have to take feedback in that context.

You have to think, these are the things that stand out about me, how can I get myself into a situation where this is considered a strength, and it’s not a weakness? In those situations where I need to adjust and I need to adapt, how do I make sure that I’m mindful of the ways that I stand out and the ways that I am different? How can I make sure that it’s not perceived as a weakness? Because treating everyone the same is impossible, because we are all gloriously different human beings. We’re not striving for equality in a pay, performance, and review process. We are striving for equity. We are striving to build an environment and a team where everyone has an equal chance of success, and that will look different for every single person.

To summarize some of my lessons learned about running multiple pay promotion and performance management processes. I reward based on impact. I reward people who make those around them better, who share their knowledge, and who are team players. I also reward for potential, people who I want to see grow in the team, people I want to keep around. I am transparent with the timetable, and I share it with everyone including individual contributors.

Performance management doesn’t happen as part of a formal process once or twice a year. It’s continuously managed, and you continuously manage expectations throughout that process as well. Also, if you can, seek to match the person and the job. Figure out who you are, and do it on purpose, with the help of your manager who can create opportunities that are right for you. They may not be right for everyone. Common mistakes I’ve seen in these processes is where decision making happens behind closed doors or by a single person, maybe a senior manager, and not even the managers who report to them.

When that happens, there’s very little chance for collaboration or consistency or rebalancing in the process. When it happens behind closed doors, there’s little opportunity to challenge for systemic bias and inequality that is not related to the person’s performance. One of the other mistakes that you can make is actually just trying to reward employees equally in the pursuit of fairness. One of my old managers called that peanut butter spreading. “We just chop up the budget and share it equally because that’s the right thing to do.” It’s very rarely the right thing to do. Also, during performance review processes, it’s really easy to focus on people’s weaknesses. Try to remember that the weaknesses might actually just be different manifestations of this person’s strength. Figure out what those strengths are and find a way to use them.

The Bad Days

I’ve been through two rounds of layoffs recently as a manager. Those are bad days. Those are really horrible bad days. I’ve been through acquisitions. Those can also be really difficult emotional days if the acquisition is not something your team wants, or if they’re worried about how the acquisition might impact you. Even things like reorgs can create anxiety within your team, and uncertainty. I’m going to talk very briefly about what your role as a manager might look like, on those very bad days. I’ve had Barbra Streisand. I’ve had Dolly Parton. Now I’ve got Rihanna. All thought leaders.

I think the most important piece of advice I can give you about the bad days is, just be present. Be present for your team. Make it ok not to be ok. What I’ve done in the past, even though I’ve been upset, and I’ve been angry, and I’ve been worried during these times, is I’ve just tried to create a space where we can be together and feel all those feelings and talk about it. I absolutely make sure the team know that today is just not a day to keep calm and carry on. It’s ok. If you need to take a break from your desk, if you need to log off for a while to process this news, or if you want to be together, here’s a Zoom that I’m going to open up and we can just use it as a drop-in for today. We can just drop in and be together and share these feelings and these thoughts and these worries, and do it together.

Unfortunately, we have to be that shit umbrella, quite often. It’s really difficult because during these bad days, there’s often ambiguity, there’s often uncertainty. You can’t share answers with your team, because the answers simply don’t exist yet. Decisions haven’t been made. It’s really difficult to be in that room, as the leader and the representative of the company with absolutely no information. It’s really hard. All you can do is to be authentic, and to be honest about what is going on, what you know.

You can try to discourage gossiping. You can try and discourage people from catastrophizing the event. In reality, you’re going through this with them. My only piece of advice there that I have found works for me is just to literally be there, go through it with them. Another thing that is slightly more structured, and I’ve used this during acquisitions and reorgs and times of big change, is just create space to voice all your irrational fears. Throw an anxiety party. Just be like, we’re just going to spend half an hour right now just venting.

We’re just going to do that. This is the time where we’re going to vent. We all know. We’re all smart people, we’re going to rationalize some of these fears away. For just a moment, we’re going to voice that fear, and we’re going to point at it, and we’re going to look at it. I find that a really powerful activity to do as a group during times of large change and uncertainty.

On those bad days, what advice can I give you? Just make it ok not to be ok. Create space to share your thoughts and feelings, however raw they may be. Be patient. No one is going to bounce back in a matter of hours or days. Everyone’s going to take their time to process whatever news you’re processing. It’s also incredibly powerful to reflect on that worst-case scenario, and figure out what you would do. What would I do if I lost my job tomorrow? Once you’ve written down what your plan would be, you can stop worrying about it. You’re like, if I get laid off tomorrow, this is my plan, this is what I’m going to do. It takes the power away from it. Also, as a manager, it’s really important that you have a safe space to vent. Your words have a lot more impact on your team.

Be really mindful about how you share your stress and anxiety, and who you share it with. This is one of the areas which is terribly conflicting because I’ve just said, make it ok not to be ok, but not for you. You’re the manager. Just be really mindful about that. Be mindful about maybe bleeding your own stress and anxiety into your team because they’ll take their cues from you and how you’re feeling, and you could make a bad situation worse.

Power

I want to talk about power, the power that we have and how we can be intentional about how we use that power as managers. A great manager can genuinely change your life. I’ve talked about equity and inclusion, because it’s something I care deeply about. I wasn’t always active in pursuit of those goals. I was passive. I would say things like, “I’m not racist,” but I wasn’t actively doing anything to combat racism. I would say, “I’m definitely not sexist,” but I wasn’t doing anything to help the women in my organization. I’m going to share a quote with you that changed how I think about going from passive to active in my pursuit of diversity, equity, and inclusion. This is a quote by Banksy that was shared shortly after the murder of George Floyd. “At first I thought I should just shut up and listen to black people about this issue.

Why would I do that? It’s not their problem. It’s mine. People of color are being failed by the system. The white system. Like a broken pipe flooding the apartment of the people living downstairs. This faulty system is making their lives a misery, but it’s not their job to fix it. They can’t, no one will let them in the apartment upstairs. This is a white problem. If white people don’t fix it, someone will have to come upstairs and kick the door in.” The leaky pipe flooding the apartment downstairs is such a simple and powerful metaphor for me. It was genuinely one of those light bulb moments.

Life is simply harder in the apartment downstairs. Life is easier in the apartment upstairs. I know that I have privilege as a white person, as a British person, as a person from a loving, stable family. I also know that I’m a minority. I’m a woman trying to succeed in a man’s world. Racism is a white problem to fix. Sexism is a man’s problem to fix. Homophobia is a straight problem to fix. Are you sat in the apartment upstairs, and are you ignoring that leaky pipe, or are you trying to fix it?

With whatever privilege and power that I have, I choose to do something. I choose to try and make things easier for people who through no fault of their own, have less power than I do. There are really simple ways that you can be active about this in your work life. I’m not talking about doing big things. You don’t have to stand up on a stage and talk about it. As a woman, I will get interrupted really frequently. This is a thing that a lot of women will experience in the workplace, we get interrupted. When a woman in your team is interrupted, what will you do? Will you say something? Will you direct the conversation back to her so she has an equal voice?

Also, as women, we take on a disproportionate amount of menial work. It’s often assumed that the woman in the room will schedule the meeting, or take the meeting notes, or organize the team social, and do a lot of the facilitation and peacekeeping that make this a great team to be on. As a manager, will you make sure that that menial work is distributed equally between the men and the women in your team? Perhaps there are no gay people in your organization, and someone’s made a homophobic joke. Is it still a problem if there’s no one in the room to get offended? Will you say something, or will you let it go? Although these sound like small things, I want to remind you that in those moments, it’s so tempting and it’s so easy to do absolutely nothing, to be passive.

This is the difference between being active in pursuit of the things that you care about, and being passive. That leaky pipe will never get fixed if the people in the apartment upstairs continue to do nothing. Here’s the thought I want to leave with you, “Perhaps the measure of a manager is what they do with power.” What will you try to change?

See more presentations with transcripts

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Alibaba Releases Two Open-Weight Language Models for Math and Voice Chat

MMS Founder
MMS Anthony Alford

Article originally posted on InfoQ. Visit InfoQ

Alibaba released two open-weight language model families: Qwen2-Math, a series of LLMs tuned for solving mathematical problems; and Qwen2-Audio, a family of multi-modal LLMs that can accept voice or text input. Both families are based on Alibaba’s Qwen2 LLM series, and all but the largest version of Qwen2-Math are available under the Apache 2.0 license.

Qwen2-Math is available in a base version and an instruction-tuned version, each with a choice of 1.5B, 7B, or 72B parameters. Because most benchmark datasets are available on the internet, Alibaba conducted decontamination on their training datasets to remove mathematical problem-solving benchmark examples. After pre-training, the instruction-tuned models were trained with both supervised fine-tuning and reinforcement learning. On the popular MATH benchmark, the largest model, Qwen2-Math-72B-Instruct, outperformed state-of-the-art commercial models including GPT-4o and Claude-3.5-Sonnet. According to Alibaba,

Given the current limitation of English-only support, we plan to release bilingual models that support both English and Chinese shortly, with the development of multilingual models also in the pipeline. Moreover, we will continue to enhance our models’ ability to solve complex and challenging mathematical problems.

Besides MATH, Alibaba evaluated Qwen2-Math on benchmarks and mathematics exams, such as GSM8K and AIME 2024. They found that Qwen2-Math-Instruct had better performance than other baseline models of comparable size, “particularly in the 1.5B and 7B models.” The 72B parameter version achieved a score of 86.4 on the Chinese-language math exam benchmark CMATH, which Alibaba claims is a new high score. They also claim that it outperformed Claude, GPT-4, and Gemini on the AIME 2024 exam.

Alibaba published a technical report with more details on Qwen2-Audio. The model accepts both text and audio input, but can only output text. Depending on the type of audio input provided, the model can operate in two modes, Voice Chat or Audio Analysis. In Voice Chat mode, the input is a user’s speech audio, and the model acts as a chatbot. In Audio Analysis mode, the model can answer questions about the content of audio input. For example, given a clip of music, the model can identify the tempo and key of the song.

Andrew Ng’s newsletter The Batch covered Alibaba’s release, saying:

Qwen2 delivered extraordinary performance with open weights, putting Alibaba on the map of [LLMs]. These specialized additions to the family push forward math performance and audio integration in AI while delivering state-of-the-art models into the hands of more developers. It’s thrilling to see models with open weights that outperform proprietary models. The white-hot competition between open and closed technology is good for everyone!

Users on Reddit discussed both model series. One user described Qwen2-Math-7B as “punching really high and hard for its size.” Another user said of Qwen2-Audio:

It would be very interesting to try to synthesize audio output using this model. The audio encoder is almost identical to WhisperSpeech one. Although Qwen2 is using Whisper-large-v3 which would probably require retraining of the WhisperSpeech acoustic model. If successful, that would be basically equivalent to GPT4o advanced voice mode running locally.

The model files for Qwen2-Math and Qwen2-Audio can be downloaded from Huggingface.

About the Author

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Alibaba Releases Two Open-Weight Language Models for Math and Voice Chat

MMS Founder
MMS Anthony Alford

Article originally posted on InfoQ. Visit InfoQ

Alibaba released two open-weight language model families: Qwen2-Math, a series of LLMs tuned for solving mathematical problems; and Qwen2-Audio, a family of multi-modal LLMs that can accept voice or text input. Both families are based on Alibaba’s Qwen2 LLM series, and all but the largest version of Qwen2-Math are available under the Apache 2.0 license.

Qwen2-Math is available in a base version and an instruction-tuned version, each with a choice of 1.5B, 7B, or 72B parameters. Because most benchmark datasets are available on the internet, Alibaba conducted decontamination on their training datasets to remove mathematical problem-solving benchmark examples. After pre-training, the instruction-tuned models were trained with both supervised fine-tuning and reinforcement learning. On the popular MATH benchmark, the largest model, Qwen2-Math-72B-Instruct, outperformed state-of-the-art commercial models including GPT-4o and Claude-3.5-Sonnet. According to Alibaba,

Given the current limitation of English-only support, we plan to release bilingual models that support both English and Chinese shortly, with the development of multilingual models also in the pipeline. Moreover, we will continue to enhance our models’ ability to solve complex and challenging mathematical problems.

Besides MATH, Alibaba evaluated Qwen2-Math on benchmarks and mathematics exams, such as GSM8K and AIME 2024. They found that Qwen2-Math-Instruct had better performance than other baseline models of comparable size, “particularly in the 1.5B and 7B models.” The 72B parameter version achieved a score of 86.4 on the Chinese-language math exam benchmark CMATH, which Alibaba claims is a new high score. They also claim that it outperformed Claude, GPT-4, and Gemini on the AIME 2024 exam.

Alibaba published a technical report with more details on Qwen2-Audio. The model accepts both text and audio input, but can only output text. Depending on the type of audio input provided, the model can operate in two modes, Voice Chat or Audio Analysis. In Voice Chat mode, the input is a user’s speech audio, and the model acts as a chatbot. In Audio Analysis mode, the model can answer questions about the content of audio input. For example, given a clip of music, the model can identify the tempo and key of the song.

Andrew Ng’s newsletter The Batch covered Alibaba’s release, saying:

Qwen2 delivered extraordinary performance with open weights, putting Alibaba on the map of [LLMs]. These specialized additions to the family push forward math performance and audio integration in AI while delivering state-of-the-art models into the hands of more developers. It’s thrilling to see models with open weights that outperform proprietary models. The white-hot competition between open and closed technology is good for everyone!

Users on Reddit discussed both model series. One user described Qwen2-Math-7B as “punching really high and hard for its size.” Another user said of Qwen2-Audio:

It would be very interesting to try to synthesize audio output using this model. The audio encoder is almost identical to WhisperSpeech one. Although Qwen2 is using Whisper-large-v3 which would probably require retraining of the WhisperSpeech acoustic model. If successful, that would be basically equivalent to GPT4o advanced voice mode running locally.

The model files for Qwen2-Math and Qwen2-Audio can be downloaded from Huggingface.

About the Author

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Podcast: Lessons Learned From the CrowdStrike Incident: InfoQ Dev Summit Munich 2024 Preview

MMS Founder
MMS Renato Losio Danielle Sudai Santosh Yadav Mykhailo Brodskyi

Article originally posted on InfoQ. Visit InfoQ

Subscribe on:






InfoQ Dev Summit Munich 2024 Overview [00:05]

Renato Losio: Hello everyone, and welcome to the InfoQ Podcast. I’m Renato Losio, the chair of the upcoming InfoQ Dev Summit in Munich. It’s a new event, and if you’re looking to stay ahead on critical topics like generative AI, security, modern web applications, and more, we’ve got you covered. If you want to learn not just from our three amazing panelists today but from over 20 senior software practitioners with diverse experiences, backgrounds, and countries, join us in Munich! There will be plenty of time to connect with the speakers and your fellow practitioners. Last but not least, the end of September is Oktoberfest in Munich, so if you want to add a few days to enjoy the event, there’s that opportunity as well.

The InfoQ Dev Summit is a two-day event brought to you by the team behind InfoQ and QCon Software Development Conferences. You may already be familiar with QCon London and QCon San Francisco, but there are also two new events. The inaugural InfoQ Dev Summit in Boston took place in June, and the next one is Dev Summit Munich at the end of September (September 26th and 27th). I look forward to connecting with you in Munich this September. I hope to see you there!

Introduction to the Panel [01:20]

Renato Losio: Today, I have the pleasure of sitting down with a panel of three amazing speakers from different backgrounds and companies, all of whom will be speaking at the upcoming InfoQ Dev Summit in Munich. They are Danielle, Santosh, and Mykhailo. In just a moment, I’ll let the panelists introduce themselves, giving each one a minute to share who they are and what they do. Then we’ll launch into a conversation covering some of the critical technical decisions that senior software developers face today and that we’ll dig deeper into in Munich next month.

Specifically, we’re going to talk about resilience, automation, and security for your cloud and non-cloud deployments. Let’s go ahead and introduce our speakers. Danielle, do you want to go first?

Danielle Sudai: I can go first. Very nice to meet you. My name is Danielle Sudai. I’ve been the Security Operations Manager at Deliveroo for the past three years. In addition to managing talented teams and focusing on defending against real-time threats, I’ve also been working in DevSecOps for the last decade across various firms. My focus is on developing the detection and triage of the alerts we receive for real-time threats, based on our organizational vulnerability management.

Renato Losio: Thank you so much, Danielle. Santosh, do you want to go next?

Santosh Yadav: Nice to be here. My name is Santosh Yadav, and I live near Hamburg. I work as a Senior Software Engineer at Celonis, which is based in Munich, so I’ll get a chance to visit my employer after a long time. I mostly work with monorepo, and my team is responsible for managing the entire monorepo, which drives our main product at Celonis, Studio. We coordinate with nearly 40 teams contributing to the monorepo, ensuring it stays healthy, follows best practices, and incorporates new tools with POCs to make the teams’ lives easier, focusing on developer experience.

Apart from that, I’m part of multiple community programs and have contributed to open-source projects. I’m part of the Google Developer Expert (GDE) program for Angular, the GitHub Stars program, and the NX Champions program. You can find me at multiple conferences speaking about NX and Angular.

Renato Losio: Thank you so much, Santosh. And looking forward to meeting you in person in Munich. Mykhailo, you’re the last one.

Mykhailo Brodskyi: Hello everyone, my name is Mykhailo Brodskyi. I’m a Principal Software Architect based in Munich, working in the FinTech industry. Currently, I’m focused on defining the architecture strategy for our platform and am responsible for multiple business-critical projects. One of these projects is our cloud platform migration. I’m also a member of the Cyber and Risk Committees, where we’re responsible for enhancing the security of our platform and mitigating potential vulnerabilities across all our platforms and related applications.

Renato Losio: Thank you so much. We’re now going to talk a bit about resilience, automation, and security.

The CrowdStrike Incident  [04:44]

Of course, this is a bit of a special summer. So let’s start with a topic to trigger some discussion, one that we’re probably all familiar with, whether as travelers, IT experts, security experts, or automation experts. Many of us had the experience last month (well, hopefully not all of us) of being stuck in an airport with a blue screen, thinking that something went wrong. For one of the few times, an IT outage on a large scale made headlines on major news sites. That’s the day you realize something big went wrong. The first reaction is, “Ha-ha, that can happen just to them”. My second reaction is, “Oh, maybe that can happen to me”.

I don’t want to dig into what happened with CrowdStrike or what the implications were; I just want to use that example as a trigger for our discussion about resilience and risk—not necessarily about a global IT meltdown, but maybe just at the company level. How do we handle that? How do we manage automation and those processes? The very first question I have for you is: Were you surprised? What surprised you most about what happened? What do you think is the critical lesson we should learn to avoid saying, “That’s never going to happen to me”?

Santosh Yadav: First, I was surprised that something so big could happen. A company with billions in revenue is responsible for a global outage like this. I remember I was traveling that day—not at the airport, thankfully. I was traveling by train in Germany with Deutsche Bahn, which is never on time, so of course, it was delayed. Regardless of the global outage, I saw some travelers struggling because they were trying to buy food at Frankfurt Station, and their credit cards weren’t working.

People don’t realize that a small mistake can cause something so significant. For someone traveling internationally, not having a working credit card while trying to buy food is a big issue. I was really surprised that this happened. But I think the lesson for everyone is that no system is completely safe. We all make mistakes, but it’s everyone’s responsibility to ensure that the critical paths work. These are critical elements that can impact millions of systems and people. So that was my takeaway: Make sure your critical paths are taken care of.

Renato Losio: Thank you, Santosh. Danielle?

Danielle Sudai: To be honest, before becoming DevSecOps, I was in security IT. The shift to that role and the move to the cloud made me wonder what we are going to do with agent-based SaaS solutions when they impact infrastructure. When we say we are hybrid and moving to the cloud, it’s important to remember that these are other firms’ servers, which are not visible to us. Whenever there is an impact, it also affects our cloud vendors to some extent. What will happen if something agent-based impacts the actual infrastructure? What happens when the on-prem and cloud approaches clash?

I was slightly amazed—I don’t want to speak about the specific company outage because things like that can happen and there is no blame. However, I was surprised by the scope. The company itself is trusted and serves many vendors worldwide, and I think the impact was what surprised me. People may not have been fully conscious of zero trust, leading them to spread agents across all their endpoints or systems, which eventually contributed to the issue. They did this for a good reason, to protect the endpoint and ensure it signals back to their management framework, allowing them to understand what’s happening there.

It’s a bit of a chicken-and-egg situation. But yes, I was definitely surprised by the impact, especially in the U.S. That was crazy. I think it opened another area that isn’t classic security but more of an infrastructure issue, which is massively impactful. All of a sudden, we have to face that reality. It reveals a lot of things that our current platforms cannot solve. We must remember there is an on-prem component behind it.

Renato Losio: That’s an interesting point you made, Danielle. It’s a different security issue in the sense that it’s not a classic denial of service attack. It’s not someone who intentionally caused a denial of service. But in the end, there was a denial of service for the end users, for anyone impacted by the outage. Mykhailo, since you work in a strictly regulated financial industry, do you see anything different? Do you think there are any lessons to be learned? Or were you really surprised, or did you feel like, “Oh yes, I’m surprised that didn’t happen before”?

Mykhailo Brodskyi: Unfortunately, I was also surprised. Payment platforms were affected as well. For me, it wasn’t a shock, but it was a big surprise. In the FinTech industry, we have a huge set of regulations—internal, external, and even some specific to banking. Yet all these regulations didn’t help to avoid this situation. A big question is, how can we improve this? How can we prevent this situation in the future? I’ve had multiple conversations with different departments and applications involved in various payment platforms, and I can say that the deployment and testing approaches should be improved dramatically. That’s what I see.

The Importance of Alternative Solutions and Rollback [11:08]

Renato Losio: Thank you. That’s one point I’d like to come back to later—what we can do to improve. But even going back to the basics, one thing I noticed on my side as a “not expert” was the two entire trends in the very first few days. Apart from blaming the company and saying, “It’s not going to happen to me”, there were thoughts like, “How can they deploy that way while we’re the experts who don’t make those mistakes?” That’s a very risky approach. I’ve always found that attitude not just unfriendly, but also something I wouldn’t want to be in that position in the future, so I’d like to learn from them more than to really blame anyone.

On a practical level, two things happened that day. First, people tried to find different solutions. You could see people in the airport checking in with a piece of paper. On the other hand, people were trying to roll back, but they had no real rollback because we were in a scenario where rolling back was much harder than deploying. I was wondering about those two aspects: what we should do in our deployments to ensure we have a rollback plan. If I’m stuck in that moment, should I think more about a rollback plan, or should I focus on finding another way to bring back what Santosh defined earlier as our critical path and feature? I don’t know, Danielle, if you have any thoughts.

Danielle Sudai: I think it’s really interesting. It’s an industry where we all talk and share experiences. I agree with you; there are a lot of people who place blame. But we should focus on what to do in this situation. This isn’t the moment to say, “Now we’re cutting the contract, and we are looking for other options”. We have to deal with it tactically. We need to communicate with our endpoints and ensure that, regardless of the scenario, we are mitigating the issue and have repair items in place.

I want to take a step back to highlight the fact of zero trust as well. Mainly with third parties and fourth parties, there is a lot of room for technical issues, SLA issues, and threats based on the tools they use and the infrastructure they rely on. Renato, you’re a cloud architect; many solutions are built on cloud infrastructure. It’s not always visible how the cloud environments are configured. They can suddenly tell us, “We actually use Java libraries, and now you’re experiencing Log4J”. You didn’t choose that; it’s so fragile.

That’s why I would expect to see a more detailed understanding of the infrastructure they use before onboarding a solution. We need to bring the right technical people to ask the right questions and work closely with solution engineers to explain how our environment looks, what we need from them, and what our concerns are. We should validate that there are no unrealistic promises from vendors that don’t reflect the reality of what’s happening in their infrastructure or the regulated frameworks they adhere to. We need to be very transparent and persistent until we find the answers we’re looking for.

That’s something I love about Deliveroo: we always think about what can happen because we have taken on a SaaS solution. It’s not just about us using them to manage threats; it’s also about how we manage them if they experience a threat. This is something we’ve experienced over the past three years. Six months after I joined, Log4J started to be an issue, and suddenly, there were a lot of SaaS solutions leveraging Java libraries.

Renato Losio: That’s a very good point you made about going down the chain of suppliers. It can be quite challenging. Sometimes, you don’t even realize where they are based. You might end up deploying your stuff on one cloud provider in a specific region, while deciding to monitor using a third-party solution that you don’t even know is deployed in the very same data center you’re monitoring. You might hope that when it goes down, it won’t take both your service and your monitoring solution down at the same time—while you’re still paying for it. But usually, you don’t have that visibility. You need to dig a bit; it’s not like all the answers are readily available. You need to go and find them yourself.

The Costs of Resilience and Human Errors [15:47]

Maybe Mykhailo can provide some feedback from his perspective. Danielle mentioned, “Oh yes, it’s different with the cloud; you might have everything in the cloud, and you need to trust them as well”. At the same time, I was thinking that as a cloud architect, sometimes it’s easy to do more. If my data is on S3 or the equivalent from another provider, and then suddenly someone tells me, “Oh no, why do you have them in just one region? If that region goes down, you want to have a multi-region setup?” Yes, we can do multi-region. In fact, it’s just one click away; it’s not that complicated. Can we implement a multi-cloud solution? Sure, we can do that too.

But how much money do you want to throw at this problem? That is often the real challenge—the balance. How do you decide where to stop? I can make my data super reliable, but the problem is that those petabytes of data I might be managing will become incredibly expensive for the company. I might be throwing money at the wrong problem. Looking back at the CrowdStrike incident, Mykhailo, where should I invest? Where should I focus on making things safer? Is just throwing money at the problem the solution?

Mykhailo Brodskyi: Interesting question. In this case, we are talking about the environment, how we test our application, and our application in general. From my experience, I can see that when we have a very critical application that we want to deploy, we sometimes come up with a runbook with detailed steps that we need to execute in a specific sequence. In case something goes wrong, we have a go decision for when we can roll back everything.

But here we are talking about the environment and how we can test all these different components, and it’s not directly related to the application. That’s why the approach we take to implement new updates to particular elements of the environment needs to be rethought. In some cases, we do not have a straightforward and documented rule on how we should do it, which is very important.

Regarding the data, we usually define and try to cluster the data in different ways. For some critical data, we choose not to store it in specific parts of the application, which is why it’s completely separated.

Renato Losio: Thank you, Mykhailo. Santosh, I don’t want you to reveal anything about your session at the summit, but since the title is “How to Ship Updates of 40+ Apps Every Week”, I was wondering how you can deal with that if you find yourself in a CrowdStrike scenario.

Santosh Yadav: Very good question. Of course, I have seen that all the engineers we have today, like the senior engineers, have broken production at least once in their lives, and they have done it pretty badly. I have done that as well. But when something like this happens, everyone becomes a pro. I mean, they start sharing that this might have been avoided by doing this or that. But the reality is not like that. I think most of the issues go back to the company culture.

For example, at Celonis, the first thing we do is write a design doc. The most important part of the design doc is our release strategy. We outline how we are going to do the release and how we are supposed to roll back if something goes wrong. We always recommend using feature flags in case something is very critical and could impact the system. This way, we can roll back without even impacting the end users; they aren’t even aware of what happened. If something goes wrong, we just roll back. That’s the first step. That’s how we ship our products. As you said, we ship 40-plus apps every week, and that’s the first goal. We don’t even test the code unless we know the plan and the release strategy if something is more critical. Of course, there are small features that can go without a design document. But if there is something critical, like what happened in the case of CrowdStrike, we don’t go ahead without having a design doc in place.

Renato Losio: Thank you, Santosh. Danielle, I was thinking, as Santosh just mentioned culture and the importance of culture in the team. Even when I don’t think about software, when I read the news in newspapers or online, there’s often something bad happening, and it’s frequently attributed to human error. My first reaction when I read about a significant problem is that it wasn’t solely a human error. Yes, there probably was a human mistake, but something was missing. Take a train crash, for example. Maybe the train didn’t stop, but we can’t rely on it stopping just because someone is pressing a button and then blame the driver. There should be multiple safety nets.

When I think about software, I assume culture plays a role, but how do we protect against a developer’s mistakes? I’m not saying a developer wants to do something wrong; sometimes, there’s a bit of complacency or laziness. If I’ve been working on the same project for many years, how do I avoid feeling so safe that I might unintentionally overlook important checks? I’m not suggesting anything is done intentionally wrong, but how do you maintain the right culture?

Danielle Sudai: It’s interesting because Santosh highlights release notes and the importance of assessing what might go wrong and documenting that. I’ll take that and add that mainly in security, we take human mistakes as fact. We’re not blaming anyone; it’s something we are calculating as part of our overall risk, and we’re trying to, you know, ultimately it’s education. There comes a point in your career when you need to understand that maybe you have done something wrong within your configuration, documentation, pull requests, or review of your pull requests, or within your Terraform deployment. That might have a big impact. As you said, how many production engineers have broken production? Many. That also relates to what my session at InfoQ is about, where we will discuss the security aspects that have been impacted by misconfigurations in cloud environments.

An Overview of InfoQ Dev Summit Munich Talks [22:19]

Renato Losio: That’s a good time for each of you to do your elevator pitch for Munich. All three of you are going to Munich and will be doing a session. There are fellow practitioners listening to the podcast: why should they join you in Munich? What are they going to learn from your session? So please, Danielle, go ahead. You’re first.

Danielle Sudai: My session is for cloud security experienced practitioners, but it’s also for developers, compliance people, and security specialists. It mainly discusses misconfiguration in our cloud infrastructure: how do we gain visibility for that? In one of my former roles, I co-engineered a CSPM solution, and it’s simpler than people think.

It’s a very good outlook for professionals—engineer professionals, security professionals—to observe how cloud infrastructures look. Are we making sure that our assets are encrypted? Is our network zoning properly set up? Have we opened a port with a security group that might allow inbound traffic? How easy is it to identify that misconfiguration?

As of today, we are heavily invested in CSPM and Synapse solutions. Before we can do all of that, we really need to understand our environment, how it can be misconfigured, and where our crown jewels are and how they can be impacted. It’s for all professional levels, and I’m excited.

Renato Losio: Thank you so much, Danielle. Santosh, you’ve already mentioned the title of your session, but please go ahead and tell us more.

Santosh Yadav: As I mentioned, we ship more than 40 apps every week. I’m excited to share how we do that, as it’s very critical when you have to work with multiple teams. Forty-plus apps means forty-plus teams to work with. How can you communicate well? Whenever you’re bringing in a new tool, how can you educate, promote best practices, and create better architectures? All those aspects will be part of my talk. I’m really excited to do this because I’ve been thinking about preparing this talk for a long time. I couldn’t be more excited because it’s happening in the city where our headquarters are based. So, yes, I’m really excited to be there!

Renato Losio: Thank you so much, Santosh. Mykhailo, I believe you are going to talk about supply chain security. Please go ahead!

Mykhailo Brodskyi: My topic is going to be around security, focusing on a comprehensive approach to software supply chain security. Creating and developing good solutions in a highly regulated FinTech industry environment is super challenging. I’m going to elaborate more on regulation and how to navigate these regulations. Because it’s not enough just to understand some technical aspects of the implementation; it’s also important to understand the environment. That’s why I will go deep into standards and regulations. Then, I’m going to show some use cases from real examples of how we try to solve some challenges. People who are not from the FinTech industry can use this knowledge and apply it to their business domain. So that is going to be an interesting talk about the FinTech industry and our technical architecture. I will show you some examples, use cases, and explain how we can make architectural decisions faster and correctly.

Renato Losio: Thank you so much. I’ll give my final pitch. These three talks were amazing. There will be 20 other incredible talks, and I hope to see you next month in Munich on September 26th and 27th. Thanks again, Mykhailo, Danielle, and Santosh, for being with us today. Goodbye!

Mentioned:

About the Authors

.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Podcast: Lessons Learned From the CrowdStrike Incident: InfoQ Dev Summit Munich 2024 Preview

MMS Founder
MMS Renato Losio Danielle Sudai Santosh Yadav Mykhailo Brodskyi

Article originally posted on InfoQ. Visit InfoQ

Subscribe on:






InfoQ Dev Summit Munich 2024 Overview [00:05]

Renato Losio: Hello everyone, and welcome to the InfoQ Podcast. I’m Renato Losio, the chair of the upcoming InfoQ Dev Summit in Munich. It’s a new event, and if you’re looking to stay ahead on critical topics like generative AI, security, modern web applications, and more, we’ve got you covered. If you want to learn not just from our three amazing panelists today but from over 20 senior software practitioners with diverse experiences, backgrounds, and countries, join us in Munich! There will be plenty of time to connect with the speakers and your fellow practitioners. Last but not least, the end of September is Oktoberfest in Munich, so if you want to add a few days to enjoy the event, there’s that opportunity as well.

The InfoQ Dev Summit is a two-day event brought to you by the team behind InfoQ and QCon Software Development Conferences. You may already be familiar with QCon London and QCon San Francisco, but there are also two new events. The inaugural InfoQ Dev Summit in Boston took place in June, and the next one is Dev Summit Munich at the end of September (September 26th and 27th). I look forward to connecting with you in Munich this September. I hope to see you there!

Introduction to the Panel [01:20]

Renato Losio: Today, I have the pleasure of sitting down with a panel of three amazing speakers from different backgrounds and companies, all of whom will be speaking at the upcoming InfoQ Dev Summit in Munich. They are Danielle, Santosh, and Mykhailo. In just a moment, I’ll let the panelists introduce themselves, giving each one a minute to share who they are and what they do. Then we’ll launch into a conversation covering some of the critical technical decisions that senior software developers face today and that we’ll dig deeper into in Munich next month.

Specifically, we’re going to talk about resilience, automation, and security for your cloud and non-cloud deployments. Let’s go ahead and introduce our speakers. Danielle, do you want to go first?

Danielle Sudai: I can go first. Very nice to meet you. My name is Danielle Sudai. I’ve been the Security Operations Manager at Deliveroo for the past three years. In addition to managing talented teams and focusing on defending against real-time threats, I’ve also been working in DevSecOps for the last decade across various firms. My focus is on developing the detection and triage of the alerts we receive for real-time threats, based on our organizational vulnerability management.

Renato Losio: Thank you so much, Danielle. Santosh, do you want to go next?

Santosh Yadav: Nice to be here. My name is Santosh Yadav, and I live near Hamburg. I work as a Senior Software Engineer at Celonis, which is based in Munich, so I’ll get a chance to visit my employer after a long time. I mostly work with monorepo, and my team is responsible for managing the entire monorepo, which drives our main product at Celonis, Studio. We coordinate with nearly 40 teams contributing to the monorepo, ensuring it stays healthy, follows best practices, and incorporates new tools with POCs to make the teams’ lives easier, focusing on developer experience.

Apart from that, I’m part of multiple community programs and have contributed to open-source projects. I’m part of the Google Developer Expert (GDE) program for Angular, the GitHub Stars program, and the NX Champions program. You can find me at multiple conferences speaking about NX and Angular.

Renato Losio: Thank you so much, Santosh. And looking forward to meeting you in person in Munich. Mykhailo, you’re the last one.

Mykhailo Brodskyi: Hello everyone, my name is Mykhailo Brodskyi. I’m a Principal Software Architect based in Munich, working in the FinTech industry. Currently, I’m focused on defining the architecture strategy for our platform and am responsible for multiple business-critical projects. One of these projects is our cloud platform migration. I’m also a member of the Cyber and Risk Committees, where we’re responsible for enhancing the security of our platform and mitigating potential vulnerabilities across all our platforms and related applications.

Renato Losio: Thank you so much. We’re now going to talk a bit about resilience, automation, and security.

The CrowdStrike Incident  [04:44]

Of course, this is a bit of a special summer. So let’s start with a topic to trigger some discussion, one that we’re probably all familiar with, whether as travelers, IT experts, security experts, or automation experts. Many of us had the experience last month (well, hopefully not all of us) of being stuck in an airport with a blue screen, thinking that something went wrong. For one of the few times, an IT outage on a large scale made headlines on major news sites. That’s the day you realize something big went wrong. The first reaction is, “Ha-ha, that can happen just to them”. My second reaction is, “Oh, maybe that can happen to me”.

I don’t want to dig into what happened with CrowdStrike or what the implications were; I just want to use that example as a trigger for our discussion about resilience and risk—not necessarily about a global IT meltdown, but maybe just at the company level. How do we handle that? How do we manage automation and those processes? The very first question I have for you is: Were you surprised? What surprised you most about what happened? What do you think is the critical lesson we should learn to avoid saying, “That’s never going to happen to me”?

Santosh Yadav: First, I was surprised that something so big could happen. A company with billions in revenue is responsible for a global outage like this. I remember I was traveling that day—not at the airport, thankfully. I was traveling by train in Germany with Deutsche Bahn, which is never on time, so of course, it was delayed. Regardless of the global outage, I saw some travelers struggling because they were trying to buy food at Frankfurt Station, and their credit cards weren’t working.

People don’t realize that a small mistake can cause something so significant. For someone traveling internationally, not having a working credit card while trying to buy food is a big issue. I was really surprised that this happened. But I think the lesson for everyone is that no system is completely safe. We all make mistakes, but it’s everyone’s responsibility to ensure that the critical paths work. These are critical elements that can impact millions of systems and people. So that was my takeaway: Make sure your critical paths are taken care of.

Renato Losio: Thank you, Santosh. Danielle?

Danielle Sudai: To be honest, before becoming DevSecOps, I was in security IT. The shift to that role and the move to the cloud made me wonder what we are going to do with agent-based SaaS solutions when they impact infrastructure. When we say we are hybrid and moving to the cloud, it’s important to remember that these are other firms’ servers, which are not visible to us. Whenever there is an impact, it also affects our cloud vendors to some extent. What will happen if something agent-based impacts the actual infrastructure? What happens when the on-prem and cloud approaches clash?

I was slightly amazed—I don’t want to speak about the specific company outage because things like that can happen and there is no blame. However, I was surprised by the scope. The company itself is trusted and serves many vendors worldwide, and I think the impact was what surprised me. People may not have been fully conscious of zero trust, leading them to spread agents across all their endpoints or systems, which eventually contributed to the issue. They did this for a good reason, to protect the endpoint and ensure it signals back to their management framework, allowing them to understand what’s happening there.

It’s a bit of a chicken-and-egg situation. But yes, I was definitely surprised by the impact, especially in the U.S. That was crazy. I think it opened another area that isn’t classic security but more of an infrastructure issue, which is massively impactful. All of a sudden, we have to face that reality. It reveals a lot of things that our current platforms cannot solve. We must remember there is an on-prem component behind it.

Renato Losio: That’s an interesting point you made, Danielle. It’s a different security issue in the sense that it’s not a classic denial of service attack. It’s not someone who intentionally caused a denial of service. But in the end, there was a denial of service for the end users, for anyone impacted by the outage. Mykhailo, since you work in a strictly regulated financial industry, do you see anything different? Do you think there are any lessons to be learned? Or were you really surprised, or did you feel like, “Oh yes, I’m surprised that didn’t happen before”?

Mykhailo Brodskyi: Unfortunately, I was also surprised. Payment platforms were affected as well. For me, it wasn’t a shock, but it was a big surprise. In the FinTech industry, we have a huge set of regulations—internal, external, and even some specific to banking. Yet all these regulations didn’t help to avoid this situation. A big question is, how can we improve this? How can we prevent this situation in the future? I’ve had multiple conversations with different departments and applications involved in various payment platforms, and I can say that the deployment and testing approaches should be improved dramatically. That’s what I see.

The Importance of Alternative Solutions and Rollback [11:08]

Renato Losio: Thank you. That’s one point I’d like to come back to later—what we can do to improve. But even going back to the basics, one thing I noticed on my side as a “not expert” was the two entire trends in the very first few days. Apart from blaming the company and saying, “It’s not going to happen to me”, there were thoughts like, “How can they deploy that way while we’re the experts who don’t make those mistakes?” That’s a very risky approach. I’ve always found that attitude not just unfriendly, but also something I wouldn’t want to be in that position in the future, so I’d like to learn from them more than to really blame anyone.

On a practical level, two things happened that day. First, people tried to find different solutions. You could see people in the airport checking in with a piece of paper. On the other hand, people were trying to roll back, but they had no real rollback because we were in a scenario where rolling back was much harder than deploying. I was wondering about those two aspects: what we should do in our deployments to ensure we have a rollback plan. If I’m stuck in that moment, should I think more about a rollback plan, or should I focus on finding another way to bring back what Santosh defined earlier as our critical path and feature? I don’t know, Danielle, if you have any thoughts.

Danielle Sudai: I think it’s really interesting. It’s an industry where we all talk and share experiences. I agree with you; there are a lot of people who place blame. But we should focus on what to do in this situation. This isn’t the moment to say, “Now we’re cutting the contract, and we are looking for other options”. We have to deal with it tactically. We need to communicate with our endpoints and ensure that, regardless of the scenario, we are mitigating the issue and have repair items in place.

I want to take a step back to highlight the fact of zero trust as well. Mainly with third parties and fourth parties, there is a lot of room for technical issues, SLA issues, and threats based on the tools they use and the infrastructure they rely on. Renato, you’re a cloud architect; many solutions are built on cloud infrastructure. It’s not always visible how the cloud environments are configured. They can suddenly tell us, “We actually use Java libraries, and now you’re experiencing Log4J”. You didn’t choose that; it’s so fragile.

That’s why I would expect to see a more detailed understanding of the infrastructure they use before onboarding a solution. We need to bring the right technical people to ask the right questions and work closely with solution engineers to explain how our environment looks, what we need from them, and what our concerns are. We should validate that there are no unrealistic promises from vendors that don’t reflect the reality of what’s happening in their infrastructure or the regulated frameworks they adhere to. We need to be very transparent and persistent until we find the answers we’re looking for.

That’s something I love about Deliveroo: we always think about what can happen because we have taken on a SaaS solution. It’s not just about us using them to manage threats; it’s also about how we manage them if they experience a threat. This is something we’ve experienced over the past three years. Six months after I joined, Log4J started to be an issue, and suddenly, there were a lot of SaaS solutions leveraging Java libraries.

Renato Losio: That’s a very good point you made about going down the chain of suppliers. It can be quite challenging. Sometimes, you don’t even realize where they are based. You might end up deploying your stuff on one cloud provider in a specific region, while deciding to monitor using a third-party solution that you don’t even know is deployed in the very same data center you’re monitoring. You might hope that when it goes down, it won’t take both your service and your monitoring solution down at the same time—while you’re still paying for it. But usually, you don’t have that visibility. You need to dig a bit; it’s not like all the answers are readily available. You need to go and find them yourself.

The Costs of Resilience and Human Errors [15:47]

Maybe Mykhailo can provide some feedback from his perspective. Danielle mentioned, “Oh yes, it’s different with the cloud; you might have everything in the cloud, and you need to trust them as well”. At the same time, I was thinking that as a cloud architect, sometimes it’s easy to do more. If my data is on S3 or the equivalent from another provider, and then suddenly someone tells me, “Oh no, why do you have them in just one region? If that region goes down, you want to have a multi-region setup?” Yes, we can do multi-region. In fact, it’s just one click away; it’s not that complicated. Can we implement a multi-cloud solution? Sure, we can do that too.

But how much money do you want to throw at this problem? That is often the real challenge—the balance. How do you decide where to stop? I can make my data super reliable, but the problem is that those petabytes of data I might be managing will become incredibly expensive for the company. I might be throwing money at the wrong problem. Looking back at the CrowdStrike incident, Mykhailo, where should I invest? Where should I focus on making things safer? Is just throwing money at the problem the solution?

Mykhailo Brodskyi: Interesting question. In this case, we are talking about the environment, how we test our application, and our application in general. From my experience, I can see that when we have a very critical application that we want to deploy, we sometimes come up with a runbook with detailed steps that we need to execute in a specific sequence. In case something goes wrong, we have a go decision for when we can roll back everything.

But here we are talking about the environment and how we can test all these different components, and it’s not directly related to the application. That’s why the approach we take to implement new updates to particular elements of the environment needs to be rethought. In some cases, we do not have a straightforward and documented rule on how we should do it, which is very important.

Regarding the data, we usually define and try to cluster the data in different ways. For some critical data, we choose not to store it in specific parts of the application, which is why it’s completely separated.

Renato Losio: Thank you, Mykhailo. Santosh, I don’t want you to reveal anything about your session at the summit, but since the title is “How to Ship Updates of 40+ Apps Every Week”, I was wondering how you can deal with that if you find yourself in a CrowdStrike scenario.

Santosh Yadav: Very good question. Of course, I have seen that all the engineers we have today, like the senior engineers, have broken production at least once in their lives, and they have done it pretty badly. I have done that as well. But when something like this happens, everyone becomes a pro. I mean, they start sharing that this might have been avoided by doing this or that. But the reality is not like that. I think most of the issues go back to the company culture.

For example, at Celonis, the first thing we do is write a design doc. The most important part of the design doc is our release strategy. We outline how we are going to do the release and how we are supposed to roll back if something goes wrong. We always recommend using feature flags in case something is very critical and could impact the system. This way, we can roll back without even impacting the end users; they aren’t even aware of what happened. If something goes wrong, we just roll back. That’s the first step. That’s how we ship our products. As you said, we ship 40-plus apps every week, and that’s the first goal. We don’t even test the code unless we know the plan and the release strategy if something is more critical. Of course, there are small features that can go without a design document. But if there is something critical, like what happened in the case of CrowdStrike, we don’t go ahead without having a design doc in place.

Renato Losio: Thank you, Santosh. Danielle, I was thinking, as Santosh just mentioned culture and the importance of culture in the team. Even when I don’t think about software, when I read the news in newspapers or online, there’s often something bad happening, and it’s frequently attributed to human error. My first reaction when I read about a significant problem is that it wasn’t solely a human error. Yes, there probably was a human mistake, but something was missing. Take a train crash, for example. Maybe the train didn’t stop, but we can’t rely on it stopping just because someone is pressing a button and then blame the driver. There should be multiple safety nets.

When I think about software, I assume culture plays a role, but how do we protect against a developer’s mistakes? I’m not saying a developer wants to do something wrong; sometimes, there’s a bit of complacency or laziness. If I’ve been working on the same project for many years, how do I avoid feeling so safe that I might unintentionally overlook important checks? I’m not suggesting anything is done intentionally wrong, but how do you maintain the right culture?

Danielle Sudai: It’s interesting because Santosh highlights release notes and the importance of assessing what might go wrong and documenting that. I’ll take that and add that mainly in security, we take human mistakes as fact. We’re not blaming anyone; it’s something we are calculating as part of our overall risk, and we’re trying to, you know, ultimately it’s education. There comes a point in your career when you need to understand that maybe you have done something wrong within your configuration, documentation, pull requests, or review of your pull requests, or within your Terraform deployment. That might have a big impact. As you said, how many production engineers have broken production? Many. That also relates to what my session at InfoQ is about, where we will discuss the security aspects that have been impacted by misconfigurations in cloud environments.

An Overview of InfoQ Dev Summit Munich Talks [22:19]

Renato Losio: That’s a good time for each of you to do your elevator pitch for Munich. All three of you are going to Munich and will be doing a session. There are fellow practitioners listening to the podcast: why should they join you in Munich? What are they going to learn from your session? So please, Danielle, go ahead. You’re first.

Danielle Sudai: My session is for cloud security experienced practitioners, but it’s also for developers, compliance people, and security specialists. It mainly discusses misconfiguration in our cloud infrastructure: how do we gain visibility for that? In one of my former roles, I co-engineered a CSPM solution, and it’s simpler than people think.

It’s a very good outlook for professionals—engineer professionals, security professionals—to observe how cloud infrastructures look. Are we making sure that our assets are encrypted? Is our network zoning properly set up? Have we opened a port with a security group that might allow inbound traffic? How easy is it to identify that misconfiguration?

As of today, we are heavily invested in CSPM and Synapse solutions. Before we can do all of that, we really need to understand our environment, how it can be misconfigured, and where our crown jewels are and how they can be impacted. It’s for all professional levels, and I’m excited.

Renato Losio: Thank you so much, Danielle. Santosh, you’ve already mentioned the title of your session, but please go ahead and tell us more.

Santosh Yadav: As I mentioned, we ship more than 40 apps every week. I’m excited to share how we do that, as it’s very critical when you have to work with multiple teams. Forty-plus apps means forty-plus teams to work with. How can you communicate well? Whenever you’re bringing in a new tool, how can you educate, promote best practices, and create better architectures? All those aspects will be part of my talk. I’m really excited to do this because I’ve been thinking about preparing this talk for a long time. I couldn’t be more excited because it’s happening in the city where our headquarters are based. So, yes, I’m really excited to be there!

Renato Losio: Thank you so much, Santosh. Mykhailo, I believe you are going to talk about supply chain security. Please go ahead!

Mykhailo Brodskyi: My topic is going to be around security, focusing on a comprehensive approach to software supply chain security. Creating and developing good solutions in a highly regulated FinTech industry environment is super challenging. I’m going to elaborate more on regulation and how to navigate these regulations. Because it’s not enough just to understand some technical aspects of the implementation; it’s also important to understand the environment. That’s why I will go deep into standards and regulations. Then, I’m going to show some use cases from real examples of how we try to solve some challenges. People who are not from the FinTech industry can use this knowledge and apply it to their business domain. So that is going to be an interesting talk about the FinTech industry and our technical architecture. I will show you some examples, use cases, and explain how we can make architectural decisions faster and correctly.

Renato Losio: Thank you so much. I’ll give my final pitch. These three talks were amazing. There will be 20 other incredible talks, and I hope to see you next month in Munich on September 26th and 27th. Thanks again, Mykhailo, Danielle, and Santosh, for being with us today. Goodbye!

Mentioned:

About the Authors

.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


.NET Aspire 8.2: Components Renamed to Integrations, Enhanced Testing, and More Improvements

MMS Founder
MMS Almir Vuk

Article originally posted on InfoQ. Visit InfoQ

.NET Aspire 8.2 has been officially released, bringing enhancements focused on onboarding, testing, and overall quality-of-life improvements. A significant change in this version is the renaming of Components to Integrations. As explained, the term Integrations now means packages that assist with the setup, initialization, and interaction with major cloud services and platforms.

The .NET Aspire team clarified this change in terminology:

We originally named these components because… well… they’re components! But we’ve realized that it’s such an overloaded term in development that we were actually just confusing people (and ourselves). Our documentation has been updated to reflect the change to Integrations and we will be using that terminology in our content moving forward.

In .NET Aspire 8.2, Integrations are utilized in two main ways. First, as a Hosting package that was added to the AppHost project, which simplifies launching resources and connecting them during local development. Second, as a package within the application code, this makes easier the process of connecting to resources created in the AppHost and simplifies the setup and configuration of new cloud services.

The release also includes improvements in testing procedures. The .NET Aspire team, with contributions from the community, has expanded its suite of tests to ensure that updates to Integrations do not disrupt existing applications. This enhancement aims to facilitate smoother version upgrades and minimize potential issues.

A significant breaking change in .NET Aspire 8.2 involves a known issue with building projects that reference version 8.1.0 when the 8.2.0 workload is installed. Users are advised to ensure their AppHost project references the latest version of the Aspire.Hosting.AppHost package by including the following line in the project file.

Looking ahead to .NET Aspire 9.0, the team is working on enabling project builds without requiring the .NET Aspire Workload to be installed. This change is expected to benefit continuous integration and deployment scenarios by reducing the need for workload installation on build machines.

It is also stated that the progress towards this goal has been made in version 8.2 by moving some components to separate packages, which projects will automatically reference. This change is anticipated to be mostly transparent to users but requires updating to the latest version of the workload and package references. An open GitHub issue provides further details on these topics for interested readers.

Community feedback on this release has been generally positive. Users have requested additional features, such as a SignalR Integration to manage hub connection URLs and ports, and improvements in documentation for deployment and issues with Azure App Service. Lastly, the official release notes hold more information about this release for interested readers.

About the Author

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


.NET Aspire 8.2: Components Renamed to Integrations, Enhanced Testing, and More Improvements

MMS Founder
MMS Almir Vuk

Article originally posted on InfoQ. Visit InfoQ

.NET Aspire 8.2 has been officially released, bringing enhancements focused on onboarding, testing, and overall quality-of-life improvements. A significant change in this version is the renaming of Components to Integrations. As explained, the term Integrations now means packages that assist with the setup, initialization, and interaction with major cloud services and platforms.

The .NET Aspire team clarified this change in terminology:

We originally named these components because… well… they’re components! But we’ve realized that it’s such an overloaded term in development that we were actually just confusing people (and ourselves). Our documentation has been updated to reflect the change to Integrations and we will be using that terminology in our content moving forward.

In .NET Aspire 8.2, Integrations are utilized in two main ways. First, as a Hosting package that was added to the AppHost project, which simplifies launching resources and connecting them during local development. Second, as a package within the application code, this makes easier the process of connecting to resources created in the AppHost and simplifies the setup and configuration of new cloud services.

The release also includes improvements in testing procedures. The .NET Aspire team, with contributions from the community, has expanded its suite of tests to ensure that updates to Integrations do not disrupt existing applications. This enhancement aims to facilitate smoother version upgrades and minimize potential issues.

A significant breaking change in .NET Aspire 8.2 involves a known issue with building projects that reference version 8.1.0 when the 8.2.0 workload is installed. Users are advised to ensure their AppHost project references the latest version of the Aspire.Hosting.AppHost package by including the following line in the project file.

Looking ahead to .NET Aspire 9.0, the team is working on enabling project builds without requiring the .NET Aspire Workload to be installed. This change is expected to benefit continuous integration and deployment scenarios by reducing the need for workload installation on build machines.

It is also stated that the progress towards this goal has been made in version 8.2 by moving some components to separate packages, which projects will automatically reference. This change is anticipated to be mostly transparent to users but requires updating to the latest version of the workload and package references. An open GitHub issue provides further details on these topics for interested readers.

Community feedback on this release has been generally positive. Users have requested additional features, such as a SignalR Integration to manage hub connection URLs and ports, and improvements in documentation for deployment and issues with Azure App Service. Lastly, the official release notes hold more information about this release for interested readers.

About the Author

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.