In late 2018, GitPrime interviewed me about the onboarding program we developed here at Drift. I discuss the strategy and value of the program, and share some secrets about how to execute it successfully.
This is their content, and I have marked their URL as the canonical original for SEO purposes. Contact me at firstname.lastname@example.org if you’d like me to remove this story.
That’s because setting up their laptops, while critical, isn’t contributing to the team. So by early afternoon on their first day, they’ve completed all the no-op stuff. …
Hi, I’m Pete, and I’m sharing this because everything I needed to know was spread all over the place. Hopefully this helps you out.
Why? Parity with production pays off.
btw — the use case that started me down this path was local cookie testing, if you must know 🤷
To keep this from being a full blown
foobar example, I’ll use… a natural history museum as an example! …
In engineering management you end up with 3 kinds of leaders.
I’ve had the privilege of working with top-notch software engineers who are interested in leadership. In the interest of helping them see success in an engineering management role, I recommend three books.
These three are the non-negotiables. I recommend them to every new manager. The applicable lessons and mental models therein are priceless.
No surprises here. This book is at the top of everyone’s leadership lists for a reason. Personally, this book helped me diagnose some ruinously empathetic behavior and completely transform the way I build trust and give feedback. …
Full disclosure: this isn’t about destroying employers. It’s about making a difference instead of venting online.
I get it. You feel a TON of resentment, and probably also feel like your direct manager is PART of the problem. Talking with them directly is NOT an option.
If your experiences have been anything like mine, there may have been a build up of irritation over time, like a slow burn. …
Finding new ways to solve problems is tough. As an engineer, we’re fed a lot of resources for becoming better technologists. Unfortunately, we aren’t trained to become more persuasive.
As you grow into senior roles, you’ll have to do more wrangling. You’ll be expected to persuade people to work together, to challenge themselves, and to make the team successful (which can require personal sacrifice).
I found inspiration in sales. Specifically, I looked at how sales trainers turned salespeople into successful persuaders.
I joined a few of my teammates at Drift to break down how product and engineering can work together most efficiently (which means breaking through the perception that engineers should be wholly removed from the customer).
Give it a listen! There are some gems for PM and Engineers alike!
Read more on Drift.com or watch the interview above!
Originally published at https://www.peteisa.party on January 6, 2019.
Here’s the thing: you should be reading. A lot. Especially if you’re a technical lead or trying to level up your engineering role.
It’s easy to focus only on the daily grind. After all, software engineering is a challenging job, and you worked hard to get to where you are. You’re basing your day-to-day work on everything you’ve learned over your career.
This isn’t a bad thing.
If you’re lucky, you have a great technical mentor who sometimes drops wisdom on you, but they’re not always available. You’ve only learned from your work, little by little, every day.
Your implementations are limited to your personal experience and observations. …
This is something people ask me a lot. They say “Pete, how do I get promoted? I’ve been an engineer for a year or two now, and I’m ready for the next level.”
The best way, without fail, is to learn from the successful seniors at your company. There is no rubric which works for everyone. Every company is different and to succeed, you must adapt to your culture.
I have been in jobs where I barely grew over the course of a year. I was waiting for the company to lay out the groundwork that would allow me to excel. I thought I was powerless to grow until we had structure for growth, signed and dotted by senior leadership, with guaranteed salary and title changes. …
These are my learnings, and you can bet this is a work in progress. Here goes!
Before I jump into methods, let’s talk outcomes.
The worst outcome would be a group of overwhelmed programmers, fully dependent on others for instruction. They wouldn’t know their role in their team or their department, and they wouldn’t be able to connect their day-to-day work with the success of the company. …
“We ship fast, and we focus on things that are useful” is what we say to engineering candidates. It isn’t until their first week at Drift that they understand what we mean by fast.
Teams here consist of two engineers (frontend & backend), a designer, a product manager, and a tech lead.
Each team focuses on meeting the needs of several related jobs to be done (JTBD). Teams are autonomous, but not without accountability. Each are expected to show visible progress every week (if not daily). It’s not unusual for folks to go the extra mile to ship particularly thoughtful or valuable work. …