Most case studies are told in the third person, don't mention the client's name, and celebrate only the successes of the victorious consultants vanquishing waste and smashing sales targets. They leave out the inevitable mistakes and missteps of any project.
A large enterprising enterprise needed a re-engineered synergistic deployment system. CleverConsultants listened carefully, selected the right enterprise tool from SAPacle, built and delivered the system in record time, and now the fairies dance in the canteen with joy.
By contrast, you will find below personal stories that include both the wins and the losses, the great ideas and the experiments that failed, in engagements with a selection of my clients. The details are there, including the client names, and I encourage you to find out more from them about what really happened and where my strengths and weaknesses lie. I hope these tales are helpful to you in understanding what it's like to work with me!
Creating team focus and coaching senior leaders
Geckoboard's high-quality SaaS dashboard product was earning solid subscription revenue, but not increasing at the rate needed to meet the ambitious growth targets founder Paul Joyce had set. Worse, the development team was leaderless and lacked focus, communications and trust between the engineers and the rest of the company were poor and getting poorer, and progress on key revenue-driving projects was nowhere to be seen. Paul and I agreed a Transformation project, with my operational involvement for several days each week, would be a good way to achieve the turnaround that Geckoboard needed.
On my first day, I noted that a team of eight engineers was holding four standups and working on at least the same number of disparate projects. By my second day, we had a single standup; by the end of the first week, we had appointed a tech lead; by week two, I had helped Paul to develop a clear company focus statement; and by week three, we had aligned the entire development team to work on a single revenue-enhancing project—integrating with online spreadsheets like Google Sheets. The new focus quickly bore fruit, with daily releases and user tests giving us valuable and largely positive feedback about the utility and usability of the new features.
With the development work much better aligned to company goals and the team working productively, I turned to medium-term improvements to help make these improvements long-lasting. First, I trained the entire company in the principles and practises of Action Science, which substantially improved everyone's ability to confront difficult issues and jointly design solutions. Next, we began using the elephant carpaccio technique to provide value every day from releases to the live site, react faster to feedback, and provide "sanity checked" target dates for marketing and sales. Then we identified a set of metrics that we expected to improve with successive milestones in the spreadsheets project, and instituted a weekly review of progress toward these goals. Finally, I worked with the new team lead, who had never managed before, to take on new challenges like correcting negative behaviour, holding one-on-ones, and completing annual reviews.
As all this was going on, Geckoboard was intensively recruiting for a variety of technical roles. I sourced, filtered, interviewed, and helped decide on several of these hires. We were most successful in finding QA and back-end developer candidates, with four solid hires in six months. We were much less successful in finding front-end developers, with Geckoboard's high standards and cutting-edge technology severely (but correctly) limiting the pool of candidates. We even tried converting our existing back-end developers to front-ends, with zero success. I was unable to suggest sufficiently high-volume sources for efficient hiring of these skills and stepped back from driving this activity.
As the spreadsheets project reached maturity, we identified a new revenue-driving improvement to make—a re-imagined integration with Salesforce. We split the developers into two feature teams, with one continuing on final improvements and polish for spreadsheets with the first tech lead, and the other taking on the new integration under the leadership of an inexperienced but very capable developer. She led the team to build and release a version of the new Salesforce tools in just three weeks, with enthusiastic user feedback. We experimented with ways to keep the two teams communicating well and I continued coaching both managers.
In the final phase of the project, I significantly reduced my involvement, switching to Squirrel-as-a-Service and continuing to function as a coach and advisor. Paul and I agreed this would be a good way to ensure the engineering team was ready to function and grow independently.
The Salesforce lead decided management wasn't for her at this time, but one of the new hires had sufficient seniority and interest to take on this challenge from her, with my guidance in the new role. We identified some long-running conflicts and challenges in the business and used Action Science methods - now firmly embedded in the company consciousness and culture—to experiment with solutions, with varying degrees of success. The engineers developed and adopted new QA initiatives with noticeable improvements in developer efficiency as a result, and minimal oversight from me. And both feature teams took on new, challenging projects, carrying out design, prototyping, and build activities on their own with positive results for customers.
After just over a year of involvement, Geckoboard was ready to continue on its own, with solid leadership in place, new and evolving processes providing value, and a clear direction to profitability. In reflecting on the engagement, Paul said,
When Squirrel began working with us, the engineering team was full of talented and committed developers who lacked leadership and confidence. He helped to transform them into an energised, highly-focused team who now deliver high-quality product better and faster than I could have imagined.
Team restructuring, introducing CTO and Head of Engineering
In the run-up to Christmas 2015, the amazing personalised children’s book Lost My Name had rocketed to success, with the book in the hands of over a million children and its tremendous brand appeal driving the company to grow very quickly from a side project to an 80-person global operation. But the organisation of the company, especially of the engineering discipline, had not kept pace with its commercial growth. In particular, an experiment with Spotify-style squads of 3-4 people had led to some brilliant successes due to significant autonomy for employees, but also some spectacular wasted effort on unneeded or duplicative projects. Experienced technical leadership was lacking and the founders wondered whether a CTO, a VP Engineering, or both could help them get the direction right. They agreed with me that a Transformation project with my involvement 2-3 days a week would be a valuable way to make tactical improvements and choose a strategic plan for technical leadership.
On arrival in November, in the throes of the Christmas rush, I rapidly diagnosed three problems: a lack of accountability, poor information flow, and unclear goals for teams. We chose not to make big changes until after the New Year, but I did begin moves to shift some developers to part-time leadership roles and ran a workshop on effective 1-1s for managers across the company. The latter, on reflection, was not ideally timed, and perhaps it would have been better to do more basic training in management skills for the less experienced participants first. The company made it to Christmas with a successful selling season and everyone took a well-deserved break.
In January, the founders and I made several rapid changes to address the immediate issues:
The improved information flow and greater accountability had immediate effects: major roadmap projects like a revamp of the website "shop front", a rewrite of the rendering platform that prints the books, and a move into China were visibly prioritised over tactical changes. As these efforts encountered delays and problems at various times, we noticed an opportunity to improve communication further and introduced "cross-squad" sessions to co-ordinate work across teams, aiding stabilisation of these projects further.
At the same time, issues were becoming clearer at the senior leadership level. Producing the one-year roadmap was challenging for the senior management team, and a retrospective I ran for the group as a result helped us see that overlapping roles for two of the founders were confusing matters and holding up progress; they successfully worked out an improved and clearer relationship over the next few months that streamlined decisionmaking noticeably. Also, we agreed that a full-time CTO was needed to solidify the changes we had started in the development team, and we began the search for such a person.
The following months were marked by a series of difficult challenges. First, our new reporting mechanisms gave us an early warning that the rewritten rendering platform, critical to successful product launches later in the year, would not scale. The team reacted well, writing three new prototype versions in a week and choosing the most scalable one. A newly hired leader for the team arrived during this excitement and brought in strong project management to get the project back on track.
Next, we located and hired the new CTO - but he immediately ran into strong resistance to innovative ideas he wanted to implement quickly. I provided training and coaching that helped him use Action Science techniques like "joint design" that improved his suggestions and led to greater internal commitment among engineers for the new methods.
At about the same time, the head of QA departed, leaving a significant leadership gap, and we promoted one of the two remaining QA engineers to his role. In the face of some scepticism from all quarters, I asked developers to help the now-smaller quality team by adopting a more disciplined delivery process using a pre-deploy tick list, and by taking responsibility for their own QA, using the quality team as expert guides rather than as release gatekeepers. I promised to buy everyone a beer if this wasn’t working after a month - but I didn’t have to pay out, as everyone soon agreed the new processes were more efficient and effective.
Participating in these difficult events led me to undertake several initiatives to improve morale across the company, including a "stairway of love" to showcase amazing customer feedback, a "ship-it squirrel" weekly performance to celebrate delivery of new features, and even composition and performance of a company song.
By August, the company could feel the rush of Q4 coming, but the solid work of the previous six months was starting to bear fruit. The rebuilt rendering engine was working and live for one product, and it came with a rapid-feedback "playground" that made a significant difference to speed of development for product creators. New heads of business intelligence and infrastructure joined and, thanks to smoothly running teams and processes, we were able to begin getting really meaningful results from both teams quickly. And we introduced a new engineering group providing services to the marketing team, with a tech lead and product manager who instituted solid practises from the start and provided significant value, starting with the integration and support of a WordPress blog called Clever Ideas that took off like a rocket and drove loads of engagement.
An influential engineer who had been with Lostmy.name since the beginning decided to leave us in this period - but with the CTO ramping up and the rendering platform lead keeping that important project on track, this was much less disruptive than it would have been only a few months before. A crucial operational contributor, responsible for the legacy manual processes involved in maintaining and updating the company’s first book, also became ill and left the company, but we had begun transitioning and automating his work to others so there was no significant loss to progress - in fact we even managed to make a substantial revision to the book during the transition.
As Christmas drew closer, we began to prepare for the big selling season. We organised and ran a substantial load test to verify that the site would scale to very high early-December volumes - which it did, thanks to careful engineering and testing earlier in the year. The new infrastructure lead organised a clear and simple mechanism for handling incidents and outages, and I helped test this by running weekly "fire drills" in which we played out various failure scenarios across the company to exercise our recovery plans. As a result, we entered Q4 with confidence.
We organised a "quiet period" for Q4, with fewer live changes to keep the site stable, and the leadership and information-flow improvements from earlier in the year really began to pay off as tech leads and product managers carefully prioritised work and negotiated with other teams effectively. My focus shifted to coaching for the CTO and the rendering lead- the latter was emerging as a senior manager and has since been appointed Head of Engineering. In twice-weekly sessions, they got my advice on conflicts between development teams, revising organisational structure for new challenges coming after Christmas, and on improving their working relationship with each other. Action Science techniques were particularly helpful for thorny issues they faced in upward and outward management.
In contrast to previous frenetic Christmasses, the engineering team were calm and focussed. The "fire drills" paid off with rapid solutions to technical challenges, including an outage on Black Friday that required the co-operation of nearly every developer to resolve, but was so smoothly handled that one of the founders decided to live-stream video of the team collaborating to resolve the problem. The result was a remarkably stable site and rendering platform that handled all the Christmas load the marketing team could throw at it.
As we started to look to the new year, the senior leadership were much better positioned to negotiate and agree an annual product plan, and they selected an aggressive approach with many new product launches and experiments, facilitated by the improved e-commerce and rendering technology we had completed during the year. I helped introduce a "product variability scorecard" that let us see quickly how hard a new product would be to introduce in each affected area (design, web store, rendering, and printing), which helped streamline the selection and ordering of new product development.
With the new year plans safely under way and the CTO and Head of Engineering functioning independently, Lostmy.name and I agreed the project was complete. At the last all-hands session I attended in my transformation role, founder Tal Oron said,
Squirrel’s impact in just a few days a week was tremendous - not just in engineering, but in product, the senior team, and across the whole company. You can bring him almost any problem and he’ll write it down in his little notebook, then come back with a thoughtful solution. He made a huge difference every day at lostmy.name.
I speak and train regularly on software development and management topics. For example, recently I gave two conference talks based on experiences at Geckoboard - watch them below if you are interested.
I can offer talks or short courses on a number of topics—a sampling appears below. Please let me know if you would like me to speak at a conference or meetup, or if you would like me to deliver a custom half- or full-day course for your company or organisation.
Action Science is a theory of organisation and management that I find very helpful. It is especially appealing for those (like us engineers!) who prefer sharply defined, step-by-step methods instead of wooly exhortations and vague models. I use techniques like the ladder of inference and two-column case studies both in my own transformational work and when training founders, CTOs, and other senior leaders.