Pete Soderling Pete Soderling on

Dmitry Storcheus is an Engineer at Google Research NY, where he does scientific work on novel machine learning algorithms. Dmitry has a Masters of Science in Mathematics from the Courant Institute and despite his very young age he is already an internationally recognized scientist in his field of expertise.  He has published in a top peer-reviewed machine learning journal JMLR and spoken at an international conference NIPS. Dmitry Storcheus got peer recognition for his foundational research contribution published in his paper “Foundations of Coupled Nonlinear Dimensionality Reduction”, which has been cited by scientists and engineers. He is a full member of reputable international academic associations: Sigma Xi, New York Academy of Sciences and American Mathematical Society. This year Dmitry is also a primary chair of the NIPS workshop “Feature Extraction: Modern Questions and Challenges”.

Continue
Unknown author on

Earlier this year, we launched a series that profiles our hardworking iHeartRadio engineering and product team. Today, we’re excited to chat with Senior Mobile Developer Hua Wang!


Before joining iHeart, Hua worked on mobile products at Pearson, Barclays, and Apptricity, among others. With a broad range of expertise, Hua has developed mobile technologies from robots to phones. She believes that mobile is impacting our lives like never before, with incredible potential for continued future disruption.



Why did you choose to become an engineer?

Simple: I love problem-solving, and being able to solve challenging problems is critical to being a good engineer. My approach looks something like this:

Continue
Eric Bogs Eric Bogs on

While I like to think that all of us at Hinge are perfectly aligned towards the same goals, in reality if you take a mindreading machine and eavesdrop on the internal monologues of my team members, you might overhear some... misalignment:


  • "Oh please for the love of god not another meeting, just leave me alone so I can finish building this feature" -Engineer

  • "We really need to have another meeting to sync on what's left to build this feature" -Engineering manager


and

  • "We're not moving fast enough, we need to focus more on speed so we can get this out to our users" -Product manager

  • "We're moving too fast, we need to focus more on quality, let me add some more tests" -Engineer


and

  • "This open plan space is awesome! I can talk with my team all day!" -Engineer A

  • "I can't get any work done because my team won’t stop talking about obscure movie references!" -Engineer B


You can boil each of these issues down to their emotional core: different team members’ needs cause friction and frustration. Together, these issues were compounding to a larger sense of negativity and lack of momentum. Deadlines were slipping, tempers were flaring, engineers were losing sleep and pulling their hair out, and some were resorting to elaborate dance-offs/arm wrestling/fisticuffs in the office to resolve disagreements.

I've seen versions of these misalignments on nearly every engineering team I've been part of. As an engineering leader, my job is to serve my team and help make them as effective as possible.

#shine-a-light


As I saw these misalignments emerge at Hinge, my first instinct was to act decisively and fix with some heavy-handed top-down management. The team doesn't like long meetings?  I’ll institute shorter meetings. Our product team wants to move faster?  I'll develop a project plan myself in a backroom. The open plan space isn't working?  I'll buy everyone noise-cancelling headphones.

The fallacy with these top-down approaches, are that they make the assumption that I am smarter than my collective team, which is definitely not the case.

Instead, what I've been doing with my team at Hinge is little more than shining a light on these misalignments, and creating safe spaces to discuss the problems and possible solutions. My team are humble, invested, and positive, so all it takes is a bit of focus on a problem for a solution to emerge. We let process be implemented by those who practice it, rather than coming from top-down.

Whereas in 2009 you might have a “quick meeting” to discuss a problem (aka “let’s take this offline”), and in 2012 you might have created a “short Google Doc” to discuss and define a policy, in 2015 we have the glorious utility of Slack.

#slack-attack


Slack allows us to quickly and easily spin up and segment discussions, invite the right people to the discussion, and lazily contribute based on our own urgency and workloads.

Some example Slack channels:


  • #ios-style-and-syntax: We expanded from 1 iOS engineer to 4 in a very short amount of time. Code reviews were derailing into larger disagreements over style (“doc notation instead of bracket notation!!!!!11”). Our iOS engineer Steve noticed this, and proposed separating style discussions out of code reviews, into a Slack channel.

  • #android-release-process (when to branch, when to create builds, when to merge back to master, where to upload builds). After gathering feedback from his peers, our Android engineer Jason took the lead on Google Doc, and once all comments and concerns were hammered it out, it then it became doctrine.

  • #office-space: Not a discussion of the hit 1999 Mike Judge film, but rather a discussion of how a growing startup can settle into its office space. After acknowledging that we’re a team of talkers, we established a "Library" in the office which is a quiet area with no-talking allowed.

  • #meetings-suck: Managers need meetings, but makers need time. This Slack channel acknowledged this tension, and resulted in the team coming up with a policy of encouraging folks to walk out of low-value meetings. In addition, we came up with the idea of setting aside Tuesdays and Thursdays as "meeting free" for engineers.

  • #moving-fast: The tension between "moving fast" and "writing perfect code" can not be resolved, and instead it should be acknowledged and celebrated. We have decided, as a fast-paced startup, we actually need this tension. We now celebrate it, and can speak openly about the tradeoffs.


#tips-and-tricks


It’s easy for anyone on the team to shine a light on problems we’re facing by spinning up a Slack channel. When spinning up a Slack channel, I usually seed the conversation with some fact-finding. The first topics to discuss in a “problem solving” Slack channel:

  • clarification of the problem (put in the “Purpose” field for the new channel in Slack)

  • how big is the problem?

  • who's feeling it?

  • is this a problem with process, culture, tech, or something else?

  • what best practices, experiences or learnings can we bring in?


To keep your Slack taut, don’t be afraid to carve out a new Slack channel when conversations expand, fork, drift, or fizzle.

I’d love to hear how your team is using Slack!

Continue
Pete Soderling Pete Soderling on

Announcer: Okay, so our next speaker is Pete Soderling. He is the founder of G33kTalk, which is—I don’t know, I guess, I think it’s going to be like a multimedia empire in a little bit, but he has a really good mailing list that sends out some really interesting articles, mostly technology  articles, a little bit on technical leadership, as well. I’m not sure how he does it, like he operates both in New York and San Francisco. He actually records meetups, and so he puts some of the videos up on his website, as well. And so, he’s certainly somebody that’s very much embedded in the community. He gave the—well, a longer version of this talk at QCon, because recruiting is also something that he is good at in addition to multimedia and stuff. So, without further ado.

Continue
Gregg Pollack Gregg Pollack on

"12 Steps to being a Better Programmer" by Gregg Pollack from Code School gives a talk on the lessons they don't teach in programming class. Gregg talks on setting expectations, getting outside of your comfort zone, moving from independence to interdependence and understanding software development as a craft. Using examples from his own experiences at his company Envy Labs,  Gregg goes through these 12 steps very concisely sharing many anecdotes that offer great perspective. This talk was recorded at the Code Crew meetup at Alley NYC

Continue
Pete Soderling Pete Soderling on

Lately, I've been advising numerous software developers and helping them consider appropriate next steps in their careers. Based on the current tech bubble I believe we're in, I'm finding that many engineers are thinking about leaving more established companies and considering venturing out to either: a. work at startups, or b. work on their own startup.

During my own career, I've been fortunate to have found myself in engineering roles at both larger companies as well as startups. Regardless of which path you personally choose, there are some basic skills that every engineer must acquire if they desire to put themselves on the path of engineering leadership (CTO, VP/Dir of Engineering, Engineering Manager, etc.). Of course, not every engineer wants a leadership role, and that's ok, too.

If you're the type of engineer that knows (or thinks) you want to move into a leadership role you can do it either at an established company or at a startup. And the truth is it can happen quite quickly in either scenario if you focus on learning and exhibit the right skills for the job.

This post is an intro to a roundup of articles that we're preparing to publish full of advice given by engineering leaders that we highly respect. They've agreed to share their wisdom with the Hakka Labs community and I'm thrilled that so many super-smart engineering managers have agreed to participate. 

But first, I'd like throw some of my own ideas at you. Some of this advice is based on my experience in both working on development teams as well as having been in a founding role at several tech startups. But some of it is simply opinion so feel free to take it or leave it, as I hope you would with any free advice.

Without further ado, here a couple of key thoughts I think every engineer desiring a leadership role should consider.

 

Decide if you really want to be a manager


You might think this step goes without saying, but I believe this is the very first step that any engineer needs to be clear about. The truth is, some engineers think they want to be managers since that's the only way they believe they can advance in their careers (it's not) and yet they never really come to grips with whether or not they really want to be a manager, or learn the skills required to do it.

I've spoke to many engineers that take management positions, only to discover that there's too much non-technical, process oriented "stuff" that they need to do all the time, and they end up not taking to their new role.

Sometimes these engineers leave the management world for good and never look back. Other times they temporarily go back to the trenches - realizing that they're happier writing code for a few more years - and then pursue management opportunities later in their career once they know it's something they want and are now ready for.

Either way, be sure you have the interest in learning management skills. Managing people isn't like managing servers. If you want to know how they're different from a practical perspective, kick off your learning by asking your current manager about his/her experiences in managing tech teams in general, not to mention his/her experience in managing you!

 

Prepare for team building now


People who are far wiser than I have made the observation that management (tech or otherwise) involves three things: planning, hiring and retaining the right team, and dealing with emergencies (which is, in reality, the result of a broken plan).

By that standard, half of any serious leadership role is likely to be made of team building/retention issues - that means people management!

If you want to find yourself in a position of leadership, start working on your people skills now. Especially the ones that directly relate to team building and hiring.

If you were the manager of your own team right now, and you needed to fill an open position, where would you start?

How do you define the role? What's the ideal profile of the person you'd most like to find to fill the role? What are the essential skills required? What skills are non-essential? (Then ask yourself again: what skills are really essential? It might seem self-evident, but often one still needs to be reminded of the simple truth - the more essential skills you require, the longer it's going to take to find the right candidate.)

How do you attract the best candidates? Where do you find them in the first place to attract them? How do you pitch them on your team? Why is your team, and, therefore, this role, essential as it relates to the business objectives of the company? What technical challenges do you have waiting for the new hire? Do they get to chose database technology or a Javascript framework? Do they get to have any input on key technical decisions?

How are you going to get them excited about joining your team now?

The implications of attracting, hiring and on-boarding the right person for an open technical role are staggering. When you find them things are awesome. But if you can't find them and the vacancy goes unfilled you really start to feel screwed in a hurry.

The most important thing an engineer in leadership can do in order to attract the best people to their team is to learn to tell a story that will be completely compelling to an engineer you're trying to recruit. And you can practice doing that now, whether you're actually in a position to hire or not.

 

Conclusion


Whether you're working as part of a larger organization or at a startup, these are some key things you'll want to consider as you prepare for engineering management. Stay tuned for additional articles in this series as other engineering managers share their wisdom on how you can prepare yourself for engineering leadership.

Continue