Empowering Early-Career Developers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 66 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46587 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Ruby Conference 201849 / 66
5
10
13
14
17
18
21
22
26
29
37
45
46
48
50
51
53
54
55
59
60
61
63
65
00:00
Software developerVideoconferencingMultiplication signProjective planeStrategy gameLevel (video gaming)Data managementClient (computing)Software engineeringOcean currentBitProcess (computing)Expected value1 (number)Dependent and independent variablesArithmetic progressionDatabase transactionInternetworkingProduct (business)CodeInstance (computer science)JSONXML
02:01
Dependent and independent variablesMultiplication signLevel (video gaming)Computer animation
02:35
Ocean currentProcess (computing)WhiteboardMultiplication signStrategy gameBookmark (World Wide Web)Projective planeParameter (computer programming)Task (computing)
03:49
Multiplication signLevel (video gaming)Data managementParameter (computer programming)Validity (statistics)Variety (linguistics)Food energyDifferent (Kate Ryan album)Process (computing)MIDIExistenceLecture/Conference
05:23
Negative numberPerspective (visual)Form (programming)TelecommunicationProcess (computing)WordPerspective (visual)Formal languageGroup actionArithmetic meanProgrammschleifeSpectrum (functional analysis)
08:10
Software developerDecision theoryTelecommunicationData managementInformation technology consultingClient (computing)Spectrum (functional analysis)Set (mathematics)Product (business)Multiplication signWebDAVForm (programming)Client (computing)Electronic mailing listLattice (order)Decision theorySkewnessData managementCategory of beingInformation technology consultingTelecommunicationCharacteristic polynomialComputer animation
09:40
Interior (topology)Information technology consultingClient (computing)Projective planeData managementStrategy gameData conversionDependent and independent variablesPhase transitionClient (computing)Online helpCartesian coordinate systemProcess (computing)TelecommunicationSpacetimeAreaSoftware frameworkDecision theoryDiagram
11:33
Point (geometry)Information technology consultingClient (computing)Decision theoryCurvatureImplementationRotationE-learningRoundingDependent and independent variablesWage labourMessage passingComputer-assisted translationPolygon meshIndependent set (graph theory)Execution unitPhysical systemRotationGoogolPhysical systemTelecommunicationResultantDisk read-and-write headInformation technology consultingElectronic mailing listExtension (kinesiology)Shared memoryCodeDecision theoryProduct (business)Lattice (order)Entire functionMultiplication signData modelPoint (geometry)Game controllerMereologyNatural numberClient (computing)Data conversionDomain nameEmail1 (number)Process (computing)PlanningConfidence intervalDependent and independent variablesOffice suiteOrder (biology)Data managementImplementationOcean currentDataflowVacuumProjective planePhase transitionComputer architectureLevel (video gaming)Bridging (networking)Diagram
18:00
Physical systemLattice (order)Task (computing)Normed vector spacePoint (geometry)Formal verificationTwin primeFlow separationService (economics)CodeGraphic designDependent and independent variablesMiniDiscClient (computing)Lemma (mathematics)Software frameworkProcess modelingAlgorithmSoftware testingSoftwareTelecommunicationData managementProduct (business)Machine visionFocus (optics)Sinc functionDependent and independent variablesProcess (computing)Strategy gameMIDIMultiplication signFeedbackData managementSocial classContext awarenessClient (computing)EstimatorData conversionCycle (graph theory)Goodness of fitLattice (order)Point (geometry)Normal (geometry)Unit testingMachine learningSoftware testingDatabaseTelecommunicationINTEGRALCodeDecision theorySpacetimeImplementationProduct (business)EmailElectronic mailing listSoftware frameworkComputer filePerturbation theoryComputer architectureBitSampling (statistics)CASE <Informatik>Descriptive statisticsPhase transitionLevel (video gaming)Term (mathematics)Constructor (object-oriented programming)Projective planeTangentInformation technology consultingOffice suiteWhiteboard
24:27
Dependent and independent variablesProjective planeAreaOverhead (computing)Structural loadCartesian coordinate system1 (number)Expected value
25:04
Information technology consultingClient (computing)Focus (optics)Type theoryTask (computing)Point (geometry)Decision theoryTask (computing)Dependent and independent variablesType theoryAreaPrice index1 (number)Variety (linguistics)Process (computing)SpacetimeTrailSinc functionExpected valueElectronic mailing listMultiplication signLattice (order)Client (computing)Computer animation
27:38
FeedbackCovering spaceImplementationRegular graphEmailArchitectureProcess modelingProcess (computing)Wave packetComputer architectureMultiplication signExpected valueEmailHydraulic jumpData modelType theoryProjective planeDependent and independent variablesDecision theoryLattice (order)Set (mathematics)Client (computing)Software frameworkMereology1 (number)Right angleFeedbackPlanningOnline helpImplementationGame theoryDifferent (Kate Ryan album)Electronic program guideGroup actionScheduling (computing)
32:07
Coma BerenicesXMLComputer animation
Transcript: English(auto-generated)
00:19
So, I'm here today to talk to you about empowering early career developers.
00:24
We're going to talk about why it's important, what we've been doing on my team, and some strategies that you can bring to your team to empower your early career devs. Like Megan said, my name is Mercedes Bernard, and I'm a senior software engineer with Tandem, formerly known as DevMind, so you guys all get to be the first ones
00:43
to hear that we're changing our name and rebranding. So, yeah, let's get started. There we go. Okay, so I want you all to just take a second and reflect back on your career progression. How did you get to where you are today?
01:01
How did you grow from an intern or an apprentice or an entry level to your current role? Did it feel a little bit like trial by fire? Or what about like drinking from a waterfall? My experience definitely did, and I can think of a few instances in particular, like at
01:24
my first job while I was still in school and I had to explain to a very angry client at 1 a.m. why deploying untested code to production was a bad idea. Or another time at my first job out of school when a large payment transaction project fell in my lap that had been poorly estimated by someone else, and then I was on my own
01:45
to manage unrealistic client expectations. In both of these scenarios, I did not have the support of someone in a senior or lead role. And unfortunately, I don't think my experience is uncommon. There has to be a better way.
02:02
On my current team, I lead a team of eight developers. This isn't my first time leading a project, but it is the first time I've led such a large team of varying experience levels and that I've shared responsibility for their professional growth. And like Megan said, I've also started a community in Chicago called Dev Together that
02:22
connects people starting their development careers with technical mentors. Both of these experiences have opened my eyes to the tremendous need in our industry for mentorship and coaching for those early in their career. Which brings me to the problem with our current technology market.
02:41
Companies are scared to invest in junior talent. If you look at any of the job boards right now, everybody's trying to hire teams of rock star senior devs. And I don't mean to call out anybody here at the conference or any of our sponsors, but I took a look at that job board. Senior, principal, lead, senior-ish, that was my favorite.
03:08
And in my opinion, this is just a losing strategy. It costs so much money to hire a team of all seniors. There's the recruiting costs, there's salaries, and the cost of attrition that comes
03:21
from lack of career growth opportunity. Because when everybody's a senior, how do you grow and improve? Also, not every task on a project requires a senior's experience. Companies are overpaying for work that people early in their career could be challenged by and learn from.
03:42
In my opinion, it costs less to mentor early career devs than it does to hire a team of all seniors. And the argument that the seniors that you do have don't have time to do this mentorship isn't valid. Your mid-level and senior-level engineers need to practice these mentorship and coaching
04:03
skills if you want to grow managers and leads who teams want to work with. It's an unfortunate reality in our industry that job hopping is often the quickest and easiest way to level up. So I can understand why that would make some companies hesitant to invest in their early
04:22
career talent. They fear that after they spend all of this time, money, and energy, their early career devs are just going to go leave to get that mid or senior title. But where do you think senior developers come from? I was talking to somebody recently who made the joke of the senior developer stork.
04:42
It just doesn't exist. People who feel valued, who are challenged, and who have the support of their leads and management are more likely to stay and grow with your company than those who are just given the intern work or the busy work, and they'll just leave to find variety
05:01
or something different. So I've been reflecting on how to improve this mentorship and coaching that our industry so desperately needs. And we need to empower our early career talent if we want to retain them and grow them into the senior devs that we're all looking for.
05:24
So I want to go back to the title of this talk for just a second, empowering early career devs, and I want to unpack what I mean for just a minute. This is the definition of empower that I particularly like and use, to make someone stronger and more confident through encouragement and support of their ability.
05:44
I want to highlight just two pieces of this definition. The first is more confident. Of course, we want to grow strong developers and strong development skills, but we should also want our developers to own their growth.
06:00
We should want confident, independent devs. And the last four words of this definition are my favorite, support of their ability. Everyone has innate strengths, and everyone is capable. By encouraging the talents that the members of your team already have, you can grow them
06:23
into the skills needed to make amazing team leads. So you may have noticed by now that I'm trying really hard to avoid using the word junior, and I'm replacing it instead with early career devs. So let me just make explicit what I mean when I say early career.
06:42
All I mean is somebody who's beginning their development career. So why is this reframing from junior to early career so important? Let's just be blunt. Junior has a negative connotation. I don't think it's warranted, and I don't think it's earned, but unfortunately, there's
07:01
a lot of people in our industry who view junior as probationary and other forms of less than rather than just as somebody who's learning. And because of that negative connotation, it causes imposter syndrome to abound. If the person you're talking to thinks you mean junior as less than, they're going
07:21
to feel less than when you use it. And just because this is somebody's first development job does not mean that they're junior. Career switchers have so many transferable skills, and often it's the communication and
07:41
soft skills that are the hardest to learn on the job. Early career devs bring fresh perspectives and no bad habits to unlearn, and in my experience, they bring all of the enthusiasm and none of the arrogance that comes from a lot of senior technologists. So when we're talking about this group of people, shouldn't we want to use positive
08:04
language when we're talking about them instead of labeling them as junior? So I want to switch gears for just a second and talk about the opposite end of the spectrum and talk about the senior developers. So what makes a senior developer?
08:20
I'm sure everyone in this room has some ideas about the defining characteristics. But for me, I've broken the traits into two main categories of skills and experience. So in my opinion, a senior dev is somebody who has really strong technical communication, time management, meeting facilitation, consulting, and client engagement, but they also have
08:45
experience making decisions, being held accountable to those decisions, looking at the big picture, and leading a team. Now you might look at my list and go, well, that skews really heavy towards the consulting side, and it's totally true, it does.
09:01
That's where all my experience is. So if you focus on product dev or other forms of dev, your list might look different, and that's totally cool. So how do we foster growth in someone who's early in their career into a team-leading senior dev who has all of these traits?
09:24
We need to give our early career devs the opportunity to practice these skills and to gain this experience before they step into a lead role. Remember the first time that they're in front of a team, we don't want it to feel like a trial by fire experience.
09:42
On my project, we've been putting some processes in place to facilitate these kinds of opportunities. So I'm going to talk about what we've done, what we've learned, and then the specific strategies that you can bring to your teams to empower your early career devs. So looking back on what my team's done over the last few months, it kind of follows
10:02
this framework. So this is what I'm going to be using for this talk. There's three phases to what we did. So in the first phase, prepare, my manager and I had a lot of conversations about ways that we could coach and mentor our team to help their professional growth.
10:20
We wanted to find ways in which they could practice skills that they weren't getting a chance to practice. We also wanted the whole team to share more ownership over our project. So I started by thinking, how am I a silo? How am I, as a lead, kind of hoarding all of these responsibilities and not letting
10:43
my team get insight into them and not letting them get the experience that they need to level up? For our project and my team, the answer was client communication. I owned almost all of the technical communication with the client, which left my team with almost no space in which to practice those skills and grow.
11:02
I was also responsible for leading a lot of our meetings and for making a lot of our decisions. And quite frankly, my team was ready to share that responsibility with me. So after reflecting on that, I tried to come up with a purpose of what I wanted to do. So for me, I wanted all members of our team to gain consulting, client engagement
11:24
and leadership experience. Ultimately, what we ended up doing is having every member of our team own a feature area of our application. And then the last step in prepare is I had to prepare myself to delegate. This was the biggest challenge for me personally, and I'm seeing some head nods in the
11:43
room, so I think it's a really common challenge for anyone in a leadership role. But it's really important to share that responsibility and that accountability with your team. The way that I've been trying to reframe how I think about it is like the grounds crew at an airport.
12:01
So I'm sure a lot of you flew in over the last couple days, and when the pilot needs to connect the airplane to the jetway bridge, it's vital that they perfectly center themselves on a white J-line that's painted on the tarmac. And the FAA actually requires three grounds crew members to direct the pilot because the door is behind the cockpit and that J-line needs to be under the plane, so there's
12:24
no way that the pilot can see everything they need to in order to make that happen. And so as a lead, that should be your role on a project, is paying attention to the things that your team might not see or might not be aware of and ultimately directing them towards their success. You're not jumping in the cockpit and doing it for them.
12:46
So in the first phase, it was mostly my manager and I just talking and trying to come up with ways to put this plan into place. But I wanted to make sure that I introduced the plan to the team, that we created a shared understanding, and that they were able to give me feedback on what they wanted
13:01
out of it. So if we go back to the purpose, ours was client engagement, consulting, and leadership. And so these were the responsibilities that I presented to my team. So for us, our feature owner is the point of contact for everything related to their
13:23
feature. They own all of the client communication, all of the questions, answers, everything related to their feature. They get to practice asking questions of the client, holding the client accountable to communication deliverables, but they also get to practice answering questions from the
13:41
client, like feature requests, priority, and timeline. The feature owner is also responsible for documenting all the conversations they had with the client and everything they learned, plus things like system architecture, user stories, access control requirements, and pretty much everything.
14:04
Documentation is not a flashy part of consulting, and we all know this, but I think that written communication skills are vastly undervalued and really, really difficult to learn.
14:23
A natural extension of documentation is knowledge sharing. So we don't want all of this consulting work to happen in a vacuum, and we don't want there to just be, instead of one silo on the project, me, now eight silos. So it's up to the feature owner to make sure that everything that they've learned from the client and that they've documented gets disseminated out to the rest of the
14:44
team. The feature owner also gets to practice their decision-making skills. So they're responsible, and they're a key stakeholder in all decisions related to their feature. They get to practice both making the decision and then being held accountable to it later.
15:03
They also have to advocate for whatever implementation decisions they make when they present them to the team. And finally, meetings. The feature owner is responsible for leading all of the meetings related to their feature.
15:22
This builds domain expertise, meeting facilitation skills, and confidence. And on our team, it had the added benefit of having everyone learn when a meeting is valuable and when they could have just sent an email.
15:41
So when my team and I were talking about what our new process would look like, I wanted to make sure that we all understood what it was not. The feature owner was not going to be the sole owner and decision maker. They'd still have the support of me, my manager, and the other seniors on the project, and they would be responsible for making decisions collaboratively with me, the design
16:02
lead, and the product owner. And in the same way that a team lead doesn't write all the code for their project, the feature owner was not going to be writing all the code for their feature. They'd still have the support of their entire team members to make sure that all the tickets got picked up and worked on in a sprint.
16:21
So now it was time for us to put our new process into practice. We have an ongoing rotation of Epic Ownership, where a few sprints before we're scheduled to start working on a feature, I assign it to one of our team members. It's up to them to go initiate the communication with the client and gather technical requirements, understand their current workflow, and to raise or identify any risks that may happen
16:45
before we start working. So you can see here that Shamil, one of my team members, had two really closely related features in the first sprint, and then his next one was in sprint four, where Sasha had a feature that spanned sprints one and two, and so then her next feature was
17:03
in sprint five. And like I mentioned before, the feature owner was responsible for all of the documentation for their feature. So what my team has done is created a folder in our Google Drive for each feature where they put any and all documentation that they come across. So you can see here it might be legacy WSDLs, the results of data modeling exercises,
17:25
or just an ongoing list of questions and answers that we receive from the client. Chris, one of my team members, has actually started just keeping a Google Doc where he labels every time he initiates questions with our client and then the answers that we get back.
17:40
This has been really helpful in increasing transparency on the team because our client doesn't always respond to emails. Sometimes they slack us, sometimes they just pop into the office to answer something, and it can be really challenging for us to know which questions are still outstanding and which ones we have answers for. We also need to document decisions that we make.
18:01
So Sasha, another one of my team members, had a conversation where we made some architecture decisions about what legacy infrastructure we would need to keep around for backwards compatibility and what we could sunset because we didn't require it anymore. So for her, all she had to do is take a picture of the whiteboard, add a few bullets about the decisions that were made, and then send an email to the team that's like,
18:23
hey, if you have any questions, let me know, but just take a look. But sometimes documentation is not enough. So in this case, Sasha sent a meeting request to the entire team to say, hey, I want to review these two classes and how we're supposed to be using them, not what we're actually
18:42
using them for, which was really great to hold the whole team accountable to the responsibilities of our code. The feature owner also has to write the user stories for their feature. In the last few months of doing this, I have seen incredible growth. Our user stories have way more detail.
19:02
The estimates are way better because we actually know what work we're going to be doing, and anyone on the team can pick them up and just hit the ground running. Rather than before, it was almost always the feature owner had to do all the work. So here you can see that Shamil wrote a user story where he gave us a high-level description, some implementation notes, and he also attached a sample request file so the person
19:24
who is ready to work on it wouldn't have any questions. And throughout the feature implementation, our feature owner is also responsible for continuing that dialogue with the client as questions come up. So like I said before, it can be as simple as just, hey, these are the questions that
19:42
are still outstanding, or like this one came up. But sometimes it can be a little bit more challenging, like reminding the client that they promised us some deliverables and that they need to get those to us on time. So what are we learning from using a process like this?
20:00
Well, I'm learning that delegating is really hard. It can be really challenging to clearly explain what it is that you're looking for and to fight that feeling of, well, just let me do it, it'll be faster. But it's really important as a lead and as a senior engineer on your team that you're taking a step back and giving your team the space they need to practice these skills.
20:23
We're also learning how important feedback is. So it's super important that you, as the senior engineer, are giving positive feedback to the team about the things that they're doing amazing. Point out the ways in which you're seeing them grow. You want to fight that imposter syndrome.
20:40
But it's also really important that you make the cycle of giving and receiving feedback so normal that constructive feedback isn't scary. It can be as simple as, hey, don't be afraid to redirect the client when they go on a tangent. Some strategies that I like to use are X, Y, Z. You want to make sure that you're giving your team members the tools that they need
21:02
to succeed. And similarly, make sure that you are asking them for constructive feedback on how you're doing. I got some feedback really early in this process that I needed to spend more time with my team prepping with them before they led a meeting. That was super valuable feedback and it raised my awareness so now I can try to make more
21:24
of an effort to put some time on the calendar so that they feel prepared to succeed in these meetings. We're also learning when to offer support. This can be as simple as explicitly asking, hey, how much support do you need on this? And anyone on the team can do it.
21:43
We're going to be coming back to this idea of support in a minute, but it's really important that you're there for your team members. And finally, remember to check in with your team. It can be really easy to make assumptions about what challenges you think they are or are not ready for, but they know themselves best.
22:02
So make sure you just check in, ask them how they're feeling and what skills they want to work on so that you can incorporate that as you continue to iterate and improve this process. So how can you bring a framework like this into your team? If we think about the three phases, I'm going to use those again while we talk
22:22
about this. So in the first phase, prepare. Identify the skills that you, your team and your company value in a senior engineer. Some ideas to get you started might include technical ability. Maybe it's learning React or Kotlin or whatever the new, hot new framework might be.
22:44
Or maybe it's getting better at database design or knowing when to do unit testing or integration testing. Or maybe it's just, hey, we're doing really well, but, like, our object-oriented skills aren't so great, so let's, like, have some fun and learn algorithms.
23:04
Technical communication. Both written and verbal. Time management. I don't think this one gets talked about enough, and I don't think people think of it as a skill that can be practiced and learned, but I hope that any of my senior engineers have really good time management skills since they're going to be juggling
23:23
a lot of responsibilities. Maybe you want your senior engineers to be able to look at the big picture and be able to make decisions based on the product and not just the short-term feature timeline. Mentorship. This is especially important if you have a lot of mids on your team who are going
23:42
to be stepping into the senior role soon. Consulting and client engagement. I know my list skews very consulting-focused. This is just meant to get you started. So once you've identified the skills that you and your company value in your senior engineers, narrow it down and identify what are the gaps on my team specifically.
24:04
The whole goal of this process is to create something that's tailored to your current team as it stands today. So some questions to ask to narrow this down might be, how are you as a lead a silo on the team? What skills do you wish your team got to practice?
24:23
And what skills are needed for individuals to level up? And while you're going through these thought exercises, make sure you're considering the scope of your project. You want to make sure that your project is big enough to accommodate all of this
24:40
new shared responsibility. You want to avoid the too many cooks in the kitchen problem. So on my project, it's 18 months long, there's lots of distinct application areas. By spreading this responsibility around, it actually decreased overhead and lightened everybody's load so that they could focus on their personal career goals.
25:05
So now you have the skills you value, the ones you specifically want to encourage on your team. Make a clearly defined purpose that you want to achieve with that. You want your purpose to be narrow enough that it sets crystal clear expectations but
25:22
broad enough that there's a variety of ways that you can achieve it and that it gives your team a variety of opportunities to practice these skills. So as a reminder, my team's purpose for this new process was for everybody to gain consulting, client engagement, and leadership experience.
25:41
You'll notice that I didn't list every skill that I value in a senior engineer and I specifically stayed away from the hard technical skills because that just wasn't important for my team. But you'll also notice that my purpose isn't for people to get better at leading meetings. Because that's just too narrow and that doesn't give everyone enough space they need
26:01
to grow. So how do you achieve this purpose? It's time to identify the responsibilities that would help you do that. Again, some questions that I asked that helped me identify them were what responsibilities satisfy one or more of the skill areas you chose?
26:22
What types of tasks serve the purpose you identified? What responsibilities do you have as a lead that everyone on your team can share? And what responsibilities do you as an individual find challenging to keep up with?
26:41
So these were the responsibilities that we outlined on my team and I find it super helpful to identify three to seven responsibilities. Anything less than that and it becomes really easy to ignore and anything more than that is just unmanageable and you can't track it. I've also found it helps to write it down or visualize it in some way because if you
27:03
can find responsibilities that satisfy more than one of your skill areas, that's a really good indicator that it's a good candidate for you to focus on. And by making them as clear as you can, it also makes it easier to track and talk about in one-on-ones or other types of reviews that you may do on your team.
27:24
We've actually had one team member get a promotion in the last few months since we've done this and it was super helpful for him to have the vocabulary of all of the things that he's been working on and all of the experience he's gained during his yearly review. And I know I've said it a million times, but really, really you have to prepare yourself
27:44
to delegate. It is so challenging, but it is vital to making this process work. So in the proposed step, schedule some time with your team to introduce this plan. I know that having a framework like prepare, propose, and practice can feel really formal,
28:03
but the only goal is to tailor it to your team. So make it as formal or as informal as you want. When I introduced it to my team, I used a Wizard of Oz themed deck where every responsibility and every feature was a step on the yellow brick road until we hit Oz, which was the project's over, we've all grown, and we're done.
28:24
And make sure that you're using this opportunity to solicit feedback. You should be asking your team or trying to understand if there's skills that they would like to practice that you may be missed. Do they feel comfortable but challenged by the responsibilities that you've outlined?
28:43
Is there anything they want to add or clarify? And do they feel that this implementation will be sustainable? This last piece is really important. You don't want the responsibilities to be so overwhelming that your team's going to get burned out, but you also don't want it to feel so easy that they can be
29:01
ignored and put on the back burner. So now it's time to put your plan into practice. Again, follow through and delegate. Don't jump into that cockpit. Take the time to explain what you need your team to do and to support them while they do it.
29:20
So there's lots of different ways that you can offer support. Some can be really formal. You can have regularly scheduled one-on-ones with all the individuals on your team. That way they have a time and a place to talk about their specific challenges and their specific questions. But it might be as simple as reading an email before they send it, just to make
29:42
sure that their ask is clear or that their request is actionable. One of the challenges we've had on our team is getting responses from the client. So it can be really helpful to have another set of eyes on that email. Or maybe like me, you need to spend some time prepping with them before they lead a meeting.
30:03
And for those who haven't had the responsibility of writing stories for their team, pairing can be really helpful. We all know it's hard to know how big to write the story or how small to write it or what details to include. And so having somebody there with you can make it a lot easier. And related to that, if somebody doesn't have a lot of experience doing
30:23
data model or other architecture exercises, it can be helpful to pair with them on those as well. You can be there to ask questions that help guide their thinking so that ultimately it is them that's doing it, but you're just kind of there as training wheels until they get used to those types of decisions.
30:42
And related to the story writing, data modeling, and architecture decisions, I found that it can be really helpful early on to send calendar invites just to set expectations for how long activities like that should take. You want to make sure that you don't have people on your team who are spending three days on something that should have just taken an afternoon.
31:03
Or that they spent more than a cursory 15 minutes on something that they should have given their full day to. And just be kind and give them reminders about deadlines. They're taking on a lot of new responsibility and things can get lost in the shuffle.
31:20
So it's as simple as saying, hey, I know you promised that documentation to the client by Friday. It's Wednesday, I'm just checking in to see how it's going. But above all, you want to make sure that the support that you're giving to your team is individualized. Every member of your team is going to have different strengths and
31:40
challenges, and you want to make sure that you're giving them the support that works for them. Our industry is missing out on so much talent, because we're not doing enough to support those early in our career. We all need to do our part to empower early career devs to grow them into the amazing seniors and team leads that we all know they can be.
32:09
Thank you.
Recommendations
Series of 13 media
Series of 14 media