AMA on Engineering Management by Rick Newman [27th May 2PM - 5PM PT]

Hi Rick. How are the major benefits of having cross-functional teams instead of siloed teams per functionality, component or classic developement, operation and testing

THANKS!

Are there some base heuristics for making choices in efficiencies in consolidating a legacy tech stack to a modern framework and parity versus continuing to support the legacy techstack and evolve through the idiosyncrasies of the each language’s update schedule?

What is the last major change in software engineering (practices, tool, anything…) you were most excited about – and what do you think most needs to change in the future?

Hiya hope you and your family are all safe and sound.

Do you have some advice or insights for someone who’s not really interested in management, and enjoys taking a more hands-on development approach, but keeps hearing that with age the hiring opportunities for developers will decrease?

When handling many projects at once, how do you learn enough to make good decisions, while not wasting time getting lost in the weeds of each project?

Hey Rick?

I am graduating in Agust in IT and Administration management. My question is I would like to know what are the best advice for me if I was to get a job as an entry level Project manager at Microsoft. What should I expect?
I was a supervisor at a hospital and I own a small software development business that’s the closest thing to management I have on my resume.

Hey Rick,
What certifications do you recommend getting for your field?

Hi Rick,

I’ve tried hard to cultivate a culture of mutual trust wherever I go, as you describe, with mixed success. How would you foster and grow trust on a 100% remote team? What sort of techniques or tools would you recommend for facilitating such an environment? And what are some of the “trust killers” that I should avoid at all costs?

Many thanks in advance!
Austin

3 Likes

Happy hours were important bonding experiences for camaraderie at my last startup.

Now that everyone’s remote, what will be the new happy hour??

1 Like

Hi Rick,

What’s the movie quote that you secretly feel you overuse but no one notices?

2 Likes

How did you handle the transition from coding (almost) every day to managing a team of coders?

2 Likes

So uhhh Rick, what are some of your most favorite (and used) movies quotes?

1 Like

hey! have you see any rise in decentralized applications or functionality with the heroku ecosystem? this one looks interesting

Since this is the first question I am answering it seems the right place to put down what I mean by vulnerability before I propose an answer.

What I DON’T mean is an inappropriate level of self-revelation. What is the right level? That’s hard to quantify but I use a rule of thumb that my own vulnerability should create a safer space through modeling behavior and NOT a more uncomfortable one. That will obviously be different dependent on the person, the team, and the existing relationships.

Why does this matter with engineering teams? Because engineering teams are people teams and people work together better when there is some trust between them.

Take for example a long-running PR comment thread on a new interface. Engineers are passionate about the right solution and that can come through in commentary. With some element of pre-existing trust, I can take the comment “This relies on account_link_id existing which isn’t guaranteed and you’re not looking for any errors in that case. Similar to previous bug #12345 that you had to fix” as well-meaning and informative.

But that last sentence could be taken as either a jab at creating a similar bug or a helpful reminder of a solution. I think building trust through vulnerability will save me a lot of cycles (internal head-space or in the thread) AND create an environment where more critical comments aren’t kept to oneself…ultimately hurting the team’s effectiveness and limiting my own ability to learn.

3 Likes

Hi daniel-murphy!

This is highly dependent on the culture at work and the specific role of the manager, but I will assume you mean a manager that is not ‘supposed’ to be spending part of her time implementing a feature.

It can be difficult to manage a team of people responsible for things that you have been responsible for in the past. Whether it be engineering or project management or teaching a class, the answer is the same. The role of manager is two-fold: help the individuals on your team grow in their career and help the team as a whole be more effective (in that order).

Diving into specific problems does neither of those things. It takes an opportunity away from an engineer that might not have had that domain experience yet (limiting their growth) and it contributes nothing to the effectiveness of the team. It MIGHT increase your team’s velocity - but your goal isn’t a higher velocity, it’s a team that is capable of one.

Keeping these two goals in mind (which is difficult :slight_smile: is what helps me keep my focus.

2 Likes

Hello lewis :slight_smile: - that my teammates don’t know yet?? Hmmm…

He has a certain way of looking at me that says, I can’t see out the window, please open the blinds. And there is no confusing that look with another.

1 Like

hahaha

1 Like

You’ve struck a bit of a nerve with that question! The books Peopleware (1987), Toyota Production System (1988), Practice of Management (1954) and writings from W. Edwards Deming and Eric Trist were all published before I got out of high school but still immediately relevant in regards to how we treat people, how we align processes and goals, and how fragmented work affects both the people and the end product.

On my more cynical days I wonder why we are still struggling :slight_smile:

Usually my more reasonable side wins out: we are each human and that means we each bring ego, personality, and some baggage to our work. And that makes work messy as we all bump into one another trying to get stuff done.

Despite my cynical days - I do see team management evolving as we take the idea of teams being ‘teams of humans’ more seriously by upper levels of leadership. Vocabulary has sprung up around teams that include more than ‘throughput’, ‘velocity’, and ‘code churn’ (focusing on output and efficiency) and consider ‘engagement’, ‘autonomy’, and ‘trust’ as equal considerations.

It’s slower than ideal - maybe because each of us feels so confident that certain things can only be done a certain way (our favorite way) ? - but there is a lot of positive progress with integrating emotional intelligence, addressing diversity, and recognizing the benefits of not multi-tasking.

I think we will continue to see that trend (of looking at personal interactions at work) becoming more and more ingrained into our understanding of how work gets done.

Anecdotally, I have more and more been able to bring those topics to executives (and have them acted on) as the years have progressed. Though obviously that is only in my tiny little corner of engineering experience.

1 Like

I’m excited to be here - it’s my first experience with one of these (on this side) and I’m oddly a bit nervous.

I’m so excited about this question in particular that I’m going to cheat and answer twice :slight_smile:

In the movie Shooter (with Mark Wahlberg), when he is teaching someone how to shoot he says ‘Slow is smooth and smooth is fast’ that I find again and again a relevant reminder. So much stuff is thrown at us in engineering that we sometimes feel like moving fast is the only real measure of productivity.

I don’t always heed the reminder of course - but it helps me remember that understanding How we do work is critical and that running from fire to fire does a long-term disservice to the team and to the product - and therefore to the customer.

And another one!

In the movie Hoosiers (with Gene Hackman as coach), he says ‘My team is on the floor’. The context is that he only has 6 (basketball) players, one of whom he benched because the player refused to pass. When someone else fouls out, the benched player starts to get up and the coach tells him no. Ref comes up to tell him he’s only got 4 players out there and that quote is the response: My team is on the floor.

The coach wasn’t being an ass, or stubborn, or taking revenge. He was making the point that building a healthy team is more important than winning a single game. I think that paints a perfect picture of engineering management. As mentioned in a previous response, my job is not a higher number under ‘Velocity’ in a report. My job is to help a team grow and learn to be a team…the numbers will take care of themselves when that happens.

2 Likes

I think my transition was easier than most as I first slid into a scrum master type role that I performed alongside my duties as an engineer. It helped me move my focus from the specific tasks at hand to thinking more about why the tasks themselves moved across the board the way they did (some very quickly, others very slowly, some moved backwards :slight_smile: )

My mindset at the time was that this was just a new problem-space and that it was just as interesting as Java…I think that part (first looking at process as scrum master) made it less difficult than just being dropped right into people management.

Some of my peers at the time might say that I was the kind of engineer that really should be promoted somewhere where I wasn’t allowed to touch the codebase anymore…but I prefer my first answer :slight_smile:

2 Likes