54

Three months ago I started a role at a new company as a software engineer. Within two months, I helped onboard the team to a lot of contemporary best practices. They didn't do proper source control, had zero testing, didn't have much cloud experience, and built projects in a pretty dated way. Note that I was never a zealot on "best practices" - I was simply asked if I knew how to do "such-and-such" and helped lead the team along the way.

While I'd argue that I'm a senior (I can build, deploy, and maintain a project from start to finish) and feel comfortable managing a team, I definitely have a lot to learn and am not ready to be the lead architect (nor am I paid with a title to reflect that). Either way, this is essentially the role I adopted as I was made the "lead developer" of a new, highly critical project.

The first sprint of this project didn't go well. I underestimated how long it would take to get this brand new program off the ground because I was operating under the following assumptions:

  1. The learning curve time was estimated into the sprint.
  2. I wouldn't be managing the team.
  3. I wouldn't be tapped by the DevOps specialist as a resource on how to do a CI/CD pipeline.
  4. I would be able to tap the senior developers (with 3-4 times my experience).

These turned out to be false assumptions. The critical failure here is that the senior developers help was, "I don’t remember how I did this, but here's a poorly written application we did two years ago that does it." TL;DR they didn't provide guidance on things they claimed they had done and I had to learn it without their assistance.

All of that is fine. What is not fine is that after a single failed sprint, the director of the company expressed frustrations and now wants the project manager to have daily check-ins with me and me alone to see if I specifically "have any blockers".

I feel extremely insulted after all of the hard work I've done and how much I've helped improve the teams' practices, knowledge of cloud and software design, and how I stepped up into a lead developer and mentor role without requesting a title or salary change. Am I overreacting? How can I communicate that I'm not okay with this?

5
  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Jun 13 at 3:30
  • 9
    @ffigari I love it nonetheless. Good on you OP. Jun 13 at 21:36
  • 1
    yeah, nicholaswmin, I love it too. Was not looking to disagree. Struggled with lack of management in the past too, it's really a hell. But I think it's also an inevitable hell one has to walk through at some point as a developer
    – ffigari
    Jun 14 at 0:40
  • without knowing exactly what the meetings would be about, there is no reason to be insulted or offended. Most likely they want your input about potential problems with the product, and they trust you enough to provide that information.
    – jwenting
    Jun 14 at 11:21
  • Speaking very generally, when you step into higher roles, you spend a lot more time in meetings with people higher up, and have to answer for things that went wrong because of other people. Some devs swear they will never go into management for that reason. This could be a test.
    – Kaz
    Jun 14 at 16:08

11 Answers 11

124

While this is a counterproductive step as framed, it’s more effective to lean into it than fight it. You admit to a litany of errors in the first sprint, so responsible management has to look more closely into the situation somehow even if this isn't the way you'd prefer. This is an opportunity to align better with expectations and make a good impression after an initial misstep, part of a practice known as "managing up" (managing your management) that will serve you well in your career.

The two key tenets of “managing up” are

  1. Remember higher level people don’t know all the details and frankly they don’t care
  2. Your goal is to get the higher level people what they want - success (details of exactly what that looks like vary per boss).

You are the lead developer, so assume the checking for blockers isn’t really about you personally but about the overall progress. Be open and helpful with the PM and they’ll see you are good and highly skilled and become an advocate for you. Use the check in to get more information about the PM and director’s goals and expectations- this is an important informational resource for you.

Any sort of “telling them I’m not OK with this” is a career limiting move. Use the opportunity given here to make an ally and build your reputation in the company.

3
  • 30
    I would add that the OP did encounter obstacles and probably did not raise them until it was too late. This is the stated reason for the meetings (and possibly the real one as well).
    – Rad80
    Jun 14 at 6:49
  • 9
    If OP expected help and didn't get it, then asking for info about blockers could be a (poorly worded) offer of assistance to make sure the help happens. If it wasn't, the daily check-ins could be an opportunity to get that assistance anyways. Jun 14 at 15:01
  • @Rad80 Within a single sprint you cannot adapt. You have to adjust for the upcoming sprint (reduce velocity) and / or the next estimation meeting.
    – usr1234567
    Jun 17 at 20:39
76

Agree with the answer suggesting you turn this obnoxious requirement to your own advantage. They want to be told what your blockers are? Tell them your blockers.

  • "We're falling behind the schedule because we're not receiving the support anticipated from the seniors."
  • "We're short of resources for this project because DevOps is making additional demands on my time for unrelated efforts. How would you like me to rank these priorities?"
  • "The lack of a proper team lead is really holding the project back."

That way there can be no miscommunication about what's going on and what the likely result will be. The success of this project is not yours to worry about - that's not your job. The success of the project is for your employer to pursue, and you are one tool among many that they will deploy in that effort.

11
  • 5
    To add to this answer I'd say that, every morning, after the verbal meeting, you also send the manager an email detailing all the "blockers' you accounted for. You also BCC those emails to an email server outside the company's control! As managers go, he'll probably not respond to those emails: those are your problems to solve, right?! (Of course not, but that's his mindset. He's a manager, he "manages"). Keep the ePaper trail well documented. I've had my share of these bosses... it'll not end pretty for you, no matter what you do. Be prepared! Jun 12 at 8:08
  • 55
    @TheonethatlovesFP sending company emails to an outside server may be illegal. and not all managers are incompetent or evil.
    – obe
    Jun 12 at 8:45
  • 2
    Yeah, if you’re going to keep emails. Do it in a way that can’t be traced. Personally, I save them onto a USB.
    – Kaz
    Jun 12 at 19:51
  • 2
    @TheonethatlovesFP i agree that documenting stuff that happens is good (also in life with various "third parties", not just at work). i'm not a lawyer, and anyway the laws may differ depending on territory and even company policy, but i believe there is a different between sending company material to an outside entity (i.e. an outside server), and keeping a safe, local copy.
    – obe
    Jun 13 at 10:13
  • 2
    The success of the project is your fault if, without any other unforeseen circumstances, your demands were met and yet still you failed. Don't put me in charge; I will tell you where every pea under every bed is.
    – Mazura
    Jun 13 at 19:09
49

I'll take a bit of a different answer: this isn't necessarily something you should worry about.

Let me give you an example why. Our company is working on a critical business project. And the group I'm in is one of the critical teams on that project, with a good possibility that we're on the critical path of the project - in other words, if our area gets delayed 1 week, then the whole project might be delayed 1 week. And my coworker is on the critical path of our part of the project.

My coworker is awesome. Nobody has any complains about his work - he's an all-star. But you can bet that, every day, he's asked if there are any things blocking him from development on the project. Because from the company's perspective, every hour of lost productivity from him is an extra hour late the project's going to be.

In other words: upper management wanting to check in with you regularly about blockers might not have anything to do with your performance; it might be them wanting to proactively monitor the CriticalPath/LimitingResource of the process and make sure everything is going smoothly.

1
  • 19
    +1, my initial thought was also that this sounds like extra support for valuable workforce (no matter how critical the project is). OP should be honored, not horrified.
    – Namoshek
    Jun 12 at 17:10
11

Forget about the insult, you may have a larger problem or a great opportunity.

Virtually nothing in the workplace is intended to be rude, so taking it that way is not a reasonable thing to do. Yes, there are certainly jerks, but their motivations are rarely "I want to be a jerk today", so interpreting this that way gets you nowhere.

You need to figure out why management wants these things. Is there a genuine attempt to help being made and just offered (and thus a great opportunity) or is there just a need for someone to blame? Management's history will inform which way you lean on this, but people who are "frustrated" tend not to like you.

I would flip on #opentowork on LinkedIn in your position, but I am assuming that management is looking for a head.

2
  • 1
    This feels like a good chance of total overrraction. Nothing in the OP says to me that a sacrificial head is being sought. They have a problem, their expectations weren't met, and its frustrating them, and they don't know what to do to get it solved. So they are micromanaging a bit to get hands on and move it along.. That's what it feels like.
    – Stilez
    Jun 14 at 13:21
  • @Stilez Exactly my thoughts as well. That's exactly what my manager is currently doing. He noticed things weren't going as smoothly as expected, so he's stepping in to make sure things get back on track. It's nothing personal, but just him doing his job.
    – Dnomyar96
    Jun 15 at 5:58
8

I'm surprised that you aren't already checking in on a daily basis with the whole team to see if there are any blockers. I believe there's a methodology widely used in the software industry called Agile.

One of the ceremonies which takes place in Agile is called the daily stand-up which normally runs for about 15 minutes. This is where the whole team meets to discuss what they're working on and to call out any blockers.

Google it and mention it to your director and project manager. So instead of just checking in with you, they can join the whole team to discuss the current work in progress and identify any blockers before they become impediments.

Also check out the The Joel Test, I would never work for a company that didn't answer yes to at least 10 of these questions.

4
  • 6
    Agile isn't really a methodology as much as it is a mindset, and the "daily standup" is actually the "daily scrum" which comes from the Scrum framework specifically. Also the daily scrum is not meant to be joined by a director or project manager.
    – Erik
    Jun 12 at 6:19
  • @Erik True, it should be just for the team, but I'm happy to invite others along if it helps communication. Mixing Agile and project management e.g. Prince2 is always painful, having a daily stand-up/scrum and then reporting back to a project manager is just painful. RAG status report anyone? Yuck, let them do Prince2 and they can fill out there own reports with what they gather at the stand-up/scrum, bring them along for ride rather than getting dragged into their methodology.
    – user122949
    Jun 12 at 8:42
  • @JonathanArcher "Mixing Agile and project management e.g. Prince2 is always painful" There are courses designed explicitly for teaching you how to do that (usually with DSDM as the Agile methodology in question).
    – nick012000
    Jun 12 at 9:19
  • @nick012000 yes I have seen a couple of them, Prince2 has one in it's track axelos.com/certifications/prince2-agile/…, although I've never done it. I am certified Prince2 Foundation, I also have a couple of Agile certifications too. Although I learnt quite a lot from Prince2 I think it's a poor choice for software projects and causes friction when program management tries to project manage an Agile team.
    – user122949
    Jun 12 at 20:09
7

This is a great opportunity: Make the project manager your resource!

Call out the blockers to the project manager and give him responsibility to get them unblocked. That's actually a large part of his role.

For example, if the "senior" developers are not being helpful, make it his job to adjust their attitude.

4

Force them to check in with you daily

Make your demands during the daily check-ins. Keep repeating them.

A bit tongue-in-cheek, but as others have said, if you turn this around in your head to think of it, this may be helpful. Most jobs suck because we can't talk to people in a position of power who can change them. Luckily for you, you are in a different situation. Use the power given to you.

Wait a few days and weeks before become demanding though - you need to build the relationship first and mention things gently initially. General folks trust others once they've seen work and honesty over time.

Of course you don't actually communicate this (the headline) to anyone. Just you.

Note for the future - initiate this process yourself. Be managed or manage them. Your choice.

1

Let me break this down into two different issues: your feelings about being asked to do the daily check in, and how you react to that request.

Your feelings are. Feelings are morally neutral. They are connected to who you are. Thus, feeling that you are being singled out is a valid feeling.

However, what to do about this situation is a totally different issue.

You state that the first project wound up surprising the management by not meeting the expected delivery date. The goal in "managing up" has to be to not surprise the manager. Let them know day by day the issues that you are facing and what they need to know to keep you at high productivity. Also, this is a very good way to let them know about assumptions that were wrong and change the "sprint" as soon as possible (or let them take management action in regards to others).

In other words, management does not want to be surprised by you any more. Now, how to do that in a way that fits your character and style is something you need to figure out (using any suggestions from others).

At the last gig, I voluntarily started emailing daily status reports at the end of the day with what I had accomplished and any notes that I wanted my manager to know about. That practice was very helpful in continuing the gig. I found it better to do the status at the end of the day while I still remembered everything. Your experience might be different.

1

It's a little unorthodox that they want to meet with you and you alone rather than have the PO, your Scrum master, you, and your team in a daily meeting routine. This is how things are done in Lean teams and SCRUM methodologies. It's known as a daily scrum, but scrum masters aren't required to attend.

You may want to investigate if there's a way to transform their daily checkins into a SCRUM with your team present, vocal, and immediately cognizant of your PO's / customers' needs in terms of functionality, design robustness, feature priorities, and project timeline. This way, all of your teammates can directly tell you and the PO of any impediments, and there's full transparency across the management stack about who's accomplished what.

Also, if this is the direction your PO/managers want to go, you might ask them to provide your team with licenses to a scrum software tool so that everyone can have RT information about which weekly goals have been accomplished, and which ones are experiencing challenges. In fact, you could even go all-in and request that there's a weekly or bimonthly planning meeting for each 1-week or 2-week sprint. This is normal for scrum. See if they agree or falter on these requests.

1

I wouldn't take this as an insult at all. If they had a serious issue, they wouldn't be offering this, they'd be giving something like a "performance improvement plan," or you might even just be laid off given how new you are.

If they're at all aware of the issues you were having, they're probably just giving you exactly what you need. And even if they weren't, if upper management is aware of the kinds of blockers that can hit software projects, this is a good bet to fix the problem - not because of any shortcomings you have, but because it lets someone above you get the information needed to do what good managers do: get obstacles out of your way so you can do your job more effectively.

Example: if you had this in the first sprint, you could have mentioned that other senior developers weren't giving the required support. The PM could then step in and do something like contact their PMs to reshuffle their sprints around to make time for giving you support (i.e. budget it into the sprint), maybe even assigning it as a ticket. Your problem would have been quickly resolved in that case, if the PM knows what they're doing.

The fact that the PM is meeting with you and you alone actually indicates that you're being provided a resource, not a subtle punishment (IME workplaces rarely do this, and don't go about it this way), because if one of your blockers is a team member below you, it would be more difficult to express it if the whole team were present. In fact, the "managers meeting" is a hallmark of treated someone as management-adjacent rather than just a developer. If they saw you as a problem, they wouldn't waste such a valuable resource in this way. I wouldn't be surprised if upper management had knowledge of your massive early contributions, saw you missed your first sprint goals, and immediately reacted by assumed you were being blocked by external forces, and thus that someone who can alleviate them for you should be assigned.

Maybe it could have been worded or presented better, but at a glance it looks like that's what's going on here.

2
  • 1
    And whether it was intended that way or not, the important thing is that OP now not only has the ear of someone who can make changes, but guaranteed time on that person's schedule.
    – Ben Voigt
    Jun 14 at 20:12
  • @BenVoigt Yep. And for that exact reason, it actually wouldn't have been a bad idea for OP to request this resource if it weren't already being provided. Jun 14 at 21:03
-1

I would consider myself to have essentially been put on a PIP, and unless I had some stock options or something, would just resign and find new job.

The job market for experienced devs is white hot right now where I am, so I would just spend the weekend submitting job applications and then call in sick forever until they fired me. Wring an extra week of salary out of them.

2
  • 3
    Two out of the four reasons he gave were blockers. Now management wants to help him no longer be blocked. I don't see a problem with this. Sometimes having a Director or a Manager in your corner is exactly what you need when you need the cooperation of others who are more senior than you. Jun 13 at 6:06
  • 2
    PIP = "performance improvement plan" Jun 13 at 16:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .