6 ms·

Used to work for C1. It was never really clear to me what scrum masters did, since our manager understood the technical and cross-team requirements of our produ

Used to work for C1. It was never really clear to me what scrum masters did, since our manager understood the technical and cross-team requirements of our product (I know this might not be universal) better than anyone else. The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month. I put leading in quotes because there’s only so much leading one can do if everyone else knows more about the product due to the inherent transitory nature of the scrum master role. Are you really adding value by reminding people that story points (some vague relationship to days of work) can only be Fibonacci numbers? Inside the company, the CEO loved to tout the “technical journey” they made which included things like moving to the cloud. Agile was on that list but it never really felt like it belonged. Depending on one’s tolerance of the kool-aid, some skepticism was always there.

abledon 4y ago
scrum master is one of the greatest grifts of 2010s-2020s tech. Esp when org chart pencils them in as 'mgmt' level so they are payed more than intermediate engineers, and on par with senior engineers
- newaccount2021 4y ago
  [dead]
- late2part 4y ago
  Why is it a great gift?
  - kensan73 4y ago
    Just in case you missed it, he said 'grift' (a petty or small-scale swindle)
TulliusCicero 4y ago
> story points (some vague relationship to days of work) Watching people insist that story points are totally not representative of predicted time spent working on a thing is the funniest shit. The mental gymnastics are incredible.
- lawrence19 4y ago
  Story points in my experience almost always devolve into time estimates, but I don't agree they have to be the same thing (which is how I interpret your use of "representative"). They are related variables in the same way that temperature and pressure are related, but that doesn't mean they are identical. In a healthy environment, I think "story points" (horrendous name) should approximate "engineering complexity given the current state, skill set, and knowledge of the development team." Time estimates should then be derived from that number based on historical performance of the team in its current state (if you fuck with the team structure, all bets are off and historical data becomes less useful). Ideally a team should use points to do thoughtful analysis of their backlog and think of ways to manipulate scope, invest in cleaning up technical debt, and learn new skills to cheapen the engineering complexity and in turn deliver faster. In practice, what you described is almost always what happens. Stakeholders keep pressing for time estimates, so shit just keeps getting added to the backlog and engineers estimate "how long?" because they are neither encouraged nor empowered to think of it any other way.
  - TulliusCicero 4y ago
    But by "complexity" people pretty much always mean "how long it'll take", so it's still time. If something was complex in an abstract way but quick to implement, it would get a small number of story points, not a large number.
    - lawrence19 4y ago
      I don't disagree with you fundamentally, but maybe one way to reframe this is around the type of conversation we're looking to prompt when we point stories. The conversation you're describing (and to be fair that I mostly have experienced as well) is a one-way, "you owe us this, how long will it take?" conversation. The conversation I'm always hoping to have, and that I've seen happen before, is a bi-directional one in which tradeoffs are discussed, priorities are constantly shifting, thoughtful investments are planned, and engineering concerns are a first-class citizen. All of this can happen if you simply consider your estimates "time" as well, but I find that conceptualizing it as "engineering complexity" helps encourage an engineering mindset among the non-developers on a team.
bastardoperator 4y ago
Agile and scrum is not a solution to anything. Participating in agile voodoo has no measurable impact. In fact, I think in many cases agile makes you immediately slower. Developers than realize they have to pad everything with bullshit estimates they pulled out of thin air so they're not getting punished for missing work or bad guesses. I just assume if the company is doing agile they have lost faith in their developers when it comes to organizing or producing value.
- sanedigital 4y ago
  You have been blessed to work on self-organizing and self-managing teams. When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features. Scrum isn't perfect, but its an "industry-standard" practice that we can use to get quick buy-in from client stakeholders, and then use to apply even the most basic level of process to these teams. As an engineer at Google or a freelance developer it never made much sense to me. But as a manager of remote, distributed, international teams? It makes a lot of sense.
  - trentnix 4y ago
    > When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features. Sounds familiar. Back in my consultant days, we would encounter companies that wanted to be “agile”. They’d insist they were waterfall and it wasn’t working. Truth is, if they’d actually been doing waterfall they’d have been performing far better. Instead, they were just chaos, reacting to one fire after another with no plan to get out. Additionally, many teams were simply staffed with poor managers and poor engineers. There’s no consulting-fu or process-fu that was going to overcome that. You can’t win horse races with pack mules, my dad (a basketball coach) used to say.
    - ethbr0 4y ago
      >> But as a manager of remote, distributed, international teams? > You can’t win horse races with pack mules, my dad (a basketball coach) used to say. You can boil it down to saying that Scrum is either (a) micromanagement or (b) an admission that your developers and their managers suck. Fix the problem, instead of slapping a bureaucratic band-aid on that's going to attrit any remaining quality developers.
baxtr 4y ago
What’s the overall feeling towards scrum masters? In my last company, everyone outside product tech never understood their actual value. My CTO was a big fan, he said they were the glue binding the teams together or something like that. I never had a strong opinion but I’m curious to see how much controversy there was around this role.
- tass 4y ago
  At an old team of mine at Amazon we would assign an SDE to that role and switch it around every few months or so. They were in charge of getting the right people together for any meetings, asking for extra info to be added to any backlog items, and telling teams when we were planning to deprioritise or drop the backlog items they asked for. It worked pretty well for us, and took maybe a day of time per week
  - morelisp 4y ago
    > we would assign an SDE to that role and switch it around every few months or so... took maybe a day of time per week The problem is if you are having a struggling team, it takes a lot more of a day of time and requires a lot more maturity than just leaving jira comments and sending meeting invites. But if you put your devs who are good at structuring problems/time on it, now they're participating in the actual development less, so the team gets even less functional (at best temporarily, at worst you're now in a death spiral). Furthermore if the root problem is not really the organizing but more fundamental (poor skills / skill alignment, understaffing, chaos agent, etc) the singular dev will rarely have the ability to deal with it and can even start drawing animosity. Having a separate person responsible for this, in a different hierarchy with different ears, can be a lot more effective in these situations. (It can also make it worse, if the separate person is also shit at their job, has too much work, has very different attitudes towards work than the rest of the team, ...) tl;dr: If your team is functional pretty much anything will work, these structures also need to be judged by how well they can get it back on track from non-functional.
- ecshafer 4y ago
  I don't see the point of scrum masters personally. They create more work if anything and mostly act as a cargo cult leader. A manager, a tech lead / staff developer, product manager... the other tech leadership positions on a team i see immediate value. Scrum Masters I do not and never have seen their use.
trentnix 4y ago
> The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month. I put leading in quotes because there’s only so much leading one can do if everyone else knows more about the product due to the inherent transitory nature of the scrum master role. 100% I interviewed with a company (not C1) earlier this year that had one of those “every team has a manager, every team has a scrum master” bits going on. I asked multiple times what the difference between the roles were, and couldn’t make sense of any of the answers I got (which were full of consultant-speak). I declined to move forward. Like anything, I’m sure there are teams out there with this situation that make it work. But it sounds to me like a recipe for confusion, conflict, and atrophy.
ashconnor 4y ago
Also used to work for C1. You're right in the sense that the role was always awkwardly jammed into teams often when it didn't make sense. Some were pretty good but most were of the certificate-chasing type that had bought into the commercialization (bastardization) of Agile. Give C1 their due though. They dragged the entire company into AWS, mostly, which is something I don't think any other bank that's been around as long as they have has done.
- victor106 4y ago
  > They dragged the entire company into AWS, And why/how is that a good thing?
  - Throw10987 4y ago
    I think if you rephrase it that they "dragged the whole company out of the particular IT hell that is associated with banks owning, running and procuring infrastructure" it probably makes more sense.
  - noisenotsignal 4y ago
    I interned there a couple years ago. It was nice to use tech that was more standardized than proprietary / internal so that the skills were easily transferable. From a business perspective it takes you out of the business of managing your own infrastructure. Even at big tech now we have to decide between managing our own infrastructure and “outsourcing” it to a managed service. Most advice I’ve gotten encourages the latter. It can cost more but if cost isn’t prohibitive it frees you up to deliver features and value for customers because you no longer have to develop (as much) expertise in ops.
    - victor106 4y ago
      I get that and that is the selling point of the cloud and it makes total sense for some workloads like ML/Data Science. However, once you move the companies infra to AWS (or any one cloud provider) and shutdown your infra, in due course AWS will keep increasing your price by x% every year. At the point you don't have a choice but to pay those price increases yoy. You have much less bargaining power. I think hybrid cloud is the best way to go. You have lot of bargaining power and no one provider can hold you hostage.
marcosdumay 4y ago
> The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month. AFAIK, scrum masters are supposed to be that one that goes from person to person, looking if everything is ok, if they need help, or if they should be doing something else. That certainly is not "leading". It is indeed some kind of "managing", mostly because this word is incredibly ambiguous. It is also the problem solved by dailys, so if your dailys are useful, it means your scrum master is useless. As far as I can see, there is no reason to have both. (And I'm still doubtful about any reason to have one of them.)
- deleted 4y ago
  [deleted]
rogual 4y ago
Oh god, the Fibonacci numbers. Project planning does not get easier if you limit yourself to a number system that is not closed under addition. A strange thing to have to tell people, but here we are.
- charcircuit 4y ago
  You can make it closed under addition by defining addition to round to the nearest Fibonacci number.
  - rogual 4y ago
    You can! But as a bit of an Agile cynic, I find it quite funny that you literally have to accept that 2+2=5 to use it.
i_like_apis 4y ago
I also regularly question the value of “project” and “product” managers. However I have noticed that when that figurehead person is missing the meetings and goals quickly disassemble. In my experience the best leader of Agile or Scrum is always a lead developer, instead of a dedicated “project” or “product” person.
crazygringo 4y ago
I can't speak to C1 specifically, but scrum masters ARE useful in some scenarios, while in others they are totally useless. Where I've seen them provide huge value is in an organzation transitioning to agile, where the product manager/owner is more on the side of waterfall/sales, making unreasonable demands. The scrum master is the one who pushes back against this and "protects" the devs, and basically ensures that sprints run smoothly. Especially if you have thousands of developers transitioning to agile, hiring scrum masters that can each associate with 5-10 teams can make a huge difference. On the other hand, if you have competent PM's (or even just eng team leads) who themselves serve as the buffer between the dev team and the rest of the org (sales, VP's, etc.) and who already know how to do agile, then yes, scrum master is entirely redundant. But to be clear, leading agile isn't about reminding about Fibonacci numbers. In an inexperienced team, if one dev picks a different number, there's often peer pressure to just "change their number" instead of discussing the sources of disagreement, which is the actual purpose of planning poker. And there are a ton of situations like these where both devs and a PM might want to "play pretend" at agile rather than actually rigorously questioning requirements, negotiating better requirements with owners, and relentlessly surfacing blockers. So leading agile requires both real knowledge of the process as well as the courage to stand up against owners, groupthink and peer pressure.
- clumsysmurf 4y ago
  I worked at a company partially owned by C1. Our culture was somewhat derivative in the Agile aspect (Scrum, moving to SAFe). > The scrum master is the one who pushes back against this and "protects" the devs, and basically ensures that sprints run smoothly. That may be the ideal (of any leadership really) but our Scrum Masters reported to the PMO, which defined their agenda and financial rewards. In fact, our weekly retros were not what we could do better, but what the PMO wanted us to do differently (like report time estimated / worked on stories in Jira down to the minute).
  - FireBeyond 4y ago
    > In fact, our weekly retros were not what we could do better, but what the PMO wanted us to do differently (like report time estimated / worked on stories in Jira down to the minute). As a Product Manager, fucking yikes. I'm sorry for that horseshit.
tkiolp4 4y ago
> The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month But, are they supposed to do something else? Been in many companies, and scrum masters are the most useless role out there. Somehow, they seem to be hired for who knows what reasons. Slowly, they are becoming less popular though. Now the trend seems to be Engineer Directors (middle management between Engineering Managers and C-level executives). Total waste once again.
nicbou 4y ago
I was something like that in a previous role. I had no official title, but I was a sort of JIRA secretary. I chased people around to gather clear requirements, and cut them into understandable tickets. I babysat tickets to completion and did QA as needed. I made meetings redundant by doing the backlog grooming and requirements gathering in parallel. I chased information on behalf of developers, and made sure they didn't get stuck. I attended meetings and passed the relevant bits to devs. Basically, I kept the backlog in sync with reality, and vice versa. I was the facilitator I wish scrum masters would be. However I also met my fair share of post it fetishists who don't seem to get much done. They seem like the priests of a modern religion, bringing their tabernacle filled with coloured markers and helping us pray to the productivity gods.

abledon 4y ago

scrum master is one of the greatest grifts of 2010s-2020s tech. Esp when org chart pencils them in as 'mgmt' level so they are payed more than intermediate engineers, and on par with senior engineers

newaccount2021 4y ago
[dead]
late2part 4y ago
Why is it a great gift?
- kensan73 4y ago
  Just in case you missed it, he said 'grift' (a petty or small-scale swindle)

TulliusCicero 4y ago

> story points (some vague relationship to days of work) Watching people insist that story points are totally not representative of predicted time spent working on a thing is the funniest shit. The mental gymnastics are incredible.

lawrence19 4y ago
Story points in my experience almost always devolve into time estimates, but I don't agree they have to be the same thing (which is how I interpret your use of "representative"). They are related variables in the same way that temperature and pressure are related, but that doesn't mean they are identical. In a healthy environment, I think "story points" (horrendous name) should approximate "engineering complexity given the current state, skill set, and knowledge of the development team." Time estimates should then be derived from that number based on historical performance of the team in its current state (if you fuck with the team structure, all bets are off and historical data becomes less useful). Ideally a team should use points to do thoughtful analysis of their backlog and think of ways to manipulate scope, invest in cleaning up technical debt, and learn new skills to cheapen the engineering complexity and in turn deliver faster. In practice, what you described is almost always what happens. Stakeholders keep pressing for time estimates, so shit just keeps getting added to the backlog and engineers estimate "how long?" because they are neither encouraged nor empowered to think of it any other way.
- TulliusCicero 4y ago
  But by "complexity" people pretty much always mean "how long it'll take", so it's still time. If something was complex in an abstract way but quick to implement, it would get a small number of story points, not a large number.
  - lawrence19 4y ago
    I don't disagree with you fundamentally, but maybe one way to reframe this is around the type of conversation we're looking to prompt when we point stories. The conversation you're describing (and to be fair that I mostly have experienced as well) is a one-way, "you owe us this, how long will it take?" conversation. The conversation I'm always hoping to have, and that I've seen happen before, is a bi-directional one in which tradeoffs are discussed, priorities are constantly shifting, thoughtful investments are planned, and engineering concerns are a first-class citizen. All of this can happen if you simply consider your estimates "time" as well, but I find that conceptualizing it as "engineering complexity" helps encourage an engineering mindset among the non-developers on a team.

bastardoperator 4y ago

Agile and scrum is not a solution to anything. Participating in agile voodoo has no measurable impact. In fact, I think in many cases agile makes you immediately slower. Developers than realize they have to pad everything with bullshit estimates they pulled out of thin air so they're not getting punished for missing work or bad guesses. I just assume if the company is doing agile they have lost faith in their developers when it comes to organizing or producing value.

sanedigital 4y ago
You have been blessed to work on self-organizing and self-managing teams. When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features. Scrum isn't perfect, but its an "industry-standard" practice that we can use to get quick buy-in from client stakeholders, and then use to apply even the most basic level of process to these teams. As an engineer at Google or a freelance developer it never made much sense to me. But as a manager of remote, distributed, international teams? It makes a lot of sense.
- trentnix 4y ago
  > When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features. Sounds familiar. Back in my consultant days, we would encounter companies that wanted to be “agile”. They’d insist they were waterfall and it wasn’t working. Truth is, if they’d actually been doing waterfall they’d have been performing far better. Instead, they were just chaos, reacting to one fire after another with no plan to get out. Additionally, many teams were simply staffed with poor managers and poor engineers. There’s no consulting-fu or process-fu that was going to overcome that. You can’t win horse races with pack mules, my dad (a basketball coach) used to say.
  - ethbr0 4y ago
    >> But as a manager of remote, distributed, international teams? > You can’t win horse races with pack mules, my dad (a basketball coach) used to say. You can boil it down to saying that Scrum is either (a) micromanagement or (b) an admission that your developers and their managers suck. Fix the problem, instead of slapping a bureaucratic band-aid on that's going to attrit any remaining quality developers.

baxtr 4y ago

What’s the overall feeling towards scrum masters? In my last company, everyone outside product tech never understood their actual value. My CTO was a big fan, he said they were the glue binding the teams together or something like that. I never had a strong opinion but I’m curious to see how much controversy there was around this role.

tass 4y ago
At an old team of mine at Amazon we would assign an SDE to that role and switch it around every few months or so. They were in charge of getting the right people together for any meetings, asking for extra info to be added to any backlog items, and telling teams when we were planning to deprioritise or drop the backlog items they asked for. It worked pretty well for us, and took maybe a day of time per week
- morelisp 4y ago
  > we would assign an SDE to that role and switch it around every few months or so... took maybe a day of time per week The problem is if you are having a struggling team, it takes a lot more of a day of time and requires a lot more maturity than just leaving jira comments and sending meeting invites. But if you put your devs who are good at structuring problems/time on it, now they're participating in the actual development less, so the team gets even less functional (at best temporarily, at worst you're now in a death spiral). Furthermore if the root problem is not really the organizing but more fundamental (poor skills / skill alignment, understaffing, chaos agent, etc) the singular dev will rarely have the ability to deal with it and can even start drawing animosity. Having a separate person responsible for this, in a different hierarchy with different ears, can be a lot more effective in these situations. (It can also make it worse, if the separate person is also shit at their job, has too much work, has very different attitudes towards work than the rest of the team, ...) tl;dr: If your team is functional pretty much anything will work, these structures also need to be judged by how well they can get it back on track from non-functional.
ecshafer 4y ago
I don't see the point of scrum masters personally. They create more work if anything and mostly act as a cargo cult leader. A manager, a tech lead / staff developer, product manager... the other tech leadership positions on a team i see immediate value. Scrum Masters I do not and never have seen their use.

trentnix 4y ago

> The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month. I put leading in quotes because there’s only so much leading one can do if everyone else knows more about the product due to the inherent transitory nature of the scrum master role. 100% I interviewed with a company (not C1) earlier this year that had one of those “every team has a manager, every team has a scrum master” bits going on. I asked multiple times what the difference between the roles were, and couldn’t make sense of any of the answers I got (which were full of consultant-speak). I declined to move forward. Like anything, I’m sure there are teams out there with this situation that make it work. But it sounds to me like a recipe for confusion, conflict, and atrophy.

ashconnor 4y ago

Also used to work for C1. You're right in the sense that the role was always awkwardly jammed into teams often when it didn't make sense. Some were pretty good but most were of the certificate-chasing type that had bought into the commercialization (bastardization) of Agile. Give C1 their due though. They dragged the entire company into AWS, mostly, which is something I don't think any other bank that's been around as long as they have has done.

victor106 4y ago
> They dragged the entire company into AWS, And why/how is that a good thing?
- Throw10987 4y ago
  I think if you rephrase it that they "dragged the whole company out of the particular IT hell that is associated with banks owning, running and procuring infrastructure" it probably makes more sense.
- noisenotsignal 4y ago
  I interned there a couple years ago. It was nice to use tech that was more standardized than proprietary / internal so that the skills were easily transferable. From a business perspective it takes you out of the business of managing your own infrastructure. Even at big tech now we have to decide between managing our own infrastructure and “outsourcing” it to a managed service. Most advice I’ve gotten encourages the latter. It can cost more but if cost isn’t prohibitive it frees you up to deliver features and value for customers because you no longer have to develop (as much) expertise in ops.
  - victor106 4y ago
    I get that and that is the selling point of the cloud and it makes total sense for some workloads like ML/Data Science. However, once you move the companies infra to AWS (or any one cloud provider) and shutdown your infra, in due course AWS will keep increasing your price by x% every year. At the point you don't have a choice but to pay those price increases yoy. You have much less bargaining power. I think hybrid cloud is the best way to go. You have lot of bargaining power and no one provider can hold you hostage.

marcosdumay 4y ago

> The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month. AFAIK, scrum masters are supposed to be that one that goes from person to person, looking if everything is ok, if they need help, or if they should be doing something else. That certainly is not "leading". It is indeed some kind of "managing", mostly because this word is incredibly ambiguous. It is also the problem solved by dailys, so if your dailys are useful, it means your scrum master is useless. As far as I can see, there is no reason to have both. (And I'm still doubtful about any reason to have one of them.)

deleted 4y ago
[deleted]

rogual 4y ago

Oh god, the Fibonacci numbers. Project planning does not get easier if you limit yourself to a number system that is not closed under addition. A strange thing to have to tell people, but here we are.

charcircuit 4y ago
You can make it closed under addition by defining addition to round to the nearest Fibonacci number.
- rogual 4y ago
  You can! But as a bit of an Agile cynic, I find it quite funny that you literally have to accept that 2+2=5 to use it.

i_like_apis 4y ago

I also regularly question the value of “project” and “product” managers. However I have noticed that when that figurehead person is missing the meetings and goals quickly disassemble. In my experience the best leader of Agile or Scrum is always a lead developer, instead of a dedicated “project” or “product” person.

crazygringo 4y ago

I can't speak to C1 specifically, but scrum masters ARE useful in some scenarios, while in others they are totally useless. Where I've seen them provide huge value is in an organzation transitioning to agile, where the product manager/owner is more on the side of waterfall/sales, making unreasonable demands. The scrum master is the one who pushes back against this and "protects" the devs, and basically ensures that sprints run smoothly. Especially if you have thousands of developers transitioning to agile, hiring scrum masters that can each associate with 5-10 teams can make a huge difference. On the other hand, if you have competent PM's (or even just eng team leads) who themselves serve as the buffer between the dev team and the rest of the org (sales, VP's, etc.) and who already know how to do agile, then yes, scrum master is entirely redundant. But to be clear, leading agile isn't about reminding about Fibonacci numbers. In an inexperienced team, if one dev picks a different number, there's often peer pressure to just "change their number" instead of discussing the sources of disagreement, which is the actual purpose of planning poker. And there are a ton of situations like these where both devs and a PM might want to "play pretend" at agile rather than actually rigorously questioning requirements, negotiating better requirements with owners, and relentlessly surfacing blockers. So leading agile requires both real knowledge of the process as well as the courage to stand up against owners, groupthink and peer pressure.

clumsysmurf 4y ago
I worked at a company partially owned by C1. Our culture was somewhat derivative in the Agile aspect (Scrum, moving to SAFe). > The scrum master is the one who pushes back against this and "protects" the devs, and basically ensures that sprints run smoothly. That may be the ideal (of any leadership really) but our Scrum Masters reported to the PMO, which defined their agenda and financial rewards. In fact, our weekly retros were not what we could do better, but what the PMO wanted us to do differently (like report time estimated / worked on stories in Jira down to the minute).
- FireBeyond 4y ago
  > In fact, our weekly retros were not what we could do better, but what the PMO wanted us to do differently (like report time estimated / worked on stories in Jira down to the minute). As a Product Manager, fucking yikes. I'm sorry for that horseshit.

tkiolp4 4y ago

> The only time I saw scrum masters really do anything was “leading” standup and “leading” planning meetings every other month But, are they supposed to do something else? Been in many companies, and scrum masters are the most useless role out there. Somehow, they seem to be hired for who knows what reasons. Slowly, they are becoming less popular though. Now the trend seems to be Engineer Directors (middle management between Engineering Managers and C-level executives). Total waste once again.

nicbou 4y ago

I was something like that in a previous role. I had no official title, but I was a sort of JIRA secretary. I chased people around to gather clear requirements, and cut them into understandable tickets. I babysat tickets to completion and did QA as needed. I made meetings redundant by doing the backlog grooming and requirements gathering in parallel. I chased information on behalf of developers, and made sure they didn't get stuck. I attended meetings and passed the relevant bits to devs. Basically, I kept the backlog in sync with reality, and vice versa. I was the facilitator I wish scrum masters would be. However I also met my fair share of post it fetishists who don't seem to get much done. They seem like the priests of a modern religion, bringing their tabernacle filled with coloured markers and helping us pray to the productivity gods.