Considering a Non-Technical Role? Think about these 6 Things

Almost three years ago, after spending 13 years as a software developer, I took on the role of Delivery Lead here at Atomic. It was a step away from code and toward all things related to project delivery: project management, backlog management, reviewing completed work, managing the team’s Scrum process, etc. It was a move I was excited to make.

Now, I’m transitioning back to a developer role. Taking on that non-technical role was a good decision for me, and I’m glad I did it. However, I feel like a more technical role is a better fit for me. I’ve learned a lot over the course of these role transitions that I’d like to share with others who may be looking at similar transitions.

1. It doesn’t have to be a permanent change.

This may depend on your organization, but for me at Atomic, I knew there would always be a way to transition back to a development role. Transitions require patience and flexibility—they need to align with the organization’s needs, as well as your own. For my situation, that means probably six months wrapping up my current project as a Delivery Lead.

Caveat: One common aspect of the technical-to-non-technical transition that I’m glad I didn’t have to worry about was the idea of promotion. Moving up the pay scale and/or the organization’s chart ladder can make it tempting to pursue or remain in a role where you’re not content.

I can’t provide experience-based advice for that specific situation, but I’ve found it helpful to have frank, open conversations to explore what options might be available. I’ve been impressed with the resourcefulness and flexibility of even large organizations when the right people get involved.

2. You won’t lose your technical skills overnight.

During my three years away from daily development, there were many shifts in preferred tools–but nothing I can’t pick up given a little time. Even if I had been doing development, I’d still have new tools to learn because the landscape is constantly changing. That’s just part of the development career (especially at a consultancy with changing projects and clients).

In other areas, no catch-up is required. I’ll still be able to provide immediate value at a conceptual and architectural level, even if I’m not quite as efficient at writing out the specific lines of code to make React, Redux, and GraphQL work together to meet our goals.

In fairness, even while I was in my other role, I didn’t leave coding behind. I wrote some for fun: a C++ / SDL cellular automata game, an Othello AI in Rust, some C/C++ for an Arduino and LEDs, a JavaScript utility or two, etc. It’s fun; I can’t help myself. ;)

3. Consider the big picture.

What work do you ultimately want to be doing? Does this new role let you do that work or get you closer to that work somehow?

I was thinking in terms of decades when considering my role changes—what do I want to be doing for the next 10 years? Keeping that sort of long-term timeframe in mind helps evaluate whether a transition is a good fit and keeps short-term pains in perspective during transitions.

4. There is value in cross-training.

Even if you transition back to a developer role, there is value in what you learn working in a non-technical role. For me, there were a few primary drivers of learning:

  • Professional development targeting non-technical domains. I participated in a series of workshops focused on interpersonal, leadership, and self-management skills and became a Certified Scrum Product Owner. Those opportunities were very different from what I considered when working in a developer role.
  • Frequent meetings with the other Delivery Leads where we helped each other with issues we were facing and shared what we were learning.
  • Working day-to-day in the role. Every day involved figuring it out and providing value to my teams.

Having those experiences as a Delivery Lead gives me more empathy with others working in similar roles and more flexibility with how I can provide value to my teams. For example, it would be great to assign me to a team with a new Delivery Lead because I could help them get up to speed and serve as an experienced backup.

5. Stick with it for a while.

It takes time to get comfortable with a new role and become effective. It took me a good few months to find a happy balance of responsibilities and participation with my teams because the role was new to both the teams and to me. Our regular Delivery Lead team meetings helped a lot with figuring that out.

Fortunately, I was already familiar with the work itself since I had already managed several projects at Atomic as a team lead and developer. I expect it could take quite a bit longer if everything were new. The takeaway is, don’t get discouraged if you feel less effective and out of sorts for a while. Find or create ways to get support, and keep at it.

6. In any role, be yourself.

Everyone has different skills and experiences that color the way they execute their role. Certainly, there are some basic expectations and responsibilities for the role that you’ll need to complete, but also think about who you want to be in that role. How do you want your strengths and experience to manifest? Where will you lean more on others or your team?

For example, when I was a Delivery Lead, my technical background helped me provide quick feedback on the complexity of new feature ideas or issues when the dev team wassn’t in the room. It allowed me to dig into an old software product’s source code to help identify requirements, and it let me provide input on some technical discussions with the development team. I also liked to visualize data rather than leave it in a table, so customers I work with are likely to get more charts and diagrams. Not all Delivery Leads at Atomic do those same things.

In conclusion, I hope you find these considerations helpful. Whatever you decide, learn continuously and work hard to be the best version of yourself in the role you choose.