At the year 2018, I’d become a VP of Engineering in a small startup from a software engineer.
I’m writing this article to you who just started to lead an engineering team and you have no clue what to do and where to start. At the same time, I’m writing to myself.
As I was managing a 12-person engineering team, the advice in this article might not apply to the bigger team.
Clear communication
First and foremost, you are working with people, communication plays the most essential part.
To form a clear communication channel, you shall start documenting the conversation. When I say about documentation, it’s not recording every single word, instead, capturing the important information and actionable items.
At this stage, don’t worry about the format. Keep all the documents in one place and keep them updated. You’ll figure out the format in the future.
These are two good documents for a starter, product requirements document and meeting note.
Although it requires some portion of your time to write the document but the time you’ve spent is worthy.
Why product requirements document?
When the requirements are written down, it sets a clear expectation between stakeholders and engineers. It saves a ton of meeting to clarify the expected outcome.
Additionally, you can invite other teams or departments to contribute to the document. In this way, everyone will be on the same page.
Why meeting note?
The main purpose is reviewing the decisions that have been made and what has been done. Without it, you might let a certain amount of great ideas go into lost memory.
Effective and efficient workflow
Second, establish an effective and efficient workflow. Why bother mentioning effective and efficient here? I want to highlight that effective means it makes sense to the business or user and efficient means you can do it as least effort as possible.
Hereby, I recommend Gitflow which gives you a sense of the stage of the development and the control of the releases. Only the tested and verified pull requests will merge to the master branch and deploy it to the production.
Then, set up on-call rotation or dedicated role to provide technical support to the operation if necessary.
Mission statement
Third, mission statement. In the early stage, this is good to have. What’s the mission statement and why? The mission statement is one or two sentences summarise your team’s purposes and values.
Why this team exists? What does this team want to achieve? What values does this team hold?
Alright, why do you need this? A clear and strong mission statement gives your team a sense of belonging and responsibility. It tells everyone in the team how you treat each other, how you react to the problems and how you make decisions.
Fail fast. Fail again. Fail better.
Last, keep this in mind.
Try again. Fail again. Fail better. – Samuel Beckett
You won’t get everything right immediately. Keep improving. Furthermore, nowadays most of the information is right on your palm. Everything is happening lightning fast. “Try again” is not enough.
Fail fast. Fail again. Fail better. – Sky Chin
Whether you are running scrum or free flow with your team, I strongly suggest having a retrospective meeting. In this meeting, the simplest format is asking these few questions.
- What was going well last sprint/week?
- What was going wrong during the last sprint/weeks?
- What can be improved next sprint/week?
The retrospective meeting allows you and your team to allocate time to reflect on what’s working and what’s not. Continuous improvement is the air for growth.
Thank you for reading
If something works for you and your team but not appear in this article, please share it to me in the comment section below. I’m happy to learn from you.
