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.

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.

Do or do not. There is no try.

I recently dreamed I was in a large audience where an unidentified leader asked for a volunteer to lead a big project. They looked at me, and I said something like I will try, but I couldn't do it alone. Someone else stood up and said they would take on the project, and I could feel the audience staring at me with disdain. So much so that it woke me up.

I am not the type of person who looks for a lot of meaning in my dreams, mostly because I don't remember them. But this one woke me up, and I spent the rest of the early morning lying in bed, considering why it bothered me.

This was similar to talking to others and asking them how we get something done, and their answer is something like, "We don't have the resources." That wasn't the question; the question was, what would it take? My dream was similar because the question was not, "Would you deliver this project by yourself." It's not a question of ensuring a successful outcome; it's a question of pulling together enough for a reasonable discussion on feasibility.

The response I would guide my dream self to give is: Sure, I will lead that big project for you. Then, I would document what it's going to take to get it done and present that to the stakeholders. 

This dream bothered me because I was settling for trying when I knew better.

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.

Builders gotta build

When I talk to people about what I like about what I do - there are usually two things that I tell them. First that I like to build stuff and second to solve problems. I am a builder - both in my professional and personal life. Building software is what I get paid to do because I have demonstrated that I am good at it. Building in the physical world is just fun.

Take for instance "building" at home. Fixed things in the house. Upgrades. Or creating something that I need. The one that I wished I had yesterday was a yard tool holder. I recently moved and left the yard tool holder behind. It was something that I built out of extra lumber I had around the house. It looked something like the picture I attached, but custom made for the tools and the materials I had available. I knew what I wanted / needed but was constrained by what I had available.

Sounds like a parallel to building software. There are the requirements and then there is what you can do. The components available and time are both constraints to what you can complete. This is one place where the problem solving comes into play - putting it all together to complete (deliver) something.

There is something rewarding about completing something that I built. Yesterday it was waxing poetic about my yard tool holder. Sounds like an opportunity to consider version 2.

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. 

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.

If you smelt...you dealt it

No this entry is NOT about flatulence.  Ironically, there is a Wikipedia page that is - here.  Instead my intent is to opine on the practice at my employer about developers supporting their own code - which means that if you broke something then you are going to be the one to fix it.

When I was managing the production support team at my previous employer; the team's responsibility was to focus on the operation of key systems and ensure that they were available and meeting SLAs.  This team did a good job at keeping things moving - if something broke they got to be pretty adept at fixing issues.  If you look at this as an outcome with a fixed cost (which is how we structured it) then it can look pretty attractive.  But in the end the people on the team had many concerns/issues/complaints/etc about the challenges they faced in sustaining this model.  In the end - I feel that this model takes too short of a view of life cycle of a system and therefore is flawed.

First it is worth noting that Amazon has a list of core leadership principles that they live and breath by.  I have done a lot of chin rubbing around these as of late and the more that I play with them the more I like them.  When considering this post there were a few in particular that I felt applied..."Ownership", "Invent and Simplify" and "Insist on the Highest Standards".  If you read the short descriptions for each of these they are all pointing to how separating support from development is flawed.

If developers are not responsible for keeping their own code running or seeing how it behaves in production then how they doing any of these things?  Sure it is possible that you get outcomes in this direction; but it is not likely - especially without the ownership.

A related topic to this is how we work this into our Agile methodology to ensure that we still get things done on time.

Humility and Confidence

Humility and Confidence are two words that have been rolling around in my head lately. In this post I am going to let these two play out here and see what I end up with; I have no idea where this is going.

This was inspired by my closing comment in my previous post - that I still have so much to learn. This was not meant to be a statement of self judgment but one of humility; especially as it pertains to leadership. The day that I believe that this statement is less true is the day that my ego is in control and I will be a less effective leader. Not to be confused with confidence. Confidence is knowing that things are going to be OK. Unfortunately confidence is mistaken by many as something more than just know that things are going to work out and it is used to boost/elevate the Self.

Confidence is experiential - Humility is constant. Confidence that is not based on experience is not solid and will not be trusted. The people around you will know this and their tentativeness will be palpable; that is if you are paying attention. But someone in this state will not be paying close enough attention; rather this person will be expending a lot of energy trying to show or justify the position that they will miss signals. The way to combat this is by being honest with people when you are not confident. That is not to say that you freak out and run out the room screaming. But rather you turn to people and say something to the extent – “I have never encountered something like this before – what would you do?” In other words show some humility.

This is where it gets tricky. First off, being a good leader means that you are doing this quite a bit already. You should be allowing people to contribute by being part of the decision making process and then empowering them to act. Good leaders do not do everything themselves. Every time I get to this point in my thinking of remember one of the tenants from “What Got You Here…” – Don’t add too much value. Secondly, statements like this need to couched in some sort of decision making “process” (I am using the work process lightly). Be very clear in your own thinking that statements like this can lead to a sense of anarchy or distributed decision making; this is not about abdicating or stealing the decision making process. Someone still needs to own the decision or you can end up on an endless discussion or debate. Also you need be very clear when the decision has been made; believe it or not this can be hard. I can’t tell you how many times I have seen a decision made and people don’t realize it and bad things happen from there (maybe something to address a subsequent post).

So back to our my statement and the key aspect of it that shows humility is the prefix – that you are being humble by acknowledging you don’t “know” the answer. But you are not faking that you do. Take the same statement without the prefix – “What would you do?” Depending upon the person this statement can be taken a bunch of ways. Every day I deal with people in different states and to a “paranoid” lonely statement could mean something different than it does to someone who is “competitive”. I believe that peoples states mostly boil down to trust – trust in me and trust in themselves (how are they different ). When I exhibit humility it helps reinforce trust. Is there a guarantee? Nope. Some people have some core trust issues and this is a drop in the ocean to helping that. But hey, before there where oceans there had to be that first drop.

Humility goes so much further than what I have mentioned here. In fact I believe that humility instills confidence. Have you ever been around a humble person and felt a difference? Are you more relaxed? I believe so. I believe that I am more likely to value humility in a leader than just pure confidence. I have worked with some way smarter people over the years and nothing was more of a turnoff than confidence with no humility. When working with someone like this I did not feel that there was anything in it for me; they just “knew” what the right thing to do was and made the call. Often times they were right or close; but how invested was I in that decision? How likely would I be to work hard to see it through the challenges? How much did I learn from the experience?

See the difference?

Lastly, humility has another aspect worth mentioning. I find that there is another aspect of humility that characterizes good leaders – they give a lot of credit to those around them. They take (or assign) responsibility and ownership for the decision but give clear credit to those who contributed to the decision. This is easy to recognize and gets my attention very quickly; regardless of whether I am the person being acknowledged or now.

So how good am I at this? I can certainly do better. I know that

PS. I feel like there are aspects to these two words that I want to address in the future that I in some way touched on above; but will wait for a future post to explore.

• Confidence is situational – Humility is not.


• Confidence is shakable - Humility is solid.


• Something about Humility being timeless.


• Attributes of healthy confidence vs less healthy?

What a year!

Was just reviewing my last post (which began similarly) and it ended with reference to changes in leadership in my department. Those changes continued to snowball and culminated with me landing a new position on the leadership team. The last year has consisted of me figuring out what this new job is and how I can do it. I just finished my self appraisal so it can say that it has been a difficult year. The transition has not been easy for me or my extended team. We changed many things in the organization this year and it has had some significant impacts. Every day I get up and keep my eye on the big vision of what we are trying to do and figure out how to make course corrections to get us there. Unfortunately it feels like I am using a spoon to do it sometimes. Yes, I am the one picking up the spoon thinking it will help and realizing that it is just the wrong "tool". Some mistakes make me feel like a rookie. Last week I was reading an article from the Harvard Biz Review called "Why Should Anyone Be Led By You?" and it reminded me of what I like about leading (and what I don't).

As part of my promotion to an officer in the company I am participating in a year-long intensive leadership training program. It's been interesting separating the leader from the manager.

For what it's worth here are some new books "on the shelf"...
1. What Got You Here Won't Get You There
2. The Leadership Moment
3. Crucial Conversations
4. True North
5. The Zen of Listening
6. Nice Teams Finish Last
7. The World Is Flat