Sunday, May 23, 2021

Five years as a Red Hatter- the best job of my life!

 As I reflect upon and contemplate over my time spent here, I deemed it apt to share. This is my attempt at summarizing the top five experiences I've had and learnt from in these glorious and eventful years. I sincerely wish these resonate as much with you as they do with me. I also hope you enjoy reading this as much as I enjoyed writing it.

1st April marked five fabulous and fantastic years since the day the honour of being called a Red Hatter was bestowed upon me. This gig is BY FAR, the best job of my life, period. It's my true north.  I've learnt and forgotten (:D!) more in these five years than in the rest of my career combined, and I'm grateful to be able to learn, add value and grow with and within Red hat.  

My Red Hat journey in a nutshell

I had read The Open Organization book by Jim Whitehurst, and to this day remark at how accurate and authentic the depiction of Red Hat as an organization and as a culture is in it; Jim, I doff my hat to you! 

When Red Hat came a callin', I was greatly interested in having a discussion with them about my career prospects at a small but beautiful town in the Czech Republic that I've now come to love; Brno! I'll admit the interview process was lengthy, tough and draining. Eventually, the Documentation Program Manager role was offered to me, and I jumped at it because the role and the prospect of working with the largest open source organization in the world had me excited. 

Since working as a DPM  for Business Automation Suite of products (they were called BxMS in those days), I've held multiple roles (Associate Manager, Business Lead, BLC member- Brno Leadership Council) and have worked in multiple products  (BXMS, Satellite, RHOAR, 3scale, RHEL, etc.). So in essence, I'm the poster child for showcasing how internal mobility well and truly works at Red Hat! If I had an iota of doubt about if Red Hat was the organization for me, it was laid to rest in the New Hire Orientation at Munich. To me, life at Red Hat was a breath of fresh air. 

Five things you need to know about Red Hat

  1. You truly lead your own career.

  2. Open Decision Framework (ODF) works. But it's often misunderstood.

  3. People Management is a whole different ball game.

  4. Situational leadership is the best foot forward.

  5. This culture bit is a big deal. And a lot more important than I had thought. 

1. You truly lead your own career.

I remember rolling my eyes - and seeing my teammates roll their eyes - at this statement. The reaction to this statement at times is, no not really. It's up to the manager, or maybe it's partly on me, but no, I don't lead my career. For me, I've realised that might have been because of the privilege of working at Red Hat. We have fantastic people managers who do so much for us, that we often forget that of course, my manager has a part to play in my career progression, but I can truly lead it, and if I do, I will progress.  The performance and development discussions, the competency deep dives, or any discussions centered around progress are really taken seriously here. While they can be  draining (or energising) and time consuming for both the associate and the manager, they've helped me tremendously and continue to do so.  

My thoughts as a manager

I've said it to my teammates on many occasions, my job as your manager isn't to make you happy or keep you happy; I'll fail at that. I believe my job is to ensure your well-being and facilitate your growth. My job is to provide you with opportunities for growth and stretching yourself and hold you accountable - as you hold me accountable to hold my end of the bargain - to what we agreed on. Now, not everyone is seeking a quick promotion, and not everyone is greatly interested in getting a pay hike. The growth bit may differ from person to person, and that's okay. The point is, you lead my growth story here. And growth doesn't make you or anyone else happy all the time, au contraire, it might just put you out of my comfort zone. But hey, in my view, that's how growth happens; one has to push oneself and have your manager keep you honest. 

My thoughts as an associate

Whenever I found things I am interested in over and above my current scope of work - doing a good job at your current role would be an important prerequisite to add here, unless I was not a good fit for that role - I've approached my manager/ mentor and have discussed things through. As my manager once told me, with some folks, there is only so much feedback that you can provide at that point of their careers and role (given they've become extremely proficient at it). What my manager focuses on is aligning our discussions,  my passions and interests to opportunities that can be presented to me. I've observed that as my work scope increases, not only does it provide me with more opportunities to learn (that's a polite way to say, I make mistakes and learn from them as it enables my manager to provide me with feedback), it bolsters my confidence. That's worked for me.  My own internal mobility success stories (four in total) are a testament to that assertion.

2. ODF works. But it's often misunderstood.

Wow, really? They're asking a large set of folks about what they think about a certain thing? How will they decide? Is it a vote, and the most upvoted idea wins? I was intrigued when I first heard of the concept of Open Decision Framework. I'd never come across anything like it in my career. I also had aspersions on how it would work, how efficiently it would work, or if it would work at all! I was so naive and new back then.

My personal experience with ODF

Despite having some inhibitions, I decided to take a leap of faith and employ ODF from the get go. As I was learning the ropes of program management in BXMSDocs, I realised that we would do well to jot down weekly status meeting notes. I presented the proposal to do so to my teammates, and detailed the pros and cons of it to them. While there were no objections to the idea of taking notes itself, there was a lively discussion within our team about the format and storage mechanism to use. Multiple options were brought forth; Mojo (Remember that thing?), Etherpad, Google Docs, Confluence Wiki, JIRA, Gitlab Merge Requests were all discussed. At one point, I remember taking a mental note of the time spent on discussing this matter - 37 minutes.

But I saw how animated, passionate and opinionated my teammates were (some were interns, mind you), and how opening this up for discussion led to understanding each others' needs, constraints and thought processes. Not only did this conversation make me respect my colleagues more, the foundation of mutual trust was formed.

I can't recall why we concluded that Mojo was our best bet for then. Was it the most ideal? No. Was it everyone's first choice? Heck no! Was it the best idea though and would it best serve the purpose? Yes! And you know what? That idea had come from an intern who's now a super Agile practitioner at Red Hat!  I learned how important and powerful this was, and pledged to employ it wherever feasible, and in all walks of my life. It has helped me build connections, mutual respect and rapport with my colleagues, family and friends.

There have also been times where post employing ODF, the burden of the final decision making has fallen on me because as in life, sometimes, there is no singular best idea but a few great ones. Someone has to decide, the team cannot be stuck in analysis paralysis, and even if it's not the most popular decision, most of my teammates have been open to accept it.

Having said that, I've had to remind folks - and myself too - about this not being a democracy but an inclusive meritocracy every now and then. One can only decide what's best by taking into consideration the factors and data points at that particular point in time. It's never a perpetual diktat and can and might need to be revisited later, and that's okay!

What ODF isn't 

  • In my view, ODF is at times grossly misunderstood, or misconstrued (without any malice, mind you) by many of us. We get swept in the wave of our own struggle to accept the decision and forget about the extremely important "assume positive intent" request.

  • If the decision that was finalised wasn't to your liking, or what you had chosen, it does not mean ODF was not followed. 

  • The burden of researching and finding out more about a decision - typically after a lot of time has elapsed since ODF was employed and the decision made - is on you, and not on the people who were involved in that decision making process. 

  • A decision that affects 17,000 fellow Red Hatters can't be revisited just because you feel so. Many intelligent and diligent colleagues who share the same Red Hat values have worked to proceed with those decisions; anything over polite dissent would be unreasonable and frankly, a tad disrespectful towards our fellow Red Hatters.

3. People Management at Red Hat is a whole different ball game

Having been in management outside and inside of Red Hat for a good 11 years - and counting - now, I can say with a lot of conviction that people management at Red Hat is… different. 

Management isn't easy

People management in itself is not for everyone; that’s no secret. I’ve had my share of challenges with it but I'd have loved to start my career as a people manager at Red Hat, and to a large extent, I did. There is so much great material available for folks considering management, to new managers, along with mentorship opportunities. 

My experience as a Red Hat People Manager

Look, let's be honest. It is imperative that I keep my team engaged, challenge them, provide them with opportunities and ensure their career is progressing, and this is not just from an ethical people manager's handbook; it also makes business sense. We hire, train and work with some of the sharpest minds in open source, and retaining those sharp minds is a priority.

However, the way Red Hat does this, is unique. Even as a manager, I don't have a lot of authority over my teammates. I cannot dictate what they will do, and micro managing managers are a rarity here as it just won't work; I've never met one in my career at Red Hat. The impetus is on influencing without authority, the onus is on me to showcase my abilities to my team so that they are confident in knowing I understand the job they do, I've been in their shoes, I can see their challenges, and that I have their back.

My primary job is to endeavour to keep my teammates engaged and communicate context to them about any broad discussions that are happening from a strategic perspective, and then clearly articulate what my expectations - usually in the form of requests - are from them. If I try telling them how to do something, it seldom works and I've had to check myself at times. I focus on the why and what; the how is on them. I've observed that by providing context, empowering my team, giving them space to falter, provide specific feedback and coaching, and ensuring they know they have my unequivocal support brings out the best in them. And of course, the same applies to my management chain up top. This does not change from first-line management to senior management and above. 

OMP ftw!

People management based on Open Management Practices has been a humbling, gratifying and enlightening experience. It has not only made me a more open manager, but I'm certain it has made me a better person. And quite frankly, I've seen my managers and the leadership in general exhibit the same OMP best practices.

The amount of time, energy and passion I see in my managers, and how they genuinely care for my career and are open to having lengthy discussions with me, work and partner with me to get where I want to, I've seldom seen elsewhere. 

4. Situational leadership is the best foot forward

I had read about situational leadership, but had very few examples of it being executed in the right spirit in my experiences away from Red Hat. Not only did it sound like an ideal to strive for, it also sounded like a pipe dream. Well, then Red Hat happened! 

Erm, situational wut?

Situational leadership is based on the premise that it's not just the managers that are leaders. Leadership isn't just a manager's prerogative; based on the situation, the requirements and expertise/ experience available, the most suitable person to lead a particular endeavour should be given the opportunity. If that happens to be an individual contributor or manager is of little consequence.

To lead - in my humble opinion - is at times to go to uncharted terrain and  make sense of it. At times, what's required is a vision, conviction and a healthy dose of optimism (and of course, if the situation demands, scepticism). However, there are times when you need experience, knowledge, and a set of skills best suited to get the job done. And it's not always what a leader or manager from their very narrow definitions might possess. And that's where Red Hat shines.

We are fantastic at identifying who the best person for a job is, and then get out of their way to let them go do their thing. Of course, we have check-ins, status calls and what have you, but the situational leader has the autonomy to proceed, the liberty to escalate and the support from their teammates that helps them deliver. I've learnt how to be a situational leader and how to identify folks for situational leadership from Red Hatters. 

I don't have all the answers; no one does. And that's okay.

There are many instances in the life of a manager or a leader, where they are uncertain, or they don't know, or they know as much as the other person. It can be a daunting realization, but at Red Hat, I've always found it easy to say I don't know. For sure, I've offered to find out if I can, or we find out together, or I point my teammates to folks I believe would know.

And if this involves a task worth doing, whoever is best suited based on experience, interest, enthusiasm, bandwidth, etc. is empowered to get the answers, or get the job done. It's truly wonderful to see this in action!

Inclusive leadership is tough, but totally worth it!

Being open, transparent and inclusive are the traits of any leader at Red Hat, and this is our secret sauce right here. Whoever is leading anything makes it a point to think about all parties that would be affected or need to be influenced based on the requirement, and ensures there are discussions and deliberations with that set of stakeholders. Hey, we're human too, and we might forget to include someone every now and then, but the intent is always to include and listen actively.

Active listening has been a revelation for me. Listening to understand, and not to respond was something I made a resolution of doing. And boy did that really assist me in broadening my perspective, and in turn, make me more inclusive, knowledgeable and open to differing viewpoints. 

5. This culture bit is a big deal. And a lot more important than I had thought.

I had read about and heard from folks about the unique culture at Red Hat, but didn't realise how telling, impactful and how huge a key differentiator it was until I experienced it myself. Through the informal email list called memo-list and through my discussions with my colleagues, within a month of starting at Red Hat, it was all too clear that while many organizations tout this culture thing of theirs, Red Hatters were the embodiment of theirs. Through their thoughts and their actions, I've seen our colleagues showcase the true Red Hat values of Freedom, Courage, Accountability and Commitment being the cornerstone of this culture. 

Now, many organizations have equally superlative terms they use to describe their culture but it's one thing to document it and a whole other thing to live it. To hold each other accountable for it, to ensure it flows through and into new Red Hatters, to seek culture fit but also culture add when hiring future Red Hatters (since part of our culture is to be diverse and inclusive). To call out if some of us momentarily forget what we stand for, regardless of what office one holds, and to be equally quick to forgive and assume positive intent and see the best in others.

For me, there is an inherent common DNA of a Red Hatter that perhaps drew me towards Red Hat. We are a bunch or scary smart, passionate about open source, highly opinionated, collaborative folks who truly believe that open unlocks the world's potential, and who aspire to be community first in all our dealings. This is what attracts the right sort of folks to Red Hat, and this is also what keeps them here. We've realised in these testing times during the pandemic where the uncertainty that's grating on our nerves, coupled by long periods of having to work in isolation have brought out the un-ideal in people. I'm also certain that if anyone can act quickly, efficiently and thoroughly to rid us of some issues related to diversity and inclusion, Red Hat is best poised to do so. I truly do. 

Not all things at Red Hat are lovely and wonderful, no. What is remarkable is that we are great at finding out what we suck at, and address it, as a group.  On many occasions, I feel we still have a startup, we're in a skunk-works mentality and with it comes the associated pros and cons. We aren't perfect, we know it, we acknowledge it, we call it out, and we work on it. But I digress; I'd rather focus on the things I learnt at Red Hat, found remarkable and those that had a far-reaching impact in my life beyond Red Hat (ain't got a shadowman tattoo for nothin'!). 

Well, that's about it. I'd love to hear more from you about what you've learnt from your time at Red Hat, and aspire to continue learning from it. I'd like to thank all my colleagues that I've learnt from and continue to do so each day; there are far too many to list here. I'm just grateful to have been given the opportunity to work at such a wonderful place with such a wonderful bunch of folks that I've come to admire, adore and befriend in these five years.

As my wife puts it, I'd do well to retire at Red Hat after many many years. Live long and prosper!    

Wednesday, March 31, 2021

Red Hatter Writes-Book key takeaway-Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less

I work at, live and breathe Red Hat, it is the best job of my life. Reading, learning and sharing are my passions. 

I'm currently on a reading (well, listening) spree as I catch-up on my must read/ listen to books during those long walks in the woods I'm indulging in. I had the chance to listen to the audio book: Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time by Brian Tracy. I have to admit, the book title had me intrigued as it brought forth memories of eating frog legs; an activity I am unsure if I'll ever partake in again. 

The book in itself is a lot of what we already know. However, it served as an apt reminder to me that knowing and doing are two different things. Here is my key takeaway from the book:

  • USE lists, in whichever form you prefer (paper, trello, papyrus). 
  • ABCDE ftw! Wut? Prioritise tasks using the ABCDE method-
    • A- Highest priority, highest impact tasks, must do
    • B- Medium priority, medium impact, should do
    • C- Medium priority, low impact, nice to do
    • D- Tasks you can delegate. But whichever you do delegate, please ensure their impact and priority is clear to the delegatee, so that they can ABCDE the task for themselves.
    • E- Low priority, low impact, can be removed from the list
  • The Six P formula- As an unabashed alliterations aficionado (see what I did there?), this brought about a chuckle.  Proper Prior Planning Prevents Poor Performance
  • If confused on how to prioritise as EVERYTHING seems a high priority, imagine you just learned you’re going on a surprise vacation tomorrow. What would you have to do before leaving? Those are the tasks you should take care of right away. If need be, seek your managers help with this. I do it often with my manager. 

And you know what? We're human. It's okay to acknowledge that every once in a while. The goal isn't to become the most productive person in the universe, this and parallel ones. The idea is to be more productive than yesterday, one step at a time :). 

Live long and prosper!

Red hatter writes: Book key takeaway-The upskilling initiative

I work at, live and breathe Red Hat, it is the best job of my life. Reading, learning and sharing are my passions. On my current PTO, I had the chance to listen to the audio book: The Upskilling Imperative: 5 Ways to Make Learning Core to the Way We Work by Shelley Osborne.

It talks about how in today's day and age, especially in IT, one needs to upskill themselves every five years to not become obsolete. At the pace at which tech is moving, employees prefer organizations that provide upskilling opportunities and have a robust system around it. This book talks about understanding the value of this initiative and creating one. Red hat in my view already excels in this area. One key takeaway from the book for me was to ascribe the deal hour acronym; the drop everything and learn hour. I personally aspire to do this each day and have often found myself learning or researching and absorbing new and complex information for hours. Encouraging this structured behavior and socializing it's benefits would be a fitting complement to the day of learning sessions we have quarterly. Continuous learning is a habit and like most needs to be cultivated.

Does it mean we whimsically decide not to attend a meeting or finish a task and start learning all about kubernetes? Of course, no. It's about looking at your calendar, and planning to block an hour a day to learn. I find having it as a part of my calendar--on most occasions--ensures I do find the time and inclination to learn each day.
Live long, and prosper!