Why I am not posting

I thought I would share a little about why this blog has been relatively silent lately. Some of it may feel like excuses while some may look like legitimate reasons. The truth is that there probably are a little of both.

I get my blog posts from two sources. First I read lots of other blogs and some books. Second I use experience in my job and to a lesser extent my personal life.

As I have mentioned in other easy to find outlets I am now employed as an IT Project Manager. This is a good thing. It helps keep the family fed and clothed. The person whose house we’re living in kind of expects some money back for the privilege. Pretty standard stuff really. It does limit my time for reading the blogs I used to keep up with. As I settle into this new position I hope to start gaining some time to keep up with relevant blogs again. As of now I am still in “fire-hose mode” and pretty exhausted by the new environment and routine by the time I get home. Basically, I don’t get much of the extra reading done I used to. I will also start getting ideas for blog posts from my work environment as time goes on. As anybody that works and writes about related topics knows this is a bit of a tension to manage. Historically I do this two ways, obfuscation and delay.

I try not to mention the company I work for when writing. It’s not hard for anyone to figure out if they want. Also, I’m human and have been known to make mistakes from time to time. I also do not mention people by name. I try to de-gender my writing as well, but I’m pretty bad at that. Finally, I tend to be as general as possible about the specific situations/technologies/ect when writing.

I’ll give an example from a long time ago at a previous job. Even so, I’m not going to mention the company. (Doubly safe due to it no longer being said company…) The situation was a need to increase collaboration between disparate campuses. I would have shared that at face value. I would have even been willing to go into some detail about how the network connections were fairly standard Cisco vpn tunnels over T1 lines for the most part. I think the main office had dual T1s. It sounds slow now, but it wasn’t bad for the time. The data we were trying to share between campuses was large CAD files and file groups. We were trying to make it so someone from any location could work on CAD files at any other location without incurring a huge slow-down. I would have hedged this a little. I might have framed it as sharing databases between sites or just calling out “drawings” instead of CAD specifically. Basically, the least amount of information I could give to convey that the files were huge, but the changes made were usually relatively small. Also, file locks and constant communication between the workstation and server where the file was hosted came into play. I would have articulated that as well as I could. I would’ve mentioned that I was doing the primary research and we had two stakeholders outside the IT team doing ancillary research. I would have mentioned our testing methods on the solutions we tried as well as I could with the level of detail already mentioned. Finally, I would have stated the specific solution we decided on because it was that good for us. (Riverbed caching and compression servers. They worked really well.)

All of this would have been posted about a month or two after the fact, or at the very least offset by a week from the actual events. This is the time-shifting portion.

Basically, my posting goals include as generic of data as possible. This not only protects my company and team, but also allows more people to see a way to apply the concepts to their own situation. My other posting goal is to delay enough so that if identities are compromised it has no negative effect.

What this means going forward is that I will slowly pepper out some posts here and there for probably the remainder of the year. By then I may be able to start peppering out posts inspired by work. Barring that I should be more in tune with the routine such that I can get more reading done and add my thoughts and commentary to the conversation.

There is one thing that may change though. This position and environment is pretty different from my previous development one. That means my work inspired posts are going to start skewing more towards project management and further from software development. That said, I still see it as an Agile Journey. I intend to approach my work with an Agile mindset in this new role just as much as I did in my previous one.

Has anyone else made the transition in the last few years from development/scrum master to project management? I’d love to talk about your experience in the transition.