Technologists for innovators

“And then you do your tech stuff,” I said to the business analyst, architect and regional CTO. They stared back. Apparently, calling it tech stuff isn’t a way to engender unbridled engagement from technical people.

Learning to work with technologists.

When I joined EPAM, I felt like I had enough technical knowledge to fit in. Reading MIT Technology Review. Ruminating on algorithms shaping influence on society. Coding HTML and CSS. All of these skills were part of my toolkit.

Nonetheless, when it came down to it, I kept hearing that I lacked technical know-how.

Now that I’m reaching a better spot in my learning curve, I realise that some of my learnings are so painfully rudimentary, no-one thinks to share them. Who the different people in a delivery team are. The artefacts they work on, what they look like, what they use them for.

It isn’t knowing about, it’s about knowing how.

My mistake was to focus on learning about technology. I needed to learn how technology is made by large-scale teams. You can’t work with a team that is doing things that you just don’t understand. And you can’t gather a nuanced appreciation for the complexities of a delivery program until you’ve really engaged with one.

For the next couple of weeks, I’m going to share what I’ve learned about delivering technology at scale. Don’t waste your time reading these articles if you are working in a scaled agile team already. This is for the people hanging out at the edge trying to wiggle their way in.

So, back to my “do your tech stuff” comment. It turns out that calling software delivery “tech stuff,” is an oversimplification that can only be offensive. There’s a huge diversity of expertise in a software delivery team, and if you understand it, and respect it, you can leverage each member individually to create outstanding market-leading products.

So this week, we’re looking at who all these tech people are.

The people who create software.

Product Owners

Product Owners make strategic decisions about what to build when. Giving strategic direction to the software (the product) they have to straddle development, design, business strategy and customer demand to make choices that maximise value for everyone. Good POs are notoriously metrics-driven (they need to prove they’ve been successful) and have their fingers in a lot of different pots, but not very deeply. Usually their technical skillset is in understanding the delivery process, but not necessarily being able to code.
Some things they make: roadmaps, vision, KPIs, decision-making frameworks, decisions

Designers

Designers think about what people will see when using the software. They think through how customers will move from screen to screen, what parts go onto every screen, and the best way to present those parts so the user understands them. Good designers focus on users, and catering to their needs. They’re also experimental, exploring lots of different options and setting up realistic tests (from AB tests to guerrilla interviews) to make sure that the designs actually do what they promise.
Designers make: screen designs, user flows, information architecture, design library, usability tests

Business Analysts

Business Analysts write detailed descriptions of what the software should do. They work with clients think through every detail of how the software should work, and compile them into documents called user stories. Good BAs are thorough, detail oriented, and are able to represent the needs of customers, the businesses, and the technology team in the requirements they define. Their roles can be flexible, sometimes moving into the UX space, sometime more similar to product management.
BAs work on Requirements, User Stories, Backlog

Delivery Managers

Delivery Managers and Project Managers oversee how everyone works together. Agile organisations have multiple teams working parallel to push out releases, DMs coordinate all the moving parts. Good DMs have a handle on all the processes going on around them. They help untie knots in the development process, and always have their eye on deadlines and KPIs. DMs and PMs are largely the same. In a large scale program, a DM oversees the PMS, and each PM oversees a stream of work.
Delivery Managers work on release planning and assignments

Architects

Architects the multiple discreet units the software is made of (and on). They approach code from a broad strategic perspective, so they understand what functions sit inside which systems. They define how these systems work together as a whole and what function sits within each. Architects are the right people to ask when you want to know how hard it will be to implement an idea. Know that they can’t feasibly estimate how long something will take without firmly defined functionality. And even then, they’re work is creative and strategic, imagining how to implement your thinking in the most elegant and efficient way possible.
Architects deliver system architecture maps, estimates and technical feasibility assessments

Developers

Developers write code, also called engineering. Developers take on assignments from the backlog, read the user stories there and figure out how to implement the work technically. Front end developers build the code that makes visuals and interactions work, back-end developers create the intricate functionality. Developers can seem rigid in their thinking, wanting to know exactly how something should work and getting frustrated by vague requirements. That’s because wrangling a computer into doing things that are useful for humans is a creative act of its own. Their brains are so focused on that work, they rarely find time to also think about the human side of things.
Developers deliver working software in the form of code.

Testers

Testers check the finished software to make sure it works as specified in the user story. They devise manual and automated tests to check every bit of the functionality making sure it’s perfect before go live. Good testers are thorough and creative. They know how to find the issues in a software. Both the technical cracks and the human level errors like when a headline says you can search for Panama, and Panama’s not in the search results.
Testers create testing plans, and conduct tests like UAT, SIT and so many more.

Understand their roles and leverage their unique expertise.

There is a huge diversity of roles in a development team. And when you understand their unique contribution, you can start to leverage them each individually to make things happen. Ask a product manager to help you understand how your idea can find product-market fit. Ask a BA to help you turn your idea into something that’s ready for engineers to interpret and work on. Talk to Architects when you want to know how hard something will be. Each person has been polishing their peculiar skillset across their career, and will be happy that you see the power of what they can do.