What I Know Now That I Wish Someone Had Told Me at Year One
Year one in IT you learn the technology. You learn the systems, the platforms, the protocols, the commands, the configurations, the tools. You build the technical vocabulary that becomes the foundation of the entire career. You are, appropriately, obsessed with being competent at the technical work, because the technical work is visible and assessable and the feedback loop is tight: you either fixed the problem or you did not, the system either works or it does not, the script either runs or it throws an error that tells you exactly what you got wrong. This feedback loop is one of the great pleasures of early technical work and one of the reasons IT attracts the people it attracts. The right answer exists. You can find it.
What I know now, fifteen years in, is that the feedback loops get slower and less legible as the career progresses, and that nothing in year one prepared me for that. The decision I made in a planning meeting in January might not produce visible consequences until October, by which time four other things have changed and the causal chain is obscured. The relationship I invested in with a business stakeholder might not produce value for two years, at which point it produces a great deal of value very suddenly and the connection to the original investment is not obvious to anyone watching. The team culture I was building, decision by decision, meeting by meeting, in the first year of a leadership role might not be legible as culture until the organization is under stress and the culture either holds or it does not. These are the things that matter most in the long run and they are the things that are hardest to see in the short one.
I wish someone had told me early that the most important things I would learn about this work would not come from certifications or courses or technical documentation, though all of those matter. They would come from paying close attention to the humans around me: the ones who were excellent at building trust and what specifically they did to build it, the ones who consistently got resources for their initiatives and what they understood about organizational persuasion that others did not, the ones whose teams wanted to follow them and what they did in the ordinary moments of the working day that made that true. Technical skills can be learned from documentation. These skills can only be learned from observation and deliberate practice, and most IT environments do not build structured development pathways for them because they are not on the certification list.
I wish someone had told me that every investment in making my work legible to non-technical stakeholders was worth more than the same investment in technical depth, past a certain baseline. Not because the technical depth does not matter. It does, enormously. But the technical depth that cannot be translated into business language that moves organizational decisions is technical depth that serves the work you are currently doing rather than the work you want to be doing next. The career progression in IT is not primarily from less technical to more technical. It is from individual technical contributor to organizational influencer who happens to have deep technical credibility. That shift requires a different kind of investment than the one year one makes visible.
Go back and give year-one you one piece of advice. I will go first: learn the technology seriously, and with equal seriousness, learn the organization you are doing it inside of. Both are systems. Both have rules. Only one of them is in the documentation.
