The problem we are solving for
Place problem-solving and the state of your domain first; let the skills and anything else be a consequence
Intuitions regarding personal growth and domain importance in a company
Absorbing a domain
Setting yourself to success and monitoring progress
The role of people managers in it
The anti-patterns when focusing on the skills or characteristics of higher levels

The problem we are solving for

How can we manage tech careers in a way that connects to the reasons that motivated us to pick this field and at the same time support building a successful company?

Those reasons, be they curiosity and interest in working with data for decision-making at scale, seeing human-like behaviors emerge from learning algorithms, building data-intensive software, etc., bring us personal fulfillment and a sense of meaningful work.

Nonetheless, this is the common and painful scene of a technical leader looking for career progress without thinking about any of these reasons:

These are unhelpful and unexciting aspects to consider. They are prone to intersect with “careerism”, which is doing whatever one can to make more money or get promoted, or the mediator mimic.

Audience

I created this content to support Lead+, and Staff+ Data Scientists and Machine Learning Engineers, but anyone in a technical field can apply it.

Notice that even though professionals from different levels can use this same framework, I target the ones who are both in a tech leadership position and are the most senior or one level below the most senior technical person in their team.

Place problem-solving and the state of your domain first; let the skills and anything else be a consequence

Associate yourself with your team’s domain. Taking the domain to the next level in your company will likely take you to the next level, too.

Instead of asking, “What should I do to grow to the next level?”, ask: “How can my domain reach the next level in my company?”

After you identify the technical levers of this change, it becomes touchable. This change should align with what you are passionate about in your technical field and what is great for your company.

Consider as a domain what teams cover from a team level (5-15 people) to a business unit level (100+ people).

Stop looking at the mirror or starting this conversation from your skills perspective. Start with problems and subjects you feel excited about. Notice one of the behaviors of technical leaders is to own the technical state of their team(s).

Here are some examples of domains, from highest to lowest level: Fraud, Credit Card Fraud, and transactional credit card fraud.

The state of a domain involves many things, generally concerned with size and quality: how important it is for the company’s current and future success, how it relates to sub or different domains, how people interact every day, how healthy its systems are, how efficient are the solutions in place, which problems have a solution, what is the state of every solution, etc.

Any complex system out of any actor's complete control is a good analogy for a specific domain in a company (especially a large one), such as a village or a garden. It would be best to look at this complex set of actors, systems, processes, etc., that has a goal in a company.

It doesn’t mean disregarding your career. You should talk to your manager about your preferences and ambitions if you feel your allocated domain doesn’t offer the best conditions for your development, etc., but this is a once-a-month to once-a-quarter subject. After associating yourself with a domain, your career story becomes part of your team story, an everyday subject.

There are many advantages of focusing on problem-solving instead of personal skills:

You have peers also looking into the same problems and at different levels of abstraction;
You might have more senior technical leaders also caring and interested in how to build together and coordinate;
Your manager and General Manager care a lot about it because it also relates to their career;
There are people outside your company doing research about it!
Multiple companies are also solving it, many in an inspiring way.

Those unclear aspects of growth become natural consequences of the exciting work:

Multiple teams impact as a consequence of solving meaningful problems that touch multiple people, teams, and BUs;
Influence as a consequence of others willing to replicate your team’s success;
Strategic as a consequence of solving complex problems that require multiple steps and solving trade-offs;
A field reference as a consequence of innovating to solve problems the community cares.

Intuitions regarding personal growth and domain importance in a company

There are a couple of situations in which companies use talent that can provide intuition behind attaching oneself to a domain instead of looking into oneself.

Think about the “hiring talent from a more mature company” pattern.

When a company does a “key hire” and brings someone from a more mature market or company to lead a domain, what they have in mind is: “Please, take us to at the least the level you took and experienced in your previous company”. It often happens when the stakes become higher for certain domains, so it is worth the investment in a high-seniority professional.

We all have a notion of a gap between reality and what is excellent, tuned by our current seniority. Have you ever said, “When I got here, it was all just wilderness?”

In the same way, a more senior person joining your team will see the “wilderness” you cannot see.

A thought experiment: “If my team hires a more senior folk from a company that’s a reference in the domain I work on, what would we expect from them?”.

Notice the difference between the external and internal hires via a promotion. The external hire performance is related to closing the gap first. They are unlikely to be promoted in this process (they might have been at the hire to accept advance the new company); they mainly exploit their existing skills in a scope they are used to. They have the title, but for a while, their domain won’t match what we expect from it, considering a person as senior as they are is taking care of it. In the internal hire via promotion, the state of the domain needs to be where we expect it when it is under a person from a certain seniority before a promotion to that seniority happens. In other words, one won’t be promoted to Staff to take a domain to where a Staff would place it, but one needs to set a domain where an “entry Staff” would in order to be promoted to the Staff level.

If there is a clear gap between your company’s stage in a particular domain and that of other companies, taking your company to the level of the best companies in this domain will likely take you to the next stage in your career. The further you are from the state of the art, the more stages of your career you can go through during your domain’s journey to the best one can do regarding that subject matter.

We don’t expect a one-to-one copy from advanced companies but a critical build, borrow or buy focusing on the same or better outcome, not necessarily the specific way others did it. For example, you work with the registration/acquisition team. You see a company in the same market that does a complete digital onboard in 3 steps that take 15 minutes, while your company has offline steps that make the process take from one to two days. The idea is more about having the same level of service considering your particularities instead of only copying the same screens and solutions from your reference.

Suppose you are on par with the market regarding current outcomes and commonly adopted approaches. In that case, it becomes more exciting since you need to work with other leaders on defining an innovative next step: how can we go further in creditworthiness assessment? How can we ease machine learning model governance for our users while guaranteeing our customers and company an even better level of safety?

Absorbing a domain

Identify what is your broader organization’s goal

Depending on the size of your company, it might be the company’s overall goal or your “department”, “business unit”, etc. For example, an external product like a Business Intelligence tool or an internal developer productivity platform.

List the main problems. What are the revenue levers? What are the highest costs? What are characteristics other than profitability that leadership shares as positive or negative? How did this domain evolve in the last couple of years? What rationale is behind the past and current Objective Key Results (OKRs)? Ask the high org leaders. Consume its P&L sheet.

In this stage, you want to grasp the problem level and notions of what is good or bad in your broader domain.

Consume your higher organization vision

There is likely an artifact that describes at a high level where your higher organization wants to be. The most interesting part of these documents is the description of what needs to be accomplished instead of “how”. This stage overlaps with the previous one since you expect a description of problems and desirable characteristics.

You need to consume and understand clearly before contributing to it. Check this article’s Impact section.

Which AI/ML/Engineering subfields relate to it?

Sometimes, a little bit of the solution leaks into the problem. Try to avoid this as much as possible. Identify the fields that solve the same problem, not those that apply your team’s current or similar approaches.

For example, if you use tree-based boosting methods and rely heavily on SHAP, avoid following only how “tree-based boosting models” and “SHAP” are evolving; instead, follow other fields tackling “predictive problems” and “model interpretability.”

Identify the best companies that play in the same field

Identify the best both for the business and tech domains.

The references in fraud, customer service, personal loans, or rewards programs. Who leads ML model serving, computer vision, causal inference, forecasting, recommendation systems, etc.

Understand and characterize the state of your domain in your company

You need to understand where you are well. What can we consider wilderness?

Which problems do we solve? How well are we solving them?
Are there problems we need to be aware of?
How well can we recover when something goes wrong with a model/solution?
How quickly can we develop a new ML model/solution?
Which things generated issues for us in the last six months?
What could generate issues for us in the next 3, 6, and 12 months?
Which things frustrate the team? Are there specificities by expertise or seniority?
Which things frustrate the customers or stakeholders from this team?
How are our costs behaving over time?
How do our costs impact the overall domain costs? How do the overall costs impact the whole company’s costs?
How often do we have data issues?
How’s the performance of our models and policies?
How’s our level of service?
How happy are our internal/external customers?
How do we exchange information?
How long do we take to deliver?

Understand the state of the art

Understand the state of the art for the business and tech sub-field domains.

Look into it deeply: why do people use approach X? What are the problems from this field that approach X’s characteristics solve? And keep looking for why people do what they do, what they used to do before, what they point to as the future, etc.

Adjust for your radius of action

You are looking for the highest level possible for your domain. Fit your sub-domain by translating the desired characteristics, goals, and problems.

What are the local metrics and milestones that will represent your local team moving to the right place?

You will want to push from local to broader.

Think systematically to push it forward

What is the ideal state? What is a good first step? Who should you partner with? Which existing strategies can you contribute uniquely? Can you see anything others can’t? Should you demand more clarity from higher-level leaders?

When pushing your sub-domain to the ideal state, do you depend on others making changes to their sub-domains? Can you implement it locally and use it to convince people, or do you need to move together with others, even for the first step?

Your expectations should be around solving these problems as a team.

Establishing a conversation with research and industry

In general, I see that we all Data Scientists and Machine Learning Engineers share:

Enjoyment of problem solving with AI;
Interest in how research on the field progresses;
The desire to be the most advanced and innovative in applying AI to solve our domain problems.

You are not the sole champion or the savior of your domain

You won’t magically and alone take a large domain to the next level. Companies hire more experienced folks to speed up development because it takes time to see levels of wilderness one couldn’t see before, and building great things takes time.

Expect having to negotiate the changes, proving approaches by delivering them incrementally, and keeping current systems working.

The delivery process will push you to learn all those leadership skills—you will have to; you won’t be able to build this beautiful thing with your team without them.

Setting yourself to success and monitoring progress

When setting in a team, ensure to ask yourself these two questions:

Are you excited about solving the underlying business problem? Does the external perception that your company solves it extremely well make you want to be part of it? For example, in customer support, you must be excited about delighting customers when solving their tickets using AI and everything else needed. More particularly, think about your team’s part in the larger business problem you solve.
Are the related tech sub-fields exciting for you? For example, NLP is used when working with customer support. Causal inference if working on behavioral changes. Recommendations if working in a marketplace or content-driven network. Engineering platforms if working in platform teams. Then, go deeper to ask about the sub-areas of these broad topics.

When part of the team, monitor your progress: Is the domain/solution you and your team are responsible for clearly progressing and operating at a new level according to your defined standards? If yes, what was your role in it?

It is impossible that the story of the career growth of the most senior tech leaders in a team won’t be intricated with the story of how that team got to their most ambitious goals.

The role of people managers in it

The idea is not to disregard the role of skills in this process or not to consider people’s particularities as professionals.

Again, it makes more sense always to have the domain as the main topic to keep the conversation illustrated with tangible problems. It is frustrating to talk about a career in a one-on-one and only hear a vague advice like one needs to “influence more” for the next step.

A people manager will ask themselves slightly different sorts of questions:

What are the tech levers in our team match my report’s interest?
Which part of the problem offers a good balance of feasibility and challenge for them considering their skills?

Improving skills with the assistance of a manager becomes more natural:

Hey, I need to understand better what our department means when we say we want to be multi-channel. Can you explain it to me?
I made a draft on how we can adapt our systems to become multi-channel. Can you review and see if the problem statement is clear and if it fits our general strategy? I need to convince these two teams that some of their initiatives will be detrimental to our whole. How do you think I can approach them?

The anti-patterns when focusing on the skills or characteristics of higher levels

Spread too thin by acting superficially in other teams for the sake of influence and multi-team impact

Don’t act as “your level” or “your level-1” for teams around yours. This behavior is a misconception about how “influence” and “impacting multiple teams” happens. It can increase your delivery volume by associating yourself with low-hanging fruits in these teams. Still, you are unlikely to have a deep understanding of many topics to make meaningful contributions all around. Worse, it can distract you from what you should be focusing on.

Solving the domain or sub-domain under you with extreme excellence will naturally influence others. If you cover a sub-domain like transactional fraud, it can influence the overall Fraud domain. If you cover a large domain like fraud, it can influence different domains, like customer service. Build a notion that the problem you are solving in your team is important to many others, and facilitating understanding and adoption of what you do is better than trying to be part of many teams.

The other proper form is to team up with others to make a systemic contribution. This means that influencing them is important because they own a component of the whole you want to push forward to solve a problem.

Building things from scratch

For a couple of years, people have been fighting the bias toward building from scratch and complexity in tech companies. It has created “promotion-driven engineering” that’s very focused on building new frameworks intended to be the big thing—and the tragedy is that they used to be rewarded before proving whether they were a big thing or not.

Building things from scratch doesn’t necessarily correlate with seniority. It is quite the opposite. Having great skills to decide when to copy, adopt, adapt, and exceptionally build is the trait people will look for in technical leaders.

When we target evolving a domain, building everything related to it becomes even more absurd. Adopting most of it from other teams, open-source or third-party, enables your team to operate on the edge and innovate instead of building your version of a commoditized tech.

Insisting on your idea or proposal just because it is yours

The evolution of a domain is teamwork. It doesn’t need to be “your thing” to push your career forward. Multiple people develop a vision and the multiple strategies associated with it. You will likely originate a part of it but follow the others most of the time. Coordination and a systemic view of how what you do fits the whole are more important.

When to look for skills resources

Look for skills resources only when you have a problem at hand. If the current problem you are solving requires convincing multiple teams to change their approach, you should look for tips on communication and influence. If the most important thing you can do for your team is internationalize a solution, look for references on how others did it and the tech topics related to it.

Enjoy and exchange with your internal and external communities.

Table of contents