How to be an effective leader [StoryTime Saturdays]
Big Tech Edition. Includes managers mostly from Data Science, AI, and Machine Learning positions.
To learn more about the newsletter, check our detailed About Page + FAQs
To help me understand you better, please fill out this anonymous, 2-min survey. If you liked this post, make sure you hit the heart icon in this email.
Recommend this publication to Substack over here
Take the next step by subscribing here. Share this post with someone who would benefit.
I’ve been talking to a lot of people,
Thanks to my writing and network, I get to connect with a lot of senior managers, developers, and upper-level decision-makers in Tech. These are people that run projects often worth millions (and sometimes billions) of dollars. Below is a video on how I met Fidel Rodriguez, a Director of Analytics at LinkedIn (and the former head of Google Analytics). He is one such individual I had the pleasure of learning from.
These are people with great decision-making skills and leadership abilities. People with a knack for identifying the correct course of action, managing difficult situations, and delivering exceptional results. I talked to these leaders about their experiences, processes, and most important learnings. In this article, I will be summarizing the many hours I spent talking to them and going over the common motifs that showed up throughout our conversations. If you’re a developer seeking to climb up the corporate ladder, a manager looking to step up your game, or someone that wants insight into how teams at the highest levels function, this article is for you. You don’t want to miss out.
Key Highlights
Promote Autonomy- One of the most prominent themes that I noticed throughout the conversations was the stress on promoting autonomy amongst your underlings (is that the right word in this context). As a manager, your biggest accomplishment happens when your team runs without your presence.
Define Processes, Delegate Implementations- Eventually, you’ll reach a level where your impact is not seen in the day-to-day. The decisions you make manifest themselves on larger time periods. As such you don’t want to waste your time and energy telling your reports what to do day-day. Set the agenda and standards, and let your underlings (I like this word) handle how that agenda is accomplished.
Foster an environment of communication- As a manager/senior developer/decision maker you want to foster an environment of communication. Remember communication is not just expressed through presentations and daily standups (if you want to excel at those, check this post out). Your code and documentation are also ways you express your thought processes.
Doing nothing is a strategy- There is a lot of value to doing nothing. Sometimes the best option is to sit back and wait to gain clarity. There is a lot of pressure to produce ‘tangible’ results but this can promote a culture of short-sighted ‘busy work’ where action is done to fill up time and not to accomplish higher results.
Simplicity is key in business cases- Often we mistake complexity for sophistication. When you can, you want to keep all business cases simple. All stakeholders must be able to articulate why a feature/project is a good idea. This might seem trivial, but this is crucial.
I hope you’re ready for this one. We’re gonna have a partyy tonight.
Promote Autonomy
When you’re lower on the hierarchy, the rules are set for you. You’re told what to do, and great places will make the evaluation criteria clear to you. However, the higher you progress up the ladder, the muddier the waters get. Suddenly you no longer get direct tasks (“improve accuracy”) but vague end results (“improve customer retention”). Achieving these directives requires an ability to zoom out and look at the various facets of the solution you are working on. You can’t do this if you’re micro-managing the day-to-day.
Whenever you can, create the spirit of autonomy in your teams. By letting your reports have their autonomy you hit many benefits at once-
You improve their experience of working under you. No one likes micro-managers.
You free up your time and energy to study the larger trends, allowing you to make much better decisions. You can also then focus your efforts on the areas where you are needed the most.
You give the people working under you the ability to grow and tackle challenges. Not only will they do a better job than you would (since they do it day-day), but they will go on to develop better skills. This will allow them to thrive, strengthening your position and network.
There are several ways to promote autonomy within your teams. So many that I will do a separate post on them. However, I will mention two very powerful ones right here. Take note of them, and implement them immediately.
Firstly we have a very important one for the tech industry- don’t punish mistakes. This was quite interesting to listen to because Big-Tech is notoriously cut-throat when it comes to firing low-performers (leading to a very high burnout rate). However if you want to inculcate a culture where people are comfortable going out and taking charge, then you want to create a culture where they feel safe to take risks. Remember that we’re fear potential loss much more than we love gain (about 2.5x more). If your employees are scared of making mistakes, then they will be hesitant to take charge, no matter how lucrative your bonuses are.
Instead, you want to treat mistakes as learning opportunities. A senior AI manager from Amazon told me that his team had a simple policy for mistakes/errors- mistakes would not be penalized if the person who made it documented their mistake, analyzed what caused it, and how it would be avoided in the future. This approach is great because it allows people to learn from their (and other people’s) mistakes. If you start building internal productivity tools, then having such a log will also help you design the best tools.
Secondly, you want a lot of clarity in your teams. You want to make ownership of ongoing projects very clear (who is responsible for what etc.) You want to create documentation that makes business goals, end customers, priorities, and rationale very clear. This allows your team members to read through and find areas to attack on their own, without you needing to hand-hold. If something is a huge priority, you can always just stress that in your documentation/communication channels. This way your team will know what the direction is and take steps to align themselves appropriately. These two will make an immediate difference to your team’s autonomy.
However, autonomy has its drawbacks. Sure it allows your team members more freedom to go out and try solutions, which improves the rate of innovation but it also creates a fundamental problem- it can lead to chaos. Not having quality checks and standard protocols can lead to failure and inefficiency in large-scale projects, where people might not have the time to check for every edge case. This is where the next learning comes in.
Define Processes, Delegate Implementations
To balance autonomy, you also want to impose strict standards and quality controls on your team, so that every part of your pipeline/user experience is amazing. In such a case, what can you do? Burn out by spending a lot of time and energy making sure every little thing is perfect or focus on the big picture and risk missing a crucial detail till it’s too late? This is where I will call back my conversation with Fidel Rodriguez, a director of analytics at LinkedIn. Fidel walks the fine line between control and autonomy perfectly.
Strong Like Bamboo. Flexible Like Bamboo.
-How a coworker described Fidel’s management.
Fidel handles this tension by setting clear processes/directions for his team and then leaving the day-to-day details to them. He’s very strict about making sure that the quality control checks are met. But as long as they are met, Fidel isn’t going to worry about the day-day. Fidel mentioned two processes in particular that he is strict about, that all of you should implement-
Gemba Walks- This was a new one for me, but when Fidel described it, I found it brilliant. Imagine your team has built a feature. Before shipping it out, have a complete outsider ask you questions about it. They can ask you whatever they want. This will help you see the feature as an outsider would, which can be crucial in identifying improvements/hidden flaws.
OKR- When Fidel first mentioned this, I laughed a little because I associate this with HR. OKR stands for “Objectives and Key Results.” OKRs are typically written with an Objective followed by some supporting Key Results. An example would be, “I will optimize this API to reduce the error rate by 1%, reduce latency by 100ms, and reduce overhead per call by 0.5%” This article is a great guide on them. This gives a lot more clarity and direction to the team while adding more accountability overall. And in trying to achieve these goals, you and your team will learn a lot about the architecture of your solution, giving you more potential for amazing results.
We’ve already mentioned the amazing benefits that come with letting employees have their autonomy. By implementing these processes (and other quality control checks), you will maintain the integrity of your product/platform.
Once again, this would require a very strong mutual understanding where everyone understands exactly where the project is headed and why. This requires communication. Lots of clear communication. So how can you promote this in your team? Let’s cover that.
Communicate Obsessively
One of the most striking parts of talking to the managers was how they put a lot of emphasis on communication. This passion showed through some of the other processes that they made sure that their teams did before they even started working on the projects. For example, Fidel put a large emphasis on bi-directional communication. What does this mean? Fidel first makes sure to have 1-1 meeting with all the stakeholders in a project/venture to understand their needs and wants very well. He then takes time to sit with his reports and share these needs in great detail, taking input from their end. These inputs can then be used when shaping strategy and setting long-term goals. By doing so, the whole organization is aligned as one, and things progress smoothly.
However, you want to also make sure your team has fantastic asynchronous communication. Too often people only associate async-comm with text messages and leave it there. For example, your overall documentation should include information of why products exist, what problems they solve, etc. I’ll do a more detailed writeup on them this Tuesday. For now keep in this general principle- a developer should have a reasonably good overview of a product and how it aligns with the larger objectives just by reading the documentation. This includes a lot more than just the code and the technical details of the internal APIs. Speaking of code, use the following guide to create better comments in your code.
All of this adds a lot of clarity and direction to the overall project and team. Which are important enough that I will now take some time to discuss them. And why the way many people rush into projects without doing the prep work is a terrible approach.
Doing nothing is an option
It’s easy to want to rush into projects, solving things as they come. Especially in Tech, where things move extremely quickly. “Move Fast, Break Things” is a Silicon Valley slogan. While speed has its place, it’s not the smartest idea when starting/working on huge projects.
Remember, if something has a huge scale, it will be harder to fix/change once you do send it out. Especially if you do things in a very ad-hoc manner, where things are fixed as they come up. I’m not saying that you have to go into every little detail in your preplanning. I am telling you that rushing blindly into large-scale ventures will burn a lot of money and energy.
While it can be annoying to take time doing meetings, brainstorming sessions, and other HR-y things, they did become staples for a reason. We’ve already covered how these sessions can boost developer productivity, by giving the team a clear and coherent direction. However, taking it slow and doing the prep work to gain clarity can also save a lot of resources in the long term. However, you want to make sure that your compensation structures account for this.
Many evaluation cycles are based on actions taken during a quarter, which can put some pressure on people wanting to show results. This leads to people doing short-term work (which is also much easier to measure) to get those bonuses/not get cut from the company. Remember, in many cases, less is more. If you’re involved in doing a lot of fixes, you will not have the mental space and energy to create the most impactful fixs. Chris Laffra noted during his work boosting developer productivity at Google. If you want to know more, check out the following post. Keep in mind, I wrote that post a while back, when I wasn’t as experienced at writing such posts. So it doesn’t flow as well as my current writing. But hey it’s a process and if you’re one of my premium subs from back then- thank you for supporting me as I get better. I’ll repay your trust with the best content on Tech.
Instead of this constant, hamster in the wheel style of finishing tasks, you want to encourage people to do nothing. Take a step back, look at the big picture, and work on the most impactful problems. This will lead to a much more impact while protecting everyone working under you from burnout. There is no benefit to making your underlings do more just to keep them busy.
To tie all this together, we will cover one final piece. This piece is a great rule of thumb in defining your (and your team’s) vision.
Simplicity in Business Cases
It’s easy to mistake complexity for sophistication and elegance. Don’t make this mistake when it comes to creating your products. I already talked about how everyone on your team should be able to explain how what they do fits into the big picture. But I want to hammer this home when it comes to your monetization strategies.
This world and finance setup has made it very possible to achieve billion-dollar valuations while selling worthless/unsustainable products. Regular readers of my Finance Fridays will be able to recall several examples. Silicon Valley has a penchant for putting Lipstick on a Pig and calling it Marylin Monroe. This is made worse by all the clickbait (done by both mainstream media and gurus online) that sells you sensationalism and castles in the sky. Don’t create solutions that engage in this system.
When you create solutions, you should be able to very clearly state how this will help you make money/achieve your goals. The simpler and more direct your plan, the better this particular product is. The utility and path to monetization should be as simple as possible.
Notice that this doesn’t mean that it has to be easy. Creating the next amazing pharma drug is not an easy process in any way. However, the utility of a drug is clear to all. When you can, work on products with obvious and far-reaching utility. These are the products that survive recessions.
There were many other lessons that I will continue to share in my upcoming articles. If any of you are interested in sharing your experiences, you know how to reach me. I’d love to talk.
Loved the post? Hate it? Want to talk to me about your crypto portfolio? Get my predictions on the UCL or MMA PPVs? Want an in-depth analysis of the best chocolate milk brands? Reach out to me by replying to this email, in the comments, or using the links below.
Stay Woke. I’ll see you living the dream.
Go kill all,
Devansh <3
Reach out to me on:
Instagram: https://www.instagram.com/iseethings404/
Message me on Twitter: https://twitter.com/Machine01776819
My LinkedIn: https://www.linkedin.com/in/devansh-devansh-516004168/
My content:
Read my articles: https://rb.gy/zn1aiu
My YouTube: https://rb.gy/88iwdd
Get a free stock on Robinhood. No risk to you, so not using the link is losing free money: https://join.robinhood.com/fnud75
brilliant and incisive