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!
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
Happy hours were important bonding experiences for camaraderie at my last startup.
Now that everyoneâs remote, what will be the new happy hour??
Hi Rick,
Whatâs the movie quote that you secretly feel you overuse but no one notices?
How did you handle the transition from coding (almost) every day to managing a team of coders?
So uhhh Rick, what are some of your most favorite (and used) movies quotes?
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.
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
is what helps me keep my focus.
Hello lewis
- 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.
hahaha
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 
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.
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 
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.
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
)
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 