Coming Clean

In response to the following blog posts regarding management in Agile processes:

Managers Are Grown-ups, too

Can Managers Lead Agile Teams?

I absolutely agree with the premise that one of the reasons Agile works well (when it works) is because it allows the engineers to indiscreetly yet directly and intelligently control and mitigate a manager’s influence – what has failed to be recognized / admitted by the Agile community is that this just inevitably builds new ways (well, not really) to fail (e.g. all the Agile attempts that fail due to mismanagement because the engineers have no better management chops than their managers). It’s about time Agile communities started to address this problem of what really ought to happen to traditional managers and how to inspect, adapt, and improve on the managerial side of the house.

Many managers and management teams use Agile as an excuse to lose cognizance about the what, why, how, and who of the activity of their team. All they feel responsible for under Agile is knowing when things will be done and a summary of the what’s, who’s, and maybe why’s of development activity. This attitude seems to accompany a lack of interest and knowledge regarding the personal interests and motivations of team members and a disconnect with the fact that these concerns are central to their role – that, as managers, they need to be proactive in learning and discerning them.

From the articles, this doesn’t appear to be particularly uncommon in Agile. Either (1) organizations don’t adopt Agile because they see managerial circumvention as inevitable or (2) Agile fails because the necessary leadership doesn’t emerge as is suppose to happen and/or should already be present in existing management.

Either way, if a manager’s primary concern is not his employees and their satisfaction, he is doomed to failure. Employee satisfaction and budget/schedule do not have to be opposing forces. In fact, with a good balance that emphasizes that employees matter first while not excusing poor performance, a manager should find that he gets more bang for his buck out of his employees because they remain retained/loyal, interested, and self-motivated to perform and improve.

Agile is good at evoking these traits within engineers precisely because it puts engineers at the center of the concern of their work. Personally, I suspect the leading reason while Agile is all the rage these days is because older, more standard processes have become more about the bureaucratic machinations of human resources, schedules, man-power allocation, and budgets rather than keeping talented employees happy and involved beyond that of being mere cogs in the work that they are about.

Management is high-level mentoring. As a manager, you must invest yourself and your time in your people and their work; otherwise, your people won’t invest the best of themselves and their time in you and your work. For them, work will be just a timeout from their real life until they can find a better gig.

When I first took a job with LMCO, it was up in DC, and what I remember the most is a distinct lack of stuff to do. While I was hired to write and maintain software, it was really a job in avoiding insanity by finding something – anything – to occupy your time that wouldn’t get you in trouble. Thus I found myself doing a lot of wandering and talking. When that got old, I taunted a beta fish that we had put in a giant plastic bear container that once housed a ridiculous number of animal crackers. But perhaps most exciting: I, along with my co-workers, became an uncanny slinger of rubber bands.

The rubber bands really were a true source of pride. I could hit someone two cubes away by aiming via the reflections off the sprinklers. When you have as much time to stare at them as we did, you can actually figure both the position and the identity of the source of the sprinklers’ reflections. In fact, though he could never prove it, I shot my manager over a cube wall after he came in to tell us to cut it out.

Probably the worst offense, though, was the shooting of the Potted Plant. The Potted Plant was brought in by an engineer who had long since left by the time I had arrived. We gave it water maybe once a month, and, by genetics that we are apt to feel impossible, it has survived to this very day. To top it off, the Potted Plant has survived many a marksman’s attempts at bringing it down.

So, when one day a particular engineer actually managed to take a leaf off the Potted Plant, I took umbrage. Or rather, the Potted Plant took umbrage. And after everyone had long gone home for the day, the Potted Plant exacted its revenge by stringing up the engineer’s favorite stuffed green Frog. He left a little note scribbled in dirt reading “Don’t Let This Happen to You”, signed with a wilted leaf tucked into a rip in the paper.

Unfortunately, I cannot provide a report on the engineer’s initial response when he found his dear Frog near death the next morning. However, I can report that by the time I arrived, the Frog had made his way to my coffee cup, whereupon he was sitting and reading what looked like a newspaper. As I arrived at my cube for the morning, the engineer reached across and gave a tug on a draw-string in the Frog, at which the Frog began to vibrate.

After a good 10 minutes of hearty laughter, I went and washed out my cup. It wasn’t that I didn’t trust the Frog – but I wouldn’t put anything past an engineer. After that, we moved the Potted Plant and the Frog into opposite corners of the cube for fear of future engagements and/or retributions; however, I have heard that a Cold War replete with espionage and sabotage has continued between the factions of the Frog and Potted Plant ever since.

… is yet another scripting language.

Why?!

Mostly because that’s what my boss says.

So, what’s going to be cool about this new language? Honestly, I’m not sure – but this is what we’re shooting for:
- extensible syntax
- extensible graphical editor (so people won’t have to be mindful of syntax)
- extensible run-time (to support extensible syntax)

This is most definitely going to be a niche thing. It’s geared to get non-programmers programming the basic flow control and information design that they are already responsible for on a daily basis. I work for a call service after all – this is what they do.

One nice carrot on this thing is that after deployment and 6 months to a year of solid running, I can release it open source.


interface Foo
{
}
interface Bar : Foo /* Bar is a Foo */
{
}
interface A
{
Foo getFoo();
}
interface B : A /* B is an A */
{
Bar getFoo(); /* C# thinks this is a bad thing */
}


Somehow or another I have landed myself on a committee to define requirements and select a tool for capturing process metrics. Even though the email was all spiffy inviting me to participate, I knew there was a background watermark of “Abandon all hope ye who enter here”. I should have given heed to the sign.

So now here I am, in a group of process and metrics weenies. As far as I can tell, I’m the lone real software engineer – though I think there is a person or two from a software background or who has dabbled as part of a software team (they give me some amount of sympathy).

I’m somewhat ambivalent to the whole thing, and I know it shows. But it’s not that I’m not interested – it’s just that I’m not interested in how they want to proceed. When I start saying things like “If you want to capture metrics, then give engineers a tool that politely and humanely lets them go through the process like engineers who are actually doing their job, and then glean/scrape your metrics out of that,” I get a lot of forlorn and exasperated looks. The unspoken response is: “Sure, that’d be great … but there’s nothing like that out there, and we’re talking about a lot more than just code reviews here.” And, of course, the underlying truth of it all is that this isn’t about process or process improvement – this an exercise of CYA vis-a-vis metrics collection.

And the whole “this isn’t just for code reviews” is really what makes all of this the most intolerable for me. We’re gathering metrics for defects found in different artifacts at different project phases. So, while something like Review Board would be abso-frickin-lutely awesome for me … it’s inappropriate (at least in the minds of the powers that be of this group) for the breadth of scope of this committee’s task. Suggesting that we use the right tool for the right project phase is probably going to be lost on them: “But, we’re collecting the same kind of data regardless of the phase!!” … nevermind that the process of which the data is generated differs between phases.

I need to refine my issue with that last bit there – that’s where I’m continually dismissed in this little piece of non-fun-ness I’m involved in. Any thoughts on the issue would be appreciated

This week was a good week, and I was expecting it to go bad.

I’ve been in the role of software lead engineer for about 6 months now. For the first 3 months, I was leading a 4 man team, and then I was promoted to oversee a 12 man team. This was problematic because I had assumed a large chunk of the 4 man team development responsibility, and finding myself responsible for the care and feeding of 12 individuals pretty much put me behind.

The 4 man team has a software release at the end of June. The other 8 engineers had completed a release of software a month ago. So, for the past month, I’ve been desperately trying to get the 4 man team back on schedule, while making sure the other 8 guys are busy – busy with the right things, mind you.

This last week was a big week. It was the week I had earmarked as IOC – Initial Operational Capability. Basically, this was the week to go alpha. And we hadn’t begun to wed our back-end development and front-end development.

And yet, things went according to my best hopes and plans. It’s basically attributed to the fact that (A) I design API specifications which are pluggable and thus implemented separately from and in accordance to that API and (B) the developer responsible for the gui was conscious of the fact that he only had two responsibilities: (1) implement the gui per the interaction design and (2) implement the gui such that its interactions are meant to interact with my API design.

I cannot speak highly enough of the developer who worked the GUI. He’s a new hire straight out of college, and he’s easily the best college hire I have seen since I was hired. There’s a good chance he’s better than me, but only time will tell. I hope to get him some fat cash in reward for his awesome contribution.

Tuesday we did the initial wedding of GUI to implemented back-end. It was buggy, but it was working. I felt like we were still walking on that knife’s edge – things either go to plan … or not and badly not.

Today, we have a solid and consistently running implementation of all deliverable capabilities, with only a few lingering interaction details. Now, we have a month’s worth of bug finding and – I suspect – just a ton of polishing.

This has me very excited because it’s validation of everything I have said for the past 3 years. It basically took me getting into this lead position to make this happen, and it just feels awesome to say “see?? isn’t this awesome?? This is how it should happen – this is what we should be delivering.”

The doubter in me says that my lead will not see this accomplishment for what it is. And I just don’t know what I will do if he won’t give me the validation I feel I have earned.

But go team, go! It wouldn’t have happened without them. They all performed to their ability – and we found a number of folks have skills we were not yet aware of. I hope this is just a sign of things to come – designing right, implementing right, and leaving enough schedule fat to really get things tested before release.

Once upon a time, I was a software engineer. Then someone said, “Spencer, you’re a very good software engineer. You grok our vision, you produce well designed code that aspires to and can grow into as well as beyond our vision, and you have a knack for working with the other engineers (though your relationship with your managers could improve). How would you feel about leading design and development efforts for our team?”

And I said, “Aw shucks,” and so my downwards spiral into management began.

At first all was well. I had a 3 man sub-team and my co-lead had a 4 man sub-team. My sub-team was kicking butt and taking names. I was doing mostly design, code reviews, and mentoring. I could have done with some more coding work – but I always manage to sneak in some significant chunks in under design work. But we were mostly hitting our milestones, and I saw no reason to fear. If worse came to worse, I could step in on a weekend and get us back on schedule – but I wanted these guys to do it largely by themselves. Good for morale and growth all the way around.

And then it was deemed that my co-lead, who also had a high-level architect hat, needed to wear only one hat, and so he passed his software lead hat to me. And so it came to pass that I was the one software lead to rule them all.

It’s at this point that my downwards spiral into management hell began.

I knew I had to schedule a lot of meetings to figure out where my co-lead was leaving off, where I was picking up, and where the progress of his sub-team was really at. And all the sunshine and happy flowers that I had been hearing about started to wilt and die before my eyes.

I basically picked up 2 very needy non-engineers, realized that my co-lead really wasn’t on top of requirements, design, or implementation progress, and that we needed to cut a bunch of features and rework the other half. Oh, and make sure the entire thing was REALLY being tested.

As petals wilted and flowers died, I flowed the needed scheduling information up the management chain. This, of course, caused new meetings which caused new meetings which caused new meetings which … well, you get the idea. Forget engineering (outside of dealing with my 2 very needy non-engineers). I’m just doing scheduling, tasking, and status … with a good dose of requirements analysis, requirements rejection, and a bit of upper-management scolding (most people think I’m insane because I’ll scold my management – I tell them what it is they have done, should have done, and should be doing – and why I shouldn’t be doing any of it … but the way I see it, if I get fired (and no one is ever really fired), it’s probably because things got to a point where I really am better off leaving anyways).

Ok, ok … it’s not all bad. Really, I’m enjoying it mostly. I just want to get back to the engineering side of things. But I have to fight, for the success of this project, this titanic management battle to get all that is screwed up with our engineering process and management turned around.

It seems that since I’m the only one who doesn’t mind expressing a very solid, actionable opinion, I get delegated with all the managerial crap that everyone else should be doing. What features do we need for our next release (you should be asking the architect)? What support do those features need (again, the architect)? Are we sure we’ve done a top to bottom analysis (I don’t mind helping out, but does the architect have an initial blueprint)? Do we have a tasking breakdown (if we have a top to bottom analysis, then yes)? Do we have initial tasking assignments (sure, I can do that)? Do we have estimate sizes per task and engineer (I can do that too)? Hoooooo crap, why am I doing this?! My part should be small, but I feel like I’m doing it all. I feel like I should be providing data, not doing the friggin’ work. (But the work is that data, they say, so either we’re data entry peons or you do all of it – managers don’t like being peons – and you’re the only one who really knows the data top to bottom)

Anyhow … this is a very long post to say: Sorry I’ve not been around much. Hope things change soon, but I’d expect radio silence to linger on for a while yet. If you want to mail me beer or wine (or money for either), I’ll appreciate it.

So I have been reading Managing Humans and Rands in Repose the past week. Rands makes me feel less like a jerk and more like a guy with legitimate managerial issues.

I was talking with my old boss (now like 1 or 2 levels of management over me) about the book and just some of the stuff I’ve been reading, how I felt kind of validated in freaking out, the lessons a manager should learn in any and all freak outs, and just some of the communication problems I see in our group. He looks at me and dead pans, “It can’t be a very good book then.” I really love my old boss. He gets it.

Today, I decided that my current project manager is a coward. His first line of status is email and IM. No phone. Not unless the poop is about to hit the fan, and he needs the “took personal time with employee” checkbox checked.

This afternoon I got an IM wherein he was checking status on a particular project. This came up just after I had replied to an email he had sent relaying that our intern, who is not very capable and is increasingly less reliable, bailed out of a week of work – the week where we were trying to get him spun up on a special project. This whole situation has begged the question of who should my manager be talking to with regards to what’s going on in the project, what’s our personnel situation, etc. As far as I’m concern, with no disrespect to my teammates, it should be me.

So I picked up the phone and called him.

Mgr: “So you want to talk?”
Me: “Yeah, more than just status. We’ve got a few things we need to talk about them and now is as good as any.”
Mgr: “We’re not going to talk about those things.”
Me: “Yes we are, after the status report.”
Mgr: “No we’re not.”
Me: “Yes, we are.”
Mgr: “No, I’m not on a private line.”
Me: “What do you mean private line? Why do we need a private line?”
Mgr: “Because we can’t talk about personnel.”
Me: “Well, if we talk about personnel, it will be because you make it an issue. I want to talk about higher level stuff.”
Mgr: “Oh …”

Yeah, see … when we talk, this is the way it always goes. He thinks he has a handle on the situation, but he doesn’t.

Skip forward to after status

Me: “Look, our process, my understanding was that you put so-so in a position for moderating process – not for technical control or personnel issues. I thought that was left to the team lead.”
Mgr: “It is.”
Me: “Well, then why are you talking to so-so about our technical status and personnel issues? And why are you giving so-so crap about the decisions I made the call on?”
Mgr: “Well, I didn’t realize you made the call. I thought there was team consensus.”
Me: “There was team consensus by my sheer force of will and the absence of project management. I said I’d take the fall. Everyone’s backing the decision now it seems.”

At this point, my manager begins a series of excuse making wherein we start talking about what he explicitly outlined he didn’t want to talk about. And in the process, he all but says that the hub-bub he’s created here in not letting the team manage itself has been wasted effort – he’s back to where we started. Skip a few minutes …

Me: “Mgr-person, do you want me on the project?”
Mgr: stunned silence
Me: “It’s just a question. But every time I have to work with you, it’s a fight. I don’t get it.”
Mgr: “Well, just because you don’t get what you want …”
Me: “What I want? I mean, I’m opinionated and strong wilked, sure, but when have I been wrong? I mean specifically, when?!” (hubris, it’s bad … but I do have a solid track record at the moment)
Mgr: “Look, I don’t know why we’re talking about this … how this happened. We’re both frustrated. So lets take a breather and talk about this later.”
Me: “Fine, we can do that.”
Mgr: “Just schedule a meeting …”
Me: “No, you schedule the meeting. If you want me on the project, show that you care and make the time.”
Mgr: “Fine”

By the time I left a few hours later, still no meeting notice. He did try to hit me up for another phone conversation (via IM instead of just, you know, calling me). We’ll see where we get tomorrow … but I’m ready to check out, and I’m making contingency plans for those I’m going to be leaving behind. Couple with my possible departure with the imminent departure of our resident senior free electron, and my project is pretty much screwed.

So … one of the big jokes amongst the developers is my constant scheming to “pull one over” on management. Generally there is something that we know they (irrationally) will not want but is in the best interest of pretty much everyone else. Every now and then, I also host a game of “dream team org chart”.

Today, though, I think I hit a real resonating chord with the senior developer. He’s da’ man on the project. I’m pretty good at getting a vision of what ought to be done and how it will look – certainly better than your average bear. He’s significantly better. In fact, one of the best I have ever worked with – and I’ve worked with a number of crazy smart people. Everyone looks to his expertise, and when he isn’t brought in, quality suffers.

Today, I pitched a covert coup to the senior developer. The main thrust is that since we have the best handle on the development efforts in progress and have the most to say about design and implementation, we need to be overseeing the design process before it gets handed off to the developers. Thing is, there is already suppose to be a structure for all of this as part of the existing systems engineering team.

So, the coup is simple – we are put in charge of developers, and we manage the work that developers do. As part of that (and this is where the coup is manifest), we facilitate the process of system design becoming software design, which is where we are perhaps the strongest of anyone else on the team. This amounts to a coup because the senior developer and I almost always view the system design we’re presented with as a very rough draft that needs a lot of refinement – and in the end, we have something that kinda resembles but mostly doesn’t look like the original design.

The present justification we can use is that, really, the systems engineering team is presently too busy to address the needs and concerns of the developers … and we get bugged by all the developers when systems engineering is not available (i.e. all the time). There’s also the added benefit that the system architect doesn’t need to be a language weenie – he can focus on being a systems engineer, which is what he really only has time for it seems.

Right, so how is this covert. We’re making this covert in that we’re going to try to make this the system architect’s idea. This is the tricky part, but … it’s doable. The system architect already knows he’s overworked and too spread out. He freely admits to this. So, the plan is to bring up his workload, try to get him to express his frustrations (which he rightly has), and then do the whole “so what I think I hear you saying is …” and voila. It’ll take some time for it to ferment and mature for him, but it is so logical and “duh” that I don’t think it’ll take long for him to get on board. And if/when he comes on board … score!

This will free us to really optimally design our software and keep the engineers engaged and busy as appropriate. It lets us manage people we’re already managing more or less. And it lets us decide to take some risks within reason of our areas of responsibility to get things done.

All in all, I’m really pumped about this. I just need to make sure senior engineer is with me to follow through on it.

The one thing that is like the central theme for all my angst at work lately is simply: I see no value in my immediate leadership and management.

And this, according to them, is a virtue of our project.

I don’t get it. I don’t appreciate essentially making up work and doing said work while they loom over my shoulder and waiting to decide when they are going to step in and take over or take “corrective action.” I know it sounds crazy – especially making up work – but that’s more or less what I’ve been doing of late.

Management, in my view, is very much a flow down activity. You work with customers, you identify requirements, you identify design needs, you work the design, then you pass off to developers but hang around to monitor the situation, and eventually take back to work things through verification/validation/QA. Nearing the end of design and preparing to hand off is when the full team begins to get engaged – this is what we’re doing, this is why we’re doing it, this is how we plan to do it … any questions? anything people think we’ve missed? lets do it then.

The dynamics of my current project is such that the developers get dragged into meetings with customers, listen to what customers say, and pretty much do all the systems engineering on our own even though our leadership/management state they are to be doing these things … and get all in a tiff when they realize they are behind or cut out.

Over the past 3 days, I’ve talked with different people on the systems engineering/leadership/management team of my project, and I’ve been overly blunt and probably disrespectful about all of this. Do I think it will change anything? … no, not really. yet here I am, with this small core of hope deep inside that won’t give up.

So, when I’m where they are, the people underneath me will know how I’m working for them. They will know – even if it is just a high level – what I’m doing and how I impact them and the value I provide them. I do not want to ever engender this feeling of being left to figure it out alone while also being responsible to some nebulous, unidentified higher standard that no one cares to share until after the fact. My people have a right to self confidence, empowerment, and assurance that their leader is working in their best interest and how he does that.

Quick question for all you management types out there: is that really too much to do/expect/ask?