Greg Thomas

Hello! What's your background and what do you do?

I am the Founder of BetaRover Inc, a cloud solution provider that helps customers onboard their organizations to the cloud. I lead a team of developers in delivering solutions on the Azure platform stack building services, databases and any other integrations they need to make the successful transition to the cloud.

I’ve worked at a variety of startups and large companies with roles ranging from Software Manager to Vice-President of R & D. I am a self-taught Software Developer with a sprinkling of certifications in there (mostly Microsoft). I fell in love with software development while pursuing my BCOM in Canada (Bachelors of Commerce). I decided to stay with my BCOM and learn software on the side consuming every book I could get my hands on. I’ve been developing software for over 20 years, no matter what role I hold, I’m always coding - I can’t get away from it.

My focus has been with enterprise software focused on service infrastructure - database, services, middleware, windows services, communication stacks. I’ve coded a number of applications around contact centres so I learned a lot about efficient use of TCP/IP programming, service uptime and keeping your services and packets small. It was by chance that I fell into this industry, but I learned so much about real-time efficiency, uptime, failover, scaling, performance - so many great lessons that I apply to what I’m doing today.

I consult with companies now on a variety of projects - right now I am working with one team as their Program Manager/Software Architect for delivery of a new platform to handle bank transactions on an Azure cloud platform. As Program Manager, I lead the development, QA and business analysts in the running of the project while interfacing with our internal users and external clients.

Today, much of my work is focused on Azure (database, services, AI, Functions, etc) and DevOps/Agile. Over the past few months, I’ve been looking to expand my language set by learning Node.js, React, TypeScript and Google Cloud (there’s always so much great stuff to learn and right now I’m learning these simply for enjoyment). I’ve always liked the idea of bringing what I learn in one language (say PHP) and concepts learned there into other languages (say C#).

How was your transition from software development to management like?

At the time, I was a Senior Developer focused primarily on writing code for our productized solutions but was also heading up a new group focused on professional services for our customers. The latter role gave me glimpses into leading projects and people as we delivered these custom solutions. In essence, I was a Senior Developer, with some added customer and project management duties. During my time in this role, I had been approached by the company a few times to make the leap to management and turned it down twice - I didn’t feel I was ready for it and had more to learn. I think this helped me because it made me think about the move, what I was missing and what I wanted to learn to get there. I was fortunate to be working for a fantastic startup that didn’t see this as a negative and instead wanted to provide me the support needed to make the leap. When I made the leap to being a Software Manager I had been with the company for two years in that Senior Developer role. When I became a manager, I was given the responsibility for a heavy research project where we scaled the team I was leading from 2 people to 10 over the course of a year.

Despite all my preparations, I was still woefully unprepared and had a lot of on the job training / mistakes to learn. There is all the management stuff that comes along with leading a team but really, it was the leadership piece that I had much to learn. I had made some good relations with people in the company so when it came to recruiting people to the project, I was able to invite some people to grow the team. We soon became the little team that was building the software for the next generation of the company; we were the startup within the startup.

What does your day-to-day work look like, and what motivates you to do it every day?

In general, if I can spend 2 - 3 hours of coding per day, that’s fantastic. Realistically, it is probably around 1 - 2. I spend a lot of time in meetings (especially these days) leading the team, meeting with developers individually and assisting with delivery planning for what we are working towards in the current/next sprints and how that contributes to the ultimate goal.

I work hard to make sure there is always time to sit down with the team and work through any issues that might arise that they might need help with. We’re pretty busy right now, but I’ve said a few times to the team that they are the first priority, before we release anything. As such, if they need me, we drop everything else.

People ship products, not process.

Sprint planning, scrums, stakeholder planning, gathering requirements, design meetings - you name it and I’m a part of it and probably running it. I like to step aside for the developer meetings and encourage the team to deliver and demo their work (code and design). I think this is a great exercise so they can grow these skills in a welcoming environment.

With all these meetings, I try to frontload my week with meetings (sometimes it works, sometimes it doesn’t), it really depends on what cycle of the sprint and release we are in. Right now we are in the middle of sprints and release planning so my calendar is a little more full than it has been compared to last month.

What are the biggest challenges you've faced so far? What did you do to overcome them?

Whether it's from when I first started as a Manager to my role now, the challenges I face always seem to be the same but in different contexts.

Balancing Coding and Leadership

Easily, this is the one I hear from other managers all the time. As Developers we invest so much time in becoming great leaders that when we make the switch, we worry about all the skills we are going to “lose”. I’ve always tried to keep coding when leading teams, primarily because it keeps me focused and gives me an outlet to solve a problem. Coding problems are generally easier to solve than people problems. I don’t work on all the mission critical features that I used to work on, I do more grunt work coding for where the team needs holes plugged that are holding them back.

Optics

I think another big challenge is how people view you. When I first started as a software manager I was a little worried about how people would view my approach, what we were doing, how I was doing, etc. I learned over time that the only people I should really care about what they think, are my team itself. When I made that internal mindshift, I stopped worrying about the optics and instead started focusing more on the team to ensure their needs were being taken care of.

What has been the biggest surprise so far? Something you didn't expect?

I’ve led a number of teams since my first Manager role and I remember transitioning from one team to the other where I tried to apply the same practices I did with the first team.

It failed.

Different people, products, processes, projects they all make up the context for which you are managing a team. In the above scenario, I even had some of my old team on the new team so I was thrown for a loop when some of what I did before was no longer working for this team. You might be able to take some components and re-use them, but be prepared to develop a new leadership style or approach that fits your new team. What they need might be different from the last team you managed.

Context is everything.

What's the best advice you've received about being a manager?

One On Ones. I was six months into leading my first team and never had one with any people on my team. I didn’t know about them. When I started having them, I began to learn so much about my team - what they were doing, what was bothering them, where they wanted to take their career, how could I help and on and on. Since then, they are the first thing I set up with any team I’m leading.

I like to keep them simple and do as little talking as possible letting the developer talk as much as they want so I can gain as much insight as to where I can help them as possible. It’s their meeting, not yours.

What do you tell developers who are considering making the switch or new to the role?

People ship Products, not Process

I’ve seen it way too often in software where we become seduced by the process to deliver software and everything that surrounds it. At the end of the day though, when the chips are down and those critical bugs are rolling in, you need to remember who is going to get them done - your team. People ship products, processes might help, but no one ever thanked the process at the end of a successful release.

Remember Who you Report to

When working with new managers, the first time we meet, I always ask them to write out who is on their team in a very simple block diagram. At the end I ask them to tell me who they report to, invariably they add a box above them who is their manager. It’s at this point that I take the diagram and invert it to show them who they really report to - their team. If you know who you are always reporting to (your team) and you’re always doing your best to support and enable them to grow, despite your missteps, your priority will always be where it needs to be.

And your team will know it and support you.

Final call to action! Where can we go to learn more about you?

I recently published a book, available on Amazon on leading software teams - whether you’re a software manager right now or a developer aspiring to lead the team. The website for Code Your Way Up is available at www.codeyourwayup.com and you can follow/chat with me @codeyourwayup. I also have a personal blog at www.rambli.com and you can always find me on LinkedIn @ https://www.linkedin.com/in/greg-a-thomas/.