rss.xml

<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Managing Reflections]]></title><description><![CDATA[Homepage and blog of Dan Applegate, a software engineering manager in New York City]]></description><link>https://danapplegate.com/</link><generator>RSS for Node</generator><lastBuildDate>Tue, 25 Jun 2019 04:56:03 GMT</lastBuildDate><item><title><![CDATA[What's in a name?]]></title><description><![CDATA[Picture this. You’ve just joined a new company as a manager. You’re inheriting a team.
]]></description><link>https://danapplegate.com//whats-in-a-name/</link><guid isPermaLink="false">https://danapplegate.com//whats-in-a-name/</guid><pubDate>Mon, 17 Jun 2019 23:38:00 GMT</pubDate><content:encoded>&lt;p&gt;Picture this. You’ve just joined a new company as a manager. You’re inheriting a team.&lt;/p&gt;
&lt;!-- end --&gt;
&lt;p&gt;Your first day finds you getting the lay of the land, surveying your organizational structure, trying to understand how your adopted team fits into the big picture. The org chart seems pretty straightforward. Lines are drawn along familiar divisions, territorial ownership proclaimed through self-evident monikers that are reminiscent of heraldic titles. The Backend Team. The Frontend Team. Devops! Finance! Sales! The Middle Eastern Global Partnerships and Strategy Team! &lt;sup&gt;wait for the fanfare…&lt;/sup&gt;&lt;/p&gt;
&lt;p&gt;And there at the bottom, your own fiefdom of plucky and endearing misfits: The Security Team. Struggling valiantly to vanquish insecurity wherever it may rear its ugly head.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;Ah yes&lt;/em&gt;. You nod your head sagely. &lt;em&gt;This makes sense&lt;/em&gt;, you think. &lt;em&gt;I now know our place in the realm; our duty is clear&lt;/em&gt;. Then a glimmer of doubt.&lt;/p&gt;
&lt;p&gt;Do you? Is it?&lt;/p&gt;
&lt;p&gt;Team names are powerful and subtle. They’re present in everyday conversations around the office, and they’re one of the first things a prospective hire sees upon reading your job posting. Within and without, they’re a tool of identity. You belong to a team. No, not just any team. &lt;em&gt;That&lt;/em&gt; team.&lt;/p&gt;
&lt;p&gt;When your team was formed, someone made a decision on what to call it. They had to, or someone else (or worse, multiple someone elses with conflicting ideas) would have decided for them. Absent anything to the contrary, a name like “John’s team” might become the official name &lt;em&gt;de facto&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;A growing organization will go through a natural progression of team naming conventions.&lt;/p&gt;
&lt;p&gt;First, there is just the founder or founders. A single team, whose name is simply the company’s name.&lt;/p&gt;
&lt;p&gt;A few hires later and teams begin to form around separate concerns. The team is still small enough and the product still in too much flux to allow for discrete chunks of identity among the mess of half-baked features and experiments. Everybody works together on all the things. So identity is refined from other sources, usually by grouping people by the type of work they typically do. The Backend, Frontend, Design, and Business teams begin to form.&lt;/p&gt;
&lt;p&gt;After a certain point, the product matures into several closely related features. The people who built each feature continue to work on that feature and hire more people to help them. Stratified, job-based team names don’t really mesh with how people are actually organizing and discussing themselves or their work. So the structure moves towards a feature-based naming scheme. Enter “The Payments Team,” or your own Security outfit.&lt;/p&gt;
&lt;p&gt;It’s a natural, evolving progression that meets the needs of the company at each stage. It works. Yet with just a bit more intentionality when we choose a name for our team, we can harness the inherent value of &lt;em&gt;identity&lt;/em&gt; to also drive &lt;em&gt;purpose&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;Consider a name like “The Payments Team.” It conveys identity, sure. It may even suggest the types of features the members of the team will likely work on. But it doesn’t inspire. When someone says they work on The Payments Team, you learn nothing about what drives that group of people, what they’re hoping to accomplish, or what pride they take in their work.&lt;/p&gt;
&lt;p&gt;Instead, imagine if the person naming the team had decided upon “The Payment Accuracy Team.” Subtle, right? What do members of this team care about? You can’t miss it, it’s right there in the name: They care about ensuring that the payments are accurate. Identity and purpose, expressed together as one and the same.&lt;/p&gt;
&lt;p&gt;Notice that going from “Payments” to “Payments Accuracy” implies a narrowing of scope. That’s a good thing. While a Payments team could work on all things payments – speed, accuracy, auditability – can they truly focus on all of them at the same time?&lt;/p&gt;
&lt;p&gt;For all the fretting we do as managers, wondering whether we’re doing enough to keep our team aligned, what if we co-opted every mention of our team’s name as an opportunity to align on our goals? Every mention of the team’s name could also be an affirmation of its reason for existing. It’s an aspirational call to its members, and a badge of honor to others in the company.&lt;/p&gt;
&lt;p&gt;The cause-effect relationship between values and identity is a lot more fluid than we might have previously thought. &lt;a href=&quot;https://web.archive.org/web/20190618025901/https://opentextbc.ca/socialpsychology/chapter/changing-attitudes-by-changing-behavior/&quot;&gt;What we decide to call ourselves can have a profound impact on what we believe&lt;/a&gt;. Why not take advantage of &lt;a href=&quot;https://en.wikipedia.org/wiki/Self-perception_theory&quot;&gt;that powerful effect&lt;/a&gt; to drive progress, especially since the act of naming a team is so trivial?&lt;/p&gt;
&lt;p&gt;Going back to your first day as the new team lead. Your manager comes up to you asking you to put together a presentation for the rest of the kingdom.&lt;/p&gt;
&lt;p&gt;“Hey, could you put together the Security Team’s roadmap for the next quarter to present to the company?”&lt;/p&gt;
&lt;p&gt;Or,&lt;/p&gt;
&lt;p&gt;“Hey, could you put together the Trust and Safety Team’s roadmap for the next quarter to present to the company?”&lt;/p&gt;
&lt;p&gt;Which team would you rather be a part of?&lt;/p&gt;</content:encoded></item><item><title><![CDATA[Hello World!]]></title><description><![CDATA[A few years ago, I got the idea that I should start a blog. I was a software engineer, working at a startup in New York City, and I was…]]></description><link>https://danapplegate.com//hello-world/</link><guid isPermaLink="false">https://danapplegate.com//hello-world/</guid><pubDate>Sun, 09 Jun 2019 17:47:00 GMT</pubDate><content:encoded>&lt;p&gt;A few years ago, I got the idea that I should start a blog. I was a software engineer, working at a startup in New York City, and I was learning a ton of exciting things about building software. I wanted to share them. I promptly bought a domain, cloned a static site generator, published my first post, and patted myself on the back.&lt;/p&gt;
&lt;p&gt;I never touched the blog again.&lt;/p&gt;
&lt;p&gt;Now that I am a few years older and a manager of engineers, I wonder what I would say if I could meet with my former self in a one-on-one. One of my favorite parts of being a manager is working directly with my reports. I love helping them reach their goals. It’s the most rewarding part of my job, seeing their self-confidence and determination grow. Perhaps a part of me feels like I’m conquering my own unfocused nature – if only vicariously – and that if I can just practice what I preach, I can accomplish every halfway ambitious thing I set out to do.&lt;/p&gt;
&lt;p&gt;Including this. Writing is a laborious process for me, so maintaining a regularly updated blog is a bit intimidating. Whenever I read authors’ reflections on their own writing process, I’m always amazed at how straightforward they make it sound. First you write the first draft, then second, third, fourth. Revisions and rewrites. Writing something down without giving it too much thought, simply to get &lt;em&gt;something&lt;/em&gt; down. They talk about the importance of regular writing and setting a goal for oneself – say, 1,000 words a day – and sticking to it, no matter what.&lt;/p&gt;
&lt;p&gt;For me, that sounds terrible. When I write, I agonize over every sentence before I write it. I hate going back over my draft work and second-guessing myself, because I can usually argue myself in circles about what would sound best. Perhaps I can reduce that friction over time and get to the point where 1,000 words a day doesn’t seem so impossible. I don’t know.&lt;/p&gt;
&lt;p&gt;What I do know is that I’m feeling that itch to write again. I’m learning so many new things about software management and I want to share them. I want to test those ideas against what others have found and see if there isn’t a better way. And maybe through the act of writing these posts, the practice of maintaining this blog, I’ll become better at simply writing down my thoughts before I stop to think.&lt;/p&gt;
&lt;p&gt;One piece of advice that I’ve always found invaluable when faced with a large task is to break it apart into smaller, more immediately accomplishable goals. Writing a single blog post doesn’t seem so bad. Hopefully this post will be the precursor to another, and then another, and before long, I’ll have a well-maintained and regularly updated blog. Even if nobody reads it, it will at least have taught me to write better.&lt;/p&gt;
&lt;p&gt;If nothing else, my former self will be impressed.&lt;/p&gt;</content:encoded></item></channel></rss>