The need to be right?

Maybe you've been here too—that irresistible urge to be right. Whether in meetings, conversations, or even casual debates, there's something deeply satisfying about knowing the answer or how to do something. But here's the tricky part: the need to be right can become a serious obstacle in leadership.

Leaders can be driven to continuously prove themselves correct, often unintentionally silencing their teams. When we put being right above getting it right, we risk creating an environment where others hesitate to share ideas, challenge perspectives, or offer valuable insights. The result? Innovation stalls and creativity takes a back seat.

Think about the best leaders you've worked with. They probably didn't insist on always being the smartest person in the room. Instead, they focused on bringing out the best ideas, regardless of who proposed them. They were comfortable admitting they didn't have all the answers, opening the door to collaboration and collective problem-solving.

Here are the things I am working on to continuously improve in this area.

1. Humility. Recognize that no one has a monopoly on good ideas—not even the boss. Being open to learning from your team creates trust and invites diverse viewpoints.
2. Prioritize outcomes over egos. My goal is to achieve the best result rather than validate my personal viewpoint. I need my team to fulfill the vision and outcomes. Giving them room to do it their way allows them to learn from experience rather than being told.
3. Listening. Slow my brain down and not plan my response. Just listen. Discuss without answering or directing. I have been rewarded by watching people arrive at the "right" thing in an entirely different way.

Remember, leadership isn't about proving you're right but empowering your team to find the best path forward together. So the next time you feel that urge to argue your point, pause and ask yourself: "Am I trying to be right, or am I trying to get it right?" 

P.S. This is good advice in a relationship.

Try Noodling on That

The name of this blog is a reference to words uttered by a friend of mine. He also added the word "noodle" to my vocabulary, which is synonymous with thinking in this context. Not to be confused with a Noodle the pug who prognosticated on what type of day we could expect to have.

Whether to myself or someone on my team, I often use the phrase "noodle on that" when the answer is non-trivial and analysis and logic are not yielding a solution. It can be relatively straightforward—I need an answer to this problem—or something more abstract—like ideation. Either way, there are times when looking for an answer is more like chasing something elusive. Finding the answer is often further compounded by some time pressure - I need to solve this by XX.

Enter Noodling.

Several times, the answer presented itself to me - but only when I took the pressure off myself. For instance, I was cramming for a math final, and the answer to a particularly gnarly calculus problem came to me in my sleep. It woke me up, presumably so I could write it down (ha). Another time, the answer came to me in the shower. Someone once attributed this to all the positive ions stimulating my brain. Whatever the reason, it's a thing - Shower Epiphanies.

As a manager, I have often suggested that they take a break from trying to solve the problem directly and noodle on it. Give yourself a break. Let the pressure off. Give your subconscious a chance to work on it. My anecdotal data is that it works the majority of the time. This has the additional benefit of letting people work it out for themselves. My belief is that things feel better when people figure something out on their own, as opposed to me giving them the answer. 

See you on comfy mountain. IYKYK.

Is Doing the Right Thing - Right?

For most of this year (the last nine months), I have been pondering whether doing the right thing is right. Let me clarify. For me, doing the right thing in the context of honesty or integrity - is ALWAYS the right thing. Is doing what I feel is the right thing to do - the right thing? I have been noodling on specific circumstances that have me questioning whether I did the right thing based on how they turned out. 

There were two circumstances where I put others' needs ahead of my own, and it didn't work out. It is not nearly as noble as when Spock sacrificed himself in Wrath of Khan, but it is my little drama. The binary part of me looks at these situations and sees the only alternative as never putting others first and looking out only for myself. Even writing that down makes me grimace, as it goes against my core beliefs. So, the answer must be in the vast gray area between what I did and doing nothing. In the classic answer for all questions, it depends.

Regarding the two circumstances I have been pondering, the others were not in their integrity, making that the easier thing to focus on. I put others (people, projects, etc.) first and myself second, and it didn't work out as I had hoped. As I healed from that, I was able to begin considering where my learning was. Even if it's a one-off, I won't trust that person in the future.

I have been thinking about reciprocity in this context; doing something for others (entities or people) without expecting what I may get in return. Being a manager/leader is being in service. The thing I struggle with is whether that also requires selflessness. My recent experience is that selflessness in the workplace is a minefield. First, it's not very likely to happen - it's just the nature of companies, especially large ones. Second, I must acknowledge that I sometimes have expectations hiding behind my actions. They may be as simple as looking for a smile, but expectations nonetheless. That doesn't make my decision/activity wrong; it just exposes that I had some expectations. It's the missed expectations that led to my disappointment.

Ultimately, I feel good about what I did and my reasons for doing it. I would make the same choice again, looking out for any expectations I have. It also means that being selfless does not mean sacrificing myself. So, maintain my integrity, do what I believe right, and watch out for personal risks.

Secure Apps Take a Village

I reflect on recent experiences and the tension between rolling out features and ensuring the product is secure. Features are flashy. They make good keynotes and/or demos. Features get customers excited and make money.

Security is about the backend. It's not flashy. It's hard to demo security; you probably wouldn't want to even if you could. But when something goes sideways, a security issue will lose you customers. It's like giving your competition bullets—"Hey, did you hear about that security breach at Acme?"

Security is getting more complex and more challenging to do well. Sure, we are smarter and better understand vulnerabilities. However, applications are also becoming more complicated (e.g., log4j and versioning). Complexity makes security harder—it just does. The bad actors are as determined as ever, and their methods continue to evolve.

I attribute much of this tension to the organization's culture. A typical culture pattern is when leadership compresses engineering estimates, and as time runs out, security verification takes place. This leads to pressure to complete verification and remedy errors without impacting the date. Regardless of the number of times that leaders tell people how important security is - actions speak louder. We must ship at this point in the project, leaving uncomfortable conversations and hard choices. 

The tension between shipping and being secure starts early, when most of the time is spent discussing/planning customer-facing features. Sure, security comes up, but in my experience, it gets a different in-depth consideration. If we are lucky,  the challenging security conversations/decisions are before we launch - and not after. Talking about security feels more like a bad thing when it's this late. Further contributing to this tension is when leaders push to make a date, a security issue is identified, and in response, they make statements akin to - "Security is always a priority, so when I push on the date, my expectation is that the system is still secure."

Imagine a product where this culture goes on for a long time; the product is very successful and lucky that lurking security issues are private. With some certainty, this culture will catch up with you, and a critical mass of security issues will arise, requiring engineering resources. Sometimes, the number and/or severity of the problems is so great - that feature delivery is paused, and most of the team is focused on remediation. I bet that for every case like this in the press, many more are not public.

Too often, I have seen teams rely on the hero model: people who, early on, take the risk of spending time on security—which, in my opinion, is under-acknowledged/appreciated. Or the heroes who scramble to fix issues after they are found—typically in a severe time crunch. The hero model is not sustainable and is unreliable for ensuring secure systems. Further, the hero model is often a symptom of something "wrong."

So, let's stop relying on heroes, best intentions, hollow statements, and punishing the bearers of bad news. In a fiercely competitive world, features are prioritized, and security often gets less attention, sometimes even becoming an afterthought. This is a culture war that needs to be waged. 

We must start by considering security not just as a necessity but as a feature as important as any other. We need to talk about it early. We need to do security reviews early and often. For instance, start a threat model on the first day, keep it up to date, and assess design decisions in the context of how it would change the threat model. Activities like this involve staffing security-oriented teams and embedding them into the project teams. Then, empower them to ensure positive security-oriented outcomes. A culture of security is independent of volunteers who take on additional responsibility to ensure a secure system.  We need mechanisms to help people do the "right" thing. Then, acknowledge (early) security wins, such as actions to avoid an event.

A culture of security is hard to change, and as leaders, we need to be honest with ourselves about it — are we backing up our words in ways that will lead to the outcome we want? Look in the mirror. Yes, the words mean something, but it takes more than words.

PS: If you're unfamiliar with the African phrase "it takes a village" - see here.

Be a Student of Management

My experience is being a manager is hard. More specifically it's hard to do well. In my career I have tried being a manager and decided it was not for me and gone back to being an individual contributor. I liked the idea of being a manager but could tell I was not ready to be a good manager.

It wasn't until I became a manager where I was also considered an officer of the company and the company enrolled me in a year-long training. Oh wait, there is training for this? This is when I became a student of management. The assumption that the skills that made me a great individual contributor were the same as the ones I needed to be an equally great manager were quickly dispelled. I needed to grow some new muscles.

I am a naturally curious person, so this was something I wanted to learn more about. That is after I swallowed a little humility. I started off reading a handful of books recommended as part of the development program. These were helpful and gave me a foundation for the type of manager I wanted to be. But it was only through trying (and at times failing) that I learned where my weaknesses were. The biggest one was to not try and control the outcomes of using my technical expertise. This is where I came up with the pattern I called controlled failure - a topic for another post.

The key for me has been to acknowledge that as good of a manager I am, that I need to remain humble. There is always something new to learn. I have learned things at the best and worst of times. My goal is never stop learning how to be the best manager I can be - to always be a student.

Adam Grant is someone I have learned a bunch from. 

Kindness Factor

Kindness is something that has been on my mind lately. What does kindness look like at work? I was thinking on this and believe kindness starts with myself then extends to others. 

Am I the only one that has an easier time extending kindness to others than myself? Self analysis aside, I can't help but smile when being kind to others. Either way, it's me expressing the kindness - I am "in control".

The challenge is - I am not in control when looking to receive kindness. It's not something I can simply request. But it is something that when it's missing, I know it. I learned a long time ago that it's foolish to think that by modeling kindness - something will change. If it does, great, but it's not likely.

Kindness at work is happiness. Satisfaction. Feeling appreciated. All sound like good things to have in the work place - right? So why do I get the sense that there are others that see this idea as foreign / incompatible with the workplace? How about you - do you see kindness where you work? 

Public vs. Private

I am a big Ted Lasso fan. I didn't want to be at first, I thought it was going to be a goofy sports based show. I could not have been more wrong and found myself laughing harder than I had in a long while. Over the last few months I have been reminded of this episode where Roy Kent gives an example of not knowing what is going on each other's lives.

[...] And none of us know what is going on in each other's lives. So for Isaac to do what he did today, even though it was wrong... I give him love. And as for why he did what he did... that's none of my f?cking business. [...]

If you don't know this one, please check out the link above with this scene. It's a great story.

Recently I found myself thinking about this - we don't know what is going on in each other's lives. I think the way this manifests is when observing another's behavior we fill in their story with our own story about what must be going on for that person. Like most stories, we tend to create them from our past experiences; many times assuming the worst.

I bet you have created a story to explain someone else's behavior; parents, colleagues, friends, direct reports, strangers. And how many times was the story a "negative" one? As much as I try not to, I know I have. This is where another Ted Lasso lesson pops for me. When Ted is playing darts with Rupert (Mannion not Giles) and shares "Be curios, not judgmental" as part of a story he is relating. My experience is that my stories are often close my judgement and therefore short circuit my curiosity. It's just about treating others as people, with respect and compassion. That doesn't mean that we shouldn't hold them accountable. But it may change the way you hold them accountable or whether you hold them accountable at all. 

I like to write these down as something for myself to continue to be mindful of as opposed to expecting anyone else to benefit from them. If you do, then great, love that.

What does it mean to lead?

Leadership is always something on my mind; whether personally or professionally I find it an interesting topic to continuously be humble around and strive to improve. 

Leadership comes in so many forms and I find it hard to define. More important than the definition is what leaders actually do is how they do it. There is one thing that I have brought over from my spiritual journey to my professional life that I feel is the key. 

It's not about you stupid. Let me 'splain. The most important thing I continually remind myself is that it's about others. Putting anything else first weakens leadership. First and foremost, people want to feel safe; when people feel safe then good stuff follows. Think about all the ways that this influences outcomes. When people feel safe, they are happy and happy people are capable of amazing things. First, and most importantly, is that happy people create a multiplying effect of creating more happy people.

The times that I think back to when I liked my job the most it was because I was happy, and I worked with a group of people that made it fun; even when it was hard.

Keep It Simple (kiss) Revisited

I have a calendar from a vendor we use that has some of the classic coding and design principles - one for each month.  I was rubbing my chin staring at it this morning and I wanted to share what popped into my head...

While I am sure that the KISS principle has been written about (perhaps to death) I had another instance of this today as it applies to operations and infrastructure.

Quick background - I recently inherited an Operational group.  Operations is the clean up crew of development here.  While I understand the rationale of separating them, I think I like the idea of developers supporting their own code so that they better understand the impact of what they do.  What a great teaching tool - you want to not get up in the middle of the night - fix the code, do a better job in the first place, write a utility to help you out.  We have a bunch of applications that have been around for years and over time the developers who maintain many of these have moved on.  So today I asked the question of someone about two AD groups and what they are used for.  In both cases the answer was initially I don't know - and later the answer became these are not used anymore.

Part of keeping systems simple is getting rid of the things that are not used anymore.  We have all these extraneous moving parts that we don't need.  This just creates system bloat that should be easy to remove.

Granted you cannot get to everything - right now.  But this stuff has to get cleaned up over time.  Putting it into some sort of maintenance, wish list or Kaizen log seems like an easy thing to do.

All it takes is discipline.

Yiddish for IT Leaders

I have come to the conclusion that I need to know more yiddish.  Can I use it as a code to hide what I am really thinking?  Help bypass any email filters?  Just make me feel better.  Here is my arsenal.

bupkis - As in - you don't know bupkis.

chutzpah - There is always one team member with too much of this.

glitch - Things are late again?  It must be another glitch.

kibitz - What we should call reviews.

klutz - You don't want this and a programming to go together.

kvetch - What I do when I get home from work.

nudnik - In management speak these are the team members you manage out.

schmuck - What you call someone who changes something directly in production - first.

schtik - A little off topic, but I think of Benji Bronk on the radio on my way into work.

shpiel - My weekly team briefings have at least one of these.

yutz - Yiddish has lots of fun words for describing people that bum you out.