1/ They’re masters of coherence in arguments, information, and statements. Expect to be called out (bluntly) on something ... and for them to be right.
2/ Don’t assume silence means a lack of interest. Sadly, introverts get chased out of the “business world”. In the swdev team world, extroverts AND introverts thrive (cool huh?). Many or my dev friends choose to chew on a thought for a long time before interjecting.
3/ Imagine a world where your every keystroke is (basically) measured, scrutinized, Jira-ed, and reviewed. And ****ing up means the whole app can go down (or worse). Compare that to your world, where you can often dismiss something with a hand wavy “that’s a learning!”
4/ They care about impact .... but are BUSY. So don’t assume all they want to do is sit with their Bose noise-canceling headphones on tapping away at their custom modded keyboard. They do that to BLOCK OUT the insanity, so they can have an IMPACT.
5/ Some of my best dev friends will sit doing “nothing” for 2hrs, take a break, play some ping-pong, have some coffee ... and then solve the problem in 2 seconds with three lines of code. You should try it sometime when you don’t have back to back meetings :)
6/ The test passes, or it doesn’t. It works or it doesn’t. It’s good code, or shitty code (the last person, of course). Compare that to your world of wishy-washy strategy and “I’ll know it when I see it”. Some skepticism is to be expected.
7/ Nothing sucks more than working for six months on something and seeing it fail (even if the org’s success theater says otherwise). It is suuuuper painful. You get to move on. THEY need to maintain the turd. Reflect on that. Kill some features :)
8/ I worked with an eng that had a rear-view mirror to see me approaching with a “quick question”. At which point he would instantly put on his headphones (the sign for not now). 5m “quick questions” can take up a whole morning.
9/ Like anything and anyone, it is hard to build trust/respect, and easy to lose it. Keep in mind that issues tend to “flow down”, and developers need to clean up the mess. So cut them some slack if they’re a bit grumpy. Do better. They’ll come around.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
- What you say, and how often you say it
- What, when, and how you celebrate
- The losses and missteps you acknowledge, and how you respond
- How you behave when the chips are down
- What you fight for at all costs
- The corners you cut
- Who you hire, promote, and compensate, and who you fire
- Who you “smoke out” until they leave the organization
- The worst behavior you accept and the best behavior you reject
- The voices you amplify, and the voices you suppress
- When you encourage conformity, and when you promote diversity
- How you handle disagreements and differences in opinion
- How and where you spend your time and money
- What gets discussed out in the open, and behind closed doors
Here’s something you see often w/ teams and #kanban
Team: “Can we move cards backwards?” (1/11)
When this happens, we’re in a pickle. In true pull-system fashion, the developer has pulled another card. Test finds an issue that demands developer’s attention. What to do? (2/11)
One solution is to say “hey dev, you can only be on two things at once...one of which is developing”. Seems reasonable...and keeps their bandwidth open to fix issues. (3/11)
Some #prodmgmt Qs for interviewer... (1/4)
- technical debt
- recent prod issues / reactive work
- direct access to customers
- attrition rate for PMs
- typical calendar / mix of activities
- last 5-10 prod decisions and outcomes
- details of decision making process
- metric you must drive to be successful
- psych safety on teams
- dedicated #ux ?
- how team missions are crafted
- autonomy over roadmap ?
- deployment pipeline, ease of collaboration
- access to product usage data (tools?)
- current “big bet” and key unknowns
- career development (conferences, training)
- incentive structure for team members
- amount of pre-committed work
- examples of PMs being reward for specific behavior
- details of approvals, sign-offs, roadmap reviews
- overall product “culture” (role of product)
Model the work, not the “workers”. With team member magnets, checklists, and markers...the bottom design can more than adequately model the work
If work ever “moves left” (e.g. QA/demo passes an item “back to dev”), then the top dsgn breaks. It is all doing.
Another classic anti-pattern is team/individual lanes and “splitting” the work. The bottom option will probably catalyze the right conversations....though the top option with string can also do the trick. (2/4) #kanban
A compromise if teams want their own card for some reason... is a hybrid board with “epics” (larger chunks of work), and all of their related cards.(3/4) #Kanban