If you are reading this it is very likely that we are or will be collaborating in one way or another in building something awesome. Maybe we are launching an app soon or taking an existing one to the next level. We may be putting together a talk about an app, a new programming language or framework, or more generally just how to work better. We may be discussing the software development processes, or how to better hire or coach developers. We may even be collaborating on going deep on a feature to make it super easy or pleasing to use.

You may very well be a software developer or architect, an engineering manager, a product designer, a business analyst or a product owner. My hope is that this intro will help in speeding up how we communicate and thus help us in achieving our shared goals more effectively.

If you have one like this or similar please let me know. I’d love to read it!

Lastly, stuff I bring up here has happened to me many, many times. I wouldn’t bother mentioning it otherwise. I’m just trying to get us to get on track faster and better. I’m not writing about you.

This piece has been greatly inspired by this other one.

About

I’ve been building software professionally for the last couple decades. I had my share of success and my share of failure too, I’d like to think I’ve learnt from both. Though I consider myself a generalist, having spent time helping in most roles you can think of when it comes to building software, I specialised in mobile development for the last half of my career.

I think mobile is where –due to the inherent restrictions of the environment– we need to push ourselves further, especially when it comes to user experience. There’s no room for 20 options in one screen, there’s no room for systems that require a user manual, there’s no room for just adding hardware to fix performance issues. Asking the user for an extra tap to achieve something can make or break an entire business when it comes to mobile. I’m positive your field of expertise has many, many exciting points of interest that demand thorough thinking and expert advice.

During this last half of my career, too, I worked independently as a contractor for multiple companies, mostly startups located in the US, Canada and Europe. I’m only just now starting to work for a well-stablished company in my home country.

I’ve founded both the NSCoder Buenos Aires and the NSConf Argentina, at that time the most important and longer standing iOS meetup and conference in Argentina. I decided on passing on the organisation of the NSCoder to good friends and earliest members, and to conclude the NSConf altogether after incredible runs.

Things I value

Clear ownership

If you hear me say that you are responsible for something, you truly are. In its entirety. It’s your project, your mission, and as such I expect you to keep me updated on its status. If I don’t hear from you I’ll assume things are going great and on time. You can rely on me for advice and resources, but I’m counting on you to deliver. I may refer to you as the “DRI” of the task at hand.

Honesty and openness

No, seriously. I will give you immediate and candid feedback. I hope you will understand where this comes from –I’m trying to help you– and that you will do the same for me.

Care for whatever we are building

Be it an app, a demo, a process documentation, a JIRA board. I like to be able to tell there was care poured into it.

Async communication

I’ve spent part of the 2000’s and most of the 2010’s working remotely. I managed to go all that time without tapping anyone on the shoulder. Please ask yourself, may I be interrupting a long thought process that may take a while to put back together? Do I really need this right now or can it wait a few minutes or even hours?

I’ll typically respond to:
Emails within 2 to 4 hours. If you tag it as Important or if you give me a clear deadline, I’ll likely be able to make it happen.
IMs within 10 minutes to 1 hour. I prefer Slack, Hangouts is OK, Whatsapp is kinda personal, so please make it your last option.
Phone calls immediately… but rudely if I’m in the zone and I realise an email or an IM would’ve done it.
Taps on the shoulder immediately… but rudely if I’m in the zone and I realise an email or an IM would’ve done it.

Am I wearing headphones?
Am I sketching on my notepad at full speed?
Am I typing furiously?
Am I staring at the blank while frowning?

Yeah, I’m probably in the zone.

Sync communication

If it’ll take more than 5 minutes, please setup a call or a meeting. My calendar is always updated. If you find an open spot, take it. There are much better chances of me accepting if you add a clear description and agenda.

Brief answers

I’m pretty much always short on time and needing to cover a lot of ground.

How many devs where involved on building feature X?

Who found bug Y?

How many criticals have we identify so far for release Z?

It’s way easier for me to ask you to elaborate when needed than to ask you to be briefer in general.

Being done in time

Being done in time means the work was carefully planned and executed. It’s a great symptom that the process is solid and that everyone –including myself– is perfoming as expected. It means we are ready to take on the next one (feature, bug, sprint, project), as opposed to being burnt out.

Brag about being done on time. Working late or on weekends is something to be concerned about, not proud of. Let me know if you are falling behind schedule. Pushing code at 3am or on a Sunday is not going to impress me(*).

I like getting out of the office by 6pm sharp(**). I’ll work on weekends only under the most daring circumstances. I’ve got friends I want to meet, I’ve got a family I want to spend time with.

(*) I may have to ask you to do it though.
(**) I don’t always do, and I do get fairly early in the morning, but it’s my choice.

Taking notes

I’ve got a terrible memory and a ton of different issues that I need to follow up. This is not going into your permanent record. I’m not going to quote you later. I’m just trying to keep my facts straight. Sometimes, I’ll be even just writing down questions to ask later in an effort to avoid interrupting you.

Volunteers

Oh, I love people who volunteer to fix whatever stuff needs fixing! I aspire to be that way myself. Take on the ugly and the opaque tasks and you’ll earn my favour. Volunteering screams team work, and leadership. Volunteering means fixing something that’s just wrong or taking on a task or role to aliviate work from your teammates. Volunteering means you’d rather take on something unpleasent than having someone else have to do it themselves.

Are you a QA lead who happens to have a Scrum Master Certificate? Are you volunteering to run the planning poker? Oh, yes, thank you.

Are you a Developer who happens to have lived for a couple years in Brazil? Are you volunteering for double checking on the Portuguese localization? Hell, yes! Thank you.

Have you just joined the project and found an error on the onboarding documentation? Are you sending a PR so that whoever comes in next has a smoother onboarding? Oh, sweet lord, THANK YOU!!1!

Self-dispensability

People who are great at what they do, who take responsibility for moving things forward and who volunteer to do the ugly tasks are scarse. You will be needed elsewhere. We need to not need you. Work towards self-dispensability. Take on the hard tasks but also make it easier for other people to take on them. Document the processes, coach others, share credentials to services used across the project. Make yourself dispensable.

Thanks for reading!

Reached this far down? Why not follow me on Twitter and letting me know your opinion on these matters?

Read.me