I'll name the best manager I ever had, since she unexpectedly passed away nearly three years ago to our team's (and company's) great sadness. Margaret Thielemann was a QA manager for nearly 10 years at Esri (she previously headed up QA at PeopleSoft before its acquisition by Oracle), and I reported to her for all of those 10 years, during which I learned and mastered web development by scoping, designing, and building several internal web apps. She hired me as a kid with little corporate experience, straight out of college, and took me "under her wing" and patiently taught me the ropes of thriving in a corporate environment.
Margaret had all the hallmarks of an incredibly great manager. She hired for potential (not past achievement) and gave employees every opportunity to grow and pursue our passion as developers. This allowed me to pivot and grow into web development, which was not in my job description or past experience. She never micromanaged, even when a deadline was approaching. She never demoed a project or took credit for something she didn't build herself. Like my teammates, I had to demo every product I built -- which was challenging but forced me to grow in public speaking skills (and she coached me the first few times). This also allowed me and other team members to gain recognition throughout the department.
She very effectively protected us from HR and whoever else wasn't on the team so we could focus on our work. A few times someone tried to ask us for help with someone else's project without asking her first--she was furious. She also fought (very effectively) with HR and management to get us raises that better reflected our increasing market value.
I owe my career and present livelihood largely to Margaret and the opportunities she provided me. I'd be remiss not to acknowledge God's obvious provision to me in her. Thanks so much Margaret, and thank you Lord.
Most of what you say are qualities I like managers to have too, but 'someone tried to ask us for help with someone else's project without asking her first--she was furious.' is a quality I do not value. I mean, protecting your people is one thing (an essential quality), but being furious because someone in need of help asked in the wrong order doesn't foster cooperation beyond the borders of the own team (causing silo mentality).
I don't know the companies culture and the people who asked for help, so maybe it was a good reaction at the time, but in general, I would advise being cooperative towards other departments.
I've seen this go both ways. It depends on how funtional/dysfunctional other parts of the organisation are. If they're as competent as you and just asking for things they genuinely need, cooperation is great. If they're not, they turn into "help vampires" and you have to put up a firewall to prevent them destroying your productivity.
I think my current workplace suffers from too much team defensiveness + not having a CTO or equivalent to integrate across teams.
It also depends on you (and others in similar roles) having a reasonably well-tuned sense of what is reasonable and what is not. I have a fairly broad charter myself but I help out all the time with things that I could argue are "not my job" as narrowly defined. However, they're mostly at least adjacent to my primary responsibilities and are mostly not a big deal to do.
Were someone to come to me with a request that looked to have the potential to be a big time sink--or if I was getting overloaded with too many one-offs--I would definitely have a discussion with my manager at that point.
Yeah, what's the point of having Microsoft Lync or whatever chat thing on every computer if I have to escalate up to our common report? A place I worked at, the investors had bought two different American companies and joined them at the top. So, when I needed a service I was supposed to consume to fix something (pretty obvious if I remember), the person at my level and his manager didn't respond to me or my manager at all. My manager said he had to escalate it like three levels above him and turns out the engineer simply forwarded my messages and emails to his boss, who did the same to his boss, who was on vacation. Took almost a week to resolve something so simple.
It was just outright bizarre that someone would not even write one line back to say "dude, hold on. I can't do anything without my manager's sign off". Like anyone not in their immediate team was an outsider they wouldn't talk to.
I think a lot hinges on whether it's truly asking for help vs. telling you you need to do something, and possibly phrasing it as a question. Depending on how the organization is set up and the seniority of the person asking, it can be very hard for a low-level employee to say "No, I don't have time to do that."
Having multiple people that can give you contradictory orders about how to spend your time makes for a miserable job experience. You either work overtime to meet both sets of demands, or you get negative feedback from one of your "bosses" for not completing their tasks. It's the manager's job to prevent this, and it's important that they do so.
The correct response would be along the lines: 'Sorry, but you have to ask my boss if we can push it to the top of our task list as she has the overview over the priority queue'.
That is different than a 'No, I don't have time for that.', as it teaches how to do it right in the future, and your boss doesn't have to get furious because everything that happened was that the team informed the org about the regular process.
I have worked enough time in the midst of a QA team to know that planning is essential to their job. Nevertheless, a team lead which is going to be furious because you didn't use the correct process isn't someone you want to ask for help. So, in the long run, it might cause more problems than it solves.
That assumes that your manager has a reasonable process for prioritizing these kinds of requests, which is often half the battle. It also requires a manager that will go to bat for you and defend that process, even when the requester says "This is critical and time-sensitive, I don't have time for that, so can you just do it?"
It’s very context sensitive. QA usually needs someone strong to protect the team, as they’re the ones who most frequently get asked to make up for cost/scope/schedule/quality problems that others caused.
In other casss, being too standoffish causes local optimization (“look how efficient my team is!”) at the expense of the broader org.
> QA usually needs someone strong to protect the team, as they’re the ones who most frequently get asked to make up for cost/scope/schedule/quality problems that others caused
Bingo. That combined with the odd guy from a completely different department coming over and singling me out for help (at the time, we were the team pushing the envelope with what was possible on the web).
That being said, (a) Margaret always offered our team's help to other teams, and we frequently spent large blocks of time assisting with outside projects. But there was so much demand for us that she had to insist they go through her first; and (b) of course we could answer people's questions and assist them for a few minutes here and there. I'm talking about requests like "hey could you do this work for me", where it ends up taking several hours or more.
My point, though, was that she protected us from outside demands so we could stay really productive.
Not software, but I supervised QC inspectors at a medical manufacturer. R&D engineers would constantly try to steal their time to inspect some pre-production part, when we were trying to supply the $250k+ per day manufacturing floor with production parts that were backordered and running out on the floor (we had horrible issues with supply, but that's another story). Sure, your "brand new" part needs some pre-production inspections, but not right now since that part isn't needed for a few weeks. Once I got it into their heads that if they absolutely needed a part NOW they should come to me (so I can work it into the schedule) they always got their parts on-time from us.
I'm sure this is similar to a software workflow with QA, where every developer is vying for limited QA time, so I don't think "getting furious" is too far a step.
I'm wrapping up my first year as a manager and I have to say this is really one of the most context dependent things I have to worry about. I can definitely see a QA manager being fierce about it. I have yet to work at an organization that actually valued the QA function, at least enough to give it resources necessary to do its job properly.
> protecting your people is one thing (an essential quality), but being furious because someone in need of help asked in the wrong order doesn't foster cooperation
This depends entirely on intent, no? If they simply got it wrong, that's one thing. If they were intentionally subverting the 'chain of command', that's quite another.
I agree. Because of that, I've made it clear to my team that the immediate responsibility for out-of-the-blue requests is triage, not solutioning. There are plenty of tasks for which 15 minutes fixes the problem. There are also requests coming in that represent days of work and need to be prioritized against existing commitments. What I need is for the team to do enough to know which is which, and make me aware of the latter so that I can get that prioritization discussion moving.
She never demoed a project or took credit for something she didn't build herself. Like my teammates, I had to demo every product I built
That sounds strange. Didn't you ever work on a product with other developers? Who demos in that case?
And what would be wrong with a manager demoing a product that was built by a team he/she manages? It seems to imply that the manager should have no sense of ownership, but a good manager is absolutely crucial to the success of a project. Taken to the extreme, it would imply a CEO of a company could never demo a company product he didn't "build himself".
A good manager will know that s/he will be given credit for good work. Letting the team (especially junior members) lets them take ownership and pride in their work. And some nice words from the senior level present in the room always goes down well, which keeps the team happy.
I don't think it's a fair to compare an internal demo of a team's work to colleagues with an external demo of a company's products to journalists and the public. To take your reasoning: marketing and sales should also be done by engineers, which is not the case.
I think what the grandparent poster meant was that the manager didn’t habitually take credit whereas the developer had to learn to take credit.
Not every demo was done by the developer, but they had to learn how to present their work too. (“Had to demo every product” doesn’t mean “did every demo myself”.)
fairly common. team builds a product that other teams use, so you do a demo.
it's obviously better for the engineer to demo their own product. not only does it feel like you have control over your own product but it also gives a face to the project.
it's obviously better for the engineer to demo their own product
Again.. rarely does an engineer create a product in a vacuum. Usually a few disciplines contribute to the project, and a manager can be absolutely instrumental.
And of the various creators of a product should be candidates to demo a thing. The right person certainly depends on the nature of the product, the team dynamics, the audience of the demo, etc.
I for one wouldn't want to work somewhere with some kind of rigid "engineer X owns product Y, manager Z is just a manager" kind of culture.
> Again.. rarely does an engineer create a product in a vacuum.
That may be rare, but that’s what people on our team did... multiple times. For my own part, for each of several products, I wrote the project charter, interviewed potential users and stakeholders, created UI comps, built the app (database, server side, front-end), managed the server VMs and infrastructure, negotiated and built 3rd party integrations (when necessary), wrote the documentation, gave the demos, supported users, and released updates for years afterwards based on feedback.
It wasn’t a culture thing as much as a necessity. We were a team of 10 with 3-5 projects in development at all times, and nearly 30 in maintenance/support after several years. And that on top of normal QA activities.
In retrospect, I think Margaret intentionally had us handling such breadth individually in order to set us up for success as much as possible (several of us she had hired straight out of college). I didn’t realize it at the time, but the QA team didn’t have to do all that stuff to begin with. The demand for it only began to really increase after we had released several projects that had a significant positive impact on the department.
You have to remember that giant corporations are actually many small teams trying to work on their own problems. So the “shit” to one team may very well be mission critical to another team. Part of the manager’s job is basically deciding when it makes sense for two teams to work together (I.e. let the “shit” through) and when it doesn’t make sense and shield the team so they can focus on their work.
And at smaller organizations “shit” can take on different forms. I’ve seen a lot of “executive indecision” shit. Where the CEO or some big shot leader wakes up every week with a totally different idea and he thinks the engineers should drop everything and start working on it right away. The best managers can talk him off the ledge and let their team focus without even seeing this chaos.
As a manager at a big company, most of the shit I'm protecting my team from is not mission critical for some other team - it's the shit they don't want to deal with themselves and hope to drop in your lap.
For the same reason we end up with shit codebases - a combination of ignorance, incompetence, egos, politics, "just-this-once", laziness, and because sometimes it really is the right thing to do.
> She very effectively protected us from HR and whoever else wasn't on the team so we could focus on our work.
on contrary, bad managers use this excuse that they are protecting you from politics to hold on to important pieces of information from the team so only he has the complete picture of what is going on. I am highly suspicious of managers who keep saying this.
This is ridiculous, if you want to be clued in to all the bullshit flying around then you should move into management because as a developer it will kill your productivity trying to keep up with and interpret it.
I didn't say that though, I said "important pieces of information" . You made least charitable interpretation of what I said and called it 'ridiculous'.
I am not saying all but i've seen managers use this excuse to justify withholding information to justify their usefulness to the project.
Fair point, but managers shouldn't avoid doing the right thing because it could be done for the wrong reason. Bad managers will use all kinds of nonsensical justifications, so I wouldn't over-index on that.
Margaret had all the hallmarks of an incredibly great manager. She hired for potential (not past achievement) and gave employees every opportunity to grow and pursue our passion as developers. This allowed me to pivot and grow into web development, which was not in my job description or past experience. She never micromanaged, even when a deadline was approaching. She never demoed a project or took credit for something she didn't build herself. Like my teammates, I had to demo every product I built -- which was challenging but forced me to grow in public speaking skills (and she coached me the first few times). This also allowed me and other team members to gain recognition throughout the department.
She very effectively protected us from HR and whoever else wasn't on the team so we could focus on our work. A few times someone tried to ask us for help with someone else's project without asking her first--she was furious. She also fought (very effectively) with HR and management to get us raises that better reflected our increasing market value.
I owe my career and present livelihood largely to Margaret and the opportunities she provided me. I'd be remiss not to acknowledge God's obvious provision to me in her. Thanks so much Margaret, and thank you Lord.