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.
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.