Pedro Piñera

Home 🏚
Journal 📝
About 👨‍💻
Speaking 🎤
Open Source 🐙
Lens 🔍
Wiki 📝
Books 📚

The manager readme

I wrote this document to share my expectations on what would make it most effective to work together, and so that you can hold me accountable for it. Use this document as an intro into my mind and how I like to operate: my mental and operational frameworks. I believe that these topics would help you become more effective and reduce managerial overhead on my side.

We’ll spend our 1:1s to get to know each other a bit better, of course.

I used Ben's README as a reference and adjusted it to my management style.

My role 👨‍💻

  • Attract, retain and grow high performing individuals.
  • Foster a culture of passion, innovation and collaboration leading to a track record for building quality tools.
  • Give the the context teh team needs to do their best job.

A couple of things that I'd like to note regarding my role:

  • If I do something that negatively impacts my ability to retain you, you would be doing me a huge favor if you let me know about it, as soon as possible.
  • If I do something that feels more like telling you how to do your job than setting context, you'd be doing me a huge favor if you let me know about it, as soon as possible

My availability ⌚️

TLDR; Very few things are more important than talking to you if you want to talk to me. If you need to talk, let’s talk.

  • You can reach out to me on Slack but don't expect an answer if it's not during my working hours, from 10 to 18 CEST. I don't read Slack nor email on my phone.
  • Heard a rumour? Need clarification on something? Blocked? I’d love to hear as soon as possible. Shoot me a Slack message, we don’t need to wait for our next scheduled 1:1.
  • Feel free to put something in my calendar, don’t feel like you need to ask first. Is my calendar full? Send me a message and I’ll very likely be able to move something around.

My assumptions 🤔

  • You’re very good at your job. You wouldn’t be here if you weren’t. If it feels like I’m questioning you it’s because I’m either: a) Trying to gather context. Or b) Trying to be a sounding board and rubber duck.
  • I’m not good at your job. You know best. I’ll work to provide necessary context and ask questions to help you vet your ideas but I won’t override you.
  • You’ll let me know if you can’t do your job. One of my main responsibilities is ensuring that you’re set up for success. Occasionally things slip through the cracks and I won’t know I’m letting you down.
  • You feel safe debating with me. I find that ideas improve by being examined from all angles. If it sounds like I’m disagreeing I’m most likely just playing devil’s advocate. This does rely on us being able to have a safe debate.
  • You are telling me the truth: I assume you are a nice person and that you are telling me as they are. If you feel there's something you would need to hide, I'd prefer if you can share that with me so that I can make you feel comfortable sharing it.

How can I help you? 😋

  • Provide context. Most of my day is spent collecting, filtering and sharing context/information from across other projects, domains, and product lines. I’ll try to push information to you as much as I can but feel free to ask about anything else.
  • Provide an outside perspective. I won’t be working on your project day to day but will be close enough to have informed thoughts.
  • Cheer. I will celebrate your successes. If you're not a person who self-promotes, please let me do it for you. Tell me when things go well, share the things which make you proud, and I'll cheer/share appropriately.“

Other. Please let me know how else I can help.

How can you help me? 😊

  • Engage with the work in your hands. You'll do amazing craft if you are engaged will the challenges you are tackling. If you are not, I'd like to know.
  • Disagree with me. The best solutions comes from a healthy level of debate. We need to be able to separate our ideas from our egos . I’ll challenge your ideas with the goal of coming to the best possible solution, I hope you’ll challenge mine.
  • Tell me when I screw up. This is very important. I screw up and sometimes don’t notice. I need to know or I’ll likely do it again.
  • Be supportive: Our work doesn't end when we put it in developers' hands. They might run into issues, have questions, or even their needs might change. We need to listen to them and be responsive giving support.
  • Bring talented people. We’re growing the team so if you know someone that could be a good fit for the team, let me know.

Distributed team 🌏

We are a distributed team with people spread across different timezones and offices. Working with such setup is only possible if:

  • Important conversations happen asynchronously: If something important is being discussed on Slack, it should be moved somewhere else, for example into a GitHub issue. It's the responsibility of everyone to decide when a conversation is becoming important.
  • Communicate. Often and clearly. What are you doing? Are you blocked by something? You didn't like something? If you don't communicate, you make it hard for others to know how you feel and the progress you are making on projects.

1&1s 📝

I'm open to any length, frequency or format for the 1&1s. From thirty minutes weekly to an hour per week. Coffee in the cafe, private meeting room, head out for a walk, video call, let me know what works best. I'll start with a weekly 1-hour 1&1 and adjust it as needed.

I like to work with you on defining your intended outcomes, and have constant conversations to help you stay on track towards them.

What I value 🌱

  • Work for living: I like to foster environments where work supports life and not the other way around. If you feel you need to work extra hours for some reason, I'd like to know.
  • Default to open: You can ask me anything. The vast majority of the time I’ll answer. Very infrequently, I won’t be able to. But I’m committed to never lying to you.
  • Empathy: I believe building software to help developers with needs or problems that they have requires empathy. Not empathizing with the users of our software results in badly designed software.
  • Be nice: Because there's no reason to not be nice. Be nice with the people you work with, with the users, with people from other teams.

Document feedback

This document is new and still a WIP. I’d love your feedback:

  • Did you find the time you spent reading this valuable?
  • Was something critical missing?
  • Were there slides included that you didn’t find useful

Reach out to me on Slack or send me an email to [email protected]