I usually learn from my mistakes, but I additionally want to look at my successful attempts because we can also improve our lives when we repeat things that work. In the past, I made small advancements in the team to help me learn different disciplines and improve my communication. Today, I want to talk about one of them.
In a leader's life, you need to constantly look for ways to improve team collaboration, competency, and project workflow while expanding your knowledge to understand different aspects of the job: product management, design, quality assurance, infrastructure, user interface development, and more. The best way to gain enough knowledge in these topics is using the advantage of working in a team: collaborating with experts. Although the best way to learn anything well is doing it by yourself, there are people around you who can give you a hand when you ask.
I learned how other disciplines work through asking people a few, sometimes more than a few, questions about their fields. For me, the main goal was learning how people in different disciplines approach the problem. Eventually, we are solving the same problem in different ways.
One day with that goal in mind, I approached our designer with a proposal. I struggled with understanding the design of the feature I was developing in an iOS application. How the user interface design was solving the problem wasn't clear to me. In these cases, I try to question the solution with curiosity. I'm not good at design, but I know how the implementation will be, and I knew many other apps, which solved a similar problem, approached the solution. After a while, I realized I was missing a perspective. I approached our designer and proposed to pair on designs.
The designer walked me through the design and explained their approach. I asked many questions, and surprisingly, so did they! It turned out that two brains together were better than one. We both knew mobile apps, but we only knew them from our perspective. In the end, we gained new ways of thinking, improved user experience, and made the implementation simpler. Not only that, we immensely reduced the time we were about to spend on the whole feature. So, win-win-win.
We liked the pairing approach so much in the team. Later on, we paired on user interface bugs and polished the app together without going back and forth between designer and developer. It was a fantastic experience.
Extract what you already have!
These kinds of pairing sessions are not new to the software engineering world. There are common pair programming formats, such as driver-navigator, ping-pong coding, and more. Extracting these collaboration strategies and applying them to a different context bring immense benefits.
Additionally, using the tools in your tool belt in different areas has multiple benefits. First, you learn other disciplines, which will help you a lot when you're a leader, and second, the other people learn from you, and last, these techniques increase team collaboration, which will be your job as a leader. Taking an extra step and initiating new strategies in your team will make you stand out.
Here is my practical advice for this week: Look at your existing operation in your engineering shell and search for the systems or processes that help you do your job better. Next, imagine having a similar approach with other disciplines. How would it look? Try to tweak some parts to adapt them to your situation. Offer it to your colleagues and ask for their opinions. If people oppose, take the feedback and improve your plan until you offer an acceptable strategy. Don't make it perfect; take action and improve your plan on the way.
These initiatives will help you improve communication with non-technical people, challenge your technical knowledge, and nudge you to research more. You're not alone in your career, so ask people around you for help.
How would you rate this week's newsletter? 🤔
What I Published Over Last Two Weeks
I published one article and a podcast episode.
Recently, I became the book supplier for my father. Choosing books for someone else is a powerful position, and I take it seriously and feel responsible.
Roberto and I talked about distributed systems, the CAP theorem, writing a book, and growing a career in software engineering. Listen to the new episode of Software World to learn more.
If you find these letters valuable, consider sharing it with friends, colleagues, or work friends!