(Having been that dev, wrong! Don't got it. Which is why, as manager...)
Mgr: "I need you to plan travel to LA. For the six of us. Planning to leave tomorrow before lunch. What questions do you have?"
Dev: "Do we have a budget or cost restriction? Is there a time we need to be in LA?"
Mgr: "Let me double-check the budget and get back to you in a few minutes. We're supposed to be in LA by 6PM tomorrow."
(Other good what-if scenarios could include that meeting the travelers are supposed to be in all afternoon tomorrow, whether everyone needs to travel together, where the group is leaving from, if the Dev should book travel or just send a plan, ...)
All of those things help shape the approach, the details, the implementation.
Because, without clarity, some manager who's not an expert and hasn't asked the right questions will say "yeah, sure, we can use the plaintext credential store Bobby threw together, it's fine, get it done fast".
When the manager is invested in creating clarity for the team (which is not the same as barking out orders or trying to "get the 'throw' done as quickly as possible), they'll take the up-front time. And when Bobby says "hey, look, plaintext credential store!", the manager can point back to the approach the team put together (e.g., salted, hashed, ever stored/logged in plaintext, etc).
Reading between the lines, it sounds like you've seen some pretty bad management, probably with a lot of short-term thinking and disrespect for "inferiors". That sucks. I've had some terrible managers too, along exactly those same lines. But I've also had some pretty good managers too. I've found that a lot of managers are terrible because they don't know better. They don't know how to support a team, or how to be clear, or how to listen. And a lot will make improvements when given some help.
> What I dislike about the original post is that he seems to think his job is to lead and have them follow.
Can you help me understand what in the original post came across that way?
Sure, managers do have a responsibility to lead their team, and they're held responsible for the results their organization team produces. That's the job. It'll look different company by company, of course. But I definitely didn't have some kind of command-and-control management approach in mind.
> It isn't. His job is to support, to do the things, manage the interactions, that are preventing the team from working effectively.
I agree! Like I wrote toward the end of the post, "The real secret of managing an expert team when you can’t do their jobs is to give up the illusion that you have to be superpowered and all-knowing. Instead, you can be the manager, supporting and directing your team, making sure you deliver results through your team."
That sounds—to me, and I might be missing something—pretty similar to what you're advocating.
The overall tone is one of "father knows best" with plenty of adversarial over and undertones. My favourite example, and perhaps the clearest, is
"For example, if you just asked them to change the text on the “Login” button, and they’re talking about new libraries and rewriting the credential store, there’s a good chance your team didn’t understand what you told them."
There is an equal or better chance that you don't understand or are completely ignorant of dependencies with which they are intimately familiar, perhaps tangled copypasta created ad nauseam in response to overbearing leaders who could not be bothered to understand.
I've seen that more than once.
In that specific instance, it would be more helpful to dive into the why while expressing the surprise you actually feel. It might even be better to go straight to "is there something in there that shouldn't be?"
If your team has history you lack, one of your first jobs is learning the pain points and gaining enough of their trust that they will show you the scars and explain how they were earned.
I've certainly been misunderstood more than once. I've also misunderstood people who thought they were being perfectly clear.
That particular example is intended to be an example of a well-intentioned manager sending a message but it not being received. Maybe it's time pressure, or an interruption, or just bad wording. "Y'all, we need to change 'Login' ...oh, hang on, I need to take this call."
The next paragraph is an example of exactly what you're talking about—where the team shares information with the manager, the manager learns something about the system, and it leads to improved trust between team and manager.
I think you're taking "there's a good chance your team didn't understand what you told them" to mean "your team is so dumb they don't understand basic words and you need to correct them". It's meant as a value-neutral description of something that's really common in human interactions: someone tries to communicate X, but what's received is different than X. In this case, that's on the manager to fix.
So...how could I edit that paragraph so it comes across better, without trying to incorporate some of the things that came before (admit you're not the expert, ask questions, etc)?
I could make it even more ridiculous:
> For example, if you just asked them to change the text on the "Login" button, and they're talking about how that means upgrading the load balancer and switching to a NoSQL database, there's a good chance your team didn't understand what you told them.
I could try to make the error attribution more obvious:
> For example, if you just asked them to change the text on the "Login" button, and they're talking about new libraries and rewriting the credential store, there's a good chance you didn't communicate what you thought you did.
I could add some corrective actions later on:
> For example, if you just asked them to change the text on the "Login" button, and they're talking about new libraries and rewriting the credential store, there's a good chance your team didn't understand what you told them. Take the time to make sure they understood correctly. If they did, you've got something to learn.
I think you're railing against the exact sort of thing I'm working to fix here: people who think their title means they don't have to listen to their team, or that they're automatically an expert because of their title, or something. So your input on how to make it land with you (because it obviously didn't as originally written) would be helpful.
Author here. Yes, if you don't know the domain, you should have a really good reason for overriding the team.
Asking questions is a way to gather information that you can then share back with the team. If I were new to a team and had a situation like what you describe, I might go back to my team: "Hey all, I was talking with Professor SmartyPants about $PROBLEM and they suggested $APPROACH. It sounded plausible to me, but y'all are the experts here. Is $APPROACH something we've thought about, and can you help me understand the pros and cons?"
The discussion that follows would help me figure out how good folks on my own team are: who considers the idea, who can explain why it's good or bad, who gets huffy when new ideas are brought.
So yes, 100%, be careful with thinking "I asked questions of a lot of people" means "now I'm an expert that should override what my team is telling me"!
Location: Iowa, USA
Remote: Yes
Willing to relocate: No (\* yes for amazing opportunity)
Technologies: C#, TypeScript/JS, Python, Ruby, Azure, relational and document DBs, DevOps,...
Resume/CV: 20+ years engineering, 8+ of those in management roles. Contact for resume.
Email: matt.schouten@gmail.com
Hi! I'm Matt. Good at leading teams, good at hands-on problem solving. I don't particularly care about the title. Looking for a technical leadership role (e.g., Director/Sr Mgr Engineering, or Senior/Staff Engineer, depending on whether it's management or hands-on).
I'd also be interested in (and good at) fractional / consulting work or team coaching.
I do my best work as a strong #2, supporting a leader that values ideas and feedback, whether in a management or IC role. (Working Geniuses: invention and enablement. Working Frustrations: galvanizing and tenacity)
Location: Iowa, USA
Remote: Yes
Willing to relocate: No (\* yes for amazing opportunity)
Technologies: C#, TypeScript/JS, Python, Ruby, Azure, relational and document DBs, DevOps,...
Resume/CV: 20+ years engineering, 8+ of those in management roles. Contact for resume.
Email: matt.schouten@gmail.com
I’m a full-stack developer with a preference for backend. Over the past 20+ years, I’ve worked in everything from avionics to WordPress to heavy GIS data processing. I love solving complex problems (make them as simple as possible, but no simpler), designing for scalability and sustainability, and mentoring engineers.
I’m a builder and coach at heart, and will happily build software, do product development, architect systems, or step into a leadership / management role. That said, you don’t want me to be your interface designer, but I can implement someone else’s design just fine.
It seems I do my best work as a strong #2, supporting a leader that values ideas and feedback, whether in a management or IC role. (Working Geniuses: invention and enablement. Working Frustrations: galvanizing and tenacity)
Location: Iowa, USA
Remote: Yes
Willing to relocate: No (\* yes for amazing opportunity)
Technologies: C#, TypeScript/JS, Python, Ruby, Azure, relational and document DBs, DevOps,...
Resume/CV: 20+ years engineering, 8+ of those in management roles. Contact for resume.
Email: matt.schouten@gmail.com
###
Hi! I'm Matt. Good at leading teams, good at hands-on problem solving. I don't particularly care about the title. Looking for a technical leadership role (e.g., Director/Sr Mgr Engineering, or Senior/Staff Engineer, depending on whether it's management or hands-on).
I'd also be interested in (and good at) fractional / consulting work or team coaching.
I will add a third claim against it: all that black and gold. As an Iowa State grad, there's a certain arrogance that the University of Iowa undergrads give off (grad students and faculty seem to be fine). [For those not from 'round here, U of Iowa and Iowa State are the two largest universities in the state. There's a healthy—and occasionally unhealthy—rivalry.]
That said, I do actually really like the town itself. Like you said, active, friendly, with a real vibrancy to it. I don't get there often (strange, since Cedar Rapids is not that far away), but enjoy it when I'm there.
Location: Cedar Rapids, IA
Remote: Yes, preferred
Willing to relocate: Only for an exceptional opportunity
Technologies: C#, Javascript, Python, SQL, Docker, CI/CD pipelines, Azure, testing, the written word, and many others
Résumé/CV: upon request; LinkedIn: https://www.linkedin.com/in/matt-schouten-3b544b7/
Email: matt.schouten@gmail.com
I’m a full-stack developer with a preference for backend. Over the past 20+ years, I’ve worked in everything from avionics to WordPress to heavy GIS data processing. I love solving complex problems (make them as simple as possible, but no simpler), designing for scalability and sustainability, and mentoring engineers.
I’m a builder and coach at heart, and will happily build software, do product development, architect systems, or step into a leadership / management role. That said, you don’t want me to be your interface designer, but I can implement someone else’s design just fine.
It seems I do my best work as a strong #2, supporting a leader that values ideas and feedback, whether in a management or IC role. (Working Geniuses: invention and enablement. Working Frustrations: galvanizing and tenacity)
[Also available for manager / leader / developer coaching.]
Dev: "Cool, got it."
(Having been that dev, wrong! Don't got it. Which is why, as manager...)
Mgr: "I need you to plan travel to LA. For the six of us. Planning to leave tomorrow before lunch. What questions do you have?"
Dev: "Do we have a budget or cost restriction? Is there a time we need to be in LA?"
Mgr: "Let me double-check the budget and get back to you in a few minutes. We're supposed to be in LA by 6PM tomorrow."
(Other good what-if scenarios could include that meeting the travelers are supposed to be in all afternoon tomorrow, whether everyone needs to travel together, where the group is leaving from, if the Dev should book travel or just send a plan, ...)
All of those things help shape the approach, the details, the implementation.
Because, without clarity, some manager who's not an expert and hasn't asked the right questions will say "yeah, sure, we can use the plaintext credential store Bobby threw together, it's fine, get it done fast".
When the manager is invested in creating clarity for the team (which is not the same as barking out orders or trying to "get the 'throw' done as quickly as possible), they'll take the up-front time. And when Bobby says "hey, look, plaintext credential store!", the manager can point back to the approach the team put together (e.g., salted, hashed, ever stored/logged in plaintext, etc).
Reading between the lines, it sounds like you've seen some pretty bad management, probably with a lot of short-term thinking and disrespect for "inferiors". That sucks. I've had some terrible managers too, along exactly those same lines. But I've also had some pretty good managers too. I've found that a lot of managers are terrible because they don't know better. They don't know how to support a team, or how to be clear, or how to listen. And a lot will make improvements when given some help.
reply