Distributed teams have lots of benefits and advantages when done right. There are specific challenges too, and lack of in-person interaction is one of the hardest things to overcome, despite there are all sorts of modern communication tools we use every day. Meetups come to rescue here, so if you don’t run them yet, it’s a good idea to start preparing your first one.
I joined Automattic at the beginning of 2020, and knew that teams have a practice of regular meetups, but COVID-19 pandemic in combination with conflict in Ukraine delayed my first meetup for 2.5 years. I just got back from the first one and realized how important that experience for bonding distributed teams.
During the normal days, everyone in the team operates within their own time-zone and context (family, life events, local news, laws, regulations, etc) which might be very different between locations. These differences may significantly affect the ways each individual behaves or engaged in particular situations. Getting together at the meetup brings everyone on the same page – same time zone, same location, same schedule and so on. All that boosts the quality of interactions during the meetup.
Seeing each other in-person for the first time helps to build the full image of your teammates. During the video calls you can definitely see how their face and top of the body looks, maybe how they sound, but it’s really hard to understand how tall they are or what’s their weight, how their voice sound without microphone, how they move, how they speak while not in the meetings, and many other little details you can sense only in person.
Personal interactions are pretty limited in distributed environment too. We have some social time together or chatting in virtual water coolers, but it’s not the same as getting together in the bar after work or sharing lunchtime. At the meetup there is enough space and time for those activities because all of us are far from home and no one needs to pick kids from school or go to the dentist.
Lots of communication in distributed environment is asynchronous. This is great and works well for most of the discussions. However, there are types of activities which are more effective when done synchronously. In distributed teams sync time might be very limited (if available at all) due to the time zones, but a few days at the meetup can easily give us the same amount of sync time as six months of weekly team calls.
Last but not least, a meetup creates a shared experience and memories for the whole team, and some of them could be pretty unique. This time on top of all the great things we did during the meetup we experienced a false fire alarm in the hotel đ¨ We got together outside the hotel and made a ton of jokes about it, where else we could get this?! All these experiences and memories will stay with us forever and will support the team all along the way when we’re back to usual distributed work.
Can your distributed team survive without meetups? I think, yes, it’s possible! At least we were able to operate pretty successfully without in-person meetups for the last 2.5 years, but meetups help us bring morale and relationships within the team to the new level. Meetups make our distributed work much easier and joyful.
As a final bonus, we’re able to learn from each other during the meetups. At least I’ve learned a lot of things from my teammates last week.
At the end of July, I got an idea that it would be nice to share in my blog some good posts I read. Can’t say that I read a lot, but I’d like to do a better job here. I also receive quite a lot of reading recommendations from various resources and struggle myself to read all of them or pick the best reads, so I thought you might have similar problems too. That’s why I want the list to be very lightweight, and carefully chosen. I want it to be something that resonates with me as an engineering lead or insightful for a person willing to create great products for real people.
Please note, there is no option to subscribe to that specific compilation. I think there are enough pings, dings, unread messages in whatever apps you use, so I don’t want this to become another one. This compilation is a free ride, you’re welcome to check and read it whenever you want or have time. Enjoy it!
Gio Lodi is sharing his thoughts about what productivity means for Software Developers. Doing more? Doing better? Doing the right things? Those are great questions to think about for yourself, and I believe the true answer will depend on your own preferred balance of those things.
The Curse of knowledge
Scott Berkun wrote an internal post about the curse of knowledge concepts and how that affects product decisions made by us. That’s a very interesting problem and concept, being aware of which could help with looking at the problems from the different standpoint. I can’t share the post by Scott, but you can read more about the concept here and here, and try to apply that knowledge to product thinking on your own. Believe me, it’ll be a fun exercise.
This is the story of how Uber get to the splitting teams into Program and Platform teams. Good read for the cases when the number of teams working on the same product is growing and the old approaches stop working at new scale. That also resembles the approach we started following at the end of 2021 for teams working on WooCommerce Payments. Some things already work the same way, and some ideas would be interesting to bring to life.
That post explains a very simply but powerful idea for improving knowledge exchange and learning within daily work routines. In two words: suggest topic/post/article for discussion, give partner or group time to digest the content, get together to discuss and exchange opinions. The author uses the idea in 1:1s, but we took this practice as an experiment to run discussions within a group of engineering leads, and it works well so far.
This thought keeps coming back to me again and again over the last months. There are many flavors of leadership – leadership styles, but none of them is a universal enough to fit in the best way for every case.
Itâs not a coincidence, Iâve chosen a sound director image for the blog post, because more often than not, I see the leaders do the same for their teams. Similar to sound directors, who adjust dozens of knobs and handles to make sure the resulting sound is as good as possible, leaders operate within their own environment to make teams shine and flourish. However, the devil as always is in the details, because the reality is way more complex than the idea itself.Â
For example, every engineering leader has to make many decisions about communication, processes, projects scope, team focus, time allocation for learning and development, amount of tech debt, size of the team, team velocity, code quality, acceptable risk levels and so on. Multiply those to a number of other factors like team members’ individuality, state of the business and market, competitors, and other elements making up the context, and you will understand how vast is the operational landscape can be.
So the definition of good enough will be very different depending on the context you operate in, e.g. velocity in the early stage products might be much more important than quality of the code, and quality requirements for payments service will be much higher than for utility application.
As a result, leaders are working every day to find that unique balance of existing tools, processes, and their configs, to steer in the chosen direction and maximize desirable outcomes, which makes the job pretty close to art.
Author: Camile Fournier Subtitle: A guide for tech leaders navigating growth & change.
TLDR; This is a very good guide on how the individualâs journey could look like in the tech company if they choose to follow the management track. It has plenty of management wisdom yet is delivered in a lightweight way giving directions for further in-depth exploration. Personally, I was very impressed by the density and quality of the thoughts in the book, so I will encourage every team member to read at least the first several chapters. Thank you, Camille, for this book!
The author
Camile Fournier (@skamille) is currently a Managing Director at Two Sigma. She studied at Carnegie Mellon University, worked at Microsoft, went from the tech lead to CTO at Rent The Runway, and took many other leadership positions in different companies. Here is a great quote from the book expressing the growth experience of Camille:
As the organization scaled, so did I. I had mentors, coaches, and friends who provided valuable advice, but no one was there to tell me specifically what to do. There was no safety net, and the learning curve was brutal.
In the âManagerâs pathâ book Camille shares her lessons and own experience as well as describes in many details different stages of the engineering management career. You can find more of her posts on medium.
For whom?
I think this book will be valuable for many people at different career levels, starting from middle engineers to tech leaders and engineering managers of any grade.
Engineers will benefit from better understanding their mentors and managers, taking a look at what leadership roles are, and getting prepared for the first steps if they decide to follow that path.
Current leaders will find some great tips and ideas for their day-to-day work as well as insights about senior leadership roles.
The book might be interesting for non-tech leaders too because they can learn a lot about the life of their colleagues from tech departments.
How to read
The book is very well structured and you can jump straight into the level of your interest. However, Iâd recommend starting from the introduction and covering at least one chapter below and above the level of interest. And donât forget to take a pencil or a notebook for taking notes. Believe me, youâll want to do so. Personally, I enjoyed reading all the chapters one after another.
My impression
I want to say that the book is amazing and let you read it on your own, but that would be unfair to you đ Each chapter has great thoughts and sparked more than one idea in my head.
Chapters about the levels Iâve already experienced (up to leading the team) resonated with me a lot. They had a lot of precise notes, observations, and tips. I wanted to scream something like âYes! Yes! Yes! This is so true!â or âI wish all my teammates knew this!â.
Chapters about the next leadership levels were very interesting. They made me play with my imagination but still were much vaguer because I havenât had such an experience yet. I also felt that life at the higher levels varies a lot depending on the context and organization culture which I believe is perfectly fine and expected for those positions.
Anyway, the book has left a very positive impression and I think Iâll read it again more than once.
My favorite quotes
I was thinking to pick three to five quotes for this section, but after making an initial list of 43 it was unrealistic to shrink it down that much. I struggled while was removing quotes from the initial list, so here are the ones I couldnât get rid of. Some of them are very obvious and simple but still very powerful.
… experience of being managed is the foundation on which you build your own management philosophy. Unfortunately, Iâve come to see that there are people who have never in their careers had a good manager.
That is a very good definition of a problem in the industry as well as the source of trouble because engineering management is hard, and not every person steps into the role striving to become good at it.
Developing the sense of ownership and authority for your own experiences at work, and not relying on your manager to set the entire tone for your relationship, is an important step in owning your career and workplace happiness.
Accepting the fact that you own your experience was the biggest game-changer not only in my career but in my life. Staying in the same spot while suffering and complaining is also the choice, but not mine đ
One of the early lessons in leadership, âŚ, is that people are not good at saying precisely what they mean in a way that others can exactly understand.
I noticed it during the past year as well. No matter how clear the message sounds in your head it will land differently on peopleâs minds, so it might be a good idea to validate what people heard, e.g. by asking them for a summary or by taking shared notes.
⌠there is nothing worse than showing up for your big job with nowhere to sit and no access to the systems.
New people onboarding process is one of the key elements of team success at times of rapid growth. Welcoming new people, making them feel you were waiting for them, is a significant booster if done right. So make sure you allocate enough time to prepare for onboarding a new teammate. If donât know how? Read the book for many great tips.
The idea that the tech lead role should automatically be given to the most experienced engineer, âŚ., is a common misconception that even experienced managers fall for.
âThere are more experienced people in a teamâ – several people mentioned this to me as a blocker for looking into leadership roles. In practice though, itâs absolutely not a blocker! In my opinion, itâs good when a leader knows he/she is not the smartest person in the room, so they have to bring other skills and tools for leading the team in the right direction.
My final advice is to remember that you can switch tracks if you want. It is common for people to try out management at some point, realize they donât enjoy it, and go back to technical track. Nothing about this choice have to be permanent, but go it with your eyes wide open. Each role has benefits and drawbacks, and itâs up to you to feel out what you enjoy the most.
I hope this quote removes another common fear among tech folks looking at leadership roles. Itâs a different job, you may like it or not, both are fine.
In the long run, if you donât figure out how to let go of details, delegate, and trust your team, youâre likely to suffer personally. ⌠Your time is too valuable to waste, and your team deserves a manager who is willing to trust them to do things on their own.
Trust your team, they wonât let you down and will save you from burnout.
Whatever the procedure is at your company, the process of coaching someone out should begin long before any performance improvement document is filled with HR, and long before the actual act of firing. One of the basic rules of management is the rule of no surprises, particularly negative one. You need to understand what a person is supposed to be giving you, and if that isnât happening, make it clear to her early and often that she is not meeting expectations.
Thatâs probably one of the hardest things you need to do as a leader. Letting someone know they donât meet expectations is usually a tough conversation, but avoiding tough conversations with the hope that things will get better soon is the worst path you can take. Poor performance or misbehavior should be addressed sooner than later because it harms overall team health. But, donât rush by calling HR to kick somebody out of the team because everyone can have a hard time in their life. First, do your best to help a person with getting back on track, but if it doesnât work out stay clear and honest with the person and help them to leave the company gracefully for the sake of the overall team.
Appropriate context is what helps teams make a good decision about how and where to focus their energy. As the manager, itâs not your job to make all of those decisions by yourself.
Yep, as a manager, you better focus the energy to create conditions where the team is capable to make decisions rather than deciding everything on your own. Autonomy is one of the basic psychological needs.
Delegation is the primary way you claw yourself out of the feeling of having too many plates spinning at once.
Itâs also a great way of developing talents in a team.
As you grow more into leadership positions, people will look to you for behavioral guidance. What you want to teach them is how to focus. To that end, there are two areas I encourage you to practice modeling, right now: figuring out whatâs important, and going home.
This year was very busy for me and for many of us at Automattic. One of my biggest insights from this adventure is for success you donât need to work more hours, you rather need to work on the right things.
Remember, youâre not expected to know everything just because youâre a manager.
No comments, just remember that.
The processes should have value even when they are not followed perfectly.
People are not machines, they do mistakes, so consider making fragile processes more resilient or get rid of them at all, especially complex and fragile ones.
You have to be able to manage yourself if you want to be good at managing others. The more time you spend understanding yourself, the way you react, the things that inspire you, and the things that dirve you crazy, the better off you will be.
I simply agree here, self-awareness, coaching, and other practices helped me a lot with getting better as a human and a leader.
If not convinced yet, believe me, there is much more in that book. I encourage you to buy a copy and keep it nearby on your bookshelf!
Photo by Towfiqu barbhuiya on Pexels.comAudio recording of this post
Being a leader implies a broad set of responsibilities and requires skills that differ from individual contributorsâ skills. I was thinking about it yesterday morning and then the question came to my head âwhat are the most important ones?â. Huh, the wheels immediately started spinning in my head trying to find the answer. Then I remembered that limitations foster creativity (here are twoposts on this topic), so I decided to add a limit of 3 skills to make the exercise even more fun. So here are the top 3 of my choice.
1. Communication
âCommunication is oxygenâ sounds like a mantra in my head not only because itâs part of the Automattic creed, but because I feel it with my bones. I doubt there is a leadership book exists which doesnât mention communication as one of the top skills for leaders or managers. I also think communication is the most powerful weapon in the leaderâs toolbelt.
There is a lot already said and written about it, but through this year Iâve realized that being good at communication is not just being able to speak or write well and without mistakes. Itâs much more – from understanding the theory of information processing by humans to resolving conflicts, from effectively expressing yourself to listening and creating a space for others to share, from stretching people to supporting them, from mentoring and coaching individuals to learning from them, and so on.
As you can see, communication is a very broad topic, so mastering and practicing various aspects of it will never hurt.
2. Sense of balance
Leadership is a very inaccurate science. There is no one size fits all solution and many recommendations depend on the context. Thatâs why I believe itâs crucial to seek, define, and regularly check the balance which works well for your case. That applies basically to everything – the amount of uncertainty affordable in the projects and processes, the amount of autonomy and control you want to have in a team, the amount of tech debt taken into sprints, the amount of time spent on learning and self-development, saying yes or no to many ideas and initiatives; the list may go very long.
No matter what was your past experience, it takes time to adjust balance in your current context, so pure curiosity, observations, and regular feedback loops are your best friends in finding the right balance.
3. Self-care
Supporting your team and its individuals is another extremely impactful way of leading the team to success. However, you wonât be able to do it well if your battery is drained. Thatâs why I think taking care of yourself is necessary, required, and mandatory in that role. If you like many others experience impostor syndrome or feel guilty about taking care of yourself, itâs time to reach out for support. Talk to your lead, talk to your peers, consider working with a coach or a therapyst, because sometimes itâs really hard to cope with. And last but not least donât forget that simple aircraft instruction âPut the mask on yourself firstâ.
Note:this is purely my opinion as of today, after being more than one year in that role with a fully distributed team, after experiencing a team growth from 4 to 12 people, after experiencing a team split, team focus shift, delivering multiple projects, switching team focus, talking to and learning from many great leads, mentors, and coaches around me.
Iâm curious what would be your top 3, so I would be happy if you share them in the comments under the post.
TLDR; Working hard and working smart are not the same things. The first ensures a lot of work is done, the second – moves you forward to the desired destination. Focus on what really matters can significantly boost individual/team/company effectiveness.
Last week Iâve read this post from The ReadMe Project about effective communication which resonated with me. The gist is that truly effective communication leads to the desired outcome rather than desired output. I think this rule could and should be applied to many other things as well: the code we write, the decisions we make, the projects we lead, the products we create, the actions or inactions we make, and so on.
The key difference between the two to my understanding is the output designates the artifact of the work like feature, document, message, post, etc, while the outcome defines the desired impact you want to achieve like improved user experience, change in the audience behavior, metric growth and so on. Thatâs why the outcome is what really matters and not the output.
Iâm not saying the output is not important; on the contrary, I believe the output is very important. However, most of the time the outcome can be achieved in several different ways but often people focus on the output they planned to create and forget about the desired outcome, or donât think about it at all. So far Iâve seen two very common patterns: doing something without thinking about the outcome and losing the focus on the outcome in the process.
Not thinking about the outcome
This is usually caused by the too-narrow thinking which might have many various reasons underneath it ranging from not enough experience to dangerous not my problem mentality. In simple cases, the situation could be improved by clarifying the context for the activity, organizing learning or mentorship, or providing feedback. In complex cases, a more thorough investigation is needed to find the root of the problem and work with it.
Losing focus in the process
This applies to longer activities like projects, roadmaps, etc. Before the kick-off, at the planning phase, itâs quite common to keep the final purpose in mind to define what output is required to achieve the project goals. However, in the execution phase, that sense of initial purpose vanishes very soon and, if completely lost, can often lead to irrational or even wrong decisions.
There are two key reasons for this: different levels of thinking and different levels of involvement from people between planning and execution phases. The planning phase assumes strategic thinking and deeper involvement from leadership (explicit or implicit), while the execution phase requires tactical thinking and deeper involvement from the implementation team.
To maintain the focus on outcome and make it part of the team or organization culture there are a few simple things needed:
Create context for people operating on the tactical level. Make sure they understand the desired outcome and indicators of success. Worth mentioning is that the outcome is more important than output.
Make the outcome a part of the progress tracking. First of all, itâs important to track the progress of the longer initiatives, so if you donât do this yet itâs time to think about it. Second, make sure the desired outcome is part of the tracking progress, either via metrics or as a reminder of what youâre trying to achieve in the end.
Reiterate the final goal/mission regularly to refresh it in people minds.
Although things above look simple, doing them consistently is tough, but only consistency will be able to build a new habit with time.
Examples
Output thinking
We should ship a new payment method X by the end of the month.
Outcome thinking
We help merchants and shoppers in Europe to sell and buy with their favorite payment method by adding a new payment method X to our product.
I need to create a weekly/monthly/quarterly report for my manager.
Iâm providing the summary to my manager so they can do their work more effectively.
I need to gather feedback from peers and stakeholders.
Iâm trying to make a better decision by incorporating the knowledge, experience, and unique perspective of my peers and stakeholders.
Validation
How do I know if somebody, including myself, is focused on the outcome over output? One of the best ways to check this is a five whys technique. Although the technique is originally intended to get to the root of the problem in this case it helps to see if you sense the root of intention:
What am I doing at the moment and what should be the result of the activity? => Output.
Why this result is important? => Outcome 1.
Why outcome 1 is important? => Outcome 2.
Why âŚ
Ideally, after a few iterations, you should see the movement towards the mission statement (personal, team, or company). If itâs not happening, that itâs a good signal to step back and rethink if the task or even the whole project is still relevant, but thatâs another story.
Thatâs it, I encourage you to raise your awareness about the outcomes youâre trying to achieve as itâs what really matters in the end.
TLDR; Are you lacking confidence? Donât feel satisfied with your daily progress? Struggling with providing positive feedback to your reports, peers, or managers? You should try success diary practice! Every day, even the tough one, has positive moments and elements of success. Training yourself to spot it can help you in many ways!
Some time ago I was reading Bodo Shaefferâs book âA dog called Moneyâ. Despite being a very good book for kids and adults about dealing with money it mentions a fantastic tool called âsuccess diaryâ. You need to write down at least 5 elements of success every day and thatâs it. The idea sounds simple, isnât it? But the power is huge, especially for leaders. In the book, the diary was aiming to improve the self-confidence of a person, but after practicing it myself for almost a year Iâm pretty sure it gives much more than that.
Success diary powers
Reflection
Reflection is a great practice helping to increase awareness, performance and boost growth. While doing exercise you create a space for yourself to step back, look at your day and observe it in a different way. I was surprised how many great things could go unnoticed in the flow of tasks without such a reflection.
Positive focus
Since youâre intentionally looking for success you tune your brain to search for it and filter out everything not matching âyour requestâ. By doing so you train the brain to spot success even in small things.
Acknowledgment
By writing items down you consciously recognize and acknowledge your success. If youâre familiar with git itâs like committing new items to a success repository inside your brain. As an outcome, your satisfaction, confidence, and motivation are growing.
Satisfaction
The third inborn intention is Sense of Accomplishment.
It feels good to accomplish something, right? Every item in your daily success list is an accomplishment. No matter if it is small or huge, it positively contributes to the sense of accomplishment and maintains it with time. If you look back in the diary after 30 days youâll get at least 150 items. Do it for a year and youâll be successful at least 1825 times!
Confidence
Have you heard of Impostor syndrome? Itâs very common in tech and often can lead to lower self-confidence and belief in own abilities. The success diary helps here by building a positive track of records. When feeling a lack of confidence or fear of failure just open the diary on the last page and start reading back until the feeling goes away, it should help đ
Motivation
You did the exercise yesterday and you know youâll do it again today, tomorrow, and so on. This habit motivates you to prepare for success! So you might take some extra effort or plan some wins for the days ahead.
How does it help leaders?
There are few more bonuses for leaders making their life easier at work.
First of all, for yourself, it helps to fight the lack of immediate accomplishments after transitioning from an Individual contributor role. I wrote a bit about it in my previous post.
Secondly, as a leader, itâs your responsibility to acknowledge and celebrate team success as well as to provide feedback, including positive ones, to your direct reports, peers, and managers. The success diary trains your muscles to spot success not only in yourself but around you too! So it will be much easier to provide positive feedback or recognize the achievements of others and will lead to better team morale.
My experience
I practiced the success diary for almost a year, every day, and stopped only when I felt I donât need it anymore because I noticed I started doing it automatically in my mind. In the beginning, I was struggling to spot success. Sometimes I was staring at a blank page for minutes or stuck after 2-3 items. The key mistake was to look for huge or big wins only and to neglect smaller ones. After some time it got to the habit and I could easily write 5 – 10 items within several minutes. Moreover, I started noticing signs of success around me and noticed I have a better mood in general.
Is it cheating or gaming? No, I donât think so, at least if you are being honest with yourself. It doesnât mitigate mistakes or failures, it doesnât keep you always positive either, but it supports you in stormy and good days as well as gives powers to support people around you.
TLDR; There is a significant difference between individual contributor and team lead roles. The leadâs focus is on multiplying a compound value delivered by the team, rather than accomplishing something on their own. So the mind shift is necessary to transition into a leadership role successfully.
Have you been thinking about stepping into a leadership role or just get âpromotedâ to team lead? Thatâs great, congratulations! The leadership role is great and has lots of fun, challenges, and interesting cases, but it requires a different mindset compared to the engineering role.
Note: further Iâll use the terms engineer, developer, and individual contributor interchangeably. Although itâs debatable and some people prefer one title over the other, however, the difference is not so important in the context of this post.
Promotion or not?
Apparently, the transition from individual contributor to team lead is a big change, but letâs take a look if it is a promotion at all?
It has some elements of promotion. E.g. youâll have direct reports, some of them even might be your previous peers or you could get a compensation raise (happens pretty often, but not always). Also, there are many talks in the industry stating that team leadership is an obvious next career step for any senior-level developer.
I canât agree with the last statement because the leadership role implies a significant change in expectations from the candidate, responsibilities, and skills necessary to be good at it. On top of that, I truly believe stepping into a leadership role requires a significant mind shift. This makes the whole change closer to career path switch rather than promotion.
So you can decide for yourself if itâs a promotion or not, but the size of the change remains significant no matter what you decide đ
How successful team lead looks like?
When I was considering a team lead role the coach asked me: âHow successful team lead looks like in your mind?â. I was absolutely sure how a good developer looks like – they write high-quality code, do great code reviews, decompose complex problems into simple ones, know a bunch of tech tools and fundamentals, mentor more junior peers, are able to drive complex feature development, communicate well with stakeholders, etc. But at the same time, I didnât have a good answer for the same question about a team lead, only a bunch of random ideas. I was surprised, I thought it must be obvious, but it wasnât.
After that, I started searching the Internet for possible answers, asked a few people in the company, including my lead, and was very much surprised by the range of answers I got. Some answers were overlapping but the priority of them was different đ¤ At the same time, I noticed the definition of the lead role, its key responsibilities, and even titles were different from post to post. Team leads, tech leads, engineering managers, all had interleaving descriptions and similarities as well as significant differences in their scope. Later I came across this post describing five engineering manager archetypes and that was a very good explanation of the observed answers range.
At the same time, there were common patterns among all the answers. Success was defined at the group level, rather than at the individual level. The leader was considered successful when the team is successful as a group. The leader is focused on multiplying team effect by supporting team members in different ways: setting focus and vision, fostering tech decisions, recruiting the best people, helping each team member to grow, creating a safe environment, establishing and improving processes, supporting team morale and so on. You see there is no mention of working on features, crafting architecture, or learning the latest fancy tech. Itâs a completely different role compared to engineering with its own different focus.
What about the code?
What about writing the code then?! I am good at it, does it mean I have to stop and donât code anymore? Well, the reality is that you shouldnât write the code anymore. It is not your focus anymore, itâs your team focus. There are a couple of exceptions though – if youâre in a pure tech lead role with somebody else wrangling the remaining responsibilities or if the team you lead is relatively small (up to 4 people) so you might have some time left for working on code. I also know a few leads with full-size teams who are able to book the slot in their calendar for coding work while keep doing all the rest, but the size of the slot is never above 10% and according to their words itâs really hard to fit in.
Does it mean all the experience you got about the code, architecture, patterns, and a ton of other things not needed anymore? Of course not! Itâs tremendously helpful for understanding the essence of software development, the process, and the way engineers think.
The shift from writing the code to doing many other things but not code also has a very interesting side effect – itâs harder to sense the feeling of accomplishment. When writing the code itâs obvious – you fixed the bug or shipped PR you got that feeling immediately! With a leadership role itâs different. The impact of your words, actions, and inactions may become noticeable long after you made them or even be left unnoticed (at least without explicit acknowledgment). So as a leader youâd need to adjust your brain to cope with the absence of that immediate accomplishment feeling and find your own ways of validating youâre on the right track, but thatâs a topic for another post story.
There are many more differences between leadership and engineering, and Iâve only scratched the surface of that iceberg. However, it should be enough to see that successful transition requires a shift in the mindset. The shift takes time no matter how well you are prepared in theory, so if youâre in the middle of a transition give yourself time to become a better leader for your team and you wonât regret it! If youâre only about to dive into leadership just know, itâs doable and itâs much better to step in being aware of the mind shift.
TLDR; In the book, Ann Dunwoody describes her journey within the US Army starting from the very beginning to the highest rank ever achieved by a female person at times of her service. Along the way, she shares a great number of thoughts and examples of both good and poor leadership encountered during the years of an outstanding career.
The book is written by Ann Dunwoody – the first four-star female general in the history of the US Army, and subtitled âLeadership strategies from Americaâs first female four-star generalâ. Iâm not very familiar with US army ranks but four stars sound like a significant achievement for anyone in the army. However, the fact that Ann achieved this being a female person in the very male-dominant system (at least that was my perception of the military before reading the book) makes it an outstanding achievement. I was curious about the story of Ann on its own but the leadership strategies part in the subtitle increased my team leadâs interest.
While reading the book it was obvious and impressive how Ann is very proud of her country and US army. Sometimes I even thought it couldnât be ideal like that in reality, luckily there were moments in the book describing very tough challenges physical and mental, how arrogant male officers would try to put her down or obstruct personal growth and fail in their attempts. I admire how Ann overcome those challenges and changed the perception of many about what a strong leader can achieve no matter what their gender is.
At times it was a bit hard to read the book due to multiple references to military ranks. Without understanding them the difficulty of a particular choice, the importance of new opportunity, or the overall context of the described cases wasnât fully clear. However, it wasnât too much trouble, I was able to get the essence of leadership examples and as a bonus got a better picture of how the US Army operates.
Speaking of leadership advice and examples, there were plenty of them along the lines and I found them very useful and inspiring. My quotes list from the book got too long to publish in a single post, moreover, some of the quotes cover pretty broad topics deserving their own post. Thatâs why Iâm sharing only some of my top picks.
You train people so they donât flail or fail – you train them to succeed.
In my opinion, thatâs a great mindset for leaders to have – focus on what needs to happen or to be done for success, rather than making minimum to escape failure. Despite the quote mentions people training, I think it applies to success in general as well, no matter if it is your success, direct reportâs success, teamâs success, company success, etc. Once the leader is aware of the success definition for each individual case they can work towards it.
The most important leadership lessons I learned throughout my career came directly from someone who took the time to teach, coach, and share ideas with me.
This is so true and I fully agree. What I also like in this quote is that one could receive and give support at the same time. I really appreciate the intention, time, and knowledge of people who mentors and coaches me, and at the same time, Iâm doing my best to pay back and forward.
Never walk by a mistake
That rule might sound arguable and I think even be harmful if applied at the extreme level, but the idea is very powerful. An unaddressed mistake sets a lower standard by giving a signal to a person or a group that a particular level of quality/behavior is acceptable. After a few confirmations (unactioned mistakes) the lower standard transforms into the implicit culture. Thatâs why spotting, acknowledging, and working with mistakes helps to update the standard and support the culture.
So this rule should be considered in the context of the culture youâre supporting. Never walk by a mistake disrupting your culture. Even if itâs small enough itâs way easier to fix it until it grows into something huge like a snowball.
Do the right thing for the right reason
Courage is defined in the book as âHaving the guts to do the right thing for the right reasonsâ. This is so true, whether itâs speaking up, having a tough conversation, letting the person go, stepping back, or anything else, leaders need the courage to get out of their comfort zone and âJust Do Itâ :trademark: It may look like something easy to do in theory but very hard in practice at times.
To maximize potential – ⌠– leaders need to look in the mirror and at their immediate surroundings to figure out whatâs missing. Those courageous enough to embrace the power of diversity will thrive.
People are different, everyone has their own unique background – the mix of history, knowledge, culture, environment, and experience. It applies to people you work with and people you create products and services for. So our background inevitably affects any opinions, thoughts, or biases we have and limits our ability to see a bigger picture. Thatâs where the power of diversity is needed to look at the problem from various perspectives, assemble the pieces of the puzzle, and make better decisions.
Everybody is replaceable – kings and queens, generals, CEOs, Hall of Fame athletes. Great leaders should be prepared to fire themselves and help find their heir apparent.
No comments here, just fully agree and love that idea.
I got the book more than a year ago as part of the employee welcome pack at Automattic and it spent some time on the bookshelf before I finally read it. I enjoyed the book a lot and recommend reading it with a pencil, notebook, or any other tool of your choice to collect the leadership wisdom dimes and bring them to life for the win.
Vasily Belolapotkov 