{"id":18570,"date":"2025-09-30T15:28:09","date_gmt":"2025-09-30T12:28:09","guid":{"rendered":"https:\/\/railsware.com\/blog\/?p=18570"},"modified":"2025-09-30T15:28:10","modified_gmt":"2025-09-30T12:28:10","slug":"coffeewithrw-how-to-stay-t-shaped-even-in-a-highly-technical-role","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/coffeewithrw-how-to-stay-t-shaped-even-in-a-highly-technical-role\/","title":{"rendered":"#CoffeeWithRW: How to Stay T-Shaped Even in a Highly Technical Role"},"content":{"rendered":"\n

The concept of being T-shaped<\/a> \u2014 combining deep expertise with a broader understanding of surrounding areas \u2014 is familiar to many of us. However, as roles and teams evolve, it\u2019s easy to lose sight of this balance. Sometimes, in an effort to cover every possible expectation, specialists end up spreading themselves too thin, rather than growing in ways that truly add value.<\/p>\n\n\n\n

That\u2019s why in this Career Growth edition, our Information Security Manager, Oleg Bida, reflects on what it really means to stay T-shaped. His focus is not on collecting more skills for the CV, but on building depth and context: the ability to connect the dots, collaborate more effectively, and make stronger decisions.<\/p>\n\n\n\n

At first glance, information security may appear to be one of the most rigid and highly technical roles available. Yet Oleg shows that even here, you can master T-shapedness  in unexpected ways(and he has the stories and lessons to prove it, so keep reading!)<\/p>\n\n\n\n

So, let\u2019s pass the floor to Oleg.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Wearing multiple hats = T-Shape journey?<\/h2>\n\n\n\n

On paper, my job as an Information Security (or InfoSec) Manager is pretty straightforward: protect data and systems, spot risks, set policies, handle compliance, and respond to incidents. However, in practice, my path has been anything but \u201ctypical\u201d for InfoSec.<\/p>\n\n\n\n

From the very beginning, my work has stretched beyond the narrow definition of \u201csecurity.\u201d In fact, I stumbled into the idea of breadth plus depth long before I knew there was a name for it. Back then, we just called it being a swiss army knife \u2014 someone who could wear many hats and make things happen.<\/p>\n\n\n\n

University was my first real testing ground. Textbook knowledge could get you through exams, but it wasn\u2019t enough for group projects. They fell apart unless someone could bridge the gaps between disciplines. That realization pushed me to explore more than just my major. I dove into privacy law, networking, even a bit of project coordination \u2014 anything that helped me connect the dots and keep projects moving.<\/p>\n\n\n\n

My first job at the regional government office in Lviv, Ukraine,only reinforced this lesson. Officially, I worked for the Department of Education. In reality, I was doing a little bit of everything: troubleshooting, network administration, some development, but also budgeting, drafting contracts, and managing vendors. If something needed to get done, you rolled up your sleeves and figured it out. By the time I became Head of IT there, wearing multiple hats had become my second nature.<\/p>\n\n\n\n

Still, I felt a pull toward one area in particular. The turning point came with my first serious incident response \u2014 a single vulnerability that rippled through and disrupted an entire organization. Watching that unfold convinced me that security wasn\u2019t just another \u201chat\u201d I wore. It was the field where I wanted to go deep. And that\u2019s when my T-shape truly started to take form.<\/p>\n\n\n\n

How to develop \u201cdeep\u201d skills<\/h2>\n\n\n\n

The first \u201cvertical\u201d I really mastered was troubleshooting \u2014 figuring out why something was broken and, more importantly, how to fix it. Honestly, it all started by just being that person who could reinstall Windows or set up a dual-boot Linux system \ud83d\ude42 <\/p>\n\n\n\n

Back in the mid-to-late 2000s, networks and computers weren\u2019t as stable as they are today, so hands-on experience was everywhere. I tackled everything from printers refusing to communicate to networks of a hundred machines grinding to a halt because of overzealous file sharing, or Windows freezing after a driver update going wrong. And then there were the classic security pitfalls \u2014 weak default passwords, open network shares \u2014 relics of a bygone era in cybersecurity, now practically museum pieces.<\/p>\n\n\n\n

\n
\n

These challenges gave me technical depth, but more importantly, they sparked a curiosity to dig into root causes \u2014 the same curiosity that eventually drew me toward information security.<\/p>\n <\/div>\n

\n
\n \n \n <\/div>\n <\/div>\n<\/section>\n\n\n

Yet in InfoSec, there\u2019s no point where you can say, \u201cOk, now I\u2019m finally here.\u201d. The field moves so fast that some things I learned at university became obsolete in mere years. True depth doesn\u2019t come from knowing everything\u2013 it comes from experience, from facing enough situations that you stop panicking when an answer isn\u2019t immediately obvious.<\/p>\n\n\n\n

\n
\n

That\u2019s why, for me, real depth means having the confidence and the process to figure things out, and knowing exactly where to look for answers.<\/p>\n <\/div>\n

\n
\n \n \n <\/div>\n <\/div>\n<\/section>\n\n\n

How to improve the breadth of skills<\/h2>\n\n\n\n

While deep technical skills gave me a foundation, I quickly realized that becoming T-shaped meant exploring areas beyond core information security. So I started digging into: <\/p>\n\n\n\n

    \n
  1. Security-adjacent disciplines: privacy regulations and data protection laws\u2014learning how different countries handle information, what\u2019s required for managing personal data, and the right ways to work with it.<\/li>\n\n\n\n
  2. Broader professional skills: communicating clearly, planning effectively, raising concerns constructively, doing independent research, working autonomously when needed, and collaborating well across teams.<\/li>\n\n\n\n
  3. Cross-domain technical awareness: networking, systems administration, troubleshooting, and light development\u2014skills that help me collaborate with technical teams and understand the environments I\u2019m securing.<\/li>\n\n\n\n
  4. Curiosity, because it keeps me reading industry news, following CERT feeds, and subscribing to newsletters. This includes also the basics, such as programming, libraries, tools, development methodologies, and efficient Googling (and now, of course, prompting AI).<\/li>\n<\/ol>\n\n\n\n

    Over time, I realized that broadening my knowledge was essential. Even learning to navigate bureaucracy helped me stay organized and keep processes moving smoothly. And curiosity made it enjoyable\u2014I genuinely like seeing how all the pieces fit together.<\/p>\n\n\n\n

    How to approach learning as a T-shaped specialist<\/h2>\n\n\n\n

    Stepping into a field you\u2019re not specialized in can feel intimidating at first. Over the years, I\u2019ve found two approaches that make learning new things stick \u2014 and actually enjoyable:<\/p>\n\n\n\n

    1. Master the basics before layering knowledge<\/h3>\n\n\n\n

    Whenever I explore something new, I start with the fundamentals. I literally go back to proper definitions and concepts. For example, in security, understanding the difference between an \u201cevent\u201d and an \u201cincident\u201d is crucial\u2014without that, nothing else makes sense. Once I\u2019ve got the foundation, I gradually layer on more context and real-world applications. <\/p>\n\n\n\n

    I use a mix of resources. Interested in quantum mechanics? There\u2019s a Coursera<\/a> course for that. Want to crochet a scarf? Udemy\u2019s<\/a> got you covered. Need a quick tip on a niche skill? There\u2019s probably a YouTube video that explains it better than a textbook.<\/p>\n\n\n\n

    Yet, the key is combining theory with hands-on practice: experimenting, making mistakes, and learning from them. <\/p>\n\n\n\n

    2. Ask questions and connect perspectives<\/h3>\n\n\n\n

    After grasping the basics, I actively seek out people who work with the topic every day. Most are happy to share insights, correct misconceptions, and show how things work in practice. These conversations often spark cross-team discussions: \u201cHey, marketing and security \u2014 what features create risks, and how can we improve?\u201d <\/p>\n\n\n\n

    By examining a problem from multiple angles, I not only learn more effectively, but I also understand how to create solutions that work both technically and practically for everyone involved. <\/p>\n\n\n\n

    How to approach learning as a T-shaped Tech specialist<\/h2>\n\n\n\n

    These tips might sound niche, but they\u2019re useful for anyone looking to grow in IT security (or really, any technical role).<\/p>\n\n\n\n

    1. Communicate and influence effectively<\/h3>\n\n\n\n

    Storytelling is huge. Being able to explain technical risks in a way non-technical people understand and actually care about \u2014 makes a massive difference. You also need negotiation skills because security often requires changes that affect others\u2019 workflows. Finding common ground and showing the \u201cwhy\u201d behind your requests makes adoption much easier.<\/p>\n\n\n\n

    2. Observe, adapt, and improvise<\/h3>\n\n\n\n

    Pay attention to how people and processes work in practice, not just how they\u2019re written in policies. Combine that with a touch of improvisation, because incidents rarely follow the playbook exactly. Understanding the real context lets you offer practical solutions that actually work.<\/p>\n\n\n\n

    For example, if I say, \u201cWe need to implement X,\u201d I can face resistance. Yet, if I frame it through another team\u2019s reality (like noticing how the support team handles incoming content that makes them vulnerable to targeted malware), I can explain that implementing X will protect them and the company as a whole. That perspective strengthens the case and builds cross-team understanding and buy-in.<\/p>\n\n\n\n

    Final advice: Keep learning, but don\u2019t stick to textbook definitions only. Always ask yourself how a concept applies in reality. Security needs vary. For instance, an open-source community project has different risks than a FinTech startup. Explore those differences, expand your context, and never lose your curiosity. That curiosity is what drives true growth.<\/p>\n\n\n\n

    Common mistakes <\/h2>\n\n\n\n

    When you\u2019re committed to becoming T-shaped, there are pitfalls to watch for. Here\u2019s what I\u2019ve learned over the years:<\/p>\n\n\n\n

    1. Keep your learning connected to your core role<\/h3>\n\n\n\n

    It\u2019s tempting to dive into anything that looks interesting, but time is limited. I focus on learning enough to collaborate effectively, not to fully replicate another team\u2019s role. <\/p>\n\n\n\n

    For example, if I need something niche from DevOps, it\u2019s usually faster and more productive to ask them directly by explaining why I need it rather than spending weeks mastering a process I\u2019ll rarely use. This way, I maintain depth in my own area while still expanding my understanding of related fields.<\/p>\n\n\n\n

    2. Prioritize relevance and frequency<\/h3>\n\n\n\n

    Before investing time in a new skill or procedure, I ask myself: how often will I actually use this? If it\u2019s something you might only need once a year, it\u2019s smarter to get help from the team that already does it. Being strategic about where you spend your learning energy prevents wasted effort and keeps your skills practical.<\/p>\n\n\n\n

    Tips: <\/p>\n\n\n\n