Category Archives: Career

A Digital Ecommerce Transformation – Lucky to Have a Coach – Part XVIII

Part XVIII in a multipart series, to start at the beginning, goto Part I.

2012 was the year that I really began working for the VP of Operations at TWLER, Judy D. In 2011, the Chief Architect for TWLER decided to leave as the investment in the rewrite of TWLER.com was cut in half, see Part VII for more on that episode. Over the course of 2011, I became the main point of contact for the team, but didn’t completely take over till later that year.

To this point in my career, I had been leading many large Enterprise Java programs, mainly as a consultant, and had just finished an MBA. I had about 18 months of pure engineering management at United Health Group, having a team of about 25 writing online wellness programs. However, that management position didn’t end well, and I learned much and more about politics at large companies.

I did not have an extensive track record of management, but because I had spearheaded the funding effort and defined the vision for the future Ecommerce platform, I became the manager of the team and was promoted to Director. Much of the work we did is detailed here, or will be detailed here in the future, today the discussion is about having a great manager as coach.

I’m going to say, as a manager, I was very rough. During my time at UHG, I had four managers in 18 months, so I received very little direction or coaching. As the lead Architect and Engineer on many programs, I was only interested in software competency and delivering systems. If you couldn’t help me do that, you were dead to me. I was rightly accused of being blunt, straightforward and lacking empathy at this point in my career. I didn’t really care, I knew how to hire great engineers, build teams where everyone had fun while delivering more than asked, and being a total pain-in-the-ass to whoever was lucky enough to manage me.

But Judy decided to invest her time and started giving me feedback on how I was acting and how I was being perceived. It was the first time in my career that someone had explained perception being reality, not logic and data. In meetings with the VPs and Senior Directors in IT, I would get worked up because they knew how to push my buttons. Once you’re in attack mode, you’ve lost the room; everyone thinks that if you can’t manage yourself here, you must not be a good manager overall. Judy helped me understand how to deflect criticisms and attacks on my project’s direction, by acknowledging the speakers point, and then presenting why I thought our direction would work. Never directly saying the other person was wrong, just that our current direction was working.

Learning the managerial arts of controlling meetings, protecting my reputation, and letting others be right (even when they were wrong), helped my project thrive by giving me the tools to fend off the IT team without offending them or giving them ammunition to take back to their leaders.

Judy always took the high road, she didn’t care if others were being assholes, it wasn’t an excuse to be an asshole too. She would always let me know she’s heard about my latest escapades at meetings across the company. She no longer wanted to hear negative news; she only wanted to hear how I was helping people, nothing else.

This process was long; Judy would debrief me after meetings and point out exactly where I lost the room and when I went off on a rant. But I was willing to listen, and I corrected my mistakes. Over time, it was as if I had been in management my entire career. I had learned to manage my reactions, while also managing the outcomes of the meetings and the perception of my team and myself.

I can’t thank Judy enough for the coaching effort she put in to teach me to be a Director at TWLER, and later a VP for Fortune 100 companies.

Goto Part XIX

A Digital Ecommerce Transformation – Making the New Mission: A Whole New Architecture – Part VIII

Part VIII – To start at the beginning goto Part I.

I’ll admit it, the deck I made was terrible, I’m not a master of Power Point, and the color scheme left a lot to be desired. I had crude animations showing how we would shift our monolithic application into the cloud, while retaining the customer data and checkout processes in the datacenter.

For about three weeks I worked mainly with another architect to take the many ideas we had discussed over the last year, and what we’d learned about operating in a cloud, and turn that into an architecture vision and implementation plan. We settled on three years to transform the ATG system to a distributed service oriented layered cloud architecture. The deck outlined the current issues with the ATG system, the future state architecture and how we would get there, and the cost of the first year of development.

My colleague urged me to begin presenting the deck to interested parties to get feedback and learn what resonated with the various digital teams. He was instrumental in networking across the organization and arranging meetings with Directors, Senior Directors and VPs in Digital and Business teams.

The first presentations did not go well, the business leaders didn’t get much from a highly technical deck with $13M of capital tied to it in the first year. Mostly the feedback was that we’ve heard this pitch multiple times over the last ten years, why should we believe you? They had a point, numerous consulting firms had been through with grand plans to rewrite TWLER.com. It had already been attempted twice, the last attempt a failed implementation of the Microsoft Commerce system that was relegated to powering the Canadian site and failing miserably even at that effort.

We regrouped and tried to determine what would make this a better presentation. We knew many of the core problems with the site and that the business teams had been unable to make changes in the homepage or product detail pages (PDPs) for years. There were a few decks kicking around that defined the UX driven future of TWLER.com that would never be implemented due to technology failure. We decided to modify the deck and highlight that in the first year we would transform the homepage and PDPs into a new architecture that would allow fast changes and high scale utilizing the CDN for more caching and isolating all calls to the cloud layer. In that way we would severely limit the number of calls making it back to the ATG commerce system running in the datacenter allowing it to scale by relegating it to the Cart and Checkout functions.

There wasn’t anything we could find that outlined a similar architecture so, as far as we knew, we were embarking on a bold new way to use clouds at scale.

GOTO Part IX

What Do Architects Do? – Part 1

Having been Chief Architect for Best Buy and currently Chief Architect for Target, I get this question frequently.  The question occasionally comes at your neighborhood party but generally it’s from people in Engineering or Marketing.  At the neighborhood party you attempt to answer this question at risk of becoming known as the “boring tech guy.”

What do architects do?

People ask this question because they truly don’t understand.  They are really asking “Are architects necessary?”  They ask this question because they have rarely seen value from the architects they’ve seen in the past.  This is the sad reality of much of the architecture world, enterprise architecture in particular.  My opinion on why architecture has devolved to a place where many companies are eliminating the practice altogether is simple.  Most architects in the upper echelons of companies were never software engineers.

Why this is important and is a point I harp on continuously, is that if you haven’t spent your 10 years writing code and building and running systems with higher and higher business complexity, you cannot do the first thing architects should do.

Answer #1:  Architects create the environment for engineering culture to thrive.

To create an engineering-centric culture, you have to have been an engineer.  You have to have a few large scale Agile/DevOps systems under your belt.  You have to understand what drives and motivates engineers that want to work on six person teams tackling the toughest problems facing enterprises.  You need to feel it in your gut when one person on the team is a hack and can’t pull their weight and your management won’t address the problem.  You must have found the rock and through sheer force of will, pushed it up the hill, leading in such a way that the rest of the team helps push it along with you.   If you haven’t done these things over the course of years, you haven’t been a software engineer.

Architects that understand how engineers want to work, spend all of their time and energy creating an environment where hard problems are solved, new solutions are found, and everyone sleeps well at night.  Architects make decisions based on whether engineer’s will understand them and choose them regardless of what else is available.

Architects also create the constraints that allow engineers to solve their problems quickly.  With the near infinite array of tools, frameworks and packages available, to remain economically competitive, enterprises need to limit the scope of technology in some way.  Make no mistake, architects select and limit technologies, but only those that involve large expenditures.  If a technology selection will cost a company in excess of $1M for licenses, subscriptions or maintenance over a five year lifespan, architects should be involved.

Architects essentially act as the aggregated will of the engineers.  Architects are there to make engineer’s lives easier.  Architects in effect are servants of both engineers, and the enterprise and walk the fine line that brings the maximum value to both.

 

Peak Architecture

I believe peak architect occurred somewhere around 2013, that was the year with the most people employed with architect titles ever. Since 2013, we are now entering the post-big-architect era, where architect roles are quickly shrinking in the tech world. This is a good thing.

The number of roles with architect titles in industry was getting ridiculous. I can riff 20 titles in less than a minute if I try: Data, Technical, Web, Digital, Application, Cloud, Security, Infrastructure, Network, Business, User Experience, Information, Middleware, Enterprise, Solution, Sales, Product, Project, Principal and my personal favorite, Sharepoint. The question is, what did all those architects do?

My contention is that they completely messed up most companies by proclaiming they knew how to select and manage technology at large companies, and forced vast numbers of engineers to conform to a highly limited set of technologies in the name of fiscal conservatism. Then retreated to their own worlds to rest and consider the next great set of technologies they would enshrine five years from now.

What is the optimum number of architects for a company?

The answer to this, like all math problems, is 0, 1 or some hard to derive number. Zero and one are actually quite good answers. Zero is complete engineering anarchy, you’ve decided to let the engineers do whatever they want. If they’re good engineers, they might actually make an amazing system by developing external APIs which hide all the technology choices from the outside world.

One is also a great answer, you’re basically saying someone needs to think about the company as a whole, and one insanely smart person can get a whole company pointed in the right direction, or they can spend a lot of time thinking and watching engineers do whatever they want. One architect can spawn ideas, if they’re in touch with the engineers, that just may be enough to get people pointed in the right direction.

A better number is some ratio to the number of engineers. But what ratio to pick? Too low and you have architects running over each other to tell engineering teams what to do. Something like the commissioned sales model, “that team was mine, I talked to them first.” Too few and you’re not much better than 0 or 1. My personal favorite ratio right now is 1:100, one architect for every 100 engineers. That seems to be enough to get some rational standardization (if you don’t like standardization, deal with it, every company beyond startup mode has some set of standards), while allowing engineers to fight the power and pick new technologies when necessary. Since technology is progressing faster and faster, it’s essential to keep new technologies flowing into an organization, and old ones leaving (sometimes 6 months is old!). Relying on a few individuals to follow these trends and pick the right tools for everyone is impossible. But sourcing newness from those engineers willing to push a new idea over a few intentional roadblocks will keep your organization current enough to remain relevant.

Peak architecture has passed, time to jump on the bandwagon and become engineers again!

Open Source North Rides Again

We had another fun and exciting rendition of Open Source North in June earlier this year (2016). It’s a conference that eventually will be recognized as the premier technology event of the year in the Twin Cities. Well, that’s my prediction at least.

I had a great time and got to give my presentation/group discussion on the state of Architecture in the Midwest and how the practice needs to be redefined. Architecture means nothing these days, Enterprise Architect in it’s traditional form is dying, and Engineers are taking over the space once occupied by Architects. Why have an architect if you can have an engineer do the same job and deliver the working software as well?

Hope to see you again next year!

Tech Cities 2016 – The Agile Architecture Game

Coming up in February 2016 I’ll be facilitating the Agile Architecture game with my former colleague and game inventor Kevin Matheny.  We’ve used the Agile Architecture game within BestBuy.com to help project managers, business analysts, product managers, engineers, and others learn about the tradeoffs involved with long term software architecture choices.  It’s a fast way to learn about the hard choices that architects make every day.

One of the comments from a person at Best Buy that played the game was “It felt like work.”   This person was an architect so we felt like we got the game right.

Tech Cities 2016 is a conference sponsored by the Carlson School of Business to foster the vision of Minneapolis being the tech center of the North.

It should be a fun conference!

Open Source North, A Great Start for a Tech Conference in MN

The OpenSourceNorth conference put on this weekend by Solution Design Group was a rocking success.  Local design, local speakers and just a little local beer made for a good time.

IMG_2174Best Buy had a recruiting booth at the conference and hopefully you had a chance to stop by and chat either with a recruiter or an engineer.  If not check out the BestBuy.com jobs located here.

osn_pic2I had a chance to give a new presentation on how and why engineers should be engineering managers, at least a few of them.  If we ever want more great places for engineers to live and work, someone needs to create them.  Only individuals that understand how software engineering really works can create those places.  Here’s a picture from the conference.

If you couldn’t make it this year, put it on your calendar for next year.

Revolutionary’s Revenge

Sometimes I think I studied the wrong field in college, I should have been a political scientist or a historian. Having studied in those fields it may have helped me understand that the worst thing that can happen to a revolutionary is to win the war and end up governing.

A true revolutionary is not doing what they do because they are seeking power, they are championing an idea, a culture or a different way of life. They believe it; to the point where they’ll risk their lives in a real war, or their professional career if they work in a corporation. We’ll stick to corporate revolutionaries for now, it’s a little bit safer.

The thing to remember is that most revolutions fail, which is great because the corporate revolutionary can move on to the next place with their ideals intact and their pride unblemished. They haven’t had to face real decisions that would affect how they view themselves and their core beliefs.

But what if the unthinkable happens and the revolution succeeds? Now you’ve got a bunch of idealistic, stubborn, socially awkward and politically unsavvy people running your organization. No one wants that, you’ll be replaced by “real managers” the second you make a big mistake.

First, believe that a powerful force is waiting on the sidelines to determine whether the result of the revolution is a new paradigm that improves the old, or a purveyor of ideals that must be snuffed out quickly lest they infect the entire organization. As the new governing body, you need to exude ineptitude while clandestinely shoring up political position and making some new friends of old enemies. Once you’ve established a culture and moved systems beyond the point of no return, you can show your true hand, your competency, and institute the revolutionary ideals that were the driver of all the change.

This is where reality sets in. Running a revolution and governing a semi-stable organization are two distinct beasts. In revolutionary times, it’s us against them, there’s always a big enemy out there to drive camaraderie and take the brunt of negative emotions as they crop up. However, once the enemy is gone, the emotions turn inwards and now you are left arbitrating disagreements between former allies and making decision you know are bad, but are necessary to prevent chaos.

The skills of the revolution are not the skills of maintaining and building incrementally on top of established practices. If you cannot make the shift to sustaining governance, everything you fought for will eventually collapse and regress to the mean. Temperance, consensus, collaboration, compromise are all words that would cause the revolution to fail, but are necessary to sustain the new system over time. Operating in the same environment for multiple years is massively more difficult than moving to new gig every year. It is also massively more rewarding to see a system build, grow and become the new normal. After five years it is firmly in place and no longer can be replaced, that is, until the next revolutionary comes along…

I’m In the Library!

This may be a bit self-promotional (but then it is a blog) but I made it into the library!  Wow, you say.  Well let’s step back to childhood and growing up in an academic family where the measure of worth was not just how many Bachelors degrees a person had, that was small potatoes, but how many PhDs, law or medicine degrees a person had.  In my extended family, two or more was the norm.

So imagine the horror when I dropped out of the PhD program for Nuclear Fusion at the University of Wisconsin.  Yes, I am a failure at life.

Fast forward 20 years or so and I just wrote an article for IEEE Software magazine.  When I was writing it I didn’t realize that IEEE Software is one of those journals that appears in libraries in Universities around the world.  However, I discovered that today!  I have an actual citation!  I’ve finally done something the family can be proud of!

Screen Shot 2014-06-07 at 12.22.29 PM

What’s Wrong with the Twin Cities’ Developer Career Path

I’ve hired over 100 developers and architects throughout the years.  I’ve worked at around 20 companies, some very briefly, as both an employee and consultant.  I like fast development teams that ride the fine line between excellence and chaos.  But I’ve recently come to understand that a lot of my attitudes around being a developer in the Twin Cities are vastly different than those of our West Coast brethren.  This post is full of vast generalizations so your particular situation may not apply, bear with.

Twin Cities Career Path

As a software developer in the Twin Cities, the general path is to get your foot in the door anywhere that will hire you.  Small companies, large companies, whoever will pay you to learn enterprise scale, team oriented development.  Honestly, your first 5 years as a developer probably cost the company you work for more money to have you there than your worth in business value.  Even so, you’ll add the most value at a small Agile shop where you get to do everything from development to deployment to maintaining the Cloud infrastructure.  Your learning experience at these places will set you up for your next 10 years of work.

Career Choice

Anywhere after your 5 year mark you get the choice to become a career developer.  Around here is where all the people that can’t really cut it become PMs or BAs or some other manager.  This is a fine choice as the life of development can be tough.  But the choice for developers is to continue to work as a cog in the corporate machine or to become an independent or sponsored (employee at a body shop) consultant.

Employee Route

When you go the employee route you get perceived stability in exchange for little control of your own destiny and work.  Due to the nature of financial funding of development projects, employees are often relegated to maintaining existing systems or as the token employee or two on the new development projects staffed by contractors.  You’re only on these projects because they want someone to maintain the system after all the consultants leave.

Why is this the case?

Budgets at corporations split development into two buckets, capital and expense.  Projects that can be capitalized allow the company to depreciate the cost of the development which saves them money on taxes.  Projects that are expense go right to the bottom line of the budget and are a drain on that division’s profitability. From a bean counter’s perspective, adding flexible staff to write new development projects makes the most sense as the cost of consultants is higher than the cost of full time staff.  That higher cost then gets depreciated and the ongoing maintenance expense goes to cheaper full time or offshore resources.

Why does this limits the career path in Minneapolis?

What this means to you as a developer is that, since your value is lower to the company as a pure expense, the amount company’s are willing to pay you is limited.  Thus the salary of a full time developer in the Twin Cities is capped not far north of $100,000.

Consultant Route

As a consultant, you can make significantly more with a similar amount of experience.  The rates vary greatly depending on your skill set and experience level but rates to the consultant between $80 and $120 per hour are fairly common.  Also, when a company pays this much for development resources, you are more likely to land a new green field project as the project is capitalized (and can be depreciated).

Career Results

Given the general climate of Twin Cities development, the more aggressive and generally higher quality developers go into consulting once they realize the limitations of working in the Twin Cities.  But, while the pay is better the career path is over at this point and one risks being a developer hopping from contract to contract for one’s whole career or until your skillset is no longer valued.

West Coast Difference

Having not lived there, I’m now going on conversations with the west coast engineers that I know.  In general, they’ve described the opposite situation as exists in the Twin Cities, where the vast majority of developers stay full time employees and the number of contractors is limited.  Also, that the best development talent is always scooped up by the numerous tech companies in the area at high salary plus stock options.  Plus, the culture of the startup breaking out is always there and quite tangible.  The latest story being InstagramThe Instagram writeup in the New York Times drives home the point of what is wrong with the Twin Cities.  This excerpt sums it up:

The extraordinary success of Instagram is a tale about the culture of the Bay Area tech scene, driven by a tightly woven web of entrepreneurs and investors who nurture one another’s projects with money, advice and introductions to the right people. By and large, it is a network of young men, many who attended Stanford and had the attention of the world’s biggest venture capitalists before they even left campus.

What is wrong with the culture of the Twin Cities tech scene?  These structures just plain do not exist here and that is the main culprit behind the exodus of top talent in the Twin Cities to mercenarial endeavors.  With all those smart minds going to short term financial reward, there will be no culture of risk taking, the financial availability won’t appear and the notion that ideas for the next billion dollar startup are ubiquitous will never materialize.

How we can start this in the Twin Cities will be difficult.  It involves getting the venture capitalist and angel’s around here to start taking chances on smart college kids and catching them before they hit the Twin Cities career path.  Once they are in, our culture will take over and they’ll be consultants before you know it.  And the next generation of risk takers will be lost.