[This is part 3 of a series on managing Data Science teams based on hard won experience running one of the larger data teams in SouthEast Asia from one of its unicorns. YMMV and advice here should be sanity checked to make sure it’s appropriate to both your corporate structure, culture, and situation. No solution is one-size, fits-all. This is to guide CDOs, VPs, and data executives and give an alternative viewpoint on organizing.]

Part 1 was on how to structure a large Data concern.

Part 2 is a supporting document to this post.

This post is on roles and how to structure people within those teams, how to evaluate them, progress them and remunerate them — and frameworks that can help.

TL;DR

Hiring, retaining, training, and promoting is hard. Risks are high, repercussions severe for wrong decisions, and cognitive biases Legion.

Your goal as the person in charge needs to focus on removing as much subjectivity and uncertainty as possible in the levelling, evaluation, remuneration, training and progression of people in their roles. Good org design is supported by these framework pillars:

1. Levels
2. Remuneration
3. Progression

Preamble

Organizational design is the oft-unspoken and under-appreciated role of a CDO/VP/Head of Department. Good organizational design avoids major problems in a company before they occur. Frameworks and practices created here pay dividends later.

Group vision and norms can be explicitly stated in structures, practices, and processes to provide clarity and psychological safety to your team. They provide the cultural superstructure and foundation upon which a team can grow quickly and effectively, which is key to a healthy, sustainable, and impactful group.

As an example, why is someone considered more senior than someone else? Why is someone paid differently than someone else? How does someone become more senior? (and how do you help them do that)?

Having an objective, logical, structured approach and explanation to levels, pay, progression, and hiring saves a world of future pain.

With data teams, many HR or People Ops teams are often ill-equipped due to the newness of data science and machine learning as fields to evaluate candidates and their levels. Bullshitters are rife. There is confusion over titles (is an Analyst a BI person or a full fledged data scientist that helps shape decision making in business units? What exactly does an ML Engineer do and how is it different than a software engineer? Is a data engineer just a fancier, updated name for data warehousing folks now?).

Few HR or People Operations teams will know and only highly professional ones will often have a good process for addressing how to practically work these things out and keep cohesion and balance within an organization . Worse, HR Directors coming from traditional companies where technology is a support function rather than a main value driver can often misstep here, causing serious harm by generically applying traditional models or frameworks here from traditional HR advisories (Hays, Mercer etc).

It is your role as CDO/VP/Head of Department to help the company understand the value of data, your people, and how they differ and are similar, as well as provide organizational design structure where they may be unable.

Your goal as the person in charge needs to focus on removing as much subjectivity and uncertainty as possible in the levelling, evaluation, remuneration, training and progression of people in their roles. Good org design is supported by these framework pillars:

1. Levels
   Clearly defined levels and a skills matrix setting out competencies, behaviours and expectations for each role at each level
2. Remuneration
   Compensation and package tied to those levels
3. Progression
   A career progression, training, and performance management framework

While also related to these frameworks, we’ll talk in another post about Hiring and processes for how you interview, assess, and classify people at level.

Levels

Almost everything derives from levels. Get these right and the skills matrix suitably relevant, and a lot of things fall into place.

For the sake of clarity, regardless of how people are titled in an organization (and often titles can be out of whack with actual seniority and expertise), I find it a helpful mental model to think about people in this manner. This is more for guideposting and reference in terms of what they do and their responsibilities. Note I am not making a distinction here between deep, technical expert track (Individual Contributors) and Managers (people who help coordinate ICs and grow them.).

Managers vs Individual Contributors (IC)

Another thing I highly recommend is making sure you have an individual contributor track as well as a management track for levels and distinguish them (and respect both). If you do not, everyone will want to become a manager, even if poorly suited to it, simply because that is the sole way to progress.

While seniors ICs do need to coordinate work and often lead projects and provide guidance to people, there is a different between operational direction and being responsible for managing a group and its collective work as well as growing and nurturing staff. Not everyone is a good fit for the latter (in fact, we often had people try it, hate it and ask to be moved back to being an IC.).

Also, without an IC track, you’ll also lose your best, in-depth experts to other firms that value craft and you want to develop and retain the deep expertise that can help drive solutions and make sure people feel that is valued by the organization.

Naming

One of the major issues you need to address is how you are going to title people. Believe it or not, this can end up being a huge issue in some regions. APAC had ridiculous title inflation going on (and still does) due to the cut-throat competitive environment for data scientists and MLEs before COVID where people’s levels in some companies were at least a level higher than their actual level leading to terrible title inflation and delusions of grandeur when people moved organizations.

This was further exacerbated by those new organizations not having good levelling systems. Even where the line was held, people leave for other companies because of refusal to put a senior in front of their title after one year on the job, or name them a head or director after 2-3 years.

While titles change, I highly recommend following a system similar to the one I outline here (though super difficult if your company has just decided titles are another form of futures-earning remuneration). I also strongly do not recommend basing it on years of experience or tenure or evaluating people based on tenure at organizations (it should be solidly skill and competency based) as 2 years at successful startup X is worth way more than 2 years at a plodding government ministry and the expectations on performance, value creation, and direction and initiative and often vastly different.

Resist the impulse to over-inflate people’s titles. It seems like a small concession to pay to keep people, but ultimately, it ends up rotting your group from the inside as people are way more concerned about relative levels and fairness than they are absolute levels or titling. The first time you cave to giving someone a Manager or Director title who threatens to leave for another job and who does not meet standards is the start of the road to ruin.

Strangely, this can even work for you and be source of pride for your team for having objective standards versus other organizations even if it can sometimes descend into a whiff of arrogance (so-and-so wouldn’t even be a Senior in our team. Company Y overinflates titles to compensate for poor pay and lack of progression and training.). This is one of the few places I respect Facebook. They have simple titles they do not generally deviate from.

Associates

People new in the role and quite often with less than 2-3 years practical experience. Primarily, these are people who still need significant guidance from someone more senior in terms of basic hygiene in engineering, data science, or technical product management. If you are training and progressing people normally, Juniors should be becoming titled engineers or data scientists, rather than Associates, and be ready at the end of two years of solid experience with you.

Titled

A solid mid level performer as engineer, data scientist, technical product manager. They are able to operate independently on projects and tasks of reasonable complexity with initial direction and guidance though requiring more guidance advanced topics such as architecture, approach, processes and such. In general, I find these people have between 2-5 years solid experience and delivery under their belt.

Senior

Seniors - These are your most experienced, knowledgeable contributors. I rarely see people attain this level without at least 5 years experience in a role and it can vary as widely as 8. These are the go-to people in your organization. They require only light direction and can run unsupervised on most well-defined projects and tasks as well as direct, advise, and grow others. The good can often sculpt out what a product, system, or Often, if they are not managers outright, they often form a fire team though their forté is not leading or growing others. They can be depended on it in a pinch to lead projects, however.

Managers

Managers - Manage. Their primary responsibility is to organize and direct others to accomplish a desired outcome. They are also responsible for growing and improving their people (which is often where many first-time managers stumble and top out.). A manager must also be growing and improving their team in terms of capabilities, expertise, and execution. Furthermore, they must be proactive, avoiding issues before they become problems (rather than claiming success for fires they themselves caused). Managers are directly responsible for the output of the people they manage.

Directors

Directors - Are managers who manage managers. Yeah, I know; but they do. This is also a level that is sometimes very difficult for technical personnel to move to and they stumble at, because they need to learn to manage indirectly. They are no longer directly responsible for the work output of people who they manage, as opposed to managing individual contributors. Also, director are often respinsible for a diverse domain or area in a group which means they often have to rely upon others rather than their own direct expertise.

Rungs

Within levels, you also need to provide some differentiation as well if you want to provide reasonable gradations of expectations within the role. This is because of people being new, fully realized in a role, and becoming senior to the point of progressing beyond it. Again, this is about relative effectiveness in the role, but having these extra gradations saves enormous issues for progressing people in a larger team and makes sense from both an expectations and remunerations perspective.

Personally, I am a big fan of there being a Low, Mid, High at each level.

Low is an entry level position at that particular level where we are seeing how the person adjust and operates to the new expectations at that level. A mid level is a solid performer at that level and High is where someone is starting to stretch the definition of the level and may be ready for a promotion to the next level in terms of competence and performance and needing larger challenges.

Why Low, Mid, High?

In just about every organization I’ve been when you ask people to assess people’s relative skill levels within a level, and particularly in comparison to other people, they will usually subjectively come down on being lower, higher or at the same level as someone within the level. This is helpful not only for progression planning, but also helps (once you have a strong competency matrix) to help evaluate incoming people you’re hiring and place them as accurately as subjectively possible with the obvious limitations of an objective skills matrix (since you can usually not position someone with absolutely accuracy as no interviewing process can assess perfectly.).

Remuneration

When you are a small team and directly managed differences between levels are usually clear (you have a manager and individual contributors), but as groups grow, different types of individual contributors and managers join, somehow you have directors whose job is managing other managers, and the question of what level of seniority people are, what is valued by the company, what people take home, and how people progress (often to get paid more) becomes critically important if you are to recruit, retain, and grow individuals. For talented data scientists and engineers, clear answers here are a key consideration on which companies they will work with.

Anecdotally: Arriving at a previous role, I wanted to understand why someone was recruited at a “T6” level versus someone at a “T5”. HR straight-up told me, “They’re a T6 because they’re paid more.” This and other incidents had led to the impression amongst staff that the company retconned levels according to people’s salary levels at their previous jobs. and worst, that pay and progression were unfair and biased (particularly for people coming from certain companies or roles.).

This is not an uncommon story. In fast moving organizations, objective evaluation criteria on people’s levels can be thin on the ground. This is further compounded by the fact few HR departments have experience with setting engineering salaries to begin with considering the competitiveness of the markets, or understand the distinction between dat groups and engineering, and often transplant “corporate” models from companies like Mercer or Hays which are ill-suited (to say nothing of the fact on how guarded salary levels are across some companies leading to little data and anecdotal evidence on salary ranges.).

Problems here compound. In one instance, two different interviewers had wildly different assessments on a charismatic candidate based on their subjective assessments of the candidate’s SQL skills (which, imho, was not even a good benchmark on if they would succeed at the role; Python skills probably being better), leading to a major bun fight within that group. And even organizations that are good at hiring will often have strange markers they use (one that used to drive me nuts at a company where I felt we actually did hiring well, was whether a candidate was good with vim, the de facto editor used by everyone on the dev team there.).

But again, I feel remuneration issues come down to a lack of objectively defined levels and too much wiggle room around salary ranges. Salaries need to be fair an internally consistent as well, and reflect the value that people bring to the company with their time and outcomes.

Also, I find pay and benefits largely ends up being a matter of philosophy, often of the executive group and their past experience or political leanings, or in more dangerous cases of the HR Head. Fact of the matter is, it is often an enlightened area despite lots of research on remunerations (excellent example: most research now shows that paying cash bonuses does not align individual incentives with company objectives. RSUs or options since it deals with the company’s longer term prospects are better, yet companies still continue to cling to “heroic” bonus payments despite the detrimental company effects it can have.). People will grumble about hidden payments and individually negotiated and differentiated levels (though everyone talks about their pay to their friends, so be prepared for repercussions if you are unwilling to make hard decisions about fixing broken relative pay structures.).

What works best for knowledge workers is paying enough money that pay and benefits are removed from that person’s day to day considerations. So, pay slightly above market. Unless you are one of the FAANGBAT, there will always be someone willing to pay more than you, and if your people should be engaged by their work, the mission, and fact they are benefitting in more than simply financial ways from their employment. In fact, I tended to avoid people who were simply and obviously in it just for the money. Mercenaries cannot be depended on to build a company.

However, I will tell you what worked best in terms of avoiding issues for past organizations where I had some control or influence over remuneration:

Pay people of the same level and rungs the precise same amount.

The benefits ended up being legion:

1. Simplicity
2. Fairness (particularly cultural, minority, and gender)
3. It moves conversations on remuneration to being about someone’s level, and this a more objective conversation about their position in the skills matrix and value to the organiazation rather than about money.
4. Pay negotiation ends up being a stressful and awful process for both managers and employees, this removes that entirely.

You do need to make sure your levels are fair, and that you have a philosophy you can stick to that is defensible with your remuneration philosophy. That means you must be able to demonstrate factually a statement like “we don’t pay the highest but we pay slightly above market.” I suggest using salary surveys of competing companies within the industry so you have a good idea of low, mid, and high. This can be hard in someplace like Asia where people hide (and frankly, dissemble) about salary levels, but do the best you can in surveying, be open about shortcomings in the survey process (we showed graphs), and separate out pay from things like equity or benefits.

Since time and acquisition have now made these things irrelevant, for example, here were the salary levels in SGD at Neo Innovation about 5 years back and prior to our acquisition by Pivotal.

Level	Low	Mid	Hi
Junior	60k	75k	90k
Mid	90k	105k	125k
Senior	125k	165k	180k
Principal	180k	210k	225k

Our commitment to staff was that we couldn’t pay the most (and certainly not as much as tech darlings like Twitter, MS, and Amazon at the time) but we would pay above average and targeted a certain percentile, as well as a commitment to doing a salary survey annually to understand how the talent market may have moved (which was sometimes a surprising amount in SIngapore.). We also, for our size, had an excellent benefits program which was based on a “Canadian model”. It did not do a great job at day-to-day things that may come up, but if anything serious happened to you, you would be taken care of and had benefits not normally in a workplace medical package here in Singapore (as an example, neo-natal care since we had a lot of budding parents.). Bottom line, we aimed to make sure people were financially comfortable and taken care of, though sadly a promised ESOP from our parent company never materialized before we were acquired.

One interesting note: I actually eliminated annual bonusing when I came on as Managing Director. It was arbitrary, overly subjective, a cash flow nightmare, and since it as tired to performance reviews, led to hurt feelings and accusations of bias, and strangely re-engineering salary bands to be fair and have less of a “kodak courage” type component actually seemed to lead to more staff loyalty than less (we had a ridiculously low turnover rate up until acquisition.

Originally when we were redesigning compensation, we were inspired by Buffer’s open salaries formula, but trying to get a formula which worked internationally (where ranges differed enormously) did not work so we eventually came down on the bands. We did have transparent salaries (internally) and our ability to say things like “everyone at the same level is paid precisely the same” actually carried a lot of weight with both staff in terms of its perceived transparency and fairness. It also bought us a lot of street cred in the market as being a good place to work that treated people fairly (which, I often think is the best thing to optimize for.).

And finally, one interesting thing I’ve noticed across a number of sectors, industries, and companies: relative levels are more important than absolute level in terms of salary.

As a cautionary morality tale, one organization I was at revised salaries and then put one particular class of employees at an entire level above other staff roles at the same level, effectively signalling that this particular role was more important and somehow “worth” more than other people at the same level. Particularly, because this was an organization where people were already taking an altruistic hit compared to what they could get in the market and no one believed that these people were an entire level more valuable, it caused a near-walkout at the company and damaged already poor relations between management and the (large) company. Any goodwill management had bought in terms of finally revising salary levels after years of complaint was vaporized and actually made worse (despite the fact people’s absolute salary levels went up.).

Alright, so you’re convinced at the level structure and the ideas around remuneration. How do you objectively figure out which people go where, level-wise? That’s where a skills matrix comes in.

The Skills Matrix

A lot of justifiable criticism has been levelled at competency frameworks. I believe a lot of it has been due to broad, fuzzy, over-inclusive frameworks that do not provide enough specificity or succinctness to provide clear, objective direction to the people using them. They are a tool only as good as the discipline and rigour in defining them. With clarity, simplicity (the hardest part), and specificity I do believe a matrix can help reduce subjectivity in levels within a role and between roles.

They really have one job: for an identified role and level, to objectively define the skills, degree of mastery, and behaviours that need to be demonstrated. This allows individuals to clearly understand what their next action/goals are depending on what they want to do with their career. The acid test of your matrix is if someone can look at how they score on it, and go “ok, this is what I need to work on next to achieve X in my career.” X could be simply getting to the next level or it could, for an engineer for example, be how to cross train go become a data scientist or MLE.

The hardest part here is keeping it simple, but appropriately distinguishing between skills which deliver outcomes vs outputs, and evaluating staff appropriately on it so one can determine progression for your people. When you figure out how to do this flawlessly, please call me.

The other issue here is you need the matrix to clearly show where there are gaps in an existing staff member’s level and the skills and competencies from what the skills matrix says they should be exhibiting at their level (since that involves catch up training, or where there are real problems, performance management.).

Let’s take two examples of matrices, years apart, whose statute of limitations have expired:

1. Neo Innovation (Pivotal Labs APAC)
2. Traveloka’s Data Team

Neo’s Skills Matrix

The first matrix is from Neo, which was Pivotal Labs APAC at one point, spun off to Digital Garage in Japan to become part of global venture builder Neo, and then reacquired five years later at a much higher multiple by Dell/Pivotal to anchor Pivotal Labs APAC (again).

Pay equity and progression were serious issues when I arrived as MD (there had been some high profile resignations over pay equity just before my arrival; a good example of what happens when basic management frameworks are not in place. In fact, those triggers and their solutions were the original domino that probably led to this blog post being written now, years later. At the time, my analysis was that a number of problems stemmed from lack of transparency around how pay, progression, and assessment were handled and too much subjectivity around their determination, promotions, and bonusing.).

As a venture builder we focused on building new businesses or major new capabilities for existing businesses and enterprises. We had startup clients whose entire businesses, business model, product, we were building out, and on the other hand, large enterprise who could not move quickly enough and used us to build out what they could not internally.

We needed engineers as they gained in seniority and on top of already excellent engineering skills, to have excellent consultancy and some client management skills, as well as being able to run projects and sprints in an agile manner, unstick stuck projects, and run key processes like scopings, interviewing, and Iteration planning meetings. In a lot of the respects, at the top level for Principal Engineers, I often felt like my job was to replace myself as Managing Director and have them graduate from running a project to a portfolio of ventures we were building (and for good succession planning for myself, eventually the entire business.). The implication of this was that we did not have a separate Individual Contributor vs Manager track, so team management skills as well as technical competency was required.

We had a town hall with staff where we said we would develop a better approach. There were 3 components to our solution:

1. A skills matrix to have people understand where they were and what they needed to develop
2. Transparent salary levels (An idea we ripped off completely from Buffer. And a salary market-survey of the highly volatile Singapore market which we transparently shared with staff.
3. Requiring managers to do weekly 1:1s, coaching, and quarterly progression reviews with staff tied to the Skills matrix and their career goals

At the time, we were just trying to fix a major problem, but our approach won us a lot of respect and street cred in Singapore and the Singaporean development and data science community (which is a very company-friendly country, usually to the determent of people working there.).

Our Skills Matrix looked something like this. Looking back now, I feel it is overly raw, subjective, and fuzzy in certain areas but it did solve many of our problems at the time and created better conversations and progression outcomes for people. However, it was a good stake in the sand at the time and provided clarity where only opinion existed before. It, and a commitment to continually iterate on it, solved our problem.

Traveloka’s Data Team Skills Matrix

More appropriate to people trying to figure out how to do this for a data team (especially in environments or countries where there are differing standards on what constitutes a data scientist, analyst, or data engineer. Traveloka had much different issues than Neo.

Primarily the problems there were a rapidly expanding company that was extremely bottom heavy with junior employees and lack of experience in data and engineering, and a lack of an experienced senior management bench. The HR department was equally junior, heavily on Loka’s recruiting deficit, and making sure people got paid, so there were few management frameworks in place. Particularly as the company expanded beyond Jakarta, it was causing significant strain as we tried to hire. While software engineering was slightly better understood (though often, inconsistently and incoherently focused team size, which led to the economic disincentive of managers blowing out headcount in order to progress and over-inflate their groups.), its use in providing guidance to data scientists, analysts, data engineers, and MLEs was limited as well as the skills expected. Especially in comparing levels between countries, we needed an objective standard to attempt to calibrate to an international standard.

Traveloka Data Team Skills Matrix

While it certainly wasn’t perfect (for example, in retrospect I wish I’d combined several skills into Influencing rather than things like Storytelling and Presentation skills amongst others.).

Effectively, we had two major “job families”:

1. Data Science
2. Engineering

Data Science included the oft-overused Analyst title which, depending on the organization, can range everywhere dome a spreadsheet slinger to a full-on data scientist capable of deploying a PoC mode-driven API. For Loka, we were ere trying to move beyond the role’s humble BI and Reporting origins in the company to become a “Data Science for Humans” role where they applied data science and business acumen with business unit stakeholders into helping drive good data-driven business and product decisions in the organization; move to “So, what?” from reporting’s start as the “What” that happened in the business.

The astute amongst you will notice the lack of a Product Management role skillset. Unfortunately, due to internal politics at Loka (and a very poor product management culture there generally) we were not allowed to hire product managers despite the dire need to have data products managed and putting engineering and data science leads in the unfortunate position of having to handle large volumes of communications overhead with other groups. This is an anti-pattern. Fight to make sure they are hired and appropriately skilled (and make sure they are product managers and not project managers. Traveloka is confused to this day on the distinction — though experienced product management is a very scarce skill in APAC.).

In general though, while there are some rough spots in the matrix I think it provides a good baseline to developing or enhancing it for your own needs or comparing it to your own. In particular, we had a reasonable way of distinguishing between different roles, such as Analyst, Data Scientist, Data Engineer, Software Engineer, and Machine Learning Engineer as well as providing a way to help people understand what they needed to do next in order to develop towards promotion, and particularly in the case of a large number of Analysts who wanted to start cross training towards being Data Scientists, or Scientists who wanted to move towards MLE roles.

Additionally, we had a clear system for progression where you needed to constitute a certain number of skills areas in Cross-Disciplinary and Core role skills before you could nominate for promotion.

If you do use the matrix or have feedback on it, please make sure to let me know how you feel it needs to change or how you have modified it at @awws or via email at hola+skills-matrix@wakatara.com.

A surprising number of people have asked for this as a jumping off point to beginning their own in various companies and I like the idea of improving this base over time her eon the blog and helping to contribute to making data teams better globally as well as leading to disambiguation of roles and expectations across the board.

Note: You’ll obviously have to calibrate it with whatever internal grading and levelling system may exist in your organization. So, unless you’re starting from scratch it provides more of a guidepost than anything else (for example, at least at Loka it was was difficult to distinguish between the skills necessary to demarcate a T5 and a T6 which were legacies of the existing system in place.).

A slightly terrifying and necessary step when you’re happy with your Skills Matrix and have socialized it with all your staff, is that you will need to assess where current staff are regardless of what their current levelling may be in relation to the matrix. Usually what you’ll find is that most people may need some work in an area or two to come up to expectation, but usually it’s something that can be adjusted to within a half. Bigger problems with people (usually earlier joiners or people been with the organization longer) who may have been promoted simply from longevity or attrition and you have a serious gap between their demonstrated skill levels and the expectation. This is where Growth Plans come in. You need them not only for the people where you may have an assessed gap, but for every person on the team, so you have a clear progression and levelling discipline and people are working and progressing through learning and improving. Basically, how do you keep challenging and growing people? This is the subject of our next section, progression.

Progression

The type of people you want on your team are those who are intrinsically motivated to learn, grow, and improve. In line with Dan Pink’s pillars of Autonomy, Mastery, and Purpose, you will need to constantly be challenging the limits of your staff in order to provide fresh challenges, grwoth opportunities and learning. Most organizations simply talk about this in the context of how to get to the next level in your role in an organization. This is short-sighted and insular. Talented staff members have many opportunities available to them, increasingly globally, and a key part of your EVP (Employee Value Proposition) is tailoring what you can offer to them in order to keep them engaged, growing, and with you for as long as makes sense (let’s face it, these days, getting 304 years out of a staff member before they move on to other roles, interests, or even careers is a good run.).

It helps to have your people managers think of your staff as customers rather than employees and flip the usual dynamic on its head. Sure, we recompense them with money for the skills they exercise with us but what do they want? Why should they as a scarce, valuable customer “buy” from us and continue to buy from us longer term? Why would they be loyal?

Much like any (good) sales person you need to determine what problems and needs your customer has and figure out how to tailor your offering to see if you can solve their problems and have something where they are willing to have a longer term buying relationship with you.

Deeper, entwined relationships of mutual exchange lead to more engaged, happier and productive employees, which not only benefits the company from an productivity perspective, but ultimately also has network effects in making things like attracting, retaining, and developing talent easier.

How do you figure to how to develop an employee value proposition (developing a general one for growing staff and for more senior staff is easier, but to individually tailor it)? It starts with talking to your staff.

I have to admit, this is as area I’d have to say I did not have a great, directed tool for answering these questions until a few years ago. And, while I’d love to say I came up with something myself, the bulk of what I came to end up using and setting as a standard in places where I could, I ripped off almost wholesale from Kim Scott’s excellent book Radical candour (Scott was the person who designed the “Learning to Lead at Apple” programme which is renowned in the industry for helping to mint future business leaders.)

The Progression and Career Discovery framework is a simple, easy-to-teach set of 3 one-hour conversations where you talk about a staff member’s:

1. Past back story influences, opportunities and developments
2. Their life goals, aspirations and possible future paths
3. A conversation about how to build a path and what opportunities you can offer to help them develop towards that

Keep in mind, some of these convos will not necessarily be about promotion or getting to the next rung. In a number of cases you’re talking about how to align interests that will eventually diverge but for, say the next 2-3 years, have mutual benefit. For example, in a number of cases, we’ve helped people build skillsets for them starting their own companies (they has entrepreneurial aspirations), returning to do their PhD (really interested in research), modifying their role so they could spend more time raising their kids, and in one interesting case, helping someone who wanted to eventually return to being a farmer.

Also, I have to say it is absolutely fascinating to spend so much time understanding your staff. I guarantee you, you will come away with a better appreciation and understanding of your staff and I have never seen an example of where that has not provided dividends. Quite simply, it will allow you to be a better boss and manager, and if done well, will definitely build trust and social capital with your people.

Promotion

While we never quite got to this point, I always wanted to have promotion being a self-validated and panelled decision. The way the skills matrix worked was that once you were capable of exhibiting 3 of the 5 core skills to your role at the next level (as well as common skills) eg. T4 if you were a T3, you could nominate yourself for promotion in any quarter and this would be checked by a quarterly panel of the Senior Leadership Team we had. We never quite got to the point where people were self-nominating because of the already existing internal process at Loka, but I always felt it would have been a cleaner, more logical approach to promotion than was advocated by People Ops during the PMS (no, I am not kidding, that’s what is was TLAed) at Loka.

Growth Plan

An important step here is also to evaluate your team member against where they fall on the Skills Matrix for their level and role. Particularly if the person is progression-minded, it is important to fully assess where they fall in the ranges of expected skills and to have a frank conversation on where skills need to be improved to get to the next level as well as your assessment of how long that may take (fend off people trying to treat the Matrix like a box to be ticked off to get to the next rung or level. It is meant to be a holistic big picture guide in the Growth Plan, not “I took a Coursera course, I now know data science, promote me” type tool.

The Growth Plan should be lightweight and should be thought of more in line with an OKR approach. If the Objective in 18 months is to grow towards being an entrepreneur then Key Results may revolve around building an MVP with a small team, learning about Sales and Marketing, and gaining understanding about P&Ls.

Roll out

My advice if you are trying to roll this out across your team is to clearly set the objective with your senior leadership team that this is something where you want to target to have this process (and, if your team is not already doing them, weekly or biweekly 1:1s) in place by the end of next quarter. It is not hard, though it is work, so like every new initiative it will take time and effort to carve out time from BAU (Business as Usual) and whatever you’ve normally been doing to get this as an established, evergreen process in your org.

First off, go through the series of 3 convos with your direct reports. Share this written guide on how to walk through the process. Teach them how it works and use the example of the Growth Plan you build with them as a template for them with their staff.

Fin

The expectation from talented data scientists and engineers that you want to retain is fundamentally that they will learn and be rewarded in relation to the value they bring the company. Your goal as the person in charge needs to focus on removing subjectivity and creating processes and frameworks which provide logical, coherent structures for people to work in over time. Good organizational design avoids problems and ends up being a form of social contract against which people can plot long term career and life goals supported by the company, increasing retention, satisfaction, and productivity. These were some of the constructs that worked well in running two distinct teams and businesses in SouthEast Asia. Good luck.

Let me know what you think about the post @awws or hola@wakatara.com. I’d love to hear feedback about what else or similar thinking about what works for you. Even better, (reasoned) opinions on why I might be wrong and what might make it better.