Git has now been a de facto tool for developers. It has powered the awesome adoption of OSS and was the second well-known project from Linus Torvalds.
One of the things I look out for when looking at a projects repo is the standard of the git commit messages. It can sometimes tell you a lot about the developer(s) and the culture of the project.
It is easy to not give a great deal or thought to the commit messages you add to commit your code. This is especially true when committing in a high frequency as highlighted in the xkcd cartoon:
Now while your code should be self-documenting, your git commit log should explain what was done and when. It can be used to provide context to the commits and should be read like a history book of your project.
But, sometimes in the real world, we don’t care enough or are in a rush. Commit messages such as the following (taken from a project I am involved in) offer no value:
If we take the first log entry, I have so many questions. What method? Why are we now returning an empty list? What was returned before? That line was all that was included in the commit message. There was no extra content providing any insight. In order for me to see what was done, I need to diff the change. That takes time and I will still not be any wiser on why it was done.
I am not going to rehash how to write awesome commit messages or why it is important. Chris Beams has written the only article needed on it and I try to follow his recommendations.
The impact is your git log becomes a useful resource. This is even more important when your project grows or people move on. Knowledge is power and as developers, we need to know why things may have been done in a certain way. Git log should be your answers.
The simplest way to ensure that it works as you expect is to return your strings in ISO 8601 compliant format such as:
This will parse a date or a date and a time correctly. All times are treated as UTC. The topic of time zones and offsets is beyond the scope of this simple post. But, if you need to return a time with an offset then you want:
This will give you a Date object with the time set to 3 hours ahead of the specified time.
It’s funny how often date time string parsing confuses even experienced developers. If you need a thorough reference then the best I have found on this subject is here.
If you know of some good references on this subject or have any thoughts then please share them with me via twitter or email.
Meetings kill creativity and your team’s ability to function.
There I have said it. Meetings are the bain of many team’s life. Daily stand-ups, full team meetings and full company meetings. Then there are the meetings that need two-thirds of your team to talk about that one upcoming button change. Everyone has seen the jovial conference call videos such as below.
Meetings slow things down. The fact of the matter is that employees need time and uninterrupted time at that to work. Breaking up their day for needless meetings results in a break in their mental flow. Not only does it break their flow it also makes them context switch. For developers, the cost of a 15-minute meeting could be between 30 and 60 minutes for each participant. Preparation and context switching away from a task and back again after the meeting. That is a lot of wasted, unproductive, time.
I have tried to structure the meetings on my team and at Open Energy Market differently. First off, constant communication between the relevant people is preferred to meetings. When meetings are suggested, I ensure only the minimum relevant people are involved. In addition, make your team responsible enough to make a decision rather than needing it to be made by committee.
The current schedule is based on a constantly reviewed feedback.
Development team meetings
No daily stand up calls or physical meeting. Yes, I know, we must be the worst Agile team ever. How can we not have a daily stand up? We do just via slack. I have written about this before and it just works for a remote based team. Try it and see if it could work for you.
Backlog review meeting. This is the only whole team meeting we have every week. The whole devops team join to review the latest stories and tasks created by the product owner. We talk through the stories and estimate story points. It’s honest and sometimes brutal for the PO and we will push back on anything we feel cannot be worked on. It’s held at 9 am (UK time) on a Monday morning. This is to prevent breaking anyone’s flow. The meeting is time-boxed to 1 hour or 1 1/2 hours depending on the volume of items being reviewed.
Team retrospective. Held on a Tuesday first thing every other two weeks (we currently run two weekly sprints). The whole team come together to answer the 3 main questions:
What went well.
What didn’t go well.
What can we do better.
We tend to use a virtual whiteboard to help with this meeting and keep detailed notes. Actions are checked up on in subsequent meetings. This meeting is also timeboxed to an hour but usually lasts about 30 minutes.
Weekly catchups. I have an hour one to one with everyone on the team. They are scheduled at either first thing in the morning or last thing in the afternoon. This is to reduce context switching again. The aim of the catch ups is to ensure that each of my team gets time with me. They get to provide a detailed update on what they have achieved in the past week and details of any blockers. They also just get to present idea’s and if need be, rant.
Any meeting instigated outside of the Devops team is evaluated about its usefulness. We generally push back on these meetings but they are sometimes not optional. So we limit involvement to the only those people required. Most of the time I will take the meeting and feedback the results to those on the team that need to know.
This is a trickier subject. As an early stage startup, you absolutely need to have an all hand weekly meeting. For us, being remote, this was even more key. It helped to update everyone on progress, wins, loses and vital information.
When your team starts to grow these meeting get much longer. That risks devaluing the usefulness of them. We changed the structure of our weekly meetings when we hit this stage. We made it that each team gave an update on a weekly rotation. This was very useful and meant that they stayed around an hour. Again as the team grew it made the meetings quite long. Meetings have to add value and 90 minutes for 25 employees does not do that. It become a real issue when we had to hold it in the middle of the day. It was the only time that would overlap 3 time zones.
Right now we have dropped the weekly all-hands meeting. We are looking for alternative ways to share and communicate updates. Slack helps with this especially as we have integrated it with our platform. We all get notified about trades, new users and retentions.
We maintain a yearly “kick-off” meeting. It is used to get everyone together in the same room (or rugby stadium in our case). We hold that at the start of the company year to set targets and expectations on the team. It works really well and we always see great results in the following few months. We will be doing a mid-year one this year to maintain the traction.
This is what works for us. But, I would suggest while it might not work for you, you should review the meetings that consume your employees time and mental energy.
I’d love to hear about how you run your teams meetings so please share them with me via twitter or email.
An old co-worker asked me the other day if I enjoy the relaxed and elevated position of CTO. This took me by surprise as I find my role to be neither relaxed or particularly lofty. In fact, I love the role as it is as varied and hands-on as a technical role can get. Then there is the business side (investors, marketing, HR etc). My days are never dull.
A lot of writing on startups share an important point about any role in an early stage startup.
You will never perform one single role.
Whether the Founder, C(EO/TO etc) or an early employee, you’ll take on whatever task needed to grow the business. I’ve read articles from CEO’s describing going from cleaning toilets into investor meetings. These stories are all true and relatable, especially in the very early days.
For anyone thinking about moving to the role of CTO for a startup, it’s worth evaluating what you want from the job. If you want to work on R & D all day while your team get stuff done, this role is not for you. If you want to sit and be the boss and manage a team, this role is not for you. If you want to build a company by developing something new and if you can create and execute the strategy to do so, then it may be the job for you.
Eric Ries stated:
“The CTO’s primary job is to make sure the company’s technology strategy serves its business strategy,”
I might go so far as to say:
“A CTO’s primary aim is to design and execute the technical strategy that delivers the business strategy while adding value to the company.”
That is pretty similar but adding value across the business is a key element of the role. Whether that is ensuring that product features go out on time or hiring the best team. It is usually by ensuring the application of technology is done right.
The role can actually be broken down into responsibilities:
Technical Strategy - Defining what technically needs to happen. What technology can be acquired or built to help the business deliver on its strategy and how you are going to do it.
Strategy Execution- Taking the above and actually executing and refining it. What’s your product look like and how will it be built. But also how technology is used within your company. GSuite or Office 365? Laptops or desktops? Could a particular technology (think AI, Blockchain etc) add real value? Can your platforms and applications integrate to enable your employees?
Evangelism - Be the public face of technology for the company. Intertwine yourself in all departments and talk to everyone. I do mean everyone as well. Promote internally as well as externally. If your staff are not excited about your technology how can you expect your customers to be?
How do you achieve all that? You end up adopting a lot of different roles.
Owning the Technology - This really is taking ownership of the design and executing of the strategy. Work with the business, listen to its needs. This is the business side in many ways. You will interact with many departments and the board. You need to be able to take what is being asked of you and produce a credible and innovative strategy. Once you have sign off you then need to nail delivering it.
Being the Chief - This is the hands-on part. In my experience, this covers everything from capturing the requirements through to ensuring the deployments are working. You will need to be a project manager, scrum master, technical architect, developer and tester in this role. You will need to have operational skills for the technology you are using to build and deploy your product. You also need to be a great HR manager as herding nerds is no mean feat. If you have good mediation skills for when different departments clash that will help.
I haven’t even scratched the surface of whats involved really in this role and I guess it does differ from company to company. I will definitely come back and write more about this soon.
I’d love to hear about your thoughts on being an CTO and the roles and responsibilities that you perform within it so please share them with me via twitter or email.
I was having an interesting conversation with my son about Alexa recently. He is 13 and his room is a trove of gadgets. I reminded him to be careful what he said near his dot as I would be able to find out from his phone what he has been saying. He didn’t realise and promised that there was nothing of interest for me to review.
I believed him … for now!
But, I’ve had similar conversations with various people about the home “assistants” available. Whats interesting is that no one that I speak to seems to understand how they work. That in order for the assistant to wake up when called, it has to be listening all the time. There is no magic when you call out ‘Alexa’ or “Hey Google”. The device has to constantly listen to spot the activation word or phrase.
The usefulness of turning your lights on or off is debatable. Instead, we should consider the hidden cost of that convenience.
I’d be interested to hey your thoughts on these assistants via twitter or email.