DEV Community: Sumeet Jain (he/him)

Stop asking questions throughout your presentation.

Sumeet Jain (he/him) — Wed, 13 Nov 2019 22:28:38 +0000

A presenter might ask the room, "Does anyone know what this abbreviation stands for?"

A common mistake that people giving presentations make is asking easy questions with obvious answers every few slides. The presenter's understandable (but misguided) intent is to keep the audience engaged. Perhaps counterintuitively, these easy questions do the opposite of boosting engagement.

When someone asks a question like, "Does anyone know what this abbreviation stands for?", they're breaking important focus, taking their audience out of the zone, and doing so for the meaningless reward of superficial audience engagement.

Why do obvious questions break audience focus?

To understand why these questions are a problem, consider for a moment what the audience would be doing if the presenter didn't ask a question here:

Listening and building a mental model to represent the ideas they're seeing and hearing.
Relating the concepts being presented to other ideas they're already familiar with.
Evaluating what's being presented to decide if they agree or not.

Once the presenter asks, "Does anyone know what this abbreviation stands for?", what is the audience doing instead? They're accessing their knowledge store of trivial information, surveying the room to see if anyone else is going to raise their hand first, and wondering if the risk of being wrong is worth the reward of speaking up.

What they're not doing is thinking critically about the material, which means they're not engaged.

There's a better way.

So what should a presenter to do instead? Well, let's back into the tactics by thinking of the goal first: If you're presenting, your goal is to deliver the content, spark critical thinking, and foster engaging discussion. You're probably hoping there's some healthy debate and the sharing of meaningful experiences to add color to the presentation's subjects.

In order to achieve these goals, your audience needs to feel a connection to the content.

Give them some uninterrupted time to process what you're presenting, to add it to their mental model. Importantly, this doesn't mean you need to stop talking. People can process quite a lot while they're listening.

Put yourself in an audience member's shoes: When you watch a good presentation, you enter a zone where the speaker's voice is a pleasing background track in your mind. And the slide being shown is a good place to rest your eyes and keep your mind from wandering. This can be an ideal state for getting lost in intense thought. It's wonderful. (And the sporadic, obvious questions just take people out of this zone.)

So keep a medium pace when you present. Know the content well enough to get through its exposition without unnecessary breaks. Anticipate the mental models you want your audience to be building, and pause to stoke the flame of conversation when your presentation arrives at a genuine punctuation point in that building process.

At that time, ask a deeper question to facilitate a more substantive conversation. Focus a lens on the nuances and conflicts surrounding the ideas you've presented, and encourage the audience to give their takes.

Preparing for greatness

To host such conversations, you need to prepare in advance. A good question to ask yourself as you're creating the presentation is, "What are the first objections or additions experts would make about this concept?" These are the deeper ideas you should be addressing. Your presentation should aim to equip the audience with enough context for them to engage on those deeper ideas.

The burden is on presenters to go beyond the first level of understanding on an issue. If you put in the work, you'll build a reputation as a speaker that begins with basic subjects but says something new about them. Nothing is quite so captivating to an audience member as learning something new about a subject they thought they'd already mastered.

Questions to ask a team you're considering joining

Sumeet Jain (he/him) — Tue, 12 Nov 2019 00:13:42 +0000

I recently chose a new team to work on at Box, and I wrote down some of the questions I asked the teams as I interviewed them to make my decision.

What are things that need doing that no one is doing? Things you’re doing that you wish you weren’t?
How do your Tech Lead and Eng Manager split responsibilities?(Especially useful to compare answers given by people on the team who are the TL/EM vs. those who aren't)
What’s the tech stack? (Have them whiteboard the layers out and ask questions until you understand it enough to re-explain it.)
Who are the people that add pressure to the team? In what ways do they add pressure?
How is status reported and tracked?
What’s your career growth plan? When do you anticipate you’ll be promoted? (Don't forget to also ask this of people who would be above you in the management chain.)
How far ahead do you know what you’ll be working on?
What’s a recent technical discussion you were part of? (Ask enough questions to fully understand it and be able to restate the resolution to an outsider.)

As always, the most value comes from followup questions, but these were good starters.

Let me know if you find these useful, and feel free to add your own in the comments.

Brief: 2 Tactics for Fostering Mentorship

Sumeet Jain (he/him) — Mon, 16 Jul 2018 20:11:52 +0000

The current state of advice on teaching mentorship skills is essentially, “Value it. Do more of it.” That isn’t wrong. But sometimes more specific tactics can help to create mentorship expertise over time within your team. A couple of my favorites:

1. Establish "question standards" in the same way you have "coding standards".

Creating a framework for how questions should be asked gives your devs a way to help each other without just supplying direct answers. Instead, they can help someone who's struggling by guiding them towards a well-structured question. Sometimes the answer even emerges from that process organically.

Careful not to become zealots about this. If a person is struggling with the question format, make time to help them on their terms.

2. Discourage private messages in Slack.

If a dev has a question, they should ask it in a channel that the relevant audience can see. Making more questions visible sends a message that questions are normal, even from more senior folks. Here's a direct quote from our Slack: "Well, since this channel's a bit more lively now, I have a question."

This also results in more devs knowing about pain points. Part of improving mentorship is being aware of what's difficult. Otherwise, it's easy for devs to underestimate the complexities in your systems/processes.

Immediate & Actionable Tactics For Leveling Up Devs

Sumeet Jain (he/him) — Tue, 22 May 2018 20:02:35 +0000

Slides:

Everyone seems angry about hiring, onboarding, and retention. This is what happens when we value something, like mentorship, without knowing how to achieve it. Worse is that much of the advice out there is not actually tactical... Instead it's just more reasons why we should value mentorship.

This talk is not about valuing mentorship. No one needs to be convinced of that anymore. The more interesting question is assuming you already value mentorship, what tactics can you employ that 1) work effectively across various teams, and 2) don't undermine other qualities of a team that you also value.

My goal for this is to present to you at least a couple ideas that you’d never heard before and be able to immediately add them to your internal playbook. Here are the 3 broad categories of tactics I'll cover:

Mentorship is not intuitive--it's something a person must actively learn to do. I'll go over a few very specific actions teams can immediately take to start training their devs to be better mentors.
Train on business logic and tooling before code. Most training is focused on code (like "learning lunches" where a person presents a new library they're learning), but new devs struggle most often with non-code problems (like understanding a business domain or knowing how to employ tools to debug more effectively). I'll present an argument for why this is true, and then I'll list a few actionable strategies for non-code training.
Promotion and retention. Companies would sooner die than lose their most senior developers, because there is so much institutional knowledge that only those seniors possess. I'll cover several immediate actions that teams can take to spread the wisdom around to more team members and finally create a proper junior-to-mid and mid-to-senior pipeline within the company.

Companies that can grow talent from within have a huge advantage. But without realistic and actionable tactics, that advantage will always be out of reach. This talk will change how teams approach training by handing them several usable strategies, and by giving them a framework to create their own playbook.

How My Mom Taught Me to Make Websites

Sumeet Jain (he/him) — Wed, 25 Oct 2017 21:24:38 +0000

Originally posted on May 29, 2012 at sumeetjain.com.

I learned to build websites when I was primary school age. Like many of a child's hobbies, my interest in web design peaked about five minutes after my first victory and hit a low about five seconds after my first failure. My hobby graveyard was full of such corpses: calligraphy, pogs, BMX biking, poetry, Abraham Lincoln, etc. Web design was on the verge of joining that cast. Then Mom stepped in.

Even though she didn't have a technical background, she could see that knowing how to build websites was more than a hobby. It could be a viable career skill. She also didn't need to be a technologist to know that whatever I had taught myself so far barely scratched the surface. That meant there was lots of additional value to be gained from the hobby, but it also meant that there would need to be many more little victories to keep me motivated. Her challenge was to keep me active in the hobby so I could encounter enough victories to develop a genuine passion for it.

People are motivated by different things at different times in their life. As a kid, I knew only enough about money to know that it was glorious for some reason. Mom told me that I could earn $1,000 over the summer if I wanted to. That got my attention. A thousand glories sounded great.

It was a slow process. She handed me the Better Business Bureau catalog and told me to start cold-calling local businesses. My opening line was, "Hello. I'm a young web designer, and I'd like to build a website for your business for free." Eventually someone took me up on the offer. I made a basic company website with FrontPage and uploaded it to Tripod's free hosting service. I think I did one or two more free sites that summer.

I wasn't thinking, "Where's my money?". I was having fun playing with new tools. Sometimes I'd accidentally screw up a setting on the computer, and I'd call Dell Customer Support to get help fixing it. I owe Dell's phone staff a huge thanks for their patience. Dell technicians were the first people to teach me about FTP, defragging, 'ipconfig', GIMP, and so much more that went beyond the scope of customer support¹.

I was working my way through the "G"s in the BBB catalogue when a local business called actually called me. The owner of Miramar Flooring was friends with the owner of one of the businesses for which I'd built a free website. He asked if I would build him a website. It sounded more complicated than the other websites, so Mom talked to him to learn the details.

We visited his store and took pictures of the carpet and flooring samples, and he sent me some content for pages. I struggled a lot with the project. The design (which was a template from Macromedia Fireworks) was more ambitious than the previous designs, and it was my first encounter with fancy effects like link rollovers. I finished the website eventually, and the client was happy. He paid me $800 for the website (Mom negotiated the terms).

Fast-forward to today: I've built a solid career around making websites. My job lets me do all the fun things I want, and often my job is the fun thing I want to do. I'm so grateful that I had someone to push me harder than I was willing to push myself. Mom's support was precisely executed, and it came at such timely moments.

Remember, you do not have to be a parent to support someone. More boldly, you do not have to be a parent to push someone beyond their comfort zone. Whom do you support? Whom do you push harder than they push themselves? Who fills that role for you?

Technical support at large companies today is run differently than it was when I was a kid. I wonder if they would be as generously helpful to a child today. It'd be cool to build a general technical support staff that only accepts calls from kids. I know some parents who might pay for something like that. ↩

Should/can employees ignore the social views of their coworkers and bosses?

Sumeet Jain (he/him) — Wed, 11 Oct 2017 13:57:59 +0000

Especially for those views that one sees as dangerous to their existence, is it reasonable to tell an employee to ignore their coworkers'/bosses' social ideologies?

I know thinking in the abstract can be difficult, so here are some examples among many to start the conversation:

A Muslim employee sees their Facebook 'Friend' vehemently defend a travel ban that is preventing their family from joining them in the US.
A Mexican employee sees a coworker post meme after meme about how people of Mexican heritage are lazy.
A woman (or anyone, for that matter) sees their boss fighting for a universal ban on the right to have an abortion for any reason.

I'm not suggesting that one investigate to discover these beliefs. But in this modern era of personal/professional mixing, coworkers 'Friend' each other on Facebook and follow each other on Twitter. They often hang out after work (and failing to do so, if we're being honest, will have some impact on one's advancement).

So if someone is broadcasting social views that an employee feels personally threatened by, what should the employee do?

Getting the Most Out of Investment Time

Sumeet Jain (he/him) — Tue, 10 Oct 2017 04:04:21 +0000

Plenty has already been said about "investment time":

Some engineering teams set aside Fridays each week for their employees to work on something outside the scope of their billable duties.
For many employees at such companies, investment time is a cherished perk of their employment.
Setting aside a day each week can reduce stress, since it adds margin to a person's week (They can use investment time to catch up on a project if it's running behind).
Investment time can be a great way for people who usually work on different teams to spend some time together.

Investment time can be a wonderful boon to a company's health, and I'll always fight for making it part of a team's culture. But it's also possible to undermine investment time if management is careless with its application.

If your company has investment time, but you've felt like it isn't as great as you'd initially envisioned, some of what follows might resonate. I'll also go over how teams sometime miss opportunities to make the time even more valuable.

(And if none of the below resonates, great! Sounds like your team is doing it right.)

Investment time is an extra burden for managers (but it's worth it).

Sometimes investment time is perceived as "free" time for individuals to do with as they see fit--as long as they're not overtly wasting it. This approach may work for some employees, but it will fail for others. Importantly, it will probably fail silently.

For it not to fail, or for it to properly "raise errors" when it fails, management needs to accept the added burden of helping their team use investment time well. Obviously, employees who are less self-directed than others will struggle with freeform investment time. But less obviously, junior team members who are self-directed might still flounder without guidance.

Allocate enough time, or the investment will not pay off.

I know of some companies that only set aside 2-3 hours per week, or only 1 day per month, for investment. That isn't enough time.

A weekly block of 3 hours isn't long enough to make meaningful progress building something (or, if it is, it's barely enough time). Worse is that your team members probably won't be fully productive for the remaining 4-5 hours due to the context switching. Commit the full day to investment time, so your team doesn't have to deal with the afternoon context switching.

Companies that set this little time aside tend to use it for short, hastily prepared presentations about new tools/techniques that someone has recently been learning about. Such presentations can be hard to glean and/or retain value from. This model also encourages breadth over depth--possibly to a fault.

Investment time is an ideal context for pair programming.

Regardless of whether your team pair programs regularly during billable time or not, consider defaulting to pairing during investment.

This is especially useful as a mentorship model, where one developer is paired with a more senior developer. Often, even for teams that aspire to pair regularly, this model can be a hard sell during billable work time. But during investment, the short term loss in speed is more palatable.

It can be particularly effective for the more senior developer to "pilot", while the more junior developer actively observes and participates by seeking an understanding of the senior's approach. Senior developers often don't realize how much they actually know. Some of their best habits are only revealed when a less senior person who's watching them stops them and asks, "Whoa--why/how did you do that?".

Prioritize depth over breadth.

Developers don't seem to need any help broadening their awareness of the tech ecosystem. Twitter, Hacker News, podcasts, and other media fling new topics at us constantly.

Depth, however, can be elusive.

As an experiment, ask the senior devs on your team how they got to be seniors. If they have some vital skill or knowledge, ask how they acquired it. I've found that a lot of senior developers were the only developer--or one of a small few--on their previous team. They gained senior-level skills by having no choice but to slowly deepen their knowledge as their product's complexity grew. Their crucial strategy was probably not building a toy app for each new JavaScript framework they were curious about. (They may well have done that, but so have lots of developers stuck at junior/mid levels.)

In an ideal workplace, billable time might be perfectly balanced to include mid-level devs in higher-level decisions and tasks, so they grow into seniors. In practice, this is rarer than it ought to be.

Begin a long-running project.

Using investment time for tech talks or learning new technologies by building toy apps wastes a precious opportunity to level up your developers. Instead of encouraging your team to learn new technologies, begin a long-running project. Whether it's an internal tool or public-facing, build its spec based on customer input and plan to deploy it as you would for any other product.

Be ambitious. Intend for the product to demand solutions to complex problems, and expect the project to take months--not weeks. In the beginning, there might be very few challenges with a product of this nature. But over time, maintaining the product will create opportunities for learning that are almost impossible to find elsewhere. And since the product is meant as a side project, your less senior devs can deepen their skills slowly without feeling the pressure of an aggressive timeline.

Watch for pain points.

As work continues on this new side-project, observe what people are asking and complaining about. If a new contributor is trying to get the app running locally but can't find setup documentation, there's a good chance your team's culture of documentation needs improvement. If tests/builds/deploys aren't streamlined, that's another part of your team's culture that you've learned about.

Failure to properly operationalize a low-stakes project may be a sign that your team's core operations need some love. Expect investment time to surface inefficiencies and insecurities. There is a lot to learn from observing dysfunction.

Properly implemented, investment time can dramatically boost your team's culture of organic skill growth. Just be watchful that some members' needs aren't slipping through the cracks and that you're taking advantage of more than just the obvious opportunities for value.