Transcript
Reimers: My name is Sven Reimers. I will try to take you onto a journey following me on my career path. I try to share some of the lessons that I learned during taking decisions along that path. Where do I start? Probably, where the journey begins. I'm not a computer scientist. Back when I started studying, that was not such a big thing. I chose to be an industrial engineer. Why did I do this? I like the broad scope of the studies. Ranging from microeconomics to macroeconomics, and all the different engineering fields from automation and robotics, to the process things and fluid dynamics. It was really a large spectrum. I really like this approach of having a good basis for what I was becoming afterwards. After my studies, I started doing a job as a research assistant, under the automation laboratory. We did traffic simulation. That was my really first encounter with software with a lot of stuff for the project. I had some experiences from the studies building programs in different languages and on different computer systems. It's uncomparable to what I got there. It was a fairly large project for a traffic simulation. It was a legacy application, completely the term you would be using today. It was built by generations of people before me. I had to figure out how all this worked. I figured out, yes, I will definitely need way more knowledge in software development to go further there. I like the combination of the engineering aspects, from classic simulation, to the physics part, to engineering part. I liked to combine this with the software things. I think this really shaped my journey very much. When this episode came to an end, I decided to stay there in the software development corner, and then try to get a job in the IT business. I put out my resume on the largest German exhibition at the time, the CeBIT. I got my real first job. Yes, there probably is where my first lesson comes in.
Lesson 1: Embrace Opportunities
First lesson, embracing opportunities. What happened to me was, I was hired for building a very shiny, new project, which in the end, never materialized, but I didn't know this from the beginning. I started digging into the details, start trying to build out some documentation, learning about the processes to be adapted for this project, and whatever thing was there. It was probably a bit more dry compared to the things I was doing before. Nevertheless, it was a really cool project. The things I was doing in my day work were not so technical in the end. Then one day I was proposed, if I could do a rescue job, a rescue mission to support some colleagues in another project. They were looking for some expertise in Java development, something I learned during my research assistant phase. If I would be willing to do this while we were waiting to get the other project more online. I thought, ok, just going there, doing this, I don't know. I looked at the project. In the end, it was interesting. It was a space business. At least the deep space business, not very rocket science-y, but very interesting. I liked the challenge of just going there and trying to see if I can pull this off, and the trust that people have in me that I could do this to check if this really works out. I embraced this opportunity, and I took my next career step. I became like a full-time software developer. It was just an amazing experience. Embracing the opportunity, even though I was a bit hesitant, because the other project was probably way more cool. My position in that project would be way more distinguished, but yes, why not? I chose the technical challenge, and embraced the opportunity.
Lesson 2: Bridging the Engineering Gap
Having gone then through this new phase and getting a new job, I figured out lesson number two for me, bridging the engineering gap. Coming into such a job, where you know nothing about the domain, so absolutely really nothing. Everything feels like rocket science. I have the need to learn a lot. It's not only that, the software developer has to learn a lot. It's necessary that the software developer shows some of the skills to the other people, to the other engineering people. The engineering people do not understand software development. Typical software developers probably are not very good at engineering. Building up your technical knowledge, and getting your technical experience ready, will help you to get the communication flowing, and to be a better software developer, because you can better understand what the engineering people want to try to sell the customer. In the end, everybody, every developer is producing something that the customer wants. Typically, the other people do not have the idea what software can really do. There's like a divide between those two engineering domains, so software engineering, the domain engineering. Sometimes they're really hard because the domain engineers are like, "You're just only doing software. That's a simple thing." What we're doing is really hard. You had to fight to be recognized. It's something that is really important. One of the major technical things was showing them what you can do, and what the software can do to solve their problems, was really important.
Lesson 3: Primus Inter Pares
With this, my role in the team changed. Once I got all this figured out, the communication with the engineers was really important. Another aspect kicked in, due to the fact that I've got a lot of the general know-how already with me that is required, people were starting to show up and ask me to help them. My role changed from writing code to mentoring people. I was just going round and helping people getting the job done, solving their problems. Only part of my day work was still pure coding. Still, without doing the coding stuff, I would never be able to help those people along the way. Being the primus inter pares was a good thing. Be a key knowledge person, ask the question. Help your colleagues, is already a thing. Yes, I really liked the decision to not throw out the people, the masses, and say, no, I have to do the coding, but to take care of them. It was really good. I continue building on this today.
Lesson 4: Spread Your Knowledge
This has been the first step to get me into the share your knowledge. A lot of people tend to be very fearful with sharing knowledge and keeping knowledge to themselves because they think it makes them irreplaceable. I think it's just the other way round. If you start sharing your knowledge, more people know what you know, and more people know how much you know, and how much you can add benefit to all the other people there. What was happening was that people started to see that there's a lot of knowledge gap between the different team members. We figured out, we need a way to solve this. A lot of new technologies come along, architecture ideas, everything around the software parts, not the engineering things. Really, it's just the software. I figured out we need a way to communicate this better. After lots of discussion with management, we got an initiative of what's called Lunch and Learn, so the people brought the time the company brought the lunch. That was back in 2000, so 20 years back. Today, this is probably a well-established thing. For such a small company, it was really a big step forward. The idea was, everybody could put in ideas for, we need to know about how does this work. Anyone from the team would pick one of those ideas on those topics, and prepare a presentation and try to share what he learned, what he prepared, whatever it is, and just go along. While that was the idea, but in fact, it ended up with people having a lot of ideas and me doing a lot of presentations. I think that's the typical way is if you start accumulating knowledge, it's always you who learns more, and to share more. By sharing my knowledge, I learned a lot way more than by keeping it to myself. Because a lot of more questions pushed me forward and getting my knowledge up to date and learning new things, different topics I probably wouldn't have looked into for myself. Because I'm to do the presentation and to get the people up to speed, I went there. Spreading your knowledge is a very good thing in the end.
Lesson 5: Leadership
Let's look at our next lesson, leadership. One thing about leadership thing, it's probably something that's very similar to the lessons we had before. Let's try the next evolution step. What do you need for technical excellence, technical experience for our leadership thing? Let me share a small story. One thing that's always tempting in that career step is to not stay focused on your technical thing, but sidestep and go into other career paths that are way more visible. In my case, this was an offer. Let's put the other way around. First, I was hired due to my very good knowledge. I was hired as the software architect for the next space project inside that company, so moving from consulting business, to being a hired employee. Very nice, being headhunted. Once all this was established, I've seen, with my title, people figured out that the way the project was managed was not working out very well. They somehow asked me not to take over, that would be too much, but to step in and take some of the project management based on authority. That was the time where we had like a saying that we had too many good system engineers that were bad project leads. I think this was one of the things where I discovered, no, I want to stay in my technical domain. I don't aspire to be a project lead or whatever, or project manager. I just liked doing the tech things. Saying completely no was not an option as well, because the team needed someone leading them. From being the primus inter pares, and from sharing my knowledge, I went to be the inofficial team lead on a technical perspective. I'm not just doing the architecture for the system, but taking care of the people with all technical problems and everything that was there, but I'm not stepping into this project management role. This was a hard decision because it was like I'm not following the normal career path. Instead, I was shaping further my technical excellence. I think the technical excellence and the technical experience was what was keeping me on track, at least. Don't be afraid to be a bit of a leader, that doesn't imply that you will be moving on to the typical management career steps. No way. Just keep focused on what you're doing, and shape your technical experience. This will take your band to the next level.
Interlude - The Award
Having talked about these leadership parts, and having already done the five lessons, I think it's just like an experience knowledge share what technical people may do, what you can do. You should not be afraid to go forward. One of the things that shaped my further career was getting an award. Having had already context a bit in the open source world, what could I do about the software writing? There's an award ceremony that's called the Duke's Choice, who watch out for big software projects in the Java world. The people doing the ceremony and the award campaign got in touch with me and said, "This is such an interesting project, you need to nominate it." I talked to my management at that point in time, and asked them, do you want to do it? I was very astonished. The answer was, no problem with doing this, but you need to do it. They just put the ball back into my field. I had to decide if I wanted to pursue on putting in the nomination and doing all the work. I talked to my team, and we decided we will do it. We ended up writing all this stuff, so about the thing with me. I had a lot of hope for the demo. In the end, we got the award. The team got the award. That changed a lot of things inside the team, and it changed a lot on the visibility of what we were doing up to the highest management. The award got us visibility. The award showed that we were doing a good job. As I say, what we were doing was not like we're just doing some software. No, it was really an excellent big project and was recognized as being something outstanding. That was good for all of us, and was good for the company. Lesson from here, don't be afraid to ask. In the end, I think it's getting recognition for what you're doing, and being aware that what you're doing is not something that's a typical business. Everything you do is something special.
Lesson 6: Leave Your Comfort Zone
Taking this forward, the experience I got from this and the result I got from my technical experience from building this, gets us to my next lesson, leaving your comfort zone. What happened was that a former colleague that had left the company before got in touch and said, we will be doing a new project, and we have no clue of doing software development, but we know you have. Back to square one, technical experience matters. It's the key point in getting people in. Do you think you can do this? It looks like the challenge, so it was like 12 years before, only way bigger and the expectations were way higher. Leaving your comfort zone is not easy. Don't get me wrong. Being in your comfort zone means, you can still work with your friends. You know the people. You know how everything works out. You know the habits and how to deal with those people. If you leave this, you leave everything else behind. You leave your friends behind. You leave the processes behind. Everything will be new. In this case, it could be even if you see a degraded title, because not everyone is into a shiny, new title. Being a software architect for a large project to being a system engineer, because there are no other job titles. It felt weird at the moment. In the end, I thought starting from scratch, no legacy, new challenge, there is nothing, we can define everything new. That's a great challenge. That's a great opportunity. It's a good way to even further my technical skills. In the end, although this was a quite hard decision, I accepted the new challenge. Leaving the comfort zone was my next career step. It was, again, all about technical excellence and the technical experience I had to share.
Lesson 7: Lifelong Learning
Moving on to lesson seven, lifelong learning. Coming from a space company, going to a space company, it's a space project, I thought this should be fairly easy. I know space. I couldn't have been more wrong. I had to relearn what rocket science really is. I need all my old physics things but I couldn't remember. I needed a lot of more new engineering things as well. Not only, I had to learn a lot of new things, new processes. I had to figure out that I had to unlearn old habits, because things were not the way that they were before. Lifelong learning is something that is good. Lifelong learning is something that happens, don't be afraid. If you come to something that's new, this is just the way it is. Lifelong learning shapes your technical experience, and will get you further. One of the things that was really overwhelming, in another way, was thinking about, yes, we can start from scratch. It's a good thing, because I could just take everything that is really new, but I had to learn that you have to do everything from scratch. It's not just the opportunity to make everything new. You have to do everything new. There is nothing you consult. You have to build up everything. This heads to what you have in your experience. You learn things you had never learned before, because it was there already. Building software development processes from scratch is a challenge. You have to figure out everything from the beginning. Don't be afraid. Even starting from scratch requires a lot of learning in the end.
Lesson 8: Open Source
From that lifelong learning, there's some more to it. Having done this lifelong learning thing, I still was, in this domain, the new kid on the block. Nobody knew me. There's a lot of high-profile people doing complex things with space sensors for measurements on Earth. I'm really feeling weird. It was just, yes, I'm just the software guy. The idea was how to find my place there. What happened was my open source things came to my rescue. Lesson eight, open source is a good thing. Open source is not, you need to do a decent amount of projects. No, it's just open source gives you a visibility angle. In the end, what happened was I got nominated as a Java champion. That nomination alone got me visibility. People are asking, ok, so what are you doing there, and why do you get such a nomination? They were just interested in what was happening. There was a new exchange on the internals of what we're doing. It was not just like, those are the people who are doing software. No. Software is a craft. Software is something that's as complex as their engineering as well. We need both of those worlds. This nomination got me a way in there. Suddenly, it was like, yes, we as a company, now the real exchange, want to embrace what you're doing. I got the MVP, the approvals to doing those things. I suddenly got funding for going to conferences, and for shaping my technical knowledge by going there, by giving talks about technical aspects. This was a new thing for me. It showed that there is value in what I was doing there. All this in the end, it led to like me figuring out that my company is into open source. That we have a strategy for that. Then all this builds up to the technical knowledge. If you want to get visibility, being in open source was definitely a good thing.
Lesson 9: Expertise
Lesson nine, expertise. We are already talking a lot about the experiences and expertise thing. The next thing that happened, and the lesson I took was, the company figured out having a real technical career path is something that was really important. They offered something that was called the expert career path, where people that fit that profile were put into a kind of pool from which the new experts would be selected. That process has changed a couple times, whatever. Being an expert, it's not just about your technical experience. Being an expert, you have to weigh in a lot of other factors as well. Those are things we already visited in the other lessons. Being an expert, you should know on the impacts of your decisions in your technical field. All decisions you take have an impact on how projects work, how the business will work, on the success of the business. It's not just selecting the newest and shiniest technology. As a technology leader, as an expert, you have to be aware of the consequences of your decisions. You have to lead those things and you have to communicate those things. There are a lot of things that are entitled. In the end, it shows that it's necessary to focus on those expertise. This expert career nomination was really something new for me. This expert thing, it was like the natural step forward, I was already looking for all the time. Being recognized for what I achieved is one bit of the deal. The other is, being visible for others, for what my knowledge can help them. Again, all these is still there. It's like the culmination of the career path, in the end. For this expert thing, probably another aspect, something that got lost here is, yes, I'm still a software developer. With all that I've done, I'm still doing software development. I'm still doing coding. This is based in the necessity of knowing everything from top to bottom. I think you all know this term the T-shaped engineer, so you need a broad range and you need the deep knowledge. Having this is the baseline of being an expert in your field, because it's necessary so that you understand all the limits and all the ranges that you can achieve and do. Yes, that's nine, being an expert in your field. Select where you're really good at, focus. That's why [inaudible 00:32:27] the expert in functional software architecture. There's a special meaning in the name. It's like a specialization. Expertise has something to do with specializing in the field, but it doesn't mean that you're only a specialist, but you still need all the things around. This is really important.
Lesson 10: Love Your Job
I think the only thing that is typically left is lesson 10, you should love your job. If you love your job, the career will probably come to you yourself.
See more presentations with transcripts
