Alex Ptakhin

I’ve often had anxiety light bulbs go off after technical conferences. People were discussing open source, so why am I not doing open source? Everyone is doing Open Source; what am I doing? Or all managers should be generally incompetent and not be stupid in processes or hires. This is all partially true—maybe even the industry is in a bad state. Everything needs improvement, rationalization, and communication. And someone like going to make it better, and people are resisting.

Recently, I came across a book about working with low performers, and this topic is discussed in team lead chats. Here’s a person who performs poorly, does tasks slowly or incorrectly, and maybe someone else doesn’t like the communication. So we put him on a Performance Improvement Plan with some metrics, which, for some reason, we consider objective. And then the person improves or not. If not, then we part ways.

Yesterday, the excellent speaker Veronika Ilina saved the weakening ex-speaker Alexander (me) at a meetup about hiring, onboarding and offboarding. A bit about hiring today. it’s not very difficult to make some weird stuff in hiring from my experience. Looking for one position, realize “something is not right” and start looking for another. Opening, changing requirements, closing positions without hiring. Yes, It is costly to hire! The time of the hiring manager and the recruiter, if any, and the time of the rest of the team in the interview.

I told myself yesterday that I needed to write a post for tomorrow. I wrote down several drafts on different topics, but they weren’t finished, and the post had to happen. Over the past month, in the background of work and home, various frivolous activities have happened: While suggesting on meetup for the ‘hiring’ topic, added ‘and off-boarding,’ and now there will be a mini-talk for 10 minutes I composed limericks, a short poetry format with a punch at the end, trying to rhyme into a form in English.

After finishing Kent Beck’s Extreme Programming recently, I was left with questions about how and why. I agree with the ideas in the book, but there’s always this “but” that seems to undo everything before it. I can read many research papers about individual or group work, yet the resistance remains. From school to university and into the early years of work, we’re taught to focus on individual work—individual effort combined with social interaction.

When I learned to drive, some of my teachers tended to repeat: “You are driving in the direction where you are looking.” But my other teachers told me it was incorrect. Yes, I will crash when my eyes are stuck on one object for a long time. But if my eyes don’t stick, I can drive almost 360 degrees from my view by changing the view angle constantly. I’m a slow driver.

When I scroll LinkedIn I’m definitely not ready to read carefully long reads. I opened one article with no images and no interaction. I couldn’t just start reading it. I wanted to scroll and consume it. I tried the exercise two more times, slowing down myself, and didn’t get through the first screen. I can complain a bit about the post-COVID health state, where reading any problematic reading is becoming especially tough.

My understanding of DORA was about the four key metrics (Deployment frequency, Lead time for changes, Time to restore service, and Change failure rate). I didn’t understand why it should be relevant to my work. Why should these metrics be my Northstar? They don’t give me much value. I got a better idea with the nice podcast Dave Farley with DORA research co-creator Nicole Forsgren. The initial motivation was to link technical capital to company financial capital.

I’m sure busy calendars open vast opportunities to choose one things over the others. The more people in our department, the busier our calendar, the more valuable we are in terms of power to the company. It’s inappropriate if anyone can see our free calendar and book a meeting for us to discuss something urgent. 15 minutes on Tuesday at 7:45 p.m. in two weeks sounds fine. It’s easier to add more processes.

Words about Scrum Loud titles about how Scrum ruined Agile cause boredom or disgust. But in the environment of satirical folklore of ScrumButs, ZombieScrums, and ScreamGuides, we can observe the negative side of the framework. Let’s try to go step by step about the good and bad parts of Scrum. Scrum is often called an “Agile framework” or “methodology”, which is wrong. It’s the list of values, roles and meetings. The values don’t match the original Agile’s.