Interestimg piece by Jamal Mashal on how to use themes and timeboxes to create structure and focus in his work: Themed days, Timeboxing and why you should use them.
How can you successfully transform an organization towards more agile and lean ways of working? According to Jon Smart, by letting your people develop VOICE.
Amazon appears to have “Banned Powerpoint” or to phrase it a bit less clickbaitish: Made a heavily prepared agenda/discussion paper the core structure for meetings. Which I guess can pay off in certain settings by reducing time spent presenting, enabling more asynchronous collaboration and opening up - for better or worse - the classic 10 slides, 20 minutes, 30 point font structure.
In essence this is the continuation of only having meetings with a well prepared agenda I rooted for a while ago.
One cardinal misunderstanding burning teams, tanking projects and killing products since the dawn of software is the assumption that software development can be reduced to the aspect of producing code.
Software development is talking: Speaking and listening to peers, colleagues and stakeholders. Software development is thinking: Thinking alone by modeling data, testing abstractions, thinking through cases, thinking together by reading other people’s thoughts. Software development is typing: Writing code, but also: Comments, readmes, specifications, code reviews, tickets, mails, …
Overemphasizing one of these aspects or neglecting others is a sure fire way for personal all professional frustration.
A true treasure trove for remote leading and working: Stripes/Increments “Guide to Distributed Teams”.
Interesting how my main takeaway from Shopify’s write-up of a major refactoring - “Under Deconstruction” - is less about code and more about people.
As it is ultimately humans that produce code, refactoring a big code base is about changing code as much as it is about changing humans. Shopify used keynotes, guilds, handbooks and trainings to create “ability” and “motivation” to support the desired changes, only added “prompts” in the form of rules and tooling later afterwards. Without ability and motivation to act on them anybprompts are bound to fail ir worse followed superficially.
My second big take away is to understand (and ensure) value is created along the way and not only if and when a (maybe over idealistic) goal is reached. No product, no architecture, no code base will be perfect any day, but it can become better everyday.
Strip away the horribly misleading title and the accelerator grandezza and you get yourself some pretty solid advice for a successful and healthy career.
Neat piece on inversion as tool for problem definition and solution.
Recently stumbled into this five part series drawing on analogies between improv theatre and consulting work. Read it in one go, will revisit for sure. Highlights: Well, consulting as improv, “Yes, and…” as strategy for collaboration, capacity building as ths consultants roe, (as opposed to problem solving) and the power of an outsiders perspective.
Still wonderingvwhen your org will finally reap the benefits of agile? When you will get better value sooner, safer and happuer? This talk by Jon Smart holds a couple of really good pointers (Maybe skip the intro).
Leading a succesful team requires clarity - a leader communicating the framework for the teams performance, the vision, goals, rules and key parameters so they are easy to grasp and presence - a leader engaging, emphatizing with and enabling his or her team during said performance. David Tates Clear and Present Leadership provides a great backdrop to reflect, learn and grow in this regard.
“Managing humans” means getting two things right: The very big and the very small. Michael Lopp offers plenty of advice for both.
Often overlooked while staffing: Most people excel in very specific situations, some prefer to make, some to maintain. But projects/products require different skillsets througout their lifecycle.
“[At the start] it needs builders, pioneers who come up with clever ideas and execute upon them fast. They improvise … are opinionated [and] make their own decisions.”
“[Later] it needs a lot of incremental improvements, nitty-gritty […] details […] and a developer team which […] only needs some fine-tuning.”
Really good example from Oliver Eidel.
Classic presentation created by Sequoia Capital created in 2008 on How to survive a crisis. In essence: Get real or go home. I think I can get behind that, no matter the times.
How long since you have been in a bad meeting? A week? A day? An hour? Unfortunately it is really, really easy to botch a meeting, to make it the worst part of any given day for a whole group of people. Fortunately it is also not that hard to make it a positive and productive experience.
I greatly enjoyed reading “Craftsmanship—The Alternative to the Four Hour Work Week Mindset” and while disagree with the dychotomie of hacker and craftsman it supposes I think this is a pretty good distinction between and entrepreuneur and somebody that just dreams:
‘I didn’t know how to do x, so I just had to figure it out.’ This is what I regularly hear from successful founders, whereas ‘I couldn’t find someone to do X, so I had to reconsider whether to pursue it at all’ is a common refrain from unsuccessful founders.
A true trove of inspiration, open anywhere and find inspiration for everyday management work.
Equal parts auto-biography and corporate manifesto this book provides an interesting glimpse at what made the worlds hippest company with an ecological conciousness.
Communication is hard, technical communication is harder, technical communication under pressure is hardest, with these little “communication (design) patterns” it gets a bit easier.
Superstar biographies, genius interviews and parental anecdotes, might lead us to believe that success or failure in life depend only on us making the perfect choice at the perfect moment. Fortunately they are all wrong.