Move fast and intentionally ignore a couple of things
Disclaimer
This post is a summary and mix of a couple of drafts I had stashed at medium for at least 4 years. I speak for myself here, not my current or former employers. I wrote this to remember certain things in my career and hopefully it may be useful to others. It comes up in my priority list when I chat with friends about the state of engineering management.
If I had to point an article about this subject with way more actionable points in a broader context, I'd say read (and re-read) this interview with Joe Stump. There are books, videos and approaches but this is a no-nonsense straight to the point guide for Engineering Managers. For the benefit of the people working with you I also recommend reading this post by Michael Lopp about 1:1s.
Audience
This is what I wanted to read when I moved from the technical track to the engineering management track. I understand there are many paths, and I'd like to make clear which group of people I want to reach.
If you planned to be a manager since you were young, If you work in the HR for a tech or non-tech company trying to figure out what to do for your engineers, if you are a CIO or Director of technology looking up on how to adapt to the new times I appreciate the time but you are set already. Most of what I am writing here might sound non-sense or rebellious. You are not my target. If you see that I can help, reach out and let's talk.
I want to reach the programmer, the tech guy, the sysadmin, the person that grew up doing stuff and was around when the company grew and got pushed into the management track. I want the person who once said "I'll never be a manager" and that got into it for any reason. I want to reach you that considered moving to this path due to opportunity, wanting to do something new, not believing there what you are sold about career plans and paths that can promises you stability until you retire.
This is a big post and maybe I'll break this up in the future and make some cards. It is a living post too as I get feedback and fix it up. I hope it helps. If this doesn't helps or gets you offended, I'm sorry but I did it for free.
Engineering versus Management
I can't say that management was a planned path to me — it was a transition I did. After some time in my career, I thought it would be interesting to try my hand in management after watching other managers results. I figured it could be the path to fix what made me unhappy about my growth. That genius moment didn't came fast or easy tho.
Management/Engineering ladder or Y career model is a term used to describe different profiles inside the same company. I call it a myth or scam because the implemented cases I saw were more about carrot-and-stick for tech people retention than the real prospect of monetary equity.
At the time I did my transition the myth of the Y Career was strong in promises but rare in opportunities — manager to tech leads ratio was over 10 to 1 at most companies. We, the tech team were told that managers were people that "are doing the boring HR work" or "isolating us from business requests" and that by working hard we could aim to a place where money and benefits were equal to managers and that would be life.
I believe the Y career model is good a temporary step while the company can't equal compensation and accountability to every member in the team based in their importance and without the meritocracy silliness, in a transparent way. It is a patch to what was instituted in the 50s corporate ladder, where becoming a manager was the end goal for employees and it didn't made sense to compensate commodity workers in the same way you did for executives.
It is better than nothing, far from optimal. You don't believe that ? Check out how much money companies pay for licenses, people and servers when their world is crashing versus when everything is good.
Is it my call of duty ?
I can say I experienced distinct management styles and scenarios; from the CYA based management to a more technical and product oriented management during this pre-manager time.
Over time, I had the feeling that only working as a technical contributor was not sustainable if I wanted to grow. It was also clear that the money flowed in a different direction and that having non-tech managers close to places where decision was made was causing a lot of rework and miscommunication.
Considering past opportunities that I declined in favour of not believing in the traditional management career I saw that I had to experiment in this "side" before making a final decision instead of delegating this to a career plan designed by someone in a company.
I knew what I did, I knew what I didn't like my managers did and I had some good role models, so why not ? I knew the golden rule so that should be easy right ? Wrong. The first barrier to overcome was that I didn't knew it was possible to me to be a manager, therefore I've had convinced myself to not pursue it — first because it seemed unattainable to get there and then under the "boring non-tech work" excuse.
At your first job, what did you think when you saw your manager or director cruising away in a big car ? In which order "I could do that" came to your mind ? It was hard to me to relate how people got into this position. Actually I've never questioned it. It looked like they were born like that.
After the aforementioned "I know how to do it " moment, I committed to get the next opportunity to lead a team and apply the same energy I did when learning a new language or on-boarding into a new team. I've vowed to start small leveraging what I knew, studying with the few technical managers available and trying to avoid making mistakes.
Turns out I did a lot of them. And while I was learning, my responsibilities increased. I started small (a 4 people team) and quickly saw myself managing half of the company tech team for reasons I should put in another post. One of the most common mistakes is not learning to say "No" soon enough.
Over time the people I managed changed, naturally as the people joining companies changed too. Furthermore my management style had to adapt, in communication and expectations.
Adapting meant trying to figure out how my team expectations changed. A generation ago the main worry was to lose your job, today companies have a hard time recruiting because good technical people don't want to have a job for a long time without meaningful space to create an impact. My first management experience was on a team with everyone mostly my age, my last one was with an average ten-years younger. It is impossible to come across with the same arguments for such a demographic range without sounding silly and inefficient.
I had the luck of working with the best people around and see a lot of them becoming managers, tech leads, working abroad and competing with good advantage to people from countries that put more emphasis in tech than Brazil. That makes me proud and my life was easier because of them.
Knowing what your team does makes your life easy. Looks like a weird thing to say, but answer this: if you had to start from where someone of your team is working today, would you know how hard is to do their job ? Would you be able to deliver, ask for help, convince your peers , burn the midnight oil or get back to management with a convincing argument about doing or not doing it ?
Harvard Business Review published an article based on a study that says "If your boss could do your job, You are more likely to be happier at work" . Besides asserting what I wrote before, it says that the common wisdom of promoting people from the team to management positions being a bad thing is wrong. It isn't easy for the new manager, but it is not a bad thing to let someone that has tech experience to manage the team. It also helps shoot down the myth of the Y career. Leadership is a natural progression and can be learned. Leadership emerges.
Your team
Regardless of how much importance is put in tech teams in a company, people are the most powerful asset. This sounds cheesy, but for companies that hire 100s of developers and tech is seem as a commodity and for companies that have a small team which holds the company's life in their hands, people make the difference.
You know that when you work as a tech person in the team, you see things from a different angle than when you are managing a team. Especially when you start managing a team and you find out they are leaving due to the former manager or because of toxic culture. Tough luck if it happens to you but do not lose hope. It's similar to buying an old car…
You will have plenty of opportunities to mess up, but this one wasn’t your fault. Learn to hire (go speak in conferences, abuse the hallway track, pay lunches/coffee/dinner, open your company to communities, reach out to friends), learn to fire (underperformers, jerks, gossipers).
People have to have purpose to perform well. They should feel that they belong to something and feel that whoever is leading supports and works to keep them safe. Safe is not "treating people like children" but safe as in "if you own it we have your back". Safety in terms of expressing what they think, support when trying and failing, getting rid of jerks and coaching everyone to be a potential leader.
I've started this post with a link to a post called "Why firing brilliant assholes is required to build a great engineering culture" by @joestump .This interview has so much more content and actionable points than just the title but it caught my eye along with Netflix culture deck I've read some years ago:
That was later rewritten and incorporated in their culture manual with a similar phrasing and more context.
On a dream team, there are no “brilliant jerks.” The cost to teamwork is just too high. Our view is that brilliant people are also capable of decent human interactions, and we insist upon that. When highly capable people work together in a collaborative context, they inspire each other to be more creative, more productive and ultimately more successful as a team than they could be as a collection of individuals.
"Brilliant jerks" by rule are not brilliant and take a lot of time and energy to manage from everyone, especially their peers. It is just not worth the time everyone spends and frankly not worth the production. I am yet to see a productive person cause impact without the minimal people skills.
I decided to not put up with this kind of personality early on after a lot of frustration, as a self-assessment anchor when I got a feedback that I behaved like a jerk and as a decision to destroy the myth that this is the default behaviour for tech people.
There are some rules from a book called "No Assholes rule" to assess if you are enabling or being a jerk:
- After encountering the person, do people feel oppressed, humiliated or otherwise worse about themselves?
- Does the person target people who are less powerful than him/her?
This works in both ways — when learning up your craft, depending on your personality you may converge to an aggressive style specially if cornered under pressure. Exercising empathy you can detect if you are falling in this trap before tagging others as jerks. You don't need to cuddle and be a clown all the time but learn some people skills.
Purpose is not only collecting their salary or vesting stock — this is good and necessary as much as impact on their industry and for themselves. But growing up, saving money, helping people to move on their careers, make successful products and get better. All of this is subjective and very particular but impossible to ignore. Learning what is the purpose of each person on your team is necessary.
Intermission — Tech Dramas
On small companies and teams CI/CD, monitoring, automation, processes, choice of programming language and code review/pair programming may be the first things you have to decide upon. Some of them for due diligence and the rest mainly to put out the week's drama. You'll always have the tension between whatever kind of Dev and Ops you implement and at this stage they come out louder as a scapegoat.
As the teams advances in maturity you'll see product management and tech culture more defined, the adjustment of the importance of tech in the org, the need for hiring and career plans.
After your company gets bigger these problems grow exponentially and you start to see leaks in your culture and morale tagged as "communication problems", a common misnomer. It is an important warning signal when HR hires "the influencer of the month" to give motivation talks.
Unhappiness, whining and rumours are normal. As soon as you acknowledge they exist and to some extent they are normal. Use your energy to build bridges and channels that this information can get to you after being filtered by the good sense of your team mates. Mondays are the worst day to take actions over this as the mood usually is not good (cut the bs about not loving mondays being a bad sign).
The top down “playing time is over”
At some point, you'll see smaller teams taking over old corporate IT teams and suggesting building instead of buying for some of the core components of the business. You might be the one leading it, the victim in the other side or just a passer by. There is a lot to learn in this situation, try to look for the balance: the "not invented here" syndrome is a waste of energy. Rebuilding the world just because of it gets in the way of getting things done and leads to endless Artsy-Engineering discussions, which leads to Bikeshed.
The other side of this is tech as commodity — when all tech you have is from outside vendors. It comes as "We have the brains, they sell the gruntwork" or "you guys spent 2 years trying to reinvent the wheel and we're making an Executive decision of buying Big O software" depending on how good or bad things are for the tech team.
In both cases proper planning, objectives and how to measure success is lacking in favour of knee-jerk reactions.
The importance of knowing what your team does, what your company do and having the nerve to express your point of view is that you will be closer to the birth of these decisions. They are not taken in the cafeteria or in all hands gathering. They are result of storming out frustration and discussions, which if you can't negotiate your way, there is a potential of trashing your tech team. In both cases the side effect is people leaving because if the higher ups don't care, why should they ? (remember they are not afraid of losing their job or not finding a new one).
All that said, while I was writing this post's drafts I stumbled in some news that caught my attention in companies with strong engineering culture and that I see as an adjustment of culture in face of results they were getting. On real big companies this is as hard to see from outside as planets around other stars. We rely on leaks, investors reports, outages and mass firings to get the data. And by adjustment I mean meaningful top-downs.
Facebook motto was "Move fast and break things", a motivational piece to own mistakes and quickly move forward. At the 2014 F8 event, they changed it to “Move Fast with Stable Infra”. The reasons behind it may not be different from other companies: investors, regulations, predictability, MTTR, SLAs and better customer experience.
Yahoo published that by cutting out QA steps led to better quality, shorter delivery times and other goodies. It does not mean that they are throwing code to production without ensuring that automation visibility is in place. It means the accountability shifted from a QA team to the engineers, using a continuous delivery system, when the code goes live if anything breaks it must to be fixed within the proper SLA. No more CYA by complaining about QA.
A couple of years ago a former Amazon engineer published the "Jeff Bezos Mandate". It is a commentary about Amazon being a platform and a list of things mandated and enforced at the engineering level to ensure this platform was to be.
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6) Anyone who doesn’t do this will be fired.
It doesn't seems important, but number 3 alone would warrant weeks of meetings at some companies and a round of beer on others. And by the rest of the post looks like Amazon enforcement was a bit more stronger than a weekly passive/aggressive reminder.
What we have there:
- going from crazy to crazy with stability is required, find your synchronism and don't bother the business because you wanted to push linux as your main network router and it failed.
- cutting out the test pipeline and telling engineers to own their quality, not because QA is bad but because cutting out who to blame forces empowerment. Saying you haven't delivered because you didn't have a free QA or DBA is not acceptable.
- jerry-rigging your stuff on any place is enforced with a ban from the paradise. This basically cuts any kind of slack you give to people that can't design and run their code alone but can't make the time to work in a team context.
Look at the guys I'm talking about: Facebook, Yahoo and Amazon. These adjustments on culture and behaviour means that a set of practices and culture paid off in a way that the traditional processes surrounding IT didn't. These processes mean less to leadership and execs than it does on other kind of companies. The team owns what is in production respecting a certain set of rules or a limited freedom. Ownership, accountability and other nice words are used to describe this effect.
Processes (why I learned to own production)
Traditional companies resort to ITIL or other traditional IT methodologies in hope that it helps figure out operations and delivery. When it gets to development, the same formula is applied with Agile methodologies or equivalent factory based ideas.
In both Development and Operations cases teams are assembled around these processes and meetings scheduled to link them to existing processes, converging to a spreadsheet and someone asking why deadlines are not being respected or how can we shrink the budget. Corporate managers versus Technical Managers.
At the same time in the last years DevOps, Facebook's Production Engineering and Google's SRE got in the middle of both teams, sometimes not to substitute them but as cry for help from development teams for more speed and freedom.
Google released a book on their SRE practices, meaning how they deliver service and software in a reliable manner. Companies tries to adopt this bundle of mixed methods to move fast but at the same time protect their business.
Given the proper context I don’t think development and operations are so distinct that they need different people and skillsets. I like to call this set of activities Delivery, which means the whole. Some business verticals and government rules require these activities to be separated (separation of duties) to allow your company to operate or to buy from you.
On the other hand, people with limited experience and weak self assessment fails miserably when trusting the same things it takes to build CRUD apps applies to operations (and the inverse is the worst: when thinking that by knowing Ansible and Python you can build business applications right away). This is a mixed problem of feedback, ego, firing and coaching. Fools rush where angels fear to tread.
What most traditional companies have not explored is taking out these processes-based roles, and probably people that fill these roles, out of the production pipeline. This is what companies like Facebook and Yahoo are saying they are doing when they say they shortened the path for production. In shorter words — distribute ownership. Often, people that failed in these companies try to sell what they saw being done as “Digital Transformation” to the aforementioned traditional companies. Run from that.
The regular production pipeline of creating software comes from the company/market/sales needs and ideas. It goes through a hopefully incremental development and deployment cycle and lives in an environment that is taken care of.
Customers use the new product, ask for new features, complain when it is offline or broken, the company lives through its pain, people exchange email blaming each other because things are not perfect and life goes on asking permission on processes that should ensure quality and stability.
In the book "High Output Management", Andy Groove (Former CEO of Intel) uses a breakfast factory to illustrate production line. One of the key metrics to plan a proper production line is the time on the task that takes more time. If you are preparing a breakfast manually (cooked eggs, toast and coffee), cooking eggs should be the first activity started in one of the presented scenarios due to the time it takes to get it done and the difficulty involved if compared to making coffee and toasts.
Many scenarios are explored and it is possible to grasp the idea of waste, delivery time and investment on production. In many cases, tentative improvements to machinery in a single place of the production line come out as waste when put together at the end. I can't recommend this book enough as it is an historical document where you can see the beginnings of many of our industries practices there — for example OKRs.
It looks controversial but in my opinion the team building a product should not delegate the product knowledge to third parties, as it should not delegate production issues, priority discussion, deployment and architecture decisions.
Having people from other teams inside your team is beneficial and recommended as it improves trust and relationship. Delegating the burden of decisions doesn't work as good as having everyone in the same context. No more "I want to do cool engineering instead of bug fix" drama if the engineer understands revenue and time to market, no more "Why another week to refactor" if the product person understand how better everyone's life will be.
All this requires a set of skills and ownership hard to achieve first hand so empathy can be used to understand what is going on when your organisation has this division. If your tech org still has functional team it means that for whoever that is accountable in a higher level things are not as green as it appears. Be sure you don't know everything about all the things.
Disagree and commit (the art of not giving a f*)
Disagree and commit means more than what is discussed on modern self-managed teams or management 3.0 material. Company performance awareness is important in this growth process. As we saw in the adjustments from Yahoo, Amazon and Facebook that we could track, there might be top downs at the executive level but more often disagreements will happen in local groups.
In an ideal team context, discussions would not veer too far of what the culture dictates. Some people will be more laid back, others more vocal. Once in a while, you will have an argument but usually it settles back. When tech management is lacking, there will be long discussions. The gauge to me is that as the discussion grows, if no action is taken, it quickly becomes meaningless. It becomes an ego exercise as I mentioned before for bikeshedding.
If this is frequent and impacting delivery, the company will institute the ARB — Architectural Review Board. In an attempt of not telling people what to do or owning up decisions you end up with a tribune to replicate the same discussions in public, like old Rome.
This is the answer of busy executives mixed with the generic "communication problem". There will be no meaningful decisions, at most the most vocal person may get some space but this kind of personality rarely comes with good execution skills. This feels different than "disagree and commit", it is a "sit down and be quiet". And far from buy-in, the side that "lost" (as they will rightfully perceive the outcome) will just wait to get delighted by the failure or collectively think about leaving to create an impact.
This is one of the cases where a good part of you leadership leaves, which is a team as hard to build as a good engineering team. Naturally we think that if the not-so-good people leave we will be in a good spot but that's rarely the case alone. There will be different composition to the horde of unhappy, and there is a cascading effect coming from the conversation this team have out of band.
There is no way out of team work in tech teams. Someone will leave, get sick, get fired, make wrong decisions, interfere with other people work, change what they don't know, lose interest and so on. If you delegate all to the communal decisions, as in hippie societies, everyone will end up naked, stoned and no work is done. If you are in this situation I recommend asking yourself a couple of questions:
- Is this ARB/Committee/Quality initiative in place because my boss can't make a decision? Is he willing to commit on behalf of us given the past results? What happened that he is not calling the shots alone anymore ?
- Is the team tension big enough that no one is willing to commit to changing our culture? Better let the current culture take over and leave by 5PM so I can have time to brew/drone/play guitar/learn how to write my name in a rice ?
- Is my boss about to get replaced because we have not delivered? Is he being replaced due to politics that we can't see while we argue about tabs vs spaces?
- Should I put up with this or find something better to do?
- Should I capitulate and find out how can I revert this ? Would I be able to do that? Is this an opportunity to grow?
TL;DR
Don't hesitate to try your hand on technical management if you considered that for at least 1 minute in the recent past. You can try it, you won't lose what you know and the world needs better leaders. The transition may looks tough, but refer to the text above and push forward.
Your role as an Engineering Manager is avoid getting to this mess. Not only you should know what your team does, as you should have enough weight to negotiate among your peers and give the proper coaching. Your voice should be worth something.
You should not run away and avoid telling people to cut the crap and get work done as much as coaching them, when they are not comfortable or they are growing up. You should be able to find support when you are in this spot but don't know what to do.
You should work on being technically relevant, without competing with your team or letting your ego go. You must give and ask for feedback and remember that you are accountable for both.
To be actively learning is important to relate to what your team does. You can be the person they go to get consultation and even not being actively developing software you can coach them to find out the answer or call out silly requirements. It will give you a good way to say no without sounding like a dictator.
Be calm in the face of adversity — Don't Panic. You are the person that can't panic, even if your stomach is churning, you feel your legs weak, remember there are people that look up to you for guidance and solace. So calm down, breath and move on.
You must constantly (I'd say each 6 months or so) evaluate if it is worth for you to keep doing what you do in the place you are working. There are plenty of good opportunities around. You will survive.
There is no running out of fights here if you believe your heart is in the right place about the company, the team and your career. What you gonna do?
Note for my reviewers
This post grew up overtime and I wanted to put it out of my system in a good form as I derived other works from ideas contained here. There is a version of this in Brazilian Portuguese with the specifics for this market and culture but you know, this post alone took around 4 years, I may do that when I retire.
I would like to thank all reviews I got into this long post. The list is long for beta readers and reviewers so I will thank Alexandre Dos Santos, Renato Lucindo both for the exhaustive, detailed and candid reviews and extend the thanks fo anyone that read that, clapped, sent me a note or rightfully ignored. I asked for a read, everyone gave me back a lot of energy and direction.
Thank you
