How to Build a Strong Career in Tech

This is an expanded version of the transcript of the talk I gave at The Conf last year.

The original title of my talk was "Career Abroad - How the best Technologists are conquering the World",?but after receiving some feedback, I decided to change it to?"How to Build a Strong Career in Tech?"?as pretty much all principles, practices, and ideas listed here can be applied to the career of any professional in tech, not only those that are trying a career abroad.

TALK ABSTRACT:

Whether you have just started or are already working in Tech for a couple of years, I'm sure that you have asked yourself the following questions:

• How does a Successful Career in Tech look like??
• What separates World-Class Performers from everybody else?
• How can I take My Career to the Next Level?
• What can I do to become More Valuable to my company??
• How can I Get a Job Abroad?

Back in 2007, I had the same questions, but I could not find the answer to most of them. There was not much out there in Portuguese. (Yes, I only got to learn English much later on.)

Today, living and working in New York City for the past six years, I would like to share the advice that I wished I had received 10+ years ago when I started my career as a Software Engineer in Tubar?o, Santa Catarina, Brazil.

I'm currently writing a book about Career Abroad in IT. For that, I'm interviewing a total of 50 Successful Technologists working on the Top Tech Hubs Around the World.

DISCLAIMER ON DIVERSITY:

I'm aware that most of the examples in this article and the professionals I interviewed for my book lack diversity. Most of them are white males. I acknowledge that it was a big blind spot on my side till recently.

But, I'm actively working to change that. If you know anyone from a minority group that is originally from a developing country and you consider them to have a successful career in Tech abroad or in their home country, please send them my way. I would love to interview them and include their career stories in my book.

SIDE NOTE:

This article's structure is inspired by the extraordinary blog post that @Tanya Reilly, Principal Engineer at Squarespace, made out of her talk "Being Glue". I really liked how Tanya combined the slides with an expanded version of her script and turned it into an outstanding reading.

* By the way, if you have not watched Tanya's talk above, I strongly recommend it. It is about how sometimes doing the less-glamorous - and often less-promotable - work that needs to happen to make the team successful might hurt your career, especially early on in your career journey.

SLIDES:

Hi, I'm Thiago Ghisi, and in this article, I will talk mainly about Career in Tech. Career Abroad will be subject to another article.

But before I get started, I want to say that I don't consider anyone to be more or less successful just because they work abroad or only because they work in New York or in the Valley. I believe that these days it doesn't make a difference. I have multiple friends and former-coworkers that, even with numerous invites to move abroad, decided to stay working in Brazil or remotely from Brazil to companies elsewhere.

Who am I to talk about this subject?

Over the past five years, I have interviewed 200+ Engineers, Tech Leads, Engineering Managers & Directors for the companies I worked for, initially for a small startup based in NYC and lately for a Fortune 500 company also based in New York. More recently, in 2018, I have helped our mobile engineering department double the size from 50 to 100+ engineers hiring talents in some of the most important tech hubs across the globe: New York, London, Singapore, and, of course, many talented Remote engineers. I did 120 interviews alone in 2018.

Also, as an Engineering Manager and now Engineering Director, I have helped 5 Engineers reporting to me to get promoted to Senior Engineer within the company's career framework.

Lastly, these opinions are all mine, not from my employer.

Shame plug, I'm also currently writing a book about Career Abroad in Tech, and I'm interviewing super successful professionals working in Tech in the Global Top 30 Tech Hubs. I have already talked to 10 of them, and I have 20 more to go. I can't wait.?

This initiative aims to initially help Brazilians (and ultimately also folks from other developing countries from Latin America, Africa, and South Asia).?

The goal is to help software developers thinking about going international with their careers in two ways:

1. Effectively grow their careers by providing a framework on how to assess their current level, identify their main skill gaps, and highest impact opportunities finding the best use of their time to go to the next level.
2. Strategically plan a move to one of the 30 global cities on the top of many super valuable lessons learned from other prolific people that already live and have built a successful career in those locations.

Enough about me and my project, let's get into it.

Today, living and working in New York City for the past 5+ years, I would like to share the tips that I wished I had received 10+ years ago when I was starting my career in my hometown Tubar?o, Santa Catarina, Brazil.

The very first question that I want to ask is: How does a Successful Career in Tech look like?

Structure of this article:

1. My Definition of a Successful Career
2. The Framework: How to measure your skills and how to compare your contributions against your next level
3. The Career Accelerators or "Hacks" that have helped many successful people I interviewed to advance throughout their careers

Part I - Definition of Career Success

So, going back, what is career success to start with?

My answer is based on the professionals I talked to in my book, the most successful professionals I interviewed for my previous and current company, and on my own experience working with hundreds of developers over the last 15 years.

Let's take a look at a few super successful professionals (to my standards) and see if we can find things that they have in common:

• What does @Martin Fowler (the famous author of Refactoring and many other influential books) have in common with @Linus Torvalds (the principal developer of the Linux kernel + creator of git)?
• What does @Matz (the Japanese programmer that designed Ruby) have in common with the famous author and VP of Engineering at Slack @Michael Lopp?

On the Brazilian side of the equation:?

• What does Alberto Silveira (VP of Engineering in New York) have in common with Sandro Mancuso (author of Software Craftsmanship and founder of a company "Codurance" in the UK)?
• What do the two guys on the bottom right (Paulo Caroli and Jose Valim) have in common???

They are all authors, speakers, or have created successful languages/open-source projects. But, is that it??Do you have to be a successful speaker or author to be considered successful in Tech??

My answer is no, not necessarily. Let's do a quick analysis this time, looking at a few common patterns of resumes and career trajectories in Tech that I have observed.

John - Resume Example 1:

This is the typical example of what is often called a 10-Page Buzzword Bingo Resume with many corporate & technology jargons, lots of unquantifiable adjectives such as Highly-Creative, Hard-Working & Deadline-Driven while holding pretty much the same position and a list of all software tools they ever worked with listed at the beginning and at the end of the resume. They often put the same weight on all technologies they ever worked with, from Programming Languages to Frameworks, simple libraries to basic software. From Microsoft PowerPoint to Lisp, everything is listed on their resume.

Question: Is this what a successful career in tech looks like??

My Answer: (Initial Reaction) "No way!". But, to be honest, it could be a maybe:

If this person started in a super small company and evolved to more significant or challenging companies over time, they moved abroad and are working at Google or to any other cutting-edge Tech company for the past 15 years. And they have not updated their resume in the last ten years; I would say yes.?

Or maybe if it is someone who maintains open-source projects or has a company on the side and is working at the same company for ten years as a software engineer mainly to pay the bills while building something bigger.

But, usually, My Answer would be: "No, that doesn't represent a successful career in 99% of the cases in my experience.

Why?

Not a lot of career progress or growth. It is the classical representation of a "Stalled Technical Career". @Mark Horstman (co-founder of manager-tools.com) has an excellent episode on this.

Paul - Resume Example 2:

What about this one?

Constant technical career progress, a transition to management, and growth over time.

Question: Is this what a successful career in tech looks like??

My Answer: "Yes, that is a lot closer!" But, it could be a maybe too.

Quoting a previous boss of mine that was a VP of Engineering in multiple companies in the Bay Area and has hired hundreds of developers:

"The candidate resume metadata doesn't often lie." – Former boss of mine

The same way that we can spot bad code just by looking at the visual shape of a particular file, he was a strong believer that once you read enough resumes, interview many people, and most importantly, work with a lot of different professionals that you ended up hiring, you can also quickly scan and distinguish a bad resume from a resume worth digging into. Pretty much as code, you can only tell if a class or a function is really good after you zooming in and analyzing for a bit, but you can tell from a distance if a code is not good with a high degree of confidence.

Why?

It seems to be someone that is continuously growing and taking up bigger and bigger challenges. For sure? Not for sure. You will only know that after interviewing or even only after working with this person for a while.

@Adam Tornhill has a fantastic piece about Complexity by the Visual Shape of Programs in his book "Your Code as a Crime Scene".

George - Resume Example 3:

What about this one??

Strong technical career progress, a transition to management then a move back to the Tech Track, and more progress in the last couple of years.

Question: Is this what a successful career in tech looks like??

My Answer: I would say Yes! Likely.

For sure??

Definitely not for sure; you will only know that after interviewing or even only after working with this person for a while.

Why?

It seems to be a person who took on different types of challenges, different responsibilities, was able to recognize that perhaps the management side was not for him, and went back to the technical side and kept growing. Back and forth.

@Charity Majors wrote a superb article demystifying and highlighting the benefits of treating a tech career as a pendulum - almost like a seesaw - between two parallel tracks of professional growth: the technical track and the managerial track. You can only be effective as a manager if you really understand engineering. You can only be effective as an engineer if you really understand management. Back and forth.

What do all those people have in common?

What does the resume metadata show you? What do those resumes have in common?

Ever-Growing Impact & Influence:

My answer: Impact of their ideas on a large number of people directly or indirectly. Success = Impact & Influence! Or, ever-growing levels of Impact and Influence.?

Impact is the key here as it is almost impossible to sustain influence in the long-term without making a continuous impact.

Keep in mind that when I'm talking about influence here, I'm not talking about authority or forced influence. I'm not talking about the person who has influence as a supervisor or someone with power due to their tenure in the company.?

I'm talking about influence without authority. I'm talking about the person you want to bring in for any discussion, review all your pull requests, interview new people, and facilitate any conversation.?It's the person that you and your team know that you will be much better off after talking to. It's the one that always has a well-balanced view and helps everyone to get to a more robust solution.

I'm not talking about the arrogant know-it-all engineer; I'm talking about the master who would never call herself or himself that. It's the name that comes up when you say I really wished _______ was here today to help me/us to navigate on this problem.

When I'm talking about impact, I'm not talking only on generating more revenue or reducing costs in the short-term; I'm talking about impact in every aspect, even if tiny at first, but that will almost compound and multiply over time.?

For example, it's easy to acknowledge the impact when someone goes on and creates a new architecture that reduces the response time of the main homepage by 50%, which has a massive impact in the short-term, and it's straightforward to quantify.

But, what about the repetitive and sometimes not so glamorous work of mentoring engineers, giving them actionable feedback whenever they do something that caused or could have caused a problem? What about the impact of repeating yourself, again and again, teaching new junior engineers the same concepts and principles year after year without any gratification? What about publishing articles weekly or doing weekly 1:1s with a handful of engineers for years? How can you measure that revenue-wise? What about the work to interview engineers and help to shape the culture of an office for years?

It's hard to know at first if you are growing your impact and influence, but as with estimating work in software, the relative comparison always makes things easier.

When you see all the actions that person A did over a while and all the actions that person B did, it's a lot easier to forecast which person's actions will have the most impact in the short but most importantly in the long run.?

It's a lot more obvious to see the impact of actions in the short-term, but a lot harder to see the cumulative effect of them in the long-term.

Focus on the infinite game, focus on your impact & influence in the long-term, even when you don't see many short-term results.

What is beyond Impact & Influence?

Ok, many of you might not be happy with my answer or might be questioning:?

• What about Mark Zuckerberg? Or Bill Gates? Or Steve Jobs? Aren't they successful Technologists?
• What about my previous boss who decided to move to be a Product Manager, and today is a VP of Product?
• Or, what about my friend that today is a Sales Executive at Salesforce?

If we go back to my criteria, "Ever-growing levels of impact and influence on a large number of people." Yes, they are all super successful Technologists! And no, they don't need to be either a VP of Engineering or a Principal Engineer to be considered successful by my definition.

In this article, I'm summarizing the two most common paths in the Tech Industry today for Engineers. There are many other paths you can take, like Product, Sales, Design, Entrepreneurship, etc. There is even The Trident Model of Career Development proposed by @Pat Kua that introduces The True Individual Contributor (IC) Track as being one of the possible high-level tracks of growth for individual experts in large organizations. Those are out of scope for this article.

With this definition of success in mind, let’s move to the next part.

Part II - Skillset Framework - The 4 Pillars to Grow Your Career

In the past 12 months, I’ve been conducting interviews with some Successful Brazilian Technologists around the world, learning about their stories, their career trajectories and I want to share some of my findings or the patterns that I found so far that I believe can guide you throughout your career.

How to take your career to the next level?

That’s a huge list of things, I could spend a lot of time talking about it, but to make everyone’s life simpler, I came up with a FRAMEWORK that can help you to identify WHERE YOU ARE and WHAT YOU NEED TO DO to take your career to the NEXT LEVEL.

But, before I go over the FRAMEWORK, I want to explain to you how I got there. As it is often said in the crypto community: "Don't trust. Verify!"

"Don't trust. Verify!"

Liking it or not, agreeing or not, one of the most important things to understand in terms of career growth is understanding how you are usually evaluated at companies, no matter if you're an Intern or the CTO.?

Even though this is not 100% the case (there are companies that don't have any definitions at all), in most successful Tech Companies, your role will be highly related to the Level of Impact & Influence you can bring on what I call the 4Ps: The 4 Pillars. Let's take a look!

Career Progression Models:

Companies can vary their methods of evaluating and promoting people. Still, the principles used are pretty similar across the board for both progressions in the Technical Ladder or the Management Ladder. Like any model, career ladders are far from perfect. But, regardless of the pros and cons, they are crucial because they put a structure and shared expectations around different levels.

Before we move forward on this, I want to remind you of what a career ladder is and what is not. I could not have put it better than Pat Kua did, so quoting him here:?

"Career ladders are a starting point for shared expectations across an organisation. However, career ladders cannot be comprehensive, as people are unique, like snowflakes.

… levels in a career ladder do not represent a checklist. Rather, levels reflect how people can have a different impact on an organisation in different ways." – Pat Kua

Here are examples of the three most common career progression models used by different Tech companies in the US (Source: @Marco Roger's talk "Creating a career ladder for engineers") :

1. The first is the Startup-Kit model
2. The second is what is called the Snowflake model and;?
3. The third is what is called the Spreadsheet-Matrix model

* I strongly recommend Marco Rogers's talk on LeadConf NYC?from last year for more details on those.

Startup Kit:

The first and unfortunately, the most popular is the "Super Vague" Startup-Kit Model. It is almost like a version of the "eXtreme Go Horse (XGH) Process" for companies' career ladder.?

Most, if not all, early-stage startups use it as a starting point. In the vast majority of companies using this model, there are no clear definitions of areas of responsibility, level of impact, or behaviors that characterize each particular level.?

Besides that, there are other problems with the model itself, as Marco Rogers pointed out on his excellent talk:?

• Mid-level engineers stay in the middle FOREVER!!!?
• Seniors people top out quickly!?
• There is not a lot of room for growth.

It's not a good model to look at to extract many useful things to plan your career.

Snowflake:

The snowflake model, popularized by Medium Engineering, is a sophisticated system that scores individuals from level 1 to level 5 across many skills under different categories of knowledge. It's great to see how you can reach the same level (and have the same score) combining different skillsets. But you should be careful not to make the score your only goal.?

"Tell me how you measure me, and I will tell you how I behave. If you measure me in an illogical way, do not complain about illogical behavior." – Eliyahu M. Goldratt

It's a pretty good model to identify areas to look at in different categories of skills - many that you might not even be aware of - yet, in general, overwhelming. With a data model and a score behind it, the snowflake is beautiful in theory. But from the company perspective, it's super complicated to maintain it relevant and meaningful, and for individuals, super easy to get lost with many skills to master or trying to game the score.

Once again, for more details on that, I strongly recommend Marco Rogers's talk on LeadConf NYC from last year.

Spreadsheet-Matrix:

The final model that we will see is the Spreadsheet-Matrix model that is simple and robust for 99% of the cases. Many famous Tech companies use a variation of it, Rent the runway, Etsy, Foursquare, CircleCI, Patreon, Spotify, Square, Kickstarter, and many other companies. It is the model that I like the most and the model that I usually recommend to companies to start with.

The spreadsheet matrix is a matrix of level across various skillsets, and it strikes a nice balance between flexibility and not being such a pain to create, maintain, and use. The often-copied Rent the Runway ladder is the classic of this type.?

Why? Clear skill levels, clear areas of responsibilities, clear expected behaviors, clear levels of impact & influence, resulting in a clear and concise career ladder overall.

If your company doesn’t have a career progression framework, I strongly recommend showing the Spreadsheet-Matrix model to your manager. You can even start by copying and adapting one of the many Public Career Matrices available on https://www.progression.fyi/ to your company’s reality.

* Reference: https://speakerdeck.com/polotek/creating-a-career-ladder-for-engineers

What have I found?

After analyzing many different career progression models and engineering ladders from different companies and after interviewing many successful and also not successful professionals in my life, I came up with what I call the 4Ps: the 4 Pillars of a Successful Career in Tech.

* Reference: https://www.progression.fyi/

Skillset Framework:

Without further due, let me introduce you to the 4 Ps:?

1. Platform
2. Product
3. Process
4. People

Those are what I found to be the 4 Pillars of a Successful Career in Tech.

The most successful professionals that I know focus on getting better and increasing their impact and influence not only on the 1st P - Platform - but in all the 4Ps: Platform, Product, Process & People.

Giving credit where credit is due: I first heard about a similar idea - the 6Ps - from my VP of Engineering Ashish Pawale in 2018 as a way to assess and understand the scope of responsibility for Engineering Managers & Directors. Initially called by him as the "6Ps":?

1. Product Delivery (Project Management, Continuous Delivery, User Experience & Product Roadmap),?
2. People (Mentorship, Feedback, Leadership Behaviours & Career Growth Strategy),?
3. Platform (Codebase, Engineering Practices, Architecture Patterns & New Technologies),?
4. Process (Culture, Metrics, Rituals & Systems),
5. Partners (Relationship with Internal & External Product, Tech or Vendors),?
6. Paperwork (You know what that is when you work for a big corporation).

I really liked the breakdown, and I noticed myself using it a lot. But, the more I thought about it, the more I realized that they were not only applicable to managers and directors but also for individual contributors. And, not only as a way to understand areas of responsibility but also to holistically think about career progression.

Next, I put a lot of thought into it, and I decided to consolidate the 6Ps into the 4Ps. Then, I got to a structure that has proven to be easy to explain and helpful to use.

Those 4 Pillars are the Engine of Career Growth in both the management and technical track taking into account how the vast majority of companies evaluate individuals.

I consider it to be a strategic abstraction of how to think about your career and how to positively impact the project, product, team, department, or company you are currently working with.

Platform:

The First Pillar is probably the most famous and usually what developers think as all that matters to advance their careers.?

However, if you deny the importance of the other 3Ps - Product & Delivery, Process & Culture, and People & Leadership, you will likely get stuck at some point in your career.

1st Pillar -> Platform - It is the Codebase, the Scripts, the Infrastructure, the CI/CD Pipeline, the Batch Jobs, the Architectural Patterns, the Databases, your Technical Skills with a particular Programming Paradigm or Language, Framework, Tool or Library. Everything that mostly only engineers can see & assess. It is the core of the engineer’s job, the ability to solve problems with tools. It is the basis for everything! Many call this their area(s) of expertise.

We are also talking here about all the cross-functional requirements of your system such as reliability, scalability, extensibility, debuggability, testability & maintainability.

MASTERING is the core verb here.?

Mastering by LEARNING & BUILDING around solid engineering foundations & SELECTING & APPLYING the right practices, technologies, and tools.

Here are a few examples of Platforms and/or Platform skills:

• Mobile -> Native or Non-Native mobile platforms, such as iOS, Android, or Flutter using Programming Languages like Swift, Kotlin, or Dart.
• Frontend -> Client-side Technologies, HTML, CSS, JavaScript using frameworks like React.js, Angular or Vue.js.
• Backend -> Server-side Engineering, Relational & NoSQL Databases, Architectural Patterns, Instrumentation, and REST APIs using Programming Languages such as Go, NodeJS, Scala, Python, Kotlin, Elixir or Java.
• DevOps -> Networking, Security & Protocols, Operating Systems, Infrastructure as Code, Containers & Container Orchestration, Monitoring & Alerting using Cloud Providers like AWS, Google Cloud, or Microsoft Azure.
• Engineering Foundations -> Foundational systems, such as deployments, pipelines, databases, and machine learning.

How do I get better at this?

The obvious advice is to focus on mastering one programming language at the time, go all the way in. Read the Advanced Classical Books, Implement Different Design Patterns, Get Certified, Contribute to Multiple Open-Source Projects, Learn the 12 Core Engineering Practices of Extreme Programming, etc… And that is not bad at all.

But, the not so obvious advice that has influenced my career a lot more than 10 years ago was the idea of becoming a Generalizing Specialist. It helped me a lot to understand how to think about my "IT Career Skills" and to evolve as a valuable professional focusing on being a T-Shaped Engineer.?

A big reference for me on this was this famous article by Scott Ambler published in 2006.

Think about this as an ongoing effort to think about your next move while keeping in mind the overall shape of your most critical "IT Professional Skills Blocks" - or, your "Career Capital" as described by Cal Newport in his famous book "So Good, They Can't Ignore You." The mindful application and accumulation of expertise are required to be successful over the course of a career.

The level of effort needed to go from knowing the first 20% of an area/activity/skill/technology (a.k.a being an effective junior) to learning the remainder 80% is massive. To be a successful professional these days, I believe that one should go broad first (master the 20% that will allow you to deliver 80% of the tasks) and go in-depth only when there is a big need, a big opportunity, or a strong interest in keeping developing your skills further in a particular area.?

This approach is like a computer science curriculum strategy, you see the big picture, get a little taste of many subjects, and then (at the end of the course) you decide where you want to do a deep dive on. You zoom in and out according to the market needs, the opportunities you have (including the problems that appear in front of you), and, most importantly, your areas of strong interest/passion. Topics, problems, or new technologies that challenge and fascinate you at the same time - make you lose track of time -, are usually a good proxy for "skill blocks" that you should invest in and deep dive on for a couple of years.

That was the approach I followed with my career:?

• For the first three years of my career as the "Technical Support" guy, I focused a lot on Networking, Security & Protocols, Operating System, Cisco Routers Configuration, LAN & WAN Implementation. I would read a lot about how to hack computers and how to exploit vulnerabilities.
• For the next five years, I focused on getting my programming foundations straight. I would read everything I could find on Java, OO, Architecture, UML, Design Patterns, Testing, Databases, and Web Frameworks.
• Then, I joined ThoughtWorks in 2012, and I suddenly started to focus a lot more on Process, Culture, really deep-diving on Agile Practices such as Retrospectives, Inceptions, Continuous Integration & Delivery, Lean and Kanban, being a change agent as a consultant, how to interview people and Mobile Development.
• After that, I moved to NYC in 2014, joined an EdTech startup, and completely switched platforms. It was my first time being a real Full Stack Engineer using Python, Django, CoffeeScript, MongoDB, Puppet, and AWS. Not only doing Web Development but actually doing DevOps & Mobile Development as well. I would sometimes start the day having a meeting with a partner that was trying to integrate with our REST API, do a solid 5 to 6 hours of pair programming on a feature for our web or mobile app, and get woken up by PagerDuty in the middle of the night when something was down, slow or about to blow out in the pre-containers era.
• For the last four years, my main focus has been People Management, Project Management, Agile Process & System Architecture, initially as an Engineering Manager and now as an Engineering Director.

If we use the analogy of the graph traversal algorithms, I would say that this is almost as going breadth-first while keeping in mind the broad picture of your career skills & tools as you deep dive, zooming in, and zooming out as you gain deeper awareness.

Please keep in mind that I’m not suggesting here for you to become a Generalist - a Jack of ALL trades and Masters at NONE.?What I’m suggesting here is for you to try to be a Generalizing Specialist or a Specializing Generalist, basically a Jack of MANY Trades and Masters of SOME.

My story: I started my career as a web developer doing both backend and frontend as it was common back in the day. I quickly realized that front-end development was not really for me, but even though it was not the thing that I most enjoyed, I would always do whenever there was a need on a project. Also, I was always open to trying new things and playing different roles. Early in my career, I was invited and decided to move to be a Project Manager and I hated it. Got some experience, but moved back to be an engineer and got really good at automating tests and continuous integration, then moved to be a QA Consultant and then moved to be a Full Stack Engineer, DevOps, Sales Engineer and later again as a Software Engineer in Test. More recently, in 2016, I started as an Engineering Manager, and last year I got promoted to Director of Engineering. If I had decided to stay 100% on the Backend Development Track in a single platform, in my case Java, and had denied the opportunities I had to play different roles and with different platforms, I’m not sure if today I would be here.

"Specialist vs. Generalist battle – many devs will proclaim loudly and proudly that they are specialists and they don’t want to be generalists.?Much of this comes from how they got good review scores in the past (focused on owning deep complex code).?Respect their strengths, but be firm on expecting them to broaden. At the end of the day, you don’t want either specialists or generalists, you want people who can go deep when it matters but you want those same folks to be able fluidly move to higher ROI tasks. This creates stronger adaptability – a key business imperative.

...I’m a believer in teams filled with (or at least largely populated by) specializing generalists. Everyone certainly doesn’t have to be able to do everything, but every team member should be able to do many things well, and a few things very well. It’s important when building a team to have diversity in both generalization and specialization – and match those skills with what’s needed for your project." – Brent Jensen

* Reference: The Combined Engineering Software Model by @Brent Jensen

Another big reference that has helped me to grow in this area has been @Sandro Mancuso's book The Software Craftsman - one of the interviewees from my book.?

The big tip that I want to leave here is to focus on the principles that are unlikely to change instead of the new tools. I like how Sandro breaks down any kind of Technical Book in 4 buckets and explains when you should focus on each one of them and why:

1. Technology-specific books are very valuable but they expire.
2. Conceptual books are books that give us the foundation to advance in our careers.
3. Behavioral books are books that make us more efficient when working in teams and organizing ourselves.
4. Revolutionary books (some call them classics) are the ones that changed the way we work.

"Favor conceptual and behavioral books for your career progression, starting with the revolutionary ones. Read technology-specific books for your short and medium-term plans." – Sandro Mancuso

Read books, a lot of o books, but most importantly, be super strategic about it.

Product:

2nd Pillar -> Product Delivery. It is the app, the website, the gadget. It is external. It is what the user is using, what it is being experienced, the features available, what the user is able to accomplish, and how quickly, the perception of speed, security & reliability. It is what the business side is seeing getting shipped. It is what makes the company profitable.?

Product & Delivery at the end of the day it is what engineers are paid to do and what users care about.

Initially, I had "executing" as the core verb here. My thought was, everything on this "P" was about making smart decisions (be effective) and getting things done. But, the more I thought about it, the more I realized that building, executing, or just getting things done was not enough.

DELIVERING, especially, delivering value is the core verb that I like the most here now.

The focus must be on customer impact and incremental improvements.?

Improving only the codebase (the platform), the same way that improving only the process or the environment for the people is not enough. The improvement of the platform, process, or people must be translated into better cross-functional requirements such as performance and security to the customer or a decrease in cost or cycle time to the company. Things that add value to the customer or the company.

Here are a few examples of Product/Delivery Skills:

• Planning & Managing Work: Estimating, Planning, Monitor, and Control.
• Engineering & Developing Products: Product Research, Analytics, User Feedback, Design Thinking & Technical Solution.
• Requirements Development & Prioritization: User Stories, Bugs, Tech Debt, Platform Modernization.
• Continuous Delivery & Release Management Strategies.
• Build Quality In the Process.

That is the core, the engine of Agile, Lean or traditional methodologies such as Scrum, Kanban, Scaled Agile, or CMMI based models. This is where the project management triangle comes to play. Strategies that help to deliver while making the right trade-offs between the constraints: Cost (Project's budget), Time (Project's deadlines), Scope (Project's features) & Quality.

How do I get better at this?

The obvious advice here is to be more productive. Learn all the keyboard shortcuts, Automate everything, Create a System for your To-do lists, Maximize your Output. Set Reminders. Work longer-hours if needed. Get more done. Finish things faster, Avoid Interruptions at Work, Minimize Distractions. Deep Work! Learn to Estimate and Manage projects well. Buy a Noise-canceling Headphone. Get a PMP Certification! :-D?

And that is not bad at all!

But, the not so obvious advice that I have learned and has influenced my career in the last couple of years is to Maximize the Work Not Done. Maximize the number of lines not written.?

"The Best Code is No Code At All” – Jeff Atwood.?

Don't focus on being efficient, focus on being effective. You must learn how to prioritize, that is the only way to be highly effective. Efficiency is the tweaks that you make to get that 10% optimization. 90% of productivity is about being effective.

One tool that has helped me a lot is User Story Mapping.?

I can't say enough how much easier it's been for me to work with Product Managers when I help them to see the full scope visually. Story maps are a much better way to visualize and organize the work to be done than traditional backlogs.

My Story: I really hate to brag about myself, but let me tell a story on how applying this concept alone got me a job as an Engineering Manager after just 2 months in a new company. It is questionable if that was a promotion, a lateral move, or a new job. Anyhow, I was a Senior Engineer and this was when I was offered to become an Engineering Manager.

As I mentioned on the previous P - Platform - I started to apply the concept of being a Generalizing Specialist really early on in my career. I got super lucky, had many opportunities and I was able to take a lot of different roles in different projects throughout my career, working with different tech-stacks, tools, methodologies, processes & cultures. But, that alone wasn’t what got my promotion.?

What got my “promotion” was the fact that within a couple of weeks in a new job, I saw a big gap in the discovery/grooming process of new projects - something that was technically outside of my area of expertise - I was a Software Engineer in Test - but that due to my “Jack of Many Trades” experiences and interests I was able to detect. With that, I not only raised that as a concern, but I volunteered to run an experimental “Inception” meeting (that I had learned from my friend and former-coworker at ThoughtWorks Paulo Caroli) with Product Managers, Designers, Engineering Team & Directors for a brand new critical project.?

That was the very first attempt to run an “inception meeting” by myself and outside ThoughtWorks.?

I got lucky again and I was not only good at running the meeting, understanding the business goals, the different perspectives from Product, Backend Engineers, Mobile Engineers, QA, Designers, and getting to shared understanding and collaboration, but among all of that, I did a great job at maximizing the work not to be done for this project by making everybody talk the same language and visualize in a couple of hours the big picture, the connections, the dependencies, the relationships and, most importantly, the multiple layers of complexity of what we were trying to build. The User Story Mapping was the forcing function that helped us to prioritize and to aggressively reduce scope early on.

I facilitated a critical meeting, connected everybody on a vision, and maximized the Work Not To Be Done while keeping everybody happy and focused. That was what I believe that the Leadership team saw in me when one of the engineering managers announced that he was leaving the company a couple of weeks later. It went so well that I’m still proud of this almost 4 years later.

"You can’t create your own luck, but you can leverage it. Say yes.” – Gayle Laakmann McDowell

Another big reference that has helped me to grow in this area has been @Paulo Caroli’s book Lean Inception - one of the interviewees from my book. Paulo is a mentor and someone that I look up to when it comes to facilitating critical conversations on critical projects. He is the master of inceptions and retrospectives.

The one-week long inception is an outstanding way to find the core priorities of the project and to align all team members on a single set of goals. Once again, being effective, not efficient. Being efficient in this case would be to start to code from day one without knowing the priorities and the business goals. Being effective here is to take the time to understand the goals, the strategy, and prioritize the best bang for the buck. Strongly recommend it!

Process:

3rd Pillar -> Process & Culture. It is the HOW.?

• How scalable are we as an engineering organization??
• How dependent are we of single points of failure (SPOF)? (Key engineers, managers, product managers, key people, or key resources in general - things that are not documented, single points of failure not only the architecture but on how we do things).
• How balanced is the work? Do you have some folks always working extra while a few always leave at 5 pm???

It is the Sustainable Pace, the Collective Ownership, and the “Bus Factor” risk that Kent Beck talks about in his famous XP Book.

Those are the checklists, the approval processes, the PR reviews, how good we are at sharing knowledge, how the engineering culture of a particular company is perceived in the industry, the interview process, the onboarding process, the documentation.

It is how many extra hours of work a team has to put to get a project shipped on schedule in the last 2 weeks before the deadline.?It is how many days it takes to a new engineer to start to contribute to the platform & product delivery. It is what allows career growth to happen even when things are busy. Are individuals able to progress in their careers? Is there a sense of personal growth?

Those are the rituals, the culture, the mindset, the sense of community, the things that teams and engineers do when no one is looking.

The core verb here is STRENGTHENING! Scale the product, the codebase, the infrastructure, how the people and teams interact with flexibility.?

Here are a few examples of skills/activities/practices under this Pillar (from Medium Engineering Snowflake guide):

• Engineering Practices -> Practices to ensure excellent quality products and services
• Career development -> Support for engineers to help them build the career they want
• Organizational Design -> Processes that enable the strong growth and execution of a diverse engineering organization
• Mentorship -> Practices that support co-workers, spread knowledge, and develop the team outside formal reporting structures
• Evangelism -> Activities that promote the company & engineering department to the outside world

How do I get better at this?

The obvious advice here is to Get a Scrum Master Certification, Organize Meet-ups, Go visit different companies, learn from other cultures, learn how other companies under similar circumstances scaled. Go to conferences, spend time mentoring junior engineers. Expand your network.?

And that is not bad at all!

But, the not so obvious advice, that has made me grow a lot in the last 5 years or so, is to get involved in your company hiring process. Be an interviewer! Try to improve how your company, department, or direct team do interviews. Try to improve the kind of interviews your company does. Reverse engineer the process to try to get the kind of professionals you see succeeding in the day-to-day. Ask yourself, is the hiring process actually working on our favor or against us?

What kind of skills or traits do we need to look for to match the behaviors we want to see down the line?

If you work in a big company, being an active interviewer will give you more visibility on the other departments and not saying that will give you a much better perspective on what other companies are doing, how the market is, what questions or exercises most candidates are coming short at…

The impact and influence you can have shaping the hiring process to the actual needs of the company and hiring the right people are beyond you. It is something that will last likely way longer than your time at the company considering the 2 years average of Tech people staying in companies.

When you are operating as a change agent, you are operating mostly at this pillar. Your focus should be on the effort that lasts beyond you. The only way to have your ideas sticking around for longer than you are around is by adopting and incorporating the new process into the culture. It's here that the practices and principles become organizational habits that are done that people just do by osmosis.

My story here is kind of crazy. I have interviewed and helped to hire two of my previous bosses, one was massively successful and the other one didn't last 3 months. Lesson: I definitely didn’t know what I was looking for on an Engineering Leader back there. I ended up focusing mostly on the technical side of things and little on the leadership, personality, experience, and traits. I should have done the opposite. I got lucky once, but not twice and that is not what you want to happen when you start to interview people. That is why knowing exactly what kind of skills, personality, and experience your ideal candidate has is so critical. The more you invest upfront designing the interview process to your ideal candidate, the more likely you will be to make good hiring decisions.

A big reference for me here has been the book Peopleware, which in my opinion would probably be a better name for this Pillar than Process.

"The maddening thing about most of our organizations is that they are only as good as the people who staff them. Wouldn't it be nice if we could get around that natural limit, and have good organizations even though they were staffed by mediocre or incompetent people?" – Tom DeMarco

People:

4th Pillar -> People & Leadership.?It is the second HOW, probably the most important one.?

• How do we collaborate as a team??
• How do we collaborate across different roles & across different teams?
• Are people happy? Are people being heard??

It is how you were able to achieve a given result.?Those are the Leadership Values. Those are the values, things that people do even when no one is seeing.?

How long does it take for someone to step in and tie-break a decision that is back and forth during days??How do the TechLeads handle conflicts? How is everybody challenging the status quo and supporting each other?

The core verb here is SUPPORTING! Support & Empathy.?

A few examples of the group of skills on this pillar (from Medium Engineering Snowflake guide):

• Wellbeing -> Activities that support the emotional well-being of group members in difficult times, and celebrates their successes
• Accomplishment -> The culture that Inspires day to day excellence, maximizes potential, and effectively resolves performance issues with compassion
• Initiative -> Practices that are used to challenge the status quo and affect positive organizational change outside of mandated work
• Communication -> Techniques that are used to share the right amount of information with the right people, at the right time, and listen effectively

How do I get better at this?

The obvious advice here is to go to Leadership Training, Read books on Soft Skills, Give presentations, Do an MBA, ask for opportunities to lead small teams. Learn how to communicate effectively. Learn how to give effective feedback…

And that is not bad at all.

But, the not so obvious advice that recently made me see things more clearly is the concept of Being "The Glue Person” or Doing the Glue Work.?

I knew it, but I didn’t know it had a name. Try to see everything as a system, see where things are falling to the cracks and pick them up. Do the Glue Work, be the Glue Person. Take Extreme Ownership over the entire project. Try to act as the CEO.

When you see that something needs to be done, but no one is doing, you jump in and do it. You don't wait for permission, you don't ask for approval. Seek forgiveness, do not seek approvals. Talk to people to understand their current pain and act on it. Make a noise or speak on their behalf if needed.

Want to Be a Better Leader? Put the effort into it.

How? Do the work that nobody is doing, but that is critical for success.

*P.S: Be careful about the amount of time you will spend doing this every day, especially if you are early in your career, doing a lot of this might be damaging. More on why on Tanya's talk Being the Glue.

How?

Basically, let me state the obvious here, I’m good at everything that I put the effort into. You will be good at everything that you put the effort into.

Do you want to be a better leader? Put the effort into it. How? Do the work that nobody is doing but that is critical for success.

The more meetings you facilitate, the better you will be at it.

The more critical communication you do, the better you will be at it.

The more feedback you give, the more comfortable and skilled you will be next time you need to give feedback to someone.

You get better at making sure that everyone's going roughly in the same direction by consistently making sure that everyone's going roughly in the same direction.

You get better at asking questions on design documents by asking a lot of questions on design documents and iterating on it.

You get better at talking to the users by talking to a lot of users.

You get better at facilitating big meetings by volunteering and running a lot of big meetings.

@James Clear, the author of Atomic Habits, has this amazing example in his book about this experiment done at the University of Florida on how focusing on the quantity of reps almost always will trump focusing on the quality of reps.?

"At the end of the term, he was surprised to find that all the best photos were produced by the quantity group. During the semester, these students were busy taking photos, experimenting with composition and lighting, testing out various methods in the darkroom, and learning from their mistakes. In the process of creating hundreds of photos, they honed their skills.

...Meanwhile, the quality group sat around speculating about perfection. In the end, they had little to show for their efforts other than unverified theories and one mediocre photo.

...If you want to be a great photographer, you could go on a quest to take one perfect photo each day. Or you could take 100 photos per day, learn from your mistakes, and hone your craft." – James Clear

A big reference for me here is @Kent Beck and his outstanding book Extreme Programming Explained, specifically the psychology of it and the big emphasis on principles and values. This quote here is not from the book, but from a tweet from Kent. It captures one of the keystones of this pillar: Being empathetic.

"The craft of programming begins with empathy, not formatting or languages or tools or algorithms or data structures."

– Kent Beck

From Kent Beck, empathy is about putting yourself in other people’s shoes and ideally, that is not only mentally, but actually physically too by actually doing their job and by actually feeling their pain when you are trying to make sure things are moving forward with the project.?

• Be the customer support agent of your company for 1-week.
• Shadow someone that plays a different role in your company for 1-day: be it a product manager, a sales representative, or a recruiter.

Where should you focus on the impact at different moments of your career?

At lower levels (junior, mid-level - less than ~5 years of experience), Technical Platform, Architecture, and Coding Skills or 1st Pillar and Get Stuff Done or 2nd Pillar (the "adder" attributes) are the primary drivers of promotions. Impact on specific projects or specific contributions to the codebase.

At higher levels (senior/staff/director/VP - more than ~10 years of experience), the importance gradually shifts to contributions to the Process & Culture, Leadership, Mentorship, and Effective Communication, "People", the 3rd and 4th pillar (the "multiplier" attributes) and both of them become the primary drivers of promotions/growth”.?

Between focusing on "Making Impact" or "Having Influence", I would focus on making a positive impact because I believe that is the only way to get to influence. I'm a strong believer in leading by example and walking the talk.?

"Those who focus on giving—without worrying when they'll get repaid—wind up with hordes of people in their gratitude." – Gayle Laakmann McDowell

Making a continuous impact is the most effective way of influence that I know.

* Reference: Rent the Runway Engineering Ladder by @Camille Fournier

Part III - Career Accelerators:

When it comes to Career Strategy, a big reference for me is @Fabio Akita (AkitaOnRails.Com).?

My favorite articles from him are the ones prefixed as "Off-Topic" on his blog, unfortunately, the vast majority of them are available only in Portuguese. He was the man behind the rapid growth of Ruby and Rails in Brazil.

A piece of advice from Akita that I read on his blog 10+ years ago and I will never forget is to change companies every three years or so during your 20s.

"Do not spend more than 3 years in the same place, especially if you are under 30." – Fabio Akita

However, as Akita also mentions, you should not change companies for the sake of it…

"It's no use to just keep changing jobs, for two reasons:

1- Not necessarily a new project will bring you new learning opportunities (the chances of being another “CRUD” work are big).

2- Learning only when it is needed for a project is too late. You will be overtaken by others who already know what you are trying to learn." – Fabio Akita

You should be super-strategic about it, changing companies is a great opportunity for you to get exposed to different people, different projects, different domains, different cultures, and different technologies that will challenge yourself in a different way, but that is not the only way.

Connecting this back to my framework, I believe that every career change should be accompanied by a big change in at least one of the 4 Ps: Platform, Product, Process, or People.

Think about this: What is your main reason for changing jobs??

If it is to learn a brand new platform or to use the same platform at a completely different scale, to work with a different business domain or under a new team setup (let’s say you work in an office with all developers centralized on the same timezone and you want to experience real distributed teams fully remote), or you are tired of your Enterprise Corporate culture and you want to experience a more startup culture, or you want to manage people or mentor junior engineers in different ways and that new career change will bring you that, that would be a great reason and a great career move.

If on the other end, your goal is just to change to make more money and you don’t see any change in any of your current 4Ps, that is probably not a good move career-wise. Money-wise, that is a different story.

So, I have a little less controversial opinion than Akita on this, my recommendation is that you should be changing at least one of the 4Ps - Platform, Product, Process & People - at least once every 2 years, not only during your 20s but actually during your entire professional career in Tech.

Continuous Interviewing:

Yes, always be open and always take interviews even - or especially when - you are super happy and engaged at your current job/company. At least once a year, accept that invite from that recruiter and move forward on an interview process with an interesting company.

My rules on deciding to take new opportunities:?

• Will I ever regret this decision? We usually only regret the things we don't do and never the things we've done.?(If the answer is yes, go for it!)
• What is the worst thing that could happen if I decide to go down this route? Would I be able to go back to a similar job that I have now in 6 months or 1 year from now if things go south? (If the answer is yes, go for it!)
• Will this move make me a more valuable professional in 10 years from now? Who do I think will be more valuable after 10 years??

1. Someone that stayed in the same company or someone that was able to move and successfully grow switching companies, languages, processes, culture, and so on??
2. How likely is that my current Tech Stack, Area of expertise, or Company will be relevant and well 10 years from now?

"If it feels like the interview cycle never stops, that’s because it doesn’t. You need to start thinking about your next career jump on your first day at the current job." – Gayle Laakmann McDowell

Learning vs. Earning:

Recommendation: Have a safety net that will allow you to take small risks!

At what phase of your career are you now? Learning Phase or Earning Phase?

What is the most important thing for you right now? Learning (getting experience) or Earning (making more money)?

I can’t emphasize enough how important it is to have a Safety Net or what is called "F*** You Money” available for your mental and emotional sanity. That is what is going to allow you to take risks that can have exponential pay-offs during your career.

Short-term vs. Long-term:

This will look like self-help advice, but I will share it anyway.

This is an interesting conclusion that I got after interviewing 15 successful professionals for my book and after reflecting deeply on my own career story. All of them had a similar story: they "tasted" in some way or another “a life” or “a vision” in a different country, different company or even using a different technology or on a different role before they had the courage, the motivation, and the persistence to make the move to start to work seriously towards it.

"All things are created twice; first mentally; then physically. The key to creativity is to begin with the end in mind, with a vision and a blueprint of the desired result." – Stephen R. Covey

My Story: In my case, in 2013, I had my little taste on how it was to live in NYC working for a Tech company.?

I came in to work on a client back when I was at ThoughtWorks.

I would stay for 3 weeks

The client’s company office was in Midtown Manhattan and I was going to stay in Jersey City and commute every day.

I had absolutely no idea where Jersey City was.

To that day, I had no interest in moving to New York City. It was my first time visiting the U.S.

I had zero expectations.

But, I will never forget how impactful it was for me seeing the One-Trade Center getting closer and closer as I was riding a cab from JFK to Jersey City.?

I will never forget the view of the skyline I had across the river from the private balcony of the corporate apartment I was staying on a beautiful summer day right by the moment that a massive cruise ship was passing by. (photo above)

I will never forget the feeling of exploring the city on the weekends with my wife, going to restaurants, museums, parks, walking in unknown streets without having to worry about being robbed, or if it was already past 8 pm.

I would probably have never imagined my life and my career in NYC if I had not experienced it.

My recommendation: Spend a few minutes imagining and writing down your future, your “ideal” personal and professional life.

1. What are you optimizing for now? Short-Term (Just surviving?) or Long-Term (Thriving?)?
2. Where do you see yourself in 5 years? 10 years? 20 years?
3. How are your daily and weekly actions making you closer to your long-term view?

"The difference between great people and everyone else is that great people create their lives actively, while everyone else is created by their lives, passively waiting to see where life takes the next." – Michael E. Gerber

When things are too easy, change the constraints of the game, try to play in the next level - not once or twice, but again and again - forever.

Thank You for reading!

If you have any questions, comments, or suggestions, feel free to post on the comment section here.?

If you disagree with anything I wrote here, I would love to know more.?

Critical feedback is much appreciated.

VIDEO:

If you made this far, here is the video of my talk:

THANKS TO:

Thanks to Rafael Almeida for the help with the designs, for the many meetings, and for helping me to structurize this talk.

Thanks to Rafael Portela & David Smith for providing me amazing feedback and many ideas on this talk.