I had been working in software development for a couple of years when a breaking change to my career was triggered. I left for a long maternity leave.
However strange this may sound, these were three sabbatical years. Not in the sense of having nothing to do, but in the sense of being able to step out of the daily job routine and take a look at things from a different angle. While being alone with kids at home, without having any serious mental work to do, I was more and more leaning into learning new things. I was stealing every free hour to develop an Android App for kids, to produce a sci-fi audiobook, to regularly answer questions from the community on stackoverflow.com, and so on. But this was not where it stopped.
Eventually, I started to review what was good and bad in my former job and this brought me to dig deeper into IT project methodologies. While I had a vague (mis)understanding of agile mostly coming from jokes on “how this does not work”, the book Disciplined Agile Delivery (DAD) changed my mind. I found agile to be a concept of intrinsic value.
Once I was back from maternity leave, my desire to work in an agile environment grew. I did a presentation of what I learned about DAD and agile principles to my managers and the whole department. While I was not successful in persuading the company to give it a try, soon after this I got a job offer from a local branch of a big international company to take the role of scrum master/technical lead of a newly formed team of 10. And to take this step was a real gain!
The next 2.5 years spent with my team were challenging, filled with hard work, but at the same time very gratifying. We grew together, pushed our limits together. I learned so much about technology and soft skills as never before. The company was great, the people-first culture was a standard, I even got a chance to become a member of a women leadership program.
So what went wrong?
One day I was approached by my boss with an offer to become a solution architect.
After getting some insights into the project, I got a feeling that this might not be my cup of coffee. But two factors steered me into accepting the role. The head of the branch called me and explained that the architect was supposed to work directly with headquarters which was considered good for our local branch. And second: I was lured by “designation”. From scrum master to solution architect — this was considered as career growth. So what happened next?
There was no software development involved in my new role, the project was about integrating third-party products into the company landscape, coordinating with vendors and other stakeholders, keeping an eye on aligning with enterprise architecture. Concepts I was preparing as a solution architect were about to happen in a couple of months or years if ever.
I was trying to do my best, but I felt my key strengths like love for technology and people skills are of little use in this role comparing to the former one. I also missed bi-weekly sprint demos with immediate visibility of the value we delivered. I missed being with a team. I missed coding.
Since people in headquarters were satisfied with my work, my manager never talked to me nor did I call him to explain what is happening until my frustration grew so much that I sent out a resignation letter.
Only after I read the Extreme ownership written by two U.S. Navy SEALs I fully recognized my failure.
As a scrum master/technical team leader I had an impact on the performance of ten people, as a solution architect it was only me. Why was the latter more important for the company? In what ways was I supposed to bring benefit to our local branch? I asked these questions only to myself and never asked them out loud. Instead of considering what I will get out of the new role, I should have asked how my best qualities could contribute to the overall outcome.
I did not get what the mission was about and I failed my boss, because I did not ask him.
I chalk up to experience one more thing: a passion for work matters more than to level up. I had dreamed about working in an agile way, and once this happened I loved my team, and to see them succeed was what fueled me with energy and motivation. I’m not the best developer, but I enjoy coding. Not necessarily eight hours a day, but to do at least some hands-on work. I like reading technical blogs and exploring what library or technology stack could suit our case, to see how properly chosen puzzle pieces fill in the big picture. Is it far-fetched if I say that coding is a little bit like solving crosswords or sudoku? The same fun, except, that your code brings benefits to people and you are doing it during working hours.
While writing these lines I recall a discussion I had with a junior colleague a couple of months ago. Standing at the beginning of his career he asked what is “a better career”: to become a scrum master or to become an AWS cloud expert. I did not have the right answer, but now I have one.
The best is the one which you truly enjoy.