DEV Community: Jan Schenk (he/him)

Teams, Slack, Discord. What's better?

Jan Schenk (he/him) — Tue, 19 Mar 2024 13:08:44 +0000

Of course, the question is not as simple, and your answers will be tenfold more complex than my question.
What thoughts would go into decision making if you were to chose a communications platform for your software engineering team?

Imagine your team is going to grow from tiny (5) to large (200+) over the next 24 months and Office 365 is the predominant productivity tool in the company.

You may take into account these factors:

accessibility
image
privacy
costs
flexibility
data sharing
speed
integration of external participants
availability across operating systems
adoption
trend

Or just comment your favourite tool from a gut feeling. But please state what made you chose one over the other.

Happy discussing!

Build a successful API by understanding user personas

Jan Schenk (he/him) — Tue, 16 May 2023 16:16:41 +0000

This article has been written by Bruno Pedro on the Postman Blog.

Postman Open Technologies Knowledge Base is a new project with the goal of providing insights from a vast amount of information about APIs available on the internet. One of the project’s objectives is to provide an API that consumers can use to retrieve information from the Knowledge Base. The result? As part of my work on the Postman Open Technologies team, I have been building the Knowledge Base API.

I’ve naturally started by following our Postman team’s internal API Design Playbook. The playbook is a series of steps that help anyone building an API come up with a solution that meets the needs of consumers. (Stay tuned for when I make this publicly available!) The API design steps covered by the playbook are strategy, definition, validation, and finally, specification. I started the design of the Knowledge Base API with the strategy step, where the goal is to document why the API should be built. The output of the strategy step consists of findings and evidence that back the importance of building the API.

Finding evidence that the API should be built can be done by understanding and analyzing potential consumers. And that’s precisely what I have done: I have identified the user personas that can benefit from using the Knowledge Base API:

Technical researchers
API designers
Product managers
Technical architects

How do you identify user personas for an API?

To identify the four user personas, I engaged with people from each of the categories in a series of interviews. I wanted to understand what their work was like and what challenges they were facing. I also wanted to validate my initial hypothesis that they would be interested in the Knowledge Base API I was designing. Not only was I able to confirm most of my assumptions, but I also enriched the information I had with feature requests. So, for example, a product manager revealed that it would be interesting to get information about API design trends. A researcher gave importance to knowing the provenance of the data used in the Knowledge Base.

I then used the information from the interviews to create my catalog of user personas. For each user persona, I have identified their jobs-to-be-done (JTBD), the tools and services they use, their work-related challenges, the benefits they would get from using the Knowledge Base, and their potential behaviors when using the API. These attributes helped refine the user personas and will help me design the different elements of the API once I get to that stage.

At this point, it’s worth remembering that user personas are fictional characters representing a specific type of person who will be using the API. Each persona has unique characteristics, such as JTBD, benefits, behaviors, and challenges. For example, a technical researcher may be interested in using an API to gather data for academic research. In contrast, product managers may be looking for an API that helps them analyze customer behavior and preferences. The important thing is that you’re able to identify a cohort of users with each of the personas.

Benefits of knowing your audience from the start

Let’s get back to my journey designing the Knowledge Base API. With all the user personas identified and documented, I could then start focusing on defining other attributes of the API. By knowing the tools each persona uses, I was able to identify the best architectural style for the API. With the benefits documented for each persona, I could define the API capabilities. JTBDs and behaviors helped me identify the API resources and operations. Altogether, the different attributes of user personas can continuously inform how I design an API that reflects what potential consumers need. And that is critical to making an API successful.

In summary, APIs explicitly designed for targeted users are more likely to be adopted. Those APIs directly address the real-world problems or goals of users. Aligning APIs with user personas’ needs and behaviors from the start will yield better outcomes than assuming what is best and hoping that users will engage.

The post Build a successful API by understanding user personas appeared first on the Postman Blog.

10 reasons why you have to exceed at documenting

Jan Schenk (he/him) — Wed, 10 May 2023 07:18:32 +0000

I’m leading Postman’s Open Technologies Program Office — our open source program office (OSPO). My team consists mainly of open source contributors, and our parent org, Postman Open Technologies, is an incubator for API tech and a strategy think tank. There’s a bunch of high-profile industry experts that I work with and for, and I’m constantly switching between impostor syndrome and delusions of grandeur to change the world.

At a recent Postman Open Technologies team meeting, I gave a very general direction in saying that we have to be the team that is known for documentation and that we need to document everything individually as well as in a team effort. While there was more context, like our collaboration with the product teams, it is also a general recommendation that I give to myself as well as others in our industry — especially in these fields of work: engineering, OSPOs, and developer relations.

But first, let’s define the term “documentation.” In the context of this blog post, documentation includes external as well as internal technical documentation, blogging, sharing knowledge on social networks, demos, how-to articles, instructions, conference sessions, webinars, podcasts, wikis, infographics, flow charts, and the like.

I understand how easy it is to get lost in responsibilities in today’s fast-paced world. But while you won’t be immediately rewarded for writing documentation like you are for writing code, setting up a process, or resolving an issue, creating good documentation is about showing compassion to those around you as well as your future self. Its impact is mid- and long term, but needs prioritization now.

My top 10 reasons why being great at documentation is key to success

You should be known as the person who exceeds at documenting because:

Documenting makes you a better coworker and collaborator. Creating good documentation reduces frustration, lowers the level of collaboration anxiety, and makes previous decisions more understandable.
Documenting increases your value. It increases your value as a professional and makes you less expendable. Letting go of a person or a team that built a good part of the internal knowledge hurts. Hiring someone who is known for building persisting knowledge is easier to justify.
Documenting helps build your personal brand. Coming across the same author name over and over again when doing research makes you a subject expert. Add on top a few more measures,—like community engagement, mentoring, public speaking, whatever you choose—will greatly help your brand.
Documenting builds internal visibility. Being able to refer to something that you’ve written is easier than vaguely repeating what you have said or commented on a team meeting. Colleagues are more likely to give credit if it’s easy to do.
You can slice and dice into content creation. Once you’ve started documenting things, you can slice and dice it for content creation. Producing a video, writing a podcast narrative, preparing a talk, or inviting people with similar or differing opinions to a panel is way easier than starting from scratch. It also helps you find a red thread for your storytelling, which is another item on this list.
Documenting helps internalize your knowledge. And identify caveats. Repetition, that’s how the human brain works. Writing something down is exactly this. When your fingers are slower at typing than your brain is at processing information, you’re forcing it to repeat the same thing over and over again. That helps you either internalize findings or helps you find catches and bugs in your thinking.
Documenting makes your knowledge persist. The most obvious one, but also the most ignored point on my list. Have you ever come across a written piece and thought, Hey, that’s good knowledge, I’m glad someone else wrote it down! only to realize it was you two years ago? We forget, and that’s even part of our learning process. Storing information is not only something you do for others but also for yourself. And even if you don’t regularly update your content, it will be useful for a certain amount of time and maybe even beyond. (Disclaimer: This is not a good excuse for not keeping your documentation up to date!)
Documenting saves time. Were you assuming the opposite, that writing documentation eats up a lot of time? Have you ever felt like repeating yourself? That’s probably because you did. When you write documentation it saves you from the tedious work of repeatedly explaining to others. When you’re spending the third time explaining something, your time would have been better spent writing it down. You could still have that discussion with your peer, but you’d have it on a different level.
Documenting helps avoid the awkwardness of having to ask. It’s not only you feeling bored about explaining the same old thing a third time this week. It’s also them feeling bad about wasting your time. Coworkers might hold back from asking you because they feel your time is too precious. This hinders collaboration.
Documenting makes you better at storytelling. The bigger picture is something that you will be asked for. Being able to not only provide facts and figures but also develop a narrative and make the numbers stick to someone’s mind is priceless.

It’s important to note that while I say “good documentation,” I don’t ask for “excellent” or “outstanding.” That’s not because I think that nothing will ever be perfect; it’s because documentation doesn’t always have to be pristine. Often enough, “average documentation” does the job and is a legit compromise between effort and benefit.

Whenever you consider prioritizing documentation, which includes internal as well as external content creation, you definitely should always answer: “Yes, I will.”

The post 10 reasons why you have to exceed at documenting appeared first on Postman Blog.

Your Shortcut to Becoming a Contributor in Google Summer of Code

Jan Schenk (he/him) — Thu, 23 Mar 2023 07:48:30 +0000

Here's a shortcut to your participation in Google Summer of Code. Or is it? The following points are the absolute must-have-dones for a successful application. And yes, please do apply. All former participants that I have talked to say it has been more than worth their time.

📖 Take 20 minutes to read into GSoC. What it is and terms and conditions. You don't need to know every detail, but you should have a basic understanding of how it works.
https://summerofcode.withgoogle.com/

📁 Check out our suggestions for projects. If you don't find anything in there, don't give up. Browse other organisations. Open Source needs you, no matter where you eventually find your sweet spot. But we at Postman are definitely the best place for APIs. https://github.com/postman-open-technologies/gsoc-2023/issues

🎙️ Get in touch with a mentor on the project(s) of your choice. You can only apply to 3 projects, so you better know who you are committing to work with. How to find a mentor? Identify them on the issues and dedicated repos, and hit them up here or on the projects' channels (could be Slack or Discord or a forum. You will learn this from the issue/repo). Ask them if they think your skillset matches the project.

🧪 Try yourself out. There will be micro-tasks and first issues on the repo. This will help you make your first steps in Open Source as well as understand if this project is a fit for you.

🪪 Register and apply on the GSoC website. You can modify your application until April 4. Don't worry if you don't have all the details ready yet. But start with something that doesn't make mentors ignore your submission (like only uploading a CV instead of an application pdf, or skipping on the details of your proposal). Expect 1h and likely more for this step. But the earlier you get to actually submitting your proposal, the better, as it creates better visibility.

👷 Continue to update your application, and stay in touch with the mentors. Engagement in the existing community is key.

🏆 You got this! 🏆

Boosting Your Personal Productivity - Life Hacks

Jan Schenk (he/him) — Tue, 21 Mar 2023 10:49:20 +0000

I asked my Postman colleagues what their secrets to an efficient and productive day are. Here’s their tips on how to increase your productivity. Not everyone is the same, so some things may work for you while others won’t. That’s ok. You do yours.

The Shultz Hour - Reserving one hour per week to zone out in a controlled manner.

Morning Pages - Habit of writing down your stream of consciousness first thing in the morning.

Calendar blockers for catching up with Slack, email. But also for lunch. And more.

Focus time playlists - using specific music to get into the flow. Many music streaming platforms have them under the name of e.g. Deep Focus (Spotify), Pure Focus (Apple Music), White Noise (different noise colors work for different kinds of people) or similar.

Calendar Bot/AI - look into reclaim.io Geekbot - an assistant on Slack to manage your day and keep track of what you do. Can integrate with your calendar.

Geekbot - an assistant on Slack to manage your day and keep track of what you do. Can integrate with your calendar.

Physical barriers - One colleague mentioned uninstalling Slack from the laptop and only have it on their iPad that is on another table. Other barriers can include: No meetings on the laptop. Chatting and doing calls happen on a separate place. What a bold move!

Work equipment - A good keyboard and mouse (or trackpad, graphic tablet, other pointer device) can enhance your productivity quite a bit. So does a good ergonomic chair. Also habits: Coding, writing, or any focus work happen with a proper chair and table.

Habits - Another colleague mentioned that a morning routine only gets them started. And for them that even includes a game of chess.

Running - Lots of folks mentioned that integrating running into their weekly (or daily) schedule improved their stress level and helped them balance.

Peripatetic meetings - Take a walk while you meet. This doesn’t require the physical presence of your meeting partner(s). But it helps making it clear to them that you do this.

Self-awareness - Finding out how often you pick up your phone during the hours that you thought you’d be focused helps you learn about yourself. Same is true for screen time and received notifications. For me it was 41 pickups, 1h 46m screen time and 116 notifications. Today, at 11:30am.

Try out what works for you and let us know here. Or share your own productivity hacks in the comments.

Join Postman for Google Summer of Code

Jan Schenk (he/him) — Thu, 02 Mar 2023 11:50:21 +0000

To all folks new to Open Source but interested in APIs:

Google Summer of Code is around the corner and Postman was able to join the group of mentoring orgs. This means we're offering a bunch of projects from OpenAPI, JSON Schema, AsyncAPI and Collection Format to work on as a newcomer to Open Source. Never contributed before? This is for you. You're an eager learner in the field of API technologies? Come join us. You want to contribute to the awesome work API Specifications are doing every day? Hello!

Google Summer of Code, GSoC, is an established summer school for people new to contributing to Open Source. You don't have to be a student to participate. Your commitment is to spend 175 or 350 hours (depending on the project you choose) coding to extend an existing Open Source project. There's suggestions on what to develop from all kinds of organisations, but of course, Postman is the coolest to choose. Why? Because we care for APIs, which are the underpinning of all the tech out there. If you understand the API lifecyle and its impact in our modern world, you can literally work everywhere.

So throw your summer plans overboard, and apply for a GSoC contributor in 2023. We'd love to work with you.

There's only two things you need to know and do until March 20, 2023

1) Move over to https://summerofcode.withgoogle.com/ and learn about the program. If you're accepted, you'll earn $$ for contributing to Open Source. How cool is that.

2) Visit https://github.com/postman-open-technologies/gsoc-2023, choose from our list of projects and show us that you can be that awesome contributor you always wanted to be.

Don't wait too long!

We're looking forward to seeing you drop into our repos issues. (Hint: that's GitHub slang for visiting our repositories, heading over to the Issues section and start commenting and letting people know what your ideas are. No worries, you'll learn it all during this summer!)

Yours truly
Open Source Program Office at Postman <3

Writing an Open Source Policy

Jan Schenk (he/him) — Tue, 14 Feb 2023 15:18:42 +0000

I never had imagined I'd write the Open Source Policy of a multi-billion dollar company. Here I am now, leading the Open Technologies Program Office at Postman, putting together what shall become exactly that. And while I'm at it, here's the principles, concepts and resources that I'm using. Just in case you get to be in a similar situation. 🫶

Split the policy up

One policy will probably not do it. Consider 4 areas, I call them "books", not all being in the initial responsibility of your Open Source Program Office (OSPO):

Using Open Source as an individual or team
Using Open Source in the Tech Stack of your products
Contributing to Open Source
Creating Open Source

Using Open Source as an individual or team

This probably needs the least regulation. You can't control it anyway, as people will be using Open Source the minute they start working. Chrome, VS Code, even your operating system - macOS, Windows, of course Linux <3 - contains a hell of a lot of Open Source. If your company decided to manage the individual use of Open Source, it is on your IT department to manage devices, installation, security and risk.

Using Open Source in the Tech Stack of your products

Let's assume your company is using Open Source to build its product or service. It could be that there's already something in place, but not called a policy. It could be a guideline, a memo or a full process on how to handle Open Source, who reviews the licenses, and where to list components. Find this and collaborate to make existing rules parts of the new Open Source policy. This likely needs investigation and collaboration.

Contributing to Open Source

Depending on your company's values and culture, contributing to Open Source could range from being considered a priority,
a high awareness lip service (e.g. "in our DNA"), it could be welcomed but not encouraged, or it could merely be tolerated or even discouraged. An Open Source Policy can help mature the company to a better member of the Open Source ecosystem by creating awareness for the principle that Open Source projects can only exist with contributions. And the responsibility for contributions are with the people using the projects. This part of the policy should make it as clear as possible what is necessary to contribute to Open Source as well as be as simple and intuitive as possible to remove barriers for people willing to contribute.

Creating Open Source

This is not for everyone, and it might be you'd never make use of this part of the policy. But chances are high some team one day has a motivation to transfer company intellectual property to Open Source. Be it a converter of some sort, or a web framework that the team came up with as a by-product. Put a lightweight process into place that enables the company to assign the tasks to the right people (e.g. legal review, code review, sign-offs), and manage maintenance over a period of time. There's no use in open sourcing some code and forget about it, arguing that somebody would take care if it mattered to them. This part of the policy should make clear that building and nurturing a community is an essential and indispensable part of open sourcing a project.

Pull in other stakeholders

IT, Engineering, Product, Legal - these are folks that may already have an interest in Open Source processes or see a value of better management (e.g. to manage risk).
You will probably end up suggesting the creation of an Open Source board or council of some sort.

Think of Open Source management as a cycle

You're trying out an Open Source project.
You like it so you consider using it more or in a workflow.
You consider using it for implementation in the tech stack.
You find issues or bugs, so you fix them to make your product better.
You create a helper tool and feel this could be beneficial to others.
You open source it, so others could use and contribute to it.
Others use your tool.
It all starts over.

Be open and comprehensible

During your research, you will run into the risk of using abbreviations and terminology. This shows that you are growing into your shoes, as you understand more and more of the topic. And you can be proud of this extended ability of understanding. Since you are writing this topic, you are probably also the most literate person when it comes to policies, licenses and strategy of Open Source. The ones reading this policy didn't have the time or opportunity to educate themselves as much, so to be open and inclusive, you will need to package all policies in a way that is understandable for them. For everyone in your company. On that same note it is important to bake into your policies your company's stance on diversity, equity inclusion and belonging. To require a Code of Conduct for contributions and newly created projects is a must.

Learn from others

Here's some great starting points for creating your Open Source policy. I found them useful. I hope you do, too!

Why Using GitHub Pages is a Great Idea

Jan Schenk (he/him) — Tue, 31 Jan 2023 08:31:00 +0000

A situation probably everyone of us has run into:
I have knowledge, and I want to share and let people contribute to it, too. Classic use case for GitHub, isn't it? But then, how to say it without offence, GitHub isn't the most welcoming place for non-techies, right? It's not the go-to platform for people who are looking for knowledge apart from code. I think it's even realistic to assume that people who aren't using GitHub at least a few times a year are skipping on search results that have github.com in their url.

For me, this became even more of a problem when I started doing program management. There was internal wikis, where I could document our processes, strategies and policies, but as soon as I wanted to share and ask for contributions in public, I defaulted to using GitHub. Even though I was aware I'd create content that was only accessible to techies.

When I started working on career ladders for, admittedly, tech roles in our Open Source Program Office at Postman, I wanted it to be public. And I wanted it to have an impact on the industry. Because personal development is important. And too few people, managers as well as individual contributors, care about it. To help this make an impact I'd need to reach people outside of engineering teams, so this documentation could not be a README.md, hidden somewhere in a repo. I wanted it to be at least a website. One like https://career-ladders.dev.

I read into GitHub Pages, as I've heard from it before, but hadn't yet used it. I was very conscious that I missed out on one of those obvious features from the platform so long. And it embarrassed and still embarrasses me. Like I've also never used CoPilot. Never too late, they say. 🤷‍♂️

Here's what you have to do to make your markdown files convert to a website (full documentation):
1) have at least the README.md markdown file in a dedicated public repo
2) go to "Pages" through the repo's Settings -> Code and automation
3) use Source -> Deploy from a branch, and Branch -> "main" -> Save, for the simplest setup.
4) wait for the Action to finish. Can take up to a few minutes.
5) visit your page at org-name.github.io/repo-name

If you want to use only a subdomain (the part before github.io) and no appended folder name, your repo must be named <user>.github.io or <organization>.github.io.

I find the Pages representation of a repo helpful in many ways.

As a former web developer, I instantly see what information is missing. No images, not enough links, lack of description, how to navigate this? It's much harder for me to identify these missing pieces in the GitHub repo.
Having a website makes many people outside your bubble more likely to read your content.
Your project suddenly feels more important and real.
You learn because right now your page looks super shitty. This is the moment when you invest more time into learning how to choose a theme and re-work the structure of your markdown files. This is where to start.

If you want to learn more about my career ladders work, visit the repo on GitHub.

And these are the GitHub Pages for the Open Source Contributor and OSPO Engineer Career Path. You see I still have to improve a lot of things for that last "your page looks super shitty" part.

The Progress on Postman's Open Source Program Office (OSPO)

Jan Schenk (he/him) — Tue, 24 Jan 2023 14:36:57 +0000

This is the second article in a documentary on implementing an OSPO structure at Postman.

The OTPO, at your service.

Since October 2022, Postman has an Open Source Program Office that helps define structure and processes related to everything Open Source, as well as remove barriers to collaboration between Open Source projects and other teams. We call it the Open Technologies Program Office (OTPO), as it lives within Open Technologies, Postman's central instance of Open Source. We're here to reduce friction for contributing to, transfer projects into and create new Open Source. And make us become a first-class member of the Open Source community.

What were we working during the last 2 months?

Structure

Postman's OTPO became a general member of the TODO Group, an initiative within the Linux Foundation to help and promote the work of Open Source Program Offices worldwide. They have a bunch of content and guidance and an awesome community to share with and learn from. If I was to recommend one single thing to a company to up their Open Source game, it would be "designate someone to work with the TODO Group".

We also made some internal changes to enable some of our Open Source projects to directly work with the Program Office. This means some of the contributors working full-time for an Open Source project from within Postman are now part of the Program Office's org. I don't like to call it "reporting line", as that would suggest there's a reporting due. Such management is not what a Program Office is about. An Open Source Program Office is better represented by servant leadership princip[les, where your duty as a leader is "the growth and well-being of people and the communities to which they belong".

Policies

We're currently working on the general Open Source Policy for Postman. Postman is also participating on the TODO Groups working group to create guides, e.g. the Employee Open Source Engagement Guide, to help other companies build their own strategy.
Postman's Open Source Policy is built with focus on encouraging the use, creation and contribution to Open Source Software and Projects. It will cover these three fields in separate documentation, as "Use of Open Source" is managed by Engineering (use in the tech stack of the product) and IT (use by teams and individuals as tools), and "Contribution" and "Creation" will be supported and led by the Program Office.
Once this gets to a less drafty state, I will make it available as Open Source.

People

We have created an Open Source career ladder system for Open Source contributors and other roles within OSPOs, that you are free to use. We ourselves borrowed from Sarah Drasner's career ladders and Mary Thengvall's career paths. If you haven't seen a career ladder for your role or for roles that you are responsible for, I can recommend to spend some time reading and adopting a custom version of this for roles in your company.

Communication

We've set up Office Hours two times a week (spanning three continents) to have a place that everyone at Postman is able to ask questions and find information other than on a Slack channel (we have that, too). We're announcing these Office Hours regularly so people would be able to find us even if they hadn't heard about the OTPO before.
There's also a comprehensive overview of the scope of the OTPO on our company knowledge base (Confluence wiki), where you'd not only find the OTPO's current projects (like the career ladder or the Open Source Policy), but also details on who we are, where to find us and what our scope of work and level of influence is.

Building the Team

Reach out to me if you are interested in becoming an essential part of our Program Office. We're building a diverse team consisting of

a Technical Program Manager
a Technical Community Manager
a Technical Writer / Technical Editor
a Developer Relations Engineer

I'll be linking the job descriptions once they are online, but until that, feel free to reach out to me here or on Mastodon, LinkedIn. Or even Twitter if you must.

There'll be more parts to this series soon. It's a documentary of what we're building, and it's a long way ahead.

Stay safe.

Strengthening Collaboration - In A Box

Jan Schenk (he/him) — Wed, 07 Dec 2022 15:04:53 +0000

Context: This is a general guide written for the Open Tech team at Postman. In my role as OSPO (Open Source Program Office) Lead, I felt it could be helpful to my colleagues to hear and read what is appreciated at the company. While it's mostly very obvious stuff, it's stuff that we need to hear over and over again, myself included, to make them actually happen.

Being an island is great when it comes to defining your responsibilities. You can clearly see where your land ends, how far you can go, what you have and what you need to do to keep a grip of it all. It’s not so great when it comes to all the other things: infrastructure, resources, communication, trading, making friends, and learning. At Open Tech, we constantly strive to not work in isolation. The Open Tech philosophy is to overcome internal as well as external isolation, serve as an example and be a partner to those who seek to get out of their own isolation. Being truly open on everything that we do is core to everything that we do.

Our main strategy to work against silos?

🪄 Tell stories.

Your most impactful tool against isolation is storytelling. Your impact with collaborating with others will only be as good as the overall story is, that you are telling. Making storytelling an essential part of your work will help you enrich all the single actions listed below.

Don’t forget to make the collaboration a shareable story itself. Blog about it, record and publish meetings, share outcomes, code, screenshots, participate in public events, etc. Slice and dice it to as many shareable items as you can and tell that story.

Actions To Consider

Here’s a list of recommended actions and a brief description that should help you decide if this action is for you. Not all actions are applicable to all parties. Consider this a toolset where you choose which tools you want to use. If you are part of Open Tech, you can consider these actions to be applicable to external collaboration just the same.

📆 Participate in other’s team meetings.

Showing presence in other teams is increasing your visibility and will raise awareness for your topic, as well as position you as an available partner when it comes to questions. Offer to join a next team meeting as a guest whenever you meet a person from a team you’re not yet in contact with. Have a standard deck (max. 3 slides) or demo, that you can present. Keep below 10 minutes when introducing your topic and yourself, so you don’t dominate that meeting. And think about the story you want to tell. Ahead of the meeting, get in touch with the team lead of that team (often the people manager, the product owner, or the spokesperson of that team. Doesn’t necessarily have to be the person highest in the org.) if this isn't the person that you asked for an invitation or invited you.

🕙 Offer Office Hours.

Offering Office Hours can be scary when you start such a series of meetings. You don’t know who will show up, what questions will be asked and if you are satisfyingly prepared. It might need a little pushing yourself to make the first few iterations happen. And that’s ok, because here’s the deal: people join your Office Hours to have a chat and learn things, or just because they want to meet with folks they don't know yet. They are not coming to make you fail. Not knowing things is totally fine. You can always say “I don't know.”. If you’re like me, you then are triggered to find out the answer. And that helps two persons grow (if you let them know), instead of only one.

Office Hours can be internal only or hybrid (external and internal attendees). Make sure you let people know about the nature of the meeting. If you already offer external Office Hours, then promote them internally.

Office Hours can be set up to happen weekly, twice a week (if you want to offer different time zone options), or bi-weekly (UK: fortnightly), even once a month is ok. There’s always less people showing up than you would expect initially. Internally announce them on #lounge and other channels (#open, your own channels, ) with people you assume could be interested in joining.

🕐 Participate in other teams' Office Hours.

Make it a habit to randomly visit other teams' Office Hours. See it like taking a stroll in the city, where you discover new shops or diners, where you haven’t been before. It’s not always enough time for a stroll. “Occasionally” is a good start.

📝 Issue reports and distribute them.

Reports serve various purposes. 1) They aggregate things you’re working on and help you prioritize. 2) They show your impact. 3) They promote your work as they will be shared by others. 4) They keep track of what happened.

Depending on what you want to focus on, your way of writing these reports (and distribute and promote them, too!) will differ. As we want to increase collaboration opportunities, let’s focus on enabling sharing and re-sharing these reports.

A good minimal approach is to provide the 3 or 5 core things you’ve been working on during the last 7 or 14 days. Write a bullet list, provide links to internal or external resources. Actively ask people to reach out with ideas, questions or contributions. Encourage them to forward to other people potentially interested. Few will do, but if they are, they are all in and collaboration opportunities are likely.

Ideally, reports are following your overall story.

🔗 Find counterparts and connect.

You’re not looking for a twin role in another org. Who you want to find is the person that is similarly responsible for your tech, but from a different approach. Take gRPC: there’s someone in Product or Labs that is working on making things happen with gRPC. They have different stakes, but learning about them will be beneficial to your job as a link to you will be to them.

Then there might not be a counterpart, too. That’s ok, you’re cutting edge. Be ready to contribute and advise once the company is ready to get into action.

👯‍♂️ Find twins and connect.

There may be someone or more than one person with the same role for a different tech on your team. “Hey, this is not cross-team collaboration!” you say? True, but they might have a different view angle, tried out things, found some working and others not just as you did. You can learn form each other. You could have a buddy relationship, or a mentor-mentee thing that you agree on. Make it a habit to exchange on ideas around cross-team collaboration, join each others Office Hours and Slack channels. This is a gold mine.

🧑‍🤝‍🧑 Find partners and connect.

Regularly invite people to connect with you on your tech topic. Being an advocate for your tech is obvious, still often a left out opportunity. We’re a fast growing company, new people join every month, sometimes every week. Shouting into #lounge is only as far reaching as the list of our current employees. What about the ones that join tomorrow, or next month? Don't assume people will tell new colleagues about what you do. This is your own duty. Actively seeking for people who are interested in your tech and inviting them to your central communication hub (e.g. your Slack channel, our’s is #open) will be the beginning for sustainable connections.

Share work with your partners. Get them involved and let them take responsibility in your shared interest. This will grow trust and make them feel valued. We’re in a business environment and you can assume dependability until proven otherwise.

👑 Be a leader.

Opposite to a widespread assumption, not all people want to be leaders ([1][2][3]). Leading is stressful, taxing and time consuming. And while some people may say they would like to lead, they’ll sometimes still hesitate to do so. Their society-trained expectation from themselves differs from what they actually feel comfortable doing.

Leaders are storytellers. People will listen to and follow those, that share a conclusive authentic story.

TL;DR when it comes to your technology, be the internal leader. Others will not easily step up to do so.

🤓 Learn from others.

This is a basic. Always be learning. Even if you are the most knowledgeable person regarding your technology, you will still get plenty of opportunities to learn from collaborating with others across the company. I wanted to spare on this point, but it’s so essential we easily forget about it.

🔐 Be a mentor. And a mentee. And a sponsor.

Similar to “Learn from others”, as to creating learning opportunities and use them. But this is a pledge to actively support others and not be afraid to also claim this support from others. Having internal mentors and mentees opens up opportunities for collaboration. And you don’t have to be afraid to use these business opportunities. Of course you’re biased towards that person when you are a mentor or a mentee. That’s ok. In a conceptual interpretation, that’s what sponsorships are made of. A sponsor is a mentor who goes from silently supporting someone’s personal growth to actively supporting that person in their business. If done with support for marginalized groups in mind, it is highly appreciated.

💛 Assume good intent.

Cultural differences, use of language, personal experience (and maybe trauma) and a number of other factors influence our behavior and can make it difficult for others to understand what we actually want to express. This often is true for all parties, so the difference between what is being said and what is being heard can be off by a magnitude. This document is probably a good example of good intention, but poor execution in terms of language-correct tone and phrasing. When you assume good intent, you help bridge this gap between cultures, language proficiency, trauma or previous experience and all the other things, that make us act off the norm. You should also be able to expect that others assume good intent in your actions.

🏃 Be perseverant.

To keep your nose on the grindstone doesn’t sound too tempting? It’s what will lead to success finally, though. I’m not saying we shouldn’t re-calibrate what we have as goals, but working with others, especially when it comes to silos, is something that needs more than one attempt. When we are used to act in our silos, and it’s a learned behavior, then it’s hard and harder to let go of these patterns. We need to poke more than one hole into these silos, over and over again. It’s demanding, no doubt. But reality is, there is no easy way of breaking up with learnt patterns. And this is not necessarily you, it’s also everyone else.

👽 Have 1:1s outside your team.

Similar direction as the “Find a partner and connect”, but more explorative. Connecting with people outside of your circle helps you extend this circle. Try to connect with people that are different to you. Role, gender identity, culture, age, etc. Seek out diversity. It helps overcome sameness barriers, that we are often blind to. And it trains you to be better at collaboration in general.

🐙 Advocate for openness.

Talk to others about joining the breaking up of silos. Direct them to this document. Offer support when talking to others about the benefits of an open work culture. Breaking up silos and ending living on islands needs active supporters like you.

This is the common story for everyone across Open Tech. We’re open. We share our knowledge.

How Postman's Building Their Open Source Program Office (OSPO)

Jan Schenk (he/him) — Thu, 24 Nov 2022 10:54:30 +0000

This is not your classic "How We've Done That Thing" post on Dev. It's not a best practice, nor a step-by-step guide to building a Program Office. It's a in-progress documentary of a company's (Postman) and an individual's (me) efforts to create a meaningful structure within a well-developed start-up: A support program for Open Source, or, an Open Source Program Office (OSPO). Although we don't call it that. Yet.

In-progress means, we're still at it. As of November 2022, we've defined an initial structure and responsibilities for our OSPO, or, how we prefer to call it for now, OTPO. OTPO stands for Open Technologies Program Office, and the name is declaratory for its current responsibilities limited to the scope of the Open Technologies department.

Where It Started

We were not starting from scratch, either. When I joined Postman in October 2021, there already was Open Technologies. And Open Technologies did a lot of the things that you'd see an OSPO doing.
I joined in Developer Relations, an adjacent department, that reported directly to Postman's CEO, Abhinav Asthana, and so did Open Technologies. Kin Lane, Chief Evangelist and Open Technologies Lead, together with others already done a good job of inviting maintainers and contributors from API Specifications Open Source projects into Open Technologies, and into joining Postman. That meant that there was already a business priority to support Open Source projects that mattered to Postman today or would do so in the future.
(As a side note and for the sake of completeness: Open Technologies now reports to the CTO, and Developer Relations reports to Open Technologies after the latest re-org.)

Assessing the Status Quo

So there was already a department hosting Open Source projects, but it lacked structure and people willing to cover the organisational matters of running an effective Open Source approach. It lacked a team taking care of the needs of Open Source projects within a company, and taking care of Open Source in general. The highly respected folks in Open Technologies did what they loved most and what they were hired for: maintaining their projects and contributing to the codebase and the community.

Pitching a better concept

I'm coming from Program Management in DevRel organisations. Providing structure to create something more easily, reducing barriers and removing uncertainties, helping people find supporters to create together and thus build their business inside a business is what I did for the last 10 years. And I saw the potential in Open Technologies, the raw beauty, the support from leadership to invest in the company's future. And I saw that it would need three things:

Structure, Business Support and Empowerment

That's when I pitched the concept of a small team inside Open Technologies and the idea of shared resources to Kin Lane end of September. That's what he said:

That's very much on point. Build it.

What is an OSPO

I hadn't had an OSPO blueprint in mind when I pitched the Program Office concept to Kin Lane. Or maybe I had, but underestimated the scope of a full-fledged OSPO. But yeah, after reading more and getting great introductory resources through the TODO Group, I realised that this is exactly what I want to build. Not only for the projects in Open Technologies, but for the whole company. Delusions of Grandeur? Maybe. Or maybe an opportunity to build something that's very much needed in a company that is still growing at a massive speed and benefits from more structure.

This mindmap gives a great overview on responsibilities of an Open Source Program Office.

Proofing the Concept

Nobody's buying a pig in a poke, they say. We are two months into the creation of the OTPO, and nobody asked me for results yet. I'm working my way to showing impact, helping make meaningful connections within the company (e.g. between Product Managers and API Specifications Leads), write and develop guides and how-tos to make it easier and remove barriers for employees to contribute to Open Source projects or opensourcing their own projects that save others tons of work. I'm holding Office Hours twice a week to give people orientation and a safe harbor for their questions. I'm having great discussions. But I realise that at this stage, it will take more than just me to create a Program Office that has an impact. And it was part of the pitch to have a Program Manager, a Community Manager, a Writer and Editor, and Engineers join the efforts. And that's where we are at them moment, we're hiring.

Building the Team

Reach out to me if you are interested in building the OTPO, and paving the path to becoming Postman's OSPO in the next 12 months. We're looking for a diverse team consisting of

a Technical Program Manager
a Technical Community Manager
a Technical Writer / Technical Editor
a Developer Relations Engineer

I'll be linking the job descriptions once they are online, but until that, feel free to reach out to me here or on Mastodon, LinkedIn, or even Twitter if you must.

There'll be more parts to this series soon. It's a documentary of what we're building, and it's a long way ahead.

Stay safe.

Announcing Postman v10: The API Platform for an API-First World

Jan Schenk (he/him) — Thu, 15 Sep 2022 12:00:00 +0000

This article was written by Ankit Sobti, CTO at Postman, and appeared first on the company blog.

Since the beginning of Postman, we have been obsessed with helping our users solve problems. And from our vantage point in the industry, we have seen the rise of API-first companies that use APIs as the building blocks of their software strategy. The transition from code-first to API-first is a significant technological shift. To succeed in this world, organizations need a system that integrates the different tools and processes to effectively build, manage, publish, and consume APIs. As a result, we’re seeing more and more legacy companies deconstructing their monoliths to become API-first.

Today, we are proud to announce that our vision—one built on the needs of an API-first organization—has come to life with the launch of the biggest and best version of Postman in our history: Postman v10! In some ways, it might look like this is one year’s worth of work as we released v9 this time last year, but in reality, v10 has been in the works for many years. With v10, we have made improvements to almost every part of the Postman API Platform.

There is lots to cover, so let’s jump right in and learn what makes Postman v10 so exciting.

Native Git support and the redesigned API Builder

After speaking with hundreds of teams to understand their API development workflows better, we introduced the API Builder in Postman v9 as a way of helping teams organize this workflow and have clear checkpoints in the development process. Then we learned from customers that the feature was complex to set up and get started. A lot of teams didn’t have API schemas to start defining their API, especially when dealing with REST APIs.

Here are four huge ways Postman v10’s new API Builder simplifies these workflows:

Postman’s API Builder now integrates natively with Git. This means that you can keep and version collections and schemas next to your codebase and work on them using your team’s pre-existing collaborative version control workflows.
We significantly redesigned the UI around the API lifecycle. These features are now available in a section on the sidebar to allow for a cleaner experience. We see development teams work in a variety of ways, and realized that a guided experience would often just get in the way.
We have simplified the publishing step of creating a version where an API would go from development to consumers. Once development on a branch is complete and a branch is merged to your deployment branch, you can publish the collection and the schema as a new version in the API Builder. Once published, the API will be available for consumers. More on that below.
We also launched a new command-line interface today—Postman CLI. Postman CLI is built atop the foundation we laid with our open-source CLI, Newman. It runs collections using the same runtime as Postman, while deeply integrating with the Postman API Platform. Postman CLI simplifies integrating with your CI system and autogenerates the pipeline code needed for you to integrate your collections and schemas with your CI process.

This tight integration means that you can now see test reports inside Postman workspaces. You can review these reports together as a team and see where your attention needs to be directed.

gRPC support and Postman’s continued expansion into being the single platform for all APIs

For today’s development needs, there are a variety of API technologies available. Postman had its origins in HTTP/REST but we soon learned that the API lifecycle is the same across any technology that is used for building APIs. However, developers suffer from a lack of tooling when a new innovation comes around in the API world. It often takes a decade for tooling to mature. Our vision is for developers not to have to make these trade-offs. Over the last few years, we have added support for SOAP, WebSockets, and GraphQL.

With gRPC emerging as the winning standard for internal microservice communication, we are thrilled to announce that gRPC support within Postman is now fully available with the launch of v10, introducing support for Protobuf definitions, autocomplete hints, tools for documentation, scripting, testing, mocking, and collaboration within Postman workspaces.

Better discovery for internal APIs through the redesigned Private API Network

We’ve been making significant improvements to how organizations discover APIs. A robust set of APIs, built alongside an effective API-first strategy, can create huge benefits. They open up existing capabilities of an organization for reuse by internal teams and reduce the time and resources needed to develop new features for users and customers.

However, private APIs only bring these benefits if they can be discovered by others easily. With the increasing number of private APIs within organizations, it becomes difficult for consumers to find the API they are looking for—leading many teams to invest time and resources in building duplicate functionality.

Today, we’re excited to announce the redesigned Private API Network to address these pain points by helping developers discover relevant APIs faster. The Private API Network provides a central directory of all internal APIs in your organization. Teams will be able to publish workspaces and collections along with APIs built in the API Builder. The publishing flow has been updated to allow for an easy workflow for publishers. The interface also makes it easier for consumers to fork collections and use them in their own workspaces.

Collaborate with your partners through Partner Workspaces

The Postman Public API Network has become the largest hub for APIs on the planet. Companies of all shapes and sizes including the likes of Salesforce, Microsoft, Stripe, and thousands of others are sharing their APIs through public workspaces on the API Network. Public workspaces reduce the time to first call for an API and make it really easy for publishers and consumers to stay in sync as APIs change over time.

However, not all of your APIs might be publicly available. Most organizations have partner APIs—APIs that are accessible to a cohort of select partners due to business, regulatory, or product-related decisions. Collaborating on these APIs has always been difficult. Customers that we spoke to often mentioned slow email-driven processes through which API artifacts including Postman Collections were shared. It was difficult to keep everyone up to date on both partnerships and co-development projects, where a company might contract out work for others to get done.

In v10, we are introducing Partner Workspaces, which provide a shared, secure, access-controlled space where organizations can invite partners to collaborate and build APIs. Users inside the workspace can have Editor or Viewer roles so they can access resources appropriately. Partner Workspaces complete the picture of collaboration that we envisioned. Check out this article on all the different ways you can use workspaces.

Standardize governance and security practices throughout your organization

As APIs proliferate across an organization, it becomes critical that they are built in a standardized way and governed for consistency, as well as regulatory and compliance reasons. As we spoke to customers, the security and governance of APIs continues to be a top-of-mind concern for senior leaders and executives. With Postman v10, we are very excited about launching a new suite of capabilities aimed at helping organizations scale their best practices toward building APIs.

API Security

Requests that you send in Postman now have built-in security validations. Postman will automatically check the API against common vulnerabilities and alert you if there is something wrong. API Security validations are also baked into the Postman API schema editor for the OpenAPI standard. These rules can be customized by security teams and make it easier for developers to discover organizational policies and remove security vulnerabilities at development time.

API Governance

Our new API Governance features will allow you to deploy a company-wide style guide for your APIs. This feature is powered through a customizable linting engine that consists of the most widely adopted open-source community standards with the ability to add your own organization’s rules. These rules will be used to scan your OpenAPI files inside the API editor and also integrated through Postman CLI and in your CI/CD pipelines.

For a high-level overview of your API landscape, you will be able to see reports for your API landscape in the updated Reporting section. Once you start adding APIs, you will be able to track compliance over time and make sure that your organization is producing high-quality APIs.

Get started now

Postman v10 is our biggest leap yet regarding integrated functionality for the entire API lifecycle. All these changes are available as part of our refreshed plans, starting today. If you’re an existing Postman customer, you will continue to enjoy the benefits of features that you had at the time you started your plan. We’ve built v10 to benefit workflows for developers and for the entire organization—and while we have shipped these new features, the Postman engineering team remains continually focused on improving performance and the quality of the entire platform.

We believe you’ll love these capabilities that we’ve added to Postman. Today, we’ve started rolling out Postman v10 to the thousands of companies who’ve already joined our v10 waitlist. You can also join the early access waitlist here.

If you want to learn more about anything in Postman v10 and how we can help you adopt Postman Enterprise, talk to our sales team today.

The post Announcing Postman v10: The API Platform for an API-First World appeared first on Postman Blog.