jm + teams   10

swill’s tech leadership essentials – Medium
very useful tips and advice from Stephanie Williams (nee Dean), who was instrumental in setting up the ops teams in Amazon Dublin, by all accounts
management  stephanie-dean  stephanie-williams  managing  teams  work  hiring 
22 days ago by jm
re:Work - The five keys to a successful Google team
We learned that there are five key dynamics that set successful teams apart from other teams at Google:
Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
Dependability: Can we count on each other to do high quality work on time?
Structure & clarity: Are goals, roles, and execution plans on our team clear?
Meaning of work: Are we working on something that is personally important for each of us?
Impact of work: Do we fundamentally believe that the work we’re doing matters?
teams  google  culture  work  management  productivity  hr 
november 2015 by jm
Notes on Startup Engineering Management for Young Bloods
Below is a list of some lessons I’ve learned as an startup engineering manager that are worth being told to a new manager. Some are subtle, and some are surprising, and this being human beings, some are inevitably controversial. This list is for the new head of engineering to guide their thinking about the job they are taking on. It’s not comprehensive, but it’s a good beginning.
The best characteristic of this list is that it focuses on social problems with little discussion of technical problems a manager may run into. The social stuff is usually the hardest part of any software developer’s job, and of course this goes triply for engineering managers.
engineering  management  camille-fournier  teams  dev 
october 2015 by jm
Git team workflows: merge or rebase?
Well-written description of the pros and cons. I'm a rebaser, fwiw.

(via Darrell)
via:darrell  git  merging  rebasing  history  git-log  coding  workflow  dev  teams  collaboration  github 
june 2015 by jm
Move Fast and Break Nothing
Great presentation about Github dev culture and building software without breakage, but still with real progress.
github  programming  communication  process  coding  teams  management  dev-culture  breakage 
october 2014 by jm
Painless, effective peer reviews
This sounds like a nice way to do effective peer-driven team reviews without herculean effort, which were one of the most effective reviewing techniques (along with upwards reviewing of management) I encountered at Amazon. (Yes, the Amazon approach was very time-consuming and universally loathed.)

The potential downside I can see is that it doesn't give the reviewer enough time to revise any review comments they have second thoughts about, whereas written reviews do, but that would be an easy fix at the end of the process. Also, it's worth noting that in most cases, a good review requires a bit of time to marshal thoughts and come up with a coherent review of a peer, so this doesn't completely avoid the impact on effort. Still, a definite improvement I would say.
hr  management  reviews  performance  peer-driven-review  360-reviews  staff  peers  work  teams  amazon 
august 2014 by jm
Hero Culture
Good description of the "hero coder" organisational antipattern.
Now imagine that most of the team is involved in fire-fighting. New recruits see the older recruits getting praised for their brave work in the line-of-fire and they want that kind of praise and reward too. Before long everyone is focused on putting out fires and it is no ones interest to step back and take on the risks that long-term DevOps-focused goals entail.
coding  ops  admin  hero-coder  hero-culture  firefighting  organisations  teams  culture 
january 2014 by jm
Operations is Dead, but Please Don’t Replace it with DevOps
This is so damn spot on.
Functional silos (and a standalone DevOps team is a great example of one) decouple actions from responsibility. Functional silos allow people to ignore, or at least feel disconnected from, the consequences of their actions. DevOps is a cultural change that encourages, rewards and exposes people taking responsibility for what they do, and what is expected from them. As Werner Vogels from Amazon Web Services says, “you build it, you run it”. So a “DevOps team” is a risky and ultimately doomed strategy. Sure there are some technical roles, specifically related to the enablement of DevOps as an approach and these roles and tools need to be filled and built. Self service platforms, collaboration and communication systems, tool chains for testing, deployment and operations are all necessary. Sure someone needs to deliver on that stuff. But those are specific technical deliverables and not DevOps. DevOps is about people, communication and collaboration. Organizations ignore that at their peril.
devops  teams  work  ops  silos  collaboration  organisations 
may 2013 by jm
The best "why estimation is hard" parable I've read this week
'A tense silence falls between us. The phone call goes unmade. I'll call tomorrow once my comrade regains his senses and is willing to commit to something reasonable.'
agile  development  management  programming  teams  estimation  tasks  software 
february 2012 by jm

Copy this bookmark:



description:


tags: