It’s not common for departing IBMers to write a retrospective but I love the company and I had a blast there — through ups and downs — so I’ma do a retrospective anyway.
Taking cue from someone I have grown to respect, my time at IBM has taught me some important lessons:
Lesson #1: Solve the bigger problem.
Every time someone has asked me about promotions and how to get promoted, I have given them same advice I have followed myself “Solve the bigger problem.”
Corporate America is about solving problems, doesn’t matter what you think you’re doing, in the end you are solving a problem. Maybe you’re solving adding software functionality that lets someone do something that can’t do today, maybe you’re re-prioritizing projects to handle a resource challenge, maybe you’re figuring out who to assign an important project to because its a critical project with a lot of visibility, I could go on — but in the end they are all problems we are trying to solve.
And, your problem is part of a bigger problem that your manager or your team lead owns. For instance, if you’re adding some functionality to a software, your team lead may be responsible for the full software release — aka the bigger problem. If you’re re-prioritizing projects — you’re manager may be responsible for a portfolio of projects — again the bigger problem.
Wanna get promoted — solve your own problem and then work on solving the bigger problem. You’ll get promoted. It ain’t rocket science.
Lesson #2: Understand the why — First Principles.
Expertise comes in three forms: The What, the How and the Why. If you know the What — you can sit in a discussion, if you know the How — you can contribute to the discussion. . . . if you know the WHY — you can run the damn discussion.
Let me explain!
— Meh Expertise is when you know what something is. What’s vertical scaling vs horizontal scaling? What’s a Load Balancer? What’s a reverse Proxy? What’s a Hybrid Cloud Architecture? You can get a lot of “what” by reading. People sometimes call this being familiar with a topic.
— Okay Expertise is when you know how something works. How do you scale vertically — you add memory and compute and storage to a server, how do you scale horizontally — replicate the server, how do you configure a load balancer — it depends if its layer 3 or . . you get the point. You can get this depth by reading, discussing, asking questions, watching a video, trying stuff out. The last one — ‘trying stuff out’ is the best way if you have the opportunity.
— Real Expertise, I mean the kind at first principles comes from figuring out why something works the way it does, because when you understand the why, you also understand why it won’t work in other cases, and why it can be improved or why it can’t be — Why does horizontal scaling exist, why was it invented — because vertical scaling is expensive and if you want to scale at a lower cost, you put a bunch of inexpensive commodity server together and if one goes down, you still have others to keep your business up. So Why does anyone invest in vertical scaling? Because horizontal scaling has other tradeoffs — you have to implement software conscious of horizontal scaling, availability comes at the cost of consistency across servers, etc. Now, because you understand they why of scaling, when you implement vertical or horizontal scaling — you will think through the tradeoffs and ensure that they make sense in your situation. And, if someone asks you to improve your current setup, you will think through the limitations of the architecture and avoid wasting effort in futility.
Lesson #3: It’s okay to not know the answer. Really!
I am naively optimistic and that has carried me far in my career. I believe in my team, I believe in “where there’s a will there’s a way”, and I grew up with the leadership style where you don’t share your doubts or concerns with anyone — always be positive.
And, as I said, that carried me well till my last promotion.
Once I became a senior manager, the scope of my responsibilities increased enough where my success and failures had a measurable impact on the business. And this is where I learned (by failing spectacularly BTW) that while its important to be optimistic, it is equally important to share the risks with your stakeholders so we can collectively manage those risks and they don’t catch anyone by surprise. So if you’re not sure of the answer, or of the success of the project, or pf your ability to hit a milestone — whatever it is — be candid and share your reservations and risks with the stakeholders along with ‘why’ you still think the team can still succeed. Doesn’t matter how silly it makes you look — it’s better to be honest and look silly than let people down — especially the ones who trusted you.
PS: Someone advised me recently to put mitigation plans for the risks in addition to sharing then with your stakeholders, so not only is everyone aware of them, but the team is also ready to execute the plans if and when the risks materialize.
Lesson #4: Tahiti Plan aka teach your team to run stuff without you.
Once I get a good feel for a new assignment, I start thinking about how I would get all my responsibilities taken care of without me being there. As in, if I went on vacation to Tahiti for say 2 months, how would I make it so that my manager, my clients, my stakeholders, my team — no one would need me.
They can miss me, but they shouldn’t need me :)
You do this by teaching people how to make the same decisions, they come to you for. Ask your team to always bring you three things when they want you to make a decision — The problem statement, up to three Options to solve the problem and one Recommendation along with why this was their recommendation. The point is not to evaluate the team’s recommendation but to be transparent about how you think, discuss why you picked an option, and why they picked an option, and thus improve their decision making skills to the point where they can make the best calls under the circumstances — without you.
Once you do that, they will keep you in the loop, but you are no longer the bottleneck. You have time on your hands. A nice side effect of this strategy is that you can now go to your Boss and solve the bigger problem.
Lesson #5: If you are a manager — you’re an owner.
If you are a leader — then you have been given the responsibility to help the business succeed. Which means you need to understand how it works and what role your mission play in its success (or failure)
As always, you need to understand the Why. Why does your team and your product exist in the first place. What problem are they solving? Why is solving that problem important for your company, for your clients? What makes you and your team the best people to solve that problem?
In other words — Why does your mission exist?
To know this, you need to understand the fundamentals of running a business. You don’t need to be an expert in sales and marketing and product management and product engineering — but you need to understand the roles they play and how they come together to help a business succeed. Because, there will come a time when your business will not do well, and if you understand why these pieces exist, you will know where you can help in the best way possible. You don’t have to solve the problem yourself, but being able to recognize the problem, thinking through who can solve the problem, helping them solve the problem, all of it goes a long way.
Businesses do not succeed because of one area — but they do fail because of one area all the time. And you might not think you were the cause, and maybe you weren’t — but you sure as heck didn’t do anything to help either. And that is your job as a leader — To help the business succeed.
Finally,
when I first became a namanger, a really good friend of mine gave me a piece of advice that has stuck with me — Treat people like you would want to be treated.
That’s all I got. — Rob.
