Win Them Over

I’ve been thinking more and more about the individual developer, the challenges that they face, and the daily needs that they have (like standups and other such engineering activities).

And the more and more that I’ve focused my conversations around the individual engineer the more I’ve been reminded that they (we) are the key to the very future of our world.

I know, I know – it sounds pretty hyperbolic (and it is) but as the world becomes more dependent on software and the code that sits right beneath the surface, the more important the developer and engineering class becomes.

I’ve seen it. I’ve experienced it. I know what it’s like to feel to be wanted, to be needed, to be desired, and to be considered an indispensable part of a team and organization. It feels good, to be sure and the need is even greater now than it was when I first started.

Unfortunately, the world has not been able to keep pace with the rise of the developer class (and the ever-increasing Developer Graph) and old-guard thinking is still as pervasive as ever, especially in the enterprise.

Decision making is still top-down in all the wrong ways when it should be more bottom-up. The growth of open source has helped but politics and bureaucracy are still very much a part of what the developer has to deal with day-in and day-out.

Perception, reality, and use.
Perception, reality, and use.

I’ve been meditating upon the above concentric circles for the past few weeks and the longer I’ve been sitting on it the more upset I’ve become. Earlier in life, as a young developer, I didn’t quite understand this dynamic and then I was rudely and suddenly introduced to this paradigm when I joined (at the time) the largest personal computer company in the world.

They had just crossed 90,000 employees and were growing a few hundred a week it seemed and the engineering department (or my small feature-centric one) was nearly 150 developers). Software and tooling decisions were made from somewhere up high in the nether, they were handed down to the teams, and then we were told to utilize and deploy.

And no one was happy.

We all found workarounds and built small black boxes with local environments running local apps so that we could do our work effectively and efficiently. Our managers either knew about it and ignored it or were completely oblivious. In fact, they may have been a bit frightened by the prospect but no one ever said anything.

Why? Because they knew that we were some of the most important assets to the system and the very lifeblood of the protocols and software that was running a billion dollar company. Although a lot (if not all) of it was duct taped together it worked and everyone above us were generally happy, for the most part.

But we, the developers, weren’t happy. We weren’t happy with the ambiguity of the timetables, the inability to know project schedules, velocity, and the underlying expectations that surrounded them. We didn’t like that we had dissimilar vernaculars and dictionaries, even among similar engineering departments. We didn’t like that we didn’t get to choose our own tools.

What most companies know now is that you have to optimize around developer happiness. This would include internal systems, processes, tool decisions, and the very culture of decision making bottom-up, not top-down. To win the enterprise (and the business) over you have to win the individual developer over.

Because without the developer then you really don’t have much of anything except an idea and wishful thinking. I believe that it’s possible to build a tool that makes developers happy, engaged, and excited… and, at the exact same time, creates visibility, transparency, and value for all parts of the team, technical and non-technical alike.

I believe that hitting the target (the middle) of those three concentric circles is possible; it’s not supposed to be easy but it’ll be worth it. But we all start at the same point: Make the individual engineer and developer happy and the rest will follow suit.


Also published on Medium.

Leave a Reply