# Adrián Moreno Peña's Manager Readme

**Engineering Manager at SumUp**

# Hello, I'm Adrián 👋

In this document (available [in Github](https://github.com/zetxek) and [ManagerReadme.com](https://managerreadme.com/readme/zetxek)), I intend to help you collaborate more efficiently with me, knowing what I expect from you, and the way I assume we will work together, to make it explicit.

As a rule of thumb, I demand to myself what I also expect from others. Please help me stick to these promises by keeping me accountable, and pointing out when you need some more support from me to work better - I will not only not take it badly, but I will appreciate it if you "help me help you".

I am a strong believer in agile as a way of working, meaning that I try to empower my teammates as much as I can, and be a "multiplier": if I can, I will teach you how to do something, because the more spread the knowledge is across the team, the stronger we are working together.

# Why this document

In the last years I've come to be aware of how many assumptions we all have when working with others, so I try to be as explicit as possible when communicating, and point out hidden assumptions that will go under the radar otherwise.

This exercise of laying out a "foundational" for the work relationship can be awkward at first - but it avoids a lot of misunderstandings and helps us collaborate more efficiently. And this does not replace any face to face communication - it should just make it easier for you to understand me.

I intend to be transparent and predictable when interacting with others - so that's why I want to write down my "principles" in this kind of "Constitution of Adrián", documenting my basic assumptions and thoughts, and what I expect from others.

# My leadership style

First and foremost, I believe that to lead I need to earn your trust. For that, I have some pillars that I base my work relationships on:  **honesty, authenticity and curiosity**.

You can always hold me accountable on these pillars - and help me the kind of leader I want to be: at your service, helping you succeed and achieve your objectives (which will make the team stronger).

# My role

Currently I work as Engineering Manager - and that involves a balancer between the people's management and being accountable for technical matters. I have joined very recently so my first priority is to have a good understanding on how the teams work with each other and collaborate, and see how I can be a good represenative of the Accounting team.

From a technical point of view, my main priorities are: systems reliability and scalability, predictability, and having a good overview of what's going on in our systems and why that's happening.

On the people management side I focus on facilitating for the developers, making sure that it is clear why we work on what we work, and removing impediments. Being a developer myself too, I try to be the kind of manager I liked to have: empowering developers, giving plenty of freedom on the implementation, and supporting when hitting roadblocks (either by pair programming, looking for help our of the team, alternative solutions...).

# What do I value most?

I value and expect  **honesty and transparency**  from people. This means that if I ask you something and you do not have the answer, the best option is to tell me that you do not know and we will work on it together.

I get quite _annoyed_ if the assumptions that others take are not made explicit (in the form of a document, message, diagram...), especially if later they prove to be wrong. Example: you do not tell me why you come to conclusions that are based on flawed logic - so I am not aware that the "facts" were just based on falsy ideas.

Related to this, I value clear communication: when something is done or decided, I expect that to be explicitly documented. This might be a slack message, a JIRA ticket comment, a code comment, or a pull request description and explanation.

But I expect that assumptions and decisions will be made explicit, so the rest of the team is aware of it.

Code-wise, I value simplicity over complexity - and working software that is well documented. Reading "[Clean Code](https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29)" changed the way I approached coding - before that, I would favour "clever solutions" (maybe trying to make me look smarter), when I've come to realize that cleaner, readable code is the best code, so any of our colleagues can own it in the future.

And something that cannot be argued against is respect: we can have critical discussions about how to improve anything in how we work, but I expect you to always respect your teammates. Always.

# My Expectations

1. I prefer to be approached by chat or a private message before getting me into a call I am not aware of - so I can prepare for that (both mentally as setting the context, and as to have the right facts).
2. If you make a mistake, I expect transparency on why that happened, so I can help you in the best way I can. Do not hide facts you know from me - when all cards are on the table, I'm your ally.
3. If you invite me to a meeting, you will have prepared it by briefing me for it and explaining me the purpose of it.
4. You can take a "no" to a question - as I might be busy with something else that demands my attention.
5. I want to be replaceable, so I will value if questions addressed to me are placed in public channels, so anyone else can help and I'm not a blocker of that specific information.
6. I do not demand quick responses, but I prefer accurate ones. Saying "I don't know" is a valid answer, as long as we later work on finding the right answer.
7. I expect you to be reachable via chat (ie: Slack) during working hours, and be able to respond a message where you are tagged in less than 1h. If you will not be available to answer during some working hours, share your agenda and availability so I can be aware of it.
8. As a product owner/project manager, I expect from you:
  1. a high level vision of the priorities and how they are important for the business of the company
  2. thinking together with the developers about how to split tickets and prepare a MVP as soon as possible, instead of bundling complex issues in endless epics or sprints
  3. detailed thinking on the issues you expect the team to solve: which corner cases must be contemplated? Which implications might have the changes on other systems?

9. As a developer, I expect from you:
  1. take ownership of the issues they deal with: if you work on a ticket, I expect you raise problems before you get stuck (the complexity was higher than anticipated - so we can take a decision together as a team)
  2. follow the best practices of the platforms you are developing in. This information is available online (google "whatever best practices", where whatever might be any system we're working on), so I do not need to point to the obvious issues, and you prepare clean solutions when possible. And if it's not possible, you should be able to explain why.
  3. you report the issues you face, so the rest of the team are aware of the challenges you are trying to solve, and maybe offer you help
  4. you to work in an independent code branch, so your changes can be traced and reviewed independently
  5. you open a Pull Request to the right branch, and document which  
decisions you have taken in the implementation, and the kind of review  
you are looking for
  6. once the code has been merged, I expect you to check if the CI/CD pipeline has run, test the feature, and be  
able to explain why it works or doesn't to a not-technical user

# 1:1s

Our 1 on 1 meetings are mainly _for you_. I want to hear what's bothering you, what you are liking, and in general how much you are enjoying work. It's a scheduled opportunity to catch up and give you feedback on what I have been observing since the last meeting, or know about problems I can help you with.

But it's a meeting _for you_, so we can make anything you want of it.

By default they'll be scheduled every 2 weeks, and we will adjust them more or less frequently at your will (although I'd rather not wait longer than 2 weeks to have a chat with you).

# Personality quirks

I am aware that I am very active at communicating and have a very wide list of active communications - and I do not expect that from you. You can tell me that you need focus and I will respect that. But I do expect you to keep track of my information requests, in exchange (comments in tickets, private chats, emails, etc).

I tend to sound excited on my communications, as I add a lot of emojis and exclamation marks. That's also because I am passionate about what we do, so that's my way of expressing engagement.

I like to have a relaxed working environment, where we can combine serious talks with jokes (mostly, bad jokes).

# Where to focus on your first 90 days?

1. I want you to understand what is the scope of the system you are working on, and how it interacts with others.
2. You will have a proactive list of improvements on the system you work on.
3. You have identified some flaws, and have raised your concerns about them, so we can improve them as a team.