I almost missed a point of reaching a three-year tier in my product manager career, which nearly matches with ten years in IT. I wrote essays about my previous years (year one, year two, combined article on Medium) as a retrospective of my thoughts and feelings.
I had doubts about whether I wanted to write the continuation. I re-read previous pieces, which made me realize I needed to continue. First, the "Sophomore Year" was quite depressing. Second, I need to finish the series, and having that as a trilogy sounds right.
I don't say it will be optimistic than a previous one. A bit brighter, maybe. And most probably, the last. Writing that in a third time felt more like an obligation.
Anyway, it is time for a retrospective of my 3rd year of being in product management.
Last year, I had an identity crisis because my job seemed to be far away from what is written on product management. It coincides with general terms, but the devil is always in details.
Then, I realized that platform engineering and product managers who are working on Internal Development Platforms (IDP). There is a community, books, webinars, courses, and tools around that. Many people are doing similar things I am trying to do and have similar problems.
Here is my writing routine: the way how I structure my research on various topics and then write an article.
It is not my usual type of content, but it might be helpful to someone. And yes, I need to fill the vacuum while working on two new writing pieces: a book review and a new topic.
I use Obsidian as a knowledge base and content management. It is free, keeps your data in your hands, not in a vendor cloud, uses Markdown for formatting, and has a variety of great plugins.
The latter is handy as my blog is also built with the MkDocs engine based on the Markdown format. So, I keep writing and editing in Markdown, which is very convenient. I don't particularly appreciate it when each tool tries to reinvent the wheel with its custom formatting, which is incompatible with anyone else. With Markdown files stored on my local machine and my cloud storage, I can quickly grab them and migrate them to another tool.
I use the Zettelkasten technique in Obsidian when I research something and need to document some information and my thoughts to reference it later. You can find a lot of information about this approach. I keep my notes connected with tags and internal references where possible. Obsidian provides a nice graph where I can filter out some notes and track references.
Once a year, I clean up by editing, merging, or even deleting some notes. So, I try to keep the number of my Markdown notes from spreading. You can see a part of the notes graph in the attached image below.
Last month, I started summarizing all my API-related posts, workshops, and webinars into extended and structured reading. That is usually a part of the Essays section, where you can find my recent Replacing Legacy series.
Reflecting on my past materials about API, I realized they were disconnected and lacked a logical narrative. However, I am proud to share that I am starting anew, from simple concepts to in-depth reviews of various Interface Definition Languages, showing significant improvement in my approach.
The new chapter, "Analysis," focuses on business analysis and aspects of requirements engineering. That was tough to write and edit, cutting pieces that did not fit and made text difficult to comprehend. Hopefully, I will get a satisfactory result.
The following case study focuses on dependency management, omitting other details that are irrelevant to the topic or might be sensitive to share publicly.
I do not necessarily speak on my behalf. Let's assume some Product Owner (The PO) appeared in such a situation and acted a certain way to resolve the dependencies.
This is what the team topology looks like, approximately. And that impacted how dependencies are distributed.
Three organizations are involved, each with their own development teams and management. It is obvious that each side pursues its own goals in accordance with contractual obligations.
Recently, LinkedIn asked me to share my insights to be eligible for the "Top Voice" badge. I realized that I have something to share with my followers in a more extended way than typical (ChatGPT-generated) answers to those top-voice questions.
As usual, let's start with the definition, which is rather made on my own. When you need someone to do something so you can do your work, that is a dependency. Postponing the dependency means a delay in delivering your work and the expected outcome, which causes financial losses.
Your team/service can have one or several dependencies and be a dependency for someone else. Sometimes it can be both. And dependencies might be temporary when you need something to be done once or permanent when you continuously need something to operate.
There can be external dependencies, meaning that you are waiting for something to be done outside your organization. Or that will be done inside your organization, which is an internal dependency.
We can distinguish cross-team, cross-stream, and cross-department dependencies, each with its own peculiarities.
In my world, dependency means an API or a software library. In your world, that may be anything else, like a vehicle part or a plumber to fix a pipeline leak.
Although this resource might be for local business analysts in Warsaw, I am adding a product management and product ownership perspective.
So, if you happen to live in Warsaw, we would be glad to have you join one of our events. If not, enjoy this newsletter.
Also, I decided to postpone the idea of my newsletter. This commitment seems too heavy at the moment. I enjoy my current writing schedule of about two articles a month. I don't want it to become a job instead of joy.
Looking at the title, this book is not about product management or business analysis...
Yes, you are right. This book is about constructing teams and establishing their interactions. It is not about my day-to-day work, but it is an area of my concern. I tend to read general books about management more and more. So we will discuss more such books in the future.
How did you find out about "Team Topologies"?
I heard about it during the Platform Engineering fundamentals course brought by Tyk (I have a fancy certificate, by the way). There were a lot of references to that book, so I decided to add it to my reading list.
It is funny, but "Team Topology" references many other sources but combines them into a solid idea.
The book basically addresses the most common problem, probably on the humanity level.
What kind of problem do you mean? We have plenty of those.
I am proud to present the second edition of the monthly newsletter made by BArszawa - the Business Analysis community in Warsaw. In one of the previous posts, I explained what this community is and my role in it.
I act as an editor, combining some materials gathered by the Community OrgTeam, writing a foreword, and publishing on different media platforms.
Hoping you enjoy that post and find it helpful. Please feel free to share it with your friends and colleagues, support us, and visit us if you appear to be in Warsaw, Poland.
