Back in the day, when I was a small kid, I had asked my dad a simple question. What did help him to grow his career the most? Born in the late 1950’s and closer in mindset to boomer, he replied – efficiency and organization. He also told me there might be people more talented than you, there might be people with better connections, but being organized will play a major role to make you stand out.
I did not get it at the time. Neither did I get why, each time I got behind on maths, physics or science, his approach was rather simple. Do another 1000 examples. Just train. Get yourself to understand patterns and just knock them into your brain. Each time you create a pattern you just apply, you are saving time. And this was his answer rather than trying to comfort me on the fact that I just don’t get it.
And so here I am 30 years later, agreeing with my dad. I have seen multiple things come and go, but businesses still need organized and efficient people.
This got me to ask a question. What does it mean to be an organized software engineering manager?
Is it making checklist in excel? Is it tracking time and micromanaging each engineer in my team? Is it just keeping things clean on my desk? Or is it having clear goals and mission?
These and many more questions flew and rattled in my head. None though seemed like the right questions to ask.
In the end it came back as doing whatever will save time on discussions and ambiguity in the team. A standard.
This resulted in me asking myself the 5 questions below to check if the team I am managing is organized.
Do I have an agreed JIRA ticket template?
Setting expectations for each ticket proven to be a great weapon removing a lot of ambiguity. The typical sections I’d recommend are – context, acceptance criteria and a set of questions you should ask while refining it. It should be built by the team and modified by the team each time you learn a new lesson. Tough just having that format helped me a lot in making the requirements smaller and clearer.
Do I know what is my service standard?
Documenting and even codifying (via tools like cookiecutter) your service standard is vital. Again a task for the team to agree on and extendable in the future, but should cover things like – which libraries to use, service composition (ECS vs lambda vs k8s pod, etc), alerting, logging, exception handling, etc, etc. Then each time you start a new service or need to update an old one, you know what needs to be done. The ambiguous discussions on how we build or maintain a service is removed.
Do I document the code first?
The stories of self-documenting code and living documentation are fun to read and amusing. Though they rarely answer the questions like why it was built this way or what was the original business requirement. Sometimes, especially in microservice architectures they fail to answer on what’s the actual place of a component or a bit of code in the bigger picture. Documenting code first and sharing these are vital parts of work of a software engineer. Lack of documentation is a common concern. Making your documentation live and change with the code should be your ultimate goal.
Is my week organized (meetings, coding time, leisure time)?
Many software engineers complain about meetings. Few actually do something about it. Like pro-active communication and setting expectations when they will be available and when not. Engineers are not natural time-managers and planning patterns of team ceremonies, focus time, leisure time and optional meetings is vital. Mainly for them to learn how important effective time-management is.
Is my team’s wiki clear and in order?
Can you imagine what would happen to an external library that you are using, which would have outdated, scarce or plain unusable documentation? It wouldn’t be used. So why do we fail to maintain the internal documentation? It serves the same purpose, but for users within your organization. Keeping this documentation, especially removing false information is vital. Future self will thank you.
All of the above was done with a simple intent. To answer the question: What are you doing to make life easier for people, who will take on the tech stack you are managing today, once you leave? with a yes.
For every minute spent organizing, an hour is earned.
Benjamin Franklin
I have noticed that after codifying the above standards with my teams, the efficiency went up. Minimized the amount of discussions on ‘methods we should vote on to decide which method we will vote with’.
In terms of my dad, getting organized first, got him into beating people who spoke foreign languages better or knew more. And eventually led him to managing director positions. It still helps him today.
And instead of a video today, a few good tips on how to write better JIRA tickets:
1: Use precise language
2: Acceptance criteria should be a true/false statement.
3: Make your features as small as possible, and no smaller.
Gustaw Fit 