Being an “Intrapreneur” as a software engineer
Building skills useful as entrepreneurs, while also shipping more, and helping your career inside a tech company
Question: “I’m a software engineer at a larger company. How can I build the right skills to thrive in my current role, while also setting myself up for success in today’s tech market?
We’re not in a great job market, these days: Big Tech is becoming more cutthroat, with cuts and stricter performance reviews, while job openings are at their lowest for several years. With recruitment tight, setting yourself up for career success in your current job makes sense. In such a context, there’s a useful skill to help with this in your current job, or in a new job at different company, and it’s also invaluable if you decide to launch your own business, like founding a startup or launching a bootstrapped company
That skill is "intrapreneurship". It’s a word combining “internal” and "entrepreneur” and I first heard of the concept from Chaitali Narla, a seasoned engineering executive who was at Google for 15 years, and recently became CTO of Glid, a startup aiming to shape the future of road-to-rail transport. She also runs her own business, ChaiTime, coaching engineers and engineering leaders on how to stand out in their careers.
Today, Chaitali covers seven habits of “intrapreneurs”:
Run towards problems, not away from them
Take end-to-end ownership to land the solution
Invest in cross-functional relationships
Get sponsorships
Don’t fear “no”
Make impact visible
Do everything, everywhere, all at once
By the way, Chaitali runs an online, week-long course for senior+ individual contributors called Outstanding: get the ratings, recognition & sponsorship you deserve. If you like to learn as part of a group, why not take a look.
Reading on this topic:
With that, it’s over to Chaitali:
I joined Google as an intern while earning my Master’s in Computer Engineering. After graduation, I accepted a full-time offer and spent 15 years at Google, moving from intern to director via 5 promotions in the first 10 years. During this time, I worked on Google products, including:
The social graph backend that powered social features across major Google services
Chrome browser
Compute Engine on Google Cloud Platform (GCP)
Google Workspace, including Gmail, Docs, Drive, Meet, and other collaboration tools.
I was an IC for my first 6 years at Google, then in a hybrid tech lead/manager role for 2 more, and was a senior manager/director for the rest. This article covers tips and learnings as they apply to ICs and managers alike.
The theme of my journey can be summarized in one word: “intrapreneur”. It’s a portmanteau of “internal” and “entrepreneur” and a style of leadership I’ve used over and over for my own career success, and that of tech professionals whom I’ve coached. Today, I’m sharing the seven habits of intrapreneurs, along with examples and tips for incorporating them into your own career.
Let’s start!
1. Run towards problems, not away from them
The best Staff+ engineers I’ve worked with are always ready to run towards problems, and I’ve also used this strategy of seeking them out in order to grow my career.
Follow friction. This is one way to find impactful problems. In many growing tech companies, some tasks get pushed aside for the sake of priorities, and many will cause inefficiencies over time. So, look for activities your team keeps doing over and over, which may be helpful to automate. Identify areas where your team feels frustrated due to missing features.
For example, in my first year at Google, I worked on the Contacts team. This team later supported social features across Google products like Ads and Gmail. We had a lot of “data seeders” in our development environment, used to populate synthetic data like:
User names
Emails
Addresses
Birth dates
… and other data required for contacts
Data seeders also created “fake” social graphs by simulating a few interactions between test users, like sending an email, or liking a post. I noticed friction, like that testing features was often a challenge because our data seeders just weren't good enough. For example, the average GMail user back then sent around 3-5 emails a day and had circa 25 contacts in their list. Our data seeder would only create one email connection between 2 test contacts, which was very far from the average case and certainly didn’t help test the boundaries of our products.
I wrote a proposal to highlight this problem, proposing to create a large library of synthetic data based on aggregated, but real, user characteristics we knew about, like the email sends and contacts list. I proactively talked to many Senior and Staff Engineers for feedback, and to iteratively refine my design. In parallel, I worked with my management chain to convince them of the value of this proposal, so I could secure their buy-in.
“Just do your assigned work” is not always the best career advice. The general career advice I’ve heard many times is to keep your head down and do your best at the assigned work. But this advice has baked-in assumptions that may not be true. For example, your manager might not know the bigger picture, they may not understand your full skill set, or could also miss details, like development friction caused by poor data seeders.
Intrapreneurs create their own job descriptions by looking for high-impact problems to solve and then owning the solution. Remember, securing buy-in from your management chain for your intrapreneurial ventures is part of the package!
2. Take end-to-end ownership to land the solution
As an engineering director at Google, I received pitches from engineers about problems we needed to solve, daily. Occasionally, a few demonstrated the quality of running towards a problem, not away from it, by volunteering to tackle problems, instead of complaining about them. However, what really set seasoned intrapreneurs apart was their commitment to owning a problem from start to finish.
When I led the developer infra organization on Google Compute Engine, we noticed the problem that hundreds of engineers wasted an hour or more, daily, on setting up or resetting a Google Cloud project. They did this long setup in order to work with their development setup, just to build and test their code!
One senior engineer on my team suggested building a service that would “rent out” preconfigured Google Cloud projects. This service would maintain a large pool of clean, ready-to-use projects. Engineers could “rent” these projects for a fixed period, use them for development, and extend the rental if needed. If they didn't request an extension, the project would be reset and returned to the pool once the time expired.
This senior engineer owned the problem from end to end:
They identified a source of friction
Proposed a solution
Implementation:
Designed the solution
Implemented it
Worked through many edge cases and connecting problems
Shipped it!
This engineer did thorough work: for instance, the Google Cloud project APIs required changes to allow for programmatically performing the "clean state" reset. Determining the ideal rental time period involved a social exercise, as it had to balance engineering productivity with the purpose of the service.
This engineer also convinced fellow devs to change their usual workflows. Hundreds of engineers needed to change their development workflows to use the rental system, instead of maintaining their own projects. Convincing devs to change their ways is not always easy, but in my observation, an engineer can do a better job as a “peer” than a top-down mandate does.
This engineer built a strong reputation for outcomes. Owning the work end-to-end, and their strong standing among peers, led to higher performance ratings during performance calibrations, a rapid promotion to Staff Engineer level, and the chance to choose exciting, high-visibility projects for years.
3. Invest in cross-functional relationships
Many engineering careers stop progressing at the level where cross-functional stakeholder management becomes a baseline expectation. This is because many professionals only focus on working within engineering, but successful businesses have many different functions. Engineers who dare to step out of their comfort zone and learn to work with cross-functional peers like product, design, legal, marketing, and others, are rewarded with outstanding performance ratings and accelerated promotions. Here are some things I've learned from working on various projects with stakeholders in engineering, product management, HR, Legal, Finance, and more.
Answer “what’s in it for me?” for every stakeholder
Your non-engineering partners on a project focus on different things. For example:
Product might focus on business growth
Legal might concentrate on business risk
Finance may ask whether a project will affect budget
Consider the perspective of each discipline. Create customized pitches to win their support. For example, when talking to my product partner about our Python 2 to 3 migration project, I emphasized that not completing this quickly endangered feature releases in the near future, which would in turn jeopardize upcoming enterprise deals dependent on them. That helped me secure their sponsorship in making the project a top priority for the organization.
Know that different seniority levels want varying levels of detail. This is true for your own engineering management chain, as well. Be prepared to provide more or less information, as needed. For example, when pitching a new project to a Director or VP, include a short summary explaining why it’s necessary, what business goal will it affect, and the cost in terms of time and headcount required. But when discussing the same project with Staff+ engineers, you might focus on details of the tech which currently exists that you can use or repurpose, and what needs to be built from scratch.
Take time to determine the most effective way to deliver your message, whether it's in person, in a document, through a presentation, or email. The most effective way varies by context, so this is where your social skills and knowledge of company culture are important: Is there a director who needs to approve your project? Find out how they consume information. Do they like live eng review meetings where you read a six-pager, discuss it and seek approval, or do they prefer an offline document to read and respond with comments?
Become a “translator” for the engineering team
One of my most memorable meetings was a critical cross-functional one about a privacy-sensitive feature. Our engineering lead spent half an hour showing complex block diagrams and code snippets to a roomful of product, design and legal folks. As I watched, their eyes gradually glazed over. Then, one of our lawyers suddenly interrupted:
"So if I understand correctly, what you're saying is..."
… and this lawyer quickly summarized the technical problem and possible solutions in under a minute, even identifying the legal requirements we'd need to check. That lawyer was what I call a "translator". You can become one by taking the time to learn about functions next to engineering. You don't have to become an expert, but building a better-than-basic understanding of these functions can really help.
Here are some ways I have seen engineers become translators:
Understand Legal. Understanding the legal aspects of a regulation like the Digital Markets Act (DMA) so you can connect the dots to the technical changes your products need, and why.
Understand Accounting. Understanding how software accounting works from a finance perspective will help you understand how tax code changes like the 2017 change to Section 174 affects the tech industry and possibly your team’s resources. One helpful resource is Accounting for Developers by Modern Treasury.
Understand HR. Understanding how HR processes like calibrations and promotions work in your company will help to position your own accomplishments for the best outcomes.
Understand other business lines. I’ve listed Legal, Accounting, and HR because my team worked a lot with these businesses. Understand those business areas which your engineering team interacts with, such as Customer Support, Marketing, or any others as relevant.
Build cross-functional networks before you need them
During my first three years at Google, I spent a massive amount of time on hiring, doing 2-3 interviews a week – but I wasn’t even a manager! And on top of interviews, I signed up for several campus visits: some included meeting students at a career fair booth, others involved interviewing 5 to 7 of them in a day! I also hosted interns every summer until I became a manager.
From one perspective, this might seem like a waste of time; I could have spent that time and energy on other technical projects which might have shown more impact and helped my career grow faster.
But time spent on “non-core work” gave me an extraordinary advantage, later. Spending so much time on hiring turned out to have a big return on investment (ROI): when I became a manager a few years later, I knew Google’s hiring process inside out, which helped me hire external candidates quickly.
Thanks to having done hundreds of interviews by then, I could spot good candidates early, and helping recruiters had earned me goodwill, and some great friends. They were all happy to assist me in hiring the best for my team. Lastly, those interns and early career hires whom I helped? They became senior engineers totally happy to do an internal transfer to my team!
4. Get sponsorships
Whenever I mention sponsorship, many people instantly think of promotions. But this is not how I think about it.
 | A guest post by
|