From Building Things to Building Teams
In the first two parts of this series, I talked about going from building houses to becoming a Web Developer and about spending more than 27 years adapting as technology continually changed.
But there's another change that happened along the way.
My definition of what it means to build something changed.
Early in my career, much of my value came from what I could personally do.
Could I write the code?
Could I troubleshoot the problem?
Could I configure the system?
Could I figure out why something wasn't working and fix it?
Those skills mattered, and that experience still matters today.
But somewhere along the journey, I realized my greatest contribution wasn't necessarily going to come from personally doing every technical task.
It was going to come from helping other people succeed at doing them.
That's a very different skill.
If I'm leading developers, I want developers who are better developers than I am.
If I'm working with database professionals, I want people who understand databases more deeply than I do.
I want infrastructure and security people who will challenge my assumptions. I want product people who understand the customer. I want people earlier in their careers bringing new ideas, new technologies, and different ways of thinking to the table.
I don't need to be the smartest person in the room.
I need to help create a room where smart people can succeed together.
That means providing direction without trying to control every decision.
It means asking questions.
It means removing obstacles.
It means recognizing when someone needs help and when they need room to figure something out themselves.
It means allowing people to challenge you.
And sometimes it means letting someone make a mistake, helping them understand what happened, and giving them another opportunity.
This is also where I've learned that product management and people management are very different things.
Product management asks: What should we build? Who are we building it for? What problem are we solving? Why does it matter?
People management asks: Does the team understand where we're going? Do they have what they need to succeed? Are we developing people or simply assigning them work? Are we creating future leaders?
Both matter.
And when you're leading technology organizations, eventually those worlds meet.
Sometimes you're creating a new product.
Sometimes you're fixing one that isn't working.
Sometimes you're modernizing something that has served the business well for years but needs to evolve.
And sometimes you're evaluating something completely new, like AI, and trying to determine where it genuinely belongs.
My job today isn't necessarily to personally write every line of code, configure every server, or know every command.
There are talented people who can do those things far better than I can.
My job is to bring those people together and help point them toward the goal.
When I think back to where this journey started, there's something almost fitting about it.
I started out building houses.
Then I learned how to build technology.
Eventually, I learned how to build products.
And somewhere along the way, I learned that one of the most rewarding things you can build is a successful team.
The tools have certainly changed over 27+ years.
I'm sure they'll change many more times before I'm finished.
That's okay.
I'm still learning.
I'm still adapting.
And I'm still interested in figuring out what we can build next.
Thanks,
Michael Cronin
Website: https://www.michaelcronin.info
LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/
