My Authors
Read all threads
I've just bought @GalZellermayer's new book "Manager in Shorts". I've read the first chapter (chapter 0) and can't wait for reading more.

"This book will make you aware." Image
@GalZellermayer Quote as I go thread

Chapter 1

"Aim to master 4 domains: T & 3 Ps:
Technology - you know: coding, design, architecture, databases, frontend, and so on.

Product - what are we building and why? Process - plan and execute.
People - (-:

“In this order”
Chapter 2

@GalZellermayer identified the above quote is lacking agility and accuracy. He mentions that @jewelia noted (and better expressed) that too, in her tweet
Leading to the below catchy? sentence on enhanced manager's principles


P eople,
c U lture,
P roduct,
P rocess,
busin E ss,
and T echnology.
Chapter 3 on #ManagerInShorts
@GalZellermayer's book, takeaways:

Invest your time and energy in people’s growth (People as individuals, and as a team).

Don’t do anything else, before you have invested enough energy in making the team a better one.

People, People, People.
Choose "master your craft". it is important, for the purpose of doing a better job and for feeling in the flow.

Another tip, as a manager and a leader, you need to focus on developing your own coaching skills and your mentorship abilities.

#ManagerInShorts,has lots of insights
I liked the mentorship analogy to the Japanese martial arts terms, Senpai (先 輩, "Earlier colleague") and Kōhai (後 輩, "Later colleague") bond.

My take, assign the right engineer to be the mentor.
@GalZellermayer defines seniors, that have enough context of the software and the organization, involvement in mentoring. (Which reminds me @notarbut's E15). Leading the process of growth and only use the manager as a leverage for that growing process
#developers optimal states is between flow state, and some of the work in a growing state - this will ensure reasonable ROI for the organization in the short-term, happiness and mastery from the engineers, but also the growth and the development parts of the equation.
When people are out of their comfort zone, they are growing. Great developers would like to grow a lot. Coach them, mentor them, challenge them.

Performance management - focus on impact and output and not on effort

Every. single. word. in this section is in the right place.
I can't agree more on that! 👏🏻👏🏻👏🏻

"Don’t be bothered by the amount of time people... Only care about output and impact."

Effective positive feedback should be concrete, specific, and cannot be copy pasted from one person to another one. Make them better.

When people are out of their comfort zone, they are growing. Great developers would like to grow a lot. Coach them, mentor them, challenge them.

The important thing is to create a safe culture.

#ManagerInshorts Chapter 4

@GalZellermayer shares his “zero bugs policy״, this great talk and article, changed his perspective and had influence on the industry too.…
It pushes the team to keep high quality for new code and features, but does not supply rules or guidelines.

The manifesto states that you shouldn’t manage #bugs at all. You should either fix the #bug immediately or close it as ‘won’t fix’ - and never think about it again.
The policy is presented as example, how it acts as a "cultural game changer".

Given enough time and the right attitude, it would change the entire way your company is approaching #quality and decision making.
Companies must have #processes in order for them to operate.

Processes are good. When processes are done correctly, they are what make an organization pace the right way.
However, w/o the required grain of salt, processes might be the thing that reduces the effectiveness of the team and in time will softly kill your org.

You always need to have a thread in the back of your mind, asking if a process can be shorter, simpler, or more elegant.
Creating a process, and executing it well falls right into the comfort zone of first-time #Software #managers. Why?

1. High return on investment (ROI), at least in the short term.

2. Creating a process has similarities to writing code.
Ask ppl about what makes the company drifting to bureaucracy, and they'll answer:

1. Too many emails.
2. Too many meetings.
3. Too many processes.
4. Paralysis analysis (or some other formation of bad/ slow decision making).
Bureaucracy and slowness are not the only evils for processing everything.

The REAL problem is that processes by nature are specific and can’t cover everything.
Trust the team's judgment, but give them guidelines.

If as a team, we have a #value to lead us, and we don’t need to invent a shiny new process.
@GalZellermayer refers to one of his previous mgrs, @unativ. According to him, he's the one who taught him how to mentally think about developing an organization culture.

Quoting his talk:

“when in doubt - think culture; you can delegate the rest”.…
Creating a culture is better than creating a process.

Focus your time on bldg the right #culture for your team. This is very impt, bcs it will define the way your team behaves, and through that, the way your #team operates.

Start with the process and transform it into a culture
@GalZellermayer's personal values sum up into 2: #Teamwork & Continuous improvement (#CI).

TW is about the understanding that the team’s tasks are more impt than pres. tasks. It’s the ability of the members to give fdbk to one another, in a helpful, respectful, and trusted way.
The safe zone creates an atmosphere where teammates feel they can speak up without being afraid of fallouts. Referring to the below rework article.…
#CI is considered as the fuel of the organization. When it exists, it pushes the product to be finer, it purifies the process to be adequate, it encourages the team to try and use state-of-the-art technologies, and it motivates the people to #improve.
Choose your values carefully, but don’t fall in love with them.

The values, among other things, should serve the company’s mission. If the company’s mission has changed, or was even just adjusted, make sure you are checking to see if your values need a refresh as well.
Hire and measure according to your explicit values

Make them inherent to the hiring process and a cornerstone in your performance evaluating themes.

Embed the values into its d2d language.

Ppl will follow. It’s your job as a mgr to correlate your wds and acts with the values.
You need to remmbr that each time you are making org. change, it has the potential to impact your culture.

Don’t be afraid of that, use it to your advtg; if a culture change is needed - good! If not, think if the new org. structure supports the current culture or not.
If you don’t use your values when you are fcg hrd choices, then you have the wrg values.

If you don’t use your values, when you are making decisions, then your values will just be a poster on the wall.

Don’t accept the status quo. Processes need tuning, cult. needs revisiting.
#ManagerInshorts Chapter 05

You need to understand the market, customers and the use cases. If you don’t, you will not be able to kw what to focus the team’s exec. on.

Referring to @HubSpot's mgrs focus on ppl and product aspects (neglecting process)…
Work together. All three functions, EPD - engineering, product, and design.

Once you all work together, with a full alignment, and open communication channels, the entire organization would be much more effective.

To get sense of purpose. Connect your team to the company’s mission and goals.

Aprntly, knowledge wkrs that are working on technical challenging problems, care about doing it for a purpose. They would like to be proud of their work.

They would like to change the world or at least have a meaningful impact on it.

Thus, the team needs to understand how the things, the team does d2d are part of our department’s goals, and how are these, contribute to the company’s mission.

You need to tell stories to your developers in order for them to understand the business and to be connected to them - increasing their sense of belonging (and purpose).

It’s critical for their ability to have a long-term drive.

#ManagerInshorts chapter 06

You need to build for yourself frameworks that would allow you to make technical decisions without doing hands-on work. Such a wild card that provides enough flexibility to react for changes;
One of the ways to achieve that is to have a developer in the team that is not pre-committed for high priority tasks. Then, this wild card is able to help people when they are blocked, or handle pebble surprised asks by the fields or product.

Tech. “hands-on” is not a critical thing for a ppl mgr. In most cases, it would even get in the way.

THO, drifting too much away from the code is risky. it allows you to understand and relate better to the challenges your devs are facing in their d2d work

Lead your developer to a different path from the one they took so far, by asking them questions, and by undermining (in the good sense of this term) their thinking, that would lead them to the same conclusion.

And if you still can’t, it’s time to do some pair programming with them. Let them drive the wheel while you are sitting by their side and helping them navigate.

Delegate 99% of the tech. decisions to the ppl that are actually doing the work. Then, all you need to do now is to ask questions, a lot of them.

Use the 5 Whys technique. By that, the team would need to dive deep enough in order to give satisfying answers.

To prevent blame game, the state of mind you need to explicitly declare is that you only care about the future - how are we getting better, and not what have we done wrong.

If it feels tricky, you can try replacing the why with a “what can we do in the future?”

Culture of claim without blame

The team has more knwl details than their mgrs, so they should feel empowered to make decisions. You need to create a culture in which failing is cool, it is acceptable - moreover it is expected. learn from it.

@GalZellermayer's best practices for #leadership:

Stop making assumptions.

Alwz , alwz and alwz start with the why. Even if it’s obvious, the why is the ground floor of alignment.

There isn't such a thing as over communication. Communicate. Communicate.

Lastly, but most importantly

Engineering Manager is a profession. It’s not a promotion from a developer role, and it’s not a step in the way.

#ManagerInshorts chapter 07

Believe in what you do!
As a manager it is hard to make changes, but you must keep trying. Your work is to make the team better.

Remember that words are your art. Mails, chat applications, and meetings are your sword and shield.
Don’t be bothered by the fact that you spend most of the time reading and writing mails. Don’t feel ashamed that your entire day was back-to-back meetings. This is your job. This is what you do.

You should spend your time and energy on hiring the right people, coaching them to fulfill their talent, focus them to work on the right things, and mentor them to do it in the right way.

#ManagerInshorts Chapter 08

1:1 mtg is the most important tool in your mgr’s toolbox. It Isn't a project’s status report.
You can certainly use the project, and the challenges they are facing in order to direct the conversation to the right places, but this isn't the main thing
@GalZellermayer summaries his 5 practices for a beneficial 1:1 mtg:

1. Create a safe zone. This is your place to show care.
2. Help people grow. by giving them fdbk and recognition and by talking with them on their career aspirations; helping them navigate it.
Now, when the expectations were set, it’s pretty straightforward to move to a state of mind of tlkin about fdbk, career, and self-dev.

3. Bi-directional fdbk. #Devs can and should feel empowered to bring up fdbk on u, on the org., on the process, and culture.

Continuous improvement. The expectations from #engineers, to carry on their critiquing glasses, since it means they are aiming higher. Not just for themselves, but from the comp. as well.

4. Purpose and motivation. It's the fuel for running long distances.

5. Leading a change. Push you agenda. You’d like to bring people to an agreement or an alignment as individuals before you are doing that with the entire group.

Frequency: One-on-one meetings with direct reports need to happen once a week. Some ppl would not feel comfortable approaching you with off topics, in an informal manner. For that reason alone, it’s required to hold the meeting weekly.

Duration: The minimum time for 1:1 meeting should be 30 minutes.

Location: 1:1 meetings should be in a room, where the only people in the room are the manager and the team members.

Content: Start most of the one-on-one meetings with a casual friendly. Another recommended approach, say nothing. @GalZellermayer refers to a short article he has previously written:…

You need to prepare for your 1:1 meetings. You should make sure that during the week, you gather input and topics for discussions, and before the meeting, you have a clear agenda of what you want to talk about.

Do follow ups, This will reinforce your credibility and demonstrate the importance you give to these meetings.


Or at least been a lot more sensitive to communicate that the right way.

In some cases, you’ll see that your 1: 1 meetings are boring. Quiet. In these cases, @GalZellermayer advises to move out of the meeting room. Go for a walk, go for a coffee outside, go to lunch together. Anything that is not regular.

#ManagerInshorts chapter 09

The real problem of slow or no decision-making culture is the atmosphere created as a byproduct.

One of the most basic foundations of a good manager is the ability to make decisions. Making decisions effectively is hard.
In organizations that decisions making is slow, delayed, or just not taken, the entire culture is slow and delayed.

The bottom line is that as a manager you need to train yourself in making fast decisions. And reiterate on them.

Make explicit bets, be ready with a backup plan if the decision turned out to be the wrong bet, and reduce as much as possible the energy consumption of trying to come up with the “right decision”.

The real issue is the energy that is being drained.

Slow or no decision-making atmosphere is contagious.
Avoid paralysis analysis at all cost. Take bets. Smart and measurable bets.

The perfection of imperfection - accept the beauty of making decisions on incomplete data. .

Make fast decisions, validate the results, and if they need to be adjusted go on and adjust once you have new data.

Diversify your decision-making techniques. Trust your team. Let them fail and use their failures as learning opportunities.

Missing some Tweet in this thread? You can try to force a refresh.

Keep Current with Dvir Segal

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!