Conversation

Whichever way you slice it, "clean" handoffs between stages of the software development process create friction and leave each role frustrated due to lack of influence into neighboring spaces. The solution is working in parallel, not expanding your "slice" until burnout. 1/

Diagram showing 6 rough stages of software development: business strategy, user research, UX, UI, front end, and back end engineering. There are four columns with stacked roles and red lines between the roles signifying friction. The first column has product manager, UX/UI designer, and full stack dev roles. The second one has PM, UX designer, UI engineer, and back end dev. The third one has many roles side by side rather than stacked, showing that they work together and there's no "true" handoff. The fourth column just has "unicorn"; it is crossed out.

read image description

ALT

343

This Tweet was deleted by the Tweet author. Learn more

Andy Matuschak

@andy_matuschak

Sep 28, 2020

I love this thread but would be curious to see a more detailed criticism of aiming for unicorns! I've seen/experienced lots of problems there, of course, but they don't quite add up to "no no no," so I imagine you have something else in mind.

Pavel A. Samsonov

@PavelASamsonov

Sep 28, 2020

"We will simply hire one person with all the skills" has always struck me as an alternative to a coherent process, rather than a building block. Mostly because it results in very inconsistent performance across any particular stage, and 80-hour weeks.

Quote Tweet

Pavel A. Samsonov

@PavelASamsonov

· Aug 20, 2019

10x PM: ½x project management ½x product owner ½x researcher ½x UX designer ½x UI designer ½x facilitator ½x info arch ½x business analyst ½x eng lead ... Too bad ½*½*½... is less than 0.001. twitter.com/johncutlefish/…

Show this thread

Andy Matuschak

@andy_matuschak

Sep 28, 2020

👍 Yep, that rings true. Often the wrong trade to make, I agree—though not sure it’s worth dismissing out of hand. When is it the right trade? In some cases it’s probably cheaper, all-in. And some states in possiblity space do seem to require “everything in one person’s head."

Pavel A. Samsonov

@PavelASamsonov

Sep 28, 2020

I think unicorns (if you can find them & pay them fairly) are fine for R&D style work. But once the experiment is done and the value is proven, you need to move the knowledge from brains into models. Bonus: formalizing it that way forces the team to refine and strengthen it.

Replying to

and

That resonates. One specific challenge along those lines: because I *can* (to varying degrees) do every stage, there’s never a moment which *forces* me to bring others in—even though it might be best. Whereas if I e.g. simply couldn’t build backends, I’m forced to build a team.

6:28 PM · Sep 28, 2020TweetDeck

Replying to

and

It sounds like a humblebrag (“oh, poor me, I can do all the things myself!”), but I really do worry it makes me complacent about these trade-offs. Curious how that aligns with your experience,

I have a thread about this somewhere too. One of the challenges I'm facing as I try to evolve my leadership alongside my craft: getting over "I can do it better" and formalizing the needs & methods for others to execute, so that I am no longer the team bottleneck.