No Rules Rules
From early on in my years as a line manager, I’ve believed in the simplicity of hiring great people and trusting them to deliver with the minimal level of guidance required. Ruby Labs is in a place where its culture and ways of working are still being defined and a big influence is the culture in place at Netflix: hiring at the top of the market in order to purposefully increase talent density, regular and immediate but constructive feedback, avoiding rules and controls in favour of trusting your staff... It is consistent with the way I’ve thought about how an organisation should be. As I took the autonomy promised to me in my last role at face value, I plan to also take this cultural approach at face value in my new role.
Hiring at top of market is something that I think many companies would find contentious. Some companies feel their staff should stay with them even when offered more elsewhere, and that taking these offers makes them disloyal; at the same time, these companies won’t hesitate to make their staff redundant when they change strategy or encounter difficulties. Ultimately, most people work to earn a living and to increase their wealth. Why should they earn less than they could in an increasingly uncertain market?
I find this new approach to building and maintaining talent density refreshing, allowing great staff to be paid top of market and having this proactively maintained. I have seen great colleagues’ and my own packages curtailed due to the distribution of other staff, and salary bands that have not moved with the market. This situation prevents the hiring and retention of the best staff in the org, and I believe this will eventually lead to a downward spiral in talent density.
There is a flip side to this approach that may seem a bit brutal to some:
If a person on your team were to quit tomorrow, would you try to change their mind? Or would you accept their resignation, perhaps with a bit of relief? If the latter, you should give them a severance package now and look for a star, someone you would fight to keep.
I think if constructive and timely feedback is not given and the outcome is as above, then I would feel this is harsh. So, having strong and fast feedback systems is key, as the scenario above can’t be avoided in order to preserve talent density.
Err on the side of Transparency
Transparency is something I believe in deeply, and I am often happy to go far beyond what others are comfortable with. For example, I believe open salaries and cap tables should and will become the norm in the future. Having salaries as a secret is unhelpful, as it perpetuates the distribution issues mentioned above, plus when employees do discuss salaries you have a half-truth in existence which is worse than no information. People often make up a ‘truth’ in the absence of real information; the human brain naturally extrapolates and interpolates distributions.
No Rules Rules covers a great deal of how transparency is a vital part of trusting your staff, and how doing so gets them to treat the company as their own. There were even examples of sensitive problems being solved because they were shared at Netflix, when other companies would try to deal with them behind closed doors.
Abstraction of line management
One of the things I really liked about the application of the Spotify model at Lyst was the abstraction of work management from line management. Squad leads at Lyst would govern the work needed to be done for a project or team (often Product Managers) and these people didn’t also need to line manage anyone at all.
I see traditional line management including three separate activities:
Mentoring - helping someone do their job better and learn new skills to achieve this
Career Coaching - helping someone progress in the way they want: I’ve often approached this as person-as-a-project with milestones towards their goals
Execution Management - guiding others in what work needs to be done and in what order to achieve success in a project or goal
I love that Lyst were bold enough to allow the third component to be flexible. Often one person would provide all three roles for an employee, but with the hub and spoke model I implemented for data, people on the spokes would always have a different Execution Manager (Squad Lead) to line manager, who covered the first two activities for them.
I had proposed that actually the first two activities could also be taken on by different people, but had yet to see that implemented before I left.
There are a couple of reasons why I believe this final level of abstraction delivers value:
It allows individual contributors who don’t want to do career coaching to invest in other colleagues via mentoring. They often do this regardless, but it recognises the value of it and also allows access to more of these individual contributors for mentoring roles.
It allows career coaching to be taken on by non-technical staff when engineering resource is scarce and expensive. Often HR specialists could do this role really well, as they are trained in how employee life cycle processes should happen: 360 feedback, career ladders, pay review, promotion, probation, redundancy, learning… it’s a long list! There is a reason why the CIPD qualification exists; there is no guarantee great engineers and data people are also good at these processes. It should also help prevent HR being seen as a cost centre as they then act as a multiplier on scarce resource. They could even work in a matrix way inside other teams to deliver this activity, as some HR business partners do today.
Enacting the above will naturally increase retention as technical staff don’t find themselves divorced from the parts of the role they like, and they feel more supported generally.
I have had to learn all three of these skills to do my job well in the last few years, but I know of many who struggle with one or two and I’ve had line managers with greatly varying levels of skill in all three areas.
It’s also really important that people can progress to the very top of an organisation as either individual contributor or execution manager; some level of the three activities above will be required, but it doesn’t have to be traditional line management. There are companies where CEO and COO are roles at parity, but with CEO closer to an individual contributor and COO closer to a top level execution manager.
Org Design from outside
One of the things I’ve found in data is that you’re very dependent on upstream frontend and backend engineering teams outputting data; if they don’t have the time or care to ensure it’s of high quality, complete, and documented then it’s impossible to ensure analytical use cases can be reliably served. I’ve proposed an initial data org that includes Data Engineering, Analytics Engineering and Analytics, heavily weighted towards Data Engineering at first.
As part of this Data Engineering team, I have proposed having iOS, Android, and Backend engineers. They would perform integration of data collection SDKs into app and backend platforms, building of CI/CD tests for data, review and adjustment of changes to app and backend that impacts data, and to eventually intake and deploy analytical and ML outputs into these platforms. This may not always be full-time work, which is why they would work in Data Engineering in a matrix way, allowing them to be involved with regular product-driven work too which will deliver further synergies and benefits.
I haven’t proposed doing this before in previous roles, but it seems like a logical solution to the problems I have seen; enabling progress at the speed Ruby Labs needs, without relying on stretched existing teams that have different goals. I’m looking forward to feedback on this from Ruby Labs but would love to get some from anyone that reads this, too.
I caught up with my new CEO ahead of starting my new role, about hiring for data, and he brought up Mikkel’s substack! I’m really excited to start at a company that sees data as so core to its success!
Thanks for reading! I’ll be back soon with a new topic.