THE CTO

FIELD
GUIDE
GLEICON MORAES



© Gleicon Moraes

Gleicon Moraes
gleicon@gmail.com
https://the.cto eldguide.com
fi

Just do it (Mike or someone like that)

TABLE OF CONTENTS
Foreword 7
Starting is hard 9
Know your team 18
Decisions 28
TL;DR 40
The plan 42
Challenges 55
Delivery 64
Closing advices 73
Interview Templates 79
DATA TEAMS 85
INFOSEC TEAMS 89
CAREER LADDER 92

 FOREWORD
My proposition is bold but simple - to provide a eld guide for
tech leaders.
A eld guide was the kind of book that fascinated me when I
was a child - electronics eld guide for radio and television
repair were the kind of technical books and magazines a
weird kid could get in Brazil
I had a small collection - a tube eld guide, couple of
electronic magazines, one of them about TTL Chips and so
on. The recipes, part numbers, substitutions and example
schematics draw me to keep reading it, even not having a
single part around to play.
I also took interest on ham radio and later on audio circuits.
All of them properly furnished with whatever technical book
or guideline I could get my hands at.
Things changed a lot when I rst saw a computer in a friend’s
house - ZX81 clone called Ringo. And right after that a MSX
(z80 80s computer). I got interested on seeing the parts
inside but soon their eld guides took me to programming.
And there I am and still learning.
When I started to move to the management path, I set to
write about my experience (another childhood habit -
doodling and keeping a journal). I accumulated many pages
of my day to day, feedbacks, experiences, projects and later
on when I was invited to help startups to gure out team
growth, what I discussed with them, books, things we did
together and so on.
There were some patterns when I was mentoring - a CEO
looking to improve their relationship with a CTO, a senior
programmer pushed into CTO or head of engineering, a head
of engineering su ering the pains of quick growth and so on.
Counting with what was happening in my day jobs I was able
to learn a lot contributing and gather a lot of notes.
I started to publish that on my blog, then as the volume of
consulting and mentoring grew, to refer to that to fast track
fi


ff

fi
fi



fi
fi

fi
fi

 the sessions - we would have 1h per company, I wanted to

leave something afterwards to help.
That went on and on until it clicked on me - my noted were
my eld guide. A modest, straight and bound to get you from
point A to B o ering substitutions, part numbers, schematics
and reference implementations of things that were not
programming - they were about people, with tech side
e ects.
Having managed teams of 10, 180, 270, 46 and diverse sizes I
was able to apply what I learned and read, lter what worked
and adapt ideas.
After planning the rst 90 days in my current company I saw
that I had enough material to try to publish an ebook about it
and try to reach out other people with the same questions I
had.
I hope that what is here helps you. This is not an Engineering
Management book - it is a Field Guide. You can read it as you
want, parts, from top to bottom and so on. There are smarter
people writing about Engineering Management in all levels
but what I have to give is practical frameworks.
A word about English language - I worked for North American
companies and for Brazilian companies where English was
the main language there but it is not mine - I always struggled
to learn and improve it. As I already had two books published
in Portuguese, I wanted to try and learn how to publish a
book for the English reading audience. Well, this will have to
be it.
ff
fi





ff

fi

fi

 1.
STARTING IS HARD

T
his ebook was created from a blog post with a big
title. To be honest, from many posts that I've written
through the last years.
I usually write pieces here and there, send to friends
and let them get old before revisiting and making them
available. After a couple of these posts it seemed to me I was
going around the same subject: management and leadership.
Things that happened to me and that I wanted to keep it
somewhere in case I needed to remember.

Companies have di erent 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 nd it named as the tech lead, engineering manager,
director of engineering, VP of Engineering or CTO.





fi
ff





 In general it means someone is ful lling a tech leadership
role and sharing accountability for team, delivery or data. You
will also nd responsibilities closer to infrastructure or
security.

It is important to separate role from position and to de ne it

because there are many combinations and measures of
success, depending on where this role is positioned and its
relationship with the company.

A technology leader that just joined a company will have

challenges that a newly promoted leader won’t. A co-founder
moving laterally for a research position will face new
situations than a large organization leader.

This is what I call the timing - the timing I will talk about in this
ebook is joining a new company or getting promoted. The
situations I want to talk about is how and where to start.

I choose it because during my professional life and mentoring

sessions this is where most technical leadership struggles to
get momentum. Specially the rst 3 months, or 90 days in the
job.

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 so there
may be something interesting there.

WHY ME ?
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.














fi

fi


fi





fi


 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 nd
out what you need to do while doing it.

The problems are not so di erent 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.

HOW TO READ IT
Conceptually this ebook is divided in two parts. One is
personal, 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.











ff








fi
 From there on, we discuss how to start, where to look for and
what to measure.

These chapters and appendix are designed to help you

prepare and execute. This is the real eld guide, where you
can ll 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.

ENGINEERING VS MANAGEMENT
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 gured it could be the path to x what made me unhappy

about my growth. Of course, that genius moment didn't came
fast or easy.

Management/Engineering ladder or Y career model is a term

used to describe di erent pro les 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
















fi
fi








ff


fi
fi
fi





 requests" and that by working hard we could aim to a place
where money and bene ts were the same of 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.








fi




 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 insu erable
genius or the distant technology executive. For instance, no
manager worth their salt nowadays don't do 1:1s.

WAS IT MY CALL TO DUTY ?

I can say I experienced distinct management styles and
scenarios; from the CYA (Cover your a**) 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 owed in a di erent 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.

LEADING VS MANAGING
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  (Treat others as you want to be treated) so
that should be easy right ?










fl




ff



ff

 Wrong. The rst 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 rst 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 rst 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 di erent 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.

GLUE WORK
Once you get promoted and accumulating seniority, you
notice that even when not managing a lot of your work is
what is called “Glue Work”.

This is work that helps other people to get their work done -
step into a review, organize a reference document, debug,
read logs, assemble a meeting to discuss technical aspects,
push back on stakeholders and early warnings on complex
issues.

There is way more than that but that’s beyond janitorial work
and hard to measure by itself without looking to its impact.














fi







fi
fi
ff
 We all remember of the moment when we stepped out of our
attributions to help the team to deliver.

That’s an important signal to follow, it does not means that

everyone will lead then manage after this sort of work but it
generally gets one to see their manager work under a
di erent light. That was happening a lot to me.

SAYING NO AND ADAPTING

The timing of my career change was interesting - the
company I was working with was doing great nancially 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 colors.














ff







fi






 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 gure 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 we did in
Brazil. That makes me proud and my life was easier because
of them.














fi
 3.
KNOW YOUR TEAM

K
nowing 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".

It 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 and invest time helping grow new leaders. An
imposed leadership will rarely work with a team.

Regardless of how much importance a company assigns to

tech teams, 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 di erence.

When you work as a tech contributor in the team, you see

things from a di erent angle than when you are managing a
team. It hits specially hard when 2 weeks after you arrive to
lead a team that you nd out people are leaving for any
reason: a new company in the market paying more, the
former manager messed up culture, 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
















ff




fi
ff




 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.

TEAM CULTURE
The team culture is made from everyone's contribution
and it is hard to see at rst how you in uence 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 that we
will discuss right after hiring: The  brilliant jerks  and  tech
dramas.

HIRING (AND FIRING)

Getting involved on recruiting, interviewing and sending
o ers 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/co ee/dinner, open
your company to communities, reach out to friends). Also,










ff

fi





fl
ff







 very important: learn to re. It is tough, but important.

Hiring depends a lot on networking, no HR team can do it

alone. And it is a network e ect. 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.

BRILLIANT JERKS
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 me when he pointed the
damage that an individual can in ict into a team. Early on, the
Net ix culture deck had this slide:






fl


fi
ff

fl







 That was later rewritten and incorporated in  their culture
manual with a similar phrasing and more context, probably to
cope with the reality of a top of the market team.

There are no “brilliant jerks.” if you have a dream team. It is

utopia to think everyone will always behave on their best but
you will spot it.

The cost to teamwork is just too high. There are that person
or situation that is hard to push by. It is not a matter of
position - although they usually breed on senior positions.

Brilliant people are also capable of decent human

interactions, and we should 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 di cult person at some

point. Feedback is important to change but also don't hesitate
to look for help.

It is very important to look for help, having the support of a

trained psychologist or mentor makes all the di erence. Most
of the times these perceived behaviours are due to issues
that we won’t resolve alone or in the workplace.

THE CULTURAL HORSE WHISPERER

On the other spectrum of the brilliant jerk is the person
everyone loves but won’t ship. In the surface that may look
more positive than harmful but as the team gets promoted
two things can happen: either you promote these people and
expose what is not working on how you evaluate impact and
that sets the wrong example across your team.

As much as we love to love people, it is a setback to have

non negotiated di erences in roles on the team. If you have
several senior engineers and one of them spends time not












ff




ffi


ff



 shipping but everywhere on conferences or activities the
others can not access, it can be perceived as an unfair
exception or perk.

Note that this is di erent than the Glue Work we mentioned

before. Managing your culture works for all its aspects and it
is one of them to ensure all voices are heard and
opportunities are available to everyone, not to the folks that
have most free time.

You will note some of these folks if you have architects or

over the sta level, it is easy to loose sight of impact if you
have a signi cant change on your career. Your job is to help
them to understand and help shape what is their impact in
the organization.

TECH DRAMAS
When small companies and teams start growing, things
like CI/CD, monitoring, automation, processes, programming
language choice 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 de ned, the adjustment
of the importance of tech in the org, the need for hiring and
career plans.

After your company gets bigger these problems will grow

exponentially and you start to see leaks in your culture and
morale tagged as "communication problems", a common
misnomer.












fi
ff





ff





fi


 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 ltered 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 yell they are wrong. You know you are
not like this. 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. Don’t add to the drama,
address it straight and institute o ce hours, AMA (ask me
anything), 1:1s up to the point where you feel you gave people
enough venues and transparency.

But don’t over do it - remember that each and everyone is

accountable for part of the work and some decisions won’t
make everyone happy.

HYPER GROWTH
At one of the startups I’ve worked we grew the
engineering team from 140 to more than 500 engineers.
There are many reasons a startup do that, from real need to
get things done to vanity metrics imposed by comparing itself
to benchmarks.

You will nd a mix of all these situations; the real need for
help, engineering is not delivering, product got into the cycle
of blaming lack of bandwidth - which is interpreted as “we
need more engineers” and so on.

In that speci c case we had a couple of complicators: the

stack was not easy and we were really into the hyper growth
with a couple of big goals: international expansion and user
base growth.










fi
fi







ffi
fi
 In an organization con gured to deliver in parallel having
that many big goals among to other complex local goals is a
killer. We will discuss more of that on Chapter 7 - I want to
focus on growing the team.

We then organized ourselves to hire in parallel, to gure out

how to interview, grade and move the candidates through the
pipelines, which metrics were important and so on. It took a
lot of practice but we did it.

But there were a couple of unexpected situations:

- Hiring engineers is a function that won’t slow down if

you hit it right. Onboarding started to hurt us. There is no
slow down and pause button.
- We have not hired enough managers and tech leads to
help the teams to be healthy. There were teams that didn’t
knew what to do after their onboarding. Once we got
around 400 engineers we noticed that and had to warm
and execute a manager pipeline.
- Productivity falls when you hire and when most of your
team has less tenure time after time. You may end up with
2/3 of your team with less than one year of tenure. If your
adjusted productivity magic number was 1.0 you will nd
that it will fall to 0.7 and be there for a while, until you
gure onboarding, prioritization and how to keep everyone
busy.
- A team is one up until 40 people, then a di erent beast
after 75, then something else after 120 and a world of
di erence from there. These numbers can vary but all your
team do won’t t in your head. Work on your direct
management structure.
- It pays o to invest on onboarding and training. If you
are growing so fast, you are doing it for the long run.
Fancy stack choices will hurt you there and have to be fed
back into the development and engineering loop. Business
decisions will hurt how people are productive too.




fi
ff

ff
fi
fi






ff



fi
fi
 - Right after doubling the team we had to implement
proper ladder and performance evaluation. The managers
were not used to that, the team was not used to that and it
used a lot of time of people and engineering teams. That
was a re ection of not partnering early with People team
and hiring managers.
- We started to have groups of people ranging from 5
years of tenure to a couple of months, and among them it
started to show some cultural cracks. We had to address it
quickly and ensure that regardless of tenure, all voices
were heard. That had us to change how the manager
would behave and neutralize power plays.

These are good problems to have. But the dot product of

communication, anxiety, expectations and a lot of work in
the hyper growth stage can burn everyone down.

The good news is that all works well in the end,

productivity gets back to your 1.0 magic number and
exceed it by 0.2 or 0.3 tops - as we all know more people
does not means more work done.





fl







 4.
DECISIONS

O
ne of the hardest things to do is to explain decisions.
Specially when the mood is that "anything coming
from outside of the team is a Top Down".

Top downs are sort of a silly ghost haunting teams, which are
hard to chase. They don't exist most of the time - what exists
is an asymmetry of the decisions based on accountability,
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 causing 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 as we

discussed in the last chapter, 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.

But having your leader genuinely part of such decisions make
it easy for a team to deal with them. No one feels comfortable
with a leader that is a victim all the time.

Top down decisions are result of storming out frustration and

discussions, which if you can't negotiate your way, there is a
potential of alienate your tech team.

In all cases the side e ect 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 nding a new one). So
being close and managing them - better yet avoiding the
point where they are made - is good for your team.










ff


fi










 "ADJUSTING" THE CULTURE
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

nding planets around distant stars. We rely on leaks,
investors reports, outages and mass rings 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 di erent
from other companies: investors, regulations, predictability,
MTTR, SLAs and better customer experience.
fi






fi





ff



 Yahoo published an analysis 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 xed within the proper SLA.
No more CYA by complaining about QA.

A couple of years ago a former Amazon engineer published

the "Je 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 red.

It doesn't seems important, but number 3 alone would

warrant weeks of meetings at some companies and a round
of beer on others.






ff

fi
fi



 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,
nd 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 stu 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. Business don’t know it until they know the side
e ects.

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 o 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 e ect.

But before moving to processes, I want to talk about another

euphemism for top downs:


fi




ff





ff
ff







ff


 DISAGREE AND COMMIT
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 leadership is missing, 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.



























 A horse designed by committee

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
e ective engineering leadership.

It feels di erent 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 di erent composition to the horde of unhappy,










ff
ff
ff







 and there is a cascading e ect coming from the conversation
this team have out of band. It is more common that
competent people leaves altogether.

PROCESSES (OR WHY I LEARNED TO

OWN PRODUCTION)
Another "disagree and commit" point are processes.
Traditional companies resort to ITIL a traditional IT
methodologies in hope that it helps gure 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.




ff

fi

 A devops clock

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.

I don’t think development and operations are not so distinct

that they need di erent 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










ff



 company to operate or to buy from you but that’s not an
absolute role.

The dev team xed the devops clock

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
ll 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



fi




fi



 care of.

Customers use the new product, ask for new features,

complain when it is o ine 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 rst 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.














fi

ffl


shamelessly stolen from https://twitter.com/chopeh/status/
926074073767206912

 5.
TL;DR

D
on'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 nd out the answer or call out silly
requirements.







fi





 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.












 6.
THE PLAN

B
efore starting a new gig, even if the only time you
have is the weekend before, 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  nd it here.







fi


 You can expand it for a due diligence too if you end working
on the merging side of a 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.

LEARNING AND MEASURING

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 rst step to
in uence 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.

ENGINEERING DELIVERY METRICS

The rst four metrics I've learned 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 nd a good








fl
fi





fi
fi



 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 x what hurts us in the process. You probably will say that
you use or used some of these metrics in the past but bear
with me and learn the science behind them.

With that in mind we can look how a range of organizations

are behaving, abstracting their internal decision path and
focus on metrics that are common across them.
There is a world of issues and problems in the way to deliver
software, 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.

These are the rst 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 rst
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 non
discussed incidents.

Looking at change failure rate prevents its increase but

having a strong foothold on incidents helps understand if all












fi
fi












fi
 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 e ects of
technical debt.

A "sales request to close a contract" ow is no di erent than

the "product feature request to code" ow if you don't take in
account how your systems break and in which way they
a ect your customer life.

I've also added some metrics for my friends at the CFO o ce,
under the umbrella of Cloud Economics:

-
line
Monthly/yearly cloud expenses total and per product

-- Licenses costs
Support cost
- 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 (COGS - a way of pricing what you sell)

should include this. If no one asked you about it, be the rst














ff







fl
fl


ff






ff


ffi
fi
 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 x 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.

TEAM METRICS
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 nd why it is like this, and what
is the measure of success of each decision.

How does the current engineering organization work ?

You will face a number of terms that may be familiar but
are used with di erent 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.

How many unhealthy teams: no manager, stretched

managers, no product manager
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












ff

fi

fi



 stretched managers I mean teams that should be split of
managers accumulating teams.

Work distribution issues: work that should be done

elsewhere, duplicated work, prioritization
The side-e ect 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 eld 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.

What is the priority de nition between engineering and

products ?
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 ?















ff
fi
fi





 Take a note, you may need to gure out a standard
prioritization process for everyone. A good team is a team
where everyone has a voice.

What is the decision making process (RFC, committee,

go horse)?
Look for documents as PRD (Product Requirements
Document), RFC (request for comment), de nitions 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.

Are there clear leveling for ICs(Individual contributors)

and Managers ?
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 nd none  —  it is one of the things you need to
kickstart right away.











fi







fi

fi


 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 are,

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.

Ladders and performance evaluations are hard. At Appendix

D I suggest a simple approach to start your ladder if you don’t
have it and build up something that makes sense to your
team.

HR AND ENGINEERING ORGANIZATION

INSIGHTS
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 nd plenty of corporate disasters that could be
avoided just by looping someone more experienced from HR
to help or lead a conversation.

How is hiring organized ? Is everyone helping ? What

are the goals ?
Hiring is everyone's job and highest priority. No "I can't
interview because I'm putting out these res" or "I can't talk to






fi



fi






 you because you are always on interviews". A lot of problems
in engineering are due to poorly sta ed teams. Work on it. If
you don't know where to start, use the template at Appendix
A

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 t". You don't want someone tame or
aggressive, friend or public gure - 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 depending on how many
interviews you do. You take notes when you interview
someone, right ?

Are there hidden functions ? (Infosec done by a SRE,

prioritization done by committees) ?
Understa ed 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 su er. 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














ff



ff
fi
fi


ff

 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, Noti cations teams ? The big rewrite team ? The
team that should manage the legacy while the rewrite team is
doing their new thing ?

Sta ng 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 ful lled just by hiring.

Is remote work allowed ? Is it successful ?

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.

PANDEMIC ADD-ON
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 o ce.

The above applies - successful teams were able to navigate

mostly due to reasonable management practices, sometimes
leaning on the side of overworking and nding out




ffi
fi




ffi



fi

fi





 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.

OPERATIONS
I'll use "Operations" as a generic fallback for day to day
stu 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 lling in for.

Is there an incident process ?

How do you know an incident from a bug ? Who listens
rst ? The CEO complaining in a public channel on Slack ? A
loud person in the o ce crashing the co ee 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 ?

Is there an incident severity matrix, blameless

postmortems and product feedback ?
Same as above: what is important, what is not ? At e-
commerces companies, the purchase ow 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 xes it,
how do they learn about it ? How do they make sure they will
have time to x it instead of implementing a new feature ?




fi
ff
fi


fi



ffi

fl

ff
fi

 How is productivity measured ? Any product vs

engineering stale-matches ?
"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
unreliable, and the person saying it be perceived as passive-
aggressive.

Team productivity using points, marshmallows or any gateway

metric are stupid and doesn't increase people's awareness of
productivity. If you have to use something, use hours and
acknowledge that a day is not made of full productive time.
You need some slack.

How is your team(s) productivity perceived and measured ?

How are growth incentives aligned for maintenance and

green eld work ?
Let me take this out of the way rst: If you have an OKR or
equivalent to measure closed bugs, kill it. Same for yearly
bonuses triggered by some at 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 nd companies where
employees with misaligned prizes (lunches, stars, days o s)
are red or leave.

It is important for you to understand how the team is











fi
fi







fi
fl
fi


ff

conditioned. These incentives have to be aligned with the

prioritization process that helps everyone.

 7.
CHALLENGES

J
oining 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?”





 HOW WIL THE TEAM REACT TO A NEW
STRUCTURE OR A NEW MANAGER/
EXECUTIVE ?
One of the weirdest experiences you can have is to be hired
and not have a de ned 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 newcomer.

A lot of energy is required to get going if you don’t plan right.

Natural resistance, teams that are classi ed as black boxes
and non-functional units are easy to spot.

But hiring is the rst step, succeeding is the challenging part.

Don’t let “opportunistic hiring” to be confused to hiring
without purpose.

This is why gathering knowledge comes before de ning

strategies to meet challenges. Once you have clear data and
objectives, individual and personal reactions are just that:
reactions.











fi


fi



fi




fi
 WHAT “LEAD BY EXAMPLE” MEANS IN
THE COMPANY’S CONTEXT ?
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 stu while you get your ngers 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
x. 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.

HOW CAN THE TEAM BE HEARD ? (ALL

HANDS, TOWN HALLS, TEAMS
GATHERING, PUBLIC FORUMS)
There are always rumours and back channels. People will
be talking about a new policy, new hires, incidents, you,
about what you do and so on. It is a fact of life and it will
make your life easier to acknowledge them.

Regardless of that you need o cial forums and rituals, clear

communication and transparency. Not to quench rumours but
to make sure that the message and information you want to
fi






ff




ffi
fi



 pass is managed.

Over time the forums and rituals you created get stronger
and people start looking up for them. Or they die - and you
won’t miss them. Don’t try to shut down on purpose, build
better and interesting ones.

Transparency is not the same as to take abuse. On public

forums, anonymous questions are good but for the sake of
the team mental health 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.

UNCLEAR DOTTED LINES: TEAMS THAT

HAVE NO CLEAR BOUNDARIES.
By in uence or legacy a team can have many in uence
ows. First hires, the CTO-turned-engineer, the new director
of engineering that worked there long before, the CTO that
was red, 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.






fl


fi
fl







fl
 ORG STRUCTURE
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 nd yourself looking for the abstractions and
controls that connect with your experience.

If we look to the average implementation of this model we

will nd:

Multidisciplinary tribes, layered teams

Each and every team/squad/tribe requires individuals of all
chapters (disciplines): product, engineering, data, ops,
nance. 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 with 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 ows plus the metrics that ensure a healthy
engineering org, how do you in uence it ? If the structure
goes away, how would you reorganize your team ? How you




fi






fi

fl
fi



fl









 deal with con icts across "tribes" ?

Pros: one stop shop for business verticals, quick reaction

time to day to day business needs

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 x 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.

Can’t prioritize and execute cross business or

engineering tasks
Shared e orts 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, undi erentiated lifting, standardization,
compliance and due diligences. These are usually overseen
and done in a hurry if it hurts the business.

Legacy product and code management is hard

Organizations 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"











ff
fl

ff
fi









 Vertical Tribes over a thin engineering horizontal and a catch all back
o ce 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 undi erentiated lifting


ffi



ff

 After these stretches most organizations approach the

independence problem from a Business Area with shared
P&L (pro t 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 e orts
Speak product language even for internal customers
Shared P&L-
Speci cally 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, Noti cation

service, Digital channels management, Design, Cloud
Economics, Developer tooling, Analytics and Data
Engineering are naturally shared and costly to replicate
locally.

These e orts bene t teams outside of technology or tribes

and they are bene ted from a solid strategy and operational
e ciency. Undi erentiated lifting should be done once and
for all.

Nimbler product teams bene ts from that, as structures that

depends on compliance and customization. It can be a good
model for companies that are exploring new businesses
based on current features (remember the API mandate ?).








ffi
fi




ff
fi

ff

ff
fi
fi

fi

fi

 8.
DELIVERY

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 a ects 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 e ort of engineers in
these teams are set to simplify operations through
automation.

Operate based on metrics

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



ff

ff


platform presents multiple base metrics but few are not about
something redundant (servers, disks, network).

Invest on tooling for automation, deployment and

metrics collection
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.

Enable accessible CD through GitOps

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 a standard way
Simplify your stack  —  good engineering is boring. Avoid virtue
signalling when creating building blocks: functional language,
NoSQL databases, niche architectures are all nicer when they
come naturally.

Cost Management
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 o 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 exible
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 t your bill. Autoscaling
su ers outside of Kubernetes but there are other bene ts.

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 ght.

The stable stack I've mentioned is the one that ts well your
development model and containers. Don't stu a huge
application into a thing designed to grow horizontally. 2TB
containers don't make sense.

Monitor egress and ingress tra c, cross region and hidden

Cloud costs. For instance at the  Open AWS GUIDE  you will






ff



ffi

fi
ff

fi

ff
fl
fi
fi





 nd a session about network costs. The $$ gures are not up
to date but the ow is clear.

I've seen bills growing fast due to non mapped tra c through
Managed NAT Gateways and poorly set S3 buckets. Same for
EKS you can hurt yourself with cross zone tra c. Loose disk
snapshots and images, unused load balancers and gateways
are a source of hidden cost. Keep an eye on them, tidy up.

Visibility and Observability

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 su ers. 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.
* Organize 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 e orts 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.

INFOSEC
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.
fi



fl






fi

ffi
ff
ffi
ff

 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 di erent 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 o ensive 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 o ensive engineers, or software engineers that like to
break stu . It pays o , a lot.

Read and learn about threat matrix, create a simple one and



















ff
ff

ff


ff




ff






 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 di erent speeds. Appendix C presents a team
arrangement that can work well with di erent attributions and
velocities.

For tooling — same advice as infrastructure: go for automation,

nd 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 re ects on engineering

decisions early: PII (private identi able 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 nd them everywhere, look for
your organization story and build them if they don’t exist.

If you don't have Infosec Metrics, start with two metrics:





fi














ff
fi


fi
fl
ff









 -- Incidents per month
Time to x 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 x security ndings will appear in
the top 5 reasons why a new feature was not delivered
and it is good to have history.

DATA
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 e orts.
Analytics or BI: Coming from a corporate set and
adapting, these are people that can gure out what the data








fi





fi

fi
fi




ff

 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 nd a better description
please let me know, I saw it a lot and all of them are di erent.

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 gure.

Data engineering is not Devops. There is a migration of

Infrastructure Engineers to Data due to a nity of platform and
infrastructure but their mindset is di erent. Managing
distributed databases, migrating data, draining and running
queues may look as an infrastructure problem but it requires
a di erent 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:
--
Get people to 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 certi cation or noti cation.








ff
fi

fi


fi



fi


ffi

ff

ff




 - 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 o ce 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 exible 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. standardize
databases and caches as much as possible)
-- Non partitioned databases
Unmanaged mix between events/serverless and
batch processing
-- Building a scheduler (use Apache Air ow)
Building a log pipeline (use ELK, use Athena/S3)
- Teams too far apart or disconnected
I've put together a slide deck about a common data
organization here. You can nd more on appendix B.
fl

ffi

fi

fl

 9.
CLOSING ADVICES

I
’ve asked myself if this was a book for a long time while
writing it. Yes, it quali es I guess. It is not the
authoritative source for what you should do but the
information here will get you a long way.

There are some closing remarks that would not t

anywhere but I wanted to get together, so there they go

SPAN OF CONTROL
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

fi

fi
 managers, this is their most important job (a close) second
only to hiring.

STACKS AND PLATFORMS

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 rst.

You will nd 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.

GROWING LEADERSHIP
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

su er what you did just because, don't be petty.

PEOPLE FIRST, TECH TO SUPPORT

People are important, technology is a side-e ect, Money
can’t buy everything but helps a lot.










ff
fi










fi
ff

 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.

COMMUNICATION
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 di erent timezones.

I've found out a set of advices from Amazon on writing in a

book called "Think like Amazon". That comes more in line
with the best communications I’ve experienced than anything
to do with Amazonian culture but I think they are a good start:

Use less than 30 words per sentence

Long sentences are hard to break and digest. Keep them
short so the reader or listener can take it home and use it.

Avoid long recaps

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.

Drop adjectives, go for data

"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.

Eliminate weasel words

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




ff

 around too much the message will be buried and trust will go
away.

The "so what" test

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
nance meeting ? Remember time is short, work on the
message.

Be straight when answering questions

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

Take a stand, own it

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.

PLANNING 101
Learn the basics of planning. Don’t invest too much time
on Kanban, Scrum, Agile Frameworks or whatever until it is
not the time. There will be smarter people to reach out to
help but you want to make sure to have a simple way to get
fi










 work organized.

What works for me is to manage WIP (work in progress) in the

teams and to establish clear ownership on “What" and “Why"
we are doing what we do.

I reserve the right of de ning the “How" to the team to avoid

long meetings jumping from idea to “it is really easy, just add
a new IF” and things that will generally sour the mod between
stakeholders and engineers.

I like to do quarterly plannings for products and adjust them

after 6 weeks (mid quarter). You can use OKRs or simple
phrasing to represent high level goals. It should be a healthy
mix between top-down and bottom-up goals (from
stakeholders, from the teams).

Avoid to promote your backlog of tasks to quarterly goals

right away. Also don’t put “closing bug tickets within X or Y
SLA” as a goal. Reserve that for when you want to ip
burgers in a barbecue, for everything else bring in the team
to help.

With the high level goas at hand we should get together and
estimate, avoiding points, magic scorecards or any indirect
measure.

These kind of things are naturally introduced when there is a

perception that the team does not likes to be told what to do
or commit to deadlines but that is usually a mistake. What the
team wants to know is “Why" and how that bene ts and
builds over what was done - that’s purpose and everyone
needs that.

The estimate is not exact but based on what the team knows
and will improve over time. I constantly remember the team of
what we already have and the cost of managing it both to
prevent non-realistic architectures, to establish a healthy






















fi






fi
fl
 workload and to keep a realistic concept of “end" in sight.

The team will get better at estimating, delivering and pushing

back at each cycle. It will also absorb not only engineering
but product management concept, improving the
understanding and breaking silos.

The role of facilitator of the backlog and decisions should

rotate within the team and the tech lead can step up if there
is a product person or any other function missing because of
that support. It also helps to get everyone exposed to glue
work and able to express what is working/not working for
them on 1:1s.

Put everything out in a place where your team and

stakeholders can see progress and correct course. Avoid top
down deadlines as much as not having deadlines.

REAL FINAL ADVICE I PROMISE

And nally, 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 in, give some space. Be kind to yourself and straight

clear when people step over your boundaries.

Have fun !










fi










 APPENDIX A.
INTERVIEW TEMPLATES

GENERAL RULES
Get the questions you will ask and
expected response. Try not to double
down on your preferences. Remember it is
Prepare
not a competition. If possible, always do
yourself
separated technical and behavioural
interviews.





 Start the How are you doing ? Is it a good time to

interview with talk ? Do you have all you need for the
an ice breaker: interview ?

This is a 1 hour interview. I'll save the last

20 minutes for you to ask questions, it is
Then set the important to us to be transparent. I will be
interview format typing but I am not working or Slack'ing
(don't do that), I am taking notes to help me
organise what we discussed.

Ask how the

Start asking how the candidate got there
candidate got
they are, what they consider are the
where they are,
important things that their resume won't
a quick
describe properly.
summary

Then pick 3 to 5 Questions From the next

Be conscious of tabs, take notes, let the interview ow but
time bring it back. It is ok to interrupt to keep
the interview productive.
Ask the candidate about their question. Be
prepared for candidates that won't have
questions so use the time to ask questions
Stop at the 35m
they should have asked as "Will I be on
mark
call ?" "How about company growth ?" "Do
you allow remote work ?" are good
questions.

Last question I like to ask "What do you want to do" and

(Personal listen. Sometimes it is career, sometimes is
choice, you can relocation, sometimes is a mission. Good
skip it) to listen and ask for clari cation.
























fi
fl
 Thank the candidate and remind them that
it is ok asking questions later if needed.
Wrap up
Point them to the next step "X will call you
to follow up". Do follow up.

ENGINEERING QUESTIONS
Q: How did you transitioned to this career ? What was left
behind, what still helps you ?
A: Give space to the candidate to talk and you to identify what
makes them excited. There is a lot to learn on career and job
transitions.

Q: Which languages you have been using ?

A: Here is to understand how the candidate prefer to work. It can
be tooling, data engineering frameworks, what makes sense for
the position you are interviewing.

Q: How do you manage costs ? is it something that worries

you ?
A: Here you can switch it for a question about operations or
production. It is important to grasp how the candidate seniority
and experience plays here. A junior candidate will not be able to
answer and that’s ok.

Q: You are dealing with a lot of pipelines now. How do you

manage time across them ? Do you think it could be
di erent ?
A: It can be pipelines, projects, data ingestion work ow but how
does that plays into the candidate interest of his current work ?
What can you o er to improve their career in this sense ?

Q: Tell me about a Technical challenge you had

A: Let the candidate talk about their challenges, don’t be
judgmental. Use this question to guide the next, specially toolbox
and outages.










ff








ff








fl




 Q: Tell me about a failure or outage you caused and how
you handled it.
A: Same here, don’t be judgmental, try to explore how the
candidate asks for help, lead, make decisions and learn new ways
of failures.

Q: What is on your toolbox ?

A: Algorithms, languages, tools, scripts, designing tools. How does
the candidate work ? Show interest, understand how they would
improve your team culture.

Q: How did you started using cloud providers ?

A: This questions always shows interesting angles for developers,
specially how they see production.

Q: What bothered you most on a programming language

that made you learn X (usually Go).
A: This question may be substituted by framework, data pipeline or
language, algorithms. Let the candidate talk about their interest
and learning path.

MANAGEMENT QUESTIONS

Q: How is your day to day as a director/eng manager/tech

lead ?
A: that’s part of the ice breaker, you can skip if it was discussed but
it is interesting to understand the drive to change jobs by learning
how their day goes on

Q: What is the biggest challenge that makes you think

about changing in your organization. Where it needs to
change ?







































 A: sometimes they can’t talk about it but you can get some insights
on management style

Q: Can you tell us about a hard conversation or situation

with someone in your team ?
A: A hard conversation marks us and can show a lot about
empathy, resilience and learning

Q: How did you transitioned to this career ? What was left

behind, what still helps you ?
A: How does one becomes a manager ? This question can help
you explore motivation. Be careful to not be judgmental.

Q: How do you manage costs ? is it something that worries

you ?
A: In some companies budget is a manager attribution. You may
learn new ways of doing it and also understand which kind of
manager you are interviewing.

Q: Which stack do your team uses ?

Q: How do you help your team make good technical

choices ?
A: do they always give the last word ? can they step aside and let
other people lead ? What novel ideas there are to leverage the
team ?

Q: Are there critical systems that your team dread work ?

How do you deal with it ?

Q: How's the team development dynamic ? How do you

help them to get to a good design ? How do you help in a
new architecture ?

Q: Do you do design docs ? How do you re ect unexpected

events as cost growth into them ?

Q: How do you run postmortems ?












































fl


 Q: Let's say a critical system is down. How do you do to
have your team on it ? What part do you play ?

Q: How do you do team/individual career development ?

Q: How do you manage costs ? is it something that worries

you ?

Q: How do you re ? Is it hard to you ?

Q: Tell me when a decision you made caused an outage or

failure. How did you handled that ?

Q: Have you designed a career ladder ? What were the

challenges ?

Q: How do you work with stakeholders ? Can you tell about

a di cult one and how you managed it ?














ffi



fi









 APPENDIX B.
DATA TEAMS

--Every company depends on data

Data initiatives usually starts with a dump of the
production database handled around
-- After some time you need market standard metrics 
The data you use to guide your company needs to
be understood across the board
- The data you use to guide your company needs to be
understood across the board
- Data oriented products become complex quickly

It is ok to start simple and move up, no need to build a

complex org (i.e. the most experienced data analyst may
be your rst data scientist. You can rent software instead of
build a full platform).

In the following diagram, Analytics, ML/DS (Machine





fi

 Learning/Data Scientists) are stacked over a Data Platform,

which runs on Data Infrastructure.

You may have mixed teams and functions, double or triple

attribution is ok here depending on company size.

ORGANIZATION



 CONTEXTS AND BOUNDARIES

The boundary here is important - a common mistake is to

overgrow an analytics/BI organization because tooling is not
accessible or data is not easy to understand.

Good product managers and executives should be able to

self service, a meaningful access structure should be enough
to guarantee controls to avoid having humans dedicated to it.

Same for data engineers and software engineers, it should be

closer and more of a specialization than largely separated
roles - asking for a data engineer on teams to deal with data
ingestion is similar to asking for SRE on a team to perform
deploys. It is a sign of poor tooling.

Machine learning and data science rarely work as project

o ce - given a fair platform they work better embedded on
product teams but beware of having a common touch point
for them to recycle, learn new technics and reuse data.








ffi







CARRERS

Career is self explanatory - data folks tend to migrate over

time - in and out of teams. You will get software engineers
interested on data or machine learning, Analytics that
developed models and are doing data science. Clarity can
help a lot in these choices.

 APPENDIX C.
INFOSEC TEAMS
Infosec teams attention on startups and fast growing
companies will generally be split between three work
streams:

-- Compliance and business controls

Day to Day Infosec (Incidents, vulnerabilities, pen-
testing, mitigation)
- Defensive/O ensive Engineering

It is ok to mix some of them but after some time there will be

con icts between the work needed to tend to incidents and
work geared to get compliant to data or market standards.

Also for startups running in the cloud and building software

products the gap between traditional datacenter based
security, IT and defensive measures for data and mobile






fl

ff



 interfaces may create a lot of stress and unneeded tension.

CISO

COMPLIANCE SECURITY ENGINEERING

Security comprises SOC (Security Operation Center, the 24/7

monitoring for incidents), Incident response, Vulnerability
management, interfaces with IT and products.

Compliance deals with all matters of certi cation (ISO, PCI,

SOX and SOC) plus interfaces with all teams for controls as
Finance, IT and products. They are liaison to Legal and Sales
teams on customer matters.

Engineering is a generic name for a concept: investment on

trying to hack itself before others do. This team should work
with product and engineering teams on missions, training and
tooling to improve vulnerability detection. It pays o to have
people dedicated to it.

You can learn more about Blue Teams/Red Teams/Purple

Teams at the NIST library (https://nvlpubs.nist.gov/nistpubs/
SpecialPublications/NIST.SP.800-161.pdf)

In a product driven company growing like this will help you

understand where demands are competing and separate
what you need to do to protect your customers and what you
need to do to operate legally.

If you look to the recent data leak incidents, a vast majority of




















fi

ff


them comes from shadow IT, lack of cloud knowledge,
shadow data work. From these either they yield important
data or ways to trick customers and the company on giving it
out, including nancial data and money.
fi


 APPENDIX D.
CAREER LADDER
Career Ladder is a term that means a lot for di erent
people. For engineers - and any function - it means a path to
progress. What is the plan or blue print for each level in the
company and how to move up.

It is common to feel that it is easy to grow changing jobs than

being in the same company. The problem is that when you
have a ladder that is not so clear, you will probably see that it
is true because the company uses a di erent criteria to hire
than when they promote.

Ladders are also used to di erentiate roles as individual

contributors from engineering managers and to help
performance assessment.











ff
ff
ff
 If you have no ladder, I suggest that you get inspired by
Engineering Ladders  and  Levels.fyi  for how levels compare
across companies. But I also urge you to start simple.

You can put together a matrix with a lot of requirements

distributed on columns describing your values and traits but if
you can’t consistently follow that up, you will nd your team
lost on long discussions about their roles and progress.

I’ve put together a simple engineering ladder for ICs and

managers to illustrate that. It is based on impact and scope
(reach within and outside the team). You can nd it here.

The rationale is simple: the expected impact will help you

understand the scope. The scope will ask you support what is
asked from someone in that level.

It is not fair to ask an engineer that just started to code to

consistently change how other engineers work or to be
responsible for a complex piece of code.

But it is reasonable to ask them to be able to work on well



















fi
fi





 de ned tasks, to collaborate with a healthy team of 4 and to

work on themselves learning.

The scope then is well de ned and you can infer a scope
progression from there up to the CTO or to your role in the
company.

With that, you can look to manages and understand from

what you already have where people from within the team
are moving back and forth these two tracks. Same for scope
as a tech lead impact di er from company to company.

After that you can put down how your team would t to this
framework and calibrate them, to make sure that everyone is
on the right level as much as possible. It is not a pure
comparison but you will see that some information is missing
and when you feel con dent I suggest that you add a column
for Execution and a column for Leadership and
Communication.

Do the same exercise you did for scope: is an entry level

developer required to lead ? What is good communication
expected there ? What are the positive examples you already
have. On execution, you can start with skills: diligent with
testing, refactoring up to things that will create broader
impact within the team.

Avoid velocity and task measuring wording here. The

intended result is that each person on your team have the
same ladder and notes around their progression, in a way
that they can build it up over time respecting their velocity
and personal style.

You don’t need to replicate what big companies as Google or

Facebook have. Remember they hire way more than you do,
and they have an insane churn and team size. Their
processes are scalable because they have time and money to












fi






fi
ff


fi


fi


run them - you probable don’t have it. Keep it simple,
transparent and fair.