ERYN: Hello! Can you hear me? Oh, there we are, you can hear me now. That is going to get weird. That is a lot of pressure to not say the wrong
thing, oh, God, it's still there. [laughter]
So, like Meri said, I'm a tech lead and I'm giving the talk -- Now You're The Tech Lead,
Now What? Subtitle, "what is our job, even?" [laughter]
So this is a bit of a definition talk, but it's also really tactical. It's also I want to give some stuff, because
there are so many people who already do this stuff, right? So normally I give this talk and it's for
people who are kind of new to this, they don't know what they're getting into or they got
into it and realized for some time after they're doing the job that they're tech leads in hell. We'll talk about some technical stuff because
I want you to be able to take home some things to be able to work on teams. So I'm Eryn. I'm a PHP developer which means I'm a big
nerd. I'm a technical lead, which means I like to
tell other nerds what to do, and I'm an independent agent. I'm going to talk about clients, I'm going
to talk about hours and budgets. You might not have those at your job. If you don't have those, that is fine. Because you have something similar. So when I say client, if you don't have actual
paying clients, hear stakeholders, hear management, hear users, hear whichever one is appropriate
for whatever you're doing. When I say hours or budget, just think of
that as the general sense of, you have to do this in some sort of timeline or you're
going to lose your job. So it might not be as official or as specific
as what I'm doing, but this stuff all connects. So you, like I said, you maybe have recently
become a tech lead. You aren't a tech lead yet, but you think
you might want to be, and if that's you, and you paid to come to this conference, spoiler
alert: You're among your people. Because that's really nerdy and I love you
for it. [laughter]
Or you are already a tech lead and you want to improve. So that's probably most of us in this room
or doing that job or doing something very adjacent to it. But there's a lot of ambiguity aren't this
term, tech leading. Not everybody even uses it, right? So let's settle this and fix that and know
where we're going next. A tech lead is the owner of a technological
vision of a product and the technical leader of the project team. So I really like the first half of this. Because that's what differentiates what we
do from project management, or product ownership. Or just being a senior engineer. So product owner, they may advocate for the
user, they may advocate for the business needs or the use cases, but they're not going to
worry about how do we get it done. Project manager is making sure that we get
it done. They care very much about the brass tacks
of the scheduling, the brass tacks of who's talking to the client, perhaps, some places
you'll talk to the client or the user, some places not. Oh, hey! You saw nothing. [laughter]
Or a senior, you know, but a project manager is not going to worry about the technical
details ms they're going to trust that the team can do that part, because they're not
technical experts. And a senior dev is worried about those technical
things, but they're not necessarily seeing the whole project. They're really focused on perhaps a very difficult
problem but it's still a contained domain in which they are the masters of the details. This looks a little different everywhere you
go. Not everyone even uses this term and places
that it's used use it slightly differently. So some cases it's a job title. In a lot of places it's more of a project
role, so maybe you're the tech lead on this project but you're just a person on this other
one. Maybe it's more of a continual management
or leadership position that you have. Every place is going to have a different set
of expectations, a different set of deliverables, and there's the specific stuff that we're
told about, it's in your job description. Maybe you deliver senior-level architecture
and up make technology decisions on the stack. You have to write requirements -- oh, I said
write requirements. You have to make sure those requirements are
implemented throughout the course of the project. But then there's the things that you are not
necessarily told about. The intangibles of this job. Saying no to scope creep. Settling disputes between two developers who
want to do things diametrically opposed ways. That's the stuff that they don't tell you
about up front but that makes or breaks the job that you're doing. It can be hard to reconcile all of these different
things that we have to do, and all of these different organizations that we might do it
in, and all of these different ways that we get it done, in one talk. With one set of ideas and definitions and
tactics, but here's the thing. The bottom line is that at the end of the
day, it's about making good software with a team. And the one thing that is consistent on every
software team that you will ever work on literally ever, no exceptions, is that there are people
on that team. And people are pretty -- we're similar in
a lot more ways than we are different. Which means we're hackable. Which is good. Because we like that. So we can talk about the psychology of humans. We can talk about the psychology of groups. Camille talked about a lot of that in her
talk this morning. There are things that you can do, that regardless
of your stack, regardless of whether you're agile or water fall or whatever you are, you
can apply these tactics. So I'm going to distill this down. We're going to achieve tech lead mastery in
three easy steps. Facilitate: Help your team do their job. Advocate: Keep the big picture in mind the
whole time. And motivate: Guide your team to the best
possible result. We're going to get into the details of each
of these, but these are our thesis. This is regardless of your technological situation,
this is what you have to do to be successful. So facilitate. Your job is to help other people do their
jobs, which can be really unsatisfying sometimes, because there aren't necessarily obvious metrics. You aren't necessarily looking at your own
lines of code. That you've written. You're doing something a lot more intangible
a lot of the time. You're helping other people get their work
done. Always be asking yourself what's next. What is my team going to need next from me? So if there's a roadblock, you move it. If somebody can't get their done that's when
you jump in, I'll talk to the admin, I'll figure what's up with the UX. It looks weird to me, I totally agree. But that's firefighting if you only wait until
somebody is blocked. What you want to do is look ahead and perceive
the need. This is a Minnesota phrase that I learned. I live in Minneapolis now but I'm from Chicago
which means I've been able to approach the culture there from a self-side Irish, very
profane anthropological point of view. One thing about Minnesotans, asking for something
is frankly very rude so you try very hard to anticipate what their needs are. So true story, I was at my brother-in-law's
house and he gave me some pretzels and I'm eating them and they're delicious and they're
salty, so I turn around to ask for a glass of water and he is standing there with the
glass of water and I was like, that's funny, I was just going to ask you for that. And he's like, of course, pretzels are salty!
[laughter] And I was really weirded out, but then I married
in, so whatever, I guess it wasn't that bad. So you want to cultivate that same sense of
helpfulness. You want to say what's going to happen before
it does, so if your dev is going to need access to a client's FTP server on Friday, don't
wait for them to ask you. Just ping the admin Tuesday. Look ahead. Get it figured out. It's a great sin to leave somebody blocked. So the only way that you can make sure that
you don't sin is to look ahead. Otherwise you're going to be constantly behind
the eight ball. Oh, yeah, let's do it. So tactic No. 1 to make it happen: Use tickets,
use hours, use burndowns, and the P MS in the room just got really excited. But seriously I love estimates and I love
burndowns, and that's because data helps us make decisions and data helps us have arguments
and helps us have productive ones, because if you just have a general gut feeling that
something is or isn't going to work, that's one thing, but if you can sit down and look
at your burndown and see the number of hours that you have that are, you know, you need
to launch this thing in June and you're not going to get it done until August, that is
not something that someone can get offended by. That's not something that someone can push
back on and say, uh, can't you just try harder? Like, no, these are facts. What are we gonna do with them. So it helps us have productive decisions and
look on to the next thing that we need to do to get the project moving. Your job now is to be interrupted. That's just reality. So what you have to do is figure out when
is it appropriate to help somebody and do the thing for them, and when is it appropriate
to make them do it themselves and it's really frustrating to get interrupted because the
startup time is a very real thing. You lose your train of thought. You have to switch tasks but in the overall
ecosystem of the organization, takes them ten minutes to ask you, takes you ten minutes
to answer them, takes you another ten minutes to get back to them. That's 30 minutes. If it would have taken them two hours to solve
it on their own, that's overall efficiency. Your job is to be interrupted now. Sorry. But it's for the health of the team and it's
for the health of the project. So you need to know all of the answers, or
at least where to find them. Because you're going to get interrupted a
lot. You're going to have people coming to you
all the time because you're supposed to be the resource on the project, right? So you're going to have P MS and management
and clients who want to know what the state of things are and QA and the customer support
who wants to know why this and this and this is always broken. You're going to get interrupted all the time
and that is only going to get worse the longer you work somewhere because you accumulate
more knowledge and more people have worked with you and decided that you're super-smart
and they want to ask you about whatever. It's a problem that only gets worse. So you just have to accept that that's part
of this. So know everything, or at least know where
to point people. Teach them how to fish. That is fine. You always want to be evaluating any request
to say, is this something that I should do now, in 10 minutes, this afternoon, next week
according to your priorities and the priorities of the organization. This is a fantastic quote from a man who will
be very upset if I call him my mentor. He made that really clear. It's fine to admit not knowing something,
but never as an excuse. I don't know, should Burt joyfully from your
lips, followed by "But I will find out" so you can ask for advice. That's OK. In fact, it's recommended. You should really ask for advice. But when your job is now the person who gets
interrupted when your job is to have the vision of the project, you don't get to say, "Not
my job". You're now responsible for making sure that
that answer -- or that get gets to where it needs to be or that that person who has that
question gets the answer. What's cool, though, is we can use it as a
learning opportunity. For example, I at the agency I was at was
doing a lot of work with DNS, but sort of sporadically. Because I had to advise clients, who's hosting
the site and you know, what are we going to do. So I had to be able to speak intelligently
about it but also I wasn't necessarily the one implementing it so I was just going to
the admins a lot, and saying, can you make me sound smart? Because I kind of know but I don't really
know the words to use exactly. I could always have gone back to ask them
for that help but I used it as an opportunity to learn more about that thing and so instead
of saying what was the answer, I said what was the answer, explain that to me. And people would explain more things to me
and that just kept getting worse, but that's OK, that's job security. So use these opportunities to learn lots of
stuff. So second, to get things done right, you need
to advocate. Your job is to advocate for whatever is not
in of the room. If you're talking to your devs and they want
to cut corners, you need to advocate for the client, for the users, for the people who
are going to use this software, for the people who are going to maintain it afterwards. But if you're talking to management, and they're
trying to push back on, can't you stop running tests? You know, can't you -- lots of terrible things. Now you're advocating for the devs. Now you're in the room saying no, we can't,
and here's why. And no matter who you're talking to, you're
advocating. If you're in an agency setting or something
where you're getting requests, so maybe it's internal stakeholders, maybe it's that manager
who is always saying, I have an idea, write it, I don't care if it's harder or technically
possible. You need to advocate for the project. Push back on that. Sometimes you have to say no. So you need to have the 10,000-foot view in
your head so you can make good decisions about what to do on the ground because when you're
always advocating for everybody, the only way to be successful in those split-second
decisions is to know what's going on, but more importantly, why. Because you want to trust your developers
to make good decisions about how to implement stuff, right? I mean they're smart, that's why they work
there. They're probably smart. They're smart, OK? [laughter]
And you want to trust them and let them fill in what's going to happen, so in that case,
you need to know the why. So when they say, well, if we ...
You can say that's a really good idea, or no, and here's why. Because developers, most humans, but especially
developers, who are a little ornery and a little logical, work a lot better if you give
them a why. Just saying yes or no doesn't work. And you all know that, because you're also
people. And you're smart people and you're people
who like to build. So if we give people the context, they can
use that context to make better decisions. However, you're only human. So you can't actually know everything. So write everything down. Everything. Send meeting recaps, send emails that recap
conversations that happened in the hallway, especially send recaps of any conversation
you have with the stakeholders, somebody who can make your life harder. This is how we avoid groundhog's day meeting
syndrome. Which is where you go into a meeting and you
spent an hour and a half digging into something and figuring out the details and it is agonizing
and everybody has very strong opinions and by the end of it no one has strong opinions
because you're all defeated but you have come to something that you agree works and next
week you have that meeting again! [laughter]
This is how we cut that off. It's especially effective with the kind of
clients who like to change their minds or the kinds of managers who like to decree how
to do things. Because if you can show somebody not only
what you agreed on, but why, they can't push back against that. Or they can, but they need to have reasons. They can't just change with the wind. So this stuff can really save your bacon,
both in terms of financially if you're really talking in terms of hours and money and things
like that on a client project, and just in sanity. Because nobody can stand those meetings. So here's how to advocate when you're talking
to certain people. Talking to developers. Developers love, love to do things right. There are degrees of correctness to everything,
though. So if the developer wants to rip the most
perfect, reusable, whatever, whatever, but it's not going to actually get reused, that's
not efficient. Everybody likes to write reusable code, and
no one wants to reuse anybody else's code. [laughter]
So if they're going to overengineer something that literally no one else is going to use,
that's not saving anything. So push back in those moments. Have a sense of scope. Don't be scared to say no. In fact, I got kind of a reputation for always
being like, no, that's out of scope, no, that's out of scope and one day one of my team members
came up to me and he was like, OK, I have this idea, I was thinking if we did this,
and this and this, and it's a much more structured thing and no, we're not going to use it right
away and but then I realized you'd say no, so I'm not even going to ask you and he walked
away. I was so proud! That was a good moment, guys. So push back. It's OK. When you're talking to management, use those
burndowns, those tickets and those hours that you have set up. When they want something faster, give them
hard facts. Don't say, no. Say no, but ... no, we can't do that, but
if you gave us another week, we'd have time. Or no, we can't do that, but if you bought
a subscription to this particular product, then we could at least see. No, we can't do that, but give me a week for
exploratory because what's going to happen is that person is going to decide, either
that's important or no, I guess not, because I don't want to pay for it. So when you give an answer back that they
can't argue with, they can't argue with you. So make sure you walk into those things with
that data. Make it impersonal. Bring in facts, push back, be firm, but you
also have to be reasonable, because again, we are all developers and we all want to do
it right. And there are tradeoffs. Any software has tradeoffs. So don't push back on everything management
wants just because management wants it. If you do that, you are going to get a reputation
as somebody who's hard to work with. So don't forget that stuff. With clients, again, you need to be able to
say no to people. Whether it's clients, stakeholders, users,
whatever it is, you need to know when no, that's not happening, is the right thing to
say. Just say no to feature creep. That is advocating for the project. One way to make sure this doesn't happen is
to always be going back to the requirements. You have requirements, right? You have user stories or requirements or you
know what you're building, right? [laughter]
OK. If not, that's another talk that I would be
happy to give. But make sure that you're not adding too much,
you know, so always be going back, always be saying no, no, no, always be comparing,
A, B, C, to the requirements. Coffee is for shippers. And you'll never ship if you keep letting
all the features get added. Finally, to get things done, you need to motivate
your team. So tech leads, we have a little bit of telling-people-what-to-do
power, but generally speaking we're not managerial. And yet we still have to get people to do
things. That sounds like a problem, but it's actually
a really good thing, because it means that you can't fall back on being a dictator. Fall back on hierarchy. You have to actually motivate people. It's not as hard as it sounds. But I don't want to scare you, but tech leading
is a form of management so if you thought that you were avoiding that whole thing by
getting into this, you're wrong. Sorry. But it's the good kind. It's the best kind of management. It is empowering people through leadership
to do their best work and that is awesome and that is what every manager should be. The first key to this is your attitude. You're going to set the tone for the project. You're going to set the tone for the team. So if you're negative all the time, your team
is going to be negative. If you're not confident, your team is not
confident. Whatever you are is the ceiling. Your team can't be more optimistic, more confident,
more calm, more whatever it is than you are. So you need to figure out how to be the wall
that all of the project crazy runs into, and then just splashes off and keeps your developers
behind you safe and dry. Absorb the crazy. Let everybody else feel calm and confident. Another big part of this is you can't -- you've
got to watch the negativity. So like, we all need to blow off steam sometimes,
but if you create a culture of blowing off steam, then you're in trouble, because that
becomes toxic. That becomes something where it's us versus
them. Where whoever it is you're always blowing
steam off, we're never working with them. This is basic human psychology, this is tribalism. Don't encourage it. We all need to let it go sometimes, but be
really deliberate, do it behind closed doors with a very deliberate audience, and don't
dwell on it. Get it off your chest, but then move on because
when we're complaining, we're not finding solutions. So it feels good, but it's not productive. One of my favorite ways to motivate people,
though, is passive-aggressive whiteboarding. So here's the thing: Lots of research has
shown that external motivators, like higher salaries, more PTO, free beer, free cake,
doesn't actually motivate people to do better work. It is a very, very short and fleeting returns. The best motivator is intrinsic motivation. It's when people motivate themselves and want
to do something. So passive-aggressive whiteboarding is a way
to trick people into motivating themselves. Here's an example. I had a kind of a big project, where there
was three developers, three backend, one front-end and me, and we had a lot of work to do and
our schedule was pretty tight and I was getting really nervous and one of the developers was
definitely not taking it seriously enough. By the way, I sign NDAs so a lot of my stories
are someone did a thing and someone else did a thing and. So one of the developers would be like hey,
I'm a little nervous and he's like, no, it's cool. And that, like, that's it, like, what do you
do with that? You're at an impasse, so what I did was I
said, hey, can you show me how you want to write that? And he's like, sure. So I went to a room and he started whiteboarding
it. And I was like, what about? And he's like, yup, nope, got that covered. And then I said about what about -- and that
was like the lightbulb moment when I say both the realization and like the dread that just
washed over his face and he was like, oh,, and I was like, yeah, I've been saying that
for weeks, but cool! Because getting somebody to walk through that
process, he realized it in his own heart of hearts, his own brain, he logically had gotten
to that place where he couldn't deny it and me just telling him he would come back and
say, no, that's not true. So passive-aggressive whiteboarding is a fantastic
trick of tricking people into admitting something that you already know they haven't settled
on yet. And you're not writing the code. I'm really selling this job, aren't I? That's a rough place to be in because you
don't have much telling people what to do power, but you're going to be in trouble if
they don't do what you need to tell them to do. So motivation is a big part of this. You getting people motivated properly to do
a really good job and make everybody work together, that helps so much. So does the advocating, so you're putting
boundaries on the project, so you're setting yourselves up for success. You're creating a situation where you can
actually succeed. But another really important part of this
is mitigating risk. As a tech lead, as that senior developer,
as that senior engineer, as that lead developer, you are going to be looking for the last 10%. So developers are really good about getting
to 90%, and then there's just that last 10%, which is actually 50% of the project. [laughter]
But they don't see it, because they're exhausted, because they're unhappy, because it took them
this long to get here and dang it, they are done. So to mitigate risk in those situations, to
find those 10% gaps, ask people to show you their work. This is another form of passive-aggressive
whiteboarding but say hey, cool, you finished it, can you demo it for me because when they
load it up and we find out that they didn't commit a file or they just didn't finish the
front-end because they were so excited about getting the backend working, stuff just becomes
obvious and they'll see it and go, all right, my bad, let me go finish it. So that's a really good way to mitigate risk. The best way is to go after the parts of the
project that scare you the most and relent lessly chase down answers until you aren't
scared. You want the easy win, you just want to dive
in and there's some other part that you're not quite sure how it works yet, but you'll
get there. It's some other third party integration you
have to work with. It's the new hotness JavaScript stack that
your front-end developer has convinced you you have to use but you don't know anything
about. It's a lot of things, but it's that black
box. When you sit down and look at a project be
honest with yourself where that black box is and charge head first into it. The less you want to do part of a project,
the more you probably need to start there. So focus on those things, and just tear them
down until they're not black boxes at all, until you know what you're looking at and
what you have to work with. Because those are the places where you have
your unknown unknowns. You may think it's a known unknown. The unknown unknown is everything that you
didn't figure out yet. So dive into those things. And focus on being the catalyst that makes
sure that everybody has thought about all of the different parts and the way that they
come together and aren't jut thinking, eh, it will take care of itself. Last note: I want to be straight up. It can be hard to code when you're a tech
lead. Once you're doing some leadership, it is tricky. Because coders work on the maker's schedule,
which is you need long chunks of time. But tech leads, you shift to a manager's schedule. You're interruptible. Your job is to be interrupted. Your job is to help other people get their
stuff done, so the reality is sometimes you don't get to program as much anymore, and
there are ways to figure out how to fit it in there, but you're never going to code as
much as you used to. And you need to accept it and your management
needs to accept it and if it isn't accepted, push back on it until it is. And if this breaks your heart, maybe this
isn't the thing for you. I mean not this conference. This conference is great. [laughter]
But leading the team in this way, maybe that's not your thing, and that's OK. But to end on a downer note:
There's still lots of things that you can do to try to mitigate this, to try to pull
it back together, to figure out how can you be effective for your team and also not go
crazy at the same time. So advocate, facilitate, motivate, and kick
butt. Thank you!
[applause]
TIL about r/ladydevs 😮
Holy shiz, I love this presentation. Eryn tells it like it is.