Jekyll blogs are still relevant!
This is a story about how I run this blog "for free"
I used to code for 10 hours a day and it was effortless. Nowadays I don’t have time for that kind of effort anymore and it’s not as effortless as it used to be. My current job is also demanding in other ways, and I need a clear head to not go crazy.
And that’s the thing… my programmer brain sometimes helps me, and sometimes it makes things worse. This document is an attempt to create an instruction manual for it.
The opinions here are my own and not those of my organization.
It’s difficult to come up with an all-encompassing definition for what I do. The way I see it, there are several broad areas of impact (in no particular order):
Take your work seriously and have fun doing it.
Focus on challenges that are interesting to you; this will guarantee high quality of your work. You’ll figure out the problems yourself and propose solutions because it interests you. This way you’ll become an expert in what you do.
Be direct and don’t wait.
Is there something that bothers you, something you think you can’t solve? Something that annoys you or worries you? Then don’t wait. Share it right away. Say what you want clearly and directly. Only then can we find a way forward together.
This is about the other things I value most (in addition to the section above). Here are some additional expectations:
In a sentence: be the leader you wish you had.
Always have a goal.
To do my best work, I need clear goals. My job is to make the best choices – for my immediate team, my project(s), and the organization. But sometimes the goal isn’t very clear, especially when I have to plan 6-12 months in advance. So I’m always looking for ways to improve and challenge the status quo until we have a worthy goal to pursue.
I strive for perfection, even if it’s unattainable.
You’ll notice that I try to improve quickly – I listen and try to implement the feedback I get from those around me. I want to find ways to get quick feedback without it being awkward or boring. You can say anything if your heart is in the right place! Iterate until perfect.
Whether it’s technology, processes, people or products, everything can be questioned. You aren’t a tiny cog in a giant machine, but a central part that keeps a close eye on its surroundings.
Be opinionated, but look at the data.
Example: “I think this feature will do more harm than good to users.” But you can’t verify that without seeing data first. Follow up with: “How can we find data?”
Take ownership of your product and processes.
Constantly look for opportunities to improve and build a culture of accountability around you. Make sure your work is demonstrably stable (testing), scalable (architecture), and trackable (analytics). Mistakes happen, and they’re our mistakes to make. We’ll have a problem if you never want to try anything new.
Always be on top of what’s happening.
Always be ready to provide data and insights into all areas of our business. KPI dashboards are a must: without insight into the data, we get stuck in a loop of throwing opinions at each other.
Close the feedback loop.
Review metrics after we release something to our users, look for potential issues, and evaluate the success of the release.
Be our user.
Or rather – work, plan, think and behave like our user. We’re not an aloof office blindly throwing code at our users. We need to be directly connected with them; we should know what annoys them, what makes them happy, how they feel about us. Try to use the product more than them and gather people who have the same goals.
Be critical of meetings.
As you know, engineers don’t like meetings. If you’re not sure if you need a meeting or not, cancel it. Can it be a 15-minute meeting instead of a 30-minute meeting? Cancel the meeting and send a message instead. Can you do it with a smaller group? Make the list of invitees smaller.
Respect team processes.
We should have (at least) a team-wide understanding of the following: Definition of Done, Definition of Ready, How we Work Together, and What we Value. Please adhere closely to these agreements or ask the team to change them together – they’re the building blocks of our work together. Circumventing the agreements hurts team morale and devalues our process efforts.
Plan each delivery in advance and create a smart plan that establishes success metrics and KPIs. Actively monitor these in collaboration with operations team and inform the stakeholders as soon as you identify a problem or an achievement.
I’ll tell you when you start doing it. I’ll agree my goals with you before I start working on them, and I’ll get things done. In the planning phase, advice on how to get things done is welcome; after that, it’s very undesirable in the form of micromanagement.
Understand what I need most.
You’ll always know when I need something. And I want you to either have a good reason not to help me, or try to help me. The worst thing you can do is block something indefinitely.
Be clear about your expectations.
Create a clear list of expectations for me (preferably in the form of a document) that I can refer to when needed. Don’t invent new requirements on the fly and expect me to do something I didn’t know I was supposed to do.
My personality type is ENFJ-A.
Like any other personality type, this type has its pros and cons… I can be too detail-oriented, in which case you need to stop me. On the other hand, fairness and equality are very important to me, and I’ll go to extremes to achieve them. I’ll try not to interrupt you in your work or tell you exactly what to do. Instead, I’ll tell you about the goals and motivations and expect you to either question them or help us achieve them together.
I don’t like meetings, certainly not in the late afternoon… but when I get an invitation, I’m 100% ready and stay until the best decision is made.
It’s also hard to tell what I’m thinking or feeling (I’ve been told). You can ask me directly if you’re not sure – I’ll tell you! You’ll get better at guessing over time.
This is a dynamic document that I try to update from time to time. Some of the points come and go, or may not be perfectly worded. Sorry about that, English isn’t my first language.
But as I mentioned earlier, I’ll keep improving until I get things right.