A few weeks ago I finished writing a README document on “how to work with me”. While this can sound a bit preposterous, I thought it could be a good summary for onboarding employees and tenured ones alike, in order to share what moves me, who I am (a little bit at least) and the things I value.
This is not something new. I saw a nice tendency where you can see README’s of kick ass CTOs and Engineering Managers. Now there is even tools to normalize and socialize it. Some people will share on slides, documents, a github document (hence the README title), etc. It worked for them, it would be nice to give it a shot and share in a transparent way what moves me.
At the same time, it gives a glimpse of what I think the CTO role is like (although this one changes quite often and quite fast and depends a lot on each company, context, ecosystem, size, etc. Werner Vogels defines quite well several CTO Roles out there).
Of course, all feedback on both the concept and the content is most welcome.
December 2018
Purpose and Motivation
The purpose of this document is to share how we work at our company, how I work, how I contribute and what I expect from my team. And how to achieve great team, technology and engineering culture together.
By setting it in a document we clarify expectations and make it easy and transparent for everyone. Not just my direct reports but every single person at the company.
This is based on the “I”, on myself. What I value and like. It does not have to be the same for you, but will settle expectations nicely 🙂
Feel free to comment and provide feedback on the document. It is a live one, continues changing as everyone does all the time. Keep spinning the wheel.
Notes
This only affects Sergio, as the CTO. Not Sergio as a friend, a developer or any other manager or staff within the company. By no means this should be applied to anybody else.
What I do
This is a brief summary of my job:
- Hire, retain and motivate the best professional and personal talent for our teams.
- Facilitate and unblock everything possible to make YOU excel.
- Communicate and share information, and provide transparency from business to technology and from technology to business. I set context on the importance of what you do.
- Advocate for you and your team with the rest of the team and the company.
- (And from time to time, I’ll terminate an instance or two if our Infra invoice goes too high)
In short, my work is to serve you as best as possible while keeping an eye on the company goals, the big picture and the business context (and of course the financial KPIs)
My Goal
I should be able to disappear for months from the company, and everything continues working as usual and improving over time. I should have mentored, trained and empowered each of the tech leads and tech managers so together can drive the technology bus (train!).
What I value the most
The Perfect Team
- Takes control and responsibility for our company destiny and goals.
- Has each other’s back. Cross teams and offices
- Holds each other accountable in a supportive way
- Expects excellence, first from ourselves and then in each other
- Assumes, ALWAYS positive intent. Assume that we are trying to do our best for the company.
- Keeps asking reasons, always asks “why?”. And then “why?” again. But it is open for change and modify its own ideas
- Keeps constantly learning.
- Laughs and enjoys together. With a guitar, with Nerf guns, or anything that makes us happy.
- Is focused on the value the product provides to our customers.
- Is a role model for their team members and colleagues. Goes the extra mile when needed and demonstrates excellence by role modelling.
Communication
- I am ALWAYS available. I am here to help and support you. You can always book me a meeting on my calendar (which is open). Or ping me on Slack or by phone. My time with you has more value than anything else.
- Tell me your worries, problems, feedback, or when you are happy as well. We live in a horizontal organization. You can talk to me anytime you feel you need support or you just need a hug!
- 1-1s are very important to me because they are dedicated space for you to talk about anything and everything you want. They are for you, and only secondarily for me and they are not a status meeting, unless you want to talk about status. But otherwise you can send that out asynchronously and by email. We can be flexible on the timing but it helps if we block a slot per week. This does not mean we can’t do 2, 3 or 7 sessions in a given week.
- Note: This is for direct reports, but ANYBODY in the company can schedule a 1:1 with me.
- If you see me frustrated from time to time, don’t worry too much, it is part of my job :). It could be because you made the same mistake 3 or 5 times ;), it could be because of pressure or maybe I just had a bad day!
Conflict
This is part of the job. Conflict happens, all the time. It is how we tackle it, how we face it, what makes us more mature and better professionals. We are passionate engineers and we have sometimes (many times) strong opinions.
This is not bad, on the contrary. But it means that sometimes we have to be flexible, or even let go our way.
I believe in consensus, negotiation and openness. We should strive to do the best job possible all the time but considering all points of view and options. And once we agree on something, we should support our team members, even if we didn’t agree on that final solution. (Yes, that also means that when something fails, we should avoid pointing fingers and saying “I told you”).
On Failure
I believe on failure. I believe on being passionate and brave and on taking chances. The world belongs to the ones who take risks. And no risk no glory.
I make mistakes all the time, every day. I make mistakes that can be solved easily, and some others that hunt me for days or weeks (or years).
We can make coding or architectural mistakes, or people mistakes. But the most important thing is that we learn from those and support each other on the problems. If somebody makes a mistake or creates a problem that affects you. Don’t be mad at him. Help him solve the issue and get better. Communicate and support. Remember: Positive intent.
Process and Operations
- Problems and maydays / downtimes: I value transparency about what happened, what is happening, and what is going to happen. Within our team and other teams. We need to strive on making sure information is out there.
- I value speed, including proactive efforts that keep us moving quickly (e.g. writing tests, refactoring legacy code before a new feature, pairing on work to improve our code quality and bus factor)
- I value learning, and know that training up on a tech stack may not always be the fastest route to production.
- I value your time and don’t want you to do any process that is neither beneficial to you nor required by law, policy, etc.
- Informed decisions: As engineers we are pragmatic and empirical animals. We make decisions based on actual numbers, proven facts and tested results. Not on wild guesses or hunches. Win the argument with facts, convince others with proof.
- I strongly believe in Pair Programming, extreme automation and Rubber duck debugging
- Your manager: Remember that you don’t work for your manager, neither for me. You work for our company and our clients. It is ok (hell, it is encouraged!) to disagree with your manager and grow together. But also mind that after making a decision we can’t keep discussing forever.
The Traffic Light
Green, Orange, Red. Every often I will ask you where you stand in terms of happiness, ownership, energy and motivation. Green means that small things might be done but in general you and your team are good to go, if we continue the way we are, there’s nothing but good things to come.
If you are in the orange, it means if we keep this way, something is going to fail soon, we will ran quickly on the red.
If you are in the red, clearly we have to do something about it. The goal of this is not just to see where you stand on a given week, but also how it evolves over time. How many good and bad weeks we have and what we can do to improve it.
My References and how I got here
In my role today I seldom code. Perhaps at home when I get some free time between family, nature, traveling or playing different instruments. I just like challenges and being on top of what technology offers us every day.
BUT I’ve been a developer for a long time. My path started as a backend engineer in Java (with Struts. Go figure!). And moved through several circles of hell. Coldfusion, C#, PHP, Ruby, NodeJS, etc.). I’ve had my share as a Sysadmin and even a bit of UX and frontend. But then started taking more project and product management roles, Scrum Master ones and technical leadership positions.
I LOVE technology. I love geeking around with anything, from high level languages to low level assembler on Z80 PICs, building small microbots, etc. I also love teaching, specially kids.
This path took me where I am now, these are some books that I consider pure and clear references on how to be a professional developer (Note: I don’t agree 100% with everything they say in the books, my opinions change over time, and it is also fine if you don’t agree!).
- Clean Code
- The Clean Coder
- The Pragmatic Programmer
- The DevOps handbook
- The Mythical man month
- Tao Te Ching
- The hitchhiker’s guide to the galaxy (ok, this one might not be tech related 🙂
That’s it! All feedback is welcome. And by the way, we are hiring, so if any of this sounds interesting to you, ping me and let’s talk!