A handbook on working with me
As a developer, I want to:
- Grow: I always want to be learning, and improving, in my craft.
- Help others grow: Software, more often than not, is built by teams of people. I want the people I work with to level up in their skill set so that they feel successful at their craft. I want co-workers who are "different" than me (e.g. race, gender, educational background, etc) to have long and fruitful careers. I value leveling up early-career folk.
- Provide value for the org: I want to help the org push the needle and contribute to exceeding the customer's expectations.
- I see myself being most effective in the ambiguities that exist on the Product/Engineering interface. If there's a product owner that needs to work with an engineer to figure out what can/can't be done, or figure out what the risks of an approach are, that's where I can provide value to the org outside of engineering.
- Imagine a ":)" exists after all of my written communication.
- When I give my opinion on how something should work, I want you to give me feedback if you disagree with me. It is likely I misunderstand something.
- If I'm confused about something, I'll ask questions bluntly. My intention is to understand. But, if I rub you the wrong way let's have a private chat about that because I want to work well with you and if there are concrete things I can do to be a better teammate, I'm all ears!
My answers for first 1:1 questions
When I percieve that there is a lack of mutual good will among team members. If I can tell that there are team members that resemble competitors, that are trying to tear each other down, more than they resemble a team trying to succeed, it makes me grumpy.
If I'm not learning or growing in my craft, I can get grumpy. Part of what I like about software development is that I can always be learning. Getting exposure to new paradigms (e.g. a new programming language or a different type of design I haven't seen before) is refreshing because it represents an opportunity for growth.
I may be reclusive. I may withold input in team discussions. I can tend to wear my heart on my sleeve so I may come across as pretty frosty if I'm grumpy.
Having a conversation privately, asking me if I'm grumpy and then giving me time to share how I'm feeling is probably the best way.
In-person, or if I'm remote, over a Google Hangout.
As it happens. If I'm doing something I shouldn't be doing, I want to know sooner, rather than later.
When giving me feedback, please also mention things I'm doing well at. Only hearing criticism can make me feel like I'm never helpful.
Public
What kinds of recognition are important to you? (Inspired by Julia Evans' post)
If you can answer "yes" to any of the questions below, then I'd like recognition about it:
- Have I helped advocate for team processes that made our lives easier (e.g. "let's create runbooks so I don't have to think at 3am when I get paged.")?
- Have I helped the team get definition around ambiguous goals (e.g. "This product requirement is vague, let's propose a use case to bring more clarity")?
- Have I helped create a team atmosphere where you feel supported and successful?
- Have my deliverables been on time, well thought out, ensuring that all stakeholders are satisfied (e.g. "Here's a service I delivered with great documentation, it addresses stakeholder concerns, addresses concerns around introspection and scaling.")?
- Knowing where I stand: I'm my own worst critic. I usually grade myself on a much harsher curve than is warranted. Having someone to tell me where I stand can be quite helpful.
- Goal setting: Setting goals that are useful to the team, useful to the org, and interesting to me can energize me.
An advocate who will give me encouragement, constructive criticism and nudge me to do the right thing, even if it is difficult.
- We want each other, and the org, to succeed.
- Assume good intent.
- When I ask for help, ask me probing questions like:
- "What have you tried so far?"
- "What is your understanding of the problem at hand?"
Assume good intent.