Background
DevEx is Important
DevEx (Developer Experience) refers to the perspective that emphasizes respecting the human experience of developers, rather than just maximizing productivity as if they were machines. This acknowledges developers as individuals with unique experiences that should be valued.
Different factions have varying definitions of DevEx. Companies proficient in business, like Microsoft, consider it as "the absence of obstacles in performing tasks" (https://microsoft.github.io/code-with-engineering-playbook/developer-experience/). I find this narrow and not favorable as it doesn't break away from the principle of productivity.
I've written an article titled Beyond Productivity: Embracing Experiencity, which takes a broader view.
DevRel is Also Important
DevRel (Developer Relations) is about viewing developers as customers deserving meticulous treatment to build a good relationship.
Originally, it was external. Companies developing products aimed at developers as target users would nurture a close relationship with them to ensure sustained use and advocacy of their products. Given that users are developers, aligning with their values becomes essential. Compared to general users, there's a heavier emphasis on information dissemination and participatory events. Thus, roles like evangelists and advocates specializing in these activities are highly valuable.
Recently, internal DevRel has also emerged. This is particularly relevant to Platform Engineering, which considers in-house developers as customers to cater to respectfully. Essentially, engineers are the backbone of a company, thus, they are of utmost importance and deserve close attention. For instance, an API platform used by internal engineers can be seen as a business targeting its internal developers as customers.
Merging DevEx and DevRel (DevRelEx)
I feel that DevEx and DevRel are beginning to converge. Essentially, it's about improving DevEx as part of internal DevRel. As it's inconvenient without a term, let's call this DevRelEx.
That said, without resorting to such complex terminology, engineering managers are already working for their teams. However, there's a high level of personal dependence.
I wanted to change this "wasteful" situation and scale it, so I created Soft Skills Engineering. The technical aspect alone is not enough for DevEx and DevRel. There's another critical component: soft skills. Specifically, detailed implementation and operation tailored to the individual, team, and organization are crucial. Such tasks require professionals with an engineering mindset.
As a practitioner of Soft Skills Engineering, I have conceptualized something useful for DevRelEx. Let me introduce it.
Manager As A Function
Manager As A Function (MaaF) means regarding the manager as a function. Members utilize the manager as if using a function. MaaF is the abbreviation.
Before/After
Traditionally, managers, who are superiors, were somewhat unilateral in their management role. Even skilled managers, proficient in active listening and relationship building, remained in a higher hierarchical position.
Conversely, in MaaF, members are treated courteously, embodying the ethos of DevRel. Member needs are prioritized. As such, the manager embodies a functional role, openly inviting members to utilize them as they see fit.
What Manager As A Function Offers
As a function, MaaF must provide an interface.
Here are a few examples:
1: Direct Appointment
This might already be in practice in many organizations, which allows anyone to freely add appointments to the manager's calendar whenever there is a free slot.
From the manager's side, any problematic appointment can be rejected, otherwise, approval is given by default.
2: AMA and RMA
Ask Me Anything and Request Me Anything formats. These can be conducted in meetings or asynchronously.
For further details, refer to:
3: Office Hours
This is primarily used by university faculty for students, where the faculty announces, "This time slot is open, feel free to drop by, and I'll answer any queries."
4: Manager Tickets
Since this is a coined term, let me explain in detail.
A Manager Ticket entails conducting exploration and providing responses within a range manageable in about an hour. The exploration and response take place asynchronously, with the response taking the form of messages, documents, or prototypes. Managers dispense these tickets as needed. When provided with a ticket by a member, they conduct research and provide responses within an hour.
The benefits of Manager Tickets include:
- 1: The ability to quantitatively track the operation of tickets
- You can increase the tickets if they seem sparse, or decrease them if there are too many.
- 2: Satisfying the needs of members from a DevRel perspective
- 3: Easy reach towards DevEx
- Members naturally start making requests to improve developer experience.
5: Maintenance Period
Being a MaaF doesn't mean always being available. Managers have various responsibilities. Thus, a reasonable maintenance period where MaaF requests are not accepted needs to be established.
Typically, a manager's time usage might be divided into three categories:
- 1: Meetings
- Traditional meetings conducted as a manager
- 2: As MaaF
- A dedicated time to respond as MaaF
- 3: Individual Work
- Time to focus on solo tasks and thinking
- Ideally, neither 1: nor 2: should infringe upon this, but interruptions can occur.
My recommendation is to schedule the maintenance period in half-day spans at the very least. A daily span is even better. Just juggling regular meetings and responding as MaaF can significantly affect well-being, so a solitary time is necessary for self-directed activities.
Conclusion
I talked about the emergence of DevRelEx as background.
Then, I introduced a tool usable as DevRelEx: the Manager As A Function. I also organized five interface ideas usable for that purpose.
We live in an era characterized by VUCA, DEIB, and generative AI. A volatile, uncertain world where answers aren't clear and expectations on employees are high. Thus, the perspective of DevRelEx seems all the more needed. Everyone is encouraged to be conscious about it and try using MaaF. See you next time.
Top comments (0)