Professional Development – 2019 – Week 26

Image Credit: https://www.flickr.com/photos/54585499@N04/

Dates covered: June 24-30, 2019 (week 26 of 52)

Business

What Startup Employees Can Teach the Rest of Us About Work (via Harvard Business Review)

“Where stability and long-term planning were once the mark of a sound strategy, adaptability is the new competitive advantage.” 1) Pitch before you apply, 2) maintain an external perspective, 3) don’t forget about the mission, 4) keep customers top of mind, 5) be a pilot, not a passenger.

The Financial Case for Good Retail Jobs (via Harvard Business Review)

The authors outline a “good jobs strategy” to combine investing in people (wages, training) with sound operational choices that lead to a more motivated and capable workforce. This leads to stores that are more smoothly run and have higher customer satisfaction.

Career

From Engineer to Manager and Back Again (via Software Lead Weekly)

I post these when they come across my radar, as most of the career transition posts of technical-to-management. These show evidence that it is possible to transition back to technical if you find that the other side isn’t where your heart is.

Communication

How to Ask for Help and Get a “Yes” (via TED)

Nobody succeeds in a vacuum; we have to rely on other people. We often fall prey to the illusion of transparency — that our thoughts, feelings, and needs are obvious to other people. If you need help, you’ll have to ask for it.

  1. Be specific about the help you want and why.
  2. Avoid disclaimers, apologies, or bribes when asking. This makes the helper feel uncomfortable.
  3. Don’t ask for help over email or text (too impersonal, too easy to decline request for help). Talk in person or call.
  4. Follow up after they’ve helped you; let them know it landed.

How to Work with Someone Who Thinks They’re Always Right (via Harvard Business Review)

  • Get behind the origins of the overconfidence bias
  • Consider how your organization might encourage this behavior (e.g., does conceding ground make you appear weak)
  • Acknowledge of other’s certainty makes you resistant

Culture

Case Study: Was That Harassment? (via Harvard Business Review)

This case study presents an example of an employee making a borderline insensitive comment in a zero-tolerance workplace. The actions that came from it are also worthy of discussion — not black-and-white.

Research: Women Score Higher Than Men in Most Leadership Skills (via Harvard Business Review)

The title sums up the post. What I found interesting was the list of 19 capabilities that excellent leaders possess.

Design

Designing Offices Where Privacy Doesn’t Compromise Safety (via Harvard Business Review)

There are design elements such as entrances, exits, communal spaces, use of transparent or frosted glass, and furniture to provide a balance of privacy (e.g., taking a personal phone call, having a confidential meeting) and public awareness (e.g., if someone does something inappropriate in a private area, others won’t know or be able to help).

Leadership

The Assumptions Employees Make When They Don’t Get Feedback (via Harvard Business Review)

In the absence of good feedback, people make up their own explanations. Some common stories (and example solutions) are given in the article: 1) as long as I’m not making trouble, I’m doing fine; 2) my manager doesn’t think I take feedback well; 3) my manager doesn’t think I can change.

How to Onboard New Hires at Every Level (via Harvard Business Review)

“Organizations can no longer ignore the needs of onboarding at all levels. By identifying target populations, creating semi-customized journeys, and enlisting stakeholder support, they dramatically speed up the integration and acclimation process and set new employees up for greater success.”

Advice for first-time managers (via Software Lead Weekly)

  1. Focus on prioritization
  2. Demonstrate and reward the right behaviors
  3. Difficult conversations
  4. Coaching and mentoring
  5. Have the courage to be vulnerable
  6. Keep it human
  7. “Become the kind of leader that people would follow voluntarily; even if you had no title or position.”

Process

The First Thing Great Decision Makers Do (via Harvard Business Review)

With access to so much data, we tend to think we should start with the data first, and let that inform our opinion. However, we have biases that convince us the data is showing us something we already wanted to see. “If you’re free to move the goalposts after you find out where the data landed, then that’s exactly what you’ll do, unconsciously. The solution is to set the goalposts in advance and resist the temptation to move them later.”

Managing an Underperformer in a Family Business (via Harvard Business Review)

  • Start with an open discussion about accountability; use a neutral third party if possible
  • Shift their role or responsibilities
  • Reassign the family member to a non-family leader
  • Construct off-ramps when necessary

Why Talented People Fail Under Pressure (via Harvard Business Review)

We should practice for events (e.g., giving a presentation, playing a sport) where the pressure is increased. However, it’s not useful to spend cognitive energy five minutes beforehand to prepare and dwell; focus on something else, like a crossword puzzle. Reframe your stress as positive (e.g., these physical signs of stress indicate I’m ready for the challenge ahead).

Things I Learnt The Hard Way (in 30 Years of Software Development) (via Software Lead Weekly)

I categorized this as Process because there are several tips that transcend software development. There are too many topics to list in this summary; if nothing else, I believe it to be worthwhile to skim through the headings. The author admits many of these are opinions; it’s useful to know how others think and act so that you can reflect upon your own thoughts and actions.

Software development

Why “Agile” and especially Scrum are terrible (via Steve Stamm)

This is one of several articles a colleague sent me that challenges the notion most of us developers/managers have learned that Agile/Scrum cures everything that ails you. Although this post leans more toward a rant, there are some solid arguments; for example, Scrum excels where you have a rapidly-evolving problem where you need a cross-cutting team. There are also some statements that made me think, particularly when it comes to trust and autonomy.

The Quiet Crisis Unfolding in Software Development (via Steve Stamm)

The author entered the field as a developer and is now a manager of managers.

  1. Be wary of high performers (they usually take shortcuts)
  2. Encourage continual product development
  3. Encourage code ownership (don’t optimize for devs leaving)
  4. Recognize the natural leaders
  5. Watch out for misleading metrics
  6. Limit interruptions
  7. Prefer private workspaces
  8. Encourage experimentation
  9. Let employees leave
  10. Never turn down small requests (e.g., better monitor)
  11. Abolish yearly and bi-yearly performance reviews
  12. You’re not better than your employees (it’s a different, not better job)
  13. Don’t discount younger or older devs
  14. Don’t have stupid dress codes

A Criticism of Scrum (via Steve Stamm)

This post had me nodding in agreement while reading. Scrum works well if you can reasonably estimate how long tasks will take… so long as there isn’t hidden complexity, inconsistent overhead, and distraction. I disagree with the premise that meetings kill as much productivity as the author states. Sure, unnecessary ceremony should be removed; however, if the frequency and quality of communication is working, then keep doing it. Scrum can often measure things that are quantifiable (stories per sprint), but not what really matters (quality code, delighted users, etc.). I also appreciated that “commitment” typically falls flat when you have dependencies your team doesn’t control.

Technical Debt: Poor System Understanding While Time Constrained (via Software Lead Weekly)

For me the takeaway is that maintaining a system context so that you can minimize technical debt involve… 1) high-level service tests, 2) architectural decision records, 3) system/transaction diagrams documentation, 4) living documentation.