Coaching Teams Through Change, Prioritising User Value, 12 Signs of Difficult Engineers
Issue #15 Bytes
🙏 Points of inspiration, reading picks, and much more for a perfect Sunday ⤵️
🎙️In Conversation with Sergio Visinoni on Maslow's Hierarchy for Tech Teams
Sergio Visinoni joins podcast episode hosted by Kovid Batra. As a visionary Fractional CTO, Tech Advisor, and now, a mentor at
, Sergio discusses reimagining Maslow’s hierarchy for tech and business teams, covering its creation, levels and benefits, how it serves tech and business needs, implementation challenges, and key takeaways on data-driven decision-making.Article of the Week ⭐
“Leaders should listen to their people, let them vent, keep calm, and not react. They should explain what's going to happen, the business rationale behind the change, and the benefits of the change.“ — Dr. Milan Milanović
How to coach people through the Change Curve
Dr. Milan has a special place in tech: As both a CTO and active High-performance Coach he has a unique perspective on bringing on change in technology organizations that isn’t just your usual bread-and-butter agile implementations and metrics.
His article on the Change Curve is a metaphors to capture how listening and understanding act as key components in any 1-on-1 situation, be it as a manager, mentor, coach or facilitator.
The Change Curve
Originally developed by Elisabeth Kübler-Ross, describes the emotional journey individuals go through when facing change. The stages include:
Denial: Initial shock and disbelief about the change.
Self-criticism: Feelings of anger or betrayal as reality sets in.
Confusion: Overwhelm and disengagement, with attempts to avoid the change.
Acceptance: Acknowledging the change as inevitable.
Solutions: Exploring new methods and opportunities within the changed environment.
Commitment: Full embrace and commitment to the new direction.
How often have you found yourself looping from denial, to judgement and confusion and back on technical and product initiatives?
How to listen?
Dr Milan highlights three levels of listening:
Content: Noticing the words and facts being communicated.
Structure: Understanding underlying emotions and behaviors.
Deep Listening: Grasping the broader picture, including values, beliefs, and motivations.
The change curve is just a map. You help your colleagues and clients navigate them by understanding what their context is. The most direct way of creating understanding is by deeply listening to conversations sparked by powerful questions.
These should be open-ended and introspective, almost on the edge of comfort-awareness, but without judgement. Engineers love binary statements, so it’s even more important for our industry to avoid simple questions with yes/no answers.
And once the question was voiced into the ether…
… silence.
The full article will act as a guide for you with plenty of bonus infographics with example questions and phrases to arm you for your next deep listening session!
From the founder’s desk!
Other highlights 👇
Rethinking Technical Tasks: Define All Tasks As User Value
It saddens us to see how shallow the ticketing-management has become in most organisations. A few linguistic tricks, tick some boxes in JIRA and the task is defined. Go! We highlighted the pitfalls of a never-ending backlog masquerading a growing stream of poorly defined ideas and wish-lists in our Number #4 Issue.
Alvaro from Leads Horizonz suggests an end to the product vs. technical task categorisation: define tasks as user value.
So… what’s value?
His article starts by highlighting the concept of Net Value, simply the naïve difference between Cost and Value in dollar terms. As an avid reader, you no doubt immediate issue with such oversimplifications:
Most tasks accrue cost and revenue along a wide timescale, including future concrete and potential ones.
All of the numbers are a guess at best
Unify Estimates
While imperfect, Alvaro emphasises that the accuracy itself is not critical. What matters most is that these value and revenue estimates capture product and business thinking for each tasks and document them, so everyone involved can be exposed to this level of outcome-based planning.
He has a few more tips on the matter along with an example in the full article below 👇
12 Ways To Tell If You’re A Difficult Engineer (And What To Do About It)
We focus mostly on CTO’s, execs and senior leadership—but there are elements to engineering cultures that transcend titles. Even though you may not be writing code as much as you would like to, managing the higher echelons of engineering management and leadership does not get any easier or simpler when it comes to working with other people.
John Crickett doesn’t beat around the bush on this one, humbly sharing his hard-earned experience in the matter by learning how to set his ego aside and stop being difficult.
We’ve all been there. Crossing the line between individuation and egoism, individual expression vs. resistance. His article highlights 12 combinations of such behavior (and what to do about them). Here are the top three:
1. Your manager tells you you are
Regardless if you were observed or complained about being difficult—this one is direct and obvious.
What to do about it: Take responsibility. Nothing will improve if you resist change.
2. You are continually challenging or correcting everyone
Engineers can be ruthless problem-solvers. Turning off the problem-radar can be a difficult challenge as we spot issues easily, revelling in the idea of brainstorming solutions. But not all problems are appropriate to dig into, especially not all the time.
What to do about it?
Before criticising or correcting ask yourself these three questions:
Does this need to be said?
Does this need to be said by me?
Does this need to be said by me now?
If the answer to any of those questions is no, keep quiet.
3. People are nervous or guarded around you
Low psychological safety is a strong predictor of low performance and individual silos—the hallmark traits of a cost centre. Your team will adapt themselves around the most out-of-balance person in the room. If it’s you they will try to avoid (or fix) you.
What to do about it: Seek first to understand before seeking to be understood. Ask questions and try to understand other people’s ideas, find some common ground on which you can build. Speak last, ask others to contribute their ideas.
📚 3 Essential Non-Tech Books for Software Engineers
On leadership, decision-making, productivity, and team culture for software engineers!
"Atomic Habits" by James Clear
Discover practical strategies for developing positive habits and breaking negative ones, perfect for boosting your productivity and strengthening team dynamics."Daring Greatly" by Brené Brown
Learn how embracing vulnerability and courage can transform your leadership style and help you build a more collaborative and supportive team culture."The Lean Startup" by Eric Ries
Explore principles for driving innovation and achieving success in startups, offering valuable insights for those in software development and entrepreneurship.
What’s your read in 2024? Let us know your top book picks in the comments!
That’s it for Today!
Whether you're hustling with your side projects, catching up with the latest technologies, or simply relaxing & recharging, wish you all a lovely day ahead.
See you next week, Ciao 👋
Credits 🙏
Curators - Diligently curated by our community members Denis & Kovid
Writers of the week -
, ,Sponsors - This newsletter is sponsored by Typo AI - Ship reliable software faster.
1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.
2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.
Thanks for the mention, glad you found the article useful.