Hello there, welcome to the week!
We'll be pausing our weekly Bytes sessions over August, but keep your eyes peeled for some amazing panels and speakers after the summer, as well as some new event formats..
To all those taking a break - have fun, switch off and come back refreshed and ready to take on the world. You've earned it
Until next time
Andy @ CTO Craft
Reads of the Week
I received this question in the comments section of my piece on The Twin Anxieties of the Engineer/Manager Pendulum, and figured I might as well answer it. It definitely isn’t a question I’ve spent a lot of time thinking about or anything.
If you schedule little things first, you run out of time for the big things. If you schedule the big things first, then you can fill in with smaller things.
In a recent paper written by Nicole Forsgren and her colleagues, “The SPACE of developer productivity: There’s more to it than you think,” there is an irony that is hard to escape.
From our Sponsors
Engineering leaders often rely on gut feel, anecdotal data, and imperfect measures to gauge how their team is doing. Learn how software engineering metrics can help you ensure development and business goals are on track in your organization
About our Sponsors
Thanks as always to the amazing sponsors helping CTO Craft bring you resources like this newsletter, our events, community and more:
AWS, CircleCI, Code Climate, O’Reilly, Pentalog, Skiller Whale, The Software House, iTechArt, LinearB, Lohika, Albany Partners, 101 Ways, PGS Software, YLD, Steamhaus, Swarmia
Culture & People
This week I am going to share Telephone Game diagrams! Recognize any? If you enjoy this post, consider sharing it.
Reading offer letter legalese can feel like someone explaining the rules of a board game before you start playing. When it’s Saturday night and you’re sitting around the table with a group of friends, typically someone will say: “Just deal me the cards and we’ll figure it out as we go. The first hand can be practice.”
When I talk about Diversity, Equity and Inclusion (DEI), I’m typically coming at it from an angle of systematic change. The purpose of DEI, as I see it, is to dismantle a rigged system and move to something more equitable.
Tomas Vocetka thinks upskilling as a software engineer is the responsibility of both the individual and the employer.
Leadership & Self-management
Have you presented to company executives about a key engineering initiative, walking into the room excited and leaving defeated? Maybe you only made it to your second slide before unrelated questions derailed the discussion.
An in-depth guide to everything you should do in your first three months as a first-time manager of managers
If your teams are hiring, this should become one of your main priorities—after all, you need to make sure that your teams get the right talent in quickly. Get insight on how that’s going and make sure you receive regular updates:
One thing I’ve been doing a lot this year is thinking about how to ask better questions. It’s not a skill I’ve deliberately tried to develop much in the past so I spend a lot of time thinking about every single question.
What’s the biggest threat to your organization right now? A coming recession? The labor shortage? Geopolitical instability? Domestic political chaos? Supply chain disruptions? Inflation? Oil prices? The answer, of course, is all of the above, coalesced in the form of uncertainty.
If an engineer is going to hit the same friction again and again due to tech debt - it is going to demoralize them. So as important as it is to launch new features, it is also important that your Investment Portfolio is healthy - which is where tackling tech debt comes in.
Agile, Engineering & Product
I’ve frequently seen product thinking discussed in product management and user experience design contexts, but haven’t seen it applied to technical writing and documentation. And yet, by applying product thinking to documentation, we can write more useful, relevant, high quality documentation.
Enterprise Sales/Solutions teams see the world one customer at a time; Product/Development teams see cumulative market impact and aggregate technical demand. These are fundamentally in conflict...
Yearly software development plans are my favourite genre of fiction. In the fabulous world of yearly plans, product developers assume they know exactly what product they must build and how long each task will take.
I feel for all the Scrum teams that do the best they can to make their Scrum work, only to be obstructed by management. I have seen so many teams who understand the concepts of Scrum, and who are super motivated. They often improve greatly in the first few months.
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!