My Values, roughly
This is an adapted version of a blog originally post written by me in Jodel’s Engineering Blog.
When a company hires a new tech lead, their first order of business should be to communicate core values rather than plans or changes.
These leadership positions, by the very scope of their responsibilities, influence and impact many people and processes. Therefore, it is only fair that they start with a basic “Hi, here are some of the things I believe in and which I use to drive my action”. Values, contrary to action items or plans, have the advantage that they seldom change, and are therefore better predictors to how people will act.
Not long after I started as CTO at Jodel, I gave a presentation on my values and how I intend to build the Engineering team. Below is a distilled version of this presentation, with a few words about each value:
Strong principles, weakly held
I started by asking my team to retain at least this one thing – for me, everything is open to discussion. I hold no attachments to any opinion and in fact, I have changed my mind about many things in my career. Openness to change is a foundation in my values.
Product leads – Engineering builds
Product and Engineering work close together but each team has a responsibility over specific areas. Product teams think and plan what needs to be built, what features or experiences we do next. Engineering teams know how to build it, and what tech debt and improvements need to be done to reach Product goal. This is a relationship of trust which I value and try to defend.
I have a preference for working processes which are very lean and minimal, focusing on the team, the product and having just one or two rules capable of fitting in everyone’s minds. At the expense of less rules, less process gives more room for people dynamics and culture to emerge and take form, which is an important property when you want to give more ownership to your teams.
The Unix Philosophy, applied to teams
The Unix Philosophy refers originally to how to write system programs:
“Have programs do one thing and do it well; have programs work together; have programs handle text streams, because that is a universal interface.”
I believe the same principles can be applied to building teams, which goes hand in hand with a minimalistic process:
- Have teams do one thing and do it well – you can expect focus and accountability from these teams and they’ll more naturally take ownership for their work.
- Have teams work with each other and consume each other’s results – this makes their interactions and the flow of work between them easier to reason about; you can also compose them differently to generate more complex workflows.
- Have teams communicate directly, without intermediaries – relying less on rules and process to define interactions and communication rules, thus making teams more autonomous and independent.
Micro-Management considered harmful
I default to give my teams power and ownership over the things they are dealing directly with. My role is to set a strategic direction and define general boundaries to the path we’re walking, but the details and the tactical decisions are owned by the ones closest to the problems.
You cannot improve what you cannot measure
I am data-driven by default and I push this mentality in my teams as well. If there are no numbers, we cannot know that we have improved or what’s lacking improvement. This is true in Engineering when we talk about test coverage or amount of bugs or performance measurements, but it’s also true when it comes to process or team-related issues.
Your career matters
One thing we all have in common, even our CEO, is that for all of us there will be a future after Jodel – even if that future is retirement. And now is the only time you can do anything about your future. So you and your career are central part of my job. Are you solving the right problems at work? Are we giving you the right tools? Are you advancing in the direction you want for your future?
There’s a whole Galaxy out there
After spending some time pushing features to production, you should consider that other people may face the same problems you’re solving.
All of this helps Jodel, our community and the industry. All of this is giving back, which is important given how much open-source and free knowledge we base our work on. And all of this helps you and your career.
If you’re going to do something, you should give it all you got. From this, it follows that if you’re sick or not feeling well, you’re not capable of giving 100% – stay home and rest. It’s a simple rule and one I always insist on very hard.
Are you sleeping well? Are you eating well? Are you overworking? These are all questions we need to ask ourselves as they directly affect our performance. It is when you’re well that you’re performing the best – and that’s in everyone’s interest.
Problems instead of technologies
Many companies form around one technology and tend to become “Java shops” or “Node.js shops”. We have to look at ourselves as a “Problems shop”, striving to avoid the pitfalls of having our tools shape too much our thinking habits – when we focus on the problem, we learn many tools whereas when we focus on the tool, we only fix whatever our tool fixes.
Measure twice, cut once
This mantra goes beyond the mere statement that “quality matters”. It’s about making our work sustainable, producing iterable work which can be extended and retain value, questioning our assumptions and our proposals thoroughly; and when we commit to a solution, we aim at doing it only once.
DevOps and QA are Cultures, not Roles.
I think we are quite fortunate, the ones of us who have interesting problems to solve. But interesting problems usually affect things in different areas and require development, operations, systems and analytics skills; they need attention to performance, maintenance, reliability. For me, this is what DevOps and QA is – bringing skills and people together, avoiding silos and being more reliable at pushing work to production and maintaining it there. It’s a cultural factor in Engineering teams and one which I believe in quite strongly.
Hiring is the most important job you’ll ever have.
A lot of people (Joel Spolsky, Phil Calçado, Joel Spolsky again and Valve, on page 42) have said this better than I ever will. Perhaps it’s enough to say that I believe in it firmly and that this is perhaps the only topic where I like to keep some tight control. I believe in having a hiring process where there can be enough scrutiny by the team, with a lot of attention given to attitude and mindset, and with a bias for showing practical work and pairing. For me, these are essential properties.
All the things I haven’t mentioned
There are other things I value, and certainly in each of the categories above there’s a lot more to say. But I think these form a good solid base to build an Engineering team.