The motivation for this

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 new jobs are 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, so that new people who I’m surrounded with can understand me better.

The opinions expressed here are my own and not those of my organization.

How I see my work

It’s difficult to come up with a single, clean definition of what I do. The way I see it, there are several broad areas of impact (in no particular order):

• Hacking, coding, problem solving, getting *it done
• Challenging the status quo and making it clear why we’re doing something
• Ensuring smooth communication and coordination
• Creating a safe space for those around us
• Helping achieve what was previously thought impossible
• Keeping required processes to a minimum to make sense of the chaos
• Filling knowledge and staffing gaps as needed
• Ensuring a steady flow of ideas and requests
• Identifying opportunities that can move us forward

What I value most

  A. Take your work seriously and have fun doing it.

Focus first on challenges that are interesting to you. This will guarantee high quality of your work. You’ll figure out the main problems yourself and propose solutions because it interests you. Then apply those solutions to the environment around you. This way you’ll become an expert in what you do, and serve your community best.

  B. Be direct and don’t wait.

Is there something that bothers you or something you think you can’t solve? Something that annoys you or worries you? Are you too excited to wait for the bi-weekly meeting cadence? Then don’t wait. Share it right away. Say what you want, clearly and directly. This is important because it sends a strong signal to the people around you that you want to make changes.

Expectations

Apart from the two main expectations shared above, this section is about the other things I value a lot.

From myself

In a sentence: be the leader you wish you had 3 years ago.

  A. Always have a goal.

Sometimes, our jobs require us to wander and discover. Most of the time, there’s problem-solving. 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. Sometimes, the goal isn’t clear (especially when I have to plan actions 6-12 months in advance), and that’s when I need to start looking for ways to improve and challenge the status quo until we have a worthy goal to pursue.

  B. I strive for perfection, even if it’s unattainable.

You’ll notice that I try to improve and iterate quickly – I listen and implement the feedback I get from those around me. Sometimes I disagree with what is being said. But even then, I want to find ways to get quick feedback without it being awkward or boring, and iterate. You can say anything when you have good intentions! We iterate until perfect.

From software engineering

  A. Question all decisions.

Whether it’s technology, processes, people or products, everything can be questioned. You shouldn’t operate like a tiny cog in a giant machine. Make yourself a central part of the machine, and keep a close eye on your environment. Challenge the status quo.

  B. Be opinionated AND Look at the data.

Example: “Adding this feature will do more harm than good.”   But you can’t verify that without seeing some data first, can you? Good, follow it up with: “How can we find some preliminary data?”

  C. Take ownership of your product and processes.

Ownership is not gatekeeping. Gatekeeping comes from a place of insecurity. True ownership comes from a place of confidence – in your work, in your processes, in your teammates. Look for opportunities to 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.

From data and operations engineering

  A. Always be on top of what’s happening.

Own your data repositories – be ready with data ahead of time, plan for collecting the right data, and have insights into all areas of our business. Know the competition. Know our own successes and failures – KPI dashboards are a must! Without insights into the operations data, we get stuck in a loop of throwing opinions at each other.

  B. Close the feedback loops.

Review your metrics after we release something to our users. Look for potential issues, and evaluate the success of the release in iterations. Don’t hesitate to share and validate your findings with the team around you.

From product managers and owners

This is going to sound really strict, but on your second read it won’t be!

  A. Be our first user.

Or in other words – work, plan, think, and behave like our first user. Not the last user, who we don’t care about anymore. The first. The one that will leave and bankrupt us if we do a bad job. We’re will not randomly throw features at our users. We will be directly connected with them – we will know what annoys them, what makes them happy, how they feel about the products we ship. Use the product yourself more than they do, and gather people who have the same goals to test it with you.

  B. Be critical of meetings.

As you might have noticed, engineers don’t like meetings. If you’re not sure whether you need that meeting or not, cancel it. Can it be a 15-minute meeting instead of a 30-minute meeting? Cancel the meeting and send a longer message instead. Can you do it with a smaller group? Make the list of invitees even smaller. Do you need to prove to your manager that you’re doing something? Ask us to help you do that rather than optimizing for getting us blocked for hours.

  C. Own the product BUT Be open to iterate.

Don’t manage. Nobody likes managers. Own your product instead. Learn it well, know every detail of it, and be opinionated about its future. Plan each delivery in advance and create a smart plan that establishes success metrics and KPIs. Be ready for shocking discoveries. Actively monitor KPIs in collaboration with operations teams and inform the stakeholders as soon as you identify a problem (or an achievement). If changes are needed, don’t hesitate to make them.

  D. 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 and the backbone of team collaboration. Circumventing the agreements hurts team morale and devalues our process efforts.

From my manager

  A. Don’t micromanage.

I’ll tell you if you start doing it. I’ll agree with you about my goals 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 much undesirable. I need to figure things out on my own.

  B. Understand what I need most.

You’ll always know when I need something. I want you to either have a good reason not to help me, or actively try to help me. The worst thing you can do is block something indefinitely for no reason. Hear me out, I will usually have a lot of ideas that challenge the status quo – very often it will be possible to make changes, so let’s do it.

  C. Be clear about your expectations.

This is a cliche, no? Let’s create a clear list of expectations for me (documented), that I can refer to when needed. It shouldn’t contain 1000 items, I can only chase one or two major goals at a time. Don’t come up with new requirements on the fly and expect me to have done something I didn’t know I was supposed to do.

Personality quirks

My personality type is ENFJ-A.

Protagonist persona

Like any other personality type, this type has its pros and cons… I can be too detail-oriented, in which case you’ll need to tell 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 afternoons… but when I get an invitation, I’m 100% ready and stay until the best decision is made. Expect to go back and forth with me for a long time if you give me a poor set of choices to start with.

It’s also hard to tell what I’m thinking or feeling (or so I’ve been told). This quirk can be difficult to get used to. The workaround is – I’ll just tell you if there’s something wrong! You can also ask me directly if you’re not sure. You’ll get better at guessing over time. 😅

Final comments

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.

I mentioned earlier, and I’ll repeat it here – I’ll keep iterating and making changes until I get things right. Let’s solve problems!