They were my personal combination janitor/talent agent.
They cleaned up the technical and political messes that me and my colleagues would often made and they helped to sell the virtues of our team and our work around the company.
He actually cared about me. Asked me how I was feeling, how life is besides work. Then from time to time he'd take us for lunch or dinner (we were a total of 6 people in his team). Felt great, everybody was really productive and happy to go to work.
He actually cared about making money. (I'm amazed at how many bosses care about everything except making money, even at hedge funds.) He gave me total autonomy to build whatever I wanted as long as I made money.
I had a sales job like this for a while at a small VAR. We were an HP, Netapp, cisco, etc Gold partner, but my boss didnt care if I sold any of that, only that I generated enough profit to cover my base salary through literally any means.
Ended up writing my own software to interact with the Amazon Marketplace sellers API and all our distributors nightly inventory data and just drop ship stuff in mass, and send a couple product I had the best pricing on to Amazon for FBA.
I got it down to maybe an hour of real work a week and was crushing my numbers. After a year or so of that I got bored and jumped shipped though because I didnt see any additional personal growth to be had at the company.
A lot of refactoring my code for the sake of refactoring, adding in more error handling and edge case protection, trying to make it only 30 minutes of work instead of an hour the next week, and a fair bit of HN and reddit and youtube.
The skills I taught myself in doing that largely lead to the position I've got now.
He approached problems from different angles than most. He understood what our business is and didnt get lost in details that didnt matter. Thanks to his decisions, efficiency on things he was involved improved significantly.
More importantly, he managed chaos. And he embraced it. From technical pov, he saw experiments as an opportunity, and set a goal to team to run as many as they can fit into cookie mods. This allowed team to learn what works and what doesnt, and gave them immediate feedback. Almost everyone else sees it only as a way to be conservative (slow roll out that is safe), this guy saw it as an opportunity.
I guess tl;dr; sees the bigger picture and doesnt get lost in details, embraces enthropy and sees it as an opportunity.
I was lucky that my first technical role was where I found the best manager I've had. He was my 2nd supervisor in that first role.
After that I got to be pickier than most about where to go next, so my results might be rosier than others. In total I've had 7 "supervisors" in my technical career. 2 of them were amazing and I would take a (small) pay cut right now to work with either. 2 were good, mostly hands off, and easy to work with. The other 3 were nice people with good intentions, but significant managerial shortcomings. None of them were bad or insufferable.
In one case, an extraordinary mentor almost entirely made up for shortcomings of the manager. Working with great people alongside you often makes the incompetency of the people above a little less relevant, or at least more tolerable.
He tore down barriers and made sure interactions with other parts of the organization or external parties were as frictionless as possible. He would take any non-technical chores off our plate where possible. He would give clear and frequent feedback, good and bad, and really cared about where I wanted to go with my career and what kind of projects I wanted to work on. He trusted me when I said I would do something and would just make sure everything was out of my way until I asked for help or deadlines were being missed.
He was a shield for those of us who worked for him.
I have found that "best buddies" and "good manager" are not always correlated. That is to say, sometimes having a good personal relationship with a manager is a sign of a good manager and sometimes not; one does not imply the other.
On the one hand, being good friends with a manager may prompt one to go the extra mile because you're helping your dear friend (and perhaps vice versa). On the other hand, a deep friendship may cause you to ignore or downplay flaws or problems (that may seriously impact the customer, etc).
I don't have a single "most favorite" but I worked for someone a couple weeks ago who began by saying "I just want you to get the job done right and I don't care how long it takes you".
I knew right away I was going to love it there. That's the way to my heart.
I think most of us want our code to see the light of day. If given an actual problem to solve, we aren't going to toil away at tiny details forever. We want to see it run!
A good manager knows this and will give you room to find that balance yourself, unless you have demonstrated you need help with that.
I read an interesting twist on perfectionism: try to the "perfect compromise". Quality has multiple dimensions and you can't optimize all of them perfectly. Instead, choose which dimension is actually most important for the current problem and prioritize it.
A few years ago I invented[1] the term 'acceptimal', meaning 'acceptably optimal'. It's not the absolute best solution, but it's a pragmatic compromise between time, cost, performance, and simplicity which performs acceptably close to optimally.
[1] Or at least I've never heard anyone else use it who didn't get it from me.
It only seems to work when the person doing the work has good judgement about what things need to be right and the manager trusts them. If there are communication and trust issues, then there will be the constant back and forth between "what makes us money" and "what needs to be fixed."
IMO, good judgement about the things that need to be right enhances the ability to make money. Too often I see manager-type people disregard the technical grievances of a team as ambiguous/unimportant things, while at the same time wondering why nobody can deliver and get things done. There is very often a direct connection!
I would think that’s the worse kind of manager. One of a manager’s job is to manage resources. There are always trade offs between doing things “right” and delivering. If you look at the old Joel quadrant of smart / gets things done (delivers value to the business), someone who “doesn’t care how long it takes” runs the risk of gold plating features instead of delivering. A deadline is a great focusing mechanism.
One big demotivating factor is forcing people to deliver mediocre stuff. That's the way to loose the best. Many folks are motivated by delivering high quality, higher even then the market wants/desires. No need to push or force them - just letting them build the best does a lot of good. There is a book called Peopleware, that discusses that aspect.
It’s even more demotivating to not have a job to come to because you aren’t delivering value to your paying customers or you didn’t have a product that convinced your investors to keep pumping money into your business.
There has to be a balance. The company can’t exist without both customers (either internal or external) and employees.
Speaking purely for myself here, but no, that's not as demotivating. Having to deliver crapware is demotivating, because you know that either the customer or yourself will get burnt by entirely preventable problems. Having to chase a new job is stressful, but not as demotivating since you know (or, have faith that) the stress is temporary.
I don't believe this, but I am curious what your thoughts are (or others) on the questioning of the premise that this job (or any job) needs "the best".
I know that once I motivated two full-stack developers to work a lot more than they were being paid for by saying 'just because the New York Times frontend developers can't do it, doesn't mean we can't do it'.
I still feel a bit ashamed when I think about how much time they invested (~160%), but I wasn't forcing them in any way. They knew the total budget from the beginning, and with that in mind, we were setting the scope together. It was their will to deliver the best possible quality which made them work the extra hours.
In the end, everybody was happy as the project was pretty successful.
Probably just a pat on the back :-/ but I don't know since they were employed at a different company.
Nevertheless, my feedback towards their team lead was very positive, and that might have helped them too since they both collected a bunch of negative feedback while working with some of my colleagues.
If you demand something from someone, often they'll give it grudgingly, and only as much as they're obligated to give. If you let that same person decide how much to give, especially when they also enjoy their work, often they'll gladly give you much more.
This was a single repeated task with a high cost of failure. There was zero possibility of "gold plating". I was working at a speed I thought I could maintain without killing someone. Telling me to think about a deadline would have simply added stress. I was plenty focused already.
We finished the week's work more than a day faster than planned.
It depends on the task at hand. The traditional project management knows three resources: Time, Quality and Budget.
So if the job requires a very high level of Quality you might start by telling people you want them to do it right and time doesn't matter (it's not precisely correct but pretty clear). If nothing gets ever done at all, you might need to talk again ;-)
There's a discussion of this in Peopleware. If memory serves me well (I read it over 15 years ago), their data suggested that:
1. If you - the manager - set the deadline yourself, the estimate will often be off (unless you're very experienced and could do it yourself; see 3).
2. If you let your engineer set their own deadline, the estimate will often be off (unless they're very experienced; see 3).
3. If you have a very experienced specialist set the deadline, the estimate will often be about right.
4. If you give no deadlines at all ("wake me up when you're done"), directs will pour their soul into it more often than not, and beat the estimate you'd get from 3.
The main argument against 1 and 2 is that having too tight a deadline is very demotivating. What's the point in working against a benchmark you can't possibly meet? (Having too loose a deadline runs into Parkinson's law, but the problem is usually that the estimate is too optimistic.)
Having tried 4 with various teams over the years, I'd suggest it can work wonderfully - but only sometimes. It requires that your team consists a) entirely of professionally minded engineers who b) can see first hand that what they're doing is useful. You're better off sticking with 3 when not.
I agree - I've worked for a company where there was zero pressure to deliver and an emphasis on quality. This led to endless discussions about minutiae code details and long debates about best practises. We ended up rewriting some parts of the code base because someone suggested it wasn't exemplary even though it was definitely fine.
The thing is, good code rarely looks stellar. It looks like code which you understand without much trouble, and usually there's more than one way to make it that way. If you get caught up into the trap of thinking you have deliver something amazing but don't understand what amazing really looks like, you're in for a lot of wasted resources.
After the aforementioned company I worked for a startup, and man was it a joy to actually ship code that affected lives. Sure, the code wasn't always the most polished, but being trusted to find the right balance between technical debt for speed of execution felt great.
Sometimes saying 'things should be done right no matter how long it takes' just means the management is unable to balance technical debt with other objectives.
Two common themes I'm seeing in all these comments, which are especially clear in this one:
1. Everybody who disagrees with my manager's statement are working in software (I was not).
2. In software, nobody can seem to agree on what exactly "quality" means.
Software is still such a young field that nobody can seem to agree on anything at all. It reminds me of other fields 100 years ago, where you could just try anything and if it seemed to work that was fine.
> Sometimes saying 'things should be done right no matter how long it takes' just means the management is unable to balance technical debt with other objectives.
In this case, I would say they'd done such a good job with managing technical debt that they knew they could say "as long as it takes" on a micro-level, and be confident that nothing would blow up on a macro-level.
This was a physical system that has annual (or semi-annual) inspections by a third party. Can you say the same about your software system?
I think you are in a very lucky situation, and that's probably not the manager's impetus, maybe it's something else.
There are very, very few managers who are realistically in a position to be able to say something like that.
There's a good chance you might be working for a nice guy / purist / engineer's manager ... but who might actually not be a very good manager at all.
If 'getting it right no matter the cost' were a good company building philosophy, we'd all be doing it!
'Getting it good enough for the market to accept given a limited budget and timeframe' is basically how 99% of the world must operate. It's just reality. That's why being a manager or starting/owning/running a business is hard. Usually really hard.
The Tao Of Programming, Book 5, Maintenance (Geoffrey James, 1987):
A manager asked a programmer how long it would take him to finish the program on which he was working. “It will be finished tomorrow,” the programmer promptly replied.
“I think you are being unrealistic,” said the manager, “Truthfully, how long will it take?”
The programmer thought for a moment. “I have some features that I wish to add. This will take at least two weeks,” he finally said.
“Even that is too much to expect,” insisted the manager, “I will be satisfied if you simply tell me when the program is complete.”
The programmer agreed to this.
Several years later, the manager retired. On the way to his retirement luncheon, he discovered the programmer asleep at his terminal. He had been programming all night.
I have been really lucky to have a number of great bosses in my career past and present. All of them have shared common traits (to varying degrees) of being available to listen and talk when needed, having a vision and a plan, empathy for life situations, missed deadlines and goals, and finally a desire to invest in personal growth even when it might not immediately be in the best interests of the organization.
I’ve never had a great manager. I look for a manager to serve a few purposes - remove obstacles, communicate the priorities of the company, get the resources a team needs, and provide a level of technical/career leadership depending on where you are in your career.
But, let me focus on the two most of important purely selfish things for me. I want a manager who provides an environment for me to grow technically and fights for me to make more money. Everything else is secondary.
I’ve had good technical managers that I learned a lot from but had no political abilities to get thier team raises so I had to take the skills I learned and get another job and I’ve had overly political managers that would throw you under the bus to get ahead but if you made them look good, you could enjoy the ride until they stabbed you in the back.
She didn't micro-manage anybody - gave everyone trust to do their job. She were honest with mistakes and worked on solutions to correct in dialoge, not monologue.
At a previous company, I joined a team that had to deliver something a year before I joined. All previous teams assembled to deliver that had failed and had been fired. That the company didn't have that feature was deeply embarrassing, the competition mentioned having it in the first line of their marketing materials. The most influential engineers on the team didn't give a damn about deadlines and thought that being friends with the director would save them, had elaborately set up a plan to blame other engineers they were not friends with, who were on the way to get fired - half the team would never, ever speak to the other half or even be in the same room. I saw a (good) new manager get hired, see the clusterf*ck, and quit because it was hopeless. None of the other managers wanted anything to do with us, we were toxic. Then someone without people management experience got "promoted" to our manager. She told us she didn't care about any of us. Revoked everybody's little privileges, would literally come see if everybody was on their keyboard and typing all the time. Didn't force overtime on anyone but was adamant against people arriving late or leaving early or missing meetings. Started openly taking notes of everybody's failures so she would have ample documentation of who failed what. Told people what to do, didn't want to know the person's opinion about it. A few short months later we shipped.
Part of being a good manager is to adapt to the situation and do what's sensible. This was an example of a good manager. Conscientiousness is always a great trait.
But we got just one sample case. We don't know how she would act in the opposite situation. It could be she is a great manager but it could also be that she was promoted because the situation asked for a tyrant and she was indeed one. When someone gets promoted in the middle of a fire the person to look after to understand the decision is the person that did the promotion. Sometimes the promoted person is promoted to do the dirty work and the person above he/she it's just exploiting their personality traits.
This is a really great question. The child argues that a good manager adapts to whatever situation is needed. It would be interesting to know if this manager took this "win" and managed all future teams this way as well, even ones that are highly functional or working on more experimental code/projects.
The best manager is the one whose only focus is for each of the team members and the team collectively to be successful. In some companies or teams that may be removing distractions or introducing accountability or getting rid of a bad apple or .... The problem is that we as humans generalize and the first success a new manager has is seen as the best way forever no matter what because it works. That way lays madness.
> She told us she didn't care about any of us. Revoked everybody's little privileges, would literally come see if everybody was on their keyboard and typing all the time. Didn't force overtime on anyone but was adamant against people arriving late or leaving early or missing meetings. Started openly taking notes of everybody's failures so she would have ample documentation of who failed what.
That sounds pretty horrendous to me, I would wish her all the best and leave.
For pretty much all teams I'd agree. But if it comes to the point as described, you pretty much have to revert to treat everybody at children and gradually build it up from there. Privileges is something you work to get.
Not within the existing culture. It seems necessary.
Most of that is "blank slate, let's start again" with expectations made clear. Obviously that was lacking in this place.
When you've got people successfully blaming others for their own failures, this manager, with experience on the front lines, did the most effective thing to remedy that. I'm sure nobody got fired for someone else's failings after that.
Exactly. The deal wasn't static: people got their freedom back when they showed they were worthy of it.
The aftermath was that a few people left the company for better jobs after we shipped (unavoidable, some had set their minds even before she joined and actually stayed longer because of her). For the rest, it was promotions. The engineers on a PIP exited the PIP by being promoted(!), were allowed to move to their favorite projects. Even the scheming engineers who turned us into a toxic team got promoted for the work they did under her management (though personally I think they should have been shown the door for their attitude). Manager moved to a more prestigious peacetime team, where I am sure she runs things differently.
To me it seems a lot of people in these teams were more interested in climbing the corporate ladder than working in nice teams. Those kinds of people might perhaps be hesitant to leave the company.
This is the wartime/peacetime leader conundrum. The tactics she used worked well because the situation was dire. They probably wouldn't have worked well in a company with a good culture.
Winston Churchill is the most famous example of this. He was a great leader during wartime but terrible during peacetime.
This book A First-Rate Madness by Nassir Ghaemi [0] is about that. He looks at various historical leaders and how one half of them make good wartime leaders, but bad peacetime leaders, and the other half -- the opposite. Some of his case studies are, as far as I can remember (couldn't find a summary online): generals in US civil war (Lee and the scortched-earth-guy), Chamberlaine, Churchill, Hitler, JFK, Lincoln, Napoleon, Nixon, Bush. US centric, but still pertaining to anyone.
It's not that Churchill was a different person in wartime than in peacetime, it's just that most people's morals change from wartime to peacetime. So the same atrocity could be viewed as an atrocity or heroic and brave depending on what the public at large feels like their situation was like at the time. That's the point being raised about the manager: every statement the parent made was basically an accusation, but because the team was desperate the success in the end overwrote the other things in everybody's mind.
If the team had failed in the end, all of the qualities that are presently being lauded would be held at fault. True morals may not be relative and situational, but the average person's mental implementation of morals sure can be.
Churchill was a complex man, but it was his party that got defeated in the 1945 election not Churchill. (Churchill it should be said, was a Liberal, not a Conservative before the war, and joined the party to prevent conflict in the immediate aftermath of the outbreak - he would later describe it (in his diaries) as a mistake.)
We don´t know if he would have been a good or bad leader during peacetime (by the time the conservatives got back into office he was no longer in his prime shall we say), but what he would most certainly have been is a leader with a lot of experience in dealing with Stalin, and a British Imperialist. Which would have been entertaining at least.
Why? It sounds like she was giving direction to her directs and holding them to account. Every manager who gets stuff done does the same thing in their own style.
There arguably are less blunt ways to do it - but for that team, it seems like it was the right approach. Also, OP is presumably overstating the need to be typing all the time since that's not how programming works.
In context of a toxic enviroment this may be more like a reset. See who has substance and who doesn't. If you do this in a clear and fair way it doesn't seem unreasonable for a non-performing enviroment. The benifits and flexibility can return when earned and the bad eggs are discovered and removed.
What little management experience I have (3 years as team lead for 2 different teams) tells me most people are masochists deep down inside and crave a dictator to order them what to do.
When a manager tells someone what to do, that person is personally assuming the responsibility of deciding how the work must be done and, of course, being accountable for failing to deliver.
Prefering to have the manager be held accountable for managerial decisions is not masochism. In fact the opposite, having to decide what and how work should be done and having to answer for your decisions, suits that definition a whole lot better.
This kind of thing generally works where there is underlying sense of duty, or impetus to win.
The WW2 film 'Twelve O'Clock High' where an Air Force General comes in an sorts out a demoralized and broken unit is used as training in various militaries to depict this kind of leadership on a higher level.
But 'reprimands' etc. tend only to work when there's a higher calling. Like winning a war.
For salaried teams - even if the team is being a little dysfunctional ... just might lead to mutiny, exodus.
From what you described I'm very surprised that the team didn't fall apart, or that the product was shipped.
A few things:
1) If the team was that utterly toxic, and people were openly backstabbing others ... this is not going to be fixed really. Those people are toxic they need to go.
2) Changing culture 'in place' is really hard with regular people. You can't just come in and play hardball with carrots and sticks. An alternative would be basically re-org the whole thing. Even having a different physical presence, maybe different team structure ... even if it's kind of a facade - a new work dynamic might set up people towards thinking of a 'clean start'. So instead of 'penalizing' people for coming in late etc. you have a new team dynamic in a new operating environment where 'everyone agrees' to more specific hours for the betterment of the team. A good idea would be to 'listen' to some of the problems, even if there's no action on it, just the act of listening will help.
I think you're lucky ... your 'no nonsense' manager is very lucky and this approach I think can only really work when there is a specific kind of dysfunction. I think if you have younger developers, all of whom lack self discipline but are otherwise good team members, maybe who need just a little bit of a kick in the pants. But I'm glad you had a good experience.
It sounds like she gave the dev team a 'day 1 boot camp' treatment -- if it works for the military, then why not a bunch of petulant developers...
Hopefully she transitioned to a more compassionate and positive management style after whipping the team into shape, instilling discipline and earning their respect as an effective leader.
Learned that the hard way. :( Unfortunately can't be said enough. Managers have to learn how to deal with bad apples. Tried too hard and long giving benefit of the doubt that the apples were actually good inside in some situations.
It's not just bad apples. Sometimes people just aren't a good fit for a role. It turns out they don't have the right skills mix, need too much direction, etc. I've definitely seen perfectly nice folks who come in but it turns out they can't really do the job and no amount of coaching seems to help. It's better for everyone not to string things out too much.
Being honest, I've had one job I wasn't a good fit for myself. But the dot-com bubble burst took care of that one relatively quickly.
My favourite attitudes in my managers (plural) over the years:
-Intellectually curious / stimulating - This gave the team the time and awareness that science mattered in our jobs, pursue intellectual journeys that actually made our work better and more rewarding. I got to learn R in the aughts, work with academia and create products the company didn't have a real use for at the time, but are their bread and butter nowadays.
-Being totally lean (in the Toyota sense) - There's so much support you can get from a manager that is aware of the hidden cost to rework and not first-time right. He would actually go out on a limb talking to other departments and managers who would make our work less productive. This guy actually bought and brought a pie to another team after they failed us multiple times to try and help them to remember there were others dependant on their work.
-Being appreciative of outsiders trying to suggest changes to the status-quo. This is a big one. You could call this humility. Teams, roles and the surroundings change constantly. Better to change from the inside out, than only when faced with external threats. But it's a hard one since the status-quo and office politics on a day to day basis seem so important.
Whether or not these skills help the manager up the corporate chain depends. For the first one to succeed you need a surrounding that's appreciative for research and new things to come out of the team. The second is a awesome middle manager skill that will be mostly in demand in change roles, but not so much in regular management roles. I am sad about this, but most environments the one who rocks the boat is the one the outside. The third is a more common subset of the second and a true leadership skill, but again managing change in a stagnant environment is hard. People expect your team to do the same thing every day.
What trumps all these great traits is: communication. Each manager should have the skill to communicating what he is doing with his team to his higher ups and surroundings. Only then can what he brings to the team flourish in the corporate environment.
I work for someone who I can trust when he says something, he does what he can to get it done. He tells me the goal we need to archive, and asks me how we can do it. Then he does everything he can to make sure I have all my stuff ready to do it. If there is a problem he helps me fix it. If something goes wrong he blames himself. If the project goes right and the customer is happy he tells everyone it's my accomplishment.
We are a team and we trust each other. I feel he knows I am good at what I do and he let's me do it, and I feel he is good at what he does and together we can accomplish great things.
We are friends, and we like each other. We disagree sometimes, but we work it out by making compromises.
> I work for someone who I can trust when he says something he does what he can to get it done. He tells me the goal we need to archive, and asks me how we can do it. Then he does everything he can to make sure I have all my stuff ready to do it. If there is a problem he helps me fix it. If something goes wrong he blames himself. If the project goes right and the customer is happy he tells everyone it's my accomplishment.
My manager goes out of his way to allow people who have passions for things onto smaller teams that work on those passions. Our company and our products are built because someone wanted to fix a problem and were given the time to do so. Playing to our strengths and helping us work on our weaknesses. No micro-manging involved, just trust and encouragement. Will lay the hammer down if needed in edge case situations but will also defend the team to the death from outside pressures and obstacles.
Whenever I stepped out of his office, I'd always have fewer problems than I had when I stepped into it. That's a managerial attribute that shouldn't be taken for granted.
Amazing systems knowledge. My previous senior was the chief architect, and a life long C++ developer. His systems knowledge was amazing, unlike all the people i knew previously who were either Java or PHP or Ruby coders. Dynamic language folks have almost no knowledge of the system their software works on which makes them script kiddies at best. Experience isnt enough to be a senior, your knowledge domain should also expand with time. Which for may doesnt and they are still developing in Ruby/Rails or PHP or Java. They havent tried writing or learning any other language. But the C++ guy since had learnt maybe 3-4 new languages. Including elm, js , Haskell etc. I feel that Knowing the latest Ruby/Rails API isnt enough to qualify as an architect because it changes every yr. That isnt an indicative of how good a programmer you are or how you think. I had .NET and Java language colleagues earlier who i had discussions like why are you starting two docker containers when one is enough? And i had a hard time explaining them the purpose of docker or process isolation. I feel a good systems knowledge is crucial to developing software including webapps. The managers with good systems could identify problems quickly while with others i had discussions like lets just deploy 1 docker container to what is docker etc..
Nope unfortunately i am describing a manager, our techlead was no good Ruby Developer with no idea about anything. We cleared our doubts from our architect/Manager.
I guess your expectation from the manager is the MBA types? Well they can never be good project managers in Tech, atleast what i have seen. Only tech people can lead good tech companies.
We were good friends. He knew every one of my strengths and what I could accomplish if given the freedom. And he gave me it in spades, enough to see a shared vision into a very successful end product.
He helped evangelize my work and got people excited about it, and had as much a part in the success as anything because of the barriers he removed, the air cover he gave me to allow the time to fix the biggest issues of it, all while helping me triage bugs and provide end-user support.
He was highly technical, and understood my code. He didn’t step on my toes or try to force any technical direction in any way, he knew well enough to delegate, and trusted my decisions. But provided amazing advice when I needed it.
Eventually he had too many people on his team and needed help managing, and I ended up getting promoted to a manager (still under him) mostly out of a favor to help him out.
That was the beginning of the end though, because eventually a reorg moved my new team to a different side of the larger org. And everything kinda went to shit after that and I left the company.
Lesson learned: Don’t become a manager as a favor to someone if you’re not ready for it.
I loved a manager I had who would listen to all arguments and allow himself to be persuaded. He also said sometimes "you're right, but we have to do it my way this time", and had earned so much trust that, when he said it, I knew the reasons were good.
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.
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".
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.
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”.)
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.
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.
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.
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.
> 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.
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'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.
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.
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.
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?"
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.
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.
> 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.
247 comments
[ 2.7 ms ] story [ 262 ms ] threadThey cleaned up the technical and political messes that me and my colleagues would often made and they helped to sell the virtues of our team and our work around the company.
He understood that the success of his team was his success, and didn't need the praise.
Ended up writing my own software to interact with the Amazon Marketplace sellers API and all our distributors nightly inventory data and just drop ship stuff in mass, and send a couple product I had the best pricing on to Amazon for FBA.
I got it down to maybe an hour of real work a week and was crushing my numbers. After a year or so of that I got bored and jumped shipped though because I didnt see any additional personal growth to be had at the company.
The skills I taught myself in doing that largely lead to the position I've got now.
Knowing they had my back if the shit hit the fan.
I've only experienced this once unfortunately.
He approached problems from different angles than most. He understood what our business is and didnt get lost in details that didnt matter. Thanks to his decisions, efficiency on things he was involved improved significantly.
More importantly, he managed chaos. And he embraced it. From technical pov, he saw experiments as an opportunity, and set a goal to team to run as many as they can fit into cookie mods. This allowed team to learn what works and what doesnt, and gave them immediate feedback. Almost everyone else sees it only as a way to be conservative (slow roll out that is safe), this guy saw it as an opportunity.
I guess tl;dr; sees the bigger picture and doesnt get lost in details, embraces enthropy and sees it as an opportunity.
After that I got to be pickier than most about where to go next, so my results might be rosier than others. In total I've had 7 "supervisors" in my technical career. 2 of them were amazing and I would take a (small) pay cut right now to work with either. 2 were good, mostly hands off, and easy to work with. The other 3 were nice people with good intentions, but significant managerial shortcomings. None of them were bad or insufferable.
In one case, an extraordinary mentor almost entirely made up for shortcomings of the manager. Working with great people alongside you often makes the incompetency of the people above a little less relevant, or at least more tolerable.
He was a shield for those of us who worked for him.
On the one hand, being good friends with a manager may prompt one to go the extra mile because you're helping your dear friend (and perhaps vice versa). On the other hand, a deep friendship may cause you to ignore or downplay flaws or problems (that may seriously impact the customer, etc).
I knew right away I was going to love it there. That's the way to my heart.
A good manager knows this and will give you room to find that balance yourself, unless you have demonstrated you need help with that.
[1] Or at least I've never heard anyone else use it who didn't get it from me.
IMO, good judgement about the things that need to be right enhances the ability to make money. Too often I see manager-type people disregard the technical grievances of a team as ambiguous/unimportant things, while at the same time wondering why nobody can deliver and get things done. There is very often a direct connection!
And no I’m not a manager.
There has to be a balance. The company can’t exist without both customers (either internal or external) and employees.
I still feel a bit ashamed when I think about how much time they invested (~160%), but I wasn't forcing them in any way. They knew the total budget from the beginning, and with that in mind, we were setting the scope together. It was their will to deliver the best possible quality which made them work the extra hours.
In the end, everybody was happy as the project was pretty successful.
Nevertheless, my feedback towards their team lead was very positive, and that might have helped them too since they both collected a bunch of negative feedback while working with some of my colleagues.
https://en.wikipedia.org/wiki/Work-to-rule
We finished the week's work more than a day faster than planned.
So if the job requires a very high level of Quality you might start by telling people you want them to do it right and time doesn't matter (it's not precisely correct but pretty clear). If nothing gets ever done at all, you might need to talk again ;-)
1. If you - the manager - set the deadline yourself, the estimate will often be off (unless you're very experienced and could do it yourself; see 3).
2. If you let your engineer set their own deadline, the estimate will often be off (unless they're very experienced; see 3).
3. If you have a very experienced specialist set the deadline, the estimate will often be about right.
4. If you give no deadlines at all ("wake me up when you're done"), directs will pour their soul into it more often than not, and beat the estimate you'd get from 3.
The main argument against 1 and 2 is that having too tight a deadline is very demotivating. What's the point in working against a benchmark you can't possibly meet? (Having too loose a deadline runs into Parkinson's law, but the problem is usually that the estimate is too optimistic.)
Having tried 4 with various teams over the years, I'd suggest it can work wonderfully - but only sometimes. It requires that your team consists a) entirely of professionally minded engineers who b) can see first hand that what they're doing is useful. You're better off sticking with 3 when not.
The thing is, good code rarely looks stellar. It looks like code which you understand without much trouble, and usually there's more than one way to make it that way. If you get caught up into the trap of thinking you have deliver something amazing but don't understand what amazing really looks like, you're in for a lot of wasted resources.
After the aforementioned company I worked for a startup, and man was it a joy to actually ship code that affected lives. Sure, the code wasn't always the most polished, but being trusted to find the right balance between technical debt for speed of execution felt great.
Sometimes saying 'things should be done right no matter how long it takes' just means the management is unable to balance technical debt with other objectives.
1. Everybody who disagrees with my manager's statement are working in software (I was not).
2. In software, nobody can seem to agree on what exactly "quality" means.
Software is still such a young field that nobody can seem to agree on anything at all. It reminds me of other fields 100 years ago, where you could just try anything and if it seemed to work that was fine.
> Sometimes saying 'things should be done right no matter how long it takes' just means the management is unable to balance technical debt with other objectives.
In this case, I would say they'd done such a good job with managing technical debt that they knew they could say "as long as it takes" on a micro-level, and be confident that nothing would blow up on a macro-level.
This was a physical system that has annual (or semi-annual) inspections by a third party. Can you say the same about your software system?
I’m often bemoaning the “Silicon Valley Bubble” that people are caught in on HN. I guess I fell into the related “Software Developers Bubble”.....
Point taken.
There are very, very few managers who are realistically in a position to be able to say something like that.
There's a good chance you might be working for a nice guy / purist / engineer's manager ... but who might actually not be a very good manager at all.
If 'getting it right no matter the cost' were a good company building philosophy, we'd all be doing it!
'Getting it good enough for the market to accept given a limited budget and timeframe' is basically how 99% of the world must operate. It's just reality. That's why being a manager or starting/owning/running a business is hard. Usually really hard.
A manager asked a programmer how long it would take him to finish the program on which he was working. “It will be finished tomorrow,” the programmer promptly replied.
“I think you are being unrealistic,” said the manager, “Truthfully, how long will it take?”
The programmer thought for a moment. “I have some features that I wish to add. This will take at least two weeks,” he finally said.
“Even that is too much to expect,” insisted the manager, “I will be satisfied if you simply tell me when the program is complete.”
The programmer agreed to this.
Several years later, the manager retired. On the way to his retirement luncheon, he discovered the programmer asleep at his terminal. He had been programming all night.
Clear direction
Trust
Let me choose my own hours
Blocks meetings I don't need to be in
But, let me focus on the two most of important purely selfish things for me. I want a manager who provides an environment for me to grow technically and fights for me to make more money. Everything else is secondary.
I’ve had good technical managers that I learned a lot from but had no political abilities to get thier team raises so I had to take the skills I learned and get another job and I’ve had overly political managers that would throw you under the bus to get ahead but if you made them look good, you could enjoy the ride until they stabbed you in the back.
Best manager I ever had.
The best manager is the one whose only focus is for each of the team members and the team collectively to be successful. In some companies or teams that may be removing distractions or introducing accountability or getting rid of a bad apple or .... The problem is that we as humans generalize and the first success a new manager has is seen as the best way forever no matter what because it works. That way lays madness.
That sounds pretty horrendous to me, I would wish her all the best and leave.
Most of that is "blank slate, let's start again" with expectations made clear. Obviously that was lacking in this place.
When you've got people successfully blaming others for their own failures, this manager, with experience on the front lines, did the most effective thing to remedy that. I'm sure nobody got fired for someone else's failings after that.
The aftermath was that a few people left the company for better jobs after we shipped (unavoidable, some had set their minds even before she joined and actually stayed longer because of her). For the rest, it was promotions. The engineers on a PIP exited the PIP by being promoted(!), were allowed to move to their favorite projects. Even the scheming engineers who turned us into a toxic team got promoted for the work they did under her management (though personally I think they should have been shown the door for their attitude). Manager moved to a more prestigious peacetime team, where I am sure she runs things differently.
Winston Churchill is the most famous example of this. He was a great leader during wartime but terrible during peacetime.
[0] https://www.amazon.com/First-Rate-Madness-Uncovering-Between...
William Tecumseh Sherman, of "Sherman's march to the sea"
http://content.time.com/time/magazine/article/0,9171,2031992...
If the team had failed in the end, all of the qualities that are presently being lauded would be held at fault. True morals may not be relative and situational, but the average person's mental implementation of morals sure can be.
We don´t know if he would have been a good or bad leader during peacetime (by the time the conservatives got back into office he was no longer in his prime shall we say), but what he would most certainly have been is a leader with a lot of experience in dealing with Stalin, and a British Imperialist. Which would have been entertaining at least.
There arguably are less blunt ways to do it - but for that team, it seems like it was the right approach. Also, OP is presumably overstating the need to be typing all the time since that's not how programming works.
When a manager tells someone what to do, that person is personally assuming the responsibility of deciding how the work must be done and, of course, being accountable for failing to deliver.
Prefering to have the manager be held accountable for managerial decisions is not masochism. In fact the opposite, having to decide what and how work should be done and having to answer for your decisions, suits that definition a whole lot better.
Yes, but what happened to the product?
Very sorry to hear that.
This kind of thing generally works where there is underlying sense of duty, or impetus to win.
The WW2 film 'Twelve O'Clock High' where an Air Force General comes in an sorts out a demoralized and broken unit is used as training in various militaries to depict this kind of leadership on a higher level.
But 'reprimands' etc. tend only to work when there's a higher calling. Like winning a war.
For salaried teams - even if the team is being a little dysfunctional ... just might lead to mutiny, exodus.
From what you described I'm very surprised that the team didn't fall apart, or that the product was shipped.
A few things:
1) If the team was that utterly toxic, and people were openly backstabbing others ... this is not going to be fixed really. Those people are toxic they need to go.
2) Changing culture 'in place' is really hard with regular people. You can't just come in and play hardball with carrots and sticks. An alternative would be basically re-org the whole thing. Even having a different physical presence, maybe different team structure ... even if it's kind of a facade - a new work dynamic might set up people towards thinking of a 'clean start'. So instead of 'penalizing' people for coming in late etc. you have a new team dynamic in a new operating environment where 'everyone agrees' to more specific hours for the betterment of the team. A good idea would be to 'listen' to some of the problems, even if there's no action on it, just the act of listening will help.
I think you're lucky ... your 'no nonsense' manager is very lucky and this approach I think can only really work when there is a specific kind of dysfunction. I think if you have younger developers, all of whom lack self discipline but are otherwise good team members, maybe who need just a little bit of a kick in the pants. But I'm glad you had a good experience.
Hopefully she transitioned to a more compassionate and positive management style after whipping the team into shape, instilling discipline and earning their respect as an effective leader.
Being honest, I've had one job I wasn't a good fit for myself. But the dot-com bubble burst took care of that one relatively quickly.
-Intellectually curious / stimulating - This gave the team the time and awareness that science mattered in our jobs, pursue intellectual journeys that actually made our work better and more rewarding. I got to learn R in the aughts, work with academia and create products the company didn't have a real use for at the time, but are their bread and butter nowadays.
-Being totally lean (in the Toyota sense) - There's so much support you can get from a manager that is aware of the hidden cost to rework and not first-time right. He would actually go out on a limb talking to other departments and managers who would make our work less productive. This guy actually bought and brought a pie to another team after they failed us multiple times to try and help them to remember there were others dependant on their work.
-Being appreciative of outsiders trying to suggest changes to the status-quo. This is a big one. You could call this humility. Teams, roles and the surroundings change constantly. Better to change from the inside out, than only when faced with external threats. But it's a hard one since the status-quo and office politics on a day to day basis seem so important.
Whether or not these skills help the manager up the corporate chain depends. For the first one to succeed you need a surrounding that's appreciative for research and new things to come out of the team. The second is a awesome middle manager skill that will be mostly in demand in change roles, but not so much in regular management roles. I am sad about this, but most environments the one who rocks the boat is the one the outside. The third is a more common subset of the second and a true leadership skill, but again managing change in a stagnant environment is hard. People expect your team to do the same thing every day.
What trumps all these great traits is: communication. Each manager should have the skill to communicating what he is doing with his team to his higher ups and surroundings. Only then can what he brings to the team flourish in the corporate environment.
We are a team and we trust each other. I feel he knows I am good at what I do and he let's me do it, and I feel he is good at what he does and together we can accomplish great things.
We are friends, and we like each other. We disagree sometimes, but we work it out by making compromises.
What if your boss is a woman?
Then I would write "she" instead of "he". But Fabio is a man.
He helped evangelize my work and got people excited about it, and had as much a part in the success as anything because of the barriers he removed, the air cover he gave me to allow the time to fix the biggest issues of it, all while helping me triage bugs and provide end-user support.
He was highly technical, and understood my code. He didn’t step on my toes or try to force any technical direction in any way, he knew well enough to delegate, and trusted my decisions. But provided amazing advice when I needed it.
Eventually he had too many people on his team and needed help managing, and I ended up getting promoted to a manager (still under him) mostly out of a favor to help him out.
That was the beginning of the end though, because eventually a reorg moved my new team to a different side of the larger org. And everything kinda went to shit after that and I left the company.
Lesson learned: Don’t become a manager as a favor to someone if you’re not ready for it.
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.
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".
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.
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.
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.
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”.)
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 haven't met any manager in years that hires for potential.
- push you to your limits (public speaking)
- shield you from management/bigcorp bullshit
- hire better people than themselves
- don’t take credit from you
I've heard that memorably described as managers either being "shit umbrellas" or "shit funnels".
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.
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.
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 my current workplace suffers from too much team defensiveness + not having a CTO or equivalent to integrate across teams.
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.
In other casss, being too standoffish causes local optimization (“look how efficient my team is!”) at the expense of the broader org.
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.
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.
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.
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.
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.
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.