Sign in Subscribe
Leadership

Back to IC

Swaroop Chitlur

• 6 min read

Two and a half years ago, I wrote about Engineering Management : Lessons learned in first year.

It’s been more than a year since I have been back to an Individual Contributor (IC) role. So I have been reflecting on that.

Why the switch back to IC?

So why the change from management career path back to individual contributor career path?

  • I liked the EM experience, and at the same time, I wished to be more hands-on on some of the projects that the team was doing. Switching back to an IC role would help satisfy that desire.
  • Because I read Charity Majors’ The Pendulum or the Ladder and chose the pendulum. I’m grateful to Charity Majors for writing such a great perspective, because it made me conscious of the choices in front of me. As I said, I chose the pendulum, so I will eventually be back in a management role if and when that would be useful to the team I will be in.
  • Because I was inspired by Keavy McMinn’s Thriving on the Technical Leadership Path. Keavy’s description of “What does the strategic work of a very senior engineer look like?” resonated with me.
  • From Charity Majors – The Engineer/Manager Pendulum: The best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management. And the best technical leaders in the world are often the ones who do both. Back and forth. Like a pendulum. So these tech leads usually spend more time in meetings than building things, and they will bitch about it but do it anyway, because writing code is not the best use of their time. Tech is the easy part, herding humans is the harder part.
  • Plenty of room to grow, career wise
  • From Charity Majors – Questionable Advice: “After being a manager, can I be happy as a cog?” Leadership is primarily exercised through influence, not explicit authority. Senior ICs who have been managers are supremely powerful beings, who tend to wield outsize influence. Smart managers will lean on them extensively for everything from shadow management and mentorship to advice, strategy, etc. (Dumb managers don’t. So find a smart manager who isn’t threatened by your experience.)Shouldn’t technical people be responsible for technical decisions, and people managers responsible for people decisions?Oh and stop fretting about “competing” with the 20-somethings kuberneteheads, you dork. You have been learning shit your whole career and you’ll learn this shit too. The tech is the easy part. The tech will always be the easy part.
  • No Regrets: My Time in Management Wasn’t Wasted — Joy Ebertz
  • Companies like Dropbox reserve first-level engineering manager roles for internal promotions only, as an incentive to senior engineers, since the role is limited in number.

To be clear, there is real value in having a great manager, and I aspire to be that someday. For now, I choose the pendulum.

Struggles so far

Transitioning from technical leader to technical leader has been challenging.

Interestingly, I believe that whenever I learn to handle these challenges, it’ll benefit whenever I choose a EM opportunity as well.

Be the Problem Finder

From “3 Phases of Career Growth”:

The difference between a senior engineer and a staff engineer is one of solution finder vs. problem finder.

I still struggle with defaulting to “solution finder” mindset.

I am trying to consciously dedicate separate times for the “solution finder” mindset vs. the “problem finder” mindset.

What does “problem finder” look like? Anticipating future issues, talking to customers (can be internal customers or internal proxies) and anticipating future opportunities, synthesizing a roadmap, building in phases that each have physical visible measurable impact, etc.

Think like a Product Manager. Execute like an Engineer.

From User Story Mapping book:

  • With a grateful nod to Ben Horowitz’s Good Product Manager, Bad Product Manager, here’s a glimpse into some of the important differences between strong product teams and weak teams:
  • Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.
  • Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.
  • Good teams understand who their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that not only work for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.
  • Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps.
  • Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something.
  • Good teams have product, design, and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective functional areas, and ask that others make requests for their services in the form of documents and scheduling meetings.
  • Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and the brand. Bad teams are still waiting for permission to run a test.
  • Good teams insist they have the skill sets necessary to create winning products, such as strong interaction design. Bad teams don’t even know what interaction designers are.
  • Good teams ensure that their engineers have time to try out the discovery prototypes every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate.
  • Good teams engage directly with end users and customers every week to better understand their customers, and to see the customer’s response to their latest ideas. Bad teams think they are the customer.
  • Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap and are satisfied with meeting dates and ensuring quality.
  • Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough.
  • Good teams make high-integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will actually work for the customer and the business. Bad teams complain about being a sales-driven company.
  • Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a “nice to have.”
  • Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful integration phase and then release everything at once.
  • Good teams obsess over their reference customers. Bad teams obsess over competitors.
  • Good teams celebrate when they achieve a significant impact to the business KPIs. Bad teams celebrate when they finally release something.

Design Docs and Mastering Calendar is technical leadership

Learn to Balance

I am still struggling with this. Will. figure. it. out. someday.