Engineering Manager Series Week 4

Hi everybody, it’s end of a sunny Sunday in Istanbul. Spring appeared in a flash; sun energized all of us.

As I promised, this week’s featured articles on accountability, low and high performers of the team.

HBR: Does your team have an accountability problem? shares some notes about accountability. At any point, I believe it’s important to first check ourselves. As mentioned in the article people do not go in the wrong direction intentionally. The following questions can be a good check before reaching the person/team.

Have I been clear about my expectations?

Have I asked what I can do to help?

Have I taken time to brainstorm and review processes?

Have I built a plan of action with my team member?

The second step is “Create a safe environment for the other person.“.

“Avoid jumping directly into critical feedback or using judgmental language such as, “Why would you…”, “You should have…”, or “That’s wrong.” It helps to assume positive intent in the other person. The goal here is to listen and to remain genuinely open to their “take” on things.

Listening, paying attention, and understanding the needs and motivations of the other person will help you put aside any assumptions you may be making about their character. You may discover that they are not “lazy,” “incapable,” or “unreliable,” but rather, that they are unclear on organizational goals, and therefore, are not properly prioritizing projects. “

This comes to our minds a broader term “Psychological Safety”. People should feel safe to share their explanation. Anyway, the easiest way is to behave how you want to be treat. But if we define it’s meaning, following Forbes article can help us.

Psychological safety is the ability to show and employ one’s self without fear of negative consequences of self-image, status or career. In the workplace, it is a shared belief held by members of a company, department or team that the team is safe for interpersonal risk-taking.

Organizational behavioral scientist Amy Edmondson of Harvard first introduced the construct of “team psychological safety” and defined it as “a shared belief held by members of a team that the team is safe for interpersonal risk taking.” 

In her TEDx talk, Edmondson offers three simple things individuals can do to foster team psychological safety:
– Model curiosity and ask lots of questions.

Frame the work as a learning problem, not an execution problem.
Acknowledge your own fallibility.

Let’s return to accountability. The following steps;
Ensure that there is clarity and a mutual agreement on how to move forward. 
Commit to setting those you work with up for success. 
Regularly track and measure progress. 

For the last, I’m about to hear but how? The article shares some best best practices:

Roles and responsibilities write-ups (to use as references)

Scorecards (to measure outcomes)

Regular progress check-ins (to give feedback)

Metric dashboards (to track performance)

Weekly meetings (to stay aligned)

Process write-ups (to gauge what is working and what is not)

Checklists (to stay organized)

Project plans (to outline future goals)

Well, with the additional explanations, it took more than I expected so I leave the low and high performer topics to the next week.

If you found the article helpful, you can rate/share(under the videos), claps(at the top of the article) or make comment so I can improve my series. See you at the next post!

Engineering Manager Series Week 3

Hi there, this is week 3. After a little break, still we’re here 🙂 This series aims to share some useful articles with some hints. This week’s articles are on a deep dive on engineering manager’s roles and responsibilities. Actually, we discussed this topic on the first post a little bit. While searching for articles I noticed Get Your Guide’s Engineering Manager series. Each company’s expectations are a little different about management but of course there are some common topics. This series summarizes it under 5 topics(productivity, team health, stakeholder happiness, customer and business impact, and systems health.). If you think about your company’s style and tools for the processes while you read the series, it would be more helpful. I’ll will give some hints from the posts.

Let’s start with Productivity. It’s mostly about prioritization of the work. They prepared 7 objectives to be more productive.

Objective 1: Projects are prioritized well (including what not to do)
Objective 2: MVP (minimally viable product) is considered and context is taken into account
Objective 3: Dependencies, primarily internal ones, are minimized and managed effectively
Objective 4: Team processes ensure continuous improvement
Objective 5: Waste is kept to a minimum  —  projects seldom get cancelled, fires and hotfixes are very infrequent, projects progress continuously and with little interruption, and uncertainties and risks are tackled early
Objective 6: Individuals are set up to be productive  —  onboarding is fast and effective, interruptions are minimal
Objective 7: Team keeps track of tech debt and keeps it in check

The “how” part is as much important as “what” part. I strongly recommend reading the whole series, all the posts consists links to some best practices. I’ll add one more best practice for the last objective. It’s called Techrospective. We noticed the technique from SabancıDx’s post, some teams started to use it.

The second topic is Team’s Health. Well you can do everything right but if you don’t be careful about one specific thing, the others doesn’t mean anything which is to prepare the right environment for a team’s being healthy. So how can we do it? GYG summarizes it under 5 main pillars.

  • Trust and dynamics
  • Setup
  • Onboarding
  • Growth
  • Performance management

Team Health is a foundational pillar to how we build high-performance teams, demanding prioritization and time investment. Balancing the different components of team health creates an exciting challenge for any Engineering Manager aiming to lead a happy and trusting team of engineers on-track for personal and professional growth. Although every Engineering Manager will have their own style and priorities, and every organization/team its own culture and maturity, team health is one aspect that must stay top of mind.

This time I’ll share one more additional best practice from Google for Growth. One of the behaviors of great engineering managers is being a good coach. Google has a page on re:Work for some tips on 1:1’s and career conversations. GROW model is very effective for coaching.

Goal – What do you want?
Reality – What’s happening now?
Options – What could you do?
Will – What will you do?

The third topic is Stakeholder Happiness.

“Managing stakeholders successfully means balancing different work streams, staying proactively aligned with others, and, ultimately, building trust by delivering on commitments. In our framework, we broke this down into three main areas, each as important as the next.
1. Team meets their commitments
2. Stakeholders are not surprised
3. Team is trusted by stakeholders

In the end, stakeholder happiness comes down to trust. This is built by meeting commitments, keeping everyone up to date, and openly addressing any misalignments in expectations or changes in direction.

The fourth is Customer and Business Impact.

– Work on the right product
– Have a long-term vision and mission
– Choose a solvable problem
– Choose a problem that will affect a large number of users
– Align your goals with the company strategy and socialize with other teams
– Start with the low-hanging fruit
– Set ambitious targets
– Measure the right metrics
– Start with the goal
– A great metric moves only based on your actions
– Make metrics visible, and own them
– Shipping something good now is better than something perfect later
– Dogfoodin
– Be paranoid about details

And the last topic is System Health. System health is something like Voltran. Lots of different teams work together in big companies to keep the system highly available. Monitoring, Automatizing the System’s health is much important as developing a rock solid system.

“To keep these systems in good health requires technical skills, good organization, and a sense of responsibility from all of our engineers. The Engineering Manager, together with the team, is responsible for making sure all of these things come together.”

On my next article, I’m planning to share some useful articles on accountability, low/high performers.

If you found the article helpful, you can rate/share(under the videos), claps(at the top of the article) or make comment so I can improve my series. See you at the next post!

Engineering Manager Series Week 2

This is the second week, so this is officially a series 🙂 You can read the first post under engineering manager category. If you got your coffee, enjoy the rest. ☕

When I first started to work as EM, one of the things that I can’t forget is the shock of how many more meetings have been added to my calendar. There were 7 agile teams I was working with then, now 9, it was 10 for a while. It means that there will be topics at least in 7 different fields. But when I look at my calendar, not all of them actually seems related to the work that we’re doing, or they’re related but at very mixed timelines and different lengths or one of them is taking the first half of my lunchtime and the following second half; there were a couple of meetings on meeting-free zones. My first reaction was trying to understand the content. So at first I didn’t change anything and tried to join almost all.

As a new EM, after years of working as IC, I was assuming that I, only me, should have joined all these meetings and freaked out if 2 of them were at the same time. Then I learned the delegation.

Delegation is one of the core concepts of management leadership. The process involves managers deciding which work they should do themselves and which work should be delegated to others for completion.

Of course, we all know what delegation is and always saying now I’m not the sum of my behaviors, we’re a team. But when I started to work as EM, at first it didn’t come to my mind at the first couple of weeks. Then, what happened. I mentioned in my first post that thanks to my company I joined a coaching group for a couple of months and it helped a lot. The idea was that the coach comes with a topic and everybody talks about it. I was mostly at the listener side, listening to the cases was very useful for a new one. Well, one of the topics was delegation, when we should use, which kind of jobs we should do on our own and for which ones could be delegated to our teams. Until that point, for everything asked to me and including all these meetings, I was trying to handle, join, answer, research even some of the request wasn’t related to my new job definition. That was a light in my mind. After that, I started to judge each request and also if won’t able to join some important meeting, delegate to some experienced people in my team and getting help. Anyway, this is just an example but, I strongly read this HBR article: To Be a Great Leader, You Have To Learn How to Delegate Well.

The upper limit of what’s possible will increase only with each collaborator you empower to contribute their best work to your shared priorities.

Let’s return to the meetings. After joining meetings for a while, I could group the meetings under some categories. Some of them were just popping in my calendar because they were sending to everybody if it’s related. Not very much but there was a group of meeting like this. The rest was team-related meetings in a very mixed timeline. So the first thing was making a calendar for me and also applicable for teams.

I said to myself, if I will change whole my calendar, I can get some help. So I started to search for meeting tips and techniques. I’m sharing a video including the most useful tips.

To give a summary of the video, the types of meetings;

  • Update -> Kill them, Replace with standups or email snippets
  • Strategy, Brainstorm, Planning, Design, Etc -> Are they masking a decision?, Be stingy with attendees, Keep them scoped
  • One on Ones -> Keep them sacred, Consider walking, How can I make your life easier?
  • Daily Standups -> Small groups, Stand!, “Accomplished yesterday?”, “Accomplish today?”, “Any roadblocks?”, Take everything else offline
  • All hands -> Regular and periodic, Rotate the planning responsibility, Share and celebrate, Q&A
  • Decision makings -> Requires the most effort to organize, Source of most pitfalls, ESSENTIAL!

A couple of more tips;

  • Decision Meetings -> Can it wait for a meeting?, Does it even need one?, Who is decider, Who are reviewers, What’s the agenda (no agenda, no meeting)
  • How long( Shorter is better, Try 20 or 40 instead of 30 or 60)
  • When (asap, defrag meeting schedules, consider “no meeting days”, Beware of recurring meetings, give time for preparation)

What I did, was I set a regular lunch break into my calendar in the time interval of the company’s official lunch break time. If anyone sends a meeting during my lunch-break or meeting free-zones, I started to reject asking with replanning or proposal.

I started to set the meetings that I organized to 20/40/45 minutes so I could have breaks between meetings.

Make the similar type of meetings with similar time intervals, use blocked times, organized as recurring. So I could save some free zones. This helped me to organize one-on-ones more easily, I could have more time to talk with people.

Of course anything urgent comes, I join the meetings at lunchtime, meeting free zones, after work, or change my agenda. But starting to judge and organize made my life easier.

Check if we need a meeting for it just talk on using collaboration tools async.

It comes with a new question? What kind of topics can be async which sync. I recommend you to read GitLab’s article: How to embrace asynchronous communication for remote work. But again I’m sharing some hot points from the article;

1. “I use sync meetings to help others when an urgent matter comes up such as incidents or deadlines.”
2. “I use sync mainly for troubleshooting where more live dialog is faster for all parties to solve the particular issue than async explanations and back and forth.”
3. “I use sync when I have exhausted async options or async is not leading towards Results.”
4. “I use sync meetings to generate creative ideas/proposals with my team that quite frankly would be difficult to do async.”
5. “10 minutes on Zoom is more efficient than 100 Slack replies over a few hours or 10 days waiting for GitLab issue thread replies from tagged team members.”
6. “For work-related, formal comms, I prefer async (and choose async when the format is up to me). Sync is great for relationship building (coffee chats, group social chats).”
7. “I enjoy sync to establish an initial human connection when team members have never met before (e.g. coffee/social/team calls).”

It’s important ask yourself always why and believe what you’re doing why you’re doing and how.

Bonus: HBR Article: Manage Your Energy, Not Your Time

Hope you enjoyed it. If you found the article helpful, you can rate/share(under the videos), claps(at the top of the article) or make comment so I can improve my series. See you at the next post!

Engineering Manager Series

Hi Everybody! It’s time to go back. 🙂

For a while, I wasn’t writing blog posts because I was trying to transform my career from individual contributor to engineering manager what I wanted to get experience for the last couple of years. Learning never ends and it shouldn’t. Otherwise, life would be so boring if you repeat yourself. But if you are new on a field, at the start it needs to push more effort, at least for me. I remember my first year of professional life; I was reading, trying till midnight almost every day to be able to build a base. Anyway, last year(especially the first 3 months) and while preparing for my change was exactly like this. I still read and research a lot and it will never stop but in a more balanced way.

Over this period, I saved the links that I thought can be helpful and returned re-read them. And also each week, I share a time to explore the trends if I’m having trouble with some issue or observe that at some point, improvement can be done or just to read over that week’s interesting articles. I have a nice library now and it’s growing day by day. All of my friends and family were so supportive during this period, I also joined a coaching group thanks to my company, got help from my senior manager and peer-managers; but 3 women’s contributions were extraordinary with their expertise and patience, who is my life coaches. I hope I can be helpful to them also. Thank you Melike OzdemirBurcu Geneci and Nazli Temurtas. You’re my heroes.

Anyway, sharing is the best thing to grow together. I’ll try to share the articles that I liked to read at the end of each week. Let’s see together if I’ll accomplish this goal or until when 🙂

So let’s start with talking about what an engineering manager’s work consists of because this is the first post of the series! Don’t worry next posts won’t be that long. Just this one. My actual work is a combination of people management, project management, technical leadership, working on team/division strategy, and some operational tasks. As everyone says the biggest difference between IC and EM is you’re not responsible just for yourself anymore, your success is your team’s success and your failure is your team’s failure. One of the most important things to be successful as a team is to listen, understand and know each other. So most of my work is getting engaged with people, an endless learning path.

Now we’re ready. So, start with the basics. One of my favorite is Google’s re:work website. It includes lots of different tools and articles to make an impact in our workplace. There are 8 common subjects that we can explore under them which are;


There is always a debate that whether managers matters or not. According to Gallup’s research, yes it’s. So what are the common characteristics of a great manager in today’s world. Again under re:work, there is research output for this. You can read the details from link but it shows that there are 10;

  1. Is a good coach
  2. Empowers team and does not micromanage
  3. Creates an inclusive team environment, showing concern for success and well-being.
  4. Is productive and result-oriented.
  5. Is a good communicator – listens and shares information.
  6. Supports career development and discusses performance.
  7. Has a clear vision/strategy for the team.
  8. Has key technical skills to help advise the team.
  9. Collaborates across the company.
  10. Is a strong decision maker.

One last nice thing from re:Work is new manager training documents. I hope these links can be helpful. There are lots of different tools, techniques and blog posts under re:Work, you can explore more.

Another very helpful company blog is gitlab’s leadership handbook. Remote working raised with pandemic but it’s not new for gitlab. They are a remote company. So including leadership tips there are a lot of handful tips for engagement while working remotely. I don’t remember how many times I read over again and used some of the tips that became very helpful. You can explore more but I’ll share my lifesavers here.

One of the most important is building a trusted environment. It takes time and energy. To leverage informal communication can help to build trust. But what are the different ways can be in the remote world. The gitlab’s link gives lots of alternatives for this. Of course, after you tried some of them, evaluate yours according to your team’s dynamics.

Working all-remote tips:

While started to explore online trainings, my favourite websites changed a little bit. Now it’s Linkedin learning after youtube of course. One of the trainings that helped me incredibly to organize my thoughts and explore what situations I can face with at my preparation period. And if a friend asks help from me to want to change the career to EM, the first thing I offer that this series. It’s Chris Croft‘s Inspirational Leadership Skills: Practical Motivational Leadership video training. Yes, we need to have a clear vision and strategy but how we can develop this, what’re the different motivation factors, at which point we can use delegation, how we can show our thank to our team members and some more critical topics.

One last topic I want to share for this post is first 90 days. Originally it comes from US president’s first 100 days.

In the United States, no one talked that much about the importance of a president’s first 100 days—until Franklin D. Roosevelt took office in 1933. He took swift action to calm the nation’s crippling financial panic (cue the Emergency Banking Act and the “fireside chats” that became Roosevelt’s signature) and began rolling out the programs that made up his New Deal, including 15 major pieces of legislation in the first 100 days. FDR’s extraordinary productivity translated into enormous popularity, and he set a first 100-day standard against which all future U.S. presidents would (perhaps unfairly) be measured.

If we return back to our journey, the most useful article I found for myself was David Loftesness, Twitter’s former Director of Engineering’s first 90 day agenda on the link. There are more than this in the article, so I strongly advise you to read but to summarize;

  • Day 0: Inevitable Truths You Need to Accept Upfront
  • Days 1-30: Own Your Education
  • Days 31-60: Find Your Rhythm
  • Days 61-90: Assess yourself: Do you actually want this?
  • Day 90: Resolve to Step Up or Aside

“After 90 days, if you’re not able to answer what’s unique about each member of the team, you haven’t had the right conversations or asked the right questions.”

And also, gitlab has a template for this. You can review over the link.

Bonus: If you wonder how engineering managers work at big tech companies and what they do exactly, I liked the following 2 videos. You can add to your watch list.

If you found the article helpful, you can rate/share(under the videos), claps(at the top of the article) or make comment so I can improve my series. See you at the next post!