13 min read

🪲 Social Cohesion, DevEx Surveys, Manager Blindspots, Real 10x Developers, Software Quality, Splitting Stories, Heroism: TMW #386

What we're currently reading, and events happening this week!
Thanks to DoiT for sponsoring this issue of Tech Manager Weekly - technology and cloud expertise to buy, optimise and manage AWS, Google Cloud, and Microsoft Azure with ease.

Hello, hello - it's Monday all over again

If you're in London, you'll want to join us for our next in-person CTO Craft Bytes event, in partnership with our friends at Softwire. We'll be inviting some experts to chat about the right way to build a strategy around AI, where to invest, risk management, and much more. You'll also be able to meet and network with a bunch of CTO Craft members. Details below:

CTO Craft Bytes: Investing in AI - Opportunities and Pitfalls for Leaders
Over the course of the evening, we will delve into strategic investment opportunities across industries, discuss risk management strategies to navigate potential pitfalls, and share insights on future-proofing your AI investments in a rapidly evolving landscape.

Tickets are still flying out for CTO Craft Con: Berlin in September - don't forget to use the code Community-Berlin-24 to get the community discount.

That's it! See you next week

Andy @ CTO Craft

PS: If you know anyone who'd benefit from getting a huge batch of reading material in their inbox every week, please do point them at TechManagerWeekly.com!

CTO Craft Events

CTO Craft Con: Berlin | 24th - 25th September 2024
CTO Craft Con will bring together hundreds of Chief Technology Officers and other senior technology leaders from the most exciting start-ups, scale-ups, unicorns, and big tech companies to elevate their engineering culture in Berlin, Sep 2024
CTO Craft Roundtables: London
Welcome to the launch of our newest event: CTO Craft Roundtables! Join us for a half-day of engaging discussions and networking opportunities designed specifically for CTOs and engineering leaders
CTO Craft Mixer: Bristol 2024
Join our community of CTOs and senior tech leaders for another insightful and interactive meet-up in Bristol.

Reads of the Week

In-Depth: How Social Cohesion Shapes Teamwork And How To Improve It
Do you remember the best team you’ve been part of? What about that team made it the best team for you? Chances are, your list will include…
Measure Developer Experience Using Surveys: Step-by-Step Guide - Dr. McKayla
Learn how to design a developer experience survey in this step-by-step guide, including concrete survey questions.

From our Sponsors

Generative AI on AWS: ebook

Companies are diving into GenAI, but the hype is surrounded by a vast learning landscape.

With this ebook you'll master the AI project lifecycle, from choosing use cases to deploying cool models and more!

Download the ebook

Leadership, Strategy & Business

The Strengths, Weaknesses and Blind Spots of Managers
Discover the difference between how managers think they are leading their teams and how employees say they’re being managed.
The 10 Most Common Mistakes of First-Time CTOs, #3 and #4
I’ve made most of these mistakes myself, and see people following the same path over and over. Don’t let these mistakes limit your ability to have impact in this role.
Tech Executive Alignment
In another effort to open the kimono, here is another key part of effective executive coaching. Many tech leaders find it hard to decide what behaviors they should be working on personally. One dia…
Mastering Change Management
Balancing Operational Demands with Employee Well-being for Organizational Success

Culture, People & Teams

The real 10x developer makes their whole team better - Stack Overflow
The route to better culture? Better managers
Workplace survey says work is lonely, stressful & disconnected
TBM 294: Close the Loop. Stop the Drift
Great/healthy teams: Don’t let problems fester. Close the loop on open questions. Integrate perspectives, code, insights, beliefs, etc., often. Put in the time to foster shared understanding. Address dissonance head-on. Limit the number of “open threads.”
The Fatal Flaws of Outdated Team Decision-Making Methods – Scott Cochrane

Technology, Operations & Delivery

How to create software quality.
I’ve been reading Steven Sinofsky’s Hardcore Software, and particularly enjoyed this quote from a memo discussed in the Zero Defects chapter: You can improve the quality of your code, and if you do, the rewards for yourself and for Microsoft will be immense. The hardest part is to decide that you want to write perfect code. If I wrote that in an internal memo, I imagine the engineering team would mutiny, but software quality is certainly an interesting topic where I continue to refine my thinking.
SPIDR: Five Simple but Powerful Ways to Split User Stories
One of the most common struggles faced by agile teams is the need to split user stories. I’m sure you’ve struggled with this. I certainly did at first. In fact, when I first began using Scrum, some of our product backlog items were so big that we occasionally opted for six-week sprints. With a bit more experience, though, that team and I saw enough ways to split work that we could have done one-day sprints if we’d wanted. But splitting stories was hard at first. Really hard. I’ve got some good news for you. Not only have I figured out how to split stories on my own, I’ve learned how to explain how to do it so that anyone can quickly become an expert. (Want a peek behind the scenes at real user stories from some of my early product backlogs, complete with commentary about what I’d do differently today? Download 200+ User Story Examples) What I discovered is that almost every story can be split with one of five techniques. Learn those five simple techniques and you’re set. Even better, the five techniques form an easily memorable acronym: SPIDR. I introduce each technique below, and the video shows them in action. SPIDR Technique for Splitting Stories A few years ago I was creating the Better User Stories course. Because this course would cover everything someone needs to know to work effectively with stories, I knew it needed a module on splitting. To create that module, I printed out over a thousand user stories I’d collected over 15 years. For each story, I had the original story and the sub-stories it had been split into. I taped each story onto the wall, grouping them based on how they’d been split. I was looking for the common approaches used in splitting all these stories. I went through a variety of groupings, trying to find the smallest set of approaches possible. I knew it would be easier to remember 5 splitting techniques rather than 20. The five I ended up with form the acronym SPIDR–S, P, I, D and R–spider without an E. Let’s take a look at the five splitting user stories techniques that make up the SPIDR acronym, with examples of how your team might use them. 1. Splitting User Stories Using a Spike S is for Spike. That’s one most agile teams are familiar with. A spike is a research activity a team undertakes to learn more about some backlog item. Spikes can also give teams the knowledge they need to split a complex story. Think of it as a research activity, but it may include prototyping or some experimental coding. During a spike a team isn’t trying to develop the new functionality, instead they are developing new knowledge that will help them develop the functionality later. Take YouTube for example. Go back in time to when YouTube added automatic captioning. The team doing that might have faced a build vs. buy decision. Do they use some commercially available software to generate the captions? Or are their needs so unique that they need to develop something from scratch? The way to settle that would be a spike to test out one or more commercially available captioning products. Extracting a spike makes the original story smaller because some or all of the research included in the original story is removed. This is absolutely an essential way to split stories. So extracting a spike is one of the five splitting techniques you should use. But normally it won’t be the first technique you’ll reach for. 2. Splitting User Stories by Path P is for Path. If a user can do something in multiple ways (for example, paying with a card vs Apple Pay), that’s a great area for splitting. To split a story by paths, look for alternate paths through the story. Sticking with YouTube, let’s use the story, “I can share a video with my friends.” When I click the “Share” button in YouTube today, I’m shown 14 buttons I can click to share directly to various social networks. I’m also shown a link I can copy. And I’m given the option to customize that link to start playback of the shared video at a specific time within the video. That’s 16 different paths through the “I can share a video” story. I don’t know that this story needs to be split into that many smaller sub-stories. That’s for the team to decide based on the effort involved. But, with the path technique alone we’ve identified 16 paths through the original story. 3. Splitting User Stories by Interfaces I is for Interfaces: Splitting your story by browser, or hardware, or delivering a complex interface in iterations. An example might be delivering a version that only works in Chrome this iteration, and saving Safari for another iteration. In other cases, splitting by interface means creating a simple version of the interface and a more involved version as separate stories. This usually applies to the user interface. Applying this to our YouTube video sharing example, as an alternative to splitting that story by paths, we could have split out a basic sharing story like, “As a video viewer, I can get a URL I can share.” This could be implemented with no user interface other than a share button on the video page. The popup with the 16 different ways of sharing wouldn’t be needed if the only way to share is with a URL. A subsequent story could be, “As a viewer, I can share a video to various social media sites.” This could be done with a very simple user interface at first–no fancy scrolling through a list of logos, maybe just a dropdown list of text with the names of the social sites. The final story could then be something like, “As a viewer, I can choose the social network to share to by scrolling through a list showing the logos of each.” Splitting by interface works because the ultimately desired feature can be built up to by progressively more detailed, and better, interfaces. 4. Splitting User Stories by Data The D of the SPIDR acronym is for Data. To split a story by data, consider whether you can deliver value in an iteration by simplifying or restricting the data that’s supported. Perhaps you can do an initial version of a story that processes only a subset of the data that will ultimately need to be supported. For example, don’t allow negative bank balances in the first iteration. Add support for those with a different user story in the next iteration. Returning to the YouTube example, YouTube allows you to upload a video in any of 16 different file formats. If we’re building a YouTube competitor, screw 16 file formats. Let’s start with 1. We’re going to support one type of data. All uploads need to be in MP4 format for now. We’ll add all the others later as separate stories. Splitting by data is an effective approach. Often there are a few types of data that add a lot of complexity. Well, do an initial implementation that ignores the more complex data. Get that working then add support for the more complex data. You probably can’t release the simpler version but you can still build it in that order. I worked on a human resources system that did exactly this. The system tracked who the manager was for each employee and would do things like route time off requests to that manager. Most employees have one manager but some employees had multiple managers. We needed to support having multiple managers but some stories were simplified initially by assuming each employee had exactly one manager. 5. Splitting User Stories by Rules R is for Rules. Temporarily relaxing support for the rules that a story will ultimately need to support can make large stories smaller. Sticking with YouTube as an example, YouTube has some strict rules around including copyrighted music in videos. If we are building a competitor to YouTube, our team’s first story will be, “I can upload a video so that others can watch it.” That story probably sounds simple but there’s a lot to it. So in the first iteration, let’s ignore the rule that videos can’t contain copyrighted music. We’re not announcing our new YouTube competitor to the world after only one iteration anyway. We’ll have plenty of time after this first sprint to comply with our internal rule about not allowing videos with copyrighted music. As another YouTube-related example, suppose we want to prevent certain text from appearing in comments. That could be swearing or maybe SQL commands that could be a hacking attempt. Great idea: let’s protect our users and our system from this type of text in comments. But an initial story of “As a user I can enter a comment on a video” can ignore that rule. Doing so makes the story smaller so that it can fit within an iteration. And support for the rule can be added a couple of iterations later. Getting Better at Splitting Stories Getting better at splitting user and job stories is an important skill. With the short iterations used in agile, it’s helpful to have small units of work. The five techniques we’ve covered here–splitting by spikes, paths, interfaces, data, and rules–should allow you to split any story. The SPIDR techniques are easy to remember but putting them into action can require a little training and a lot of practice. That’s why I put together a Better User Stories video course that includes the SPIDR method for splitting stories, and a whole lot more.
No known bugs
How the principle of “no known bugs” works in practice
How Activity-Based Plans Differ from Deliverable-Based Plans - Johanna Rothman
In a recent conversation, I realized that very smart and experienced project managers do not always know the difference between activity-based plans and deliverable-based plans. While activities might result in an interim or internal deliverable, activities do not result in a user-focused deliverable. The team might make some progress, but not progress users can see. […]

Stress, Wellbeing & Growth

I am not a fan of heroism in the engineering industry
📈 Long-term good work > 📉 short spikes of great work
Identify — and Develop — Your Natural Strengths
When we think of self-improvement, we tend to focus on our weaknesses. But that means we often underestimate our strengths — or even don’t recognize them at all. In this article, the author explains why we’ve developed this focus on weakness, and she then lays out a program for identifying and developing our strengths, with a particular focus on natural abilities that we might take for granted and therefore overlook.
How To Start Mentoring?
Mentoring Made Easy: A Beginner’s Framework for Success
From Burnout to Breakthrough: How I Transformed My Developer Workflow with One Simple Change
Discover how to overcome developer burnout with simple workflow changes that boost productivity and well-being.

That’s it!

If you’d like to be considered for the free CTO Craft Community, fill in your details here, and we’ll be in touch!


Please do remember to share this link if you know of anyone who’d like to receive TMW:


Have an amazing week!