LinkedIn is good and, sometimes, not so good. The plethora of contact invites that come in daily is bewildering at times. With many people using the network to ‘push’ sales lines at other members, it can feel invasive. Others ask to be endorsed and recommended by contacts that they don’t really know. Then there are the requests for contact introductions to people that you appear to be connected with, but in fact you can’t remember why you have a link to them in the first place. All that being said, it’s also a valuable network for connecting with industry professionals in all fields and specialisms… but does it make you happy?
For any technology to make end users happy, the software application developers behind the platform in question have to be happy from the start. The software engineering team at Linked is taking that thought seriously as it now moves to open source its Developer Productivity & Happiness Framework (DPH Framework). This ‘framwork’ is a collection of documents that describe the systems, processes, metrics and feedback systems used to assess how LinkedIn’s own internal developers feel and be able to understand their needs.
Change navigation
LinkedIn senior software engineers Max Kanat-Alexander and Grant Jenks have blogged to remind us that developers today are navigating a lot of change, especially in this era of generative AI. This means that teams need the systems, processes, metrics and feedback systems to be successful – and of course, happy.
“Over the last four years, LinkedIn has invested both time and resources to create a set of guidelines on how to design such a framework, starting from the high-level philosophy of how to think about the problem and getting down to specific best practices for implementers of data pipelines,” note Kanat-Alexander and Jenks.
The framework starts off by describing a ‘high-level philosophy’ that the team use internally to guide work, covering (and in fact named) goals, signals and metrics. Its first function is designed to solve one of the most difficult problems, “How do I choose what to measure?” The team then uses this framework to describe the specific goals and signals that it selected.
Developer personas & champions
“Next, we discuss our ‘developer personas’, a system we developed for categorising developers into different groups based on their workflows, [which involves] thinking about priorities separately for each of those groups. The documentation provides information on how [an organisation] can design its own developer personas system. It also describes our concept of ‘persona champions’, who are volunteers from across the engineering organisation who understand the workflows and pain points for these engineers and can share those insights for consideration and incorporation into the system,” note the pair.
Kanat-Alexander and Jenks say that they discuss the difference between ‘data’ and ‘insights’ when a team wants to use qualitative (objective) data vs. qualitative (subjective) data, how to drive decisions (and provide the right data for an audience) and what data a team should collect (including some thoughts about data schemas for engineering data).
“When your data systems are in place, you’ll need to translate that data into concrete metrics, reports and visualizations,” say the LinkedIn engineers. “We cover the key principles you’ll need to think about when designing any engineering-related metric and explain some of the common pitfalls in metric design. This includes understanding the potential problems of aggregating multiple metrics into a ‘score’ and the reasons why ‘volume of output’ is not the best metric for judging the performance of individual software engineers.”
Detailed definitions, example metrics
To demonstrate how all of this works in practice, there is a set of documents that detail a few specific metrics that the team has actually implemented at LinkedIn. It starts off by describing a few key concepts in developer productivity that are often thought about when they design metrics. They then provide detailed definitions of a few example metrics, covering both some company-wide developer productivity metrics, and a few metrics that are specific to an individual team.
The team made the DPH Framework open source so that users can fork, modify and re-use these documents however they wish inside of their own company. Users will need to respect the Creative Commons license that is on the repository.
“We are also looking forward to community contributions that help move forward the state of the art in understanding software developers across the entire software industry. If there’s something missing in the documents that [any user would] like to see added, feel free to file an issue via our GitHub issues tracker! If you just have questions or a discussion you’d like to have, participate in our GitHub Discussions,” say Kanat-Alexander and Jenks.
Let’s hope that this data-centric approach to developer happiness translates to LinkedIn user happiness and a wider proliferation of happier experiences across the network itself. In fairness to LinkedIn, journalists (or other professions where there is a definite trend for ‘selling to’ individuals) probably get more ‘flak’ sent to them across the service than most other users and it’s a question of choice to expose yourself to the service in the first place.
In summary, I’d like to add you, but I want you to be happy too.
Image credit: LinkedIn
2 days ago
