I’m working with https://text.com/ for half a year now. Time passes quickly!

Company goes through a large change now - both in terms of organizational structure, as well as a new product being launched (see release video here). As you can imagine, that means frequent changes, adaptation. How did it affect me?

How it started

One day before starting the cooperation I was informed that my role has to change - instead of supporting multiple teams, I was supposed to focus on a single team which lacked resources. Very quickly it turned out that I’ve joined in the middle of the pre-release crunch and what team desperately needed was more contributors, not managers. It was time to go into the trenches.

First contributions

I was stressed as hell because I wasn’t contributing actively for over 3 years, I felt rusty. Of course I do some side projects all the time, but their scale was tiny compared to Text application. Additionally my tech stack wasn’t matching what Text was using.

It turned out to be pre-mature worry. In the first week I’ve realized that:

• even without domain experience yet, the general software-engineering experience allowed me to coach engineers through right questions; that was useful in general problem solving, prioritization, scope reduction;
• company supports using AI tooling - using ask mode in a repository made it fairly easy for me to find areas where I needed to make a change, while using this mode in GitHub copilot would help me find the right repository;
• it turned out that as usually, many problems are people and team related - acting on elephants in the room that nobody wanted to touch allowed me to quickly gain some impact;

Coding some more

Actual code contributions started from some easier tasks, where I’ve learned specific style and architecture preferences of the team. I made sure not to repeat mistakes I did and follow a pre-PR checklist and pre-commit hooks. Text has a great CI/CD pipeline which contains typical steps you would expect (static style & security analysis, running unit and integration tests) but also steps that were fresh to me - visual snapshot analysis from Percy and AI reviews from Rabbit.

With more and more weeks I started to get more efficient and codebase-aware. Somewhere last month I was able to get 36 PRs merged in the last 30 days; all of that while also doing other tasks like planning, solutioning, reviews, hiring, 1:1s and general cross-team communication.

The pendulum

Some time ago the idea of managerial pendulum became more popular. It goes like this:

• You start off as an engineer, gaining expertise and technical taste which grows with every contribution
• When you switch to management, you learn new skills but have less time to contribute in code, your expertise starts to quickly corrode because technology evolves rapidly
• Instead of going further down the road to manage managers, you switch back to being an engineer (a contributor) to refresh technical expertise while you already possess managerial skills that don’t corrode so quickly

At that point you have the best of two worlds - mix of fresh technical skills with strong leadership capabilities.

The concept was popularized because for many individuals this felt like demotion, hurt the ego. Especially for young folks who got promoted to management very quickly before they really became senior engineers.

My own pendulum

I feel that I experience right now my own pendulum. Initially I wasn’t sure about the change but later… I started to enjoy it! 😄

• It’s absolutely satisfying to focus down on a technical problem and solve it; I once again feel this intellectual stimulus that often does not fade out after work-day ends.
• It’s refreshing to learn topics from http://frontendmasters.com/ compared to another leadership/managerial book.
• 6-7 (😉) meetings a week instead of 30-40? Great!

My goal now is to experience this journey and take the most out of it.