Architect
1a. Architect an application you don't actually build. This includes pitch if applicable, creating visual diagrams of how it all works, & time estimations, effort, risks, & integration points.
1b. This is hard b/c if you have passion for coding, you want to see your creation come into being, & want to help it become so by coding the fun parts. You don't. You can do parts, sure, and sometimes it's your area of expertise. It's more impactful if you have others do it.
Grooming
2a. Grooming. You've done enough projects that you have a general idea of 20-80% of the work. You might not know the minute details, but "build a login flow", "setup CI/CD", "do form validation on email". The key is answer either at story or epic level "what are we doing".
2b. Depending on your people management/product owner/product management, this can involve a LOT of "not coding". Not just meetings, but your own time spent writing, organizing, planning. This includes either updating the architecture as you learn, or vice versa.
2c. Part of this is also figuring out how to delegate the parts to others you shouldn't be doing. If your management is the one who sells to client/leadership, they should be the ones organizing/prioritizing into a big ole deck/spreadsheet. You should stay tech.
Code Review
3a. Code review. While this should be done your whole career, your responsibility is not just "30,000 ft view of architecture", but also in the weeds as well. Ensuring the code quality & methodology supports the team's architecture. Teach. Mentor.
3b. This doesn't just mean "you forgot a return in this if statement". It means writing lots of code examples in the PR's, pointing to other more advanced references you yourself have read & vetted. Sometimes it means PR's against the PR's.
Influence
4a. Influence. You can't tell someone to build or fix code unless you're trusted. Not all code has a correct way to be written. Tons of human, illogical nuance. To get people moving in a single direction, you have to be influential, charismatic, liked, or trusted.
4b. Various tactics on how to do this. Since I loathe sales, I put in the hard work of helping everyone I can, consistently, and building helpful tutorials and reference architectures. I try to listen, be empathetic, and let people in their own direction and pace. My code works.
4c. For non-tech influence, this means "translating tech speak" to business/people managers. I use metaphors, tl;dr; at the top, target business 1st in decks, tech last. I ask questions & repeat back; they know I care about their needs. I give them the illusion of choice.
Improve Teams with New Technology
5a. Improve teams w/tech. Not just "hey, Angular or AWS has this new, helpful feature", but translating that to business/manager speak, doing architecture around it, time estimations, story acceptance criteria, and reference architecture within an existing codebase.
5b. This includes pitching senior leadership whose responsibility it is to be wary of new shiny trojan doom, and verifying yourself you can even use it from a cyber/security perspective. Not just 1 team, but more than 1. It should lift many boats.
5c. Sometimes it's not used and this just ends up being new knowledge. That's still great. Devs of all skill levels, including first day employees share equal value knowledge. Some do this by side effect of being smart. I do it because I love helping people.
Being Wrong, Reserving Your Right to Change Your Mind
6a. Being wrong & reserving the right to change your mind when presented w/new evidence. Software is about people. We use the word "engineering" around it as an attempt to mentally deal w/the fact it's messy & not very scientific at all. It's very artistic, opinionated, biased.
6b. Instead of "Oh, I didn't know we needed that level of Transactions Per Second" it's "oh, I see, cool, so we'll have to change to a more powerful server". Instead of "but Angular is cool!" it's "this intern will crush it in JQuery on this small part".
6c. Above is hard if you had your heart set on either a particular tech stack, or technique. There WILL be opportunities for you to play, but tech leadership isn't about you; it's about others first. Do what's right, but do it on the evidence you know right now. Change if need be.
Be Vulnerable
7a. Be vulnerable. Different then being wrong & is super hard for guys, & why women excel here; they don't have alpha male bs baggage. Lead w/"I don't know", "I want to learn more" vs. "I know all this". Goal is to be a sponge of knowledge, not a battering ram of skill.
7b. This means you publicly, honestly show you love learning from others at all skill levels, you honestly want them to succeed, and your agenda is just that: to learn and have fun. It seems weird to relinquish control, but leadership is what most don't actually control.
7c. Being vulnerable means picking up the ball of leading, publicly admitting your faults, what you've done, what you'll do better, what you've learned, acknowledge those who helped you and their ideas. Others may choose Rust, but you influenced where they used it.
7d. And on the topic of women, while they may not have the alpha male overbearing, non-logical, emotion fueled desire to prove themselves to compensate for insecurity, they ARE working with those who do that. Spot it, & fight for their right to speak.
7e. You'll be perceived as weak by those who aren't mature enough to know what they're doing, or who are "in the moment". It's the right thing to do, not the easy thing to do. This includes admitting yourself when you screwed up. I'm a ball of honest "sorry"'s.
Network, Make Friends & Contacts
8a. Network. Often times you don't know everything. But you should know who does know something that'll solve your problem. Nurture those relationships. Show them they're valuable, and bring them to solutioning meetings you setup.
8b. This is also for yourself. Want to get better at pitching to business? Find the hard ass sales guy & demand he teach you. Suck at Unix? Buy the Ops woman lunch so you can drain her brain of knowledge for an hour. Teacher/student relationships work both ways... AND are true relationships.
Build Tools & Connect the Dots
9a. Build tools & Connect the Dots. A more helpful unit test library to help yourself is one thing, but if you suddenly open source that and it improves the lives of hundreds, THAT is cross team impact.
9b. Eventually you'll learn to do the opposite; spot that cross-team problem and proactively build a tool/cli/etc. Open Source does this day 1, but not with all the work of implementing it in projects. Pitch to business, explain nuance to tech leadership, and lead development.
Fail A Lot
10a. Fail a lot. Do not neglect continuing to code. The cool thing about development is that you can keep doing the same routine of building things to get better at building things. This includes continuing to fail in spectacularly new, and horrible ways.
10b. You do what you've always done. Learn from these mistakes. Business had no clue what you were saying. Senior Leadership thought you were abrasive and close minded. You perceive yourself as right, everyone else thinks you're nuts.
10c. Failures are not the end, they are seeds of growth!
Conclusions
The above is development feature team biased.
Architecting things you don't build is hard. Realize you can carve out places "for you" to help. Sometimes that place "for you" disappears. There will be others.
Teach grooming to your teammates and delegate the un-fun stuff. Managing up sucks, but sometimes it can be a group effort.
Be thorough on code reviews; remember, we all naturally project so you're also inadvertently critiquing your own weaknesses through others. Win win!
Practice speaking, writing, pitching, selling, marketing, interviewing, asking questions of developers, speaking about complex tech, all of it. Care about others. It's hard since this is about people, not coding. People are whack.
Learn new tech, explain how it'll be fun for others. Validate if it genuinely solves a problem, else identify why you think it'd be more fun than status quo solutions. Practice pitching others on using new stuff. Continue to exchange knowledge.
Be wrong, change your mind, don't attach a belief to your very being. That's how science works. You learn something new? Cool. Change your mind again? Cool. Being flippant is different than being flexible.
Be vulnerable. Best weapon against insecure alpha males. "I don't know" is your shield "I'll figure it out" is your sword "we'll work through this together" is your Viking Shield Brother. Always be a student who attempts to practice what you learn.
Network. Talk to people. Ask 'em questions. Have them speak about what they're passionate about. Act like you care by just listening. Sometimes being quiet together is ok too. Validate their skillset as awesome and helpful in the world.
See how multiple teams have the same problems. Figure out how to solve that. Build things, sometimes many attempts until you get it right.
Fail a lot. Learn a lot. Be proud of that long history of screw ups that lead to you having many stories, knowledge born from experience, and empathy to your fellow devs who may be going through what you went through.
So why do these "suck"? Because they aren't coding building cool things with your favorite toy. Make sure you make time for that. That's why you do all the other stuff with confidence... because you know how to build things and still enjoy it.
Top comments (0)