By Merlin Carter
How do you envisage the second half of your career as a developer? You could go down the leadership and management path and become a CTO. But is that the only path available?
I put this question to our CTO, Stephan Schulze, and he had some interesting this to say. We discuss “beginner’s mind”, T-shaped profiles, and how the tech sector keeps evolving. You can listen or read below. Enjoy!
Merlin: Hi Stephan, It’s great to have you back from your well-deserved summer break…because we’re all hungry for more tech insights.
And this time, I’m looking for insights on developer career progression. Specifically for those developers who are approaching the middle of their careers.
What I mean by that is people who have reached some kind of senior position. For example, most people in our development team have the word “senior”, “principal”, or “lead” in their job titles — I would say they’re approaching mid-career because they’re still fairly young.
I would say they probably have about 20–30 years left in their careers which is a lot of time for progression.
The problem is that not everyone progresses at the same pace. I’ve heard that people’s career trajectories start to diverge after they reach a certain level of seniority. Because when you finally become a pro in any field, I think it gets harder to distinguish yourself and stay fresh.
So….. if one of our team asked you for guidance on how to progress beyond the level of a senior developer, what would be your advice?
Stephan: Well, it all comes down to what you want out of your career
There are a couple of directions that you can go:
- You can become a team lead which puts you on the management track.
- Or you can become a principal engineer who takes you down a different path…..one that leads to becoming an individual contributor or expert.
- Another option you can choose is to go into a hybrid role.
A role where you organize and develop technical solutions across multiple teams and/or departments — this requires a broad knowledge of tech but also strong communication skills, as well as business acumen and management experience and knowledge.
People like these are often called Technical Program Managers or Technical Leads or similar.
The most important thing is that you really think about what you want:
If you’re ready for more responsibility, you can take the management or Lead track, or you can also try something else. That’s the great thing about tech, it’s such a broad space, and there are so many things that you can do.
Suppose that you’ve been a backend engineer for 15 years. But maybe you’ve gotten more interested in how front-end technologies have evolved. You can easily switch over frontend development and at least start off as a “junior” front-end developer. Or you decide that you’re interested in machine learning or whatever else is out there.
There is a wide range of options, so it’s really up to you to figure out what you want.
Merlin: So basically, an alternative to management could be specializing in a very specific area?
Stephan: Yes, but you could also do the opposite and become a generalist.
For example, we have a couple of people who’ve been with us for quite a while now.
They’ve spent a few years each working on both frontend and backend projects. Each developer has become like a kind of swiss army knife. You can pull them out of your pocket and throw them at any problem. You know that they’ll come up with a good solution.
You also have developers who are also very good at DevOps and Cloud Infrastructure. Not all developers are interested in this aspect of the job, but it’s another way to expand your skills.
Last but not least, we see people who develop more and more into a broader role, who also have strong communication skills, broad knowledge, and the will to influence and change tech organizations for the better on every level — who lead but not necessarily in a classical team lead/engineering manager role.
Merlin: Yes, now that we’re talking about the generalist approach, does it make sense to clearly differentiate between front-end and back-end teams when people get to that level. What about the so-called “full-stack” developer? Should senior developers aim to be full-stack developers?
Or do you think some people just aren’t interested in dealing with the specific kinds of problems that you’ll face in either frontend OR backend development?
Stephan: Well, that’s the thing, right? Everyone has different preferences.
There’s an endless list of problems that you can solve in the backend space, so you won’t run out of challenges. You don’t have to go full-stack to find new challenges.
But maybe you like working for smaller companies, and smaller companies usually need someone who can do everything. So becoming a full-stack developer makes more sense.
Even then, full-stack developers usually have a specific focus area — an area where they’re especially strong.
This is what people call the “T-shaped profile”. You have a deep proficiency in one area but are also skilled in a wide range of other disciplines.
Merlin: Ok, but what if someone doesn’t want to take either track? For example, you started out specializing in backend development with PHP and Symfony. Then, you started on the management track and eventually became a CTO.
But what if you just continued PHP and Symfony and specialized in it right up until today? Would that worry you if one of your developers wanted to follow this kind of path?
Stephan: Not at all….. it’s a completely valid option, right? You can solve many problems with PHP too.
But I would expect the person to be open-minded enough to try another language when PHP can’t solve a certain problem.
For example, if an application has a high volume of transactions with large amounts of data, PHP might not be the most performant option. I would hope that the person has the skill and experience to use another language.
But generally, if someone said to me, “I’m so in love with PHP and Symfony…I want to work with it for the rest of my life” I would say, “Sure, go for it — why not?”.
I mean, look at the state of PHP 10 years ago compared to how it is today. I couldn’t have predicted how it would evolve.
Likewise, it’s hard to predict how PHP will look in the next 10 years. Maybe PHP and Symfony fall into obscurity — who really knows?
So, you can’t really count on being able to use the same frameworks for the rest of your career.
This is the challenging (but, from my perspective, also an exciting) part of working in (and with) technology.
Merlin: Yes! That’s exactly what I’m getting at.
It’s not just about what framework you, personally, are passionate about. You also have to be a little bit strategic when thinking about your career.
Especially if you work at a company like ours, which is somewhat similar to an agency. We have to be conscious of our target audience — which is our portfolio companies. We have to be aware of what technologies they’re using so that we can adequately support them.
I would guess that other teams, like marketing and sales, have a similar challenge and I notice that they do a lot of courses and workshops to keep their skills sharp.
But it sounds like you leave this further education to the developers themselves. Would you ever gently nudge them to do a course or actively upskill in some way?
Stephan: Absolutely, we already do that, in fact.
When I joined Project A around five and a half years ago, we had two backend teams that each focused on a specific language — Java and PHP. Nothing else. And, of course, there was the frontend team that focused on JavaScript, HTML, CSS, etc.
But if you look at the teams now, it’s a lot different. We have one backend team that can still do PHP and Java, but they also support Kotlin, Golang, Python, C#, and a few others.
This didn’t happen because our developers demanded we use those other languages. It happened because I talked to my counterparts at other companies, and I noticed that they were using these languages more often.
When I notice that startups are working with a new language or technology, I’ll raise it with my team, and they’ll go and do some research. And this is what I really appreciate about my team. They’re open and willing to leave their comfort zone and learn a new language.
This isn’t easy. Even if you’re an expert in the principles of programming, it can still be painful to learn a new language. You have a new syntax to learn and new terminology. You’re an efficient senior developer, but you have to start at a junior level again. At least for a little while. Senior developers can usually get back to their original velocity quite quickly.
So they eventually get good at the new language….and voila! We have a new skill in our service catalog.
Merlin: I see, I see — and to build up a team like that, you need to hire for specific qualities, right?
I mean, not everyone wants to regularly go through the hassle of learning a new language. If you’re proud of being an absolute master of Java, maybe you don’t want to go and learn Rust…..because it means you’ll be a beginner again (at least temporarily). Not all masters appreciate the joy of the “beginner’s mind”.
So if you are looking to hire someone who already has a lot of experience, how do you make sure they’re flexible enough to keep evolving?
Stephan: Well, my first priority is to hire for what we need in the short term. So if I need another Java developer, I’m mostly interested in their Java skills.
But of course, I’m going to be transparent with them.
I’ll make sure that they’re aware of our operational model.
- That we need to adapt our skills to the requirements of our portfolio companies.
- And that these requirements are always evolving.
So what I tell people in interviews is something like:
”OK, you are starting here as a PHP developer. But in the future, we might ask you to learn Python, or another language, like Java or Kotlin”.
And I think most candidates already know the basics of other languages. So it’s not an impossible challenge for them.
Naturally, I also ask candidates if they’re comfortable with that — and if they’re comfortable with change in general.
Because they’ll need to react to change and also push for change when necessary.
I also make it clear that they won’t be thrown into the deep end. It’s not like we expect them to learn GoLang in a week. We’ll give them all the time they need. But they at least have to be willing to learn it.
Indeed, some of the developers in our team have occasionally switched languages. For example, I was recently talking to one of our developers who started here as a PHP developer but later switched to something else.
I wanted him to start on another PHP project, and he said to me:
“Stephan, sorry, but it’s been 2 years since I worked with PHP or the Symfony framework — I need a bit of time to get back up to speed”
And I said, OK, sure, go ahead, take some time to do some reading and catch up on all the newest versions. Then we’ll be ready to go.
Merlin: Yes! and that’s really the heart of this whole discussion.
Maybe some people naively assume developers are just “heads down” coding all day, every day.
I don’t want to make assumptions about other teams, but it seems like there’s often an in-depth research phase before they start making big changes.
Do you build research and learning time into your estimates when you’re quoting projects? Do you set aside a time budget each week or month for learning? How do you account for that non-coding part of the job?
Stephan: Yes, we do reserve time for that. In fact, our regular IT open space just started today. That’s a monthly two-day event where developers can work on their own projects and learn new things. But generally, the amount of time that we reserve really depends on different things.
We have our regular knowledge-sharing sessions, where developers can showcase interesting things that they learned on certain projects.
Occasionally, we might ask our portfolio companies for extra time as well. For example, we might have a developer who has a basic knowledge of a certain language but needs time to get better at it.
And then, one of our portfolio companies turns around and asks us if we can support them with this language. We might offer them a deal where that developer onboards with them and starts working with them for…. let’s say….a four to six-week learning phase. And of course, they won’t need to pay us for that, as this is obviously an investment from our side, which results in a win-win situation.
That gives our developers time to get up to speed in a real-world situation rather than just learning with theory and tutorials. And it also gives them time to integrate into the new team.
So that’s another way to account for learning time, and so far, it’s worked really well.
Merlin: Yes, that’s great when you have the time to ramp up. I’m curious about urgent situations, though.
For example, we have a startup where the core of their platform is written in C#. But let’s say a prestigious .com giant suddenly poaches all their top developers, or they all just resign for some reason, maybe to start their own company.
In any case, there’s an urgent need to replace them — there’s an urgent need for C# developers who can get up and running quickly. And then, maybe in the meantime, we’re supporting three other startups that need C# skills.
So at some point, you might realize it’s not enough to use your all-rounders, you need to add some C# experts to your team.
Do you have a strategy for when the technical requirements of our portfolio start to shift in a new direction?
Stephan: Well, I would say it highly depends on how permanent those requirements are.
In the case where there’s a sudden gap in skills because developers just left, there’s a limit to what we can do. I would then just focus on recruiting as fast as possible, with the help of our Talent Acquisition Team. This is a very similar case to when a company grows all of a sudden and urgently needs more developers.
Another option is using specialized freelancers until you can fill the gap with permanent team members.
Essentially, we’ll do whatever it takes to keep the company afloat.
Naturally, it’s always painful when people with a lot of domain knowledge and experience leave and take all that knowledge with them. But at least your application is still up and running.
OK, it’s going to be harder to maintain, and you won’t be able to add new features in the short term. So you just need to slow down for a while until you get some new people. But we can at least provide a safety net during that period — we can provide some technical support. That’s also important for other reasons.
The developers who are left behind don’t need to feel so isolated and overwhelmed — they can feel safe knowing that our developers are there to back them up.
And meanwhile, our Talent Acquisition team will be busy searching for new recruits to help them get back on their feet.
Merlin: OK, but what about your strategy for hiring people for our own team? For example, I heard that we’re looking for a GoLang expert, right?
Stephan: Well, that’s partially true.
We’re more generally looking for junior to medium backend developers. By the way, if you’re listening and you’re interested, just take a look at our careers page.
But generally, we already have a couple of people with GoLang experience, it’s just that they’re not “experts”.
Also, I think it is difficult to define what the term “expert” actually means — the definition is usually very subjective.
So if you know “Go” and at least one other language, your chances of being hired at Project A are pretty strong.
Merlin: Aha, so it’s not a “no go” if you don’t know Go, but if you “know go”, you know where to go……sorry, that’s my dad joke for this session (cringe).
But seriously, I’m curious, what made you suddenly decide to recruit for this skill? Did you just wake up and think, “Go is so hot, right” I need people who know Go? What was the trigger?
Stephan: There wasn’t really a specific “trigger”, I would say.
I just talk to CTOs in our portfolio and in my wider network and get to know the tech stacks that they’re using.
And I just began to notice that more and more people are choosing to use Golang, and it’s now becoming more relevant to the market we are operating in.
In a nutshell, it was about: understanding the needs of our portfolio to be able to support them best.
But it’s not like I’m about to hire a full Go team…like we did back in the day with Java or PHP.
We invest slowly, so I want to build up our expertise slowly. This is the approach that’s worked well for us so far…
Merlin: Indeed, and you’ve inspired me to continue talking like a dad and lapse into a football metaphor for a second….
As a CTO, you need to have a feel for what kind of players you need in your squad. And you need to adapt your squad for different tournaments or games.
So you’ve developed a gut feeling for what you’re going to need in the short-term future, right?
Stephan: Yes. It is a gut feeling mainly formed during many conversations and listening actively. And this really also depends on factors that are out of my control.
I don’t know who our investment team is going to pick next, but I have to keep track of their investment strategy and make sure I have the right skill set and capacity to support our current and future portfolio.
Other companies have a fixed product that runs on a certain tech stack. If they’re unhappy with their stack, they can just switch technologies.
With us, it’s more unpredictable. We need the right skill set to support the entire portfolio. So we need to make the right choices.
For example, if I see that companies have more Go in their tech stacks or if we’re investing more in deep tech startups, then we need to build up our knowledge in languages like Rust and GoLang.
Merlin: Yes, and I see now that being in that situation gives you a very unique skill set as a CTO. In fact, we should follow up on that subject in another session.
Because unfortunately, we’ve run out of time — but as always, I want to thank you wholeheartedly for sharing your insights. And again, if you’re interested in working for us, check out our careers page.