One of the very early challenges I hit in my new capacity as a Chief Technology Officer was that of reporting, in particular I had the following questions from the outset.
- Does a CTO have to report and why?
- Who does the CTO report to?
- How frequently and when should a CTO report?
- What should a CTO report and how?
- How long should I spend on reporting?
I began with common sense and experience mostly, answering them in a slightly more logical order that I thought of them at the time.
Note: It’s worth noting this article is focused on formally reporting up the chain of command within a company, I will tackle the arguably as important responsibility of reporting within the technical and support teams in a further article. Disclaimer: As I’ve mentioned previously I work for a relatively small company, however I believe the below should scale pretty well and should obviously be adapted to you and your businesses needs.
Does a CTO have to report and why?
Fundamentally the answer to this is a big bold YES. Within business of any nature communication and visibility is fundamental, if a CTO doesn’t report then assumptions and misinterpretations will ultimately be made resulting in uninformed decisions being made that will absolutely effect the business financially. That said, for reporting to be of value it needs to be tangible, targeted at the correct audience, reliably frequent and not impact other commitments of actually completing work, all of which is discussed below.
Summary: Yes
What should a CTO report and how?
I’m assuming we’re in agreement and you also feel it important to report? Ok, the killer question and what feels like an appropriate place to start is, what do I do that others want/need to know about? My initial thoughts were to include something like the following.
- What have my team achieved since the last report?
- What are we planning to achieve before the next report?
- What has blocked us/caused us issues?
- What else is in the longer term pipeline?
- Ability for the consumer to read on any device and for the CTO to be able to send from any device.
- Easily searchable for future reference.
- Simple to read and consume, no technical or connectivity hurdles to jump.
- Confidential by default.
- In contrast to the above, redistributable either in whole or part, as is felt fit.
Who does the CTO report to?
The simple answer is the Chief Executive Operator (CEO)/Director, at least within our company it is, but who else should I include, who cares?
Non-executive Director? – Yep, the majority of the time this should be high-level enough for him to keep in touch, he appreciates seeing what we’re up to and helps him to stay engaged with the business.
Customer Services Director? – Hell yeah, he can have some of this, in my role I work closely with the Customer Services Director and him understanding our technical progress and blockers is imperative.
That’s about it for me, it will absolutely differ for you, I do also CC in my Directors Admin/PA, just so she can glance over it and maybe spot any scheduling date clashes.
Summary: CEO/Director, Customer Services Director.
How frequently and when should a CTO report?
I felt, and still do, it to be incredibly important to maintain a predictable reporting cadence, I want those that receive my report(s) (see above) to know when they’re coming and never be dissapointed. So how frequently, daily? No way, way too frequent it would become noise in others life and would likely contain nothing of value. Weekly? This frequency seems right to me, not too frequent but enough time to report on completed tasks, conversely monthly or bi-weekly just wouldn’t cut it, we move far too quickly for that frequency.
So having decided on a weekly reporting frequency the next question was when to report? Beginning, middle or end of the week? This was more personal preference for me but I went with a Friday end of day, my reasoning was that we’re extremely busy during the early part of the week, I don’t want to be too busy to report and conversely I want to report on the status of that early part of the week, I also felt there to be much more chance of the reports being consumed by the audience on a Friday/over the weekend when peoples Inboxes are comparitviely quieter.
Summary: Weekly on a Friday.
How long should I spend on reporting?
Well certainly not as long as writing this article. During this whole process I had a good google around and came across numerous articles detailing a reporting process referred to as the 5-15 Report, the most useful of which was this. To paraphrase this technique requires the author (in our case the CTO) to spend no longer that 15 minutes writing his/her reports including only what is relevant. In turn the report should be able to be read within 5 minutes.
This approach appealed to me immediately and also included similar detail to what I felt I wanted to report on, further more it also detailed a number of further benefits, I quote.
“these weekly reports allow team members to communicate successes without feeling awkward, capture important lessons, demonstrate awareness of next steps, and alert you to setbacks without asking for support.”
That all sounds good, especially the piece about lessons learned, I felt it definitely worth capturing that within what we report, so my revised list of what a CTO should report became.
- What have my team achieved since the last report?
- What are we planning to achieve before the next report?
- What has blocked us/caused us issues?
- What else is in the longer term pipeline? – *On reflection I felt this was not really relevant to this report
- What lessons have we learnt, where can we improve?
Putting it all together
Below is the template I use when creating a new weekly report, credit to Gary Cohen as I have most definitely used some of his wording instead of mine. All in all I’m finding this method of reporting to be efficient for myself and my CTO, I’ve also received positive feedback of the frequency and reliability, thanks mostly to it being simple to compile. I find it helpful to create the report iteratively over the week saving as a draft as I go along, otherwise I find it almost impossible to remember everything I want to communicate come the end of a busy week.
Dear [name],
Please find below my weekly report.
Week ending: dd/mm/yyyy
Accomplishments for this week:
- [What have my team achieved since the last report as a bulleted list, a brief status of notable projects as appropriate, tie back to the priorities for this week that were detailed in the previous report]
Priorities for this coming week:
- [Exactly that, what are we planning to achieve before the next report?]
Challenges/Roadblocks:
- [What has blocked us/caused us issues during the past week, also use to raise any potential concerns]
Lessons Learned/Opportunities for Improvement:
- [What lessons have we learnt, where can we improve? Make these tangible, I often find asking for feedback on something concrete is more effective than open statements]
Regards,
<name>
I have also included a below an example CTO report with some sample content to show what I typically report. I’m still working on the level of granularity but we’re finding the below is about right for our purposes at present. Names/sensitive data removed.
Dear <name>,
Please find below my weekly report.
Week ending: 15/02/2013
Accomplishments for this week:
- Successfully completed the upgrade of all ESXi physical hosts with no downtime (bar a slight blip of 4 minutes) to clients.
- The Live environment performed well for all platforms leading up to Valentines. Comparing the week leading up to Valentines day with the previous week for Client1 (Google Analytics link removed) we can see we had consistently more traffic, peaking at 7,479 page views on Mon 11th Feb. We didn’t see any performance issues across the live environment for any clients during this period.
- We focused this weeks development work almost as a mini sprint. Mon-Wed was focused on Client1 and Thurs-Fri on Email marketing integration predominantly for Client2. We had some set backs with a couple of live issues and deployments but it seemed to focus all development effort effectively and we have some great output. This was adopted and tried in an attempt to reduce our WIP.
- The new milestones whiteboard in the office is proving to give us some nice visibility of upcoming commitments.
- Client1 status: SyncTool Upload in test, initial testing proving positive and <name> has documented this for clients reference (link removed), Complete end-to-end Product Feed integration in to ElasticSearch in Test, this has been running for the last 3 days and logging amendments in to the feed, we are continuing to verify and test and have a relatively slick repeatable installation process for this in to Live. The CyberSource Payment Plugin is integrated and enabled for the Client1 platform in Test. Live environment changes have been planned to free up enough storage to enable us to build the new search server.
- Email Marketing module (Client2) status: <name> has been working on the UI changes to add the additional buttons and grid columns (all feature switched). I have worked on initial API investigation and scoping along with setting up some standard templates with dynamic content within the Email marketing platform, I have some outstanding questions for <supplier> but in all this is ticking along nicely with no shock surprises. Relatively simple editor integration will be required early next week and we initially hoped to have this ready for internal test (Single Email Distribution only) by Tuesday, realistically this is more likely to be Wednesday.
- We met the new baby and she’s a cutie.
Priorities for this coming week:
- We have a scheduled maintenance window (4 hours) with <supplier> for late Tuesday 19th/early Wednesday 20th Feb to migrate the current over purposed SQL Server volume on our Live SAN to free up an approximate 400GB of usable storage space. I am also taking the opportunity to reconfigure how we configure SSL on each of the web servers to make out of load testing far easier. This is in direct response to the capacity review and plan of the Live environment that I presented to <supplier>. II suggest we get a generic notice out to alls customers.
- I am arranging a meeting with <supplier> for the w/c 25th Feb at our offices.
- We need to discuss and sign-off the quote from <supplier> for the additional RAM I have specified for Live environment hosts. This will be required to allow us to build the distributed caching servers for Client1 leading up to Mothers Day.
- Begin another small focused sprint to continue knocking off our WIP and give ourselves some breathing room.
- SyncTool sign-off and roll-out. This is so so close now and would hugely benefit all clients. Just need to “test” in Live against <link removed> now so we know all our bindings/routings are working well.
- Get feedback from Client1 on end-to-end testing, start making it look nice and understand what is missing functionally.
- Get the first cut of the Email Marketing module in to internal test.
- Phase in the Jira/Zendesk Basher role between the DevOps team leading up to <name> being away.
- Decide between ourselves which Microsoft exams for Silver Partner status we would like to take and purchase the training material as needed.
Challenges/Roadblocks:
- Unplanned work still bites us but we have done well this week to try and minimise that, apart from the Client3 issue early in the week, however we have learnt from this and <name< has put in a temporary fix to stop it happening again, particular thanks to <name> for protecting us all from a lot more distractions.
- We may soon reach the limit of the number of active free TeamCity projects we can have with the free version. This will ultimately incur an additional licensing cost of £1479 +VAT http://www.jetbrains.com/teamcity/buy/index.jsp. This is more a heads up, I expect it to hit us in the next 3 months or so.
Lessons Learned/Opportunities for Improvement:
- Feedback on the internal issue tracking decision tree, which I’ve added to the homepage of the wiki would be greatly appreciated.
- <name> and myself have continued planning for his holiday in early March and <name> has created a few wiki and Zendesk user guides in preparation for this. I woud like to see a report from <name> including commitments/milestones during that week provided to us in the week leading up to his holiday. This should also include any last minute brain dumping that may be required.
- We have discussed the idea of providing Enterprise clients with a custom test regression pack (or including it within the Platform), before we can realistically do this we obviously need the UserOps role filled which we have made good in roads to advertising for this week. Either that or we identify a test partner we can sub in, which may make more sense in the short term?
Regards,
Lloyd
