The Humanist Methodology: Humble Beginnings

Today is September 7th, 2015.

Labor Day.

Inspired by all of those who came before us to create a better world via sound labor practices, I've decided to start codifying the processes and best practices that I use on a daily basis as a software consultant into a centralized resource for anyone trying to gain greater output from their software development team.

Wait But Why?

Why would I offer up the knowledge that I use on a daily basis for gainful employment for free on the internet? Like many things in life, it's not a simple answer, but one I've been thinking about for as long as I've toyed with the idea of creating The Humanist Methodology. There are three pieces:

1. I want to leave this world a better place

Once we humans figure out all of the hard stuff (food, shelter, reasonable sized TV for watching football, etc.) we start thinking about self-actualization. How can I leave my mark on the world? How can I leave my children a better planet? How can I do something bigger than myself? If codifying the tips and tricks I've picked up from the brilliant minds I've worked with helps even one person achieve greater job satisfaction, one person get home to their kids on time, or one person keep their team together in a time of strife, that would mean the world to me. 

 My motivation.

My motivation.

2. I want to make myself better at my craft

I work in a high performance space. The games industry is volatile, opportunistic, and extremely demanding. Anything I can do to further codify, reinforce, and fool-proof the processes and operational details I bring to an organization, the better off I'll be. I know that there are people less experienced than me, studying what I do, and working hard to get better. I want those people to be asking questions, bringing new ideas to the table, bringing energy into the equation. Likewise, there are many masters of the craft who I can learn from in order to make this offering stronger. I want them to challenge my assumptions and battle test these notions. I want to become a stronger Humanist Software Manager.

3. You still need to hire me (or people like me)

Chris Galardi, an engineer I worked with at Causely, once summed up the role of production in the software development process very eloquently: "That's where the magic happens." It's true. You can have all of the best practices written down, all the best talent in the world, all the shiny toys and tools - and it will all surely help - but to truly achieve maximum output, you need a strong producer handling the myriad details of implementation and modification that come with mapping any process to a living, breathing team. You need good process, but without good producers, you just have a bunch of paper.

In short, I want to help you help me help you make the world a better place.

Who am I?

...and why should you care what I have to say about production and process?

My name is Coray Seifert. I'm a father of two, a production and strategy consultant in the games industry, and an avid football fan/blogger. I have a decade and change experience as a game producer, designer and writer. 

I'm generally brought onto teams to help build/grow teams, maximize velocity, and increase product quality. Specifically as a production lead, I've had successful stints at Slingo Inc., Causely (Formerly SocialBon), and Autodesk. I also make indie games here at Krakensoft. I've shipped 35 games, taught at a few universities, spoke at conferences like GDC, and served on the Board of Directors of the IGDA. 

I have enough experience to be able to bring subject matter expertise to the table, but I'm still ambitious and crazy enough to take on something like this and willing to adapt my methods as I see opportunity for improvement. 

So, what's next?

In lieu of publishing a book straightaway, my goal is to post a section at a time to this blog and hopefully garner feedback from a few trusted sources, before putting everything together in a single resource. I don't view the methodologies I employ in the workplace as a static set of rules; they flex and change as we as an industry realize new and better ways to make software. Accordingly, I'd like anything I put my name on to afford the same fluidity and responsiveness. 

I hope you'll join me on this adventure and jump into the comments section. I want people to challenge the assertions and assumptions set forth in this series of posts, especially if you have an experience, idea or research that counters what I'm bringing to the table.

Thanks in advance for your participation and a Happy Labor Day to you and yours.

Coray Seifert