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.
A regular discussion I have with junior developers is about loosely coupled code. Why especially with .Net, it is important and the benefits it can bring. I cover test-ability, multiple inheritance and polymorphism. I instil the SOLID principles in them and offer guidance when reviewing their code. Developers sometimes say it feels like they are over-engineering a solution. I argue that experience has taught me that it will pay off at some time.
One of the biggest points of discussion is the Open/Closed principle and how it can be implemented in real code. Adhering to this principle can be done in many ways depending on the situation. Finding good teaching examples in your own project can sometimes be hard.
This week some code that I wrote 2 years ago finally generate a good example for me to use. It came in the guise of a service class that used an abstraction to retrieve a List<Model>. When developing the original code there were two requirements:
Create the list, pre-populate initial with data from the database and calculate the remaining fields. This data is then persisted to the database.
Read the previously calculated data from the database if it exists.
At the time I created two implementations of the interface to meet the criteria. I then used a Factory class to return the implementations as a SortedList. This was so that the Service Class could decide how to obtain the data. The Factory design pattern can be read up on here and here. The pattern’s goal is to allow code to defer instantiation of concrete objects to subclasses?
In our solution, we make use of the Ninject Dependency Injection framework throughout. While you can find extensions to create factories for your abstractions, I find it easier to use a factory class. You still inject your dependency’s into the factory. You then use them to create your concrete classes.
First off I defined the service interface
I then implemented the two service classes that I needed to meet the requirements. One to generate the model list and one to read the data if it exists in the database and create the models.
I then defined the factory class.
The implementation of the method is interesting. I used a SortedList return the concrete service implementations. This way I can state the order in which the client code transverses the services returned.
The service that wants to get the data call’s the factory’s GetPrioritisedServices(). It iterates over the services calling GetModelListFor(customer) method on each service. Once it obtains data it exists the loop.
The reason that this code becomes a great example was due to an extra requirement. We needed to be able to generate an example list of data based on some hard-coded values. The developer assigned to the work proposed a couple of different ways of making the change. Each involved making changes to the service class to generate and process the fake data through the workflow. I showed them that there was no need. That the abstraction was still open for modification without having to change it.
We created a new IService derived class. We implemented the hardcoded data in the GetModelListFor() method. We generated a dummy partial list which can be used as a basis for the existing calculations. We then updated the factory so that it returned the new service.
A nice simple solution which didn’t involve any changes to the service class. The solution isn’t quite right as the subsequent conversation with the developer showed. It would be a worthwhile change to actually have the factory use reflection to create the services based on the abstraction. This is a change that is now being made.
I’d be interested to hear your thoughts on this approach with suggestions for alternative ways to achieve the requirements. Reach out to me on twitter or email.
Stand-up, Huddle, Daily Scrum - so many names for such a key meeting in an Agile teams process. Wikipedia describes a Stand-up meeting as:
“A stand-up meeting (or simply “stand-up”) is a meeting in which attendees typically participate while standing. The discomfort of standing for long periods is intended to keep the meetings short”
The aim of the daily meeting is to communicate progress, plans and obstacles. Nothing more. They should be focused and managed (usually by the scrum master).
But, forcing the team to stand to keep the meeting short means that the Stand-up is not always effective. I have endured some horrific stand-up meetings caused by a particularly grumpy developer. They used the meeting to moan about everything from the requirements to why a vendor had changed an API. The person running the meeting was too weak to deal with the developer. The situation wasted a great amount of time on that team. I have also worked on a team that made the meeting too short. No obstacles were discussed during the meeting. They were always taken offline. That meant that communication suffered as did knowledge transfer.
Once you have a remote team across time zones things become even more interesting. At Open Energy Market we have decided to conduct the daily update meeting via Slack. We have created a channel specifically for the updates. Each team member has until 9:30 (UK) time to provide their update. It follows the same requirements as a standard daily scrum; what was achieved yesterday, what do you plan to achieve today and what (if any) obstacles are blocking you. We have added what did you learn yesterday to the criteria as well. I have found this method works very well and encourages some useful discussions.
Have you used different approaches to Stand Up meetings? What is your experience on differnt teams? Message me via twitter or email.
One of the challenges in running a remote team is finding ways to enable and encourage team bonding. With employees across the globe, it is hard to get everyone together regularly. If you do not encourage the team to interact socially then it is easy for team members to feel isolated.
Up to 65% of remote employees report that their teams only discuss project work.
These activities should not be mandatory as not all employees find them appealing. You should aim to run a few in parallel to cater to as many employees as possible. There is no limit on what you could try especially with the magic of video calls and Slack.
There are a lot of ideas on the internet such as:
Virtual Coffee Break. Arrange a time for a virtual call where team members connect from their local coffee shops. The aim is to discuss their personal lives, sport, entertainment or professional topics. You discuss anything but your project over your favourite brew.
Knowledge Sharing. Start a book club or arrange lightening talks to teach your team about new tools or libraries. These shouldn’t be about things directly relating to your project.
Fun Slack Channels. Pictures of your pets, film quotes, Dad jokes or selfie channels.
Board Games. You can arrange leagues and tournaments for games such as Chess, Drafts or Monopoly.
Team Lunches. Like the Virtual Coffee Breaks but you arrange to all meet up while eating lunch together. You can take this further with sharing recipes and agreeing to try each others.
When Ben, our new Head of Product joined Open Energy Market he suggested a music sharing exercise to bond with the team. On a Friday each team member gets to submit 2 music tracks on our team Slack channel. Once all the submissions are in then the team votes for a winner and Ben adds the winners to a Youtube playlist. There are no prizes. It can get quite competitive with some team members (in a fun way). It has become a staple of our week and for a music lover, it’s a great way to discover some new artists. There is a suprising mix of artists and genres for such a small team.
For anyone interested I have created a Spotify playlist of the submissions which I update each week.
I’d love to hear about your team’s approach to team building and bonding so please share them with me via twitter or email.