Weeknotes 2024 W16: Why

April 15​–​21, 2024
2700 words

Quick bits:

Last week’s week­notes, Week­notes 2024 W15: String of bad luck, elicited some questions. It makes sense to elaborate on a thing or two. But perhaps more importantly, I want to elaborate on the healthy ways in which product managers and software developers can get stuff done together.

Answer the “why.” At the start of a project, it is critical to identify why this project exists. It can be a problem or need, or even an opportunity that can be taken advantage of.

For example, “we need a central place to track the status of to-do items across the platform, because our customers keep losing track of what they need to do.” Straightforward and easy to understand.

It is critical that software engineers know this “why,” too.2 Otherwise, there is the risk of building the wrong thing. It’s demotivating to not know the “why,” too. You cannot make progress towards a target if you do not know what the target is.

Some software developers can work without the “why.” But if you, as a software developer, don’t know why you’re doing something, then… why are you doing it at all? Some developers work 40 hours a week just to get the paycheck. There is nothing wrong with that per se, but I’m not a developer who can chug through task after task without knowing the motivation behind it all.3

Worth pointing out that I use both the term “product” and the term “project,” but these are not interchangeable: a project is not a product. A project is time-limited and has end goals, while a product exists for an indefinite amount of time. The distinction can be subtle, though: it is a project to create the first version of a product.

Find the stakeholders. List every person and team who could be involved of affected by this project, and figure out what their involvement needs to be.

There are a few semi-formal approaches to this, such as RACI (Responsible, Accountable, Consulted, Informed) and DARE (Decide, Advice, Recommend, Execute). The precise approach doesn’t matter too much, as long as all the right people are involved.

Include people and teams who will possibly be impacted, even if they don’t (shouldn’t?) have a say in the project.4 It is much better to over-communicate than to say too little or leave people and teams out of the loop.5 Surprises are bad — avoid them!

Involve software engineers as early in the process as possible. Technical feasibility can only be assessed by engineers: whether an implementation takes 4 hours or 4 weeks, only software engineers will be able to tell.6

Clarify responsibilities. It’s often clear who works on what, but not always. In my experience, responsibilities can be remarkably fluid in newly formed teams and startups. This is all fine, as long as the expectations are clear.

While I describe myself as a software developer first and foremost, I’ve done other work, too. Among other things, I’ve done UI/UX and design work,7 technical writing, Linux system administration, and product management. Product management is fun and rewarding, and I think I’m rather good at it!

But before I go beyond my usual remit, I clarify what responsibilities I can and should take up. Sometimes, it’s clear right off the bat: if there is a product manager, then I obviously don’t take on product management responsibilities.8

Even when sticking to software development, I thrive on vague requirements. I’m much more happy to work on general problems rather than specific tasks. As is true for many people, I don’t do good work (nor am I very happy) when I am being micro-managed. It gives me the freedom to explore the problem space thoroughly, and end up with the best possible solution for the given problems.

Sometimes, it can be worth re-evaluating and reassigning responsibilities. If things aren’t working well, consider changing the responsibilities of the people in the team, bringing in people from outside, or (as a last resort) handing over the project.9

Define the priorities and the scope. It is frequently the case that there is more stuff to do than there is capacity. Find a way to order everything to do by priority10 and use that to scope the project to what is realistic.

This approach helps to arrive at a finished MVP (minimum viable product) quickly, and allows iterating to build an increasingly refined product. Shipping fast is useful: a product is only useful if it is in the hands of a customer.

As with anything, this approach also helps with communication. Critically, it sets clear expectations. And speaking of communication — 

Keep communication as the top priority. Communicate proactively and openly.

Communicating proactively means sharing information when it becomes available, rather than only when it is asked for. (You can’t ask for information if you don’t even know it exists!) Weekly or even daily status updates are helpful.

Communicating openly means sharing information with as wide a group of people as possible.11 Keep Slack channels public.12 Make meeting notes accessible to anyone. Have discussions in the open. Make decisions in the open.

Communicating proactively and openly can create a remarkable amount of synergy, massively reducing waste, increasing velocity, and improving overall happiness.

That said, an environment where communication is proactive and open requires a great deal of trust. In an environment where what you say can be used against you — an environment without trust — having open communication can be counter-productive in the short term. But in the long term, having private communication channels to satisfy the need for “safe spaces” is unsustainable. Open channels must be safe — and this is one of the most difficult changes to bring forth. (I’d love your thoughts on this one.)

Don’t compete and deceive, either. There is only one company; competition between teams does not benefit the company.13

With all that said, I want to talk specifically about this failed year-long project for a bit. Why did this project fail so hard? I’d like to present a few reasons — for entertainment purposes only, mind you:

I don’t think any of these takes come very close to the truth. As I said: this is just for fun. I’m most partial to take #3, because I love stories with political intrigue, conspiracies, and subterfuge.

Still, I would’ve loved to have an inkling of honesty on this project. I am still thoroughly in the dark as to what really went on.

Fiction writing is hard, man. I’m keeping at it, but occasionally I want to throw up my hands in the air, give up, and get rid of everything I’ve ever created. Throw it in the trash. Empty the trash. Delete all backups. Run all the paper on which I’ve done long-hand writing through the shredder, and then burn the shreds.

It feels like the writing is not just bad, but it is the worst writing anyone has produced in the last century. It’s not just the writing that’s bad; my lived human experienced are bad, irrelevant, fake.

But of course, I rationally know that this isn’t true. Judging from what other writers have said, this conflict is something that is bound to stay with me forever, and I’ll have to learn to deal with it.

Then the next day, everything is just fine again, and I continue writing (or start something new). Everything is fine, as long as I don’t think about what I want to achieve with it, and as long as I don’t compare myself to others. The idea of being published? Terrifying.

The last thing to which I applied my fiction writing skills is a reworked “page not found” error page. It was fun to do, because writing is fun, especially when it’s pointless.

Entertainment:

Links:

AI links:

Other tech links:

  1. Anne Lamott, Bird by bird: some instructions on writing and life (New York: Anchor Books, 1995). ↩︎

  2. This is already where the trouble, described in last week’s week­notes, started. I never knew the why of this year-long project — and nobody else at the company seemed to know either. So why was this project so important? … exactly! ↩︎

  3. I wrote about something similar in Week­notes 2023 W37: Preferring problems. ↩︎

  4. It was quite the unwelcome surprise to find out the sudden introduction of Salesforce as the new source of truth: a decision made unbeknownst to any of the most senior software engineers. Should En­gi­neer­ing have a say in this decision? Not necessarily, but we weren’t even aware until the decision was already made. ↩︎

  5. A success story: one time, I was approached by an engineering manager who informed me that it was likely that a product would eventually fall into my lap. I quite appreciated this: before any decisions were made, and even before it was clear whether or not my team would be involved, I was already fully in the loop. A+ communication! ↩︎

  6. As much as I love Star Trek, it has had a negative impact on how people believe estimates work. It’s the typical interaction: someone in En­gi­neer­ing states “it will take 4 days” and the captain responds with “you have two hours.” In­ev­i­ta­bly, En­gi­neer­ing will get it done in two hours — but people forget that Star Trek is fiction. ↩︎

  7. It is flattering to receive the question “What template do you use?” about my web sites. I design them from scratch myself! ↩︎

  8. This year-long failed project had a product manager who shirked their responsibilities of defining the product vision. I couldn’t take up the role of a product manager myself, because I was forbidden from talking to customers, and no other stakeholder could help me either. ↩︎

  9. After many months without progress on this requirement-less project, the product team angrily announced they would be taking over. I was glad, because the responsibility of defining the product now lay firmly with the product team. Product requirements would be there coming week, the product manager said. But alas — that coming week, I heard nothing but crickets, and more crickets for the next half year. ↩︎

  10. I’m partial to the MoSCoW method, which categorizes items into the decreasing priorities must, should, could and won’t. ↩︎

  11. I wrote about this in Week­notes 2024 W03: Open channels. ↩︎

  12. Once upon a time, the team channels were private. To talk to a team, you’d have to be invited to an “inbound” channel which was also private. At end of the conversation, you would be kicked out of the “inbound” channel. Luckily, I managed to dissolve that toxic setup. ↩︎

  13. I once found out, quite by accident, that another team internally forked a product owned by my team. That other team had been actively developing their own fork of this product, completely without knowledge of our team. ↩︎

  14. Diablo II: Resurrected (Blizzard Entertainment and Vicarious Visions, 2021), published by Blizzard Entertainment. ↩︎

  15. Pillars of Eternity (Obsidian Entertainment, 2015), published by Paradox Interactive. ↩︎

  16. Vampire: The Masquerade – Bloodlines (Troika Games, November 16, 2004), published by Activision. ↩︎

You can reply to this weeknotes entry by email. I’d love to hear your thoughts!
If you like what I write, stick your email address below and subscribe. I send out my weeknotes every Sunday morning. Alternatively, you can subscribe to the web feed.
Incoming links:
Fitbit
Weeknotes 2024 W17: Irrational
Weeknotes 2024 W25: Nanoc 4.13