- Introduction
- Engineering vs Management
- Know your team
- Decisions
- TL;DR
- The plan
- Learning and Measuring
- Challenges
- Org structure
- Delivery
- Closing advices
This ebook was created from a post with a big title. Actually many posts that I've written through the last years. I usually post some pieces here and there, send to friends and let them get old before revisiting.
Companies we have today have different meaning for the CTO role. Indeed for any technical leadership.
Sometimes it is a broad role, other times is per business unit or marketed as "Head of X". You will find it named as the tech lead, engineering manager, director of engineering, VP of Engineering or CTO. In general it means someone is fulfilling a tech leadership role.
I wanted to define it because there are many combinations and measures of success, depending on where this role is positioned and its relationship with the company.
The timing I will talk about in this ebook is when joining a new company or getting promoted. The situation I want to talk about is figuring out where to start. I choose it because during my professional life and mentoring sessions this is where most technical leadership struggles to get momentum.
And why 90 days ? It seems a good time measure. Honestly you won't have the time. Things go so fast that sometimes it looks like you are always late. But it is a good time window to look back. Companies pace their lives in quarters.
I've had the luck of having great mentors and managers, and not so good managers that provided me plenty of opportunities or examples of what not to do.
Besides regular work, I've been helping startup CTOs and other tech leads as a mentor for some years, mostly learning with them and helping where I can. I took notes. A lot of them. I also keep diaries about my own professional experiences that I review from time to time.
When we are growing, we are used to look only for stellar success and fear big failures but there is a lot in between.
But what struck me most is how starting is hard, even if you started many times. There are so many variables that it is unfair to think you will be able to cover most of them. And when you start, you are in a hurry to show some service, to help and succeed, which mounts up the pressure.
Every change or promotion is a new start and there are two important aspects: you and what you will be doing for the next years. There are many canned disciplines: taking it easy, failing fast, delivering faster but in the end you will only find out what you need to do while doing it.
The problems are not so different but the people are. And the space they have to attack these issues too. When leadership is needed, having a minimally structured plan goes a long way.
I've divided this ebook in two parts. One for you, to consider your career and look at situations that you may get caught personally while developing or adapting your style. It goes from this Introduction to TL;DR. These chapters are personal and based on observations while in transition.
After that we talk about how to start, where to look for and what to measure. The section from The Plan to the end has what you need to know to get prepared. This is the real field guide, where you can fill the spaces and get going. You can jump directly to The Plan.
This is an opinionated guide because... well, they are my opinions and experiences.
Good reading !
I can't say that management was a planned path to me. After some time as an engineer, I thought it would be interesting to try my hand in management after watching other managers work. 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 because the implemented cases I saw were more about retention than the real prospect of monetary equity or a path where you could move between careers without prejudice. This is called "pendulum career".
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 way over 10 to 1 at most companies.
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.
Don't take me bad - I believe the Y career model is a good temporary step while the company can't equal compensation and accountability to every member in the team based in their importance in a transparent way. It is a patch to the 1950s corporate ladder all companies implement, 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 executives.
This discussion is only possible by the radical change on engineering culture that we are seeing in the last 10 years. The market for engineers and people that can manage them changed radically, old school managers are pressed to learn and behave in ways that their peers from 20 years ago would not even imagine.
Acceptable behaviors from Engineers and Managers also shifted radically, long are gone the days of the insufferable genius or the distant technology executive. For instance, no manager worth their salt nowadays don't do 1:1s (For the benefit of the people working with you I recommend reading this post by Michael Lopp about 1:1s).
I can say I experienced distinct management styles and scenarios; from the CYA based management to a more technical and product oriented management during my pre-manager time.
Over time, I had the feeling that being a technical contributor was not enough 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 favor of not believing in the traditional management career, at some point I started to believe that I had to experiment this change.
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 know 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.
What did you think when you saw your manager or director cruising away in a big car in your first job ? In which order "I could do that" came to your mind ? It was hard to me to relate how people got into this position. I've had never questioned that.
After the aforementioned "I know how to do it" moment, I committed to myself that I'd embrace 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 company, to start small leveraging what I knew.
Everyone can and should lead and that's different from managing. To manage is to care about time, outcome, expectation and a world of nice words. To lead is connected to action and execution.
The timing of my career change was interesting - the company I was working with was doing great financially but having problems on engineering and product. Managers where leaving and at some point someone was needed to help a team that worked with a legacy product no one wanted to touch. I was lucky to be in the right place.
I've approached the challenge trying to avoid too many mistakes but eager to learn what would be my new career. 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.
The only advice I had was "be careful to not back into your comfort zone" meaning I shouldn't not compete with the team by coding or making their decisions when I faced some uncomfortable situations where I questioned my choice.
If you are in this situation you will remember fondly the time when you just coded, but think again - you never did that if you were leading. We tend to see the past in warm colours.
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 concern 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 have an impact. Around the same time getting straight tickets of what to do was a plus and now it is unthinkable to not involve your team on prioritization.
I had the luck of had worked 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 ?
It also states that the common wisdom of promoting people from the team to management positions being a bad thing is wrong. Life isn't easy for any new manager, but it is not a bad thing to let someone that has tech experience to try and manage a small team, learn and go from there. It also helps shoot down the myth of the Y career. Leadership is a natural progression and can be learned.
I also learned that Leadership emerges. Pay attention to who you work with, invest time helping grow new leaders. An imposed leadership will rarely work with a team.
Regardless of how much importance is put in tech teams in a company, people are their most powerful asset. This sounds cheesy, but both in companies that hire 100s of developers and tech is seem as a commodity than for companies that have a small team which holds the company's life in their hands, people make the difference.
When you work as a tech contributor in the team, you see things from a different angle than when you are managing a team. It hits specially hard when 2 weeks after you arrive you find out people are leaving for any reason: a new company in the market paying more, the former manager messed up, a key person left or excess work.
When it happened to me, I didn't knew what to do, but a friend told me to start hiring. Tough luck if it happens to you but do not lose hope, it happens. You will have plenty of opportunities to mess up, but if you are just getting there, this one wasn’t your fault.
People have to feel 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 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.
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 for your own growth. Have empathy.
The team culture is made from everyone's contribution and it is hard to see at first how you influence it as a leader and how each of the personalities plays into it.
It is important to be consistently hiring in a way that you spot your biases and improve diversity.
Firing is equally important to keep a healthy culture. It is not hard to spot culture aggressors. I want to point two: The brilliant jerks and tech dramas.
Getting involved on recruiting, interviewing and sending offers changed my point of view on retention in these situations. You have to be always recruiting, recruiting pipelines are hard to warm up and if you don't do that often by the time you remember them you it is an emergency.
Learn to recruit and hire (visit and speak in conferences, abuse the hallway track, pay lunches/coffee/dinner, open your company to communities, reach out to friends). Also, very important: learn to fire. It is tough, but important. Specially jerks (we will discuss them below).
Hiring depends a lot on networking, no HR team can do it alone. And it is a network effect. You hire good people, more good people come. But also you should start developing your current team and having them to speak, collaborate with OpenSource projects and the community. That makes for a stronger attractor and helps you balance your culture mixing what was created at your company with what new people bring that is positive.
If I had to point an article about engineering culture in a broader context I say read (and re-read) this interview with Joe Stump.
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 positive impact without the minimal people skills.
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. This behavior can come from any role: Engineers, Product Managers, Engineering Managers and executives.
To be fair we all were perceived as a difficult person at some point. Feedback is important to change but also don't hesitate to look for help.
You don't need to cuddle and be a clown all the time but learn some people skills. It is very important to sought for help, having the support of a trained psychologist or mentor makes all the difference.
When small companies and teams start growing, things like CI/CD, monitoring, automation, processes, choice of programming language and code review/pair programming will require a decision. 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.
Unhappiness, whining and rumors are normal. As soon as you acknowledge they exist and to some extent they are normal, the best. 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.
Also a tip here: there are rumors about you. Some of them will make you want to get in front of everyone and yell they are wrong. You know you are not like this. This is normal but may be partially your fault. No one deserves to be the subject of unfounded rumors but a phrase not well connected or decision not explained can lead to that. Chill.
Mondays are the worst day to take actions over this as the mood usually is not good (cut the bullshit about not loving Mondays being a bad sign, everyone is entitled to have their bad day of choice).
One of the hardest things to do is to explain decisions. Specially when the mood is that "anything outside of the team is a Top Down". Top downs are sort of a silly ghost haunting teams, which is hard to chase. They don't exist most of the time - what exists is an asymmetry of the decisions based on priority, urgency, execution power or capabilities.
You'll see smaller teams taking over old corporate IT structures to build instead of buying some of the components of the business. You might be the one leading it, the victim in the losing side of it or just a passerby. Depending on it a decision of one team can be perceived as a Top Down to the other.
The contrary movement happens too: tech as commodity — when all technology you have is from outside vendors. It comes as "We have the brains, they execute" or "you guys spent 2 years trying to reinvent the wheel and we're making an Executive decision of buying Big O software". Same energy and awareness issue. Where transparency failed ? Where all nice agile presentations were gone ?
In both cases proper planning, objectives and how to measure success is left in second or third place in lieu of knee-jerk reactions. We will see that below, after The Plan.
The importance of knowing what your team does, what your company do and having the courage to express your point of view is that you will be closer to the birth of these decisions. They are not made 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 finding planets around distant stars. We rely on leaks, investors reports, outages and mass firings to get the data. Ah, and by "adjustment of culture" I mean 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.
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- 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.
- It doesn’t matter what technology they use. HTTP, CORBA, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.
- 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.
- 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 companies 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.
But before moving to processes, I want to talk about another euphemism for top downs:
Disagree and commit means more than what is discussed on modern self-managed teams or management 3.0 material. Company performance awareness is important during growth.
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.
Ideally discussions would not extend beyond what the culture support. 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.
It is useful to me to track if no action is taken while the discussion volume increases. If no action is taken, no one moves, it quickly becomes meaningless. It becomes an ego exercise as I mentioned before for bikeshedding.
If no action is taken, if the team is constantly discussing it will impacts delivery.
The company will look for tools to help unlocking that from a high executive perspective: institute devices as 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. The other common device is bringing in outside experts.
These are the answers 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. It signal strongly that there is no effective engineering leadership.
It 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 may cause middle manager leadership to leave, 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. It is more common that competent people leaves altogether.
Another "disagree and commit" point are processes. Traditional companies resort to ITIL an 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, which describes 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. In the sections below you will see some of these practices selected to help you quickly get on your feet.
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 reverse: when thinking that by knowing Ansible and Python you can build business applications right away.
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. That is usually named "You build, you run".
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 among other things. One of the key metrics to plan a proper production line is the time on the task that takes more time. It is an interesting book to explore as it embodies most of how we work today.
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.
Your job 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 organization 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.
shamelessly stolen from https://twitter.com/chopeh/status/926074073767206912
Don't hesitate to migrate to management if you considered that for at least 1 minute in the recent past. You can safely try it, you won't lose what you know and the world needs better leaders. The transition may looks tough, but doable.
You will be technically relevant, without competing with your team or letting your ego go. You will give and ask for feedback and remember that you are accountable for both aspects of the work.
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.
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/12 months or so) evaluate if it is still worthwhile for you to keep doing what you do in the place you are working. There are plenty of good opportunities around if that's not the case and it will help you not to have this question coming up every time something happens. Take a time to think about it and move on.
And now, let's go for The Plan !
Before starting the new gig, even if the only time you have is the weekend before starting your new position, put a plan together. It doesn't need to be complex but it has to have a path to start, which you can go back after a full day and see progress.
You probably don't need or will check all items in there but it is a good baseline to learn how you evolved later on. It is good to look back and see how naive or to the point you were planning your start.
I created a slide deck to help organize this plan. It has high level questions based on items I describe in this book. You don't need to stick to the order there but you will see that there are some dependencies. You can find it here.
You can expand for your due diligence too if you end working on an M&A (Merge and Acquisition). At some sales processes you will be asked for questions and records on due diligence and that can help.
Ideally you will make notes after each section or subsection to revisit later or measure. The plan is to learn. The order is suggested based on information you need to learn to complete each step.
So, how do you say something is good or bad ? How do you demonstrate things that are obvious to you but not so obvious to the person or group you are talking to ? Apart from telepathy you can use known baselines and metrics from companies that you can relate and derive them.
After some time repeating "we did that in company X or Y" gets tired as you are not there anymore, your team does not works there. So having a simple deriving path help other people learn what you know, which is the first step to influence them.
I've grouped what concerns me when I make an assessment in four sections. For each one of the sections I've put together baseline metrics or concepts. Some are obvious as smarter people came before us and studied them, some of them require some imagination.
The first four metrics I've borrowed from the Accelerate book. If you have not read it, you should. It is a book based on research and as good research you will find a good taxonomy and baseline. Accelerate | by Nicole Forsgren, Jez Humble & Gene Kim.
The rational is: with the tools we have today, deploying should not be a problem and by deploying often we are able to fix what hurts us in the process. With that in mind we can look how a range of organizations are behaving, abstracting their internal decision path and focusing on metrics that are common across them.
There is a world of issues and problems in the way, ranging from quality to compliance but the idea is to iterate over this process to achieve a high rate of deployment with a low lead time and time to recover while measuring how failure happens. So this are the first four metrics to look for. They are there, somewhere in your organization.
* Deployment Frequency
* Lead time for changes
* MTTR (Mean Time To Recover)
* Change Rate Failure
I've added a metric of empathy to the folks that get the first call at your company, the invisible mob of customer experience and support teams:
* Incidents count per week
This is an important reality check on resourcing and prioritizing within teams, and often overlooked as "Stakeholder management issues". A lot of shadow work by your team is done to mitigate or compensate for this. Looking at change failure rate prevents its increase but having a strong foothold on incidents helps understand if all that you are doing is everything that should be done.
If you hear that your organization was "Sales Oriented" it becomes important as a way to gauge side effects of technical debt. A "sales request to feature" flow is no different than the "product feature request to code" flow if you don't take in account how your systems break and in which way they affect your customer life.
I've also added some metrics for my friends at the CFO office, under the umbrella of Cloud Economics:
* Monthly/yearly cloud expenses total and per product line
* Licenses costs
* Support cost
* Amount of discounts due to enterprise deals and negotiations
"We are just burning money, no worries about it, we're a startup" or "We are spending on cloud to save engineering time" concepts are amazingly misplaced and naive. Money only buys velocity if you are buying a racing car. Money buys tools to build things and money doesn't likes to be thrown around. You may get a free pass for a while spending and not knowing where the truth lies these truisms will hurt. That pass won't last forever.
Strive to know how much you spend, where are the low hanging fruit and how to feedback to business and the team how much they are spending. Engineers love a challenge and they like to see how well their code is performing. Cost of goods sold (a way of pricing what you sell) should include this. If no one asked you about it, be the first one to inform everyone and keep a tag on it.
I've lost count of times spent having to work overtime to reduce unexpected cloud billing or fix a big money leak found too late. Also lost sight of how much I worked double time to build yearly budgets in the last minute when someone high up learned this is the company's 2nd or 3rd biggest expense. Having a way to see it quickly and to see a pattern helps on both.
Here the term "metrics" is loose: look for and quantify how the team is working now, without prejudice or trying to change it. Map it well to try to find why it is like this, and what is the measure of success of each decision.
You will face a number of terms that may be familiar but are used with different meanings within the company. Teams, squads, tribes, chapters, guilds, teams (again for the sake of sanity), business units, great areas etc. Learn them, connect with the language. Build a glossary.
It is important to map where people don't want to work (the haunted teams), where are the heroes, where the real work happens and the territories. Yes territories, you may question why Team A has 30 people, all looking fresh and nice and why Team B have 2 disgruntled engineers. Learn this, it may be the reason you were brought in. By stretched managers I mean teams that should be split of managers accumulating teams.
The side-effect of siloed organizations (teams, tribes, squads) is that one way out of an argument is to duplicate work. This may be a strength or as most of the times, waste of energy. Look for work done within a tech team and/or by a product manager that should be automated or executed elsewhere. Mark it. Also look how prioritization and escalation works.
Who or which group call the shots ? How people know what to do. Look closely for slack channels that are used as "help" or "listening" channels with dynamics of people trying to get attention. Attend as many prioritization and planning ritual as you can to gather field experience.
Try to understand if escalations are done through "old friends" or is methodical. By escalations I mean any decision that could not be decided by peers or stakeholders and go up the chain to the CEO or other executive. If escalations is how most of things are decided and can undermine the belief on any prioritization process.
Is there a set of rules for deciding what to do ? Are there teams that feel "priority changes every time"? Have you heard "I am no people manager, just X manager" ? Is there a good positive tension between engineering and product people to decide what to do ? Does product work sounds like project management and engineering as body shop ? Take a note, you may need to figure out a standard prioritization process for everyone. A good team is a team where everyone has a voice.
Look for documents as PRD (Product Requirements Document), RFC (request for comment), definitions on PR review (pull request review). Is there a decision group in place ? How have the team decided to migrate from databases or cloud providers ? Was it generalised as "top down" ? It is healthy for an engineering team to create a way to discuss and document their decisions. It is good for training and onboarding.
Look for postmortems. It is good to remember why we never use web scale databases anymore or obscure niche tech. Don't fall into the trap of confusing autonomy with chaos of lost decision track, writing is good.
Figure it out if there is a small group of people that make these calls — all engineers should do it. Architecture groups and boards are a thing of the past, no smart engineer wants to work against a spec sheet. Use their seniority to train and gather consensus on why it is better to stick to 2 or 3 stacks than 200 semi-functional languages that only few people heard about. Help people improve their arguments and document them.
First order of the day: how do you evaluate, give feedback and help your team to grow ? Look for you company's career ladder, if you find none — it is one of the things you need to kickstart right away.
You can get inspired at Engineering Ladders for existing ladders and Levels.fyi for how they compare across companies.
I've put together an engineering/manager ladder based on what I've been using, based on impact and scope (reach within and outside the team) with parallels on both tracks.
Look for performance reviews and any document for your direct reports. No performance cycle process ? That's a consequence of a good ladder and there are tools to help automate it. You can do it straight on spreadsheets if needed.
No team will be healthy without knowing where they and, where they will go and without candid feedback about their performance and growth. Also remember there is no Y career — you need both careers (management and engineering) and a good write up on how the pendulum works there.
The questions below are to give you an insight of how HR interacts with the engineering team. There are companies where both teams seem to be at war and others where they work well. There is information that you will only learn in a neutral way by collaborating with your HR partner. Most of what you will have to work with people in your team you can only solve with them, for expertise and safety sake. You will find plenty of corporate disasters that could be avoided just by looping someone more experienced from HR to help or lead a conversation.
Hiring is everyone's job and highest priority. No "I can't interview because I'm putting out these fires" or "I can't talk to you because you are always on interviews". A lot of problems in engineering are due to poorly staffed teams. Work on it. If you don't know where to start, use my template:
Engineering Interview Templates
Make it so at least 3 people interview a candidate, one of them someone with good people skills (HR partner). Gather everyone together, compare notes and make a call based on how you all read the candidate. Ask the hard questions beyond "cultural fit". You don't want someone tame or aggressive, friend or public figure - you want the best for the team.
It is easy once you start organizing a basic interview guideline and a process where you ensure no biases are applied — it can use a daily or weekly committee to quickly assess the notes you took while interviewing. You take notes when you interview someone, right ?
Are there hidden functions ? (Infosec done by a SRE, prioritization done by committees) ?
Understaffed teams have a reason: no headcount, no leadership, reorgs, acquisitions, bad leadership. You have to learn about them and the whys. Prioritization done by committees appear here because that's the tool of micromanagers. Decisions require owners, the best teams own their decisions. The mediocre ones wait on external guidelines and quality of work suffer. You want to know about that.
Any functions/procedures depend on a single individual ? (e.g. the person that knows legacy code or how to deploy, or point of contact to solve an issue)
No heroes, no bus factor should be allowed for the sake of people's mental health. If you have them, HR can tell you the reason: new engineers only go for the nice frontend project, product is being discontinued, no one can put up to work with this or that person and so on. Something is up and you wanna know upfront.
Any team missing or leaving altogether ? Infosec, SRE or Platform infrastructure, Engineering tools, Data engineering, Data Science, Product Engineering, Digital channels, Notifications teams ? The big rewrite team ? The team that should manage the legacy while the rewrite team is doing their thing ?
Staffing decisions that you need context and history. Managers tend to leave a trail of destruction behind when they are under pressure and decide to leave. If you are joining a company or team because of that, look further.
There might be provisions for teams that can't be built. There are commitments that won't be fulfilled just by hiring.
How do you do it, how do you measure it. Tip: if remote work doesn't work for you, look up the chain of command. A good manager is required for remote team to be successful — good in the sense of communicating well, planning ahead and knowing how to organize team rituals.
We don't know how the world will be as we learn and adapt to all that happened but remote work was not optional. We got isolated and highly anxious about all things that we had for granted in the office.
The above applies - successful teams were able to navigate mostly due to reasonable management practices, sometimes leaning on the side of overworking and finding out adjustments.
I suggest you to run periodic surveys - it can be a simple NPS form or "What to start/stop/continue doing" format to assess team dynamics.
Also companies that had written practices as RFC, PRD, WIKIs and collaborative documents thrived as their async nature helped a lot. Hashicorp, makers of Terraform and other tools shared their written practices.
I'll use "Operations" as a generic fallback for day to day stuff that I have not covered above or covered only the metrics. These are questions you ask your peers outside of your team, your boss and if you have the chance, the person you are filling in for.
How do you know an incident from a bug ? Who listens first ? The CEO complaining in a public channel on Slack ? A loud person in the office crashing the coffee room looking for a senior engineer ? How does it help people now being interrupted unless something is really important ? How comfortable people outside of tech feel about its precision ?
Same as above: what is important, what is not ? At e-commerces companies, the purchase flow is king. Payment is important for most companies, conversion metrics, availability of the main website, server provisioning.
When something is down or broken and the team fixes it, how do they learn about it ? How do they make sure they will have time to fix it instead of implementing a new feature ?
"I wish I could do it but I am a product manager, not the team manager" or "it is done when is done, engineering is hard" are not good things to say. They make a team look along making the person saying it be perceived as unreliable. Team productivity using points, marshmallows or any gateway metric sucks and doesn't increase people's awareness of productivity. How is your team(s) productivity perceived and measured ?
Let me take this out of the way first: If you have an OKR or equivalent to measure closed bugs, kill it. Same for yearly bonuses triggered by some flat metric as "closed JIRA tickets". They set the wrong incentives, working on bugs, legacy code, improving quality is everyone's work.
Public kudos and prizes have to be carefully put in place: which behavior you want to foster ? How is this connected to growth expectations ? This is seen by the whole team and can create conditioning that working on bugs is less important for your career growth than working on new features.
How does the company deals with a misplaced incentive as someone focusing on what helps win a prize and leaving work behind ? It is common to find companies where employees with misaligned prizes (lunches, stars, days offs) are fired or leave.
It is important for you to understand how the team is conditioned. These incentives have to be aligned with the prioritization process that helps everyone.
Joining an existing team is hard, especially if it is during or after a reorganization. Reorganizations, or reorgs, are just a tool. Sometimes they are seen as punitive or meaningless but they are just a way of trying to tame the uncertainty of how a team should organize to achieve its objective.
Common questions are "Where will rejection come from ?", "What failure looks like ?", "Where are the leverages ?" and "When will the next reorg happen?"
One of the weirdest experiences you can have is to be hired and not have a defined team or role. This is when an executive is crying for help, hires a senior executive but forgets that if he can't deal with what is happening now, probably a new executive will fail.
It comes as a surprise to most CTOs and higher ups that the team is not "with them" all the time and are struggling for power — the one he delegated to a new comer. This is why gathering knowledge comes before defining strategies to meet challenges. Once you have clear data and objectives, personal reactions are just that: personal reactions.
Leading by example varies in intensity and subject. What does not work is to hire managers that don't know what the team does. "I take care of humans and I have someone to take care of technology" and "I deal with the boring business and HR stuff while you get your fingers dirt coding" are not smart things to say. Fortunately these managers are going away and you are stepping in.
Look out for starting small and simple, pair up with engineers. Set up your workstation and strive to push code out, a bug fix. Fail at that, but try to feel what your team feels when they are getting things done. Be part of rituals, planning and discussion. Tie break and top down, deal with the push back and strike new dialog venues.
Which public forums the team have ? How can they be heard ? (all hands, town halls, teams gathering)
There are always grapevines. People will be talking about you, about what you do and so on. But you need official channels, clear communication and transparency. Over time they get stronger and people start looking up for them. Don't try to shut down channels, build better and interesting ones.
Transparency is not abuse. On public forums, anonymous questions are good but for the sake of the team they should be respectful and naturally curious. Look up for the signal/noise ratio among hard questions. Take them upfront. If you feel you are not good enough to answer them, take a note, put them in a doc, answer later on and publish for everyone's consumption. Leave no question asked but repeated, silly and purposefully aggressive.
By influence or legacy a team can have many influence flows. First hires, the CTO-turned-engineer, the new director of engineering that worked there long before, the CTO that was fired, the product manager that migrated from engineering are some.
These are noisy but no noisier than having teams with split management: sales integration, marketing technology, operational squads. Look for having a clear objective and reporting line within your team. If this is not possible, they should not be there. At the end of the day, accountability is hard to be split across managers.
Every company you go nowadays you see a variation of the "Spotify Model". I won't even link because there are many posts around and I'm not sure even Spotify uses it anymore. The thing is that as it happened with Scrum, it layered roles and organizations over existing positions and teams.
Among the many permutations that create the illusion of control you will find yourself looking for the abstractions and controls that connect with your experience.
Looking to the average implementation of this model:
Each and every team/squad/tribe requires individuals of all chapters (disciplines): product, engineering, data, ops, finance. This started the trend of solid and dotted lines based on the concept that to make things easier and practical everyone should work closely. Solid lines are who manages you, dotted who manages your work.
This also creates some confusion and loosening accountability up until the general manager/tribe lead. All groups want a saying and should they balance their solid/dotted line hierarchy to do that ? Or the tribe lead ?
Using the old RASCI matrix may help but I found out that the R and A matters the most. Ask: "Who is responsible to get things done, who will be accountable if they don't".
Abstract all that and connect to your abstraction of choice. Follow the money: once you know productivity and prioritization flows plus the metrics that ensure a healthy engineering org, how do you influence it ? If it all goes away, how would you reorganize your team ? How you deal with conflicts across "tribes" ?
Emulating a small company you can move fast and absorb local optimization and debts. If the business changes a lot you end up having a lot of agility to tend these changes.
Cons: amplify the cost of simple decisions, as business grows it requires more high level arbitration
Matrix reports and their decision are a thing — a head of product for the company may not be happy if they can't do portfolio management. A CTO may not be happy if they can't do tech visions and engineering. A lot of intra tribe decisions trickle out to the origin organizations.
Cross tribe work is always painful. A local priority always takes over a distributed priority — you will hear that "The CEO is the tribe master and can fix it etc" — remember what real tribes did in the past when they met: Killed each other, conquered territories based on not knowing each other language. Be mindful of names and behaviors.
Shared efforts are hard to push. Some decisions coming from Legal, Finance and Infrastructure have goals and directions that can not always be consensus driven as costs management, undifferentiated lifting, standardization, compliance and due diligences. These are usually overseen and done in a hurry if it hurts the business.
Organisations that were not born this way (most if not all of them) may have shared codebase and processes. Who owns them prior to a big micro service split and rewrite ? Look up for teams called "ACME", "ATLAS", "PHOENIX" or "SKUNKWORKS" that "takes care of what no one is looking for"
Vertical Tribes over a thin engineering horizontal and a catch all back office team
The tribe model is too stretched, as we discussed cross business concerns are spread across individuals, it is hard to identify duplicated decisions and structures: If I don’t like your mobile framework, should I adopt a new one ? The cost of discussing it through the CTO may make deciding locally attractive.
A balanced approach for fast product teams taking in account the engineering and business undifferentiated lifting
After these stretches most organizations approach the independence problem from a Business Area with shared P&L (profit and loss) perspective, looking where sharing can optimize cost and speed. All that to say we always revert to the same model.
* Keep tribes where it make sense
* Invest on platforms, bottom heavy, light on product/customer interfaces
* Identify shared efforts
* Speak product language even for internal customers
* Shared P&L
Specifically for engineering organizations, nimbler product teams foster a strong dependency on APIs — you can't possibly predict permutations done at the edge of the product so sticking to strong APIs is a proven strategy.
Authentication, API management, InfoSec, Notification service, Digital channels management, Design, Cloud Economics, Developer tooling, Analytics and Data Engineering are naturally shared and costly to replicate locally.
These efforts benefit teams outside of technology or tribes and they are benefited from a solid strategy and operational efficiency. Undifferentiated lifting should be done once and for all.
I've mentioned the Accelerate book before and it provides a good framework to evaluate delivery. When I say delivery I mean the mix of running your systems and all activities connected to it, including building and shipping code and how it affects your customers.
Back in the day everything was slow and manual but after the wide adoption of cloud providers and disciplines as Devops, SRE and Production Engineering the effort of engineers in these teams are set to simplify operations through automation.
Adopt an observability tool and go beyond CPU/Disk/Latency metrics. Collect meaningful business metrics and operate from them. They should guide your decision as each platform presents multiple base metrics but few are not about something redundant (servers, disks, network).
A code template tool, abstraction to make engineering work secure and repeatable, automated deployment and monitoring are expensive but once built they take operations to a new level. They get heavy lifting out of the way.
Deploys should not be rituals. You need a way to track them but they should be done multiple times a day in a way that you can assess if prioritization, complexity or lack of purpose is the problem. Not access, arcane knowledge or risky environments. Having them integrated on how you build code is key. When code is merged, it goes to production. No special control panels.
Look for at least 70% of infra/deploys to be uniform, leave corner cases for data and mobile. Invest on short feature deployment cycles with product prioritization (lower lead time). Implement "You build You Run" in an standard way Simplify your stack — good engineering is boring. Avoid virtue signalling when building blocks: functional language, NoSQL databases, niche architectures are all nicer when they come naturally.
Investments in good infrastructure engineering yield good cost management.
It all starts when you Tag and control Cloud resources. No VM or disk should be up without information about team, product and owner. With that you can tag which products use the most, as the cloud dashboards are not that good on knowing how your platform is structured.
The next step is to conduct monthly resource distribution reviews. It means simply looking at how your money is distributed, low hanging fruits and new things happening in production. The least surprise principle applies.
These two items seems to be naive and easy but I strongly advice you start doing them right away, manually.
After a cycle of doing it manually, adopt at least one cloud cost management tool besides the one the cloud vendor provides. Besides usability you want neutrality. Tools that before being clear on what you are expending want to tell you how to save the money have mixed incentives. There are free and paid tools depending on your provider. They usually implement schedulers to park (turn off or stop) test, development and other unused resources at night and weekends if you are not using them.
Some cloud providers give you increasing discounts as your usage grows. Others rely on reservation, saving plans and ephemeral instances. Prepare for yearly planning to do a reservation (or the equivalent) cycle and monitor its usage. You don't want to commit and don't use it and it is easy to let it slip as capacity planning is hard. Opt for flexible commitments that let you convert credits among resources.
Only go for containers with a stable stack and after nailing CI/CD. Containers are great for density and usage, but nothing wrong with Virtual Machines if they fit your bill. Autoscaling suffers outside of Kubernetes but there are other benefits.
Speaking of which, when you go for specialized tools such as Kubernetes, you also have to go for specialized people and remember that distributed systems are hard. Pick your fight. The stable stack I've mentioned is the one that fits well your development model and containers. Don't stuff a huge application into a thing designed to grow horizontally. 2TB containers don't make sense.
Monitor egress and ingress traffic, cross region and hidden Cloud costs. For instance at the Open AWS GUIDE you will find a session about network costs. The $$ figures are not up to date but the flow is clear.
I've seen huge bills due to non mapped traffic through Managed NAT Gateways and poorly set S3 buckets. Same for EKS you can hurt yourself with cross zone traffic. Loose disk snapshots and images, unused load balancers and gateways are a source of hidden cost. Keep an eye on them, tidy up.
I've mentioned adopting observability, the "You build, You Run" model but the last part missing is to drive incident management processes, automation to protect delivery. We have a tendency to slow down when quality suffers. But quality is subjective.
It is easy to default to creating bureaucratic structures when it is hard to measure or understand what is happening. I suggest that if you don't have some sort of visibility yet, start doing the following:
* Publish weekly metrics reports, for everyone, start with the ones we discussed here.
* Organise monthly postmortems and learning events
* Get involved in incidents, be there, help coordinate, just watch, help write postmortems. Lead by example, and in this context the example is simple.
* Distribute the metric and measurement efforts to all teams, with reports published weekly by them. Start your big meetings with hand picked metrics review. The good and bad ones. Work on the bad ones, rinse and repeat.
Being on the losing end of a leak or security incident hurts. You are not alone. It is not if, it is when. Working with security has a double burden: it is always critical and you have to deal with the worst kind of initiative all around. Be mindful of your mental health all the times.
As a CTO or tech executive you may have to manage an Infosec team. Or step into one. Or deal with one of these teams out of your organization. I will hereby thread safely and respectfully giving the advice that helped me in such times.
The advice that helped me most is to hire people that really like Infosec, curious engineers that are willing to learn what they don't know. This is slightly different than seasoned or traditional Infosec engineers. Hire experienced security engineers to teach them and your team.
Strike a good balance there and you will be surprised, especially in the offensive security world. Software engineers learn fast and like to be challenged.
Get involved in communities as B-Sides, events as H2HC and so on.
Learn. Read a lot. I suggest this comprehensive Cloud Security guide:
The Extended AWS Security Ramp-Up Guide
I am saying all that because some may point that Infosec is for Infosec folks. But at tech startups the role is not clear. Sometimes it is derived from engineering, platform or infrastructure teams. Most of the time is a part time job until an incident happen.
This is positive as it brings folks to Infosec that wouldn't switch careers if not given the opportunity. Look where no one is looking. Make it easy for engineers to secure their apps and services as they do with testing. Trust no one, especially yourself and WebView mobile apps. Invest on hiring offensive engineers, or software engineers that like to break stuff. It pays off, a lot.
Read and learn about threat matrix, create a simple one and grow them. If your company is too small, look at the Infosec community for a consultant outside of big consulting companies.
Avoid at all costs an Infosec org that works as a barrier for people doing what they need to do. Train them to help you. This is important. The work is complex and you will deal with complex situations most of the time.
When you say no, people will try to negotiate around it and this will add to your frustration. This is not a side job. Break that cycle, separate what is business and compliance from the core Infosec mission of protecting the business. They work on different speeds.
For tooling — same advice as infrastructure: go for automation, find good pentesting and code review tools that plug on git and help you to improve development. Everything starts there, when you are in a rush you make bad choices.
Look for compliance advice that reflects on engineering decisions early: PII (private identifiable data) storage can change depending where you are, what you do which info you collect. Money spent here is money well spent.
Tie this with the work of your Data and Analytics team, write a data policy and data matrix that tells you the minimal requirements for GDPR (Europe), LGPD (Brazil), CCPA and other regulations around the world. Keep a strong track of data ancestry (where the data came from).
Read security incidents postmortems. Start by the Capital One Data Breach. You can find them everywhere, look for your organisation story and build them if they don’t exist.
If you don't have Infosec Metrics, start with two metrics:
* Incidents per month
* Time to fix vulnerabilities found by pen testing.
These are relevant to engineers, product managers and people outside of your organization. At some point, interrupting the team to fix security findings will appear in the top 5 reasons why a new feature was not delivered and it is good to have history.
You will probably manage a variety of Data teams combinations. Sometimes they will be close together, sometimes they will be far apart. It is important to note that companies will sometimes start something outside of the product/engineering team to do data science as an accelerator or valuation booster, not necessarily as part of the product.
It is also worth noting that Data means money spent on infrastructure and growing security and compliance risks. It comes to no help that good data infrastructure will step in when the product lacks features, sometimes not in the best way (bunch of python scripts, shadow IT holding PII data, endless support requests when a data source is broken or changed).
Data is valuable and deserves a few comments. There are some common teams that deal with Data:
Data Engineering: Sometimes data infra, but builds platform and data lakes, model data, automate ETLs and ingestions. You will see these teams migrating to support machine learning pipelines and large analytics efforts.
Analytics or BI: Coming from a corporate set and adapting, these are people that can figure out what the data means, build churn and regression models, support high executives on complex decisions by forecasting market or sales. A lot of data scientists sit there or start there to move on to specialized roles.
Data Science: People of all backgrounds are set to solve hard problems by using data. If you find a better description please let me know, I saw it a lot and all of them are different.
The foundation of a good Data Engineer is a good Engineer. The specialization is on tools and methodologies but overall you should look for good principles. Data Scientists without a good engineering foundation struggle to deliver. Analytics/BI without engineering usually does very well. Go figure.
Data engineering is not Devops. There is a migration of Infrastructure Engineers to Data due to affinity of platform and infrastructure but their mindset is different. Managing distributed databases, migrating data, draining and running queues may look as an infrastructure problem but it requires a different set of tools and knowledge.
This advice saved my life more times than I could count: “80% of a data scientist work is data engineering (data preparation and tooling) — Fabiane Nardon”
I live by this quote. Every company I worked for had a struggle between teams that was only solved when the engineering behind the work was understood and solved.
My advice for tech leads and engineering managers in Data Teams:
* Make people work together, avoid silos.
* Understand the engineering required to run complex data work but abstract the day to day analytics.
* Spend time and share objectives with your Infosec and Compliance teams, you will be looped into that anyway for a certification or notification.
* Create discipline to pick your tooling and avoid big migrations (anything over 10TB is hard to migrate timely in the cloud)
* Push work to the teams: analytics, data science, machine learning should be close to product, it doesn't work in a project office fashion. Look for Airbnb, Uber and Pinterest benchmarks. Break silos early on. Provide orthogonal structure and support tho.
* Work on model deployment (for machine learning models) early on.
* Be flexible on how you archive data. Migrating data is a pain in the cloud, duplicate it if needed (one archive sorted by date, same data sorted by user ID)
Avoid:
* Too many of each building block (e.g. standardise databases and caches as much as possible)
* Non partitioned databases
* Unmanaged mix between events/serverless and batch processing
* Building a scheduler (use Apache Airflow)
* Building a log pipeline (use ELK, use Athena/S3)
* Teams too far apart or disconnected
If you got curious I've put together a slide deck about a common data organization here.
It maps roles to teams, career ladder and a suggestion of how to tie together teams and types of work.
Is this a book ? Not yet. Not the authoritative source for what you should do. I've put down what helped me and not when it helped me, because I tried to abstract situations, companies and people.
When building or reorganizing teams, keep the span of control on 5 to 8 people for each manager, including you. Opt for line managers with small teams and clear objective and planning rituals that you can help instead of an overly hierarchical org. Engineering managers should support line managers, this is their most important job (a close) second only to hiring.
Advocate for standard stacks and technology. Not the one you love, but the ones that work well for the team. Make them accountable for delivery.
A good platform that makes deployment, observability and testing is worth 10x a language war. Fix that first.
You will find all kinds of discussions about it but done in production works great to improve morale and build knowledge. No decision is permanent. Avoid virtue signaling.
Run a Manager Training session. It can be simple as a book reading club. I suggest you base it on the book “An Elegant Puzzle”. Conduct role playing sessions to learn how to give and receive feedback.
Remember that what brought you here is not guaranteed to work in the future. Learn how the new generations work, there is a lot to learn with them. Keep that in mind for the leaders in your team.
Drop the "blame the millennials" bullshit. Don't make them suffer what you did just because, don't be petty.
People are important, technology is a side-effect, Money can’t buy everything but helps a lot.
Good and smart engineering helps more. Don’t try to blindly save on tools that help your team.
Don't save going for less than optimal hiring. Cheap here means trouble later.
Writing will be what you will do most in the remote reality we have now. Go for a written culture that is better to keep up at different timezones.
I've found out a set of advices from Amazon on writing in this book. I try to stick to the to the following and it is a constant exercise to keep in line (hence this ebook being a git project with reviews):
Long sentences are hard to break and digest. Keep them short so the reader or listener can take it home and use it.
Time is short. It is tempting to give out a lot of context but make a clear judgement if that's needed. If so, write them down, send in advance and ask for the audience to be prepared if there is a presentation coming.
"Huge amazing rocketship !" can pass excitement but prefer "We grew 10% month over month in the last 6 months". Leave the adjectives for the audience or reader.
This is about doublespeak/corporate talk or uncertainty. Either you want something done, communicated or planned. It is important to know what you want and do it. If you go around too much the message will be buried and trust will go away.
Drop the ego when reading your paper or deck and ask "does it matter ? should I extend it ? shorten it ?". What's the value ? It may help kill a meeting that could be an informative email. Does people really care about an algorithm in a finance meeting ? Remember time is short, work on the message.
If you get a question, reply with "Yes", "No", A number or "I don't know, will follow up". Or any equivalent. Drop the storytelling
The summary is to take as stand and own what you are communicating or want to do. There are meetings and presentations that can be productive and others that go everywhere and leaves the audience frustrated as no decision was made.
Writing straight to the point means you know what you want and that's progress.
I am not a native English speaker so writing was hard for a while. On Writing Well provides actionable advice and helped me a lot. Work on it, communicating well is required.
And finally, you are the outsider, people tend to think the past was better than it really was. If there is a team, they will probably project on you the changes at some point.
Breathe, give some space. Be kind to yourself and straight clear when people step over your boundaries.
Have fun !